先に要点
AI エージェントの設計を見ていると、handoff という言葉が出てきます。
特に OpenAI Agents SDK では、manager 型のオーケストレーションと並ぶ基本パターンとして扱われています。
ただ、日本語でざっくり 引き継ぎ と訳すだけだと、単なるツール呼び出しとの違いが分かりにくいです。
この記事では、2026年4月21日時点の OpenAI の公式ドキュメントを中心に、handoff の基本、オーケストレーター 型との違い、向く場面、失敗しやすい点まで整理します。
Handoffとは何か
Handoff とは、あるエージェントが現在の会話や作業を、別の専門エージェントへ渡す仕組みです。
たとえば、最初の窓口エージェントがユーザーの相談を受けて、
- 予約の相談なら予約担当へ渡す
- 返金の相談なら返金担当へ渡す
- 技術問い合わせなら技術担当へ渡す
というように切り替える形です。
このとき重要なのは、ちょっと別の機能を呼ぶ のではなく、担当そのものが切り替わる ことです。
OpenAI Agents SDK でも、handoffs は specialist should take over the conversation という位置づけで説明されています。
つまり、中心エージェントが裏で専門担当を使うのではなく、専門担当が前面に出る構成です。
ツール呼び出しと何が違うのか
ここが一番混同されやすいです。
ツール呼び出しでは、中心エージェントが主導権を持ったまま外部機能や specialist を使い、最後は自分で返答をまとめることが多いです。
一方で handoff では、次の担当が会話の中心になります。
ざっくり比較するとこうです。
| 観点 | ツール呼び出し / manager型 | handoff型 |
|---|---|---|
| 主導権 | 中心エージェントが持ち続ける | 次の担当へ移る |
| 向く場面 | 全体管理、統合、最終回答 | 問い合わせ種類ごとの担当切り替え |
| 強み | 出力形式や安全確認を一元化しやすい | 専門担当へ会話を集中させやすい |
| 弱み | 中心が太りやすい | 受け渡しが雑だと文脈が崩れやすい |
最終的な窓口は一つにしたい なら manager 型、担当そのものを切り替えたい なら handoff 型、という見方が分かりやすいです。
なぜ handoff が必要になるのか
1. 専門担当に会話を集中できる
最初の窓口が全部知っている必要はありません。
問い合わせの種類ごとに担当を切り替えた方が、指示も短くなり、専門特化しやすいです。
2. 役割の境界をはっきりさせやすい
オーケストレーター型だと、中心エージェントが多くのことを抱え込みやすいです。
handoff 型は、ここから先はこの担当 と切り替えやすいため、窓口責任と専門責任を分けやすくなります。
3. 会話設計を自然にしやすい
カスタマーサポートや社内ヘルプデスクのように、もともと人間でも担当を振り分ける業務では、handoff の考え方が自然にハマります。
OpenAI Agents SDKではどう扱われているか
OpenAI の公式ドキュメントでは、handoffs はエージェントが別のエージェントへ delegate tasks する仕組みとして説明されています。
さらに、handoff は LLM に対して tool として表現され、たとえば Refund Agent なら transfer_to_refund_agent のような形で扱われます。
ここで大事なのは次の点です。
- handoff 先は
handoffsに登録する - 必要なら
handoff()helper で説明や入力をカスタマイズする - handoff 時に渡す追加情報を schema で定義できる
- 入力フィルタで、次の担当へ渡す履歴を調整できる
つまり、handoff は単なる概念ではなく、いつ渡すか 何を渡すか どこまで履歴を見せるか まで設計対象になります。
どんな場面で向いているか
handoff が向いているのは、問い合わせの種類や作業の種類ごとに担当が切り替わる 場面です。
たとえば次のようなケースです。
- FAQ、請求、返金、障害対応で担当が分かれるサポート導線
- 最初に要件を受けて、適切な専門担当へ振り分ける受付窓口
- 多言語対応で、言語ごとに担当エージェントを切り替える構成
- 対話の途中で、専門性が必要になったら担当を切り替える構成
逆に、複数担当の結果を最後に一つへ統合したい場面では、handoff より manager 型の方が扱いやすいことがあります。
失敗しやすい点
1. 何を引き継ぐか決まっていない
handoff の失敗で多いのがこれです。
次の担当に必要な要約、前提、制約、ユーザー意図が整理されていないと、受け手が最初から聞き直すことになります。
2. いつ渡すかが曖昧
handoff 条件が曖昧だと、窓口担当が抱え込んだり、逆に早すぎる段階で専門担当へ飛ばしたりします。
どの条件で誰に渡すか は最初に決めた方が安定します。
3. 誰が最終責任を持つかが不明
handoff を重ねると、今の窓口が誰なのか分からなくなることがあります。
特に本番操作や課金が絡む場面では、最終的な責任点を曖昧にしない方が安全です。
4. 人間確認を抜いてしまう
重要な承認まで handoff の連鎖で流すと危険です。
本番反映、外部送信、契約処理、権限変更などは、人間確認を入れる設計の方が現実的です。
実務で先に決めたいこと
handoff を入れる前に、少なくとも次は決めておくと崩れにくいです。
- どの条件で誰に渡すか
- handoff 時に何を要約して渡すか
- どの履歴を次の担当に見せるか
- handoff 後に元の担当へ戻るのか
- どこで人間承認を挟むか
この設計を飛ばして とりあえず担当を分けた だけにすると、見た目だけ高度で、運用はかなり苦しくなります。
まとめ
Handoff とは、AIエージェントが会話や作業の主導権を別の専門担当へ受け渡す仕組み です。
AI エージェント設計ではかなり便利ですが、別のツールを呼ぶだけ と同じ感覚で使うと失敗しやすいです。
大事なのは、
- 誰に渡すのか
- 何を渡すのか
- 渡したあと誰が責任を持つのか
をはっきりさせることです。
全体像から見たい場合は、オーケストレーターとは？AIエージェント設計で役割分担を束ねる基本を整理 や マルチエージェントとは？複数のAIエージェントを分けて使う意味と注意点を整理 もあわせて読むとつながりやすいです。