Nullstead

MCP

MCPサーバーを本番運用する前に読むチェックリスト2026 — 権限地雷を避ける実践ガイド

MCPの本番運用で事故を防ぐために、OAuth/RFC 8707・承認ポリシー・Prompt Injection対策・監査ログ設計までを個人開発向けに整理した実践チェックリストです。

約8分

MCPサーバーを本番運用する前に読むチェックリスト2026 — 便利さの裏にある「権限地雷」を避ける

「MCPを入れたら、AIが全部いい感じにやってくれるらしいです」 このフレーズ、2026年の個人開発界隈では定番になりました。半分は正解です。もう半分は、設定を間違えると笑えない事故につながる、という意味で大正解です。

MCP（Model Context Protocol）は、AIモデルと外部ツール・データをつなぐ共通規格です。※MCP: モデルがツール呼び出しや外部コンテキスト取得を標準化して扱うためのプロトコル。 Anthropicの公開以降、各社の実装やドキュメント整備が進み、いまは「知っている人だけの技術」から「個人開発でも普通に導入する技術」に変わりました。

特に最近は、OpenAIのドキュメントでもリモートMCPサーバーやコネクタを使う実装導線が明確で、接続自体は驚くほど簡単です。だからこそ、今のボトルネックは実装ではなく運用です。言い換えると、接続は数分、事故は数秒です。

この記事では、MCP仕様の更新点（2025年6月〜11月）とセキュリティガイダンスを踏まえて、個人開発で実際に使える本番運用チェックリストをまとめます。派手な裏技はありません。代わりに、事故率を下げる現実的な方法を詰め込みます。

2026年のMCP運用で押さえるべき前提

まず前提です。MCPは「情報を読むための仕組み」だけではありません。「行動するための権限の入口」でもあります。

つまり、MCPを入れるということは、

  • モデルにどのツールを見せるか
  • どの操作を自動許可するか
  • どの範囲の認可トークンを渡すか を設計することです。

この3つを雑にすると、モデルの賢さ以前に運用が崩れます。逆にここを固めれば、モデルが多少ブレても被害は小さくできます。セキュリティは「絶対に壊れない」を目指すより、「壊れたときに小さく止める」ほうが現実的です。

仕様更新で重要な2点: OAuth Resource Server化とRFC 8707

MCP Authorization仕様では、HTTPベースの認可フローが明文化されています。ここで重要なのが、MCPサーバーをOAuthのResource Serverとして扱うという整理です。

さらに、2025年の更新で強く打ち出されたのがRFC 8707（Resource Indicators）の利用です。※Resource Indicators: トークン要求時に「このトークンはどのリソース向けか」を明示する仕組み。

これがなぜ効くかというと、トークンの誤利用（token mis-redemption）を抑えられるからです。ざっくり言うと、

  1. クライアントがトークンを要求するときに宛先を明示
  2. 認可サーバーはその宛先向けに絞ったトークンを発行
  3. 別のサーバーに持っていっても使いにくくなる という流れです。

地味ですが、地味な安全策ほど本番で効きます。派手なAI機能はデモで映えますが、RFC準拠は障害報告書で効きます。

本番運用チェックリスト（まずはここだけ）

ここからは「最初に守るべき最小セット」です。厳密さより継続性を優先しています。

1. ツール公開面を最小化する

  • read系とwrite系を分離します。
  • デバッグ用の万能ツールは本番で無効化します。
  • 「将来使うかも」で公開しない。必要になってから足す。

最初に絞るほど、後で監査が楽になります。逆に最初に全部開けると、どれが危険か分からなくなります。

2. 承認ポリシーを先に決める

  • 削除、送信、公開、課金は承認必須。
  • 参照のみの操作だけ自動許可を検討。
  • 承認ログを必ず残す。

「安全だと思うから承認なし」ではなく、「事故時に説明できるから承認なし」に変えると判断が安定します。

3. トークンを短命・最小スコープにする

  • サーバー単位でaudienceを分離。
  • TTLは短め（例: 15分）を基本。
  • スコープはツール単位で最小化。

長寿命・広スコープは、便利ですが事故半径が大きくなります。短命トークンは少し面倒ですが、面倒は保険料です。

4. プロンプト注入を前提に設計する

OWASP LLM01:2025が示すように、Prompt Injectionは最重要リスクです。※Prompt Injection: 入力テキストに埋め込まれた命令でモデル挙動を不正に誘導する攻撃。

特に「外部コンテンツを読むツール」は危険度が上がります。対策として、

  • 外部入力を命令ではなくデータとして扱う
  • 高リスク操作は必ず人間承認を挟む
  • 不審な指示（秘密情報送信、権限拡大）を拒否する を最低ラインにします。

実装イメージ（動作未検証サンプル）

以下は運用方針をコード化するための例です。環境差分があるため、実運用前に必ず検証してください。

# mcp-policy.yaml
approval:
  default: always
  allow_without_approval:
    - search_docs
    - list_projects

tools:
  enabled:
    - search_docs
    - list_projects
    - create_issue
  disabled:
    - exec_shell
    - delete_repository

oauth:
  token_ttl_seconds: 900
  require_resource_indicator: true
  scopes:
    search_docs: ["docs:read"]
    list_projects: ["project:read"]
    create_issue: ["issue:write"]

// 擬似コード: 危険操作の承認ゲート
function shouldRequireApproval(toolName: string, args: Record<string, unknown>) {
  const risky = new Set(["delete_file", "publish_post", "send_message", "charge_payment"])
  if (risky.has(toolName)) return true

  if (toolName === "create_issue" && args["public"] === true) return true
  return false
}

ポイントは、モデルを疑うことではなく、モデルの判断だけで確定しない構造を作ることです。自動化はアクセル、承認はブレーキです。どちらも必要です。

監査ログと緊急停止の設計

本番では「どう作るか」と同じくらい「どう止めるか」が重要です。最低限、以下のログを残します。

  • どのユーザー入力が起点か
  • どのツールを呼んだか
  • 主要引数の要約（機微情報はマスク）
  • 成功／失敗とエラー

さらに、緊急時の切り替えを準備しておくと安心です。

  1. 高リスクツールを即時無効化するフラグ
  2. 全操作を承認必須にするモード
  3. write系停止の読み取り専用モード

この3つがあるだけで、インシデント時の初動がかなり楽になります。障害対応で一番つらいのは、技術難易度より「止め方が決まっていないこと」です。

参考リンク

導入前テスト項目（ここを飛ばすと後で泣く）

本番投入前に、最低限この5項目だけは手動で確認することをおすすめします。私はここを「15分プレフライト」と呼んでいます。名前はかっこいいですが、やっていることは地味です。地味だから効きます。

1) ツール一覧の差分確認

前回デプロイ時と比べて、公開ツールが増えていないかを確認します。意図しない追加がある場合は、設定ファイルのマージ事故を疑います。

2) 承認バイパスの有無

高リスク操作を自然文で誘導し、承認ダイアログが必ず出るかを確認します。1回でも素通りしたら、その日は本番投入を見送ります。

3) トークンのaudience確認

別サーバー向けのトークンでアクセスが拒否されることをテストします。これが通ってしまうと、RFC 8707を使っていても運用実装が崩れている可能性があります。

4) 失敗時のロールバック

MCPサーバーが落ちたとき、アプリ全体が巻き込まれないか確認します。理想は「機能低下で継続」、最悪でも「安全停止」です。

5) 監査ログの追跡性

テスト呼び出しを1件実行し、ログ上で

  • リクエスト起点
  • ツール名
  • 実行結果 を一意に追えることを確認します。

このプレフライトは、機能開発より達成感が薄いです。しかし、障害が起きたときに「過去の自分ありがとう」と言える確率を上げてくれます。個人開発では、派手な新機能より「壊れにくい運用」が継続率を上げます。

まとめ

MCPは2026年の個人開発において、ほぼ必修の連携技術になりつつあります。実装は確かに簡単になりました。ただし、本番運用は別問題です。

  • ツール公開面を絞る
  • 承認境界を明確にする
  • トークンを短命・最小スコープにする
  • Prompt Injectionを前提にする
  • 緊急停止手段を先に作る

この5つを先に決めておけば、導入速度を落とさずに安全性を底上げできます。

AI時代の自動化は、速さだけでは勝てません。速く作って、壊れ方を管理できる人が強いです。MCPはそのための良い土台です。便利さを味方にしつつ、権限地雷だけは踏まないように進めていきましょう。

補足すると、この記事のチェックリストは「企業でしか使えない重装備」ではありません。個人開発でも十分回せる粒度に絞っています。最初は2〜3項目からでも構いません。大切なのは、一度決めた運用を継続して改善することです。

Tags #MCP #AI #セキュリティ #個人開発 #自動化
← 記事一覧に戻る ページの先頭へ ↑