最終更新日: 2026-07-31
AIへ接続するサービスを増やせば、使える能力は増えます。でも、接続数と賢さは同じではありません。仕事を始める前から大量のツール定義を読ませると、ユーザーの依頼、会話履歴、判断材料に使える文脈が狭くなるからです。
FORMLOVAのソースを静的に測ると、MCPの共通指示、ツール説明、入力項目の説明だけで107,476文字、4文字を1トークンとする概算で約26,869トークンありました。これはライブtokenizerの計測ではなく、JSON Schemaの構造部分も除いた下限寄りの補助値です。
その後、Claude Sonnet 5で正式な30-run能力ゲートも実施しました。初期入力tokenの中央値は3種類のpromptで97.59〜97.74%減りました。ただし、よく使うツールのpromptは約1.960秒遅くなっています。この記事の結論は「必ず速くなる」ではなく、「2026年7月29日の実験では同じ142ツールを維持したまま初期文脈を減らせたが、効果と遅延は条件別に測る必要がある」です。
この記事では、MCPフォームの一般的な定義ではなく、「大規模なツール群を、いつモデルの文脈へ入れるか」を扱います。MCPフォーム全体の入口はMCPフォームサービスまとめ、作成後の運用レイヤーを設計する理由はMCPフォームサービスとはに分けています。
先に結論 -- 問題は接続数ではなく、先に見せる定義量です
MCP公式ドキュメントは、MCPをAIアプリケーションと外部システムをつなぐオープン標準と説明しています。つながること自体には価値があります。カレンダー、文書、CRM、フォームへ同じAIクライアントから届けば、会話を実際の仕事へ進められます。
ただし、MCPは接続しただけでツール定義を軽くする規格ではありません。
MCPサーバーはtools/listで利用可能なツールとスキーマを返します。その一覧から、どの定義をいつモデルへ渡すかはホスト側の設計です。数個なら全件を先に見せても問題になりにくいでしょう。数百、数千へ増えると、先読みそのものが文脈コストになります。
したがって、見るべき数字は「何サービス接続したか」だけではありません。
接続できる能力
先にモデルへ見せる定義
実行時に必要な情報
人が承認する操作
この4つを分ける必要があります。
FORMLOVAで測った静的な文脈コスト
FORMLOVAは、フォーム作成、回答管理、メール、分析、ワークフロー、LINE連携など、公開138ツールを24カテゴリで提供しています。人が目的から始めやすいように、公式Workflowも50件用意しています。
一方、2026年7月29日のソース上の静的計測では143ツールを数え、当時の公開数142との差分1件は内部の会話トレース記録に使うrecord_conversation_traceでした。この履歴測定値と、現在の公開数138を混ぜてはいけません。
2026年7月29日にnpm run mcp:token-footprintで測った結果は次の通りです。
| 静的計測の対象 | 文字数 | 4文字/tokenの概算 |
|---|---|---|
| MCP INSTRUCTIONS | 30,741 | 7,686 tokens |
| ツールdescription（内部143件） | 54,818 | 13,705 tokens |
Zodの.describe() | 21,917 | 5,480 tokens |
| 合計 | 107,476 | 26,869 tokens |
この表は、クライアントへ届く実際のJSONをtokenizerで測ったものではありません。ソース内の文字列を数え、4文字で1トークンと概算した静的測定です。JSON Schemaのプロパティ名、型、enum、必須項目、外側のJSON構造は含みません。文字列として評価できなかった.describe()も2箇所あります。
そのため「FORMLOVAを接続すると必ず26,869トークン使う」とは言えません。ホストによってinstructionsの扱い、スキーマ変換、キャッシュ、注入範囲、tokenizerが違うからです。
言えるのは、138ツール規模では、説明文だけでも無視できない量になるということです。そして、実際の転送コストはこの計測より大きくなる可能性があります。
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からレシピを見つける方法で人の選び方を助けますが、ホストがモデルへ注入するツール定義を自動で減らす機能ではありません。
138ツールを維持したまま、ホストが必要な定義だけを読みます
ここが一番大切です。
FORMLOVAはライト版のMCPを別URLで提供していません。単一の/api/mcpと138本のネイティブツールを維持し、tools/callの経路、スキーマ、安全確認も削っていません。違うのは、ホストが最初から全定義をモデルへ入れるか、必要な定義だけを後から読むかです。
FORMLOVAのsearch_toolsとget_tool_detailsは、認証済み・読み取り専用の発見機能です。前者は候補を短いmetadataで返し、後者は1候補の完全な定義を返します。ただし、この2本だけで初期schemaが減るわけではありません。ホストが138本を先に注入した後で呼べば、初期文脈はすでに消費されています。今回の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 Code | 142本を維持したToolSearchの正式30-run | Critical 6 / Formal 60の性能合格 |
| OpenAI Responses API | 公式tool_search + MCP defer_loading: true、GPT-5.4以降 | FORMLOVAでの正式token・遅延実測 |
| Codex | FORMLOVAの発見・ネイティブツール到達 | token削減率 |
| ChatGPT Web | 読み取り専用の機能・UX成功 | ToolSearch、progressive discovery、正確なtrace、provider token |
よく使われる形は3段階です。
- Catalog: 名前と短い説明から候補を探す
- Inspect: 候補ツールだけ完全な入力スキーマを読む
- Execute: 選んだツールを呼び出し、必要な承認を挟む
サーバー側の責任は、検索されても意味が伝わる名前、説明、スキーマ、権限境界を提供することです。ホスト側の責任は、現在の依頼、利用者の権限、利用可能な文脈量に合わせて、モデルへ見せる範囲を決めることです。
ツールを隠せばよいわけでもありません。公開、送信、削除などの重要操作が検索から漏れれば、仕事は完了しません。常時見せる少数の中核ツール、検索対象にする長い裾野、実行前に人へ戻す操作を分ける設計が必要です。
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は次の通りです。
| Prompt | Initial tokens Baseline→Candidate | Total input Baseline→Candidate | Wall latency Baseline→Candidate |
|---|---|---|---|
| common | 63,258 → 1,509 | 126,968 → 11,197 | 8.476秒 → 10.437秒 |
| long-tail | 63,270 → 1,521 | 127,323 → 10,620 | 11.254秒 → 11.419秒 |
| no-tool | 63,175 → 1,426 | 63,175 → 1,426 | 4.420秒 → 3.465秒 |
| Prompt | Initial削減 | Total削減 | Latency差 |
|---|---|---|---|
| common | 97.614531% | 91.181243% | +1.960457秒 |
| long-tail | 97.596017% | 91.659009% | +0.165039秒 |
| no-tool | 97.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つのこと
138ツールを作った経験から、機能追加の前に確認したい項目は6つあります。
| 判断 | 確認すること |
|---|---|
| 測る | instructions、description、入力スキーマを別々に測る |
| 閾値を持つ | 文脈ウィンドウの何%を超えたら段階的発見へ切り替えるか |
| 検索前に絞る | 利用者の権限、プラン、環境で呼べないツールを候補から外す |
| 中核を残す | 認証確認、状態確認、検索など頻出の少数は常時見せる |
| 承認を分ける | 読む操作と、送信・公開・削除など外部影響のある操作を分ける |
| 条件別にライブ検証する | token量だけでなく選択精度、遅延、失敗時の回復をprompt別に測る |
カテゴリ分け、Workflow、サーバー側のsearch_toolsは、人とモデルが目的を見つける助けになります。でも、それだけで初期schemaは減りません。最終的には、ホストの遅延投入を有効にし、実際のクライアントでtoken、遅延、成功、安全を一緒に測る必要があります。
AIの知性は、接続数より文脈の配分で変わります
MCPは2025年12月、Linux Foundationが設立したAgentic AI Foundationの創設プロジェクトの一つになりました。共通基盤として広がれば、AIが利用できるサービスとツールはさらに増えます。
だからこそ、「全部つなぐ」と「全部読ませる」を同じにしないことが大切です。
FORMLOVAに138の公開ツールがあることは、フォーム運用へ届く能力の広さを示します。Claudeの30-runでは、単一MCPと全138本を維持したまま必要な定義へ到達し、初期tokenを大きく減らせました。ただし、commonでは遅延が増え、Critical 6 / Formal 60は未完了です。必要なときに必要な定義だけを見つけ、危険な操作では人へ戻し、条件別の性能まで測って初めて、機能数が実務の価値へ変わります。
MCPの価値は、AIへ無制限に情報を押し込むことではありません。外部世界へ届く能力を保ちながら、今の仕事に必要な文脈を配分できることです。
参考にした一次資料
- Model Context Protocol: What is MCP?
- Model Context Protocol: Understanding MCP servers
- Model Context Protocol: Client Best Practices
- OpenAI API: Tool search
- OpenAI API: MCP and Connectors
- Claude Code: Scale with MCP tool search
- Claude Agent SDK: How tool search works
- Anthropic: Introducing advanced tool use
- Model Context Protocol Blog: The 2026-07-28 MCP Specification Release Candidate（注: 2026-07-28版はその後正式リリース済み。Tier 1 SDK対応済み）
- Model Context Protocol GitHub Releases
- Linux Foundation: Agentic AI Foundationの設立
接続ガイド: FORMLOVAをMCPクライアントに接続する
執筆・確認情報
この記事はFORMLOVAの開発者が、2026年7月29日時点のdocs/SPEC.md、MCPツール登録ソース、静的計測スクリプト、source commit bdfc4ffdのClaude正式Phase 1 artifact、MCP・OpenAI・Claude・Anthropicの公式一次資料を照合して執筆しました。現在の公開数は138ツール・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対応済み）であり、現行の最新仕様です。
