Media > AI活用ユースケース > 人事 > 各部門の採用の要望(業務量・欠員・必要なスキル)のメモから、要員申請書と求める人物像の下書きを作る

各部門の採用の要望(業務量・欠員・必要なスキル)のメモから、要員申請書と求める人物像の下書きを作る

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

部門から届く採用の要望のメモを、要員計画の表と等級の定義に照らして、要員申請書と求める人物像の下書きにします。あわせて、申請に足りない情報と、年齢や性別の条件に当たる表現を一覧にします。

サマリー
生成AI
ChatGPT/Claude/Gemini/Microsoft Copilot
対象業界
IT・SaaS/建設/物流/製造
対象部門
人事/採用
対象業務
書類作成
主な課題
属人化している/書類作成に時間がかかる/確認ミスが多い
AIで行う処理
生成
主な効果
品質標準化/対応スピード向上/工数削減
導入難易度
★☆☆☆☆
実装レベル
半自動化
費用感
SaaS追加(小)
人間の確認
必須
現在工数
25h/月
AI導入後
10h/月
想定削減
60%
年間削減
180h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. 部門が Forms で採用の要望を出す
  2. 採用担当が要望を読み、要員計画の表でその部門の計画の人数と今の人数を確かめる
  3. 申請書に要る項目のうち足りないもの(業務量の根拠、採用以外の手段の検討、等級)を部門に聞く
  4. 部門の回答を待ち、申請書を Word の様式で書き起こす
  5. 等級の定義書を見て、要望のスキルに合う等級を当て、人件費の見込みを書く
  6. 申請の承認の後、求める人物像を必須と歓迎に分けて書く
  7. 人物像を部門長に確かめてもらい、求人票の作成に回す
導入後(After)
  1. 人部門が Forms で採用の要望を出す(これまでと同じ)
  2. 人採用担当が、要望の回答を「要員申請の下書きエージェント」に貼り、申請書の下書きを頼む
  3. 自動エージェントが、要員計画のリストからその部門の計画の人数と今の人数を引く
  4. 自動エージェントが、申請書の様式の欄ごとに要望から書けることを書き、書けない欄を「部門に確認」とする
  5. 自動エージェントが、等級の定義と照らして等級の候補と根拠の文言を示す
  6. 自動エージェントが、部門への確認事項を1通の問い合わせの文面にまとめる
  7. 人採用担当が下書きと確認事項を見直し、部門に1回で問い合わせる
  8. 人部門の回答を貼り、エージェントに申請書を仕上げさせ、人物像の下書きと注意すべき表現の一覧を作らせる
  9. 人採用担当が等級と表現を確かめ、部門長に人物像を確かめてもらい、申請の承認に回す
各工程の詳しい説明を読む
  1. 部門が Forms で採用の要望を出す
  2. 採用担当が要望を読み、要員計画の表でその部門の計画の人数と今の人数を確かめる
  3. 申請書に要る項目のうち足りないもの(業務量の根拠、採用以外の手段の検討、等級)を部門に聞く
  4. 部門の回答を待ち、申請書を Word の様式で書き起こす
  5. 等級の定義書を見て、要望のスキルに合う等級を当て、人件費の見込みを書く
  6. 申請の承認の後、求める人物像を必須と歓迎に分けて書く
  7. 人物像を部門長に確かめてもらい、求人票の作成に回す

(a)聞き直しが何往復にもなる。 3番で足りない項目を聞いても、部門の回答で別の項目の不足が分かり、また聞きます。欠員の補充で急いでいる部門ほど、往復のたびに不満が溜まります。

(b)申請書の書き方が担当で違う。 ある担当は業務量の根拠を残業時間で書き、別の担当は受注の見込みで書きます。承認する人事部長から見ると、申請ごとに見る場所が違い、比べられません。

(c)人物像に条件が紛れ込む。 部門のメモの「若手」「体力のある男性」が、急いで書いた人物像にそのまま残ることがあります。求人票の段階で気づけばよいのですが、面接の評価の基準にまで残ると、選考そのものが偏ります。

(d)等級の当てはめがぶれる。 要望のスキルを等級の定義に当てる判断が担当によって違い、同じような要望で等級が1つずれた申請が出ます。

  1. 【人】 部門が Forms で採用の要望を出す(これまでと同じ)
  2. 【人】 採用担当が、要望の回答を「要員申請の下書きエージェント」に貼り、申請書の下書きを頼む
  3. 【自動】 エージェントが、要員計画のリストからその部門の計画の人数と今の人数を引く
  4. 【自動】 エージェントが、申請書の様式の欄ごとに要望から書けることを書き、書けない欄を「部門に確認」とする
  5. 【自動】 エージェントが、等級の定義と照らして等級の候補と根拠の文言を示す
  6. 【自動】 エージェントが、部門への確認事項を1通の問い合わせの文面にまとめる
  7. 【人】 採用担当が下書きと確認事項を見直し、部門に1回で問い合わせる
  8. 【人】 部門の回答を貼り、エージェントに申請書を仕上げさせ、人物像の下書きと注意すべき表現の一覧を作らせる
  9. 【人】 採用担当が等級と表現を確かめ、部門長に人物像を確かめてもらい、申請の承認に回す

6番目が、この設計の分かれ目です。 足りない項目を1つずつ聞くのではなく、様式の欄の一覧に照らして、聞くことを1通にまとめます。 部門にとっても、何を答えればよいかが一度で分かります。

8番目で、注意すべき表現を置き換えずに示すのも意図してのことです。 「若手」を「成長意欲のある方」に自動で言い換えると、部門が本当に求めていたこと(たとえば長く技能を継いでほしい)が見えなくなります。 元の言葉を示し、何を求めているのかを部門と話して決めます。

02今回想定するシステム構成

構成図
部門の採用の要望(Microsoft Forms の回答)
   ▼【トリガー】採用担当が要望を受け取り、エージェントに貼る
Microsoft Copilot(Agent Builder で作る「要員申請の下書きエージェント」)
   │  知識:要員計画(SharePoint のリスト)
   │        等級の定義書、申請書の様式、人物像の書き方の決まり、
   │        注意すべき表現の一覧、職種ごとの過去の人物像(埋め込んだファイル)
   ├──▶ 要員申請書の下書き(書けない欄は「部門に確認」)
   ├──▶ 等級の候補と根拠の文言
   └──▶ 部門への確認事項(1通の文面)
   ▼【採用担当が見直し、部門に1回で問い合わせる】
部門の回答を貼る
   ▼
Microsoft Copilot ── 申請書の仕上げ、求める人物像(必須/歓迎)、注意すべき表現の一覧
   ▼【採用担当と部門長が確かめる】
人事部長・担当役員の承認 → 求人票の作成へ
役割想定する製品代替候補
処理Microsoft Copilot(旧称 Microsoft 365 Copilot。Agent Builder で作る要員申請の下書きエージェント)ChatGPT Enterprise、Gemini、Claude
受付Microsoft Forms(採用の要望)Google フォーム
台帳SharePoint のリスト(要員計画)人事の専用の仕組み
文書Word(要員申請書と人物像の様式)-

新しく足すのは、採用グループ3名の Copilot のライセンスと、エージェントだけです。 要望の受付も要員計画も、今の仕組みをそのまま使います。

エージェントは Agent Builder で作ります。 公式のページでは、知識にはSharePoint のリストを1つまで、端末から上げて埋め込むファイルを20個まで指定できるとされています。要員計画をリストのまま知識に入れられるので、部門の名前から計画の人数と今の人数を引けます。リストは2万行と50MBのテキストまでで、超えると切り詰められ、その旨が応答に書かれるとされています。

等級の定義書や様式は、埋め込んだファイルにします。 埋め込めるのは .docx・.pdf・.pptx・.txt などで、.xlsx は30MBまで、それ以外は512MBまでとされています。職種ごとの過去の人物像の例も、ここに入れます。

「指定した知識だけを使う」設定を有効にします。 Agent Builder の「Only use specified sources」は、指定した知識を優先させる設定で、一般的な知識を完全には止めないとされています。指示の側でも、要望と知識に無いことを書かないよう明記します(第7章)。

03どうやって実装するのか

Step1

処理の起点を決める

採用担当が部門の要望を受け取り、エージェントに貼ることを起点にします。 Forms の回答をそのまま自動でエージェントに流す仕組みにはしません。要望の中には、採用ではなく配置転換で済むものや、すでに別の申請で進んでいるものがあります。 採用担当が最初に一読して、下書きに進むかを決めます。

下書きは2回に分けて作らせます。 1回目は要望だけで作り、足りない項目と確認事項を出させます。2回目は部門の回答を足して仕上げ、人物像まで作らせます。1回で人物像まで作らせると、足りない情報を推し量った人物像ができてしまいます。

要望を受け取った当日のうちに1回目を作ります。 欠員の補充は急ぎのことが多く、確認事項を部門に返すのが早いほど、申請の承認も早まります。

Step2

入力データを集める

データ中身取得元
採用の要望部門、職種、人数、希望の時期、理由、業務の内容、必要なスキル、自由記入Forms の回答(採用担当が貼る)
要員計画部門ごとの今年度の計画の人数、今の人数、退職の予定、計画の外の申請の有無SharePoint のリスト
等級の定義書等級ごとの役割、求める能力、経験の目安埋め込んだファイル
申請書の様式欄の並びと、欄ごとの書き方の決まり埋め込んだファイル
人物像の書き方の決まり必須と歓迎の分け方、職務に関係する能力で書くこと埋め込んだファイル
注意すべき表現の一覧年齢・性別・容姿・出身・家族などに当たる表現の例埋め込んだファイル
過去の人物像職種ごとの、承認された人物像の例埋め込んだファイル

質を決めるのは、2行目の要員計画と4行目の申請書の様式です。 要員計画が無ければ、計画の内か外かが書けません。様式の欄ごとに「何が書かれていれば埋まったとするか」が決まっていなければ、足りない項目を洗い出せません。

申請書の様式は、欄ごとに書き方の決まりを添えておきます。

【要員申請書の様式(欄と書き方の決まり)】
1. 申請の理由:欠員の補充/業務の増加/新しい職種 のどれか。欠員なら退職・異動の時期
2. 業務量の根拠:数字で書く(残業時間、受注の見込み、設備の増設、対応件数など)。数字の出どころ
3. 採用以外の手段の検討:配置転換・派遣・業務の見直しを検討したか、しなかったならその理由
4. 等級と人件費の見込み:等級の候補と、等級の定義のどの文言に当たるか
5. 要員計画との関係:計画の内か外か。外なら、その理由
6. 希望の時期と、遅れた場合の影響
Step3

データの取得方法を決める

取るものどこから何に使うか
要望の本文採用担当が Forms の回答をチャットに貼る様式の欄を埋める材料
計画と今の人数エージェントの知識に、要員計画のリストを指定する計画の内か外か
等級と様式と決まりエージェントに埋め込んだファイル欄の並び、等級の候補、表現の確かめ

要望は、Forms の回答の全項目を貼ります。 自由記入の欄だけを貼ると、人数や時期の欄に書かれていた内容が抜けます。回答の画面から全項目をコピーするか、回答の表の行を貼ります。

要員計画のリストには、部門の名前を Forms の選択肢と同じ表記で持たせます。 「第2工場 製造課」と「第二工場製造課」が混ざると、エージェントは計画の行を引けません。Forms の部門の欄を自由記入ではなく選択肢にして、リストの表記とそろえます。

過去の人物像は、承認されたものだけを入れます。 下書きの段階のものや、条件の表現が残ったものを入れると、エージェントはそれを手本にします。

Step4

AIへ渡す前に整形する

  1. Forms の部門の欄を選択肢にする … 要員計画のリストの表記とそろえます
  2. Forms に業務量の欄を足す … 「業務量の根拠(残業時間、受注の見込みなど数字で)」の欄を設け、必須にはせず、空でも出せるようにします
  3. 要員計画のリストを月初に更新する … 今の人数と退職の予定を人事の記録から写します
  4. 注意すべき表現の一覧を作る … 年齢(「若手」「20代」)、性別(「男性」「女性向き」)、容姿、出身地、家族の状況などの例を並べ、それぞれなぜ注意が要るかを添えます
  5. 過去の人物像を職種ごとに選ぶ … 製造、品質保証、生産技術、設計、営業、管理など、主な職種ごとに承認されたものを1つずつ選びます

2番目を必須にしないのは意図してのことです。 必須にすると、部門は根拠の無い数字を書いて送ってきます。空のまま出してもらい、確認事項として聞くほうが、出どころのある数字が返ってきます。

4番目の一覧は、人事部と法務の担当で作ります。 性別については、募集と採用で性別にかかわりなく均等な機会を与えなければならないと定められています。年齢についても、法律で、厚生労働省令で定めるときは年齢にかかわりなく均等な機会を与えなければならないとされています。どの表現が当たるかは一覧で例を示し、判断は人が行います。

Step5

AIに処理させる

させるのは、要望と知識に書かれていることを様式の欄に並べることと、書けない欄を洗い出すこと、等級の候補と注意すべき表現を示すことです。

欄させること書けないときの扱い
申請の理由要望の理由の欄と自由記入から、3つの区分のどれかと時期を書く区分が読み取れなければ「部門に確認」
業務量の根拠要望に書かれた数字と、その出どころを写す数字が無ければ「部門に確認」
採用以外の手段の検討要望に検討の記述があれば写す記述が無ければ「部門に確認」
等級の候補必要なスキルを等級の定義と照らし、候補と根拠の文言を示す当てられなければ「人事で判断」
要員計画との関係リストから計画の人数と今の人数を引き、内か外かを書く行を引けなければ「計画の行が見つからない」
求める人物像必須と歓迎に分け、職務に関係する能力と経験で書く要望に無い能力を足さない
注意すべき表現一覧に当たる表現を、元の言葉のまま、どの欄にあったかとともに示す-
させないこと理由
業務量の数字を推し量って書く部門が言っていない根拠で申請が通る
採用するかどうかの判断人事部長と担当役員が決める
注意すべき表現を自動で言い換える部門が本当に求めていたことが見えなくなる
要望に無いスキルを人物像に足す採用の基準が要望より厳しくなる
特定の個人を前提にした記述「前任の〇〇さんのような人」を人物像にしない

1行目がいちばん大事です。 申請書は承認の根拠になる文書で、業務量の数字はその中心です。 Copilot は様式の欄を埋めようとして、「残業時間の増加が見込まれる」のような文を作ります。数字が無い欄は空けておくことを、指示で明確にします。

4行目も同じくらい大事です。 過去の人物像を手本にすると、Copilot は手本にあったスキルを今回の人物像にも足します。必須の欄が増えるほど、応募は減ります。 人物像は要望に書かれたスキルから作らせます。

等級の候補は、定義の文言を引用させます。 たとえば等級の定義書に「G2:指示を受けて担当工程の作業を行える」「G3:担当する工程の段取り・調整を一人で行える」「G4:複数の工程を管理し、後輩を指導できる」とあり、要望に「NC旋盤の段取りから任せたい」と書かれていれば、候補はG3で、根拠は「段取り・調整を一人で行える」です。要望に「後輩の指導も」とあればG4も候補に挙がります。 どちらにするかは、人件費の見込みと部門の人員の構成を見て人事の担当が決めます。

人件費の見込みは、エージェントに計算させません。 等級ごとの給与の幅は人事の担当が持つ表から写し、下書きでは「等級の候補が決まったら人事で記入」とします。 給与の表を知識に入れると、エージェントを使える人すべてがその内容に基づく応答を見られるようになるためです。

Step6

指示内容を固定する

エージェントの指示として Agent Builder に書いておく内容です。 採用担当は毎回、要望を貼って「1回目の下書きを作って」と頼むだけにします。

あなたは製造業の人事部の採用担当を手伝い、部門から届いた採用の要望から、
要員申請書と求める人物像の下書きを作る立場です。
貼られた要望と、知識に指定した要員計画のリスト、等級の定義書、申請書の様式、
人物像の書き方の決まり、注意すべき表現の一覧、過去の人物像だけを見てください。
一般的な採用の知識や、要望に無い情報で補わないでください。

【1回目:申請書の下書きと確認事項】
- 申請書の様式の欄ごとに、要望から書けることを書いてください。
- 欄の書き方の決まりを満たす情報が要望に無いときは、その欄を「部門に確認」とし、
  何が足りないかを1行で書いてください。
- 業務量の根拠は、要望に書かれた数字と、その出どころだけを写してください。
  数字を推し量ったり、一般的な目安で書いたりしないでください。
- 要員計画のリストから、この部門の今年度の計画の人数と今の人数を引き、
  計画の内か外かを書いてください。行が見つからないときは「計画の行が見つからない」と書いてください。
- 等級は、必要なスキルの記述と等級の定義書の文言を照らし、候補を1つか2つ挙げ、
  当たる定義の文言を引用してください。当てられないときは「人事で判断」と書いてください。
- 最後に、「部門に確認」とした欄をまとめて、部門への問い合わせの文面を1通作ってください。
  質問は欄の順に番号を付け、答え方の例を添えてください。

【2回目:仕上げと人物像(部門の回答が貼られたとき)】
- 部門の回答で埋まった欄を書き直してください。まだ足りない欄は「部門に確認」のままにしてください。
- 求める人物像を「必須」と「歓迎」に分け、職務に関係する能力と経験で書いてください。
  要望と回答に書かれていないスキルを足さないでください。
- 注意すべき表現の一覧に当たる表現が、要望・回答・下書きのどこかにあれば、
  元の言葉のまま、どこにあったかとともに一覧にしてください。言い換えないでください。

【厳守事項】
- 採用するべきかどうか、人数が妥当かどうかは書かないでください。
- 特定の個人の名前を、求める人物像の手本として書かないでください。

1回目の最後に問い合わせの文面まで作らせるのは、往復を減らすのがこの構成の目的だからです。 欄ごとに「答え方の例」を添えると、部門は「残業は月平均で何時間か、直近3か月の数字で」のように、何を答えればよいかが分かります。

「言い換えないでください」を2回目に書いているのは、何も言わなければ言い換えるからです。 Copilot は表現を整えようとして、「若手」を「意欲的な方」にします。整った文になるほど、元の要望の意図が消え、人が見落とします。

Step7

出力形式を固定する

エージェントには、申請書の様式の欄の順に、表の形で返させます。 申請書は Word の様式に移して承認に回すので、JSON ではなく、採用担当が欄ごとにそのまま貼れる形にします。

【要員申請書(下書き)】第2工場 製造課 NC旋盤オペレーター 1名
| 欄 | 下書き | 状態 |
| 申請の理由 | 欠員の補充(11月末で1名が定年退職) | 要望から |
| 業務量の根拠 | 部門に確認(残業時間や受注の見込みなど、数字の記載が無い) | 部門に確認 |
| 採用以外の手段の検討 | 部門に確認(配置転換・派遣の検討の記載が無い) | 部門に確認 |
| 等級の候補 | G3(「担当する工程の段取り・調整を一人で行える」に当たる) | 要望から・人事で確認 |
| 要員計画との関係 | 計画18名、今の人数18名、11月末で17名。計画の内 | 要員計画から |

【部門への確認事項】
1. 業務量の根拠:直近3か月の課の残業時間の平均、または受注の見込みの変化を数字で教えてください。
2. 採用以外の手段:他課からの配置転換や派遣を検討しましたか。しなかった場合はその理由を教えてください。

【注意すべき表現】(2回目で出力)
| 表現 | あった場所 | 一覧の区分 |
| 「若手が望ましい」 | 要望の自由記入 | 年齢 |

1つ目の理由は、「状態」の列で何が確かめ済みかが分かることです。 「要望から」「要員計画から」「部門に確認」「人事で確認」の4つに分ければ、採用担当はどの欄を自分で確かめるべきかが一目で分かります。

2つ目は、確認事項がそのまま問い合わせになることです。 採用担当は文面を見直して、Teams かメールで部門に送ります。

3つ目は、注意すべき表現が「あった場所」とともに残ることです。 要望の自由記入にあったのか、過去の人物像から紛れたのかで、話す相手が部門か人事部の中かが変わります。

Step8

システムへ連携する

つなぎ先方式内容
Forms の回答採用担当が回答を貼る要望の本文
要員計画エージェントの知識にリストを指定計画と今の人数を引く。書き込まない
部門採用担当が確認事項を Teams かメールで送る1回で聞き切る
申請書・人物像採用担当が Word の様式に移す承認の回付へ

要員計画にはエージェントから書き込みません。 計画の人数を変えるのは承認の後で、人事の担当が行います。

Step9

人が確認する

この構成では、全件を人が確かめます。 申請書は承認の根拠で、人物像は選考の基準になるからです。

  1. 「部門に確認」の欄を見直す … 本当に要望に無いかを、要望の原文で確かめます
  2. 等級の候補を確かめる … 引用された定義の文言が、要望のスキルに当たるかを見ます。等級は人事の担当が決めます
  3. 注意すべき表現の一覧を見る … 当たる表現があれば、部門長と、何を求めているのかを話して書き直します
  4. 人物像の必須の欄を絞る … 要望に無いスキルが入っていないか、必須が多すぎないかを見ます
  5. 部門長が人物像を確かめる … 職務の内容と合っているかを見てもらいます

3番目を省かないでください。 人物像は求人票と面接の評価の基準になり、ここに残った条件は選考の全体に広がります。

目標は、1件あたり20分です。 要望を読んで欄を埋める時間が、下書きの欄と状態を確かめる時間に置き換わります。

Step10

例外に対処する

起きること対応
要望が配置転換で済む内容だった下書きに進まず、部門と人事で配置を検討する
要員計画の行が見つからない部門の表記の違い。Forms の選択肢とリストの表記をそろえる
新しい職種で、過去の人物像も等級の当てはめも無い等級は「人事で判断」。人物像は部門と面談して作る
部門の回答でも業務量の数字が出ない「部門に確認」のまま承認に回さない。部門長と面談する
複数の職種をまとめた要望職種ごとに分けて下書きを作る
要員計画のリストが上限を超えた切り詰められる。今年度の行だけのリストにする

4行目は、無理に埋めないことが大事です。 数字の無いまま申請を通すと、次の年度の要員計画の見直しで、根拠をたどれなくなります。

3行目の新しい職種は、年に数件ですが手間がかかります。 社内に前例が無いので、等級の定義の言葉にも当てはまりにくく、エージェントは「人事で判断」を多く返します。 これは失敗ではなく、正しい振る舞いです。部門と面談して人物像を作り、承認されたものを過去の人物像のファイルに足せば、次の同じ職種の要望からは下書きが作れるようになります。

Step11

記録を残す

  • 要望の原文と、1回目・2回目の下書きの全文
  • 部門への確認事項と、部門の回答
  • 採用担当が直した箇所 … 等級の候補を変えた、必須のスキルを外した、など
  • 注意すべき表現と、それをどう書き直したか
  • 承認された申請書と人物像の最終版

4行目は、注意すべき表現の一覧を育てる材料になります。 一覧に無かった表現が見つかれば、足します。同じ部門で同じ表現が続けば、部門長に考え方を説明する機会にします。

保存先は、採用グループの SharePoint の申請ごとのフォルダにします。 エージェントとの会話の履歴だけに頼らず、下書きと確認事項を Word のファイルとして残します。 半年後に「この申請はどんな根拠で承認されたのか」と聞かれたときに、要望の原文、部門の回答、承認された申請書を並べて示せるようにしておきます。

04実装レベルの3段階

最小構成:Copilot Chat に様式と一覧を貼り、要望から下書きと確認事項を作らせる / 1件ごとの下書きと確認事項
半自動化:上記+要員計画のリストと等級の定義・様式・決まりを知識に持つエージェントで作る / 計画との照合、等級の候補、人物像、注意すべき表現
本格構成:上記+Forms の回答を Power Automate で採用担当の Teams に届け、承認の回付と要員計画の更新を自動にする / 受付から承認の回付まで

本記事の想定は半自動化です。 1件50分が20分になるのは、欄を埋める作業と、足りない項目を洗い出す作業が下書きに移るからです。 本格構成でも、エージェントに貼る操作は採用担当が行います。 要望を一読して、下書きに進むかを決める段階は残します。 本格構成で足す価値が大きいのは、承認の回付と要員計画の更新です。 採用担当が申請書を確定させたら、Power Automate で人事部長と担当役員に承認の依頼を送り、承認されたら要員計画のリストに「申請中」から「承認済み」の印を付けます。 エージェントが次の要望で計画を引いたときに、承認済みの申請を含めた人数で内か外かを判断できるようになります。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
3 名
月間件数
30 件
1件あたり現在時間
50 分
1件あたり導入後時間
20 分
現在  30件 × 50分 ÷ 60 = 25 時間/月
導入後 30件 × 20分 ÷ 60 = 10 時間/月
月間削減時間
15h
削減率
60%
年間削減時間
180h
年間金額換算(時間単価4,000円)
72万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. 工場・拠点・本社に多くの部門があり、欠員の補充や業務の増加のたびに部門から採用の要望が届き、人事部の採用担当が要望を聞き取って要員申請書と求める人物像を書き起こしている製造業・物流業・建設業など。部門の要望が「とにかく1人ほしい」「経験者で若い人」のような書き方で届き、申請に要る業務量の根拠や採用以外の手段の検討を聞き直す往復が多い場合。人事部の担当者が Microsoft Copilot(旧称 Microsoft 365 Copilot)を使える場合。
向いていない
  1. 採用の要望が年に数件で、人事部が部門と直接話して決めれば足りる場合。要員の計画と申請を人事の専用の仕組みの中で完結させており、文書の下書きを別に作る余地が無い場合。部門の要望をメモの形で受け取らず、口頭だけで決めている場合。なお、採用するかどうか、何人をどの等級で採るかの判断、求める人物像が公正な採用の考え方に合うかの最終の判断は、この構成では代替できません。

07最小構成で試す方法

  1. 先月の採用の要望から5件を選ぶ(うち1件は、部門と3往復以上やり取りした要望、1件は人物像に年齢か性別の表現が残っていた要望を入れる)
  2. Copilot Chat に、申請書の様式と注意すべき表現の一覧を貼る
  3. 要望を1件ずつ貼り、第7章の1回目の指示で下書きと確認事項を作らせる
  4. 出てきた確認事項を、当時の部門とのやり取りと比べる
  5. 当時の回答を貼って2回目を作らせ、注意すべき表現が出るかを見る

3往復した要望は必ず入れてください。 当時の3回分の質問が、下書きの確認事項の1通に入っているかを確かめます。

出てきた内容判断
当時の質問が1通の確認事項にそろったエージェントに進む
業務量の根拠に推し量った数字が入った指示の「推し量らない」が効いていない。書き方で直る
注意すべき表現が言い換えられて消えた「言い換えない」を指示に足す

最小構成では、要望に個人の名前や事情が書かれていれば、貼る前に消します。 試しの段階はエージェントを作っておらず、Copilot Chat の会話に要望を直接貼るためです。消すのは退職する人の名前と事情、部門の個人への評価の記述で、業務量や人数の記述は残します。消した後の要望でも確認事項が当時の質問とそろえば、名前は下書きに要らないということが分かります。

08実装時につまずきやすいポイント

問題対策
業務量の根拠に推し量った文が入る数字が無ければ「部門に確認」と指示する
注意すべき表現が言い換えられて消える「言い換えない」と指示し、元の言葉で一覧にさせる
過去の人物像のスキルが足される要望と回答に無いスキルを足さないと指示する
要員計画の行が引けないForms の部門の欄を選択肢にしてリストとそろえる
1回で人物像まで作って推し量りが増える2回に分けて作る
一般的な採用の知識で補われる「Only use specified sources」と、指示の「補わない」を両方入れる
エージェントを広く共有して要望の内容が見える採用グループだけに共有する

上の2行が、この構成の失敗のほとんどです。 どちらも、整った文書にしようとして元の情報が消える失敗です。整えるのは人で、エージェントには欠けと元の言葉を残させます。

3行目は、運用を続けるほど起きやすくなります。 過去の人物像のファイルを増やすと、手本の数だけ足されるスキルの候補も増えます。職種ごとに手本は1つに絞り、新しいものが承認されたら古いものと入れ替えます。 半年ごとに、必須の欄の項目数が増えていないかを数えて確かめると、人物像が少しずつ厳しくなっていくのを止められます。

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: 部門の要員の状況、退職や異動の予定、人件費の見込み、等級の定義です。退職の予定は、本人がまだ周りに伝えていない情報であることがあります。

  1. エージェントの共有を採用グループに絞る … 公式のページでは、埋め込んだファイルの内容に基づく応答は、エージェントを使えるすべての人が見られるとされ、情報バリアも埋め込んだファイルには効かないとされています。等級の定義や過去の人物像を入れたエージェントは、採用グループの3名だけに共有します
  2. 退職の予定を要望に書かせすぎない … 要望には「11月末で1名減」とだけ書いてもらい、本人の名前や事情を書かない決まりにします
  3. 秘密度ラベルを確かめる … ラベルで抽出の権利が無効になっているファイルを埋め込むと、エージェントの作成が失敗するとされています。人事の文書のラベルの設定を、作る前に確かめます
  4. データの扱いを確かめておく … 公式のページでは、プロンプト、応答、Microsoft Graph で参照したデータは基盤のモデルの学習に使われないとされています。また、EU 以外の顧客のクエリは米国、EU、その他の地域で処理されうるとされています
  5. 採用の判断を代替させない … 採るかどうか、等級、人物像が公正な採用の考え方に合うかは、人事部と部門長が決めます

誤りが起きた場合のリスクは、根拠の無い数字で申請が通ることと、人物像に年齢・性別の条件が残ることの2つです。 前者は「部門に確認」を空けたままにすることで、後者は注意すべき表現を元の言葉で示し人が直すことで防ぎます。

10まず何から始めるか

1週目:様式と一覧を整える

要員申請書の様式に、欄ごとの書き方の決まりを書き足します。人事部と法務の担当で、注意すべき表現の一覧を作ります。

2週目:5件で試す

先月の要望を5件選び、Copilot Chat で1回目と2回目の下書きを作ります。当時の往復の質問が1通の確認事項にそろうか、注意すべき表現が言い換えられずに出るかを最優先で見ます。

3週目:Forms と要員計画を直す

Forms の部門の欄を選択肢にし、業務量の根拠の欄を足します。要員計画のリストの部門の表記をそろえ、今の人数を更新します。

4週目:エージェントを作る

Agent Builder で要員申請の下書きエージェントを作り、指示、等級の定義、様式、決まり、一覧、過去の人物像を入れ、要員計画のリストを知識に指定して、採用グループの3名にだけ共有します。

2か月目: すべての要望で使い、部門との往復の回数を数えます。3か月目以降: 1件50分が何分になったかを実測し、部門との往復が1回で済むことが多くなった時点で、この構成は完成です。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-10-14/最終更新:2026-10-14
確認した内容情報源確認日
Agent Builder の知識に SharePoint のリストを1つまで、端末から上げて埋め込むファイルを20個まで指定できること。リストが2万行と50MBのテキストまでで、超えると切り詰められ応答にその旨が書かれること。埋め込めるファイルの種類と、.xlsx が30MB、.docx・.pdf などが512MBまでであること。埋め込んだファイルの内容に基づく応答はエージェントを使えるすべての人が見られ、情報バリアが効かないこと。抽出の権利が無効のラベルのファイルを埋め込むと作成が失敗すること。「Only use specified sources」は指定した知識を優先させる設定で一般的な知識を完全には止めないことMicrosoft Learn: Add knowledge sources to an agent in Agent Builder2026-10-14
Microsoft 365 Copilot が Microsoft Copilot に改称されたこと。プロンプト・応答・Microsoft Graph で参照したデータが基盤のモデルの学習に使われないこと。EU 以外の顧客のクエリが米国・EU・その他の地域で処理されうることMicrosoft Learn: Data, Privacy, and Security for Microsoft Copilot2026-10-14
事業主は、労働者の募集及び採用について、その性別にかかわりなく均等な機会を与えなければならないこと(第5条)e-Gov 法令API: 雇用の分野における男女の均等な機会及び待遇の確保等に関する法律2026-10-14
事業主は、厚生労働省令で定めるときは、労働者の募集及び採用について、その年齢にかかわりなく均等な機会を与えなければならないこと(第9条)e-Gov 法令API: 労働施策の総合的な推進並びに労働者の雇用の安定及び職業生活の充実等に関する法律2026-10-14

どの表現が募集・採用の条件として許されないか、例外に当たるかは、人事部と法務の担当、必要に応じて社会保険労務士に確かめてください。 本記事は公開されている製品の仕様と法令の条文で確認できた範囲だけを扱っています。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-1496)についてのご相談はこちらから。

AI活用について相談する
目次