AIエージェントへ100個のツール定義を最初から渡すと、使わない引数スキーマまでコンテキストを占有します。OpenAIのTool Searchは、必要なツールだけを実行時に読み込む仕組みです。ただし、これは認可機能ではありません。効率化と実行権限を分けて設計することが重要です。
Tool Searchは「巨大な工具箱の目次」です
通常のツール呼び出しでは、モデルは利用可能な関数の名前、説明、引数スキーマをコンテキスト内で受け取ります。ツールが増えるほど、その定義だけでトークンを消費し、モデルが似た道具を取り違える余地も増えます。
Tool Searchでは、候補となる関数、名前空間、MCPサーバーを検索対象として登録し、詳細の読み込みを実行時まで遅らせます。モデルが必要だと判断したサブセットだけがコンテキストへ追加され、その後に通常のツール呼び出しへ進みます。
OpenAIの公式ガイドでは、ツール検索を有効にする条件を次の2点としています。
tools配列へtool_searchを追加する- 遅延対象の関数またはMCPサーバーへ
defer_loading: trueを付ける
2026年8月29日時点の公式ガイドでは、Tool Searchをサポートするのはgpt-5.4以降です。Agents SDKのホスト型検索はOpenAI Responsesモデル向けで、Pythonではopenai>=2.25.0に依存します。導入時はモデルとSDKの両方を確認する必要があります。
遅延される範囲を誤解しない
Tool Searchは、ツールを完全に不可視にする機能ではありません。名前空間やMCPサーバーを使う場合、最初に見えるのは名前と概要だけで、内部の個別関数は検索後に読み込まれます。一方、個別関数だけを遅延すると、その関数名と説明は最初から見え、主に引数スキーマが後回しになります。
そのため、個別関数を大量に平置きするより、crm、billing、shippingのような業務単位で名前空間へまとめる方が効果的です。OpenAIは、可能なら名前空間またはMCPサーバーを使い、各名前空間を10関数未満に保つことをベストプラクティスとして示しています。
車載開発でいえば、全ECUの全サービス仕様を毎回配るのではなく、まず「診断」「書き換え」「ログ取得」という目次だけを見せ、選ばれた領域のサービス定義を開くイメージです。
キャッシュを壊しにくい追加位置
Tool Searchはトークン削減だけでなく、プロンプトキャッシュを保ちやすいよう設計されています。公式ガイドによると、新しく見つかったツールはコンテキスト末尾へ追加されます。先頭の共通部分が変わりにくいため、リクエスト間でキャッシュが効きやすくなります。
ただし、「何％削減できる」と一律には言えません。効果はツール数、スキーマの大きさ、実際に読み込む割合、モデル料金で変わります。導入前後で少なくとも次を計測すべきです。
- 初回リクエストの入力トークン数
- 検索で読み込んだ名前空間・ツール数
- 最終回答までのレイテンシー
- ツール選択の正解率と再試行回数
- キャッシュ済み入力トークンの割合
安全に導入する4つの設計
1. 名前空間を業務境界に合わせる
ライブラリの都合ではなく、利用者の目的に合わせて分けます。たとえば注文照会ならcrm、請求確認ならbillingです。説明文には「何ができるか」だけでなく「何は含まないか」も書くと、不要な検索を減らせます。
2. 常用ツールと遅延ツールを混在させる
名前空間内では、即時利用できるツールとdefer_loading付きのツールを混在できます。毎ターン使う検索や状態確認は常用にし、長いスキーマを持つ例外処理や管理機能だけを遅延させる方が、検索の追加ステップを抑えられます。
3. 在庫が固定ならホスト型、動的ならクライアント実行型
候補ツールがリクエスト作成時に分かるなら、OpenAI側が検索するホスト型から始めるのが簡単です。テナント、契約、プロジェクト状態によって候補自体が変わるなら、アプリが検索結果を返すクライアント実行型が向きます。
ただしAgents SDKの標準Runnerは、クライアント実行型のtool_search_callを自動処理せず、呼び出されると例外になります。Responses APIを手動でオーケストレーションする必要があります。方式選択は「自前検索が必要か」で決めるべきです。
4. 検索と認可を分離する
defer_loadingは、ツール定義を後から読み込む指定であって、実行権限を奪う指定ではありません。利用者に見せてよい名前空間の絞り込み、ツール実行時の認可、引数検証、承認ゲートは別に実装します。
また、実行ログには最終的な関数呼び出しだけでなく、tool_search_callとtool_search_outputも残します。「なぜその道具が候補になったか」を追えないと、誤選択の原因をモデル、検索面、権限設定のどこへ戻すべきか判断できません。
PL視点では「ツール数」より探索経路をレビューする
レビューでは、登録ツールの総数だけを数えても不十分です。次の5点を確認します。
- 最初からモデルへ見える情報は何か
- どの名前空間が、どんな説明で検索されるか
- 1回の要求で何個のツール定義が読み込まれるか
- 検索結果が権限変更やテナント境界を越えないか
- 検索、実行、承認をトレースで結べるか
Tool Searchは、巨大なツール群を扱うためのルーターです。ルーターが賢くても、実行ゲートがなければ安全にはなりません。逆に、すべてを最初から渡して認可だけ強くしても、コンテキスト効率は改善しません。
まとめ
- 全ツール定義を先に渡さず、必要なサブセットだけ読み込む
- 個別関数の平置きより、10関数未満を目安に名前空間化する
- 固定在庫はホスト型、動的在庫はクライアント型を検討する
- 遅延読み込みを認可と混同せず、実行時に別途検証する
AIエージェントの工具箱が大きくなったら、モデルを替える前に「目次と実行鍵を分ける」設計を見直す。Tool Searchが示しているのは、ツール追加ではなくツールの公開範囲を管理する重要性です。