Claude Managed Agentsで採用エージェントを作る｜日常業務3実例＋マルチエージェントの実践ガイド
はじめに——「使い分け」が分かったら、次は「作る」番だ
前回の記事では、Claude Managed Agentsを採用業務で活用するためのフレームワークを提示しました。採用業務を「決定論的な処理」と「非決定論的な処理」に分け、非決定論的なタスクからエージェント活用を始めよう、という話でした。
今回はその実践編です。採用担当者が毎日・毎週行っている業務3つについて、Managed Agentsの具体的なエージェント設計を紹介します。さらに、複数エージェントが協調するマルチエージェントの設計例も紹介します。
その前に——「決定論的 vs 非決定論的」は二項対立ではない
前回の記事では説明の便宜上、2つをきっぱり分けました。しかし実際の採用業務では、この2つは**グラデーション（地続き）**です。
例えば書類選考。AIが候補者をスコアリングするのは非決定論的な処理です。しかしそのスコアを「評価基準の構造」に従って出し、「人が承認するゲート」を通さないと次のステップに進まない設計にする——これは非決定論的な処理の中に決定論的な制御を埋め込む設計です。
専用の採用AIサービスが優れているのは、まさにこの「地続きの設計」です。AIの柔軟な判断力を活かしながら、運用が破綻しないようにワークフロー制御・承認ゲート・データ整合性チェックを組み込んでいる。
今回紹介するManaged Agentsのエージェントは、このグラデーションの中で**「純粋に非決定論的なタスク」——つまり、人が最終判断する前提で、失敗してもやり直しが効く領域**を対象としています。「エージェントの出力をそのまま候補者に送る」ような使い方ではなく、「エージェントが考え、人が判断する」構造です。
Managed Agentsの基本セットアップ
実例に入る前に、Managed Agentsでエージェントを作る基本の流れを押さえておきましょう。
Step 1: Agentを定義する
└ モデル、システムプロンプト、ツール、ガードレールを設定
↓
Step 2: Environmentを設定する
└ 実行環境（パッケージ、ネットワークアクセス）を構成
↓
Step 3: Sessionを開始する
└ Agent + Environmentを指定してセッションを起動
↓
Step 4: Eventを送る
└ ユーザーメッセージを送信し、エージェントの応答をSSEで受け取る
採用業務でのポイントは、Agentのシステムプロンプトとツール設定の2つです。ここを業務に合わせて設計することで、採用担当者は毎回プロンプトを考える必要がなくなります。
以下、各実例では主にシステムプロンプトとツール構成、そして**実際の使い方（Eventの送り方）**を紹介します。
実例1：求人票レビューエージェント
なぜこの業務か
求人票の作成・改善は、採用担当者が最も頻繁に行う「考える仕事」の一つです。新規ポジションが開くたびに、応募が来ないたびに、採用要件が変わるたびに発生します。
そして多くの場合、過去の求人票をコピペして部分修正するだけ。競合の求人を調べたり、候補者目線で見直したりする時間はなかなか取れません。
エージェント設計
システムプロンプト：
あなたは採用のプロフェッショナルです。求人票を受け取ったら、
以下のフレームワークでレビューしてください。
## レビュー観点
1. ターゲット人材に響く表現になっているか
- 抽象的な「コミュニケーション能力」ではなく、
具体的な業務シーンで記述されているか
- 候補者が「自分のことだ」と感じる具体性があるか
2. Must条件とWant条件の切り分けは適切か
- 「経験3年以上」は本当にMustか？
- Wantにできる条件がそのままMustになっていないか
3. 候補者が知りたい情報が含まれているか
- チーム構成、技術スタック、働き方の柔軟性、成長機会
- 入社後の具体的なイメージが浮かぶか
4. 競合との差別化
- Web検索で同職種の競合求人を2-3件調査
- 競合が掲げていないが、御社の強みとして訴求できるポイント
## 出力フォーマット
以下の構成で回答してください：
### 現状の評価（各観点ごとに○/△/×）
[4観点の評価と理由]
### 競合調査結果
[競合求人2-3件の特徴と、御社が勝てるポイント]
### 改善版の求人票
[全文を提示]
### 変更理由の説明
[何をなぜ変えたかの解説]
ツール構成：
| ツール | 用途 |
|---|---|
| Web検索 | 競合の求人票・市場の相場感を調査 |
| ファイル操作 | レビュー結果をMarkdownファイルとして保存（後で取り出せる） |
実際の使い方
Sessionを開始したら、以下のようにEventを送ります：
以下の求人票をレビューしてください。
ポジション: バックエンドエンジニア（Go）
背景: 現在のチームは3名。プロダクトの成長に伴い、
マイクロサービス化とパフォーマンス改善をリードできる人材を探しています。
---
[求人票本文を貼り付け]
エージェントは、Web検索で競合の求人を調べた上でレビューを実行し、改善版を提示します。
ポイント
- エージェントの出力をそのまま使わない。あくまで「たたき台」として、採用担当者が判断する
- セッションが永続化されるので、「先週のレビュー結果を踏まえて、応募状況を見て再調整して」という継続的な改善が可能
- Agentを一度定義すれば、誰でも同じ品質でレビューを実行できる。AI活用スキルの個人差を吸収できる
実例2：スカウトアプローチ設計エージェント
なぜこの業務か
スカウトの文面作成は、採用担当者が毎日最も時間を使う業務の一つです。候補者一人ひとりに対して「この人には何を伝えれば響くか」を考えるのは時間がかかりますが、かといってテンプレートのコピペでは返信率が上がりません。
このエージェントは「文面を書く」のではなく、**「アプローチの戦略を設計する」**エージェントです。文面の生成はその先のステップであり、まず「なぜこの人に送るのか」「何を訴求するのか」を明確にします。
エージェント設計
システムプロンプト：
あなたはダイレクトリクルーティングのストラテジストです。
企業情報と候補者プロファイルを受け取ったら、
スカウトの「設計」を行ってください。
## 応答手順
1. 候補者プロフィールの分析
- 経歴の強みと特徴を抽出
- 現在のキャリアステージを推定（成長期？安定期？転換期？）
- 転職の動機仮説を立てる
2. マッチング分析
- この候補者とポジションの接点を特定
- 候補者が「自分のことだ」と感じるポイントを抜き出す
3. 訴求戦略の設計
- 候補者の推定動機に対して、何を伝えれば響くか
- 「なぜあなたなのか」の根拠を明確に
- 「なぜ今なのか」の緊急性を作れるか
4. メッセージの方向性提案
- 具体的なメッセージの方向性を3パターン提示
- 各パターンの「この人に刺さる理由」を説明
## 制約
- 文面そのものの生成は行わない。「設計」までがあなたの役割
- 候補者情報の取り扱いに注意し、セッション外に出さない
- 「この候補者に送るべきか」の判断はしない。設計材料を提供し、判断は人が行う
ツール構成：
| ツール | 用途 |
|---|---|
| Web検索 | 候補者の公開情報（技術ブログ、登壇資料等）を補完的に調査 |
| ファイル操作 | 設計結果をファイルに保存 |
実際の使い方
以下の候補者へのスカウトアプローチを設計してください。
## 企業情報
- 社名: ○○株式会社
- 事業: SaaSプロダクト（HR Tech）
- 強み: 技術力の高い少数精鋭チーム、プロダクト成長率前年比200%
- ポジション: バックエンドエンジニア（Go）
- 訴求ポイント: アーキテクチャ設計から携われる、プロダクトへのインパクトが大きい
## 候補者プロフィール
- 名前: 山田太郎（仮名）
- 現職: 大手SIer システムエンジニア（5年目）
- スキル: Java/Spring Boot、AWS、チームリード経験あり
- 特徴: 個人でGoのOSSにコントリビュートしている
エージェントは「候補者分析→マッチング分析→訴求戦略→メッセージ方向性」の順で思考し、「この人にはこうアプローチするべき」という設計図を出力します。その設計を見て「送る/送らない」「この方向でいく」を判断するのは人間です。
ポイント
- システムプロンプトの「制約」セクションが重要。**「文面生成はしない」「送るべきかの判断はしない」**と明示することで、エージェントが「考える」に彻する
- 同じセッションで複数候補者のアプローチを設計すれば、「この人とこの人で訴求が似てしまっている」といったクロスチェックも可能
実例3：面接準備エージェント
なぜこの業務か
面接の前準備は、採用担当者と面接官の両方に発生する「地味だが毎回必要な」業務です。
- 採用担当者：候補者の経歴を要約し、面接官向けのブリーフィングシートを作る
- 面接官：候補者の経歴書を読み込み、何を聞くべきか考える
これをエージェントに任せることで、準備時間を大幅に削減しつつ、面接の質を上げることができます。
エージェント設計
システムプロンプト：
あなたは採用面接の準備を支援するエキスパートです。
候補者の経歴情報と評価基準を受け取り、
面接官向けの「面接準備キット」を作成してください。
## 出力構成：面接準備キット
### 1. 候補者サマリー（3行）
[経歴のハイライトを簡潔に]
### 2. 書類から確認済みの事項
[面接で重複質問しなくてよい内容のリスト]
### 3. この候補者特有の確認ポイント
[経歴から読み取れる論点・確認が必要な点]
例：キャリアの転換点、ブランク期間、マネジメント経験の深さ
### 4. 推奨質問リスト（優先度順）
[評価基準の各項目に対応する質問]
[各質問に「この質問で何を見るのか」を一行で付記]
### 5. 深掘りガイド
[「こう答えたらこう深掘り」のパターンを2-3件]
### 6. 評価のポイント
[「この候補者の合否判断は、この点にかかっている」という判断軸の提示]
## 制約
- 合否の判断は一切行わない。判断材料の提供に彻する
- 候補者の個人情報を外部検索しない（提供された情報のみ使用）
- 質問は構造化面接の原則に従う（同じ評価基準で全候補者を評価できるように）
ツール構成：
| ツール | 用途 |
|---|---|
| ファイル操作 | 候補者の経歴書PDF/テキストを読み込み、準備キットをファイル出力 |
※ このエージェントではWeb検索は意図的に無効化します。候補者の個人情報を勝手に検索しないようにするためです。これはガードレールの一例でもあります。
実際の使い方
以下の候補者の面接準備キットを作成してください。
## 評価基準
- 技術力（アーキテクチャ設計・コード品質・パフォーマンス）
- チームワーク（コードレビュー・メンタリング・ドキュメンテーション）
- カルチャーフィット（自律性・スピード感・不確実性への耐性）
## 候補者経歴
[経歴書の内容を貼り付け]
ポイント
- 出力フォーマットを固定しているのがミソ。毎回同じ構成のキットが出るので、面接官が読み方に慣れる
- 「書類から確認済みの事項」が特に価値が高い。面接で「書類に書いてあることを聞き直す」無駄がなくなる
- 複数候補者の準備キットを同じセッションで作れば、「候補者AとBで確認ポイントの違いは？」といった比較も可能
実例4：選考パイプライン分析（マルチエージェント）
なぜマルチエージェントが必要か
「今期の採用を振り返って、次に何を改善すべきか提案して」——このタスクは単純に見えて、実は複数のステップが入り組んでいます：
- データの集計・可視化（通過率、リードタイム、辞退率等）
- 異常値・パターンの発見（「このフェーズだけ通過率が低い」等）
- 原因仮説の立案（なぜそのパターンが発生しているのか）
- 改善提案の生成（何をどう変えればよいか）
これを単一エージェントで行うと、文脈が長くなりすぎて品質が下がります。Managed Agentsの**マルチエージェント機能（Research Preview）**を使うと、各ステップを専門のエージェントに分担させられます。
マルチエージェントの設計
[オーケストレーターエージェント]
│ 全体の指揮を取り、各エージェントの結果を統合
│
├─ [Agent A: データアナリスト]
│ CSVデータを受け取り、集計・可視化・異常値検出
│
├─ [Agent B: 採用コンサルタント]
│ データ分析結果を受け、原因仮説を立案
│
└─ [Agent C: 改善提案ストラテジスト]
仮説とデータを踏まえ、具体的なアクションプランを提案
各エージェントの設計
Agent A：データアナリスト
あなたは採用データの分析専門家です。
採用パイプラインのCSVデータを受け取り、以下を実行してください。
1. 基本指標の集計
- 各選考フェーズの通過率
- 平均リードタイム（応募→内定）
- 各フェーズの滞留日数
- 辞退率（フェーズ別）
- 応募チャネル別のパフォーマンス
2. 異常値・パターンの検出
- 他フェーズと比べて特異な数値
- 月別・ポジション別のトレンド
- 「ここがおかしい」ポイントをフラグ
Pythonで分析コードを実行し、結果を構造化JSONで出力してください。
グラフも生成してください。
Agent B：採用コンサルタント
あなたは10年の経験を持つ採用コンサルタントです。
データ分析結果を受け取り、採用課題の原因仮説を立ててください。
## 分析の観点
1. ボトルネックはどこか
- 「通過率が低いフェーズ」と「滞留が長いフェーズ」を区別
- 「質の問題」と「スピードの問題」を区別
2. なぜそのパターンが発生しているか
- 以下の観点で仮説を立てる：
a. 採用基準の問題（基準が曖昧/厳しすぎ/甘すぎ）
b. プロセスの問題（調整に時間がかかりすぎ/判断が遅い）
c. 候補者体験の問題（魅力訴求が弱い/レスポンスが遅い）
d. 市場環境の問題（求人倍率が高い/報酬が競合に劣る）
3. 仮説に信頼度をつける
- データから裏付けできる仮説 = 信頼度「高」
- データからは断定できないが強く疑われる = 信頼度「中」
- 一般論として可能性がある = 信頼度「低」
仮説ごとに信頼度を明示し、構造化JSONで出力してください。
Agent C：改善提案ストラテジスト
あなたは採用オペレーションの改善専門家です。
データ分析結果と原因仮説を受け取り、
具体的な改善アクションプランを提案してください。
## 提案フォーマット
各提案について：
### 提案名
- 対象の課題： [どの仮説に対する打ち手か]
- 具体的なアクション： [誰が、いつまでに、何をするか]
- 期待効果： [どの指標がどう変わるか]
- 実行難易度： [低/中/高]
- 優先度： [根拠つきで]
提案は「すぐできる」「1ヶ月以内」「中長期」の3タイムフレームに分けてください。
## 制約
- 実行可能性を重視。「全部やり直す」のような非現実的な提案はしない
- 専用ツールやサービスの導入が有効な場合は、具体的に指摘する
- 「すぐできる」提案を必ず2件以上含める（成果体験が重要）
オーケストレーターエージェント：
あなたは採用パイプライン分析のオーケストレーターです。
ユーザーから採用データを受け取り、以下の3つのエージェントを順番に実行してください。
1. データアナリストエージェントにデータを渡し、集計結果を受け取る
2. 採用コンサルタントエージェントに集計結果を渡し、原因仮説を受け取る
3. 改善提案エージェントに全結果を渡し、アクションプランを受け取る
最後に、全エージェントの結果を統合し、
以下の構成で統合レポートを作成してください：
## 統合レポート構成
### 1. エグゼクティブサマリー（3行）
### 2. 主要KPI（表）
### 3. 発見された課題（優先度順）
### 4. 原因仮説（信頼度付き）
### 5. 改善アクションプラン（タイムフレーム別）
### 6. 次回分析で確認すべきこと
なぜこの設計が効くのか
| 単一エージェント | マルチエージェント |
|---|---|
| 文脈が長くなり、後半の品質が下がる | 各エージェントが専門領域に集中するので品質が安定 |
| 「集計」と「考察」が混在し、どちらも中途半端 | 役割分担でそれぞれの深さが出る |
| エラー時にどこが失敗したか特定しづらい | エージェント単位でリトライ・差し替えが可能 |
実際の使い方
Sessionを開始してオーケストレーターエージェントにデータを渡すだけです：
今期（4月-6月）の採用パイプラインを分析してください。
データは以下のファイルにあります：
- pipeline_data.csv（候補者ID、応募日、各フェーズ通過日、最終ステータス、辞退理由）
- positions.csv（ポジション名、部署、採用予定数）
特に知りたいこと：
- 一番のボトルネックはどこか
- エンジニア採用とビジネス採用で傾向が違うか
- 来期に向けて何を変えるべきか
オーケストレーターが各エージェントに順番にタスクを渡し、結果を統合して最終レポートを生成します。
運用のコツ——エージェントを「育てる」観点
エージェントを作ったら終わりではありません。以下の観点で継続的に改善していきましょう。
1. セッション永続化を活かす
Managed Agentsのセッションは会話履歴とファイルシステムが永続化されます。これは採用業務で大きな強みになります。
- 求人票レビュー: 「先週レビューしてもらった後、応募が増えた。同じ方向で別のポジションも見て」
- パイプライン分析: 「前回の仮説を踏まえて、今月のデータで検証して」
- アプローチ設計: 「前回設計したアプローチで返信が来た。このフィードバックを踏まえて次の候補者も設計して」
このように、セッションを「使い捨て」ではなく「継続的なパートナー」として扱うことで、回を重ねるほど精度が上がります。
2. チームでエージェントを共有する
Managed Agentsでは、Agentを一度定義すればIDで参照できます。つまり：
- 採用リーダーがエージェントを設計・改善
- チームメンバーは同じエージェントIDでSessionを開始するだけ
プロンプトの書き方やAIの使い方に個人差があっても、エージェントの設計が品質を担保するので、チーム全体のアウトプットが底上げされます。
3. ガードレールを意識的に設計する
実例3（面接準備）でWeb検索を無効化したように、「このエージェントに何をさせないか」も重要な設計判断です。
| エージェント | 有効なツール | 意図的に無効化 | 理由 |
|---|---|---|---|
| 求人票レビュー | Web検索、ファイル | — | 競合調査に検索が必要 |
| スカウト設計 | Web検索、ファイル | — | 候補者の公開情報調査に活用 |
| 面接準備 | ファイル | Web検索 | 候補者の個人情報を勝手に検索しない |
| パイプライン分析 | Bash、ファイル | Web検索 | 社内データのみで分析する |
ガードレールは「制限」ではなく「品質設計」です。エージェントが余計なことをしないようにすることで、アウトプットの信頼性が上がります。
エージェントと専用サービスの「地続き」を理解する
ここまで紹介した4つのエージェントは、いずれも「人が最終判断する」前提の設計です。エージェントは「考える」側を担い、「実行する」のは人間です。
しかし実際の採用業務では、「考える」と「実行する」はきれいに分かれません。
例えば書類選考。「この候補者をどう評価するか」は非決定論的な判断ですが、「評価結果を記録する」「次のステップに進める」「候補者に結果を通知する」は決定論的な処理です。そしてこれらは一連のワークフローの中で地続きになっています。
専用の採用AIサービスが優れているのは、まさにこの「地続き」の設計です。
- AIがスコアリングする（非決定論的）
↓ だけど、構造化された評価基準に従って出力する（決定論的な制御） - 人が承認する（非決定論的）
↓ だけど、承認なしでは次のステップに進まない（決定論的なゲート） - 候補者に通知する（決定論的）
↓ だけど、送信前に内容を確認できる（非決定論的な調整余地）
このように、非決定論的な処理の中に決定論的な制御を埋め込み、決定論的な処理の中にも非決定論的な柔軟性を残す。運用が破綻しないのは、この**「地続き」の設計が精密だから**です。
今回紹介したManaged Agentsのエージェントは、このグラデーションの中で「純粋に非決定論的な側」を担うものです。そして、決定論的な制御も含めた端から端までのワークフローを「地続き」でつなぐのが、専用サービスの役割です。
**どちらかだけではなく、両方があって初めて採用業務全体が回る。**それが、この2つの関係の正しい理解です。
まとめ——まずは1つ、作ってみる
今回紹介した4つのエージェントを振り返ります。
| # | エージェント | 頻度 | 難易度 | おすすめの開始順 |
|---|---|---|---|---|
| 1 | 求人票レビュー | 毎週 | ★☆☆ | 最初に試す |
| 2 | スカウトアプローチ設計 | 毎日 | ★★☆ | 2番目 |
| 3 | 面接準備 | 面接前毎回 | ★☆☆ | 1と並行でもOK |
| 4 | パイプライン分析（マルチ） | 月次 | ★★★ | 他が定着してから |
おすすめは、まず「求人票レビューエージェント」から。既存の求人票を渡すだけで効果が分かり、リスクもゼロです。
そして、エージェントの出力品質に満足できないとき——それは失敗ではなく、システムプロンプトを改善するサイクルの始まりです。「どんな制約を加えれば、もっと使える出力になるか」を考えること自体が、採用業務の構造化につながります。
Tasonalは、書類選考AI・日程調整AI・AIスカウトを統合した採用AIプラットフォームです。AIの柔軟な判断力と、確実なワークフロー制御・承認ゲート・データ整合性を「地続き」でつなぐ設計で、採用業務全体を安定して回します。
