はじめに
どの会社にも、「地味だけど、なくならない定型業務」があります。複数のシステムを行き来して、情報をコピーして、別の場所に貼り付けて……。1件ずつは数分でも、積み重なると相当な時間を食う——あの手の作業です。
今回ご紹介するのは、まさにそうした業務を抱えた、あるクライアントとの取り組みです。クライアントは、人材紹介会社。「この手作業、AIでなんとか自動化できないか」というご相談から、すべては始まりました。
ただ、いきなり本格的なシステムを開発するのは、費用も時間もかかります。そこで私たちは、まず「実証実験（PoC）」として小さく作ってみることをご提案しました。AIを活用すれば、どこまで自動化できるのか。現実的なコストで成立するのか。それを見極めるための、お試しのプロジェクトです。
2026年春、私たちはこのPoCに取り組みました。結果として、クライアントの担当者の手作業は、PoCの範囲でほぼゼロに。
この記事では、その作っていく過程を公開します。きれいな成功談でも、「完璧な正解」を見つけた話でもありません。PoCだからこそ見えた「どこまでできて、どこからは本格的な開発と専門家が必要か」——その線引きまで、正直にお伝えします。
そして実は、この自動化ツールには”つなぎ込む先”がありました。その全体像も、記事の後半でお話しします。
※特定のツール名（各ATSや利用サービスの固有名）は伏せています。ただし業務のシチュエーションは、人材紹介の現場をご存じの方なら「あの作業か」とピンとくる程度に、具体的に書いていきます。
クライアントが抱えていた業務
まず、どんな業務だったかを、具体的に整理します。
人材紹介会社の仕事は、ざっくり言えば「求人企業」と「求職者」をつなぐことです。そのためにはまず、取引先の求人企業がどんな人材を求めているか——つまり求人情報を、手元に揃えておく必要があります。
ところが、この求人情報が、きれいに一か所にまとまってはいません。
- 求人企業はそれぞれ、別々の採用管理システム（ATS）で求人を募集している
- クライアントはエージェントとして各ATSの求人を見られるが、ATSごとに画面の構造も、項目名も、フォーマットもバラバラ
- 中には、求人票がPDFで渡されるだけで、項目ごとに整理されていないものもある
- 新しい求人が出る・募集が終わるたびに、担当者が1件ずつATSを開いて、求人票を読み取り、自社の求人管理システムに手で登録していた
「あるATSでは『給与』、別のATSでは『想定年収』、また別のATSでは項目すらなく求人票の本文に埋もれている」——こうした”ゆらぎ”を、担当者が毎回、頭の中で読み替えながら入力していたわけです。
人材紹介の現場をご存じの方なら、「ああ、あの作業か」と思い当たるのではないでしょうか。1件1件は、できる作業です。でも取引先と求人が増えるほど、時間も、ミスの確率も膨らんでいく。クライアントが「なんとかしたい」と考えたのも、当然でした。
なぜ、これまで自動化されてこなかったのか
こうした業務の自動化は、昔から「やりたいけど、できない」の典型でした。クライアントも、ずっと同じ壁に突き当たっていました。
本格的に外注すると、高い
専用のシステムを開発会社に発注すれば、相応の費用がかかります。「この作業のためだけに」と考えると、費用対効果が見合いません。
かといって、社内では作れない
業務を一番わかっているのは現場の担当者です。でも、その担当者はコードを書けない。「作れる人は業務を知らず、業務を知る人は作れない」——よくあるねじれです。
「とりあえず試す」手段がなかった
本格開発はオーバースペック。でも放置はつらい。その中間にある「小さく試してみる」という選択肢が、これまでは現実的ではなかったのです。
この前提を変えたのが、AIとの協業でした。人が大まかな方向性を決め、実装とテストはAIと進める——この形なら、専用の開発チームを組まなくても、小さく・速く・現実的なコストで「動くもの」を形にできる。だからこそ、PoC（実証実験）という進め方が成り立ちました。
作っていく過程
ここからが本題です。私たちが実際にどうPoCを作っていったか、順を追ってご紹介します。
STEP 1：業務の棚卸し（ヒアリング）
最初にやったのは、コードを書くことではなく、クライアントの業務を、徹底的に言葉にすることでした。
- どのATSに
- どんな求人情報が
- どういう形で登録されるのか
- それを最終的に、求人管理システムのどの項目に入れたいのか
これを、担当者へのヒアリングを通じて一覧に書き出しました。AIに「自動化して」と言う前に、業務を正確に説明できる状態にする。ここが出発点です。実は、この棚卸しがPoC全体でいちばん重要な工程でした。
STEP 2：「何をきっかけに動くか」を決める
次に決めたのは、ツールが動き出すトリガーです。
幸い、ATSには「求人企業に動きがあると、エージェント宛に通知メールが届く」という仕組みがありました。『◯◯社から、新しい求人の推薦をお願いします』『◯◯社の求人がクローズされました』——人材紹介の現場で日々届く、あの通知メールです。
そこで、この通知メールをきっかけに、ツールが自動で起動する設計にしました。新着の求人なら情報を取りに行き、クローズなら募集終了として扱う。
担当者が「そろそろ確認しなきゃ」と思い出す必要がなくなる。通知が来たら、ツールが勝手に動き出す。これだけで運用負荷はぐっと下がります。
STEP 3：ATSごとに、求人情報を取り出す
ここは、地味に大変なところでした。
前述のとおり、ATSごとに画面の構造がバラバラです。そのため、ATSごとに「求人情報の取り出し方」を用意する必要がありました。
ここでの進め方を、正確にお伝えしておきます。AIに丸投げしたわけではありません。「どのATSから、何を、どういう形で取り出すか」という大まかな方向性は、私たちが決めます。 そのうえで、その方針を形にするコードの実装と、それがきちんと動くかのテスト——いわば”手を動かす部分”を、AIに委ねる。役割分担はこうでした。
方向性は人が握り、実装と検証はAIが受け持つ。この分担が成り立つからこそ、専用の開発チームを組まずとも、PoCを前に進められたのです。
STEP 4：バラバラのデータを、ひとつの型に揃える
過程の中で最も頭を使ったのが、この工程です。
各ATSから取り出した求人情報は、項目名も粒度もバラバラ。これを求人管理システム側の決まった型（約30項目）にきれいに揃える必要があります。
ここで、処理を2種類に切り分けました。
- ルールで処理できるもの：「給与」「想定年収」「賃金」のように、表記ゆれはあっても規則的に対応づけられるものは、決まった変換ルールで処理する。
- AIに任せるもの：文章の中に埋もれた情報など、規則では拾いきれないものは、AIに「この文章から年収・勤務地・雇用形態を読み取って」と頼む。
ポイントは、全部をAIにやらせなかったことです。規則的なものは規則で、曖昧なものだけAIに。この切り分けが、精度と運用コストの両立につながりました。「AIを使う」とは「何でもAIに丸投げする」ことではない——これはPoCを通じて得た実感です。
そして、この”AIに任せた部分”こそが、今回のPoCの核心でした。
これまで、ATSごとの表記の揺れ——「給与」なのか「想定年収」なのか、必要な情報が求人票本文のどこに書かれているのか——を吸収していたのは、担当者の”頭の中”でした。人間が毎回、文脈から意味を読み取り、判断していた。手作業がつらかった本当の理由は、作業が単純だからではなく、1件ごとに人間の推論を必要としたからです。
この「推論」や「揺れの吸収」は、長らく人にしかできない仕事だと思われてきました。ルールでは書ききれないからです。そこを——推論を得意とするAIが、肩代わりできるようになった。 これこそが、今回の自動化を成立させた、決定的な変化でした。ルールで書ける部分は、もともと自動化できた。書けなかった「人間の判断」の部分に、AIがようやく手を届かせた。そこが本質です。
なお、この工程でデータを”型に揃えた”ことは、のちに大きな意味を持ってきます。その理由は、記事の後半で明らかになります。
STEP 5：【方針転換】”全自動”から、”現実解”へ
そして、この記事でいちばん正直にお伝えしたいのが、この話です。
当初の構想は「全自動」でした。 情報を取り出し、型に揃え、そのまま自動で求人管理システムに登録まで——人が一切触らない仕組み。これが理想であることは、今も変わりません。
でも、作っていく中で、いったん考えを変えました。
求人管理システムには、クライアントの顧客や個人にまつわる重要なデータが入っています。そこにツールが自動で書き込むとなると、考えるべきことが一気に増えます。データの取り違え、誤った上書き、そして——人材領域では避けて通れない——個人情報の扱い。これらを安全にクリアしたうえで「全自動」を成立させるのは、PoCという小さな枠組みで扱える範囲を、明らかに超えていました。
そこで、PoCのゴールを、現実的な形に切り替えました。
- ツールがやるのは、「下ごしらえ」まで。情報を集め、型に揃え、確認用のファイルとして出力する。
- 既存のデータと突き合わせて、「新規」「更新」「終了」を自動で判定し、わかりやすく提示する。
- そして、最終的な登録は、担当者が中身を確認してから行う。
ここで、はっきりさせておきたいことがあります。これは「人の確認を残すのがベストだ」という話ではありません。 本来は、全自動のほうが優れています。私たちが人の確認を残したのは、設計思想が立派だからではなく、PoCというプロジェクトの規模・予算で対応できたのが、ここまでだったからです。
なぜ「全自動」のハードルが高かったのか——その正体は、実は技術の問題ではありませんでした。これは大事な話なので、章を改めて正直に書きます（後述の「正直に言うと、これは”ベスト”ではない」をご覧ください）。
ひとつ確かなのは、この方針転換が、作りながらできたということです。AIと対話しながら作っていたからこそ、「ここは一度、現実的な形に引こう」とその場で舵を切れました。PoCの強みは、まさにこの身軽さにあります。
STEP 6：担当者が確認して、反映する
最後の工程はシンプルです。ツールが出力したファイルを担当者が開き、内容をざっと確認し、問題なければ求人管理システムに取り込む。
以前は「ゼロから全部を手入力」していた作業が、「できあがったものを確認するだけ」に変わりました。
何が変わったか
| 項目 | Before（手作業） | After（PoCで作ったツール） |
|---|---|---|
| 情報の収集 | 担当者が各ATSを巡回 | 通知をきっかけに自動で収集 |
| フォーマットの統一 | 頭の中で読み替えてコピペ | 自動で正規化 |
| 表記の揺れ・文章に埋もれた情報 | 担当者が頭の中で読み替え | 推論の得意なAIが肩代わり |
| 新規・更新・終了の判定 | 目視で照合 | 既存データと自動で突合 |
| 1件あたりの所要時間 | 数分〜 | まとめて数十秒 |
| 転記ミス | 起こりうる | 仕組みで排除 |
| 最終登録 | すべて手入力 | 担当者が確認して反映（現時点では人が担当） |
担当者の作業は、「収集・読み替え・入力」という大部分が消え、「確認」だけが残りました。PoCとしては、十分に手応えのある結果です。
正直に言うと、これは”ベスト”ではない
ここまで読んで、「うまくいった事例」として受け取られた方もいるかもしれません。実際、担当者の負担は大きく減りました。それは確かな成果です。
ただ、フェアにお伝えしておきたいことがあります。今回の形は、ベストな答えではありません。 そもそもPoC（実証実験）は、「できるかどうかを確かめる」もの。完成品ではありません。「今回の枠組みでできたのが、ここまでだった」というのが、正確なところです。
理想は、やはり全自動です。人の手を介さず、収集から登録までが流れるように完結する——そこに異論はありません。では、なぜそこに届かなかったのか。技術的な限界だったのでしょうか。
いいえ。難しさの正体は、技術ではなく、その外側にありました。
1. 個人情報保護のセキュリティレベルを、どこに置くか
人材紹介会社が日々扱うのは、求職者の経歴・連絡先・年収・転職理由といった、きわめてセンシティブな個人情報です。求人情報を集約する仕組みも、最終的にはそうした個人情報と同じ基盤の上でつながっていきます。これを自動で動かすなら、「セキュリティのレベルをどこまで上げるか」が、まず最大の論点になります。そして、これに「唯一の正解」はありません。
2. セキュリティと「業務が回ること」のトレードオフ
セキュリティを突き詰めるほど、システムは安全になります。しかしその一方で、手続きや制約が増え、現場の業務が回らなくなっていきます。逆に緩めれば業務はスムーズですが、リスクは上がる。「安全であること」と「業務が成立すること」は、しばしば綱引きの関係にあり、その最適点を見極めるのは簡単ではありません。
3. 連携先となる各ツールの利用規約
データを取得・連携する各システムには、それぞれ利用規約があります。自動での取得や連携が、規約上どこまで認められるのか。これを正しく踏まえたうえで仕組みを組み上げる必要があり、技術だけで突破できる問題ではありません。
そして、ここがいちばんお伝えしたいことです。これらの難しさは、「AIの限界」でも「システムの限界」でもありません。
セキュリティの基準も、個人情報の扱い方も、各ツールの規約も——その時々の社会や経済といった、外部のコンテキストによって形づくられています。何が「適切」かは、技術ではなく社会が決める。だからこそ答えが一つに定まらず、難しいのです。
これらをきちんと設計しきり、本番運用に耐える「全自動」を実現するには、本来、セキュリティや法務といった専門家の知見と、相応の予算・体制が欠かせません。それらが揃えば、全自動も十分に実現できるはずです。今回のPoCでたどり着いた形は、その手前にある「現実解」——実証実験という枠組みに見合った、等身大の到達点です。
でも、それでいいのです。PoCの役割は、完成品を出すことではありません。「どこまでが現実的にでき、どこからは本格的な投資と専門家が必要なのか」、その線引きを、実物で確かめること。 今回、私たちはそれをはっきりと見届けました。
このPoCが教えてくれたこと
今回の過程を振り返って、改めて感じたことが3つあります。
1. 「理想」は下げず、「現実解」から始める
全自動という理想は、下げる必要はありません。むしろ、下げるべきではないと考えています。一方で、「理想が完璧に整うまで何も動かさない」のでは、いつまでも前に進めません。
だからこそ、理想（全自動）を見据えたまま、まずPoCで現実解を形にする。PoCはゴールではなく出発点です。そこで得た手応えと課題をもとに、専門家の力も借りながら、少しずつ理想に近づけていけばいい。「理想」と「今できること」を、両方とも手放さないことが大切だと考えています。
2. AI時代のボトルネックは、コードではなく「業務理解」
今回のPoCで必要だったのは、高度なプログラミング技術ではなく、業務をどれだけ深く理解できるかでした。
「このATSのこの情報は、求人管理システムのこの項目に対応する」「この表記ゆれは同じ意味」——こうした判断は、業務の解像度がなければできません。AIはコードを書けますが、“何が正しいか”を教えるのは人間の仕事です。
だからこそ、私たちがまず時間をかけたのは、コードを書くことではなく、クライアントへのヒアリングでした。業務さえ正確に捉えられれば、あとはAIとの協業で形にできる。 これが、いまの開発の現実です。
3. 作りながら、設計は変えていい
従来の外注開発では、仕様は最初に固めるのが基本です。でも、AIと作るPoCは違います。
実際、今回も「全自動」から「人の確認を残す」へと、作っている途中で方針が変わりました。それでも大きな手戻りはありませんでした。作りながら考え、考えながら直せる——これが、AI協業でPoCを進める大きな強みです。
このPoCの、その先 ― データの”つなぎ込み先”
ここまで、「手作業の転記を自動化したPoC」としてお読みいただきました。でも、実はこの自動化ツールは、それ単体がゴールではありませんでした。
私たちは、並行して、もうひとつの仕組みも構想していました。求職者と求人を、AIが照らし合わせるマッチングの仕組みです。
（このマッチングのPoCについては、続編の記事で詳しくご紹介しています。）
人材紹介の核心は、「この求職者には、どの求人が合うか」を見極めることにあります。求職者のスキルや志向と、求人側の条件——これまでコンサルタントが経験と勘で結びつけていた部分を、AIが読み解き、「この人には、この求人が合いそうだ」と適合度を点数化して補助する。そういう仕組みです。
（この”照らし合わせる”発想は、人材紹介に限りません。「顧客」と「商品」、「物件」と「希望条件」——何かと何かをマッチングする業務なら、同じ考え方が応用できます。）
そして——ここが大事なのですが——この2つの仕組みは、つながる前提で構想していました。
- 1つ目（今回のPoCで作った自動化ツール）が、バラバラの求人情報を集め、きれいな型に揃える
- 2つ目（マッチングの仕組み）が、その整ったデータを使って、最適な組み合わせを導き出す
STEP 4で「データを型に揃える」ことに、しつこいほどこだわった理由が、これです。AIマッチングの精度は、入力データの”整い方”でほぼ決まります。 フォーマットがバラバラのままでは、AIも正しく比較できません。逆に、データさえきれいに揃っていれば、その先で何倍もの価値を生み出せる。今回のPoCは、マッチングという”本丸”を支える土台でもあったのです。
ここから見えてくるのは、AI活用は「点」ではなく「線」で考えると効く、ということです。
「この作業を自動化したい」という”点”だけを見ると、ツールは単発で終わります。でも、「この業務の流れ全体は、どうあるべきか」という”線”で見ると——データを集める仕組みと、それを活かす仕組みがつながり、効果は何倍にもなります。
PoCを1つやるたびに、「次は、何とつながるか」を考える。この視点を持てるかどうかが、AI活用の成否を分けると、私たちは考えています。
こんな業務、ありませんか？
最後に、今回のような自動化PoCが向いている業務の特徴を挙げておきます。ひとつでも当てはまるなら、一度試してみる価値があります。
- 複数のシステムやファイルに、情報が散らばっている
- そのフォーマットや項目名が、出どころによってバラバラ
- 担当者が、毎回手作業でコピペ・転記している
- 件数が多く、ミスも起きるが、本格的に外注するほどの規模ではない
- 作業自体は単純で、「考えること」がほとんどない
こうした業務は、どの会社にも必ずあります。そして多くの場合、「面倒だけど仕方ない」と放置されています。「本格開発はオーバースペック、でも手作業はつらい」——その板挟みのまま、止まってしまうのです。
でも今は、AIとの協業を前提にすれば、「PoCで小さく試す」という現実的な一歩が踏み出せます。いきなり完璧なシステムを目指さなくていい。まず動くものを作り、何ができて何が課題かを、実物で確かめる。そこから始められる時代です。
まとめ
複数のシステムに散らばる求人情報の集約という、地味で重い定型業務。それをAIとの協業で自動化する——その実証実験（PoC）の過程を、ご紹介しました。
ポイントを振り返ります。
- 業務を言葉にすることから始める。コードより先に、業務の棚卸し（ヒアリング）を。
- ルールで書ける処理はルールで、”人間の推論”が要る処理こそAIで。丸投げではなく、使い分ける。
- 理想（全自動）は下げず、現実解から始める。PoCはゴールではなく出発点。
- 作りながら方針を変えていい。AI協業のPoCなら、大きな手戻りなく軌道修正できる。
- ツールは「線」でつなぐ。1つの自動化で終わらせず、業務の流れ全体を設計する。
そして、忘れてはいけないことがもうひとつ。今回のPoCでたどり着いたのは「現実解」であって、「全自動」という理想そのものではありません。その先へ進むには、セキュリティ、個人情報の扱い、各ツールの規約——技術の外側にある論点を、専門家とともに丁寧に詰めていく必要があります。そしてそれらは、社会や経済の動きとともに変わり続けます。自動化は「作って終わり」ではなく、「社会の文脈に合わせて育て続けるもの」だと、私たちは考えています。
それでも、最初の一歩は、驚くほど軽くなりました。「面倒だけど仕方ない」と諦めていた業務があるなら、まずはPoCとして小さく試してみる。それが、いちばん確実な始め方だと思います。
当社では、こうした業務自動化やAI活用のPoC・ご相談を承っています。「うちのあの業務、AIでどうにかならないかな」と思い当たることがあれば、お気軽にお声がけください。
シリーズ記事
この記事には「後編」があります。集めて整えたデータを「マッチング」に活かす、もうひとつのPoCの話です。
