Nullstead

MCP

MCP本番運用プレイブック2026：個人開発で安全にAIエージェントを回す設計

MCPを個人開発や小規模チームで本番運用するための実践ガイドです。stdioとStreamable HTTPの使い分け、OAuth同意設計、最小権限、観測性、30日導入プランまでを2026年の最新動向とともに整理します。

約8分

はじめに：MCPが「おもしろ技術」から「運用対象」になった話

ここ1年で、MCP（Model Context Protocol）が一気に「試してみた系」から「本番でどう回すか」へ話題が移ってきました。AIエージェントにツールを渡せば何でも解決……と言いたいところですが、実際は「便利さ」と「制御不能」の境目をどこに引くかが勝負です。雑に言うと、MCPは魔法の杖ではなく、ちゃんと取扱説明書が必要な電動工具です。うまく使えば爆速、雑に使えば指を詰めます。

この記事では、個人開発〜小規模チームを想定して、2026年時点のMCP運用をどう設計すると事故りにくいかをまとめます。特に以下を重視します。

  • トランスポート選定（stdio / Streamable HTTP）
  • 認可と同意の設計
  • ツールの最小公開と観測性
  • 失敗前提の運用（タイムアウト・リトライ・フェイルクローズ）

※MCP（Model Context Protocol）: LLMが外部ツールやデータにアクセスするための共通プロトコルです。

2026年の変化：なぜ今MCP運用設計が必要か

まず背景です。MCPは「標準化の動きが速い」「対応製品が増える」「セキュリティ要件が重くなる」の3点が同時進行しています。

OpenAIはResponses APIでリモートMCPサーバー対応を打ち出し、画像生成やCode Interpreterなどのツール連携を単一のAPI文脈で扱える方向に進めています。これで「エージェントは社内ツールもSaaSも横断して使う」が一気に現実的になりました。一方で、使えるツールが増えるほど、権限境界の設計ミスがそのまま事故になります。

さらにMCP仕様側でも、トランスポートやセキュリティのベストプラクティスが整理され続けています。特に「とりあえずSSEでつなぐ」時代から、より明示的な運用前提へ移っているのがポイントです。

要するに、2026年のMCPは「接続できたら勝ち」ではなく「安全に運用できて初めて勝ち」です。ここを無視すると、デモは100点、本番で0点になります。デモは拍手、本番は監査。人生そんなものです。

トランスポート設計：stdioとStreamable HTTPを使い分ける

MCP仕様では標準トランスポートとしてstdioとStreamable HTTPが定義されています。選定指針はシンプルです。

  • 同一ホストで完結: まずstdio
  • ネットワーク越しの共有: Streamable HTTP

stdioは構成が単純で、ローカル開発や1対1接続に強いです。プロセスライフサイクルも把握しやすく、最初の検証に向いています。反面、複数クライアントやリモート公開には向きません。

Streamable HTTPはサーバーを独立プロセスとして扱え、複数クライアント接続を前提にできます。実運用はこちらが中心になりますが、セキュリティ要件が増えます。仕様にもある通り、Origin検証、認証、ローカルバインド方針などを明確にしないと、DNS Rebindingなどの古典的な攻撃が普通に刺さります。

最初の実装で迷ったら、以下のルールで十分です。

  1. 開発初期はstdioでユースケースを固める
  2. 公開前にStreamable HTTPへ移行
  3. 移行時に認証・監査ログ・レート制限を同時導入

「まず動かしてから守る」も悪くはないですが、守りを後付けすると高確率で設計負債になります。引っ越し前提で家具を買うのと同じで、玄関を通らない棚を買ってから泣くタイプの失敗です。

認可設計：OAuthと同意画面を甘く見ない

MCPのセキュリティ文書では、Confused Deputy（権限の取り違え）問題が具体例付きで説明されています。これ、個人開発でも無関係ではありません。むしろ小規模環境ほど「まあ自分しか使わないし」で飛ばしがちです。

最低限、以下は守るべきです。

  • クライアント単位の同意を保持する
  • 同意画面で「誰が」「何の権限を」要求しているかを明示する
  • CSRF対策（state等）を入れる
  • トークンや同意Cookieを安全属性付きで管理する

特に危ないのが「同意済みだから次もOKでしょ」の雑な実装です。便利ですが、攻撃者にも便利です。セキュリティの世界では、開発者の優しさはしばしば脆弱性と同義になります。悲しいですが、現実です。

ツール公開の原則：最小権限 + 意図が伝わるスキーマ

MCP運用でハマるのは、技術よりも設計の雑さです。代表例が「とりあえず全部のツールを見せる」。これはだいたい失敗します。

公開ツールは以下を基準に絞るのが有効です。

  • ユーザー価値が明確なものだけ公開
  • 破壊的操作（削除・上書き）は別サーバーに隔離
  • ツール説明文に副作用を明記
  • 引数スキーマで危険値を通しにくくする

例えばGitHub連携なら、最初は「read系（issue一覧、PR参照）」だけで十分です。いきなりwrite系を開けると、モデルの暴走というより設計者の期待値設定ミスで事故ります。

GitHub公式MCPサーバーの公開プレビューが示したように、実用性は「数」より「説明の質」で決まります。ツールが100個あっても、モデルが正しく選べなければ0個と同じです。むしろ迷わせる分だけマイナスです。

観測性：ログがない運用は「祈り」に近い

MCPを本番で回すなら、観測性（Observability）を後回しにしてはいけません。

最低でも次を残します。

  • どの入力で
  • どのツールが呼ばれ
  • 何秒かかり
  • 成功/失敗したか
  • 失敗理由は何か

クラウド側ではAI Gatewayのように、複数プロバイダをまたいで可視化・制御する仕組みが一般化しつつあります。個人開発でも、せめて「1リクエスト1トレースID」で追えるようにしておくと、障害対応の体感難易度が段違いです。

「ログは出してる」だけでは不十分で、「あとから読める」形式にするのが大事です。JSON構造化ログ、相関ID、サンプリング方針。この3点があるだけで、真夜中の障害調査が“地獄”から“めんどう”くらいに下がります。めんどうで済めば勝ちです。

まず動く実装テンプレート（Node.js + HTTP MCP前提）

以下はあくまで最小構成の例です（動作未検証）。重要なのは「実装より運用フック」です。

# 例: 必要パッケージを追加
npm i express pino pino-http zod

// server.js (動作未検証のサンプル)
import express from "express";
import pinoHttp from "pino-http";
import { z } from "zod";

const app = express();
app.use(express.json({ limit: "1mb" }));
app.use(pinoHttp());

const ToolInput = z.object({
  action: z.enum(["list_posts", "get_post"]),
  id: z.string().optional(),
});

app.post("/mcp", async (req, res) => {
  const traceId = req.headers["x-trace-id"] || crypto.randomUUID();

  // 1) Origin / Auth 検証（本番では必須）
  // 2) JSON-RPC バリデーション
  // 3) タイムアウト制御

  const parsed = ToolInput.safeParse(req.body?.params?.arguments ?? {});
  if (!parsed.success) {
    return res.status(400).json({ error: "invalid_arguments", traceId });
  }

  // 読み取り系だけ公開する例
  if (parsed.data.action === "list_posts") {
    return res.json({ result: [{ id: "1", title: "Hello MCP" }], traceId });
  }

  return res.json({ result: { id: parsed.data.id, title: "Post" }, traceId });
});

app.listen(8787, "127.0.0.1", () => {
  console.log("MCP server listening on http://127.0.0.1:8787/mcp");
});

この段階で最低限やるべきチェックは以下です。

  • action を列挙型で制限できているか
  • 想定外引数を落とせるか
  • タイムアウトと最大入力サイズがあるか
  • トレースIDで1件追跡できるか

MCP Inspectorを使えば、ツール一覧や引数検証、失敗パターンの確認を対話的に進められます。ローカル検証での“雑な安心感”を減らすのにかなり有効です。

個人開発での現実的ロードマップ（30日）

最後に、私が個人開発で実際に回しやすいと感じる30日プランを置いておきます。

  • 1週目: 1ユースケースだけ作る（read-only）
  • 2週目: 監査ログ、タイムアウト、リトライ方針を追加
  • 3週目: 認可フローと同意画面を導入
  • 4週目: 失敗事例を収集してプロンプト・スキーマを修正

ポイントは「先に機能を増やさない」ことです。MCPの価値は接続数ではなく、再現性ある成功率です。10個つながるけど毎日壊れるより、2個で安定する方が100倍えらいです。

AIエージェントの未来は明るいですが、運用は地味です。地味ですが、地味こそが本番を救います。派手なデモの翌日に静かに動き続けるシステム、それが正義です。

参考リンク

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