採用の適性検査の結果の PDF を、職種の求める人物像と照らして面接で確かめる点のメモにまとめ、採用担当の確認を経て面接官へ届ける
適性検査の結果帳票のPDFを読み、職種の求める人物像に関係する項目を拾って、面接で確かめる点と質問の案のメモにします。採用担当が確かめて直したものを、面接官へ届けます。
- 生成AI
- Azure OpenAI Service/Claude
- 連携・自動化
- Make/n8n/Power Automate/Zapier
- 対象業界
- IT・SaaS/人材/小売/金融
- 対象部門
- 採用
- 対象業務
- 書類作成/要約
- 主な課題
- 人手が足りない/属人化している/書類作成に時間がかかる
- AIで行う処理
- 要約
- 主な効果
- 判断支援/品質標準化/工数削減
- 導入難易度
- ★★☆☆☆
- 実装レベル
- 半自動化
- 費用感
- ノーコード連携(中)
- 人間の確認
- 条件付き
01導入前 / 導入後の業務フロー
- 応募者が適性検査を受け終えると、提供会社の管理画面に結果が出る
- 採用担当が結果のPDFを出力し、採用管理システムの応募者の記録に添付する
- 帳票を読み、能力の得点と、性格の尺度で目立つ傾向を拾う
- 応募職種の求める人物像の資料を開き、3番目の傾向のうち関係するものを選ぶ
- 面接で確かめる点と質問の案をメモに書く
- 面接の予定を見て、担当の面接官にメールでメモを送る
- 人採用担当が結果のPDFを出力し、SharePoint の文書ライブラリ「適性検査の結果」に、応募者ID・応募職種を付けて保存する
- 自動ファイルの作成をきっかけに Power Automate のフローが動き、ファイルの中身を取り出す
- 自動職種ごとの「人物像と尺度の対応表」と面接の評価項目を SharePoint リストから引く
- 自動AI Builder のプロンプトが、帳票と対応表から、面接で確かめる点と質問の案を JSON で返す
- 自動質問の案に、職務に関係しない事項の語が入っていないかをフローで照合する
- 自動採用担当に、Approvals の Start and wait for an approval of text でメモの下書きを出す
- 人採用担当が下書きを読み、帳票と見比べて直し、承認する
- 自動承認されたメモを、面接の予定の一覧から引いた面接官へ Teams で届ける
- 自動メモの最終版と、採用担当が直した点を記録に残す
各工程の詳しい説明を読む
- 応募者が適性検査を受け終えると、提供会社の管理画面に結果が出る
- 採用担当が結果のPDFを出力し、採用管理システムの応募者の記録に添付する
- 帳票を読み、能力の得点と、性格の尺度で目立つ傾向を拾う
- 応募職種の求める人物像の資料を開き、3番目の傾向のうち関係するものを選ぶ
- 面接で確かめる点と質問の案をメモに書く
- 面接の予定を見て、担当の面接官にメールでメモを送る
(a)読み方が担当者ごとに違う。 3番目でどの尺度を「目立つ」とするかは、担当者の慣れで決まります。同じ帳票でも、ある担当者は「慎重さ」を書き、別の担当者は書きません。 面接官が受け取るメモの中身が、誰が書いたかで変わります。
(b)職務に関係しない話に寄っていく。 性格の尺度には、ストレスの感じ方や気分の波のような項目があります。メモに「ストレスに弱い傾向。私生活の状況を確認」と書かれると、面接官は家庭の事情を聞いてしまいます。 公正な採用選考の考え方から外れる質問は、こうした書き方から生まれます。
(c)結論を書いてしまう。 忙しい日ほど、メモが「営業向きではない」「要注意」のような短い結論になります。面接官は結論を確かめに行くだけになり、応募者の話を聞かなくなります。
(d)1件の時間が積み上がる。 帳票を読み、人物像と照らし、メモを書いて送るまで1件12分です。月150件で30.0時間になり、慣れた2名に偏ります。 面接の前日にまとめて書くことになり、面接官に届くのが当日の朝になることもあります。
- 【人】 採用担当が結果のPDFを出力し、SharePoint の文書ライブラリ「適性検査の結果」に、応募者ID・応募職種を付けて保存する
- 【自動】 ファイルの作成をきっかけに Power Automate のフローが動き、ファイルの中身を取り出す
- 【自動】 職種ごとの「人物像と尺度の対応表」と面接の評価項目を SharePoint リストから引く
- 【自動】 AI Builder のプロンプトが、帳票と対応表から、面接で確かめる点と質問の案を JSON で返す
- 【自動】 質問の案に、職務に関係しない事項の語が入っていないかをフローで照合する
- 【自動】 採用担当に、Approvals の Start and wait for an approval of text でメモの下書きを出す
- 【人】 採用担当が下書きを読み、帳票と見比べて直し、承認する
- 【自動】 承認されたメモを、面接の予定の一覧から引いた面接官へ Teams で届ける
- 【自動】 メモの最終版と、採用担当が直した点を記録に残す
7番目が、この設計の分かれ目です。 下書きは必ず採用担当が読みます。検査の結果を面接官に渡す前に、帳票の読み方を知っている人の目を通すことは外しません。 自動で面接官に届く経路は作りません。
5番目で語の照合を AI の外に置いているのも、意図してのことです。 プロンプトで「家族や健康のことを聞かない」と書いても、まれに外れた質問が混ざります。 照合に当たった下書きは、採用担当の画面で目立つ印を付けて出します。
02今回想定するシステム構成
適性検査の提供会社の管理画面(結果をPDFで出力) │ 採用担当が応募者ID・応募職種を付けて保存 ▼【トリガー】When a file is created (properties only) Power Automate(クラウドフロー) ├──▶ Get file content:PDFの中身を取り出す ├──▶ Get items:人物像と尺度の対応表・面接の評価項目(SharePoint リスト) ▼ AI Builder のプロンプト(Run a prompt、文書の入力、JSON 出力) │ 能力の得点の写し/人物像に関係する傾向/確かめる点と質問の案/帳票の注意書き ▼ Power Automate ── 職務に関係しない事項の語の照合 ▼ Approvals ── Start and wait for an approval of text(採用担当が読んで直す) ▼ Microsoft Teams ── 面接官へメモを届ける ──▶ 記録用の SharePoint リストへ
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| ワークフロー | Power Automate(クラウドフロー) | Make、n8n、Zapier |
| 生成AI | AI Builder のプロンプト(Run a prompt、文書の入力、JSON 出力) | Azure OpenAI(Microsoft Foundry)、Claude |
| 連携 | SharePoint(結果の文書ライブラリ、人物像と尺度の対応表、面接の予定、記録) | Microsoft Lists |
| 承認 | Approvals(Start and wait for an approval of text) | Teams のアダプティブカード |
| 通知 | Microsoft Teams(面接官とのチャット) | Outlook のメール |
入口は、SharePoint の When a file is created (properties only) です。 文書ライブラリにファイルが作られたときに動き、応募者ID・応募職種の列もあわせて受け取れます。 中身は Get file content で取り出して、プロンプトに渡します。
AIは、AI Builder のプロンプトの文書の入力を使います。 公式の説明では、文書の入力に使えるファイルの種類は PNG、JPG、JPEG、PDF で、文書は50ページ未満、ファイルの合計は25MB未満、処理は最大100秒とされています。適性検査の結果帳票は数ページなので、この範囲に収まります。ただし、大きな文書の表の行は抜き出しが不正確・不完全になりうるとも書かれています。 得点の表を読ませるところは、採用担当の確認を前提にします。
採用担当の確認には、Approvals の Start and wait for an approval of text を使います。 プロンプトの出力のあとに人の確認を挟む手順として、公式の説明に載っているアクションです。承認する人は、受け取った文章をその場で直してから承認できます。
03どうやって実装するのか
処理の起点を決める
文書ライブラリにPDFが保存されたことを起点にします。 応募者が検査を受け終えた日に採用担当が出力して保存すれば、その日のうちに下書きが採用担当の手元に届きます。 面接の前日にまとめて作る形にはしません。前日にまとめると、第3章の(d)と同じく、面接官に届くのが当日の朝になります。
保存するときに、応募者IDと応募職種の列を必須にします。 列が空のファイルは、フローの最初の条件で止めて採用担当に戻します。職種が分からないと、照らす人物像が決まらないからです。 ファイル名から推し量ることはしません。
同じ応募者の帳票が二度保存されることがあります。 再受検や出力のやり直しのときです。記録のリストに同じ応募者IDの下書きがあれば、新しい下書きを作る前に採用担当に「再保存」の印を付けて知らせ、どちらを使うかを決めてもらいます。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 結果帳票 | 能力の検査の得点、性格の検査の尺度ごとの傾向、提供会社の注意書き(回答の態度など) | 文書ライブラリのPDF |
| 応募者の情報 | 応募者ID、応募職種 | 文書ライブラリの列 |
| 人物像と尺度の対応表 | 職種ごとの人物像の項目、関係する尺度の名前、面接で聞く行動の場面の例 | SharePoint リスト |
| 面接の評価項目 | 職種ごとの評価項目と評価の目安 | SharePoint リスト |
| 面接の予定 | 応募者ID、面接の日時、面接官 | SharePoint リスト |
氏名はAIに渡しません。 帳票には応募者の氏名が印字されていますが、メモに要るのは傾向と質問だけです。プロンプトには応募者IDで指示し、メモにも氏名を書かせません。 面接官に届けるときに、フローが面接の予定から氏名を足します。
質を決めるのは、人物像と尺度の対応表です。 例えば法人営業の「顧客の要望を聞き出す」という項目に、帳票のどの尺度が関係しそうか、面接ではどんな場面を聞けばその行動が分かるかを、経験のある採用担当と現場の課長で書きます。これが第4章の②の「頭の中の対応表」を紙に移す作業です。 対応表に無い尺度は、メモに出しません。
対応表には「扱わない尺度」の行も書きます。 気分の波やストレスの感じ方のように、職務の場面に結びつけにくく、聞き方を誤ると健康や私生活の質問になる尺度は、ここで外します。外した尺度は、AIに渡す指示の側でも触れないように書きます。
データの取得方法を決める
| 取るもの | どこから | 何に使うか |
|---|---|---|
| ファイルの作成と列の値 | When a file is created (properties only) | 起動と、応募者ID・職種 |
| PDFの中身 | Get file content | プロンプトの文書の入力 |
| 対応表と評価項目 | Get items(Filter Query で職種を指定) | プロンプトの文字の入力 |
| 面接官 | 面接の予定を Get items | 届け先 |
対応表は職種で絞ってから渡します。 3職種分の対応表を全部渡すと、別の職種の人物像の言葉がメモに混ざります。 Get items の Filter Query で応募職種に当たる行だけを取り、文字の入力として渡します。
面接の予定がまだ無い応募者もいます。 検査を受けた時点で面接の日が決まっていなければ、下書きの承認までは進め、面接官への送付は予定が入った時点で行います。 予定の一覧に行が作られたときに動く別のフローが、承認済みのメモを送ります。
AIへ渡す前に整形する
- 列の確認 … 応募者IDと応募職種が入っているか、職種が対応表にある名前かを確かめます
- ファイルの確認 … PDFであること、ページ数が50ページ未満、大きさが25MB未満であることを確かめます
- パスワードの確認 … 提供会社によってはPDFに鍵がかかっています。開けないファイルは採用担当に戻します
- 再保存の確認 … 同じ応募者IDの下書きが記録にあるかを確かめます
- 対応表の取り出し … 応募職種の行だけを取り、「扱う尺度」と「扱わない尺度」に分けて文字にします
2番目は、ほとんどの帳票で問題になりません。 ただし、複数の応募者の結果を1つのPDFにまとめて出力したファイルが保存されると、別の応募者の結果が混ざります。ページ数が普段より多いファイルは、採用担当に戻して1人ずつ出力し直してもらいます。
5番目で「扱わない尺度」を文字で渡すのは、AIが帳票の全部を読むからです。 帳票には扱わない尺度も印字されているので、「読まないでください」ではなく「メモに出さないでください」と名前を挙げて指示します。
AIに処理させる
させるのは、帳票のうち対応表に載っている尺度の傾向を拾い、それを面接で確かめる点と質問の案にまとめることだけです。 合否や適否の判断、性格の断定はさせません。
| まとめるもの | まとめ方 | 判断できないときの扱い |
|---|---|---|
| 能力の検査の得点 | 帳票に書かれた値をそのまま写す | 読み取れなければ空にして unreadable |
| 人物像に関係する傾向 | 対応表の尺度ごとに、帳票の記述を短く写す | 帳票に該当する尺度が無ければ書かない |
| 確かめる点 | 傾向を、職務の場面での行動の問いに書き換える | 対応表に場面の例が無ければ出さない |
| 質問の案 | 過去の行動の事実を聞く形(「どうしましたか」) | - |
| 帳票の注意書き | 回答の態度などの注意書きをそのまま写す | 無ければ空 |
2行目で「写す」と書いているのが大事です。 帳票の「慎重に物事を進める傾向」を、AIが「決断が遅い」と言い換えると、検査の結果より強い言葉が面接官に届きます。 言い換えはさせず、帳票の言葉を短く写させます。
3行目は、傾向を「確かめる問い」に変える工程です。 例えば「人と関わることへの意欲が控えめ」という傾向なら、「初対面の顧客に連絡を取る必要があった場面で、どう準備し、どう進めたか」のように、職務の場面での行動を聞く問いにします。帳票の傾向が面接で当てはまらなければ、それも大事な情報です。
| させないこと | 理由 |
|---|---|
| 合否・適否の判断 | 結果のみで採否を決めない。判断は面接と評価会議で行う |
| 性格の断定(「〜な人」) | 結果を絶対視させない。面接官に先入観を渡す |
| 扱わない尺度への言及 | 健康や私生活の質問につながる |
| 家族・出身・住宅・思想などに触れる質問 | 就職差別につながるおそれのある事項 |
| 得点の解釈(「平均より低い」) | 基準は提供会社の帳票の記載に従う。AIが作らない |
4行目は、指示とフローの照合の両方で止めます。 厚生労働省のサイトは、本人に責任のない事項(本籍・出生地、家族、住宅状況、生活環境)や、本来自由であるべき事項(宗教、支持政党、人生観など)を把握することが、就職差別につながるおそれがあると挙げています。質問の案にこれらが入ると、面接官はそのまま読み上げます。
指示内容を固定する
あなたは人事部の採用担当で、一次面接の準備メモの下書きを作る立場です。
添付の適性検査の結果帳票と、職種の対応表だけを根拠にしてください。
【作るもの】
1. ability_scores ... 能力の検査の得点を、帳票の表記のまま写す
2. traits .......... 対応表の「扱う尺度」に当たる帳票の記述を、尺度ごとに短く写す
(帳票の言葉を使い、強い言葉に言い換えない)
3. checkpoints ..... traits を、対応表の「行動の場面の例」に沿って、
面接で行動の事実を聞いて確かめる点に書き換える
4. questions ....... 確かめる点ごとに、過去の行動を聞く質問の案を1〜2個
5. report_notes .... 帳票にある注意書き(回答の態度など)をそのまま写す
【厳守事項】
- 合否、適否、向き不向きを書かないでください。
- 「〜な人」「〜に欠ける」のように性格を断定しないでください。
- 対応表の「扱わない尺度」({excluded_scales})には触れないでください。
帳票に書かれていても、traits にも質問にも出さないでください。
- 家族、出身地、住所・住宅、健康・病歴、宗教、支持政党、思想、
人生観、尊敬する人物、愛読書、労働組合に関わる質問を作らないでください。
- 質問は、職務の場面での過去の行動を聞く形にしてください。
「もし〜ならどうしますか」だけで終わる質問にしないでください。
- 得点が平均より高い・低いといった解釈を書かないでください。
帳票に解釈の記載があるときだけ、その記載を写してください。
- 読み取れない値は空にし、status を "unreadable" にしてください。
- 応募者の氏名をどこにも書かないでください。
- JSON のマークダウンを答えに含めないでください。
【応募者ID】{applicant_id}
【応募職種】{job_title}
【この職種の対応表(扱う尺度と行動の場面の例)】{scale_map}
【面接の評価項目】{eval_items}
【結果帳票】(文書の入力)
「性格を断定しない」と「強い言葉に言い換えない」を別々に書くのが大事です。 断定を禁じるだけだと、AIは「決断に時間がかかる傾向」のように、断定ではないが帳票より強い言葉に言い換えます。 言い換えそのものを禁じ、帳票の言葉を写させます。
質問の形を「過去の行動」に決めているのは、評価の目安とそろえるためです。 仮定の質問は答えがうまい人ほど高く見え、職務の場面で実際にどう動いたかが分かりません。 最後の一文は、JSON が作れないときの対処として公式の説明が挙げている一文です。
出力形式を固定する
次の形のJSONで受け取ります。 プロンプトの JSON の形式を Custom にして保存し、毎回この形で返るようにします。
{
"applicant_id": "",
"status": "ok | unreadable | not_a_report",
"ability_scores": [ { "name": "", "value": "" } ],
"traits": [ { "scale": "", "report_text": "", "persona_item": "" } ],
"checkpoints": [
{ "persona_item": "", "point": "", "questions": ["", ""] }
],
"report_notes": ""
}
1つ目の理由は、照合をかける場所が決まることです。 職務に関係しない事項の語の照合は、checkpoints の point と questions にだけかけます。帳票の写しである traits は照合から外し、採用担当が帳票と見比べます。
2つ目は、メモの形を面接官ごとにそろえられることです。 フローが JSON から次の形のメモを組み立てるので、誰の担当の応募者でも、面接官は同じ並びで読めます。
【一次面接の準備メモ】応募者ID:A-2026-1043 職種:法人営業
【能力の検査】言語 54/非言語 48(帳票の表記のまま)
【確かめる点】
1. 顧客の要望を聞き出す(帳票:人と関わることへの意欲が控えめ)
質問案:初対面の相手に連絡を取る必要があった場面で、どう準備しましたか
2. 期限を守って進める(帳票:慎重に物事を進める傾向)
質問案:急ぎの依頼と確認の両方が要った場面で、何を優先しましたか
【帳票の注意書き】回答の一貫性に関する注記なし
※検査の結果は面接で確かめるための材料です。結果だけで判断しないでください。
メモの最後の一文は、毎回フローが付けます。 AIに書かせると言い回しが変わるので、固定の文として足します。
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| 結果の文書ライブラリ | When a file is created (properties only)、Get file content | 起動とPDFの取り出し |
| 対応表・評価項目 | SharePoint の Get items | 職種の行だけを取る |
| AI Builder のプロンプト | Run a prompt(文書の入力と文字の入力) | 下書きのJSON |
| Approvals | Start and wait for an approval of text | 採用担当の確認と手直し |
| 面接の予定 | SharePoint の Get items | 面接官の特定 |
| Microsoft Teams | Post message in a chat or channel | 面接官へのメモの送付 |
| 記録のリスト | SharePoint の Create item | 下書き・最終版・直した点 |
採用管理システムには書き込みません。 メモは面接官に届けるための文書で、選考の記録として残すものではありません。 評価は、面接の後に面接官が評価シートに書きます。
面接官には帳票そのものを送りません。 送るのは承認されたメモだけです。帳票を見たい面接官には、採用担当が面接の前に口頭で補足します。 この運用はいまと変わりません。
人が確認する
人が見るのは、すべての下書きです。 適性検査の結果を面接官に渡す前の工程なので、ここは件数が多くても省きません。
- 照合に当たった下書きを先に見る … 職務に関係しない事項の語に当たった質問を、消すか書き直します
- 能力の得点を帳票と見比べる … 表の読み取りは不正確になりうるので、値は必ず帳票で確かめます
- 傾向の写しを帳票と見比べる … 帳票の言葉より強くなっていないかを見ます
- 質問の案を職種の評価項目と見比べる … 評価の目安で点を付けられる問いになっているかを見ます
- 直して承認する … Approvals の画面で文章を直し、承認します
2番目と3番目を省かないでください。 得点の読み違いと言葉の強まりは、面接官に届いた後では誰も気づけません。 面接官は帳票を見ていないからです。
目標は、150件をならして1件4分です。 照合に当たらず、得点も傾向も帳票どおりなら2分ほどで終わります。直すところが多い下書きは数分かかります。
例外に対処する
| 起きること | 対応 |
|---|---|
| 応募者IDか職種の列が空 | フローを止め、採用担当に戻す。ファイル名から推し量らない |
| 職種が対応表に無い | 下書きを作らず、対応表の追加を採用担当に依頼する |
| PDFに鍵がかかっている | 開けない旨を採用担当に戻し、鍵の無い形で出力し直してもらう |
| 複数の応募者の結果が1ファイルに入っている | ページ数で検知し、1人ずつ出力し直してもらう |
| 得点が読み取れない | unreadable。得点の欄を空にして下書きを出し、採用担当が帳票から写す |
| 帳票ではない書類が保存された | not_a_report。採用担当に戻す |
| 質問の案が照合に当たった | 下書きに印を付け、採用担当が書き直してから承認する |
| 処理が100秒を超えて止まる | 採用担当に知らせ、手でメモを書く。再実行は1回まで |
| 面接の予定がまだ無い | 承認まで進め、予定が入った時点で送る |
| 承認されないまま面接の前日になる | 採用担当のチャネルに知らせる |
5行目で下書きを止めないのは、得点だけが読めない帳票が多いからです。 得点の表は帳票のレイアウトによって読み取りにくく、傾向の記述は読めているのに得点だけが空ということが起きます。 得点は採用担当が帳票から写せば足ります。
8行目は、手で書く道を残しておくためです。 面接の日は動かせないので、AIが止まったときにメモが届かないことのほうが困ります。
記録を残す
- 結果帳票のPDF(文書ライブラリに保存したもの)と、保存した担当者・日時
- AIが返した JSON と、そのときのプロンプトの版、渡した対応表の版
- 照合に当たった語と、採用担当が直した内容
- 採用担当が承認したメモの最終版と、下書きとの違い
- 面接官に届けた日時と、届けた相手
- 職種ごとの、照合に当たった件数と直された箇所の傾向
4つ目の「下書きとの違い」は、プロンプトと対応表を直す材料です。 採用担当が毎回同じ箇所を直しているなら、対応表の場面の例が足りないか、指示が言い換えを止めきれていません。
保存の期間は、採用選考の記録の扱いに合わせて決めます。 選考が終わった応募者の帳票と下書きは、決めた期間を過ぎたら消します。
04実装レベルの3段階
最小構成では、手間はあまり減りません。 添付とメモへの書き写しが残るので、確かめるための段階です。 半自動化で、1件12分が4分になり、この段階が本記事の想定です。 帳票を読んで人物像と照らす作業が下書きの確認に変わります。本格構成で足すのは、取り込みの自動化です。 ただし、検査の提供会社が結果を取り出す仕組みを公開しているかは会社ごとに違うので、提供会社に確かめてから検討します。 段階を飛ばさないでください。 半自動化を1か月回すと、採用担当が直している箇所の傾向が見えます。対応表とプロンプトを直してから取り込みを足すほうが、確認の時間が先に減ります。
05工数削減シミュレーション
導入後 150件 × 4分 ÷ 60 = 10 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 中途と新卒の採用を通年で行い、一次面接の前に適性検査を受けてもらっている会社。結果の帳票を採用担当が読んで面接官に要点を伝えているが、読み方が担当者ごとに違い、面接官が帳票をそのまま読んで性格を決めつけてしまうことがある場合。職種ごとの求める人物像と面接の評価項目が文書になっている場合。Microsoft 365 を使っている場合。
- 適性検査を使っていない会社、または結果を面接官に見せない運用の会社。採用が年に数名で、採用担当が1件ずつ丁寧に伝えられる場合。検査の提供会社との契約で、結果の帳票を外部のAIサービスに渡すことが認められていない場合。なお、合否の判断、検査の結果をどこまで面接に使うかの方針決めは、この構成では代替できません。
07最小構成で試す方法
- 先月面接した応募者の結果帳票から20件を選ぶ(3職種がそろうようにし、メモの書き方で迷ったものを入れる)
- 経験のある採用担当に、それぞれの帳票で何を拾い、なぜそう書いたかを聞き取る
- 帳票の氏名を伏せたPDFを、手元のAIサービスの画面に1件ずつ添付する
- 「この帳票から、法人営業の人物像(顧客の要望を聞き出す、期限を守って進める)に関係する記述を帳票の言葉のまま写し、面接で過去の行動を聞いて確かめる質問を作ってください。合否や性格の断定、家族や健康に関わる質問は書かないでください」と指示する
- 出てきた下書きを、当時の採用担当のメモと突き合わせる
20件は必ずやってください。 フローを組む前に、「帳票から職種に関係する記述を拾えるのか」を確かめます。
| 出てきた内容 | 判断 |
|---|---|
| 当時のメモと同じ傾向が拾えた | 対応表の作成とフローに進む |
| 帳票より強い言葉に言い換えた | 指示の書き方で直る。構成は有効 |
| 得点の表が読み取れない | 得点は人が写す前提にする。 傾向が読めていれば構成は有効 |
3行目が出ることは珍しくありません。 帳票の得点はグラフや表で描かれていることが多く、文字の記述ほど安定して読めません。 その場合は、得点の欄を最初から採用担当が埋める形にしてください。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 帳票より強い言葉に言い換える | 言い換えを禁じ、帳票の言葉を写させる |
| 合否や向き不向きを書く | 指示で禁じ、メモの最後に固定の注意書きを付ける |
| 家族・健康に触れる質問が出る | 指示で禁じたうえで、フローの語の照合で止める |
| 扱わない尺度に触れる | 対応表の「扱わない尺度」を名前で渡す |
| 得点の表が読み取れない | 採用担当が帳票から写す前提にする |
| 別の職種の人物像が混ざる | 対応表を職種で絞ってから渡す |
| 複数の応募者が1ファイルに入る | ページ数で検知し、1人ずつ出力し直す |
| 鍵付きのPDFで止まる | 鍵の無い形で出力する設定を提供会社の画面で確かめる |
| 下書きがそのまま面接官に届く | 自動送付の経路を作らない。承認の後だけ送る |
| 面接官が帳票を見たがる | 帳票は渡さず、採用担当が口頭で補足する運用を続ける |
| 承認が面接に間に合わない | 前日に未承認の下書きを知らせる |
| 契約で外部への提供が認められていない | 提供会社に確かめ、認められなければこの構成を使わない |
上の3行が、この構成の失敗のほとんどです。 どれも「検査の結果が、実際より強い意味で面接官に届く」という同じ形をしています。写す、断定しない、照合で止める、の3つを入れてあるかで、メモを面接に使ってよいかが決まります。
最後の行は、作り始める前に確かめてください。 作り終えてから契約で止まると、対応表の手間も含めて無駄になります。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 応募者の適性検査の結果(能力の得点、性格の傾向)、応募者ID、応募職種、面接の予定と面接官の名前です。選考に使う個人情報で、扱いにはとくに注意が要ります。
- 結果のみで採否を決めない … 厚生労働省のサイトは、適性検査の結果を絶対視したりうのみにしたりせず、結果のみで採否を決めないことを求めています。メモは面接で確かめるための材料で、評価や合否の欄を持たせません
- 適性・能力に関係のない事項を把握しない … 同じサイトは、適性検査等によって適性・能力に関係のない事項を把握しないことも求めています。扱わない尺度を対応表で決め、質問の案から外します
- 処理される場所を確かめる … 公式の説明では、日本でホストされる Power Platform の環境では生成AIの機能を支える Azure OpenAI Service が米国でホストされ、地域をまたぐデータの移動を許可すると入力と出力が地域の外に移ることがあるとされています。管理者がこの設定を確かめ、応募者への個人情報の利用目的の示し方とあわせて判断してください
- 氏名をAIに渡さない運用にする … 帳票には氏名が印字されていますが、指示は応募者IDで行い、メモにも書かせません。 氏名は届けるときにフローが足します
- 提供会社との契約を確かめる … 結果帳票を外部のAIサービスで処理してよいかは、検査の提供会社との契約しだいです。 確かめる前に始めないでください
- 閲覧と保存の範囲を決める … 文書ライブラリと記録のリストは採用グループだけが見られるようにし、選考が終わった応募者の帳票と下書きは、決めた期間で消します
誤りが起きた場合のリスクは、検査の結果が強い意味で伝わって応募者が不当に低く見られることと、職務に関係しない質問が面接で出ることの2つです。 どちらも応募者の就職の機会に直結します。だからこの構成は、下書きを全件人が読む前提で作っています。
10まず何から始めるか
1週目:契約と方針を確かめる
検査の提供会社との契約で、結果帳票を外部のAIサービスで処理してよいかを、法務と確かめます。あわせて、検査の結果を面接でどこまで使うかの方針を、人事部で文書にします。
2週目:対応表を書く
3職種それぞれについて、人物像の項目、関係する尺度、面接で聞く行動の場面の例を、経験のある採用担当と現場の課長で書きます。「扱わない尺度」の行もここで決めます。
3週目:20件で試す
先月の帳票から20件を選び、氏名を伏せて手元のAIサービスに添付し、下書きを作らせます。当時の採用担当のメモと突き合わせ、言葉の強まりと職務に関係しない質問が無いかを最優先で見ます。
4週目:保存から承認までをつなぐ
Power Automate で、文書ライブラリへの保存を起点に下書きを作り、語の照合をかけ、Approvals で採用担当に出すところまで作ります。この時点では面接官に送らず、採用担当が自分のメモと見比べます。
2か月目: 承認したメモを Teams で面接官に届け始め、採用担当が直した箇所を毎週数えます。3か月目以降: 直された箇所の傾向から対応表とプロンプトを直し、1件12分が何分になったかを実測します。照合に当たる下書きと、言葉を直す下書きが目に見えて減った時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
| 適性検査等の結果を絶対視したりうのみにしたりしないこと、適性・能力に関係のない事項を把握したり結果のみで採否を決めたりしないこと、専門的な知識と経験をもった人が用いること。面接の質問を職務遂行に必要な適性・能力の評価に要る事項とし、評価基準をあらかじめ決めておくこと | 厚生労働省 公正採用選考特設サイト: 採用選考の具体的な方法 | 2026-10-14 |
| 就職差別につながるおそれがある14事項(本籍・出生地、住宅状況、家族、生活環境・家庭環境、宗教、人生観・生活信条、思想、購読新聞・愛読書、支持政党、尊敬する人物、労働組合・社会運動、身元調査、不要な健康診断、適性・能力に関係ない事項を含む応募書類) | 厚生労働省 公正採用選考特設サイト: 採用選考時に配慮すべき事項 | 2026-10-14 |
| プロンプトの文書の入力に PNG、JPG、JPEG、PDF を使えること。ファイルの合計が25MB未満、文書が50ページ未満、処理が最大100秒であること。大きな文書の表の行の抜き出しが不正確・不完全になりうること。入力に指示を含められないこと | Microsoft Learn: Add inputs to your prompt | 2026-10-14 |
| Run a prompt の名前(2025年5月に改称)。プロンプトの後に Approvals の Start and wait for an approval of text で人の確認を挟み、承認者が文章を直せること。利用の上限や容量による制限を受けることがあること | Microsoft Learn: Use your prompt in Power Automate | 2026-10-14 |
| SharePoint の When a file is created (properties only)、Get file content、Get items(Filter Query)、Create item | Microsoft Learn: SharePoint コネクタ | 2026-10-14 |
| 日本でホストされる環境では Azure OpenAI Service が米国でホストされ、地域をまたぐデータの移動を許可すると入力と出力が地域の外に移ることがあること。AI Builder の AI Prompts がこの設定の対象であること | Microsoft Learn: Move data across regions for Copilots and generative AI features | 2026-10-14 |
検査の結果を選考にどう使うか、結果帳票を外部のサービスで処理してよいかは、人事部・法務と検査の提供会社で確かめてください。 本記事は上記の公式情報で確認できた範囲だけを扱っています。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-1456)についてのご相談はこちらから。
