ツールとMCP

ツール呼び出しのみを行うエージェントは、作業をあなたに委ねてしまいます。このページでは、プラットフォームがどのように「行動」させるかを扱います：ツールが呼び出された際、ターン内で何が起こるのか、それが会話を破壊しないようにするにはどうするか、そしてあなたのシステムがどのように接続されるかです。

ツールループ

1つのターンは単一のモデル呼び出しではありません。モデルは回答するか、またはツールの呼び出しを要求する可能性があります。ツールが呼び出されると、その結果が会話に追加され、モデルはその結果を手にして再度実行されます。その後、別のツールを呼び出すこともあります。ループは、モデルが回答を生成するか、または反復制限に達するまで続きます。

この制限は重要です：これがなければ、ツールを呼び出し続けるモデル（実際に一般的な失敗）は無限に実行され続け、トークンを消費し、顧客は永遠に来ない返信を待ち続けることになります。

ループが行わないのは、蓄積されたすべてのものから顧客への回答を書き出すことです。ツールが終了すると、リクエストはクリーンに再構築されます — エージェントの指示、短い要約、このターンで見つかった事実、そして質問 — 、そしてその返信が生成されます。その理由は計画的なものであり、Why agents get worse as context grows の主題です。

モデルの実行前にどのツールを決定するか

上記のループは、モデルが正しいツールを要求すると仮定しています。しばしばそれは正しくありません — そしてその理由は正確に述べる価値があります。なぜなら、それは知識の問題ではないからです。

人々は、ソフトウェアが望むような形式でリクエストを表現しません。「他にもありますか？」は、ツールも、主題も、数量も指定していません；それらは2つのメッセージ前でした。そのモデルに渡されると、「それら」とは何を指すのかを解決し、ツールが関与しているかどうかを決定し、どのツールかを見極め、その引数を埋め、そして良い返信を書く必要があります — 1つのサンプルで5つの仕事です。通常、投げ出されるのはツール呼び出しであり、顧客は商品リストがあるべき場所に文章の塊を受け取ることになります。

これは1種類のリクエスト以上のものをカバーします。「他にもありますか？」はアイテムの表示を望み、「読書レベル別の書籍の分布を見せて」はカタログをカウントして描画することを望みます。2つ目のケースで放置されると、モデルはそれを実行するのではなく作業を叙述します — 私たちは1つのモデルが「データベースを照会させてください」と6回言い、その後SQL文を返信に出力するのを見ました。これはツールの入力であり、読者が目にしてはならないものです。

したがって、ツールが明確に示唆されているリクエストの場合、プラットフォームはまず一歩を踏み出します。1つの小さく、安価な呼び出しが会話を読み、事実のみを返します — 何が求められているか、そしてその数量です。それは会話のみを見ます：エージェントの指示も、取得された資料もありません。そのため、回答に逸脱することはありません。その後：

• プラットフォームが指示を書きます、ツールが実際に応答する wording で、欠落した文脈を補填して；
• そのターンには1つのツールのみが表示され、選択するものがなくなります。

重要なのは最初のものです。モデルにリクエストを書き換えさせることは、測定可能な変化をもたらしません — 異なる言葉での同じ推測です。プラットフォームがツールの定義からその文章を構成することは、セルフホストされた35Bモデルを同じリクエストで**16%から70%**に引き上げました。ツールに届く wording はソフトウェアが計算できるものなので、ソフトウェアはそれを計算します — チャートデータやカードの内容をモデルの手に渡すのではなくサーバーに留めるのと同じ推論です。

プラットフォームが意図的に行わない第3のことがあります：プロトコルレベルで呼び出しを強制することです。このオプションは存在し、数をさらに引き上げます。しかし、それをデコーディング制約として実装するセルフホストサーバーでは、モデルを反復ループに押し込みます — 私たちが測定したとき、おおよそ4ターンに1回、そのうちの1回は同じフラグメントを2分間出力し続けました。決して届かない返信は、文章で回答するものよりも悪いです。

知っておくべき2つの結果があります。構成された指示が英語であっても、返信は顧客の言語で戻ってきます — それはプラットフォームによって固定されており、モデルに気づかせることに委ねられていません。また、ターンが何かを渡すはずだったのに文章を渡した場合、プラットフォームはそれに気づき、もう一度問いかけ、スキップされたステップを特定し、正直な出口を提供します（「該当する資料がない場合はそう言ってください」）— なぜなら、出口なしで圧迫されたモデルはそれを発明するからです。8つの製品を説明して1つも表示しないエージェントは、待っている人にとって、質問を無視したエージェントと全く同じように読めます。

このチェックは外見ではなく、何が戻ってきたかを見ます。結果の形状を学んだモデルは、作業を行わずに形状を書きます — 空のブロック、または実行されなかったルックアップへの参照。どちらも、何も配信されなかったものとして扱われます。

この追加のステップは数分の1秒の費用しかかからず、それを必要とするように見えるメッセージでのみ実行されます — 通常の質問には何もかかりません。実行中、会話は自分が何をしているかを伝えます。意思決定のいずれかの部分が不明確な場合、ターンはそれなしでそうであったかのように正確に進行します。

2つの予算、1つではない

ツールの結果は、会話のコンテキストが破壊される最も一般的な方法です。1つのCRMクエリは、モデルのコンテキストウィンドウ全体よりも多くのテキストを返すことがあります。

個々の結果を制限することは明白な防御策ですが、不十分です。結果は反復 across 蓄積されます — 会話は成長する一方です — なので、最悪のケースは、反復制限に、反復あたりの複数のツールを掛け、さらに結果あたりの制限を掛けたものです。各結果は独自の制限を通過し、合計は依然としてオーバーフローします。

したがって、2つの予算があります：結果あたりの制限と、全体のターンのための集計予算です。集計が枯渇すると、さらなる結果は追加されるのではなく、短いプレースホルダーに置き換えられます。

そのプレースホルダーに含まれる内容は、切り捨て自体と同様に重要です。静かに切り捨てられた結果は、none よりも悪いです。なぜなら、モデルは半分だけのレコードから推論していることを知る方法がないからです。切り捨て通知と枯渇プレースホルダーの両方は、コンテンツが不完全であることを明示し、モデルに持っているものから回答し、欠落した部分を発明しないよう指示します — 「最初の数件の注文しか見ることができませんでした」と言うエージェントと、自信を持って残りをでっち上げるエージェントの違いです。

切り捨ては、ツール名とサイズとともにログに記録されます。なぜなら、定期的に予算をオーバーフローするツールは、より少ないフィールドを返すべきであり、これは確認すべき設定問題だからです。

適切なツール呼び出しを出力しないモデル

すべてのモデルが構造化されたツール呼び出しを確実に生成するわけではありません；いくつかは、返信としてテキストとして呼び出しを出力します。それを失敗したターンとして扱うのではなく、ループはメッセージコンテンツからツール呼び出しを解析し、返信が顧客に届く前に壊れたフラグメントを削除します — そのため、モデルが調子を外しても、JSONが会話に漏れ出すのではなく、わずかに遅いターンに劣化します。

自分のシステムとの接続

ツールは2つの場所から来ます。

組み込みツールはプラットフォームに同梱されています — フォローアップのスケジュール設定、リマインダーの作成、連絡先情報のキャプチャ、スキルの呼び出し、ドキュメントの編集、チャートの描画、ウェブ検索。

これらの多くは、あなたが決定するものではありません。それらはすべてのエージェントに利用可能であり、それらを必要とするターンにアタッチされます、これがそれらが何もコストをかけないことを維持する理由です：訪問者のメッセージが使用する理由を与えないツールは、そのターンのリストにありません。そのため、コンテキストを一切占有せず、モデルが誤って選択するものも提供しません。それらを維持するチェックリストはなく、エージェントが電話番号を受け取る能力を静かに欠くような設定もありません。

スキルの独自のツールは例外であり、意図的にそうなります：それらはそのスキルがロードされた場合にのみ到着し、それ以前ではありません。能力パックは作業方法であり、ツールはその方法の一部です — それらを別々に渡すと、モデルは方法をスキップします。Skills and how one gets chosen を参照してください。

決定されるのは公開ソースからの回答です — このエージェントがウェブを検索し、見つけたものを読めるか、それともあなたの資料のみから回答するか。それは単一のスイッチです。なぜなら、それは単一の質問だからです：検索とフェッチは一緒にオンにされます。なぜなら、ページを見つけられるが読めないエージェントは、3つの設定の中で測定可能な最悪のものだからです。デフォルトではオフであり、オンにしている場合のエージェントの行動（ラベリング、レビューキュー）は、Retrieval で説明されています。

あなたのシステムはMCP経由で接続されます。 テナントはMCPサーバーを登録し、それらのツールはそのテナントのエージェントに利用可能になります。3つのトランスポートがサポートされています：ローカルサブプロセス用の stdio、およびリモートサーバー用の streamable_http と sse。ホストされたCRMや内部APIの場合、リモートHTTPサーバーが通常の選択です — プラットフォームの隣にインストールする必要はなく、接続はテナントごとです。

ツール定義がテナントごとに登録されているため、1つのテナントのエージェントが別のテナントのツールやエンドポイントを見ることは決してありません。

実践的な意味

• エージェントは文脈の途中で何かを検索し、実際の値で回答できます。
• 顧客にそれを行うよう伝えるのではなく、すでに実行しているシステムに予約、ファイル、記録できます。
• ツールがターンが保持できるものよりも多くの結果を返した場合、エージェントはギャップを妥当なフィクションで埋めるのではなく、その見解が部分的であったと言います。

回答するのではなく行動するビジネス上の議論は、Agents that act にあります。