Step 0 — MCP の on-demand ロード

/debug が起動して最初にやることは、バグの調査ではなく道具の準備です。SKILL.md の「Step 0」で Model Context Protocol（MCP）のツールを読み込みます。

MCP は最初から使えない（だから読み込む）

MCP は、公式ドキュメントの取得や構造化推論など、モデルの外側にある機能をツールとして呼び出す仕組みです。便利な反面、すべての MCP ツールを常時アクティブにしておくと、ツール定義だけでコンテキストを圧迫します。

そこでこの環境では、MCP ツールを**あえて読み込まない状態（deferred）**にしてあります。使う直前に ToolSearch で必要なツールのスキーマだけを読み込みます。deferred と ToolSearch は Claude Code 標準の機構（📦）で、「Step 0 で何を必ずロードするか」という手順は /debug の SKILL.md に書かれた筆者の設計（🔧）です。

必要な MCP を都度ロードする

ToolSearch(query="select:mcp__sequential-thinking__sequentialthinking", max_results=1)
ToolSearch(query="select:mcp__context7__resolve-library-id,mcp__context7__query-docs", max_results=1)

「全部積んでおく」のではなく「使うときに取り出す」。これが MCP の on-demand ロードです。仕組みの詳細は MCP の 2 段ロード で扱います。

なぜ sequential-thinking が「強制」なのか

/debug の Step 0 では、sequential-thinking の読み込みが必須になっています。これは「複数の仮説を立てて、順に検証する」というデバッグの性質に直結します。

SKILL.md Step 0（抜粋）

- sequential-thinking: 強制使用。複数仮説の検証プロセスを構造化。
    各ステップで修正 / 分岐 / 手戻りを明示化
  - MCP なしの場合: 1 仮説に固執して時間を浪費 /
    真因を見逃して症状だけ消す対症療法に陥る

sequential-thinking は、思考を「仮説 → 検証 → 分岐 → 修正」と段階に分けて進めるための MCP です。今回の fetchUser のバグなら、こう構造化します。

• 仮説 H1: 空配列のとき array[0] が undefined を返している（ロジックエラー）
• 仮説 H2: 非同期処理の戻り値を待たずに参照している（並行性エラー）
• 仮説 H3: 型定義が User を約束しているのに実体は User | undefined（型エラー）

これを「1 つずつ検証する」と決めておかないと、最初の思いつきに飛びついて、見当違いの場所を直してしまいます。MCP を強制することで、その失敗パターンを構造的に避けています。

context7 は「ライブラリが怪しいとき」

もう 1 つの MCP、context7 はライブラリやフレームワークの公式ドキュメントを取得します。/debug では「エラーがライブラリ起因と疑われる場合」に使います。記憶にある古い API 仕様で判断せず、対象バージョンの正しい使い方や既知の不具合を一次情報で確認するためです。今回のような自前ロジックのバグでは出番がないこともあります。

ハーネス全体との整合

この「記憶で判断せず、まず裏取りする」姿勢は /debug 固有のものではありません。rules/fact-check.md という規範が全体に効いています（Guides と Sensors でいう Inferential Guide）。ライブラリ仕様や AWS 挙動などは MCP を第一選択にする、という方針です。skill の Step 0 は、その規範を具体的な手順に落とし込んだものです。

この章のまとめ

要点は次のとおりです。

• MCP は常時オンにせず、ToolSearch で使う直前にスキーマを読み込む（on-demand）
• /debug は sequential-thinking を強制ロードし、複数仮説を「1 つずつ検証する」構造を作る
• 「記憶で断定せず裏取りする」姿勢は rules/fact-check.md が全体に課す規範と地続き

---

次は 調査・修正中に効く rule と hook で、ファイルを読み書きする最中に何が割り込むかを見ます。