コンセプト

AIは、つながるほど賢くなるとは限らない -- 142ツールで測ったMCPの文脈コスト

English version available
AIは、つながるほど賢くなるとは限らない -- 142ツールで測ったMCPの文脈コスト

最終更新日: 2026-10-15

接続を増やすことと、AIが必要な操作を正しく選ぶことは別です。サーバーで利用できる能力と、ホストが先に読む定義を分け、成功・安全・トークン・遅延を同じ課題で測ります。

この記事の静的計測とClaude正式30-runは、2026年7月29日の公開142ツール時点の記録です。現在の公開174ツールを測り直した結果ではありません。初期tokenは減りましたが、commonでは遅くなりました。読者が試す目的は、利用中ホストが必要な操作へ正しく届くか確かめることです。

先に結論 -- 問題は接続数ではなく、先に見せる定義量です

MCP公式ドキュメントは、MCPをAIアプリケーションと外部システムをつなぐオープン標準と説明しています。つながること自体には価値があります。カレンダー、文書、CRM、フォームへ同じAIクライアントから届けば、会話を実際の仕事へ進められます。

ただし、MCPは接続しただけでツール定義を軽くする規格ではありません。

MCPサーバーはtools/listで利用可能なツールとスキーマを返します。その一覧から、どの定義をいつモデルへ渡すかはホスト側の設計です。数個なら全件を先に見せても問題になりにくいでしょう。数百、数千へ増えると、先読みそのものが文脈コストになります。

したがって、見るべき数字は「何サービス接続したか」だけではありません。

接続できる能力
先にモデルへ見せる定義
実行時に必要な情報
人が承認する操作

この4つを分ける必要があります。

FORMLOVAで測った静的な文脈コスト

FORMLOVAは、フォーム作成、回答管理、メール、分析、ワークフロー、LINE連携など、公開174ツールを24カテゴリで提供しています。人が目的から始めやすいように、公式Workflowも50件用意しています。

一方、2026年7月29日のソース上の静的計測では143ツールを数え、当時の公開数142との差分1件は内部の会話トレース記録に使うrecord_conversation_traceでした。この履歴測定値と、現在の公開数174を混ぜてはいけません。

2026年7月29日にnpm run mcp:token-footprintで測った結果は次の通りです。

静的計測の対象文字数4文字/tokenの概算
MCP INSTRUCTIONS30,7417,686 tokens
ツールdescription(内部143件)54,81813,705 tokens
Zodの.describe()21,9175,480 tokens
合計107,47626,869 tokens

この表は、クライアントへ届く実際のJSONをtokenizerで測ったものではありません。ソース内の文字列を数え、4文字で1トークンと概算した静的測定です。JSON Schemaのプロパティ名、型、enum、必須項目、外側のJSON構造は含みません。文字列として評価できなかった.describe()も2箇所あります。

そのため「FORMLOVAを接続すると必ず26,869トークン使う」とは言えません。ホストによってinstructionsの扱い、スキーマ変換、キャッシュ、注入範囲、tokenizerが違うからです。

言えるのは、142ツール規模では、説明文だけでも無視できない量になるということです。そして、実際の転送コストはこの計測より大きくなる可能性があります。

MCPのTools、Resources、Promptsは制御主体が違います

大規模な接続を整理するときは、MCPの機能を一つの「全部モデルへ渡す箱」と考えない方が分かりやすくなります。

MCPのServer conceptsでは、3つの主要機能を次のように分けています。

機能役割主な制御主体
Toolsモデルが呼び出す操作model-controlled
Resourcesアプリケーションが選んで文脈へ入れるデータapplication-controlled
Promptsユーザーが明示的に選ぶテンプレートuser-controlled

この分担は、文脈配分のヒントになります。

Resourcesは、アプリケーションが必要な部分を選び、検索し、文脈へ入れられます。Promptsは、ユーザーが目的に合うものを選べます。Toolsも「利用可能であること」と「全定義を常時モデルへ見せること」を分けられます。

FORMLOVAの50件の公式Workflowは、MCPプロトコルのツール検索そのものではありません。業務目的から使い方を見つけるためのプロダクト上のカタログです。Workflow Placeからレシピを見つける方法で人の選び方を助けますが、ホストがモデルへ注入するツール定義を自動で減らす機能ではありません。

過去の142ツール実験では、能力を維持して定義を後から読みました

ここが一番大切です。

FORMLOVAはライト版のMCPを別URLで提供していません。2026年7月29日の実験では、単一の/api/mcpと当時の142本のネイティブツールを維持し、tools/callの経路、スキーマ、安全確認も削りませんでした。現在の公開registryは増えていますが、実測の対象は当時のsnapshotです。違うのは、ホストが最初から全定義をモデルへ入れるか、必要な定義だけを後から読むかです。

FORMLOVAのsearch_toolsとget_tool_detailsは、認証済み・読み取り専用の発見機能です。前者は候補を短いmetadataで返し、後者は1候補の完全な定義を返します。ただし、この2本だけで初期schemaが減るわけではありません。ホストが142本を先に注入した後で呼べば、初期文脈はすでに消費されています。今回のClaude実測で初期削減の主役になったのは、Claude Code側のToolSearchです。

OpenAIの公式Tool Searchでは、Responses APIへtool_searchを追加し、MCP定義へdefer_loading: trueを指定します。対応はGPT-5.4以降です。モデルは最初にMCPサーバーの名前と説明だけを見て、必要になった関数定義を検索して読み込みます。

Claude Codeの公式MCPドキュメントでは、ToolSearchが既定で有効です。MCPツール定義を最初から入れず、必要なものだけを発見します。小さなツール集合では検索の1往復がかえって遅くなる場合もあるため、これは万能な速度改善ではありません。

ホスト別の確認境界は次の通りです。

ホスト2026-07-29時点で確認したことまだ言えないこと
Claude Code142本を維持したToolSearchの正式30-runCritical 6 / Formal 60の性能合格
OpenAI Responses API公式tool_search + MCP defer_loading: true、GPT-5.4以降FORMLOVAでの正式token・遅延実測
CodexFORMLOVAの発見・ネイティブツール到達token削減率
ChatGPT Web読み取り専用の機能・UX成功ToolSearch、progressive discovery、正確なtrace、provider token

よく使われる形は3段階です。

  1. Catalog: 名前と短い説明から候補を探す
  2. Inspect: 候補ツールだけ完全な入力スキーマを読む
  3. Execute: 選んだツールを呼び出し、必要な承認を挟む

サーバー側の責任は、検索されても意味が伝わる名前、説明、スキーマ、権限境界を提供することです。ホスト側の責任は、現在の依頼、利用者の権限、利用可能な文脈量に合わせて、モデルへ見せる範囲を決めることです。

ツールを隠せばよいわけでもありません。公開、送信、削除などの重要操作が検索から漏れれば、仕事は完了しません。常時見せる少数の中核ツール、検索対象にする長い裾野、実行前に人へ戻す操作を分ける設計が必要です。

ツール数ではなく、一つの受付が作れるかを試す

以下は試用の依頼例で、今回の改稿で実行・実測した結果ではありません。まず検証用の非公開下書きで確かめます。

FORMLOVAで勉強会の受付を非公開で下書きしてください。名前、メール、希望テーマ、任意の質問を聞きます。作成と確認に必要な操作を見つけ、保存された項目とプレビューを示してください。公開・送信・他サービス接続はしません。ホストがusageや遅延を示す場合だけ実測値を別記録にし、ツール数から削減率を推測したり、過去実験の割合を今回の結果としたりしないでください。

次に進む前に、ここを確認します。

  • ホストが実際の作成/確認操作へ到達したか。
  • 保存済みの非公開フォームと項目が依頼に一致し、PC/スマホで読めるか。
  • 遅延・usage・失敗・承認を過去の結果と分けて観測したか。

自分のAIクライアントで、受付を一つ試す

Freeで下書き・プレビューと通常の回答確認を試せます。ツール検索やusage表示はAIクライアント次第で、削減率を保証する登録ではありません。

無料で受付作成を試す

登録・メール確認後、対応AIクライアントに接続し、上の依頼文を貼り付けます。保存された下書きを確認してから公開を判断してください。AIクライアント側の契約・利用条件は別です。

Claude正式30-runで分かったこと

2026年7月29日、claude-sonnet-5を使い、同じ142本のregistryでBaselineとCandidateを比較しました。source commitはbdfc4ffdです。よく使うツール、長尾ツール、ツール不要の3 promptを、各conditionで5回ずつ実行しました。expected 30 / observed 30、missing 0、skip 0です。全runで処理成功、機能assertion、Safety assertionがpassしました。

Initial tokensとTotal inputは、Claudeが返したprovider-reported usageに基づく値です。prompt別medianは次の通りです。

PromptInitial tokens Baseline→CandidateTotal input Baseline→CandidateWall latency Baseline→Candidate
common63,258 → 1,509126,968 → 11,1978.476秒 → 10.437秒
long-tail63,270 → 1,521127,323 → 10,62011.254秒 → 11.419秒
no-tool63,175 → 1,42663,175 → 1,4264.420秒 → 3.465秒
PromptInitial削減Total削減Latency差
common97.614531%91.181243%+1.960457秒
long-tail97.596017%91.659009%+0.165039秒
no-tool97.742778%97.742778%-0.955896秒

Candidateはcommonとlong-tailでToolSearchを各runちょうど1回使い、必要なネイティブツールへ到達しました。no-toolではToolSearchもネイティブツールも0回でした。単一/api/mcp、全142本、定義digestは前後で一致しています。サーバーをライト版へ分割した結果ではありません。

一方、速度は一律に改善していません。commonは約1.960秒、long-tailは約0.165秒遅く、no-toolは約0.956秒速くなりました。ToolSearchの追加往復と、初期文脈を小さくする効果のどちらが勝つかはpromptで変わります。

この30-runは能力ゲートです。「必要なツールを見つけられるか」「不要なツールを呼ばないか」「安全性が退行しないか」を確認しました。Critical 6 scenarioを各condition 5回で回すFormal 60は未完了です。したがって、ここで示した削減率を全業務、OpenAI、Codex、ChatGPTへ一般化したり、製品全体が速くなったと断定したりはできません。

Anthropicの85%例は、FORMLOVA実測の補助資料です

段階的発見の効果を示す一次資料として、AnthropicのAdvanced Tool Useがあります。

同社の例では、50以上のMCPツールをすべて先読みする構成で、仕事を始める前の文脈消費が約77K tokensでした。Tool Search Toolを使う構成では約8.7K tokensとなり、85%削減したと報告しています。

これはAnthropicの構成と社内テストです。上のFORMLOVA正式30-runとは別の測定であり、同じ分母として比較できません。

FORMLOVAの約26,869 tokensは、ソース文字列を4文字/tokenで換算した静的補助値です。Anthropicの77Kと8.7Kは、同社のツール検索構成で測った総文脈消費です。対象、tokenizer、システムプロンプト、スキーマ、ホスト実装が違うため、数字を直接比較して「FORMLOVAでも85%減る」とは言えません。

参考にできるのは割合ではなく、方法です。

全件を取得できる状態は維持する
全件を最初からモデルへ入れない
依頼に合う候補だけを探す
完全な定義は必要になった時点で読む

この順番なら、能力を捨てずに文脈を守れます。

2026-07-28版は正式リリース済みです

文脈配分と、プロトコルの状態管理も分けて考える必要があります。

MCP公式ブログが公開候補(RC)として案内していた2026-07-28版は、その後正式仕様として確定し、Tier 1 SDKの対応も完了しています。ステートレスなコア、Extensions、Tasks、認可強化などを含みます。stableだった2025-11-25版に代わり、2026-07-28が現行の最新仕様です。

ステートレスなコアは、接続状態を暗黙のセッションへ抱え込まず、通常のHTTP基盤でルーティング、キャッシュ、追跡をしやすくする変更です。「AIが忘れるようになる」という意味ではありません。フォームの下書き、認証、業務の進行状態は、アプリケーション側で明示的に管理する必要があります。

そして、ステートレス化だけでツール定義が自動的に絞られるわけでもありません。tools/listをキャッシュしやすくすることと、その全定義をモデルへ注入することは別の判断です。

大規模MCPで先に決めたい6つのこと

142ツールを作った経験から、機能追加の前に確認したい項目は6つあります。

判断確認すること
測るinstructions、description、入力スキーマを別々に測る
閾値を持つ文脈ウィンドウの何%を超えたら段階的発見へ切り替えるか
検索前に絞る利用者の権限、プラン、環境で呼べないツールを候補から外す
中核を残す認証確認、状態確認、検索など頻出の少数は常時見せる
承認を分ける読む操作と、送信・公開・削除など外部影響のある操作を分ける
条件別にライブ検証するtoken量だけでなく選択精度、遅延、失敗時の回復をprompt別に測る

カテゴリ分け、Workflow、サーバー側のsearch_toolsは、人とモデルが目的を見つける助けになります。でも、それだけで初期schemaは減りません。最終的には、ホストの遅延投入を有効にし、実際のクライアントでtoken、遅延、成功、安全を一緒に測る必要があります。

AIの知性は、接続数より文脈の配分で変わります

MCPは2025年12月、Linux Foundationが設立したAgentic AI Foundationの創設プロジェクトの一つになりました。共通基盤として広がれば、AIが利用できるサービスとツールはさらに増えます。

だからこそ、「全部つなぐ」と「全部読ませる」を同じにしないことが大切です。

FORMLOVAに174の公開ツールがあることは、フォーム運用へ届く能力の広さを示します。Claudeの30-runでは、単一MCPと全142本を維持したまま必要な定義へ到達し、初期tokenを大きく減らせました。ただし、commonでは遅延が増え、Critical 6 / Formal 60は未完了です。必要なときに必要な定義だけを見つけ、危険な操作では人へ戻し、条件別の性能まで測って初めて、機能数が実務の価値へ変わります。

MCPの価値は、AIへ無制限に情報を押し込むことではありません。外部世界へ届く能力を保ちながら、今の仕事に必要な文脈を配分できることです。

参考にした一次資料

接続ガイド: FORMLOVAをMCPクライアントに接続する

次に試すこと

過去実験の分母は変えず、自分のクライアントでは保存された下書きができるかから評価してください。成功・遅延・安全を観測してから対象を広げます。

関連ガイドと参照資料

執筆・確認情報

この記事はFORMLOVAの開発者が、2026年7月29日時点のdocs/SPEC.md、MCPツール登録ソース、静的計測スクリプト、source commit bdfc4ffdのClaude正式Phase 1 artifact、MCP・OpenAI・Claude・Anthropicの公式一次資料を照合して執筆しました。現在の公開数は174ツール・24カテゴリ、公式Workflowは50件です。2026年7月29日の内部静的計測は143件で、record_conversation_traceを含みます。4文字/tokenはライブtokenizerではない概算です。Claude結果は30/30の能力ゲートであり、Critical 6 / Formal 60の性能検証は未完了です。Codexのtoken削減率は未測定です。ChatGPT Webは読み取り専用の機能・UX成功だけを確認しており、ToolSearch、progressive discovery、正確なtrace、provider tokenは未検証です。MCP 2026-07-28版は2026-07-28に正式リリース済み(Tier 1 SDK対応済み)であり、現行の最新仕様です。

次の一歩

自分のフォームで、この記事の方法を試す

無料プランでフォームの作成・公開、回答の検索・ステータス管理、CSV・Excel出力まで使えます。

登録・メール確認の後、対応するAIチャットへ接続して始めます。

最終検証日:

この記事をシェア

執筆者

@Lovanaut
@Lovanaut

FORMLOVAの開発者。「ラバ = ラブ」の想いで、優しいサービスを作り続けています。

同じカテゴリの記事