---
title: "AIエージェントはどのようにツールを選ぶのか：エージェントによる発見のメカニズム"
description: "Claude、ChatGPT、CursorがどのMCPサーバーを呼び出すかを決定するメカニズムの内部。どのシグナルが重要で、選ばれるツールになるにはどうすればよいか。"
canonical_url: "https://getminds.ai/blog/ja/how-ai-agents-choose-tools-mcp-discovery-mechanics"
last_updated: "2026-06-02T02:51:07.157Z"
---

# AIエージェントはどのようにツールを選ぶのか

マーケターがClaudeに「ドイツのB2B SaaS向けの合成顧客パネルを探して」と尋ねると、モデルは検索エンジンを開きません。現在セッションに接続されているすべてのMCPツールの説明を読み、それらをランク付けして1つを選びます。このランキングこそが、ツール発見におけるインターネットの新たなフロントページであり、そのために最適化している人はほとんどいません。

本記事ではその内幕を明らかにし、2026年現在、ランキングが実際にどのように機能しているのか、どのようなシグナルが影響を与えるのか、そしてMCPサーバーを提供するすべてのチームにとっての実践的な意味合いを解説します。

## エージェントの文脈における「発見」の意味

区別すべき2つの発見レイヤーがあります。

*レイヤー1、レジストリレベル。* ユーザー（またはエージェント自身）がディレクトリでMCPサーバーを見つけ、クライアントに接続します。これはブラウザスタイルの発見です。エージェントフレンドリーなレジストリ、OAuthフロー、「このコネクタを追加」ボタンなどです。MCPレジストリ、Anthropicのディレクトリ、OpenAIのApps SDKディレクトリ、そして`mcpmarket.com`はすべてこの役割を果たします。ユーザーが「接続」をクリックすると、サーバーはエージェントのツールリストに追加されます。

*レイヤー2、セッション内での発見。* ユーザーがメッセージを送信するたびに、エージェントはどのツールを呼び出すか（もし呼び出すなら）を決定しなければなりません。これが実際に利用を左右するレイヤーです。エージェントが常に別のツールを選ぶため、サーバーが接続されていても何ヶ月も呼び出されないことがあります。ここで本当のランキングが行われますが、このことについて語る人はほとんどいません。

この記事の残りの部分では、レイヤー2について解説します。

## エージェントが実際に何を見ているか

MCPサーバーが接続されると、公開するすべてのツールを記述したハンドシェイクを送信します。エージェントはツールごとに以下を受け取ります。

- 名前（例：`create_panel`）
- 短い説明（1～3文、サーバー作成者が記述）
- 入力パラメータのJSONスキーマ
- オプションの構造化メタデータ（アノテーション、例、戻り値の型）

これがすべてです。エージェントはあなたのウェブサイト、価格、ドキュメント、ブログを見ません。あなたの製品全体で最も影響力のある文章は、ツール登録時の説明文です。

これが意味するところは不都合な真実です。つまり、優れたツールであっても説明が曖昧であれば、平凡なツールでも説明が的確であれば、必ず負けてしまうのです。

## ランキングプロセスのステップバイステップ

ユーザーがメッセージを送信すると、エージェントはおおよそ次のように動作します。

1. *関連性の高いツールに絞り込む。* モデルは自身のコンテキスト（これまでの会話、ユーザーの最新メッセージ）を読み、候補セットを特定します。ツールセットが小さい場合（20ツール未満）、通常はすべてを考慮します。ツールセットが大きい場合は、まずフィルタリングを行います。
2. *説明の一致度でスコアリングする。* 各候補ツールについて、モデルはその説明がユーザーの意図とどれだけ一致するかを評価します。これはキーワードマッチではなく、ソフトなセマンティックマッチです。類義語は機能します。ドメイン言語も機能します。曖昧な説明は失敗します。
3. *呼び出しを構成する。* ツールが選択されると、モデルは会話のコンテキストからパラメータを埋めます。スキーマが曖昧なフィールド（例：パラメータ化されていない「options」オブジェクト）を要求するツールは、モデルが正しく呼び出せる自信が低いため、ペナルティを受けます。
4. *オプションで呼び出しを連鎖させる。* 複数ステップのタスクの場合、モデルは最初のツールを選んで実行し、結果を読み取って、これを繰り返します。構造化された、エージェントが読み取り可能な出力を返すツールは、フォローアップの呼び出しを獲得します。長文テキストを返すツールは、連鎖を停滞させます。

このすべては1回の推論パスで行われます。独立したランカーモデルは存在しません。テレメトリのフィードバックループも（まだ）ありません。決定は、説明とスキーマのみに基づいて行われます。

## 実際にランキングを動かすもの

観測されたエージェントの振る舞いから逆算すると、4つのことがツール選択に明らかに影響を与えます。

*説明の具体性。* 「市場調査を実行する」は、「オーディエンスペルソナに対して合成顧客パネルを実行し、要約された調査結果を返す」に負けます。説明が長いほど、モデルが掴むための手がかりが多くなるため、より多くのクエリに一致します。文字数には上限がありますが（ほとんどのエージェントは約500文字で説明を切り捨てます）、ほとんどのサーバーはその上限には遠く及びません。

*動詞-主語-目的語の構造。* エージェントは、ユーザーが使った動詞と一致する説明を持つツールを選びます。「顧客に尋ねる」は、`query_panel_responses`よりも`ask_panel`によく一致します。命名と説明の両方で、アクションを先頭に置くべきです。

*具体的な出力形式。* 「`panel_id`、`responses`、`summary`フィールドを持つJSONオブジェクトを返す」は、「パネル結果を返す」に勝ちます。エージェントは、出力で何をすべきか予測できる場合に、そのツールを呼び出す可能性が高くなります。

*スキーマの解析可能性。* モデルがコンテキスト（テキスト説明、数値カウント）から埋められる必須フィールドを持つスキーマは呼び出されます。呼び出しの途中でユーザー入力が必要な必須フィールド（認証トークン、内部ID）を持つスキーマはスキップされ、エンドツーエンドで実行できるツールが優先されます。

## （まだ）ランキングを動かさないもの

2026年現在、重要であるかのように語られていますが、実際にはそうではないもののリストです。

- *レジストリでのスター数。* レイヤー1での発見可能性には関係しますが、レイヤー2では無関係です。
- *SEOスタイルのキーワードスタッフィング。* モデルはセマンティックマッチを行うため、キーワードマッチは行いません。説明に「agentic research AI panels MCP」を詰め込んでも意味がありません。
- *ブランド認知度。* セッション内レイヤーでは、モデルは未知のブランドよりも確立されたブランドを好むことはありません。説明の質が勝敗を分けます。
- *500ms未満のレイテンシ。* モデルはランキング時にツールの呼び出し時間を計測しません。遅くても便利なツールは依然として呼び出されます。

これは変わるでしょう。評価スコア、呼び出し後の満足度シグナル、スパム対策ランキングはすべて、主要なホストのロードマップにあります。今日、てこになるのは説明です。

## スパム対策の問題

これらすべての自然な帰結として、誰でも非常に長く、キーワードを多用した説明を書くことでランキングを操作できてしまいます。ホスト側もこれを認識しています。Anthropic、OpenAI、そしてMCPレジストリのメンテナーは皆、2026年後半から説明文の詰め込みを非推奨にし始めています。

2つのスパム対策メカニズムが登場しつつあります。

*スキーマ検証。* 宣言されたスキーマが実際のレスポンス形式と一致しないツールは、ランクが下げられるか削除されます。

*クロスホスト評価スコアリング。* MCPレジストリは、登録済みサーバーに対してプロンプトを実行し、正解率スコアを報告する公開評価スイートを試験的に導入しています。評価に失敗したサーバーは警告を受け、その後削除されます。

2026年半ばの時点ではどちらも完全には稼働していませんが、両方とも導入される予定です。取るべき姿勢は、単にキーワードで一致するだけでなく、品質でスコアリングされる世界で勝てる説明を書くことです。

## サーバー作成者への実践的な推奨事項

MCPサーバーを提供している場合、以下の変更を行うことで、セッション内での選択率が目に見えて向上します。

1. *すべてのツールの説明を、ユーザーが使いそうな動詞から始まるように書き直す。* 「パネル実行ツール」ではなく、「ターゲットオーディエンスに対して顧客調査パネルを実行し、要約された回答を返す」のようにします。
2. *説明に出力形式を明記する。* 「`responses`配列、`themes`フィールド、`summary`フィールドを持つJSONオブジェクトを返す」のように記述します。これにより、エージェントは自信を持ってフォローアップの呼び出しを連鎖させることができます。
3. *必須フィールドをコンテキストから埋められるようにする。* フィールドが内部IDを必要とする場合は、名前を受け入れてサーバー側で解決するようにします。エージェントは、必須フィールドを予測できないツールをスキップします。
4. *各ツールの説明に200～400文字を使用する。* 100文字未満では内容が薄すぎます。500文字を超えるとほとんどのクライアントで切り捨てられます。
5. *ツール数を見直す。* 30を超えるツールを持つサーバーは、エージェントがランク付けする前にフィルタリングされてしまいます。可能な限り、関連するツールを統合してください。60個のツールを持つサーバーが、12個のツールを持つサーバーよりも選択率が悪いケースを見てきました。これは、モデルがロングテールのツールを目にすることがないためです。

これらの説明を最も重要なコピーとして扱うチームは呼び出されています。一方、レジストリの付随的な作業として扱うチームは呼び出されていません。

## 今後の展望

このメカニズムは今後12ヶ月でより強固なものになるでしょう。3つの変化が予想されます。

*評価ベースのランキングが本番稼働する。* 自動評価による品質スコアがレジストリのリストに表示され始め、少なくとも1つの主要ホストでセッション内の選択に影響を与えるようになります。

*エージェントのテレメトリフィードバックループ。* 「過去のセッションで満足のいく結果を出したツールはより高くランク付けされる」という機能を最初に出荷した主要ホストが、他を圧倒するでしょう。これはエージェントにおけるクリックスルー率に相当し、最適化の目標を変えることになります。

*垂直的なエージェントエコシステム。* マーケティングエージェント、セールスエージェント、リサーチエージェントは、それぞれ独自の標準的なツールスタックを開発するでしょう。すべてのディレクトリに掲載されることよりも、自社のバーティカルでデフォルトになることの方が重要になります。

この移行期に勝利するツールは、MCPの説明を自社製品のフロントページとして扱うツールです。そうでないツールは、基盤となるサービスがどれほど優れていても、呼び出されることはないでしょう。

---

そもそもなぜエージェントが新たな買い手となるのか、その全体像については、[AIエージェントは新たなマーケティングの買い手](/blog/ai-agents-new-marketing-buyer-agentic-discovery)をご覧ください。実践的な設定については、[Claude、ChatGPT、Cursorから顧客パネルを実行する方法](/blog/run-customer-panels-from-claude-chatgpt-cursor-mcp-guide)をご覧ください。適切に記述されたMCPサーバーが本番環境でどのように見えるかを確認するには、[Minds MCP](/mcp/overview)をご覧ください。