MCP の 2 段ロード

Step 0 で、/debug が ToolSearch で MCP を読み込む様子を見ました。この章では、その「都度ロード」の仕組みを掘り下げます。

なぜ全部積みっぱなしにしないのか

MCP サーバーには多くの種類があります。公式ドキュメント取得や構造化推論、AWS 仕様の確認、ブラウザ操作など、用途はさまざまです。これらの定義をすべて常時アクティブにすると、一覧だけでコンテキストを大量に消費します。

そこでこの環境では、MCP を必要なときだけ前に出す設計をとっています。制御は 2 段に分かれています。

段	何を制御するか	操作
スキーマレベル	ツール定義をコンテキストに読み込むか	ToolSearch で都度ロード（deferred tool）
プロセスレベル	MCP サーバーに接続するか	claude mcp add / 設定ファイルで登録し、/mcp で状態確認・認証

スキーマレベル — deferred tool と ToolSearch

deferred tool と ToolSearch は Claude Code 標準の機構（📦）です。普段、MCP ツールは名前だけ見えて、定義は読み込まれていない状態に置かれています。これを deferred（先送り）tool と呼びます。名前は分かっても、パラメータの形（スキーマ）が無いので、そのままでは呼び出せません。

使う直前に ToolSearch でスキーマを取り出します。

スキーマを取り出してから呼ぶ

# 1. スキーマをロード
ToolSearch(query="select:mcp__sequential-thinking__sequentialthinking", max_results=1)
# 2. これ以降は通常のツールとして呼び出せる

select:<名前> で名前を指定して読み込むほか、キーワード検索でも探せます。「全部積む」のではなく「使うときに取り出す」——この一手で、ツール定義のコンテキストコストを必要な分だけに抑えています。

用途テーブルと自律判断でロードする

毎回手で ToolSearch を打つわけではありません。CLAUDE.md（🔧）には「どんな用途のときにどの MCP を使うか」を定めた用途テーブルがあり、モデルが話題・タスク内容からテーブル該当を自律判断してロードします。ロード時は「context7 でライブラリ仕様を確認します」のように、冒頭で宣言する取り決めです。

用途	MCP	ロードのきっかけ
複雑な判断・構造化推論	sequential-thinking	トレードオフ分析・多仮説デバッグなど、構造化が要る判断に入るとき
AWS の挙動・制約	aws-knowledge	AWS 仕様の裏取りが必要な話題に入るとき
画面・パフォーマンス検証	chrome-devtools	UI 修正後の実画面確認や Core Web Vitals 計測のとき
ライブラリ/FW 仕様の確認	context7	最新仕様の確認が必要と判断したとき（MCP 優先原則）

列挙トリガーから自律判断へ（設計の変遷）

以前は「アーキテクチャ設計」「大規模リファクタ」のような発話の複合句を列挙して自動ロードの引き金にしていました。しかし、列挙したのに発火しない取りこぼしが起き、トリガー語彙の保守コストも積み上がる一方でした。そこで 2026 年 6 月に列挙を廃止し、用途テーブル + モデルの自律判断 + 冒頭宣言へ委任しています。旧トリガー語彙は参照ファイルにアーカイブしてあるので、委任がうまく働かなければ戻せます。仕掛けを足すだけでなく、効かない仕掛けは記録を残して畳む——これもハーネスの育て方の一部です。

なお、発話から skill 起動 で見た skill の発話トリガーや promote-ultracode.sh の複合句検知は、いまも複合句方式のままです。委任に切り替えたのは MCP のロード判断だけで、skill / hook は「意図が明確な複合句だけに反応する」方針を維持しています。

この章のまとめ

要点は次のとおりです。

• MCP は「スキーマレベル（ToolSearch）」と「プロセスレベル（接続）」の 2 段で制御する
• 普段は deferred tool として名前だけ見え、ToolSearch でスキーマを取り出してから呼ぶ
• ロードの判断は用途テーブルに基づくモデルの自律判断で、使用は冒頭で宣言する
• かつての複合句トリガー列挙は廃止して委任に切り替えた。skill・hook 側の複合句トリガーは維持している

---

次は memory の仕組み で、セッションをまたいで学びを残す 3 層を見ます。