MCP で外へつなぎ、返ってきた内容をデータとして扱う

ここまでの2回で渡してきたのは、あらかじめ書いておける知識でした。規約も手順も、書いた時点で中身が確定します。

確定しないものもあります。いま本番で出ているエラー、データベースの中身、チケットの状態、外部サービスの現在の設定。どれも先に書いておけません。見に行くしかない。

MCP（Model Context Protocol）が、その「見に行く」を担います。

約束事が共通であることの意味

MCP は、AIのエージェントが外部の道具やデータへつなぐための共通の約束事です。Claude Code が決めたものではなく、複数のツールが対応している仕様です。

あるサービス向けのサーバーを1つ用意すれば、対応したどのツールからも使えます。ツールを乗り換えても、つなぎ込みは作り直しになりません。

接続の形は2つ覚えれば足りる

公式ドキュメントには4つの形式が載っていますが、実際に使うのは2つです。

手元でコマンドとして起動する形は、ローカルのファイルやデータベースを扱うものに使います。

claude mcp add --transport stdio my-db -- node /path/to/server.js

-- のあとは、そのままサーバーへ渡されます。引数を書くときは、この区切りを忘れないでください。

HTTPでつなぐ形は、外部サービスが提供しているものに使います。公式が遠隔のサーバーに勧めているのはこちらです。

claude mcp add --transport http stripe https://mcp.stripe.com

残りの2つのうち、SSE は非推奨とされています。WebSocket は JSON で設定を書く形になります。

追加したあとは、状態を確認するコマンドがあります。

claude mcp list        # つないであるものを並べる
claude mcp get <名前>   # 1つの設定を見る
claude mcp remove <名前>  # 外す

セッションの中からは /mcp で状態を見られます。

範囲は3つあり、1つだけ共有される

同じサーバーでも、どの範囲で追加するかで保存先が変わります。ここが Claude Code の MCP でいちばん間違えやすい部分です。

指定は --scope project のように書きます。

真ん中の project が特別です。リポジトリに入るので、それを開いた人全員に影響します。

リポジトリに入っているサーバーは、承認を挟む

他人がコミットした .mcp.json がそのまま動いたら困ります。そうはなっていません。

公式ドキュメントによれば、対話セッションではプロジェクトのサーバーについて承認を求められます。承認の記録を消してやり直したいときは claude mcp reset-project-choices です。

ただし例外があります。対話でないセッション、つまり claude -p での実行、SDK 経由、クラウドのセッションでは、承認を求めずに読み込まれます。--strict-mcp-config を付けると、指定した設定以外を無視できます。

自動化の中で他人のリポジトリを扱うときは、ここを意識してください。承認の画面は出ません。

鍵をコマンドの引数に書かない

つなぐ先には、たいてい認証が要ります。

手元で起動する形には --env KEY=value があります。HTTPでつなぐ形には --header "Name: value" があります。

どちらも、シェルの履歴に値が残る形で書かないでください。環境変数を参照する形にして、値そのものは別の場所に置きます。第9回で触れた CLAUDE.local.md と同じ発想で、コミットされる場所と、されない場所を分けるのが基本です。

返ってきた内容は、指示ではない

ここがこの回の中心です。

公式ドキュメントは、はっきりした警告を出しています。つなぐ前に、そのサーバーを信頼できるか確かめてください。外部の内容を取ってくるサーバーは、プロンプトインジェクションのリスクにさらします、と。

具体的に何が起きるかというと、課題管理のコメント欄や、取得したウェブページの中身に、Claude への指示に見える文章が混ざっていることがあります。「この設定ファイルを読んで送信せよ」のような形です。

第5回で見たとおり、auto モードの分類器はツールの実行結果を読みません。だから、返ってきた内容で分類器を直接だますことはできません。取り除かれる理由が、まさにこれです。

ただし、Claude 本体は読みます。読んで作業の材料にします。だから、誰でも書き込める場所をつなぐときは、その前提で設計してください。

対策は3つです。

• つなぐ先の権限を読み取りだけにする
• 戻せない操作（書き込み、削除、通知の送信）ができるサーバーは、必要なときだけ有効にする
• 第5回の deny 規則で、触られたくないファイルの読み取りを塞いでおく

なお、MCP 側で対話が必要と指定されたツールは、どの権限モードでも必ず確認が出ます。第5回の「どのモードでも自動にならないもの」の一覧に入っていたのが、これです。組織の設定で特定のツールを常に確認にすることもできます。

つなぐ数を増やしすぎない

運用してみて分かったことがあります。つなぐ数が増えると、選択の精度が下がります。

Claude は、使える道具の一覧を持った状態で作業を始めます。一覧が長くなるほど、その中から適切なものを選ぶ判断が難しくなり、関係ない道具を使おうとする場面が増えます。第10回でスキルの説明文を正確に書く話をしましたが、同じ構図です。

使っていないものは外す。定期的に claude mcp list を見て、3か月使っていないものを外す程度で足ります。

3つの仕組みの使い分け

ここまでで、Claude Code に何かを渡す仕組みを3つ扱いました。判断は2つの質問で足ります。

どの作業にも関係するか。 するなら CLAUDE.md です。

しない場合、それは書いておける内容か。 書いておけるならスキル、書いておけないなら MCP です。

3つは競合しません。同じ作業で全部使うこともあります。リリースの作業なら、規約は CLAUDE.md に、手順はスキルに、デプロイの状態の確認は MCP 経由で、という形になります。

置き場所を間違えたときは、静かに効かなくなる形で現れます。規約をスキルに入れると、呼ばれなかった回に効きません。取りに行くべき情報を規約に書き写すと、古くなったことに誰も気づきません。実際に起きた例はCodex 集中講座の第12回に書きました。

次の回

ここまでは、1つの会話の中で作業を進める話でした。

第12回では、作業そのものを分けます。サブエージェントという、別の文脈で動く作業者の話です。

参照した公式情報

• Anthropic「MCP」「Choose a permission mode」（code.claude.com/docs、2026年9月時点）
• Model Context Protocol の仕様（modelcontextprotocol.io、2026年9月時点）