Agent as toolとは？Handoffとの違いと使い分けを整理

AIエージェント設計で Agent as tool と Handoff はかなり混同されやすいです。
どちらも複数のエージェントを使うための仕組みですが、実際には役割が違います。

OpenAI Agents SDK の docs では、multi-agent orchestration の代表的な形として agents as tools と handoffs が紹介されています。
ざっくり言うと、

• Agent as tool: 専門エージェントを呼び出して、中心エージェントが結果をまとめる
• Handoff: 別の専門エージェントへ会話の主導権を渡す

という違いです。

この記事では、2026年4月21日時点の OpenAI Agents SDK の公式ドキュメントをもとに、Agent as tool とは何か、Handoff と何が違うのか、どちらを選ぶべきかを整理します。

Agent as toolとは何か

Agent as tool とは、専門エージェントを別のエージェントから呼び出せる tool として扱う設計です。

たとえば、manager agent がユーザーと会話しながら、必要に応じて次のような specialist を呼びます。

• 予約専門エージェント
• 返金専門エージェント
• 調査専門エージェント
• レビュー専門エージェント

OpenAI Agents SDK の Python docs では Agent.as_tool()、JavaScript docs では agent.asTool() の形で紹介されています。
中心の manager agent は specialist を tool として呼び、結果を受け取って、最終的な返答を自分でまとめます。

つまり、ユーザーから見る窓口は変わりません。

Handoffとは何か

Handoff は、別の専門エージェントへ会話や作業の主導権を渡す仕組みです。

OpenAI Agents SDK の Handoffs docs では、handoff は専門領域の違う agent に task を delegate する場面で便利だと説明されています。
また、handoff が起きると新しい agent が conversation history を受け取り、会話を引き継ぐ形になります。

たとえば、最初の triage agent がユーザーの内容を見て、

• 返金なら refund agent
• 請求なら billing agent
• FAQなら FAQ agent

へ渡すような構成です。

この場合、ユーザー対応の中心が次の agent に移ります。

一番大きな違いは「主導権」

Agent as tool と Handoff の一番大きな違いは、会話の主導権です。

呼び出して戻る のが Agent as tool。
担当を切り替える のが Handoff。
まずはこの理解で十分です。

Agent as toolが向く場面

1. 最終回答を一つにまとめたい

複数の specialist から結果を集め、manager が最終回答を作る場合です。

たとえば、

• 調査agentが情報を集める
• レビューagentがリスクを見る
• managerが読者向けにまとめる

のような流れです。

2. ユーザー窓口を変えたくない

ユーザーとの会話は manager が持ち続け、裏側で専門担当を呼びたい場合に向いています。

3. specialistを狭い仕事に使いたい

この観点だけ確認して この分類だけして この差分だけレビューして のような小さな専門作業に向きます。

4. 承認やログをmanager側でまとめたい

最終的な判断、承認、ログ出力を manager 側に集めたい場合も Agent as tool が扱いやすいです。

OpenAI の Tools docs では、Agent.as_tool(..., needs_approval=...) も function_tool と同じ approval flow を使うと説明されています。
承認設計と組み合わせるときにも便利です。

Handoffが向く場面

1. 問い合わせカテゴリごとに担当を切り替えたい

カスタマーサポートのように、返金、請求、予約、FAQ で担当が明確に違う場合です。
この場合、専門担当がそのまま会話を持った方が自然です。

2. 専門agentに会話を集中させたい

専門agentがユーザーへ追加質問をしたり、そのまま解決まで進めたりする場合は Handoff が向きます。

3. managerが全部を抱えると重すぎる

manager が常に全体を見て、すべてを統合する構成は便利ですが、長い会話では太りやすいです。
担当そのものを切り替えた方が軽くなることがあります。

会話履歴の扱いも違う

Handoff では、handoff先の agent が previous conversation history を見る前提になります。
OpenAI の Handoffs docs では、必要に応じて input_filter で次の agent に渡す履歴を調整できると説明されています。

一方、Agent as tool は tool 呼び出しとして specialist を使います。
そのため、manager が specialist へ何を渡すかを比較的コントロールしやすいです。

この違いは、コンテキスト分離 とも関係します。

よくある失敗

1. Agent as toolで何でもやらせる

specialist を tool として呼べるからといって、万能agentを大量にぶら下げると、manager がどれを呼ぶべきか迷いやすくなります。

specialist は、狭く、説明しやすい役割にした方が安定します。

2. Handoffで引き継ぎ情報を渡さない

handoff先が必要な前提を知らないと、また最初から質問することになります。
必要なら input filter や要約を使って、渡す情報を整理します。

3. 両方を混ぜすぎる

manager が specialist を tool として呼び、さらに specialist が handoff し、戻ってきた結果をまた別agentへ投げる。
こうなると、ログも責任も追いにくくなります。

複雑にする前に、まず 主導権を誰が持つべきか を決める方が安全です。

どう使い分ければいいか

迷ったら、次の基準で見ると判断しやすいです。

最終回答を誰が持つべきか

manager が持つべきなら Agent as tool。
専門担当がそのまま返すべきなら Handoff。

ユーザー窓口を変えてよいか

変えたくないなら Agent as tool。
変えてよい、むしろ変えたいなら Handoff。

作業は部分タスクか、会話全体か

部分タスクなら Agent as tool。
会話全体を引き継ぐなら Handoff。

履歴をどこまで見せたいか

必要情報だけ渡したいなら Agent as tool が扱いやすいです。
会話履歴込みで担当を切り替えたいなら Handoff が自然です。

実務では組み合わせることもある

Agent as tool と Handoff は排他的ではありません。
たとえば、triage agent が refund agent に handoff し、その refund agent が裏側で policy checker agent を tool として呼ぶ、という構成もありえます。

ただし、最初から複雑にしすぎると遅くなります。
まずは、

1. manager が持ち続ける構成でよいか
2. 担当を切り替える必要があるか
3. 人間承認をどこに入れるか

を決める方が実務的です。

まとめ

Agent as tool は、専門エージェントを tool として呼び、中心エージェントが会話の主導権と最終回答を持ち続ける設計 です。
Handoff は、別の専門エージェントへ会話や作業の主導権を渡す設計 です。

大事なのは、

• 呼び出して戻るのか
• 担当を切り替えるのか
• 最終回答を誰が持つのか

を先に決めることです。
周辺の設計としては、Handoffとは？AIエージェントが役割を受け渡す仕組みを整理、LLM主導のオーケストレーションとは？AIエージェントが流れを判断する設計を整理、人間承認をどこで入れるべき？AIエージェントの承認設計を整理 もあわせて読むとつながりやすいです。

参考リンク

• OpenAI Agents SDK: Agent orchestration
• OpenAI Agents SDK: Agents
• OpenAI Agents SDK: Tools
• OpenAI Agents SDK: Handoffs
• OpenAI Agents SDK JS: Agent orchestration