【イベントレポート】グッドパッチが1年で試した50のAI施策

採用業務にAIを取り入れたい。そう考えて手を動かし始めたものの、作った仕組みが使われずに定着しない。こうした悩みは、多くの採用チームに共通するものではないでしょうか。

物量として施策を打つことと、それが組織に根づくことは別の話です。定着する仕組みとしない仕組みは、何が違うのでしょうか。

2026年6月24日、株式会社グッドパッチでPeople Empowerment Officeのリクルーターを務める宍戸知勢氏が登壇し、ウェビナーを開催しました。テーマは「1年間で50のAI施策。AIとともに人が主役の採用プロセスをつくる」です。モデレーターは、株式会社overflow代表取締役CEOの鈴木裕斗が務めました。

宍戸氏が1年間で試した施策の全体像、定着する仕組みを見極める4つの設計原則、ナレッジ自動蓄積やスカウト支援の事例、そして組織にAIが広がったきっかけを、当日の内容に沿ってまとめます。

「負を解消する」から始まった、1年で50以上のAI施策

宍戸氏は、自分がユーザーとして感じた不便を仕組みで解消することをテーマに、グッドパッチの採用業務で1年間に50以上のAI施策を試しました。施策のカテゴリーは、母集団形成、オペレーション、面談・面接、ナレッジ蓄積、レポーティング、その他です。

「負を解消する」というテーマ

宍戸氏の個人的なテーマは「負を解消する」ことで、今のAI時代はそのハードルを越えやすくなっていると言います。

グッドパッチでリクルーターを務めており、今はイネイブルメント担当として仕組みづくりやAI活用の推進もしています。前身は人材業界の営業やデザイナー、エンジニアチームでのテストなどでした。

個人的なテーマは「負を解消する」ことです。自分がユーザーとして感じた嫌なことや、もっとこうだったら生産性が上がるのに、ということを仕組みにする。これを人生の大きな意思決定にも用いてきました。

今のAI時代は、その負を解消するハードルが飛び越えやすくなっているので楽しいなと思っています。

これまでの施策をカテゴリーに分けると、母集団形成、オペレーション、面談・面接、ナレッジ蓄積、レポーティング、その他で、50以上をやってきました。

1つ1つを覚える必要はありません。目に入るものを全てAIで効率的にできないかと、とにかく手を動かしてアタックした。その結果として残ったものがある、ということです。

グッドパッチ採用チームの体制と特徴

グッドパッチの採用チームは、リクルーター4人、コーディネーター（オペレーション）2人、スカウト支援のメンバーで、多くの職種の採用を担う体制です。

前提として、グッドパッチの採用チームの体制もお伝えします。リクルーターが4人、コーディネーター（オペレーション）が2人、スカウト支援のメンバーも参画しています。

特徴は、まず職種が非常に多いことです。デザイナーだけと思われがちですが、セールスやマーケ、コーポレートも多く募集しており、いろんなポジションを把握しながら進めるバランス感覚が求められます。

リクルーターが関わる工程も、母集団形成から入社後まで広い。1人1人の体験を大切にしているので、雑にテンプレートで済ませることはしません。結論、すごく忙しく、すごく頭を使うチームです。

1年間の推進で得たもの

宍戸氏が1年間のAI活用の推進で得たものとして挙げたのは、外注コストの削減、SaaSの解約によるツールコストの圧縮、リクルーター業務を個人のWillや組織の重要業務へ振り分ける余裕、暗黙知の形式知化と標準化です。

AI活用の軌跡は、1年ちょっと前に私が個人で使い始めたところからスタートし、その後チームで、どの業務の手間を減らせるかを議論しました。

このとき、メンバーそれぞれの活用度合いやAIへの考え方を揃えるのはとても大変だったのですが、そこで生まれた仕組みを1つ軌道に載せ、SaaSの内製化によるコスト削減、人事チーム全体でのデプロイ、と広がっていきました。

1人休むと誰も把握していない状況から、他の人もサポートできる体制になった。周りも本人も安心できるこの標準化が、私は1番の結果だと思っています。

定着する仕組みとしない仕組みを分けた、4つの設計原則

宍戸氏によれば、定着した仕組みとしなかった仕組みの分かれ目は設計の思想にあり、行き着いたのが「全部を1人で抱えない」「使い手に新しい負担を増やさない」「業務全体をAI前提に再設計する」「AIに任せるものと人が担うものを分ける」の4原則です。

一直線に成功したわけではありません。50個の施策の中には定着しなかったものも結構あります。GitHubでナレッジを共有する、各々がスキルやジェムで自分の業務を楽にする、仕組みのために新しいツールを作る。こうしたものは全然定着しませんでした。

逆に、Chrome拡張や、面接・面談で話しているだけで自動でサマリができるものは、うまくいった印象があります。その分かれ目は、設計の思想にあったと考えています。行き着いた設計原則は4つです。

原則1「全部を1人で抱えない」

1つ目の原則として、宍戸氏は、仕組みを作る人と使う人を分け、基盤やバックエンド、セキュリティはエンジニアに、フロントエンドは業務ロジックが分かっている事業部の人に任せることを挙げました。

1つ目は、全部を1人で抱えないことです。仕組みを作る人と使う人を分ける。何かを作る場合も、基盤やバックエンド、セキュリティはエンジニアに任せ、業務ロジックが分かっている事業部の人がフロントエンドを作る。

この分業ですごく早く済みます。作る人が多すぎると、同じようなジェムがいっぱいできて業務が保たれなくなるからです。

原則2「使い手に新しい負担を増やさない」

2つ目の原則は、Slackからの呼び出しやChrome拡張のように使い手が見慣れたUI（ユーザーインターフェース）で使える形にし、普段の仕事がそのままAI活用の素材になるように作ることでした。

2つ目は、使い手に新しい負担を増やさない仕組みを作ることです。見慣れたUIを使ってもらう。AIを使うにしてもSlackから呼び出す、Chrome拡張として横に機能を出す、といった工夫です。

「AI活用のためにこれをやってください」と手間を増やすのは、大体うまくいきませんでした。普段の仕事をしているだけで、それが勝手にAI活用のための素材になっていく。使い手の負担が増えないことが大事です。

原則3「業務全体をAI前提に再設計する」

原則3では、AIが処理できる形に業務のルールを作り直します。

3つ目は、業務全体をAI前提に再設計することです。使い手の負担は増やさないものの、AIがちゃんと処理できるように前情報を整える業務設計をします。

特定の仕組みを通ってもらわないと回らない場合は相談をして、会議の名称にこういう文言を入れておく、インタビューではこのポイントを押さえて聞く、といったルールを設けました。

原則4「AIに任せるものと人が担うものを分ける」

原則4は、業務ごとにAIに任せるか人が担うかを一度俯瞰して整理することです。

4つ目は、原則というより気づきに近いのですが、業務の特性によってAIに任せるものと人が担うものが分かれます。これに応じて、人がやる・ヒューマンインザループにする、という工夫を1回俯瞰してみた方がよいと考えています。

AI活用はコンテキスト情報が肝なので、情報の蓄積は基本的にAIでできるようにする。その上で、どこをAIに置き換え、どこを人が注力するかを整理して、取り組みの順番を決めるとよいと思います。

AIを導入しても定着しない理由と、担い手の決め方を一般論として整理した記事はAI導入の進め方｜定着しない理由と担い手の決め方です。採用担当者向けの実務資料は、Offers（株式会社overflow）のお役立ち資料にまとめています。

日常の会話・面談から組織ナレッジを自動で蓄積する事例

うまくいっている事例の1つ目は、面談・面接やハイヤリングマネージャーとのミーティング、Slackのやり取りから、議事録・意思決定軸・マニュアルの追記といった組織ナレッジを自動で生成する仕組みです。

うまくいっている事例を紹介します。1つ目は、日常の会話や対話から組織ナレッジを生成する仕組みで、主に3つのことをやっています。

面談・面接では、ただ参加して議事録を入れるだけで、議事録に加えて「何を質問されたか」「参加者の発話のバランス」といった改善のための情報を自動で揃えられるようにしました。

現場のハイヤリングマネージャーとのミーティングでは、リクルーターが話しているだけで意思決定軸が蓄積されます。こういう人はダメ、こういう人はオッケー、といった判断です。

1つの意思決定に対して1つのログが残る。このログはいずれJDに反映し、フィードバックのループを回せる仕組みにしたいと考えています。

マニュアルの更新も、業務のやり取りをSlackに残し、そのログを元に週1回、運用の変化をClaudeに見てもらい、追記しています。

蓄積したログを「分析の素材」として使う

蓄積したログは、選考基準の変化の確認、候補者からの質問の傾向の把握、面接官ごとの面接の傾向の分析に使える素材で、分析の軸は人間が決めるべきだと宍戸氏は話しました。

蓄積したログは、さまざまな分析の素材になります。社内ミーティングのログをスプレッドシートに取っておけば、最近のUI・UX（ユーザー体験）の選考基準はどう変わったか、と聞けば調べて出してくれます。

面談・面接であれば、質問と回答が全部ログに溜まっている。この1ヶ月でAIについて何を質問されているかを見て、事前に回答を用意する。求職者からの質問を採用マーケティングのブログのネタにする、といった使い方もできます。

面接ごとに、転職理由や懸念が聞けているか、いくつかの軸で自動的にログを取る仕組みです。「Aマネージャーの面接の傾向を分析してください」と依頼すると、スコアやログを見ながら改善案を出してくれます。

これを本人にフィードバックし、面談・面接を改善する素材にしていますが、どういう軸で取るかは、人間が決めるべきだと考えています。

AIに決めさせるのではなく、今の採用課題は何で、どの部分を分析したいから、この軸で設計してほしい、というところを人間がやっていく。それがよいと思います。

あらゆるデータを接続して素材を生成する

宍戸氏は、蓄積したログや社内のデータベース、SlackやドライブのMCP（Model Context Protocol）をつないで資料を作らせることも多く、自分のポジションの引き継ぎ資料はレビューを含めて1時間かからずに作れたと話しました。

蓄積されたログや社内で使っているデータベース、SlackやドライブのMCPを繋いだものを統合し、特定のポジションや情報を作りたい時に全部接続して依頼するのもよくやっています。

直近では引き継ぎ資料を作りました。イネイブルメントに集中するため自分のポジションを10個ほど引き継いだのですが、引き継ぎ資料が全くなかったのです。

そこで、あらゆるデータベースに接続して作ってもらいました。レビューを含めても1時間かからず、暗黙知になっていたものを引き出せた、すごく助かった事例でした。

Chrome拡張とSaaSで採用業務の工数を圧縮する事例

2つ目の事例は、採用活動で最も工数がかかっていたメール作成と、求人情報の各媒体への転記を、自作のChrome拡張で圧縮した取り組みです。

宍戸氏は登壇の冒頭で、紹介する施策はあくまでグッドパッチで進めてきたもので、会社ごとに最適な形や守るべきルールがあるため、取り入れる際は社内の専門部門と協議してほしいと述べました。現時点のルールの中で進めているため今後変わる可能性があること、個人情報や機密情報、各媒体社や提供会社の規約を守って進めていることもあわせて伝えています。

採用活動で1番工数がかかるのはメール作成です。選考プロセスを人によってアレンジしたり、途中でコミュニケーションを挟んだりするため、メール作成には多くの時間をかけていました。

そこで、メール作成を支援するChrome拡張を作りました。「面接の案内をしてほしい、体調を崩していたのでタイトルはこうしてほしい」といった依頼をします。

すると、気遣いの一言を入れ、弊社のご案内フォーマットに則った文面を作ってくれます。裏側はスプレッドシートで、テンプレートのパーツをAIがつなげる仕組みです。

スプレッドシートにしたのは、ソースコードに埋め込むと私しか保持できなくなるからです。あえて元データをスプレッドシートに置いています。

もう1つ、コーディネーターが大変だったのが、求人情報の各媒体への転記です。採用管理システムで作った求人を各媒体に転記する際、媒体ごとに項目がバラバラでした。

そこで、求人ページを開けば自動でページのHTML（ウェブページの記述言語）を読み、Greenやビズリーチなど各媒体向けの文章と社内告知文を一緒に作れるようにしました。項目単位でコピーできるボタンをつけたのがこだわりです。

SaaSは「総合的なメリット」で使い分ける

自前で作るより使った方がよいものとして、宍戸氏はインフラの維持、セキュリティ、保守、個人情報の取り扱いの面で総合的なメリットがあるものにSaaSを使っています。

自前で作るより使った方がよいものはSaaSを利用します。インフラの維持、セキュリティ、保守、個人情報の取り扱いといった面で総合的なメリットがあるものです。

弊社では自社開発のスカウト支援ツールを使っています。媒体のプロフィール画面で判定を押すと、登録情報からマッチ度を判定し、プロフィールと求人情報を見てスカウト文章も作ってくれます。

以前はリクルーターが1人1日1〜2時間かけて全部スカウトを送っていましたが、ポジションが増えると難しくなりました。

今はこの仕組みでスカウト支援チームを立ち上げ、ピックアップとベースの情報作成まで任せ、人は確認して送るだけにしています。量も増やせた、この半年間で1番頑張った施策です。

エンジニアと組んで社内プロダクトを作る

宍戸氏はエンジニアと組み、スカウト送信の管理アプリと、構築中のタレントプールという2つの社内プロダクトを作っています。エンジニアがセキュリティやインフラを見て、宍戸氏がUIを作る分業です。

さらに、エンジニアと一緒に社内プロダクトも作っています。1つはスカウト送信の管理アプリで、媒体を開いて拡張機能を押すと、どのポジションにスカウトを送ったかが管理できます。

もう1つは構築中のタレントプールです。市販のCRM（顧客管理システム）は採用に特化していなかったり高値だったりするので、使いたい入り口や管理したい情報にこだわって自分たちで作っています。

施策別の効果も見られるよう、キャンペーン管理に近い概念で実装中です。エンジニアがセキュリティやインフラを見て、私はUIを作る、という分業体制でやっています。

AIを作る3つの理由と「人が主役」の採用プロセス

宍戸氏がAIを作る理由は効率化だけではなく、属人性をなくして組織をスケールさせること、業務体験をよくして採用ブランドにつなげること、人が人と話す時間を確保することの3つです。

最後に、なぜAIを作るのかという思いをお伝えします。AIを使うのは、効率化のためだけではありません。理由は3つあります。

1つ目は、属人性を持つと組織自体がスケールせず、健全ではない状態になりかねないからです。会社や体制が永続的に続くためにも、属人性を排除し、誰でも使えるものにしていきたいと考えています。

2つ目は、業務体験をよくすることが採用ブランドにつながるからです。手間がかかって大変だ、忙しい、という状態は候補者にも伝わってしまいます。

採用担当やハイヤリングマネージャーが滑らかに仕事をすることで、その体験の良さが候補者に伝わり、採用も成功していくと考えています。

3つ目は、人が人と話す時間を確保するためです。人がやる仕事は、人と人との熱量の交換、感情への寄り添い、旗を立てて何をするか決めること。その時間を増やすためにも、AIで効率化していきたいのです。

私が思い描く究極系は、リクルーターやハイヤリングマネージャーが社内外の人と話しているだけで採用が完了する状態です。

意思決定者と話して「こんな人が欲しい」と言うだけで求人票ができて社内に告知され、判断基準も蓄積されていく。候補者のサジェストが上がってきて、オッケーならコミュニケーションが始まる。

新しい仲間が増えた時も、そのバックグラウンドを生かして翌日から採用活動を前進できれば、オンボーディングもうまくいき早くパフォーマンスを上げられます。

話しているだけで採用が完結する世界を作りたい。まだ全然できていませんが、人が主役でAIができることはAIに任せ、人は人に向ける仕事をする。そんな採用チームを作っていきたいと思っています。

チーム全体にAIが波及したトリガー（ディスカッション）

宍戸氏が挙げたAI波及のきっかけは、代表や役員が使い始めたこと、業務に入れた仕組みでメリットを感じてもらえたこと、それを見た人が自分で手を動かし始めたことの「2.5個」でした。

――鈴木：おひとりで使うところから始めて、チーム、そして組織へと進んでいかれました。波及したなと感じたタイミングや、1番のトリガーは何だったと感じますか？

宍戸：2つ、いや2.5個ある感じです。1つ目は、代表や役員が使い始めて「これめっちゃ楽しい、使ってみなよ」と言い始めた瞬間に、めちゃくちゃ広がりました。トップが使うと定着があるんだなと。

2つ目は、実際に業務に仕組みを1つ入れてみて、その人たちの業務でメリットがあったと思ってもらえた時です。面接・面談のスコアに「その方が面接中に何を求めているか」の情報も加えたら、現場と交渉して一緒に働く仲間が能動的にレビューを始めてくれました。

3つ目、0.5は、それを見て自分で手を動かし「面白い」となった瞬間です。今年、育休明けで復帰したメンバーがAIと一緒にGAS（Google Apps Script）を組んで自分の業務を自動化したら、人1人分の数年が出るのではというくらい効率化できました。

――鈴木：最初の0→1を始める動機は、どういうものなのでしょうか？

宍戸：元々「負を解消する」がテーマなので、面倒くさいなということをずっと集めているんです。暇なタイミングで「これ解決できませんか」とAIに聞いて、作ってみたらうまくいく。

当たり前として受け取らず、改善できるんじゃないかという違和感に気づく視点を持ってみるのがよいと思います。

――鈴木：浸透してきた中で、会社全体や個人の働き方にはどんな変化がありましたか？

宍戸：リクルーターとイネイブルメント担当を分けたこと、新しく入ったメンバーがAIをお供に2日目から戦力になったことは、事実として起こりました。

あと所感ですが、「工数がないから諦めましょう」という話をあまり聞かなくなった気がします。まずAIに聞いてやり方があればやる、という思考に変わってきました。

採用組織での取り組みを全社のAI変革プロジェクトへ広げ、現場が自律的に改善を進める状態を築いた別の企業の取り組みは、kubellのイベントレポートで紹介しています。

参加者Q&Aで深掘りする実践のポイント

参加者の質問に対し、宍戸氏は、最初に取り組むなら会話の録画とトランスクリプトの蓄積、ナレッジの品質は今も課題で出力は判断を補助するものと位置づけて出典を明示させる、ツールは保守性で選ぶ、といった実践の考え方を答えました。

質問：50以上の施策の中で、最初に取り組むならどの業務がおすすめでしょうか。採用担当が2名程度の少人数です。効果が出やすい領域や、後回しにした方が良い領域があれば教えてください。

宍戸：最初に取り組むなら、会話を全部録画してトランスクリプトを蓄積しておくことです。コンテキストや判断基準を人間の頭からいかに取り出すかが大事で、それが取り交わされているのは会話やSlackです。

会話は取り逃すと人の頭にしか残らず断片的になるので、まず録画を取ります。次に地道ですが、職種別のデータベースを社内で作ります。

誰がハイヤリングマネージャーで、どういう選考基準か、といった情報を構造化データにしておく。そこにコンテキスト情報を紐付けて、判断基準の抽出や求人票のブラッシュアップ、スカウト文章の作成につなげます。

次に来るのが、人間しか持っていない判断基準の言語化です。選考基準やスカウト送信の基準は、人間が作らないとAIも動けないので、そこを言語化していきます。

質問：FAQや面談ログなどのナレッジが自動で蓄積される仕組みで、情報の品質はどう担保していますか。古い情報や誤った情報が残るリスクや、更新・削除の運用についても伺いたいです。

宍戸：正直に言うと、溜まっているデータの精査はできていません。本来はAIの出力と人間の確認の差分をフィードバックしてチューニングすべきですが、そこまで手が回っていないのが現状です。

今は、そういう情報だという前提で、あくまで判断をサポートするツールという位置づけです。出力を確実な正解だと思わず、「それはどこから引っ張ってきたのか」と出典を必ず明示させています。

不安があれば元データを見て、違えば消したり手で修正したりしています。とても鋭いご指摘で、課題感を感じている部分です。

質問：メール文面作成で画面左に出すAIアシスタントは、どうやって出しているのでしょうか。求人票の一部をコピーするボタンは、Claude Codeで作れましたか。

宍戸：特別なことはしていません。「こういう拡張機能が欲しい」とClaude Codeに自然言語で指示して作ってもらいました。

Chromeの「拡張機能を管理」で自分の拡張機能を読み込み、ボタンを押すと出てくる、単体で1つのアプリです。裏でGCP（Google Cloud）やGeminiのAPI（外部から機能を呼び出す窓口）を発行する手間はありますが、エラーもスクショを渡せばClaudeが解決してくれます。

まずは拡張機能を作りたいと依頼してみるとよいと思います。

質問：DXと同様、既存業務の整理や流れの再設計は重要でしょうか。クイックウィンの施策として社内説得につなげたいのですが、事前の業務整理が重要な気がしています。

宍戸：余裕があれば、業務の始まりから終わりまでを一度書き、データと意思決定のつながりや歩留まりを俯瞰して戦略を立てるのはやるとよいです。

採用のデータは元が一緒で、選考の中で形を変えて数珠つなぎになるので、繋がるように設計しておくとスムーズです。

ただ社内説得のためなら、まず手元のクイックウィンを目指した方がよいと思います。メール送信やスカウトの工数をこれだけ削減できた、だからリソースをください、と交渉する。

業務を俯瞰して設計すると他人ごとになりがちなので、まずみんなで手元でやってみて、筋のいいものだけ仕組みに残すのがよいと考えています。

質問：何でもコードで作るのではなく、GASやZapierを使い分けている印象です。どういう基準でしょうか。

宍戸：意識しているのは保守性です。仮に私がいなくなっても誰かが保守できるように、ノードを見れば解釈できるZapierを使う、データが溜まらないものはスプレッドシートに置く、といった具合です。

面談・面接のログも、Geminiの議事録だとマイドライブに入って他の人が取りに行けません。ZoomやMeetなど開催者もバラバラです。

そこで議事録ツールで入り口を1つにまとめ、どのプラットフォームでも誰でも見られる状態を作り、そこからWebhookを叩くようにしていました。それぞれに意図を持ってツールを選んでいます。

質問：AI活用をチームに広げる際、メンバー間のリテラシーの差を埋めるコツや、実施した施策はありますか。

宍戸：究極、使って覚えるのがAIだと思うので、まず触ってみる雰囲気を作ります。何か聞かれた時に「AIは何て言ってた？」と返して、本人がAIで調べ出すように促すのも、本人のためになると思います。

施策としては、去年の4月・5月にChatGPTのプロジェクト機能で「あなたのキャリアを整理します」というワークショップをやりました。まずAIの便利さに気づいてもらう狙いです。

その次に、CHRO（最高人事責任者）主導でAIで業務の困り事を解決するワークショップや黙々会をやりました。こうしたステップを組織として用意するとよいと思います。

質問：システム基盤の構築はエンジニアの方にやっていただいたとのことですが、どのように巻き込んでいったのでしょうか。

宍戸：仲良くしているエンジニアに「こういう構想があるんだけど、どう？」とDM（ダイレクトメッセージ）を送り、「面白そう」と返ってきたので一緒にやってもらっています。

社内で普段からいろんな人と仲良くしておくこと、そして「拡張していい」というValueを持つ弊社のカルチャーに救われている部分だと思います。

おわりに

宍戸氏が1年間で試した50以上の施策には、定着したものもしなかったものもあり、その分岐にあったのは物量ではなく、「全部を1人で抱えない」「使い手に新しい負担を増やさない」「業務全体をAI前提に再設計する」「AIに任せるものと人が担うものを分ける」という4つの設計原則でした。

根底にあるのは「人が主役」という思想です。AIで手間を減らすのは、属人性をなくし、業務体験を通じて採用ブランドを高め、人が人と話す時間を増やすため。手を動かした先に残ったのは、ツールの数ではなく、人が本来やるべき仕事に集中できる採用チームの姿でした。

まずは、日々の会話を録画してコンテキストを蓄積すること、そして「これは面倒くさい」という違和感をメモしてAIに聞いてみること。明日からの一歩として、そこから始めていただければ幸いです。

Offers（株式会社overflow）が開催する採用担当者向けのウェビナーは、イベント一覧で案内しています。