各部門の採用の要望(業務量・欠員・必要なスキル)のメモから、要員申請書と求める人物像の下書きを作る
部門から届く採用の要望のメモを、要員計画の表と等級の定義に照らして、要員申請書と求める人物像の下書きにします。あわせて、申請に足りない情報と、年齢や性別の条件に当たる表現を一覧にします。
- 生成AI
- ChatGPT/Claude/Gemini/Microsoft Copilot
- 対象業界
- IT・SaaS/建設/物流/製造
- 対象部門
- 人事/採用
- 対象業務
- 書類作成
- 主な課題
- 属人化している/書類作成に時間がかかる/確認ミスが多い
- AIで行う処理
- 生成
- 主な効果
- 品質標準化/対応スピード向上/工数削減
- 導入難易度
- ★☆☆☆☆
- 実装レベル
- 半自動化
- 費用感
- SaaS追加(小)
- 人間の確認
- 必須
01導入前 / 導入後の業務フロー
- 部門が Forms で採用の要望を出す
- 採用担当が要望を読み、要員計画の表でその部門の計画の人数と今の人数を確かめる
- 申請書に要る項目のうち足りないもの(業務量の根拠、採用以外の手段の検討、等級)を部門に聞く
- 部門の回答を待ち、申請書を Word の様式で書き起こす
- 等級の定義書を見て、要望のスキルに合う等級を当て、人件費の見込みを書く
- 申請の承認の後、求める人物像を必須と歓迎に分けて書く
- 人物像を部門長に確かめてもらい、求人票の作成に回す
- 人部門が Forms で採用の要望を出す(これまでと同じ)
- 人採用担当が、要望の回答を「要員申請の下書きエージェント」に貼り、申請書の下書きを頼む
- 自動エージェントが、要員計画のリストからその部門の計画の人数と今の人数を引く
- 自動エージェントが、申請書の様式の欄ごとに要望から書けることを書き、書けない欄を「部門に確認」とする
- 自動エージェントが、等級の定義と照らして等級の候補と根拠の文言を示す
- 自動エージェントが、部門への確認事項を1通の問い合わせの文面にまとめる
- 人採用担当が下書きと確認事項を見直し、部門に1回で問い合わせる
- 人部門の回答を貼り、エージェントに申請書を仕上げさせ、人物像の下書きと注意すべき表現の一覧を作らせる
- 人採用担当が等級と表現を確かめ、部門長に人物像を確かめてもらい、申請の承認に回す
各工程の詳しい説明を読む
- 部門が Forms で採用の要望を出す
- 採用担当が要望を読み、要員計画の表でその部門の計画の人数と今の人数を確かめる
- 申請書に要る項目のうち足りないもの(業務量の根拠、採用以外の手段の検討、等級)を部門に聞く
- 部門の回答を待ち、申請書を Word の様式で書き起こす
- 等級の定義書を見て、要望のスキルに合う等級を当て、人件費の見込みを書く
- 申請の承認の後、求める人物像を必須と歓迎に分けて書く
- 人物像を部門長に確かめてもらい、求人票の作成に回す
(a)聞き直しが何往復にもなる。 3番で足りない項目を聞いても、部門の回答で別の項目の不足が分かり、また聞きます。欠員の補充で急いでいる部門ほど、往復のたびに不満が溜まります。
(b)申請書の書き方が担当で違う。 ある担当は業務量の根拠を残業時間で書き、別の担当は受注の見込みで書きます。承認する人事部長から見ると、申請ごとに見る場所が違い、比べられません。
(c)人物像に条件が紛れ込む。 部門のメモの「若手」「体力のある男性」が、急いで書いた人物像にそのまま残ることがあります。求人票の段階で気づけばよいのですが、面接の評価の基準にまで残ると、選考そのものが偏ります。
(d)等級の当てはめがぶれる。 要望のスキルを等級の定義に当てる判断が担当によって違い、同じような要望で等級が1つずれた申請が出ます。
- 【人】 部門が Forms で採用の要望を出す(これまでと同じ)
- 【人】 採用担当が、要望の回答を「要員申請の下書きエージェント」に貼り、申請書の下書きを頼む
- 【自動】 エージェントが、要員計画のリストからその部門の計画の人数と今の人数を引く
- 【自動】 エージェントが、申請書の様式の欄ごとに要望から書けることを書き、書けない欄を「部門に確認」とする
- 【自動】 エージェントが、等級の定義と照らして等級の候補と根拠の文言を示す
- 【自動】 エージェントが、部門への確認事項を1通の問い合わせの文面にまとめる
- 【人】 採用担当が下書きと確認事項を見直し、部門に1回で問い合わせる
- 【人】 部門の回答を貼り、エージェントに申請書を仕上げさせ、人物像の下書きと注意すべき表現の一覧を作らせる
- 【人】 採用担当が等級と表現を確かめ、部門長に人物像を確かめてもらい、申請の承認に回す
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どうやって実装するのか
処理の起点を決める
採用担当が部門の要望を受け取り、エージェントに貼ることを起点にします。 Forms の回答をそのまま自動でエージェントに流す仕組みにはしません。要望の中には、採用ではなく配置転換で済むものや、すでに別の申請で進んでいるものがあります。 採用担当が最初に一読して、下書きに進むかを決めます。
下書きは2回に分けて作らせます。 1回目は要望だけで作り、足りない項目と確認事項を出させます。2回目は部門の回答を足して仕上げ、人物像まで作らせます。1回で人物像まで作らせると、足りない情報を推し量った人物像ができてしまいます。
要望を受け取った当日のうちに1回目を作ります。 欠員の補充は急ぎのことが多く、確認事項を部門に返すのが早いほど、申請の承認も早まります。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 採用の要望 | 部門、職種、人数、希望の時期、理由、業務の内容、必要なスキル、自由記入 | Forms の回答(採用担当が貼る) |
| 要員計画 | 部門ごとの今年度の計画の人数、今の人数、退職の予定、計画の外の申請の有無 | SharePoint のリスト |
| 等級の定義書 | 等級ごとの役割、求める能力、経験の目安 | 埋め込んだファイル |
| 申請書の様式 | 欄の並びと、欄ごとの書き方の決まり | 埋め込んだファイル |
| 人物像の書き方の決まり | 必須と歓迎の分け方、職務に関係する能力で書くこと | 埋め込んだファイル |
| 注意すべき表現の一覧 | 年齢・性別・容姿・出身・家族などに当たる表現の例 | 埋め込んだファイル |
| 過去の人物像 | 職種ごとの、承認された人物像の例 | 埋め込んだファイル |
質を決めるのは、2行目の要員計画と4行目の申請書の様式です。 要員計画が無ければ、計画の内か外かが書けません。様式の欄ごとに「何が書かれていれば埋まったとするか」が決まっていなければ、足りない項目を洗い出せません。
申請書の様式は、欄ごとに書き方の決まりを添えておきます。
【要員申請書の様式(欄と書き方の決まり)】
1. 申請の理由:欠員の補充/業務の増加/新しい職種 のどれか。欠員なら退職・異動の時期
2. 業務量の根拠:数字で書く(残業時間、受注の見込み、設備の増設、対応件数など)。数字の出どころ
3. 採用以外の手段の検討:配置転換・派遣・業務の見直しを検討したか、しなかったならその理由
4. 等級と人件費の見込み:等級の候補と、等級の定義のどの文言に当たるか
5. 要員計画との関係:計画の内か外か。外なら、その理由
6. 希望の時期と、遅れた場合の影響 データの取得方法を決める
| 取るもの | どこから | 何に使うか |
|---|---|---|
| 要望の本文 | 採用担当が Forms の回答をチャットに貼る | 様式の欄を埋める材料 |
| 計画と今の人数 | エージェントの知識に、要員計画のリストを指定する | 計画の内か外か |
| 等級と様式と決まり | エージェントに埋め込んだファイル | 欄の並び、等級の候補、表現の確かめ |
要望は、Forms の回答の全項目を貼ります。 自由記入の欄だけを貼ると、人数や時期の欄に書かれていた内容が抜けます。回答の画面から全項目をコピーするか、回答の表の行を貼ります。
要員計画のリストには、部門の名前を Forms の選択肢と同じ表記で持たせます。 「第2工場 製造課」と「第二工場製造課」が混ざると、エージェントは計画の行を引けません。Forms の部門の欄を自由記入ではなく選択肢にして、リストの表記とそろえます。
過去の人物像は、承認されたものだけを入れます。 下書きの段階のものや、条件の表現が残ったものを入れると、エージェントはそれを手本にします。
AIへ渡す前に整形する
- Forms の部門の欄を選択肢にする … 要員計画のリストの表記とそろえます
- Forms に業務量の欄を足す … 「業務量の根拠(残業時間、受注の見込みなど数字で)」の欄を設け、必須にはせず、空でも出せるようにします
- 要員計画のリストを月初に更新する … 今の人数と退職の予定を人事の記録から写します
- 注意すべき表現の一覧を作る … 年齢(「若手」「20代」)、性別(「男性」「女性向き」)、容姿、出身地、家族の状況などの例を並べ、それぞれなぜ注意が要るかを添えます
- 過去の人物像を職種ごとに選ぶ … 製造、品質保証、生産技術、設計、営業、管理など、主な職種ごとに承認されたものを1つずつ選びます
2番目を必須にしないのは意図してのことです。 必須にすると、部門は根拠の無い数字を書いて送ってきます。空のまま出してもらい、確認事項として聞くほうが、出どころのある数字が返ってきます。
4番目の一覧は、人事部と法務の担当で作ります。 性別については、募集と採用で性別にかかわりなく均等な機会を与えなければならないと定められています。年齢についても、法律で、厚生労働省令で定めるときは年齢にかかわりなく均等な機会を与えなければならないとされています。どの表現が当たるかは一覧で例を示し、判断は人が行います。
AIに処理させる
させるのは、要望と知識に書かれていることを様式の欄に並べることと、書けない欄を洗い出すこと、等級の候補と注意すべき表現を示すことです。
| 欄 | させること | 書けないときの扱い |
|---|---|---|
| 申請の理由 | 要望の理由の欄と自由記入から、3つの区分のどれかと時期を書く | 区分が読み取れなければ「部門に確認」 |
| 業務量の根拠 | 要望に書かれた数字と、その出どころを写す | 数字が無ければ「部門に確認」 |
| 採用以外の手段の検討 | 要望に検討の記述があれば写す | 記述が無ければ「部門に確認」 |
| 等級の候補 | 必要なスキルを等級の定義と照らし、候補と根拠の文言を示す | 当てられなければ「人事で判断」 |
| 要員計画との関係 | リストから計画の人数と今の人数を引き、内か外かを書く | 行を引けなければ「計画の行が見つからない」 |
| 求める人物像 | 必須と歓迎に分け、職務に関係する能力と経験で書く | 要望に無い能力を足さない |
| 注意すべき表現 | 一覧に当たる表現を、元の言葉のまま、どの欄にあったかとともに示す | - |
| させないこと | 理由 |
|---|---|
| 業務量の数字を推し量って書く | 部門が言っていない根拠で申請が通る |
| 採用するかどうかの判断 | 人事部長と担当役員が決める |
| 注意すべき表現を自動で言い換える | 部門が本当に求めていたことが見えなくなる |
| 要望に無いスキルを人物像に足す | 採用の基準が要望より厳しくなる |
| 特定の個人を前提にした記述 | 「前任の〇〇さんのような人」を人物像にしない |
1行目がいちばん大事です。 申請書は承認の根拠になる文書で、業務量の数字はその中心です。 Copilot は様式の欄を埋めようとして、「残業時間の増加が見込まれる」のような文を作ります。数字が無い欄は空けておくことを、指示で明確にします。
4行目も同じくらい大事です。 過去の人物像を手本にすると、Copilot は手本にあったスキルを今回の人物像にも足します。必須の欄が増えるほど、応募は減ります。 人物像は要望に書かれたスキルから作らせます。
等級の候補は、定義の文言を引用させます。 たとえば等級の定義書に「G2:指示を受けて担当工程の作業を行える」「G3:担当する工程の段取り・調整を一人で行える」「G4:複数の工程を管理し、後輩を指導できる」とあり、要望に「NC旋盤の段取りから任せたい」と書かれていれば、候補はG3で、根拠は「段取り・調整を一人で行える」です。要望に「後輩の指導も」とあればG4も候補に挙がります。 どちらにするかは、人件費の見込みと部門の人員の構成を見て人事の担当が決めます。
人件費の見込みは、エージェントに計算させません。 等級ごとの給与の幅は人事の担当が持つ表から写し、下書きでは「等級の候補が決まったら人事で記入」とします。 給与の表を知識に入れると、エージェントを使える人すべてがその内容に基づく応答を見られるようになるためです。
指示内容を固定する
エージェントの指示として Agent Builder に書いておく内容です。 採用担当は毎回、要望を貼って「1回目の下書きを作って」と頼むだけにします。
あなたは製造業の人事部の採用担当を手伝い、部門から届いた採用の要望から、
要員申請書と求める人物像の下書きを作る立場です。
貼られた要望と、知識に指定した要員計画のリスト、等級の定義書、申請書の様式、
人物像の書き方の決まり、注意すべき表現の一覧、過去の人物像だけを見てください。
一般的な採用の知識や、要望に無い情報で補わないでください。
【1回目:申請書の下書きと確認事項】
- 申請書の様式の欄ごとに、要望から書けることを書いてください。
- 欄の書き方の決まりを満たす情報が要望に無いときは、その欄を「部門に確認」とし、
何が足りないかを1行で書いてください。
- 業務量の根拠は、要望に書かれた数字と、その出どころだけを写してください。
数字を推し量ったり、一般的な目安で書いたりしないでください。
- 要員計画のリストから、この部門の今年度の計画の人数と今の人数を引き、
計画の内か外かを書いてください。行が見つからないときは「計画の行が見つからない」と書いてください。
- 等級は、必要なスキルの記述と等級の定義書の文言を照らし、候補を1つか2つ挙げ、
当たる定義の文言を引用してください。当てられないときは「人事で判断」と書いてください。
- 最後に、「部門に確認」とした欄をまとめて、部門への問い合わせの文面を1通作ってください。
質問は欄の順に番号を付け、答え方の例を添えてください。
【2回目:仕上げと人物像(部門の回答が貼られたとき)】
- 部門の回答で埋まった欄を書き直してください。まだ足りない欄は「部門に確認」のままにしてください。
- 求める人物像を「必須」と「歓迎」に分け、職務に関係する能力と経験で書いてください。
要望と回答に書かれていないスキルを足さないでください。
- 注意すべき表現の一覧に当たる表現が、要望・回答・下書きのどこかにあれば、
元の言葉のまま、どこにあったかとともに一覧にしてください。言い換えないでください。
【厳守事項】
- 採用するべきかどうか、人数が妥当かどうかは書かないでください。
- 特定の個人の名前を、求める人物像の手本として書かないでください。
1回目の最後に問い合わせの文面まで作らせるのは、往復を減らすのがこの構成の目的だからです。 欄ごとに「答え方の例」を添えると、部門は「残業は月平均で何時間か、直近3か月の数字で」のように、何を答えればよいかが分かります。
「言い換えないでください」を2回目に書いているのは、何も言わなければ言い換えるからです。 Copilot は表現を整えようとして、「若手」を「意欲的な方」にします。整った文になるほど、元の要望の意図が消え、人が見落とします。
出力形式を固定する
エージェントには、申請書の様式の欄の順に、表の形で返させます。 申請書は Word の様式に移して承認に回すので、JSON ではなく、採用担当が欄ごとにそのまま貼れる形にします。
【要員申請書(下書き)】第2工場 製造課 NC旋盤オペレーター 1名
| 欄 | 下書き | 状態 |
| 申請の理由 | 欠員の補充(11月末で1名が定年退職) | 要望から |
| 業務量の根拠 | 部門に確認(残業時間や受注の見込みなど、数字の記載が無い) | 部門に確認 |
| 採用以外の手段の検討 | 部門に確認(配置転換・派遣の検討の記載が無い) | 部門に確認 |
| 等級の候補 | G3(「担当する工程の段取り・調整を一人で行える」に当たる) | 要望から・人事で確認 |
| 要員計画との関係 | 計画18名、今の人数18名、11月末で17名。計画の内 | 要員計画から |
【部門への確認事項】
1. 業務量の根拠:直近3か月の課の残業時間の平均、または受注の見込みの変化を数字で教えてください。
2. 採用以外の手段:他課からの配置転換や派遣を検討しましたか。しなかった場合はその理由を教えてください。
【注意すべき表現】(2回目で出力)
| 表現 | あった場所 | 一覧の区分 |
| 「若手が望ましい」 | 要望の自由記入 | 年齢 |
1つ目の理由は、「状態」の列で何が確かめ済みかが分かることです。 「要望から」「要員計画から」「部門に確認」「人事で確認」の4つに分ければ、採用担当はどの欄を自分で確かめるべきかが一目で分かります。
2つ目は、確認事項がそのまま問い合わせになることです。 採用担当は文面を見直して、Teams かメールで部門に送ります。
3つ目は、注意すべき表現が「あった場所」とともに残ることです。 要望の自由記入にあったのか、過去の人物像から紛れたのかで、話す相手が部門か人事部の中かが変わります。
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| Forms の回答 | 採用担当が回答を貼る | 要望の本文 |
| 要員計画 | エージェントの知識にリストを指定 | 計画と今の人数を引く。書き込まない |
| 部門 | 採用担当が確認事項を Teams かメールで送る | 1回で聞き切る |
| 申請書・人物像 | 採用担当が Word の様式に移す | 承認の回付へ |
要員計画にはエージェントから書き込みません。 計画の人数を変えるのは承認の後で、人事の担当が行います。
人が確認する
この構成では、全件を人が確かめます。 申請書は承認の根拠で、人物像は選考の基準になるからです。
- 「部門に確認」の欄を見直す … 本当に要望に無いかを、要望の原文で確かめます
- 等級の候補を確かめる … 引用された定義の文言が、要望のスキルに当たるかを見ます。等級は人事の担当が決めます
- 注意すべき表現の一覧を見る … 当たる表現があれば、部門長と、何を求めているのかを話して書き直します
- 人物像の必須の欄を絞る … 要望に無いスキルが入っていないか、必須が多すぎないかを見ます
- 部門長が人物像を確かめる … 職務の内容と合っているかを見てもらいます
3番目を省かないでください。 人物像は求人票と面接の評価の基準になり、ここに残った条件は選考の全体に広がります。
目標は、1件あたり20分です。 要望を読んで欄を埋める時間が、下書きの欄と状態を確かめる時間に置き換わります。
例外に対処する
| 起きること | 対応 |
|---|---|
| 要望が配置転換で済む内容だった | 下書きに進まず、部門と人事で配置を検討する |
| 要員計画の行が見つからない | 部門の表記の違い。Forms の選択肢とリストの表記をそろえる |
| 新しい職種で、過去の人物像も等級の当てはめも無い | 等級は「人事で判断」。人物像は部門と面談して作る |
| 部門の回答でも業務量の数字が出ない | 「部門に確認」のまま承認に回さない。部門長と面談する |
| 複数の職種をまとめた要望 | 職種ごとに分けて下書きを作る |
| 要員計画のリストが上限を超えた | 切り詰められる。今年度の行だけのリストにする |
4行目は、無理に埋めないことが大事です。 数字の無いまま申請を通すと、次の年度の要員計画の見直しで、根拠をたどれなくなります。
3行目の新しい職種は、年に数件ですが手間がかかります。 社内に前例が無いので、等級の定義の言葉にも当てはまりにくく、エージェントは「人事で判断」を多く返します。 これは失敗ではなく、正しい振る舞いです。部門と面談して人物像を作り、承認されたものを過去の人物像のファイルに足せば、次の同じ職種の要望からは下書きが作れるようになります。
記録を残す
- 要望の原文と、1回目・2回目の下書きの全文
- 部門への確認事項と、部門の回答
- 採用担当が直した箇所 … 等級の候補を変えた、必須のスキルを外した、など
- 注意すべき表現と、それをどう書き直したか
- 承認された申請書と人物像の最終版
4行目は、注意すべき表現の一覧を育てる材料になります。 一覧に無かった表現が見つかれば、足します。同じ部門で同じ表現が続けば、部門長に考え方を説明する機会にします。
保存先は、採用グループの SharePoint の申請ごとのフォルダにします。 エージェントとの会話の履歴だけに頼らず、下書きと確認事項を Word のファイルとして残します。 半年後に「この申請はどんな根拠で承認されたのか」と聞かれたときに、要望の原文、部門の回答、承認された申請書を並べて示せるようにしておきます。
04実装レベルの3段階
本記事の想定は半自動化です。 1件50分が20分になるのは、欄を埋める作業と、足りない項目を洗い出す作業が下書きに移るからです。 本格構成でも、エージェントに貼る操作は採用担当が行います。 要望を一読して、下書きに進むかを決める段階は残します。 本格構成で足す価値が大きいのは、承認の回付と要員計画の更新です。 採用担当が申請書を確定させたら、Power Automate で人事部長と担当役員に承認の依頼を送り、承認されたら要員計画のリストに「申請中」から「承認済み」の印を付けます。 エージェントが次の要望で計画を引いたときに、承認済みの申請を含めた人数で内か外かを判断できるようになります。
05工数削減シミュレーション
導入後 30件 × 20分 ÷ 60 = 10 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 工場・拠点・本社に多くの部門があり、欠員の補充や業務の増加のたびに部門から採用の要望が届き、人事部の採用担当が要望を聞き取って要員申請書と求める人物像を書き起こしている製造業・物流業・建設業など。部門の要望が「とにかく1人ほしい」「経験者で若い人」のような書き方で届き、申請に要る業務量の根拠や採用以外の手段の検討を聞き直す往復が多い場合。人事部の担当者が Microsoft Copilot(旧称 Microsoft 365 Copilot)を使える場合。
- 採用の要望が年に数件で、人事部が部門と直接話して決めれば足りる場合。要員の計画と申請を人事の専用の仕組みの中で完結させており、文書の下書きを別に作る余地が無い場合。部門の要望をメモの形で受け取らず、口頭だけで決めている場合。なお、採用するかどうか、何人をどの等級で採るかの判断、求める人物像が公正な採用の考え方に合うかの最終の判断は、この構成では代替できません。
07最小構成で試す方法
- 先月の採用の要望から5件を選ぶ(うち1件は、部門と3往復以上やり取りした要望、1件は人物像に年齢か性別の表現が残っていた要望を入れる)
- Copilot Chat に、申請書の様式と注意すべき表現の一覧を貼る
- 要望を1件ずつ貼り、第7章の1回目の指示で下書きと確認事項を作らせる
- 出てきた確認事項を、当時の部門とのやり取りと比べる
- 当時の回答を貼って2回目を作らせ、注意すべき表現が出るかを見る
3往復した要望は必ず入れてください。 当時の3回分の質問が、下書きの確認事項の1通に入っているかを確かめます。
| 出てきた内容 | 判断 |
|---|---|
| 当時の質問が1通の確認事項にそろった | エージェントに進む |
| 業務量の根拠に推し量った数字が入った | 指示の「推し量らない」が効いていない。書き方で直る |
| 注意すべき表現が言い換えられて消えた | 「言い換えない」を指示に足す |
最小構成では、要望に個人の名前や事情が書かれていれば、貼る前に消します。 試しの段階はエージェントを作っておらず、Copilot Chat の会話に要望を直接貼るためです。消すのは退職する人の名前と事情、部門の個人への評価の記述で、業務量や人数の記述は残します。消した後の要望でも確認事項が当時の質問とそろえば、名前は下書きに要らないということが分かります。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 業務量の根拠に推し量った文が入る | 数字が無ければ「部門に確認」と指示する |
| 注意すべき表現が言い換えられて消える | 「言い換えない」と指示し、元の言葉で一覧にさせる |
| 過去の人物像のスキルが足される | 要望と回答に無いスキルを足さないと指示する |
| 要員計画の行が引けない | Forms の部門の欄を選択肢にしてリストとそろえる |
| 1回で人物像まで作って推し量りが増える | 2回に分けて作る |
| 一般的な採用の知識で補われる | 「Only use specified sources」と、指示の「補わない」を両方入れる |
| エージェントを広く共有して要望の内容が見える | 採用グループだけに共有する |
上の2行が、この構成の失敗のほとんどです。 どちらも、整った文書にしようとして元の情報が消える失敗です。整えるのは人で、エージェントには欠けと元の言葉を残させます。
3行目は、運用を続けるほど起きやすくなります。 過去の人物像のファイルを増やすと、手本の数だけ足されるスキルの候補も増えます。職種ごとに手本は1つに絞り、新しいものが承認されたら古いものと入れ替えます。 半年ごとに、必須の欄の項目数が増えていないかを数えて確かめると、人物像が少しずつ厳しくなっていくのを止められます。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 部門の要員の状況、退職や異動の予定、人件費の見込み、等級の定義です。退職の予定は、本人がまだ周りに伝えていない情報であることがあります。
- エージェントの共有を採用グループに絞る … 公式のページでは、埋め込んだファイルの内容に基づく応答は、エージェントを使えるすべての人が見られるとされ、情報バリアも埋め込んだファイルには効かないとされています。等級の定義や過去の人物像を入れたエージェントは、採用グループの3名だけに共有します
- 退職の予定を要望に書かせすぎない … 要望には「11月末で1名減」とだけ書いてもらい、本人の名前や事情を書かない決まりにします
- 秘密度ラベルを確かめる … ラベルで抽出の権利が無効になっているファイルを埋め込むと、エージェントの作成が失敗するとされています。人事の文書のラベルの設定を、作る前に確かめます
- データの扱いを確かめておく … 公式のページでは、プロンプト、応答、Microsoft Graph で参照したデータは基盤のモデルの学習に使われないとされています。また、EU 以外の顧客のクエリは米国、EU、その他の地域で処理されうるとされています
- 採用の判断を代替させない … 採るかどうか、等級、人物像が公正な採用の考え方に合うかは、人事部と部門長が決めます
誤りが起きた場合のリスクは、根拠の無い数字で申請が通ることと、人物像に年齢・性別の条件が残ることの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技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
| 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 Builder | 2026-10-14 |
| Microsoft 365 Copilot が Microsoft Copilot に改称されたこと。プロンプト・応答・Microsoft Graph で参照したデータが基盤のモデルの学習に使われないこと。EU 以外の顧客のクエリが米国・EU・その他の地域で処理されうること | Microsoft Learn: Data, Privacy, and Security for Microsoft Copilot | 2026-10-14 |
| 事業主は、労働者の募集及び採用について、その性別にかかわりなく均等な機会を与えなければならないこと(第5条) | e-Gov 法令API: 雇用の分野における男女の均等な機会及び待遇の確保等に関する法律 | 2026-10-14 |
| 事業主は、厚生労働省令で定めるときは、労働者の募集及び採用について、その年齢にかかわりなく均等な機会を与えなければならないこと(第9条) | e-Gov 法令API: 労働施策の総合的な推進並びに労働者の雇用の安定及び職業生活の充実等に関する法律 | 2026-10-14 |
どの表現が募集・採用の条件として許されないか、例外に当たるかは、人事部と法務の担当、必要に応じて社会保険労務士に確かめてください。 本記事は公開されている製品の仕様と法令の条文で確認できた範囲だけを扱っています。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-1496)についてのご相談はこちらから。
