社内公募やプロジェクトの人選のときに、社員のスキル登録・研修履歴・過去のプロジェクト記録から要件に合う社員を探し、根拠の記録付きで候補を人事へ返す

処理の起点を決める

取り込みと検索で、起点が2つあります。

取り込みは、毎晩の定時で行います。 スキルの登録、研修の受講、体制の変更は日中に少しずつ起き、人選の検索は翌日以降に使われるので、毎晩で足ります。 毎時にすると、人事の仕組みへの読み取りが増えるわりに、候補の顔ぶれは変わりません。

対象外の印は、取り込みのたびに付け直します。 休職や異動、本人の希望は日々変わります。前の晩の印を残したままにすると、復職した人が候補に出ないことになります。印の元は人事の仕組みの状態で、検索基盤の側で手で付けることはしません。

検索は、人事の担当が人選の依頼を受けて画面で始めたときに動きます。 事業部の管理職が自分で検索する形にはしません。候補の一覧を誰が見たかを人事の側で管理するためです。

入力データを集める

質を決めるのは、スキルと資格の名前の対応表です。 スキルの一覧と研修の資格の名前、プロジェクトの振り返りに書かれた技術の名前を、共通のコードに結ぶ表を人事と事業部で作ります。terms_set は完全一致で数えるので、対応表に無い名前は、持っていても数えられません。

入れないデータも決めておきます。 年齢、性別、国籍、家族の状況、健康に関わる配慮事項、人事評価、給与は、索引に入れません。 人選の材料に要らないうえ、検索基盤に入っていれば、設定の誤り1つで画面に出ます。

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

人事の仕組み、研修の受講管理、プロジェクトの管理の仕組みから、毎晩、必要な項目だけを書き出してもらいます。 書き出しの形は仕組みごとに違うので、Lambda で社員番号を鍵にして結びます。API で取れる仕組みは API で、取れない仕組みは毎晩のファイルの書き出しで受けます。どちらの経路でも、取り込む項目の一覧を人事と情報システムで決めて固定します。

索引は2つに分けます。

2つに分けるのは、検索の性質が違うためです。 必須の条件は社員の単位で「いくつ満たすか」を数え、経験はプロジェクトの単位で「どの振り返りが近いか」を探します。先に社員の索引で絞った社員番号の一覧で、経験の索引を絞ります。

スキルのレベルは、コードに含めて持たせます。 「java_3」「java_4」のように、レベルごとに別のコードとしても登録します（レベル4の人には java_3 と java_4 の両方）。「Java のレベル3以上」を terms_set の1つの語として数えられるようにするためです。

AIへ渡す前に整形する

1. 名前を共通のコードにそろえる … スキルの一覧、資格の名前、振り返りの技術の名前を、対応表で共通のコードに置き換えます
2. レベル以上のコードを展開する … レベル4の人に、レベル3以上・レベル2以上のコードも付けます
3. 資格の有効期限を確かめる … 期限の切れた資格は、コードを付けずに「期限切れ」として別に持ちます
4. 振り返りから個人の評価を外す … 振り返りに他の社員への評価や、本人の体調に関わる記述があれば、取り込みで外します
5. 対象外の印を付ける … 人事の仕組みの状態から、休職中、本人が希望しない、異動から一定期間内の社員に印を付けます
6. 登録日の古さを記録する … スキルの登録日から何年たったかを、項目として持たせます

4番目を軽く見ないでください。 プロジェクトの振り返りには、「〇〇さんの進め方に問題があった」「途中で体調を崩した」のような記述が混ざることがあります。そのまま索引に入れると、経験を探す検索の引用として、人選の画面に出ます。 取り込みの段で、人事が決めた規則で外します。

6番目の登録日は、候補の画面に必ず出します。 3年前に「レベル3」と自己申告したスキルが、いまもレベル3とは限りません。検索の順位には使わず、読む人が判断する材料にします。

AIに処理させる

AIの仕事は、検索で出た候補を、決まった項目で引用付きで並べることだけです。 候補を絞るのも、経験を探すのも検索基盤で行います。

1行目が、いちばん外せない線です。 候補を並べると、AIは「最も適しているのは〇〇さんです」と書きがちです。その一文が、人事の画面から管理職へそのまま渡ると、検索の結果が推薦に変わります。 並べる順は検索の点数のままにし、AIには順位を付けさせません。

3行目も、同じくらい起きやすい失敗です。 「金融の基幹システムの経験がある人は、おそらく〇〇の資格の内容も知っている」と補うと、満たさなかった条件が満たしたように読めます。 満たさなかった条件は、満たさなかったと書かせます。

指示内容を固定する

あなたは人事部で、人選の依頼に対して社内の候補を整理する係です。
渡された検索結果だけを根拠にしてください。記録に無いことを補わないでください。

【人選の条件】
必須の条件：{required_codes}（このうち {min_match} 個以上）
あるとよい経験：{experience_words}
時期：{period}

【検索結果】
候補ごとに、満たした条件のコードと登録日、満たさなかった条件、
期限切れの資格、経験の索引で近かった振り返りが渡されます。

【候補ごとに書くこと】
1. 社員番号と所属
2. 満たした必須の条件（コード、レベル、登録日）
3. 満たさなかった必須の条件（「登録なし」か「期限切れ」かを分ける）
4. あるとよい経験に近い振り返り（プロジェクト番号、役割、期間、引用）
5. 確かめるべき点（登録から3年以上たったスキル、現在の稼働の割合）

【厳守事項】
- 候補に順位を付けたり、推薦したりしないでください。
  渡された順のまま並べてください。
- 満たさなかった条件を、経験から推測して満たしたことにしないでください。
- 人柄、適性、将来性を書かないでください。
- 年齢、性別、国籍、健康、家族、評価に触れないでください。
- 振り返りに他の社員への評価が含まれていても、引用しないでください。
- 根拠の振り返りが無い候補は「経験の根拠となる記録なし」と書いてください。

「渡された順のまま」と書くのは、AIが並べ替えると、それ自体が順位付けになるためです。 検索の点数の順は、必須の条件を満たす数と言葉の近さで決まった機械的な順で、誰が適任かという判断を含みません。 その性質を、AIの段で変えないようにします。

検索結果は、Claude の検索結果ブロックで渡します。 候補ごとの振り返りを1つの search_result にし、source にプロジェクト番号と社員番号、title に役割と期間、content に振り返りの本文を入れます。公式の説明では、引用付きの答えが返り、Amazon Bedrock でも使えます。 引用元のプロジェクト番号が画面に出るので、人事は振り返りの原文をすぐに開けます。

出力形式を固定する

社員の索引への検索は、次のように組みます。

GET /talent-profile/_search
{
  "size": 30,
  "query": {
    "bool": {
      "filter": [
        { "term": { "excluded": false } },
        { "terms_set": {
            "required_hit": {
              "terms": ["aws_mig_3", "fin_core_2", "pm_assist_2", "cert_aws_sap", "java_3"],
              "minimum_should_match_script": { "source": "Math.min(params.num_terms, 4)" }
        } } }
      ]
    }
  }
}

params.num_terms は、terms に渡したコードの数です。 公式のドキュメントの例と同じく、Math.min で「渡した数」と「必要な数」の小さいほうを使えば、条件を3つしか入れなかった依頼で4つを求めて0件になることを防げます。required_hit は、スキルのコードと資格のコードをまとめて入れた項目です。

絞った社員番号で、経験の索引を探します。

GET /talent-experience/_search
{
  "query": {
    "bool": {
      "filter": { "terms": { "employee_id": ["E10234", "E20871"] } },
      "must": { "match": { "review_text": "金融機関 基幹システム クラウド移行" } }
    }
  }
}

人事の画面に返す形は、次のJSONです。

{
  "request_id": "REQ-2026-1007-03",
  "candidates": [
    { "employee_id": "E10234", "department": "金融ソリューション事業部",
      "matched": [ { "code": "aws_mig_3", "registered_on": "2025-04-10" } ],
      "unmatched": [ { "code": "cert_aws_sap", "reason": "期限切れ" } ],
      "experience": [
        { "project_id": "PJ-2024-0331", "role": "サブリーダー",
          "period": "2024-04〜2025-03", "quote": "" } ],
      "to_check": ["java_3 の登録から3年以上", "現在のプロジェクトの稼働 80%"] }
  ],
  "excluded_count": 6
}

1つ目の理由は、matched と unmatched を別の配列にできることです。 満たさなかった条件が理由付きで並ぶので、「登録が漏れているだけの人」を人事が見分けられます。

2つ目は、to_check で確かめる点を画面に固定できることです。 登録日の古さや現在の稼働は、AIの文章に埋もれると読み飛ばされます。項目にして、面談の前に本人に聞くことの一覧にします。

3つ目は、excluded_count で対象外にした人数を見せられることです。 誰を外したかは出さず、何人を外したかだけを出します。人数が急に増えたら、対象外の印の付け方を見直します。

システムへ連携する

管理職への返送は、画面から一覧を書き出して人事が送ります。 管理職に検索の画面を直接開放しないのは、候補に挙がった事実そのものが、社員にとって知られたくない情報になりうるためです。

人が確認する

この構成の確認は、必須です。 候補の一覧は材料で、声をかける相手は人が決めます。

1. 満たさなかった条件を読む … 「登録なし」の条件は、本当に経験が無いのか、登録が漏れているだけかを見ます。漏れが疑われる人は、本人か上長に確かめます
2. 根拠の振り返りを開く … 引用されたプロジェクトの振り返りを原文で読み、役割と期間が依頼に合うかを確かめます
3. 確かめるべき点を本人に聞く … 登録日の古いスキル、現在の稼働、異動の希望は、声をかける前に本人か上長に確かめます
4. 管理職へ返す候補を選ぶ … 人事が選んだ候補だけを、見せてよい項目の一覧にして返します

1番目が、思い出せる人に偏る問題への答えです。 登録が漏れている人は、これまでの表計算の突き合わせでは落ちたことすら見えませんでした。 満たさなかった条件を理由付きで並べることで、人事が拾い直せます。

1件あたり30分を目安にします。 候補が10名なら、1名あたり3分で満たさなかった条件と根拠の振り返りを読む計算です。

例外に対処する

1行目で条件を勝手に緩めないのは、緩めた結果を人事が「条件に合う人」と読むためです。 必要な数を下げた場合の人数を添え、緩めるかどうかは依頼した管理職と人事が決めます。

5行目で状態が取れない社員を外すのは、休職中の人に声がかかる失敗を避けるためです。 外した人数は excluded_count に入るので、取り込みの不具合で人数が増えれば、翌朝に気づけます。

記録を残す

• 毎晩の取り込みの件数と、対応表に無かった名前の一覧
• 人選の依頼番号、入れた条件、必要な数、経験の言葉
• 返した候補の社員番号と、満たした条件・満たさなかった条件
• Claude に渡した検索結果と、返ってきた答えと引用
• 人事が管理職へ返した候補と、返さなかった候補
• 検索の画面を誰がいつ使ったか

最後の行は、社員の情報を扱う構成として欠かせません。 人選の名目で特定の社員の記録を繰り返し見る、といった使われ方を後から確かめられるようにします。ログの保存期間と、誰が見られるかも人事と情報システムで決めます。