Nullstead

MCP

2026年のMCP運用設計: 個人開発でもできる「便利さを壊さない」セキュリティ実装ガイド

AIエージェント時代に必須となるMCPの安全設計を、個人開発者向けに具体的な実装手順で解説します。OAuth、最小権限、承認フロー、監査ログまで、便利さと安全性を両立する現実解をまとめました。

約9分

AIエージェントを作っていると、だいたい同じ瞬間にこう思います。
「うわ、これ便利すぎる」
そして3分後にこう続きます。
「いや待って、これ危なくないですか？」

この「テンション上昇と不安の同時発生」は、MCP（Model Context Protocol）時代の開発あるあるです。MCPは、LLMアプリと外部ツールをつなぐ共通規格として急速に広がりました。便利さは本物です。ただし、設計を雑にすると、便利さがそのまま事故の導線にもなります。

本記事では、個人開発でも回せる現実的なMCPセキュリティ設計を、2026年時点の公開情報をもとに整理します。怖がらせるのが目的ではありません。目的は「怖いので使わない」ではなく、「安全に使い倒す」です。

MCPが一気に実務化した背景を3分で整理します

まず前提です。MCP※は、LLMアプリと外部システムの接続方法を標準化する仕様です。2025年以降、主要プレイヤーが実装を進めたことで、ローカル実験から実運用へ一気に移行しました。

  • Anthropicは、MCPをオープン標準として公開し、データソースとAIツールの双方向接続を狙うと明言
  • OpenAIはResponses APIでリモートMCPサーバー対応を打ち出し、エージェント実装の入口を下げた
  • CloudflareはリモートMCPサーバー構築手順と認可フローを整備し、公開運用の現実解を提示

要するに、2026年のMCPは「面白そうな規格」ではなく、「運用設計が必要な本番インターフェース」です。

※MCP: Model Context Protocol。AIアプリにとってのUSB-Cのような標準接続口、と説明されることが多いです。

MCPのリスクは「モデル」より「接続面」に出ます

誤解されやすいですが、MCPの主要リスクはモデル精度そのものより、接続と権限の設計に集中します。OWASPのAI Agent SecurityやPrompt Injectionの整理を見ると、個人開発でも踏みやすい地雷は次の4つです。

  1. 間接プロンプトインジェクション
    外部ドキュメントやWebページに埋め込まれた指示を、エージェントが信じてしまう問題です。
  2. ツール権限の過大付与
    読み取り専用で十分なのに、書き込みや削除まで開けてしまう問題です。
  3. メモリ汚染
    悪意ある入力を長期メモリに保存し、後続セッションまで影響する問題です。
  4. 承認なき高リスク実行
    送信、課金、削除のような操作を自動で通してしまう問題です。

ここで大事なのは、MCP仕様自体も「ツール説明や注釈は信頼できない前提で扱うこと」「ユーザー同意を必須にすること」を明記している点です。つまり仕様レベルで、ゼロトラスト寄りの実装が推奨されています。

個人開発向けMCPセキュリティ設計 5原則

私が実装時に使っているのは、次の5原則です。企業向けの大規模統制ではなく、1人〜少人数で回せる粒度に絞っています。

1) ツールを「能力」ではなく「業務単位」で分割する

「何ができるか」ではなく「何のために使うか」でツールを分けます。

  • 悪い例: database_tool が read/write/delete を全部持つ
  • 良い例: get_post_summary、create_draft_post、publish_post_after_approval のように分離

この分割は、事故時の被害半径を物理的に小さくします。

2) 最小権限をデフォルトにする

読み取り専用を標準にして、書き込みは明示的な例外として追加します。
「とりあえず全部開けて後で閉じる」は、ほぼ確実に後で閉じません。人間は忙しいので。

3) 高リスク操作は必ず二段階にする

送信、削除、公開、決済は「提案」と「実行」を分離します。
エージェントが実行するのは提案まで。最終実行はユーザー承認後に限定します。

4) 外部入力は全て不審者扱いにする

RAG経由の文章、Webhook本文、スクレイピング結果は、親切そうな見た目でも未検証入力です。
「前の指示を無視して」系の断片を検知したら、実行フローに載せないルールを作ります。

5) 監査ログは後付けしない

誰が、いつ、どのツールを、どんな引数で呼んだか。最低限ここまで残すと、事故時に「何が起きたか」がわかります。ログがない運用は、火災報知器なしのキッチンです。

実装テンプレート: 最小権限 + 承認フロー

以下は、MCPツール実行前に承認ゲートを挟む最小例です。動作未検証ですが、設計パターンとしてそのまま使えます。

// 動作未検証のサンプル

type ToolName = "read_notes" | "create_draft" | "publish_post" | "delete_post";

type Policy = {
  writeAllowed: boolean;
  destructiveAllowed: boolean;
  requireApproval: ToolName[];
};

const policy: Policy = {
  writeAllowed: false,
  destructiveAllowed: false,
  requireApproval: ["publish_post", "delete_post"]
};

export async function guardAndRun(tool: ToolName, args: Record<string, unknown>) {
  if (!policy.writeAllowed && (tool === "create_draft" || tool === "publish_post" || tool === "delete_post")) {
    return { status: "blocked", reason: "write_disabled_by_policy" };
  }

  if (!policy.destructiveAllowed && tool === "delete_post") {
    return { status: "blocked", reason: "destructive_disabled" };
  }

  if (policy.requireApproval.includes(tool)) {
    return {
      status: "pending_approval",
      tool,
      preview: JSON.stringify(args)
    };
  }

  return runTool(tool, args);
}

この形の利点は、モデルが賢くなっても安全境界がコード側に固定されることです。賢いモデルは歓迎ですが、権限チェックをモデルの善意に委ねると、いつか泣きます。

リモートMCP公開時に必須の認証・認可チェック

ローカルMCPと違い、リモートMCPはインターネット公開が前提です。Cloudflareのドキュメントが示す通り、公開時は認証なし運用も可能ですが、本番では認証・認可を入れるべきです。

最低限のチェックリストは次の通りです。

  • OAuth※でユーザーを識別する
  • スコープ※でツール利用範囲を制限する
  • クライアント登録の扱いを固定し、野良クライアントを減らす
  • セッション期限とトークン失効を実装する
  • ツールごとに「誰が使えるか」を定義する

※OAuth: 外部サービス連携で広く使われる認可の標準方式です。
※スコープ: 許可範囲を表す識別子です（例: read:posts, publish:posts）。

特に個人開発では、「最初は認証なしで試す」まではOKですが、そのまま本番化しないことが重要です。試作の便利さを、本番の前提にしない。ここが分岐点です。

プロンプトインジェクション対策は「検知」より「構造」で勝つ

インジェクション対策というと、怪しい文字列を正規表現で弾きたくなります。もちろん一定の効果はありますが、構造対策なしでは限界があります。

有効なのは次の3段構えです。

  1. 命令とデータを分離する
    取得テキストは必ずデータ領域に隔離し、システム命令と混ぜない。
  2. ツール引数をスキーマ検証する
    受け取る型と許容値を固定し、予期しない引数を実行前に拒否する。
  3. 高リスクツールに人間承認を必須化する
    これだけで被害の上限が大きく下がります。

「全部自動化したい気持ち」はよくわかります。私もあります。ですが、公開・送信・削除だけは、人間のワンクッションを残したほうが最終的に開発速度が上がります。事故対応で1日溶かすより、承認クリック1回のほうが安いです。

2026年に個人開発者が採るべき現実解

最後に、私が今のところ最も再現性が高いと感じている運用順序を置いておきます。

  1. ローカルMCPでツール分割を先に固める
  2. 読み取り専用で公開し、監査ログを先に整備する
  3. OAuth + スコープを導入してから書き込み権限を開ける
  4. 公開・削除・送信は最後まで承認付きで維持する

この順序だと、便利さを享受しながら致命傷を避けやすくなります。
MCPは、うまく設計すれば「危ない近道」ではなく「安全な高速道路」になります。逆に設計を省くと、見通しの悪い峠道です。しかも夜道です。しかも雨です。

便利さと安全性は、トレードオフではなく設計課題です。2026年の個人開発は、ここを丁寧にやった人が強いと感じています。

参考リンク

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