次の方法で共有


ツールの追加

前のページでは、エージェントで LLM をラップして、永続的な ID、手順、およびセッション管理を提供する方法を示しました。 しかし、これらすべての場合でも、エージェントはコンテンツ (テキスト、画像など) のみを生成できます。今日の株価を検索したり、電子メールを送信したり、データベースにクエリを実行したりすることはできません。 トレーニング中に組み込まれた知識や、プロンプトで提供したコンテキストから回答します。

ツール によってこのギャップが埋められます。 エージェントには、トレーニングデータを超えて現実世界と対話し行動する能力が与えられています。 ツールの追加は、エージェントを本当に役立つものにするために実行できる最も影響の大きい 1 つの手順です。

使用タイミング

次のいずれかの場合にエージェントにツールを追加します。

  • エージェントは、モデルのトレーニング データにないリアルタイムまたは外部データ (ライブ価格、天気、データベース レコード、検索結果) にアクセスする必要があります。
  • エージェントは、単にコンテンツを生成するのではなく、電子メールの送信、チケットの作成、API の呼び出し、ファイルの書き込みなどの アクションを実行 する必要があります。

考慮事項

考慮事項 詳細情報
Latency 各ツール呼び出しによってラウンド トリップが追加されます。モデルによってツール要求が生成され、コードによって実行され、モデルを続行する前に結果が返されます。 マルチツールは、これを複合します。
トークンのオーバーヘッド ツール定義 (名前、説明、パラメーター スキーマ) は、すべてのプロンプトに含まれます。 ツールが多いほど、会話履歴とモデルの応答に使用できるトークンが少なくなります。
デバッグの複雑さ 問題が発生した場合、原因は、モデルのツールの選択、選択した引数、またはツールの実行にある可能性があります。 推論 コードをまとめてデバッグしています。
信頼性 このモデルは、ツールを誤って呼び出したり、不正な引数を渡したり、必要ないときにツールを呼び出してしまうことがあります。 適切な説明と ツールの承認 は、これを軽減しますが、排除しないでください。

エージェントにツールが必要な理由

LLM Fundamentals で説明されているように、LLM はトークンを生成するようにトレーニングされます。これには、ツール呼び出しを表す特別な構造化形式が含まれます。 しかし、モデル自体は何も実行しません。 モデルの出力を解析し、実際の関数を実行し、結果を返すアプリケーション (またはエージェント フレームワーク) です。

つまり、ツール はモデルの 内容を変更せず、エージェントが 実行できることを変更します。 ツールがない場合、エージェントは対話者です。 ツールでは、演算子になります。

旅行予約エージェントについて考えてみましょう。 ツールがないと、フライトについて話し合い、一般的な知識に基づいて旅程を提案することができます。 ツールを使用すると、次のことができます。

  • フライト API でリアルタイムの可用性と価格を検索する
  • ユーザーの代わりにフライトを予約する

これらの各アクションには、ツール (エージェントが外部と対話するために呼び出すことができるコードの一部) が必要です。

ツール呼び出しループのしくみ

エージェント ツールを指定すると、Agent Framework によって ツール呼び出しループが自動的に管理されます。

┌──────────────────────────────────────────────────────┐
│  User: "What's the weather in Seattle?"              │
└──────────────┬───────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────┐
│  Agent sends messages + tool definitions to LLM      │
└──────────────┬───────────────────────────────────────┘
               ▼
       ┌───────────────┐
       │ LLM responds  │
       └───┬───────┬───┘
           │       │
     Tool call?    No ──────────────────────────┐
           │                                    │
           ▼                                    ▼
┌─────────────────────────────┐   ┌─────────────────────────────┐
│  Agent Framework executes   │   │  Final response:            │
│  the tool (e.g.,            │   │  "It's cloudy in Seattle    │
│  get_weather("Seattle"))    │   │   with a high of 15°C."     │
└──────────────┬──────────────┘   └─────────────────────────────┘
               │
               ▼
┌─────────────────────────────┐
│  Agent sends tool result    │
│  back to the LLM            │
└──────────────┬──────────────┘
               │
               └──────► (back to "LLM responds")

ツール呼び出しループを示す図:LLM は、最終的な応答を返す前に、ループ内の外部ツールとメモリと対話します。

重要なポイント:

  1. ループを記述する必要はありません。 Agent Framework は、モデルの応答でのツール呼び出しの検出、ツールの実行、結果のフィードバックを処理します。 ツールを定義します。フレームワークは、残りの部分を調整します。
  2. ターンごとに複数のツール呼び出し。 モデルでは、最終的な回答を生成する前に複数のツール (並列で呼び出される可能性があります) を呼び出したり、ツール呼び出しをチェーンして出力が次の応答を通知したりする場合があります。
  3. モデルは、ツールを呼び出すタイミングを決定します。 ユーザーの要求と指定したツールの説明に基づいて、モデルはツールが必要かどうかを判断します。 適切なツールの説明は、より良いツール選択につながります。

ヒント

最初のツールを追加し、このループの動作を確認する実践的なチュートリアルについては、「 手順 2: 作業の開始」チュートリアルの「ツールを追加する」を参照してください。

ツールの種類

Agent Framework では、いくつかのカテゴリのツールがサポートされています。 適切なエージェントの選択は、エージェントの実行が必要な内容と機能の場所によって異なります。

関数ツール

関数ツール は、エージェントに記述して登録するカスタム関数です。 これらはプロセスで実行され、ロジック、セキュリティ境界、エラー処理を完全に制御できます。

関数ツールは、次の場合に使用します。

  • エージェントが呼び出す必要があるカスタム ビジネス ロジックがある (データベースのクエリ、内部 API の呼び出し、計算の実行)
  • リソースにアクセスして環境内で実行するツールが必要です
  • あなたはコンパイル時の型の安全性とテストのしやすさを求めています。

関数ツールは、最も一般的で柔軟なツールの種類です。 ほとんどのエージェントはここから始まります。

MCP ツール (モデル コンテキスト プロトコル)

MCP は、アプリケーションが LLM にツールを提供する方法を定義するオープン標準です。 ツール ロジックを自分で記述する代わりに、REST API がエンドポイントを公開する方法と同様に、標準プロトコル経由で一連のツールを公開する MCP サーバー に接続します。

Agent Framework では、次の 2 つの種類がサポートされています。

フレーバー それは何か いつ使用するか
ホストされている MCP ツール Microsoft Foundry またはその他のプロバイダーによってホストおよび管理されている MCP サーバー インフラストラクチャを管理せずに、一般的な機能 (ファイル検索、コード実行など) へのターンキー アクセスが必要な場合
ローカル MCP ツール 自分で実行するか、任意のプロバイダーから接続する MCP サーバー カスタムまたはサード パーティ製の MCP サーバーがある場合、または独自の環境で実行するツールが必要です

MCP ツールは次の場合に使用します。

  • 事前構築済みの MCP サーバーには、必要な機能が既に用意されています
  • 共有サーバーを介して複数のエージェントまたはアプリケーション間でツールを再利用する場合
  • MCP エンドポイントを公開するサード パーティのサービスと統合している

プロバイダーホスト型ツール

プロバイダーによっては、プロバイダーのインフラストラクチャで実行される組み込みのツールが用意されています。ローカル コードは必要ありません。 これらには次のものが含まれます。

ツール 動作内容
コード インタープリター プロバイダーのインフラストラクチャ上のサンドボックス環境でコードを実行します
ファイル検索 プロバイダーにアップロードしたファイルを検索します
Web 検索 Web でリアルタイム情報を検索します

プロバイダーホスト型ツールは、次の場合に使用します。

  • ツールを自分でビルドまたはホストすることなく、コードの実行や Web 検索などの機能が必要です
  • プロバイダーは、要件を満たすマネージド バージョンを既に提供しています

プロバイダーホスト型ツールの可用性は、プロバイダーによって異なります。 プロバイダーの完全なサポート マトリックスについては、 ツールの概要 を参照してください。

一部の LLM プロバイダーは、OpenAI による Responses API など、推論中にインフラストラクチャでホストされたツールを実行する場合があります。 これらの推論サービスは、推論とツールの実行を組み合わせたセミエージェント サービスと考えてください。 基になるモデルの動作は変わりませんが、サービスの応答生成の一部としてツールの実行が行われる可能性があることを意味します。 これらのサービスはローカル ツールを実行できません。ローカル ツールは、独自のインフラストラクチャで実行する必要があります。

適切なツールの種類の選択

質問 レコメンデーション
カスタム ビジネス ロジックはありますか? 関数ツール - 独自の関数を記述して登録する
必要なものを既に実行している MCP サーバーはありますか? MCPツール — たとえばGitHub MCPサーバーなどに最初からビルドする代わりに接続します。
コードの実行、ファイル検索、または Web 検索は必要ですか? プロバイダーホスト型ツール - プロバイダーがサポートしているかどうかを確認する
複数のカテゴリのツールが必要ですか? 組み合わせ — エージェントは、関数ツール、MCP ツール、プロバイダーホスト型ツールを同時に使用できます

ツールの説明が重要

モデルは、 名前と説明に基づいてツールを選択します。 あいまいな説明では、ツールの選択が不適切になります。モデルが間違ったツールを呼び出したり、使用するツールをスキップしたり、正しくない引数を渡したりする可能性があります。

API ドキュメントを記述するのと同じ方法でツールの説明を記述します。ツールの動作、各パラメーターの意味、返される内容について説明します。 説明が明確であるほど、モデルの判断が良くなります。

ヒント

ツール定義 (名前、説明、パラメーター スキーマ) はプロンプトに含まれており、コンテキスト ウィンドウでトークンを使用します。 多数のツールを登録すると、オーバーヘッドが大きくなる可能性があります。 エージェントが実際に必要とするツールのみを登録します。

ツールの承認: 人間を介した

一部のアクションは機密性が高く、送金、レコードの削除、電子メールの送信などです。 エージェントでこれらのツールを自律的に実行したくない場合があります。 ツールの承認 により、ツールを実行する前に人間による確認が必要になります。

ツールが承認が必要とマークされると、エージェントは実行前に一時停止し、承認が必要であることを示す応答を返します。 アプリケーションは、これをユーザーに提示し、その決定を返す責任を負います。

このパターンは、多くの場合、ヒューマンインザループと呼ばれ、重要なアクションを処理する信頼できるエージェントを構築するために不可欠です。

よくある落とし穴

落とし穴 ガイダンス
ツールが多すぎます すべてのツール定義でトークンが使用されます。 エージェントの目的に関連するツールのみを登録します。
あいまいな説明 モデルに「データで何かをする」は役立ちません。 具体的には、「SKU による製品の可用性に関するインベントリ データベースのクエリ」を参照してください。
エラー処理なし ツールが失敗する可能性があります (ネットワーク エラー、無効な入力)。 明確なエラーメッセージを返して、モデルが問題を理解し、再試行するか、ユーザーに通知できるようにします。
過度に制限の緩いツール "任意の SQL クエリを実行" できるツールは、セキュリティ上のリスクです。 ツールを特定の明確に定義された操作に範囲を設定します。
機密性の高いアクションに対する承認がありません ツールで元に戻せない変更を加えることができる場合は、 ツールの承認 を追加して、人間をループに入れておく必要があります。

特記: コードインタープリターツール

LLM の基礎で説明したように、LLM は正確な計算と正式なロジックでエラーを発生させることができます。 これは、LLM はパターン マッチングに基づいてトークンによって応答トークンを生成するためです。実際には 計算されません。 2 つの大きな数値を乗算するように求められた LLM は算術演算を実行していません。これは、トレーニング データに基づいて、回答がどのように "見えるか" を予測しています。 これは驚くほど頻繁に機能しますが、例外的なケースでは予測がつかず失敗することがあります。

コード インタープリター は、エージェントがサンドボックス環境でコードを記述して実行できるようにすることで、これを解決します。 答えを推測する代わりに、モデルは正確に計算し、実行し、検証された結果を応答で使用するPython スクリプトを記述します。

モデルでは、同じ問題の解決を求められるたびに少し異なるスクリプトが記述される場合がありますが、結果 はほとんど 一貫している必要があります。

Warnung

コード インタープリターは、人間側の慎重な推論に代わるものではありません。 エージェントの作業を常に確認し、必要に応じて個別に結果を確認します。

エージェントが必要とする時にコードインタープリターを提供します。

  • 正確な計算 (財務モデリング、統計分析、単位変換) を実行します。おおよその "最適な推測" は許容されません。
  • データの変換または分析 - CSV の解析、行の集計、グラフの生成、構造化データの整形を行います。
  • ファイルの処理 - アップロードされたドキュメントの読み取り、コンテンツの抽出、形式の変換、または新しいファイルの生成を行います。
  • 独自の理由を検証します 。ユーザーに提示する前に、論理要求を検証するテスト コードを記述します。

ヒント

コード インタープリターは、プロバイダーホスト型ツールである場合があります。コードは、環境内ではなく、サンドボックス内のプロバイダーのインフラストラクチャで実行されます。 これにより、サーバー上で任意のコードが実行される心配なしに安全に使用できます。 セットアップの詳細については、 コード インタープリターのリファレンス を参照してください。

次のステップ

エージェントにツールが追加されたら、次の手順では、必要に応じて読み込むことができるエージェント ドメインの専門知識を提供する、手順、参照資料、スクリプトの移植可能なパッケージである スキル について学習します。

より深く進む: