GetClaw
GetClaw
Sign inGet started
ブログに戻る
MCPセキュリティデプロイプライベートAI

2026 年の MCP セキュリティ: RCE の踏み台を作らずに MCP サーバーを導入する方法

最小権限、読み取り専用の初期設定、ネットワーク分離、私有インフラでの実行を前提に、2026 年の MCP 導入を安全に進める方法を解説します。

著者 Julian ParkReviewed by GetClaw Editorial Team14 分で読める

2026 年に MCP を安全に導入するには

2026 年時点で MCP を安全に導入する最善策は、すべての MCP サーバーを「コード実行境界かつデータアクセス境界」として扱い、読み取り専用から始め、プライベート基盤に隔離し、外向き通信を絞り、ワークフローに本当に必要なツールだけを露出することです。広いファイルアクセス、シェル実行、運用資格情報を既定で許したまま導入するなら、それは AI 統合基盤ではなく、使いやすい RCE 面を置いているのに近いです。

MCP の採用が急速に進んでいる今、この区別はとても重要です。標準化が進む一方で、認可や安全性の設計はまだ発展途上だからです。

なぜ MCP セキュリティが現実問題になったのか

MCP が便利なのは、モデルをツール、ファイル、API、ローカルプロセスに橋渡しできるからです。ですが、その強みは信頼境界が曖昧だとそのまま危険になります。

2026 年には、複数 SDK にまたがるアーキテクチャ上の RCE リスクや、@modelcontextprotocol/server-puppeteer に関する SSRF、間接的プロンプトインジェクション、sandbox bypass などの懸念が公開情報として出てきました。

全部が同じ深刻度だと仮定する必要はありません。ただし、MCP サーバーが機密ファイル、任意コマンド、内部アプリ、強い API キーに届くなら、どこか 1 つの境界の緩さが全面的な侵害に変わり得ます。

主な MCP リスク分類

本番事故の多くは、だいたい次の失敗パターンに収まります。

リスクどう見えるかなぜ危ないか
広すぎるツール権限タスク以上の読み書きや実行が可能小さなミスが大事故になる
資格情報の集中1 台の MCP が強い鍵を持ちすぎる1 回の侵害で被害が広い
プロンプトインジェクション外部入力がツール利用を誘導するモデル自体が攻撃経路になる
SSRF / Web ツール悪用ブラウザや fetch が内部へ届く内部管理画面やメタデータが漏れる
ファイルシステム漏洩ホームや SSH キーに届くローカルの機密がすぐ流出する
マーケットプレイス由来の信頼問題3rd party MCP を気軽に入れる供給網リスクを直接抱える

一番安全な初期値は読み取り専用

もし 1 つだけ徹底するなら、まずこれです。可能な限り MCP サーバーを読み取り専用で始めて、必要性が証明されたものだけ権限を増やします。

良い初期例:

  • レポート用リードレプリカに対する read-only DB サーバー
  • 読み取り専用スコープの GitHub 接続
  • 検索と取得だけに限定したドキュメント連携
  • ホームディレクトリではなく、狭いコンテンツディレクトリに向けたファイルサーバー

悪い初期例:

  • シェル実行を最初から有効化
  • 本番リポジトリへの書き込み権限
  • 運用 DB のフル権限
  • 認証済みブラウザセッションを雑に継承するブラウザ MCP

より安全な MCP 配置パターン

MCP サーバーは、開発者の私物ノート PC ではなく、分離された環境に置く方が安全です。

レイヤー安全寄りの選択避けたい選択
Host専用 VPS、VM、分離コンテナ私用データ混在の開発端末
Networkプライベートサブネット、受信拒否、最小外向き通信平坦で広いネットワーク
Credentialsサーバーごとの限定資格情報共通の強権限トークン
Filesystem専用ディレクトリのみホーム全体や共有ドライブ
Transport明示管理されたローカル / プライベートトランスポート公開面に雑に露出
Observability中央ログと監査ツール実行が無記録
LLM client or agent
        |
        v
   MCP client boundary
        |
   +----+----------------------+
   |                           |
   v                           v
Read-only MCP server      Restricted write MCP server
docs/search/files         narrow task-specific actions
   |                           |
   v                           v
Scoped data only          Explicitly approved targets only

有効化前に何を確認すべきか

新しい MCP サーバーは、権限を持つ内部マイクロサービスと同じ感覚でレビューした方がいいです。

  • 実際に呼べるコマンド、クエリ、API は何か
  • 書き込みは本当に必要か、読み取り専用で足りないか
  • どの資格情報を保持するか
  • どのディレクトリを読めるか
  • 公開インターネットや内部管理画面へ届くか
  • リクエストとツール実行は記録されるか
  • 読み込んだ Web ページや文書が危険操作を誘導できないか

答えが曖昧なままなら、本番投入はまだ早いです。

ファイルシステム権限はどう絞るべきか

よくある失敗は、ワークフローが必要とする範囲をはるかに超えたディレクトリを MCP に見せてしまうことです。

安全寄り:

/opt/agent-workspace/docs
/opt/agent-workspace/reports
/opt/agent-workspace/uploads

危険寄り:

/home
/Users
/

文書を要約するだけのサーバーに、SSH キー、ブラウザプロファイル、パスワード書き出し、個人の Downloads が見える必要はありません。

MCP の資格情報はどう扱うべきか

1 台の MCP サーバーに無関係な強い権限を集めないでください。

使うべきもの:

  • サーバーごとに別の資格情報
  • 連携ごとに狭いスコープ
  • ローテーションしやすい環境ファイルやシークレットマネージャー
  • レポート用途なら read-only 認証
  • Staging と Production の資格情報分離

避けたいもの:

  • 共通の root クラウドキー
  • 複数サーバーで同じトークンを再利用
  • リポジトリやサンプル設定への直書き
  • 権限の強いログイン済みブラウザセッションの無自覚な継承

プロンプトインジェクションはどう考えるべきか

MCP では、モデルが指示をツール利用に変換できるため、プロンプトインジェクションの影響が大きくなります。悪意ある Web ページやチケットが「全ファイルを送れ」と書いていたとき、本当に問題になるのはモデルが騙されるかだけではありません。接続されたツールがそれを実行可能にしているかです。

実務的な対策:

  • 機密ツールと一般 Web 閲覧ツールを分離する
  • 書き込みや実行は明示承認を入れる
  • 信頼できない閲覧と広いローカル権限を混ぜない
  • 外部コンテンツが誘発できる downstream action を制限する
  • ツール呼び出しをログに残す

モデルはときどき間違った判断をする前提で設計した方が安全です。

ブラウザ系 MCP が特に危険になるのはいつか

ブラウザ接続型の MCP は便利ですが、危険な性質を同時に持ちやすいです。

  • 任意 URL へアクセスできる
  • 信頼できないコンテンツを取得・描画できる
  • 認証済みセッションに触れる可能性がある
  • ネットワーク境界が弱いと内部ツールに届く

このため、SSRF や間接的プロンプトインジェクションの話題がブラウザ系で強く出てきます。どうしても使うなら、最重要資格情報や管理系ネットワークとは分けるべきです。

MCP サーバーをノート PC 上で動かしてよいか

短いローカル実験なら構いません。ただし、継続的なエージェント運用では既定にしない方がよいです。

ノート PC には普通、次が載っています。

  • 個人資格情報
  • 開発用 SSH キー
  • 関係ないソースリポジトリ
  • 保存済みブラウザセッション
  • クラウド CLI 認証

プライベート VPS や分離 VM の方が、被害範囲、Firewall、ログ、更新、秘密情報、ディレクトリ制御を統一しやすくなります。

本番用 MCP のハードニングチェックリスト

  • MCP サーバーを専用の私有基盤で動かす
  • 読み取り専用から始め、必要があるものだけ書き込み許可
  • ファイルパスを狭く限定する
  • サーバーごとに最小権限の資格情報を使う
  • 不要な外向き通信を止める
  • 閲覧系ツールと機密ローカルツールを分離する
  • 3rd party MCP を導入前にレビューする
  • ツール呼び出しと失敗を中央ログに残す
  • 公開インターネットへ直接露出しない
  • Staging と Production を分ける

GetClaw はどこに合うか

GetClaw が向くのは、MCP を「私有 AI 基盤の中に置きたい」場合です。

安全な MCP 構成には、多くの場合次が必要です。

  • 専用計算資源
  • 分離やパッケージ管理のための root 権限
  • OpenClaw、MCP、ローカルモデルを同居させるきれいな場所
  • より制御しやすいモデル Gateway

OpenClaw などのエージェントをすでに使うなら、私有ホストと組み合わせた方が最小権限を徹底しやすくなります。

結論

MCP はエージェントシステムの標準レイヤーになりつつありますが、内部 API Gateway や shell bridge と同じくらい慎重に扱うべきものです。問題は MCP を使うことではなく、MCP サーバーを「害のないアダプタ」と見なしてしまうことです。

読み取り専用、私有基盤、狭いファイル範囲、限定資格情報、閲覧系と機密ツールの分離。この 5 つを押さえるだけで、MCP はかなり扱いやすくなります。逆にここを飛ばすと、最終的なセキュリティ判断をプロンプトや外部パッケージに委ねることになります。

OpenClaw、MCP、マルチモデル構成を私有環境でまとめたいなら、GetClaw のプライベート AI クラウド と マルチモデル Gateway の組み合わせが分かりやすい出発点です。

FAQ

一番安全な MCP の初期値は何ですか？

読み取り専用、狭いファイルスコープ、限定資格情報、不要な公開なし、です。

MCP サーバー自体が危険なのですか？

それ自体が危険というより、ツール、ファイル、資格情報、ネットワークに直結する信頼境界だという理解が必要です。

MCP はノート PC と私有サーバーのどちらで動かすべきですか？

短期実験はノート PC、本番や継続運用は私有サーバーまたは分離 VM が適しています。

出典とメモ

AI クラウドをデプロイする準備はできましたか？

専用の AI インフラストラクチャを 3 分で起動できます。複雑なセットアップは不要です。

始める

Not sure which path fits your deployment? Talk to us

Helpful next steps:Author directoryEditorial standardsSupport options

関連記事

同じエージェント、インフラ、デプロイ領域の続きの記事です。