この記事は、「Dify Advent Calendar 2025」の19日目の記事になります。
業務効率化をした事例がテーマということで、本記事では、実際に社内の業務で活用している 「採用フローの効率化事例」 をご紹介します。
【この記事のサマリ】
課題：応募数増で選考工数が限界（15分×応募者数）
解決：Dify Workflowを“ロジックエンジン”化し、Notion/Slack上の業務導線は変えない
ガバナンス：AIは合否を決めず、「問題なし／要確認／不備あり」のチェック結果と要約を作る（人が最終判断）
成果：書類選考＋Webテスト選考の工数50%削減、月11時間削減（応募者は月50名程度）
セキュリティ：人事専用セルフホスト、権限/アクセス制限、鍵管理
採用業務にAIを導入すると聞いて、「AIが勝手に合否を決めるなんて、、、」という気持ちになりませんか？
- AIのチェック結果にバイアスはかからないか？
- 公正な採用基準は担保できるのか？
- 人の仕事が奪われてしまうのではないか？
私たちも当初は同じ懸念を抱いていました。しかし、発想を転換しました。
「AIに合否を決めさせない。人間がしっかり見る必要がある、およそ2割をピックアップさせる」
生成AIにアシスタント役になってもらうことにしました。その結果、社内の抵抗感なく導入でき、選考の工数を50%削減することに成功しました。
この記事では、Dify (Workflow) × Notion × Slack × AWS を組み合わせた、実用的でセキュアな選考フローの構築支援事例を、アーキテクチャやプロンプト設定とともに公開します。
出発点は「足切りしたくない。でも時間は有限」というジレンマ
私たちのスタンスは、巷で言われる「AIによる自動選別（足切り）」とは少し違います。
「基本は機械的に落としたくない（足切りしない）」
「ただ、その判断のために全員分の応募書類を確認するのはもう限界…15分×応募者数分の時間の捻出が難しい」
「明らかな不備や懸念があるケースは、しっかり内容を確認して通過有無を判断したい」
出発点は、このような極めて“実務的”な課題感でした。
そこで、以下の技術スタックを組み合わせ、新しい選考フローを構築しました。
- Notion（万能ドキュメントツール）：応募者データベース
- Slack（ビジネスチャットツール）：通知・コミュニケーション
- Dify Workflow（AIアプリ開発プラットフォーム）：ロジックエンジン（選考の一次チェック）
- AWS Lambda（FaaS）：各ツールをつなぐ接着剤
Dify導入で選考フローはここまで変わる！Before/After
今回のAI選考の対象：書類選考（一次選考）＋Webテスト選考（二次選考）
今回の仕組みは、書類選考とWebテスト選考の2つで利用しています。
- 書類選考：応募書類（OpenES・学歴・自己PRなど）というフリーフォーマットの文章をAIが一次チェック
- Webテスト選考：テストの回答そのものではなく、採点済みの「解析結果レポート」だけをAIが一次チェック
書類はフォーマットがバラバラで揺れが大きい一方、Webテストの解析結果は決まった形式の数値データ・レポートです。この2種類の性質の異なるデータを、Dify Workflow上でほぼ同じフローに乗せているのがポイントです。
運用体制
書類選考およびWebテスト選考は、人事担当者1名 + 人事アシスタント数名という少人数体制で運用しています。
- 人事アシスタント：応募者情報をNotionに登録し、依頼画面から選考依頼を実施
- 人事担当者：依頼を受けて応募情報を確認し判断
担当者が1名しかいないからこそ、「全員分の書類を15分ずつ確認する」運用は限界でした。AIアシスタントの導入は、効率化ではなく業務を回すための必須要件だったのです。
採用チームの業務がどのように変わったのか、導入前後のフローをご覧ください。
【Before】全員分の応募書類を15分かけてチェック…終わらない確認作業
Dify導入前は、すべての確認と判断を人の目で行っていました。応募が増えれば増えるほど、担当者の負荷が雪だるま式に増えていく、典型的な人海戦術です。
【業務フロー】
- Notionへ応募者情報登録
- Notionの対象レコードから「依頼画面 ※１」を起動
- 依頼内容を記載しSlackへ通知
- 通知内容のURLなどをNotionに履歴として保存
- 依頼を受けた担当者が、応募者全員の書類を1人15分かけて確認し選考
※１．依頼画面とは？
採用チームでは応募者データをNotionで管理し、採用部門への依頼はSlackで行っています。この2つのツールを横断するやり取りは、ツール間の行き来や依頼履歴の管理が必要になります。作業自体は単純ですが、毎回手動で行うのは大変な作業でした。そこで、両ツールの連携をスムーズにするため、下記のような依頼画面を独自に作成しています。
【After】AIがアシスト！しっかり見るべきは「およそ2割」だけに
Difyを導入した後のフローです。AIが「記載不備」や「提出物欠落」、「テスト結果がボーダーライン以下」といった機械的なチェックを肩代わりしてくれます。人間はそのような 「通過判断に迷う候補者」という本当に見るべきおよそ2割の応募者にしっかり時間をかけるようになりました。
【業務フロー】
- Notionへ応募者情報登録
- Notionから「依頼画面」を起動
- 「AI一次チェック」ボタンを押すとDify Workflowが裏側で一次チェックを実行
- AIの一次チェック結果を添えて、Slackへ書類選考依頼を通知
- 通知内容のURLや一次チェック結果をNotionに履歴として保存
- AIのチェック結果が「要確認／不備あり」となった候補者は、担当者が応募書類を丁寧に確認。問題なしの場合はさらっと確認
チェックボタンは、依頼画面に追加する形とし、業務導線は変更しないようにしています。
【技術解説】Dify × AWS × Notion 実装の裏側
ここからは、エンジニア向けに具体的な実装内容を解説します。
ポイントは、「Difyをチャットボットとしてではなく、API経由のロジックエンジンとして使う」 点です。
アーキテクチャ概要
- フロントエンド（依頼画面）: Notion上のリンクから開くシンプルなHTML/JS画面（Amazon S3から静的配信）。Notionのインテグレーションを使い、GETパラメータにレコードのIDを追加。レコードIDを元に選考対象者情報を取得し、依頼画面が開きます。
- バックエンド: 依頼画面からAPI Gatewayを経由しAWS Lambdaがリクエストを受け取り。Notion APIで候補者情報や応募書類を取得します。取得した内容をDify Workflowで作成したAI一次チェックアプリへ送信。また、Slack通知やNotionへの履歴登録を実施します。
- AI処理: LambdaからDify API（Workflow実行）が呼び出されます。応募書類（PDF）のテキスト化（OCR）や一次チェックロジックはすべてDify側に隠蔽しています。
- 結果通知: Difyからのレスポンスを整形し、SlackとNotionへ書き込み。
なぜDifyを選んだのか
本プロジェクトには3つの方針がありました。
- 可能な限りエンジニアの手離れを良くする
- 現場の意見をスピーディーに反映させる
- LLMはその時の"美味しいとこ取り"をする
この3つを同時に満たせるのがDifyでした。
| 方針 | Difyでの実現 |
|---|---|
| 手離れを良く | ワークフローはノーコード。エンジニア不在でも運用可能 |
| 現場の意見を即反映 | プロンプト修正は管理画面から。デプロイ不要 |
| LLMは美味しいとこ取り | モデル変更はプルダウンで切り替えるだけ |
特に3点目は重要です。現在はOCR精度を理由にGemini 2.5 Flashを採用していますが、GPTやClaudeが上回る日が来れば、コード変更なしで即座に乗り換えられます。
LLMの進化が速い今、特定モデルに依存しない設計は必須だと考えています。
同様の仕組みは自前実装でも可能ですが、
- プロンプトの変更にエンジニア工数が必要
- モデル切替がコード改修になる
- 一次チェックロジックの属人化が進む
という理由から、運用フェーズでは破綻すると判断しました。
Dify Workflow の設計
Dify側では「チャットフロー」ではなく「ワークフロー」を使用しています。処理の流れはとってもシンプルです。外部からのインプット情報としては応募書類を渡しています。
「Webテスト選考」ワークフロー
Webテスト選考のワークフローは次の図のようにとってもシンプルです。
「AI一次チェック(LLM)」ブロックにすべてのプロンプトを入れることもできました。しかし、「チェック観点」と「当社募集要項」は「テンプレート」ブロックに記載しています。理由は、人事担当者自身で、AI一次チェックロジックを迷わず編集できるようにするためです。
Difyを使うことで、プロンプトの修正が、コードを変更せずに管理画面から即座に行えるのは大きなメリットです。加えて背景が黄色部分のようにメモを残して置けるので、引継ぎも楽に行えます。
【実装例】実際に「LLM」ブロックで使用しているプロンプト（システム指示）
DifyのLLMノードに設定しているプロンプトの骨子です。
「落とす」ためではなく、「注意すべき点を見つける」ことに特化させています。
あなたは経験豊富な新卒採用担当者です。応募者から送られてくる資料を基に一次チェック結果を出力してください。
資料をOCRし、下記観点に沿ってチェックしてください。
チェック観点：
{{テンプレートブロックのチェック観点}}
出力形式：
次の形式で出力してください。
1行目に一次チェック結果を出力
次に総合的なコメントを出力
最後に各部分で気になるポイントを出力
マークダウン装飾はしないこと
一次チェック結果は、必ず次のいずれか1つだけを出力する：
- 問題なし
- 要確認
- 不備あり
出力例：
一次チェック結果：${ここに一次チェック結果}
総合的なコメント：
${ここに総合的なコメント。適宜改行を入れて読みやすくすること。}
各部分で気になるポイント：
${ここに各部分で気になるポイント。適宜改行を入れて読みやすくすること。}
当社募集要項：
{{テンプレートブロックの募集要項}}
「書類選考」ワークフロー
書類選考もシンプルです。Webテスト選考のワークフローに、学校情報取得を追加しています。LLMのOCRで学校名と学部名を取得します。Perplexityへ学校名・学部名を渡し、学校の情報やWebサイトURLをインターネットから取得する形をとっています。
書類選考時には、応募者の学校情報やWebサイトのURLなどを検索して確認する作業が発生していましたが、これもDifyが自動化することで担当者の調査作業がほぼゼロになりました。
従来：
- 学校の情報をサイト検索して都度調べる
→ 30～60秒/人かかる
導入後：
- Difyが書類情報から検索し、結果をSlack通知しNotionへ自動記録
これにより、選考プロセスの“調査作業”も解消され、さらに工数削減に寄与しています。
OCRにはGemini 2.5 Flash × ビジョン機能を採用
応募書類（PDF）の読み取りには、LLMブロックのビジョン機能を利用しています。
実はあまり知られていませんが、DifyのWorkflowでは、LLMノードに「Vision対応モデル（今回であればGemini 2.5 Flash）」を指定してファイルを渡すだけで、PDFや画像のOCRを行うことができます。
PDFの文字抽出に加えて、テキスト抽出ノードでは対応できない
- PDFに埋め込まれた画像からの文字抽出
- 手書き書類のOCR
- スキャン画像からのテキスト取得
まで一貫して行えるため、書類選考フローと非常に相性が良いです。PDFを直接LLMに渡すことで、別途OCRサービスを用意せず標準のDifyの機能で完結します。
LLMはGemini 2.5 Flashを採用し、有償版のGemini API経由で利用しています。社内の別案件で日本語OCR精度を比較した結果、Geminiが最も高い精度を出していたためです。
導入効果：書類、Webテスト選考の総時間が50%減！
本仕組みを導入した結果、 選考に必要な工数は約50%削減 されました。
現在は、
- AIが“問題なし”とチェックした候補者も、人が最終確認としてAI要約＋重要確認箇所の1分チェックを実施
- ただし、AIが十分に整形・要約してくれているため、確認時間は大幅に短い
- 学校情報の検索をAIが自動化することで、人手作業がさらに削減される
という現実的で安全性の高い運用に落ち着いています。
その結果、
- 1人15分かかっていた確認業務が、問題なし候補については3～5分に短縮
- 要確認者（およそ2割）についてのみ、従来どおり丁寧に確認
- 学校情報取得の自動化により、人手作業が軽減
という形で、全体として約50%の工数削減を実現しました。
月に50名くらいの応募をいただけるので、具体的な削減工数としては、
- 書類選考で375分の工数削減（Before：50名×15分=750分。After：750分×50％=375分）
- Webテスト選考で300分の工数削減（8割くらいがWebテスト選考に進んでいくので、Before：(50名×0.8)×15分=600分。After：600分×50%=300分）
となり、月に約11時間程度の工数削減ができています。人事担当者が一人ということを考えると、月に丸一日以上の余裕が生まれることになります。
| 項目 | Before | After |
|---|---|---|
| 選考時間 | 応募者全員を15分ずつかけて確認 | 問題なし候補はAI要約＋重要箇所の1分確認で5分、要確認や不備ありの場合はしっかり15分（全体では約50%削減） |
| 作業内容 | 書類確認＋学校情報等の手動検索 | Difyが学校情報を自動取得し、書類の要約・整理まで実施 |
| 最終判断 | 人事担当者がすべての情報を読み込む必要 | AIの下準備後に、人は最終判断だけに集中 |
| 判断の透明性 | 理由は担当者の頭の中 | 理由・要約・フラグがNotionに残り、共有可能 |
現場担当者の声
実際に運用している人事担当者からは、以下のようなフィードバックをもらっています。
導入前はすべての応募書類に対し、公正に判断するために、日夜神経を尖らせていました。選考のイチ過程ながらとても時間を要する業務でした。
今では『定めた基準に則って、AIが一次チェックしてくれている安心感』があります。
AIが機能することでヒューマンエラーの心配がなくなり精神的負荷が軽減され、面接での質問内容をさらに深く考える時間に充てられる等、余裕をもつことができるようになりました。何より、AI一次チェックロジックを自身でカスタマイズできるため、『自身の判断とより近い判断理由』がNotionに全部書いてある状態が整えられ、採用部門への共有もスムーズです。
人事の不安を解消するためのセキュリティ設計
導入時には、「応募者情報の扱い」について人事から強い懸念がありました。
- 応募者の個人情報が外部に渡ってしまわないか？
- モデルに学習されてしまうのではないか？
- Webテストの出題内容が漏れてしまわないか？
- 社内で人事以外のメンバーに見られることはないか
そこで、次のような方針でセキュリティと心理的安心を確保しています。
-
人事専用のセルフホスト環境でDifyを稼働
- Difyは自社管理の環境にセルフホストし、応募書類データが外部SaaSに保存されないようにしています
- 全社的に利用しているDifyから切り離すことで、人事メンバーのみアクセス可能な環境を構築しています
- ALB（Application Load Balancer）のリスナールールを利用することで、管理画面は社内からのみアクセス可能、APIのみ外部から呼び出しできるように特定パスを起点として接続制限を設定しています
- LambdaからDify Workflowを呼び出すために必要なAPIキーはAWS SSM（Systems Manager）のパラメータストアで保存しています
-
LLMは各提供元の利用規約・設定に基づき、学習に利用されない（またはオプトアウト可能な）プラン/設定を選択
- 利用しているLLMは、いずれも有償のAPI経由のエンドポイントで呼び出しており、 モデル側に応募データが学習されない形で運用しています
-
Webテストは「採点・解析済みデータ」だけを渡す
- Webテストの回答内容や問題文そのものはAIに渡さず、分野別スコアや解析レポートなどのサマリーデータだけを入力としています
この“技術的安全性”と“心理的安心”の両方を満たす設計にしたことで、人事部門からも「これなら安心して使える」という声が得られました。
やってみて分かった3つのポイント
今回の実装を通して、業務にAIをうまく組み込むための重要なヒントが見えてきました。
1. Difyは「依頼画面」ではなく「ロジックエンジン」として使う
Dify標準のチャットやワークフロー画面を現場担当者に使わせるのは、ツール切り替えの手間やUIの学習コストがかかります。生成AIについても例外ではありません。いくら簡単で使いやすいUIだったとしても、そのために何かを開く。というのはストレスがかかるものです。
そのため、既存のツール（NotionやSlack）の 「裏側で動く賢いエンジン」 として組み込み、API経由で実はDifyが動いている状態を作ることが、現場定着への最短ルートでした。
2. AIに最終判断をさせないほうが、うまくいく
AIの役割は、あくまで 「人間が見るべき候補者を、浮かび上がらせること」。
「最終的な合否は人間が決める」というラインを守ることで、人事部の心理的な抵抗感をなくし、スムーズな導入を実現できました。
特に注意しているのは、本来「要確認」にすべき候補者をAIが「問題なし」と見逃してしまう（False Negative）リスクです。そのため一次チェック基準はあえて少し“緩め”に設定し、「少しでも迷うケースは要確認側に振る／最終判断は必ず人間が行う」というポリシーで運用しています。
3. Notionにすべての履歴を残すと、チームの透明性が劇的に上がる
Slack通知だけでなく、NotionデータベースにAIの出力（要約・チェック結果・理由）を書き戻す設計にしたのが正解でした。これにより、採用担当、面接官、開発者といった関係者間で「なぜ、この候補者は次のステップに進んだのか？」という認識のズレが格段に減りました。
現時点の課題と、今後の拡張方針
中途採用への拡張
今回のAIを使った選考フローは、まず新卒採用を対象に運用を開始しています。理由は、次の課題が残っているためです。
- 中途採用では、職種ごとに募集要項やチェック観点が大きく異なる
- 現状は Dify のテンプレートにチェック観点を“直書き”しているため、変動の少ない新卒向けにしか適用していない
今後は、中途採用の多様なポジションにも展開できるようにしていきたいと考えています。そのためには、募集要項やチェック観点を Notionで管理し、職種に応じて Dify Workflow に引数として渡す構成 に変更する必要があります。
これにより、「新卒専用のAI」から、「職種横断で使える汎用的な選考エンジン」に進化させていく計画です。
AI一次チェックのトリガー化
AI一次チェックの実行方法を、手動のボタン押下から、応募者情報登録をトリガーにしたイベントドリブンな自動実行にする予定です。
Dify v1.10.0よりトリガー機能が導入され、WebhookでWorkflowを呼び出せるようになりました。Notionでは情報の更新をトリガーにしてWebhook送信ができます。そのため、人事アシスタントの情報登録と同時に、イベントドリブンなDifyのWorkflowの呼び出しが可能になるはずです。
具体的な設計としてはこのように考えています。
- Notion：書類登録時にページIDを含めてWebhook呼び出し
- Dify：ページIDを元に対象レコードを特定し、Notionから書類取得
- ：現在と同様のAI一次チェックを実行
- ：ページIDを元に対象レコードを特定し、一次チェック結果をNotionに書き込み
まとめ：AIは「審査官」ではなく、優秀な「アシスタント」だった
今回私たちが実装したのは、AIが人間の判断を代替する仕組みではありません。人間が “本当に見るべき応募者だけ”に集中するための仕組みです。
- Notion（データベース）
- Slack（インターフェース）
- Dify（ロジックエンジン）
- AWS Lambda＋HTML（各ツールをつなぐ接着剤）
この絶妙な役割分担によって、「全員の応募書類を15分ずつ読む」という単純作業を、「AIのチェック結果が『要確認／不備あり』のおよそ2割の候補者だけを丁寧に見る」という、より付加価値の高い業務へと変えることができました。
また、今回の事例を通じて、Difyを業務フローに取り込むときは「新しくツールを追加する」のではなく、「既存業務アプリの頭脳として裏側で動かすと真価を発揮する」と強く感じました。
もしあなたが、「AI導入を進めたいが、現場の理解が得られない」「何から手をつければいいか分からない」と感じているなら、まずは 「判断は人間に残しつつ、下準備だけAIに任せる」 というアプローチを検討してみてはいかがでしょうか。
Difyを使えば、そのための「優秀なアシスタント」は、驚くほど簡単に作ることができます。
最後に：「Dify活用プロジェクト」なのにDifyを使わなかった話
ここまで読んでいただいた方に、一つ告白があります。
今回の事例は Dify活用プロジェクトのフェーズ2 の話でした。しかし、前身となるフェーズ1ではDifyを使ってません。
なぜか？プロジェクト発足当初、採用チームが最も課題に感じていたことは、「NotionとSlackの間の連携作業の手間」でした。そのため、なるべく既存の業務フローや利用ツールを変えず課題を解決させるために、Notionから起動が可能な依頼画面を作成しました。
ところがこの段階では、NotionやSlackのAPIを呼び出す必要はあれど、生成AIを利用する必然性がありません。
せっかくだし、と思いDifyを無理やり活用してみました。採用状況のステータスなどから依頼文章のたたき台を生成する。Slackのメンション先の予測をする。など、いくつか試してみました。しかし、目的と手段が入れ替わってしまうと上手くいくはずがありません。当然オール没です。
そんなフェーズ1を経て、採用チームから「選考のAIアシスタントを入れたい」という、明確で生成AI向きなニーズが上がってきたことで、今回の事例に繋がっています。
エンジニアリングは、それ自体が目的ではなく「課題を解くための手段」です。 今回のプロジェクトを通じて、まず現場の課題と目的があって、その上でDifyを組み込むときに一番力を発揮することを改めて実感しました。