AIエージェントを支える基盤技術④-1: Tool Use / Dynamic Tool Selection の仕組みと設計

はじめに

前回の記事では State Management（状態管理）について見てきました。

• Long-term Memory → 過去を覚える
• Context Compression → 必要な情報を取り出す
• State Management → 現在の状態を把握する

Long-term Memory によって過去の情報を記憶し、Context Compression によって必要な情報だけを取り出し、State Management によって現在の状態を把握できるようになりました。しかし、これだけでは AI エージェントは実際のタスクを完了できません。なぜなら、

次に何を実行するべきなのか

はまだ決まっていないからです。たとえば、State として

status: approval_waiting

が管理されていたとします。（つまり、State はコンテキストの中だけに保持されるのではなく、外部ストレージへ保存され、必要なタイミングで再び読み込めるようになっています。）

エージェントは「現在は承認待ちである」ということは理解できます。しかし、

• 承認依頼メールを送るべきなのか
• Slack で通知するべきなのか
• Google Calendar で日程調整を行うべきなのか

までは自動的には分かりません。実際の業務では、

• Gmail
• Google Calendar
• Google Drive
• Slack
• Salesforce
• GitHub
• Jira
• BigQuery

など数多くのツールが存在します。そのため AI エージェントには、

現在の状況に応じて最適なツールを選択する

仕組みが必要になります。本記事では、この問題を解決する Tool Use と Dynamic Tool Selection について見ていきます。

Tool Useとは何か

「Tool Use」を直訳すると、「ツールを利用すること」を意味します。しかし、Agent Engineering における Tool Use は単にツールを呼び出すことだけを指すわけではありません。AI エージェントは現在の状況を理解した上で、

• 利用可能なツールを把握する
• 適切なツールを選択する
• ツールを実行する
• 実行結果を利用する

という一連のプロセスを通してタスクを実行します。つまり、Tool Use とは、

AI エージェントが外部ツールを利用して実際の処理を実行する仕組み

のことです。言い換えると、Tool Use は単にツールを呼び出すことではなく、

ツールの選択から実行結果の活用までを含む仕組み

だと言えます。

なぜTool Useが必要なのか

通常の LLM はテキストを生成することしかできません。しかし、実際の業務では

• メール送信
• カレンダー更新
• データベース検索
• GitHub 操作

などが必要になります。そのため Agent はツールを利用して外部システムと連携します。

出張手配の例を考えてみましょう。ユーザーが

来月の大阪出張を手配してほしい

と依頼したとします。LLM はテキストを生成することしかできませんので、出張プランを考えることまではできます。しかし、

• 航空券予約
• ホテル予約
• カレンダー登録

は実際には行えません。つまり、「考えること」と「実行すること」は別問題なのです。この「実行する」という問題を解決するのが Tool Use です。

Action = Tool ?

LLM は文章を生成することはできますが、現実世界へ直接働きかけることはできません。

2023年前後は、この制約をどのように乗り越えるのかが大きなテーマとなり、さまざまな Agent アーキテクチャや実装パターンが提案された時期でもありました。AI Agent が爆発的に注目され始めた頃には、

LLM に Action（行動）を与える

または

LLM + Memory + Planning + Action

という説明がよく使われていました。たとえば、

• メールを送信する
• 会議を登録する
• データを検索する
• 予約を実行する

といった Action を実現する仕組みとして Tool Use が利用されるようになりました。ただし、Action と Tool は同じものではありません。たとえば、

Action : ホテルを予約する
Tool : ホテル予約サービス

のように、

Tool は Action を実現するための手段

だと考えることができます。なお、近年では Action よりも Tool Use や Function Calling という表現が使われることが増えています。つまり、Tool Use によって AI エージェントは「考えるだけ」の存在から、「実行できる」存在へと進化したのです。

Dynamic Tool Selectionとは

「Dynamic Tool Selection」を直訳すると、「動的なツール選択」を意味します。Agent Engineering では、多数のツールの中から

状況に応じて最適なツールを選択する仕組み

を意味します。たとえば、

• 会議日程確認 → Google Calendar
• 顧客情報確認 → Salesforce
• ソースコード修正 → GitHub

のように、タスクによって利用するツールは変わります。

Tool Registry

実際の Agent は利用可能なツール一覧を保持しています。これを Tool Registry と呼びます。

Tool Registry には、

• ツール名
• 説明
• 入力パラメータ
• 出力形式
• 利用条件や権限情報

などが登録されています。

Tool Selection

Agent は Tool Registry を参照しながら、

現在のタスクに最も適したツール

を選択します。

前述したように、Dynamic Tool Selection とは、

状況に応じて最適なツールを選択する仕組み

のことです。実際には、Agent は Tool Registry に登録されたツールの中から、

現在のタスクに最も適したツールを選択する

ことになります。つまり、Tool Selection とは、

Tool Registry の中から最適なツールを選択する仕組み

だと言えます。

Tool Calling

ツールを選択した上で、実際にそのツールを呼び出して実行する必要があります。この処理を Tool Calling と呼びます。Agentは、

• ツール選択
• ツール呼び出し
• ツール実行
• 実行結果またはエラーの取得

を繰り返しながらタスクを進めます。

Tool Callingの処理を詳しく見る

上の図では、ツール選択から結果取得までを大きな流れとして示しました。この一連の流れを広い意味で Tool Calling と呼ぶこともあります。一方、各処理を詳しく見ると、Tool Selection、Tool Calling、Tool Executionにはそれぞれ異なる役割があります。

• Tool Selection：使用するツールを選択する
• Tool Calling：ツール名と引数を指定し、実行を要求する
• Tool Call Validation：ツール名、引数、権限などを検証する
• Tool Execution：検証されたTool Callに基づいてツールを実行する
• Observation & Evaluation：実行結果やエラーを解釈し、次の行動を判断する

出張手配の例で考えてみましょう。Agentがホテル検索・予約ツールを選択しただけでは、ホテルの検索は実行されません。検索を実行するには、ツール名と検索条件を引数として指定したTool Callを生成し、実行基盤へ渡す必要があります。たとえば、本社周辺のホテルを検索する場合は、次のようなTool Callを生成します。

{
  "name": "search_hotels",
  "arguments": {
    "location": "本社周辺",
    "check_in": "2026-10-15",
    "check_out": "2026-10-17",
    "max_price_per_night_jpy": 20000
  }
}

ここでは例を単純にするため、検索場所を「本社周辺」と表現しています。実際のツール呼び出しでは、Agentがユーザーや組織のコンテキストから本社の住所やPlace IDなどを取得し、検索ツールが解釈できる値として渡す必要があります。本社の所在地を特定できない場合は、ツールを呼び出す前にユーザーへ確認します。

また、これはTool Callの構造を説明するために簡略化したJSON形式の例です。実際の形式やフィールド名は、利用するAPI、プロトコル、エージェントフレームワークによって異なります。ただし、多くの場合は、呼び出すツールの名前と、そのツールへ渡す引数を構造化して表現します。

実行基盤はTool Callを受け取ると、指定されたツールが存在するか、引数の形式が正しいか、実行に必要な権限があるかを検証します。検証に成功するとツールを実行し、検索結果をAgentへ返します。検証や実行に失敗した場合は、エラー情報を返します。

Agentは実行結果を受け取ると、その内容を現在の状態へ反映し、目標を達成できたかを評価します。まだ情報が不足している場合は、別のツールを選択したり、引数を修正して同じツールを再度呼び出したりします。目標を達成した場合はツールの呼び出しを終了し、最終的な回答を生成します。

ホテル検索から予約まで

ホテルの検索と予約は、通常、1回のTool Callで完了するとは限りません。まずホテルの候補を検索し、条件に合う候補を比較します。その後、ユーザーの承認を得てから予約を実行します。

search_hotels
（ホテル候補を検索）
  ↓
候補を比較・絞り込み
  ↓
候補をユーザーへ提示
  ↓
ユーザーの承認
  ↓
book_hotel
（予約を実行）
  ↓
予約結果を確認

search_hotelsは候補を取得するためのTool Callです。一方、book_hotelは実際の予約を確定し、料金やキャンセル条件などの外部的な影響を発生させる可能性があります。そのため、この例ではAgentが検索結果から予約内容を勝手に決定するのではなく、ホテル、宿泊プラン、料金、キャンセル条件などをユーザーへ提示し、承認を得てからbook_hotelを呼び出します。

予約時には、検索結果に含まれるホテルや宿泊プランの識別子を使用し、次のような情報を指定します。

{
  "name": "book_hotel",
  "arguments": {
    "hotel_id": "hotel-123",
    "plan_id": "plan-456",
    "check_in": "2026-10-15",
    "check_out": "2026-10-17"
  }
}

この例も説明のために簡略化しています。実際には、宿泊者情報、部屋数、決済方法、キャンセル条件への同意など、予約サービスが要求する追加情報が必要になる場合があります。

ツールが増えすぎる問題

ツールを利用できるようになったことで、AI エージェントは「実行する」ことが可能になりました。しかし、新たな問題が発生します。たとえば、

• Google Calendar
• Gmail
• Slack
• Salesforce
• GitHub
• Jira
• Google Drive
• Notion

など多数のツールが存在します。すると今度は、

どのツールを使うべきか

という問題が発生します。

まとめ

今回は、AIエージェントを支える基盤技術の一つであるTool UseとDynamic Tool Selectionについて見てきました。AIエージェントが実際のタスクを完了するには、利用可能なツールを把握し、現在の状況に適したツールを選択・実行したうえで、その結果を次の判断へ反映する必要があります。そのために、次の仕組みが重要になります。

• Tool Registry：利用可能なツールの定義と仕様を管理する
• Tool Selection：現在のタスクに適したツールを選択する
• Tool Calling：ツール名と引数を指定して実行を要求する
• Tool Call Validation：ツール名、引数、権限などを検証する
• Tool Execution：検証されたTool Callに基づいてツールを実行する
• Observation & Evaluation：実行結果やエラーをObservationとして受け取り、その内容を解釈して次の行動を判断する

このように、Tool Useは単にツールを選択して呼び出すだけではなく、複数の処理を組み合わせて実現されます。Agentは、これらの処理を繰り返しながらタスクを進めます。

また、ホテル予約の例で見たように、ツールを呼び出せれば、すべてを自動実行してよいわけではありません。search_hotelsのように情報を取得する処理と、book_hotelのように外部システムの状態を変更する処理を区別し、必要に応じてユーザーの承認を得る設計が重要です。

Tool Useによって、AIエージェントは単に文章を生成するだけでなく、外部システムを通じて「現実世界へ働きかけることができるシステム」へと拡張されます。メール送信、予約処理、データ検索などが可能になることで、ユーザーの依頼を実際に遂行するAgentとして機能するようになります。

しかし、利用可能なツールの数が増えるにつれて、

• ツールごとに接続方法が異なる
• 実装や保守の負担が大きくなる
• 新しいツールを追加しにくくなる

といった新たな問題が発生します。

こうしたツール連携の課題に対応するための仕組みの一つが、MCP（Model Context Protocol）です。MCPを利用すると、Agentと外部ツールの接続方法を標準化しやすくなります。ただし、MCPは「どのツールを選択するか」を自動的に決める仕組みではありません。状況に適したツールを判断するTool Selectionと、Agentとツールの接続方法を標準化するMCPは、役割を分けて考える必要があります。そこで次回は、MCPの仕組みと設計について見ていきます。

本シリーズの関連記事は次のとおりです。

• AIエージェントを支える基盤技術④-1: Tool Use / Dynamic Tool Selection の仕組みと設計（本記事）
• AIエージェントを支える基盤技術④-2: MCP の仕組みと設計