先に要点
AIエージェントにツールを渡せるようになると、つい できることを全部渡したくなる ことがあります。
Web検索、ファイル検索、DB参照、メール送信、チケット起票、Git操作、クラウド操作、社内API、MCPサーバー。
全部つなげば強そうに見えます。
でも実務では、ツールを増やしすぎると逆に不安定になります。
AIがどれを使うべきか迷ったり、不要なツールを呼んだり、権限が広がりすぎたり、ログを追いにくくなったりします。
この記事では、2026年4月21日時点の OpenAI Agents SDK 公式ドキュメントを確認しながら、AIエージェントにツールを渡しすぎると何が起きるのか、どう設計すればよいのかを整理します。
まず結論: ツールは「多いほど賢い」ではない
AIエージェントにとってツールは、外の世界へ触る手段です。
検索する、APIを呼ぶ、コードを実行する、ファイルを読む、メールを送る。
できることが増えるのは確かです。
ただし、ツールが増えると、同時に次の負担も増えます。
- どのツールを使うか選ぶ負担
- ツール説明を読む負担
- 権限を管理する負担
- 失敗時に原因を追う負担
- 監査ログを確認する負担
つまり、ツールは能力であると同時に、複雑性でもあります。
起きやすい問題
1. ツール選択を間違える
似たようなツールが多いと、AIはどれを使うべきか迷いやすくなります。
たとえば、
search_docssearch_filessearch_knowledge_basesearch_websearch_ticket_history
のようなツールが並んでいると、どれを優先すべきかが曖昧になります。
ツール説明が似ていれば、さらに間違いやすくなります。
2. 不要なツール呼び出しが増える
LLM主導のオーケストレーションでは、モデルが文脈を見てツールを選びます。
選択肢が多すぎると、調査のたびに複数ツールを試したり、本来不要な確認を挟んだりしやすくなります。
結果として、応答が遅くなり、コストも増えます。
3. トークン消費が増える
ツール定義やスキーマ、説明文もコンテキストに入ります。
大量のツールを一度に渡すと、それだけでコンテキストを消費します。
OpenAI Agents SDK の Tools docs でも、多数の function tools や hosted MCP servers がある場合に tool-schema tokens を減らすため、ToolSearchTool や namespace、defer loading を使う考え方が紹介されています。
つまり、ツール数が増えるほど、使っていないツールの説明 にもコストがかかる可能性があります。
4. 権限が広がりすぎる
読み取りだけなら比較的安全でも、書き込み、送信、削除、課金、本番操作が混ざると危険度が上がります。
AIエージェントに最初から全部のツールを渡すと、必要以上に広い権限を持った状態になります。
これは最小権限の考え方と相性が悪いです。
5. ガードレールが複雑になる
ツールが増えるほど、どこに ガードレール を置くかも難しくなります。
OpenAI Agents SDK の Guardrails docs では、function tool に対して tool guardrails を設定できる一方で、hosted tools、built-in execution tools、handoff、Agent.as_tool などでは guardrail pipeline の扱いが違うことが説明されています。
つまり、ツールなら全部同じように止められる とは限りません。
ツール種別ごとに安全設計が変わります。
6. 監査ログが追いにくくなる
ツールが多いと、何が起きたのかを後から追うのも難しくなります。
- どのツールを呼んだのか
- なぜ呼んだのか
- 入力は何だったのか
- 結果はどうだったのか
- 人間承認は挟まったのか
この情報を追えないと、問題が起きたときに説明できません。
承認ログの考え方は、AIエージェントの承認ログには何を残すべき？後から説明できる記録設計 でも整理しています。
特に危ないツール
ツールの中でも、次の種類は慎重に扱うべきです。
| ツール種別 | リスク | 対策 |
|---|---|---|
| メール・Slack送信 | 誤送信、機密情報流出 | 送信前承認、宛先制限 |
| DB更新・削除 | データ破壊、誤更新 | 読み取り専用から開始、更新前承認 |
| クラウド操作 | 課金、障害、本番影響 | 環境分離、権限制限、承認 |
| シェル実行 | 破壊的操作、情報漏えい | 許可コマンド制限、ログ、sandbox |
| 外部API連携 | 外部送信、契約違反 | DLP、送信先制限、承認 |
| 権限変更 | 権限昇格、内部不正リスク | 人間承認、監査ログ、期限付き権限 |
これらは 使わせない というより、いつ使えるか と 誰が承認するか を決めてから渡すべきツールです。
ツールを渡しすぎているサイン
次のような状態なら、ツールを減らすか整理した方がよいです。
- 似た名前のツールが多い
- どのツールを使うべきか人間でも迷う
- AIが毎回いろいろ試して遅い
- 不要な検索やAPI呼び出しが多い
- tool call のログを見ても意図が分からない
- 危険操作と読み取り操作が同じ agent に混ざっている
- 人間承認が多すぎて作業が進まない
この状態では、モデル性能を上げる前にツール設計を見直す価値があります。
対策1: 役割ごとにツールを分ける
一番基本的な対策です。
たとえば、
- 調査 agent: web search、file search、read-only DB
- 実装 agent: repository read、patch、test
- 通知 agent: draft mail、send mail
- 管理 agent: cloud read、limited deploy
のように分けます。
全agentに全ツールを渡すのではなく、その役割に必要なツールだけを渡す方が安定します。
これは コンテキスト分離 と同じ発想です。
対策2: 読み取りと書き込みを分ける
読み取りツールと書き込みツールは分けた方が安全です。
最初は読み取り専用で調査させ、書き込みや送信が必要になったら別の承認付きツールに渡す。
この形にすると、AIエージェントの暴走リスクをかなり下げられます。
人間承認をどこへ置くかは、人間承認をどこで入れるべき？AIエージェントの承認設計を整理 でも詳しく整理しています。
対策3: namespaceやtool searchを使う
ツールが多い場合、全部をトップレベルに並べるのではなく、関連ツールを namespace でまとめる方法があります。
OpenAI Agents SDK の Tools docs では、namespace groups や hosted MCP servers、defer loading、ToolSearchTool を使って、必要なツールを runtime で探させる考え方が紹介されています。
特に、namespace は crm、billing、shipping のような関連ツール群をまとめるのに向きます。
公式ドキュメントでは、各 namespace は小さく保つのがよく、理想的には10個未満の functions とされています。
これは、ツールが多すぎると探索面が複雑になることの裏返しです。
対策4: tool_choiceで制御する
OpenAI Agents SDK では、ModelSettings.tool_choice によって、ツール利用を auto、required、none、特定ツール名に制御できます。
たとえば、
- まずは tool を使わず回答させる
- 必ず検索を使わせる
- この場面では特定ツールだけ許可する
といった制御ができます。
ただし、tool_choice で全部解決できるわけではありません。
ツールの種類や Responses tool search の制約もあるため、全体設計とあわせて使う必要があります。
対策5: ガードレールと承認を組み合わせる
危険なツールには、tool guardrails や人間承認を組み合わせます。
たとえば、
のような設計です。
ツールを増やすなら、その分だけ止め方も設計する必要があります。
ツールを渡す前のチェックリスト
新しいツールを agent に渡す前に、次を確認すると事故を減らせます。
- その agent の役割に本当に必要か
- 似たツールと役割が重複していないか
- 説明文だけで使いどころが分かるか
- 読み取りか、書き込みか
- 外部送信や課金が発生するか
- 人間承認が必要か
- ログに入力と結果を残せるか
- 失敗時に戻せるか
- namespaceや遅延ロードにできないか
このチェックを通してから渡すだけでも、かなり安定します。
まとめ
AIエージェントにツールを渡しすぎると、ツール選択ミス、不要な呼び出し、トークン消費、権限過多、ガードレールの複雑化、監査ログの追跡困難 が起きやすくなります。
ツールは多いほど賢くなるのではなく、役割に合ったものを絞って渡す方が安定します。
大事なのは、
- 役割ごとにツールを分ける
- 読み取りと書き込みを分ける
- 危険操作には承認を置く
- namespaceやtool searchでツール面を整理する
ことです。
Agent as tool や Handoff との関係は、Agent as toolとは？Handoffとの違いと使い分けを整理 もあわせて読むとつながりやすいです。