MCP時代の個人開発を守る設計図：認可・観測・ガードレールを一気に整える実践ガイド

最近のAI開発は、モデルを呼ぶだけの時代から「モデルが外部ツールを呼ぶ」時代に入りました。便利さは上がりましたが、同時に「どこまで呼べるのか」「誰の権限で呼ぶのか」「何をログに残すのか」という、ちょっと胃がキリキリする設計課題も増えています。

特に Model Context Protocol（MCP）※ の普及で、エージェントがSaaSや社内ツールに接続しやすくなったぶん、個人開発でも“軽いノリで本番級の責任”を背負いがちです。

※ MCP：LLMアプリと外部データソース・ツールを接続するためのオープンプロトコル。

本記事では、2025〜2026年の公開情報をベースに、私が個人開発の現場で実装しやすいと感じた「安全運用の最小セット」をまとめます。結論を先に言うと、次の3点です。

• 認可（Authorization）を“最初に”設計する
• 観測（Observability）を“後付けしない”
• ガードレール（Prompt Injection対策）を“プロンプトだけに頼らない”

「全部やるのは重い」と思うかもしれませんが、順番を決めれば意外と回せます。私も最初は「とりあえず動けばOK」で始めて、あとから汗をかきました。みなさんは先に傘をさして歩きましょう。

なぜ今、MCPの安全設計が重要なのか

MCPの良さは、道具箱の規格化です。ツール連携を共通化できるので、開発速度が一気に上がります。一方で、道具箱に包丁もチェーンソーも入るようになる、という意味でもあります。

MCP仕様では、HTTPベース実装における認可フローとしてOAuth 2.1系の考え方や、Resource Metadata、Authorization Server Metadataなどを参照する形が整理されています。特に重要なのが、アクセストークンの対象リソースを明示する Resource Indicators（RFC 8707）です。

ここが曖昧だと、悪意あるサーバーや誤設定によって「別のリソース向けトークンが流用される」リスクが出ます。個人開発でも、Notion・GitHub・決済・メールのような高権限ツールをつなげるなら、もはや他人事ではありません。

さらに、OpenAIのResponses APIではリモートMCPサーバー対応が進み、実装ハードルが下がりました。これは朗報ですが、同時に「接続先が増えるほど攻撃面も増える」ことを意味します。便利になったぶん、ガードを明示的に追加する必要があります。

個人開発で先に決めるべき認可モデル

私がまず決めるのは「誰の権限を、どの範囲で、どの時間だけ使うか」です。雑に言うと、万能鍵を作らない、という話です。

1. スコープ最小化（Least Privilege）

※ Least Privilege：必要最小限の権限だけを付与する原則。

• 読み取り専用で足りる操作は write 権限を付けない
• 危険操作（削除、送信、公開）は別スコープに分離する
• 本番データと検証データでクライアントIDを分ける

2. リソース明示

MCPクライアント側で、認可リクエストとトークンリクエストに resource パラメータを入れ、対象サーバーを明示します。これをしないと、後で監査ログを見たときに「このトークン、どこ向けでしたっけ？」というホラーが起きます。

3. 短命トークン＋ローテーション

長寿命トークンは便利ですが、漏えい時の破壊力が大きすぎます。短命化し、失効や再発行を前提に実装します。個人開発でも、ここは頑張る価値があります。

以下は概念例です（動作未検証、構成イメージ）。

# 例: 対象リソースを明示して認可URLを組み立てる
AUTH_SERVER="https://auth.example.com"
CLIENT_ID="my-mcp-client"
RESOURCE="https://mcp.example.com"
REDIRECT_URI="https://app.example.com/callback"

open "${AUTH_SERVER}/authorize?response_type=code&client_id=${CLIENT_ID}&redirect_uri=${REDIRECT_URI}&scope=tools.read&resource=${RESOURCE}"

プロンプトインジェクション対策は「多層防御」で考える

OWASP Top 10 for LLM Applications 2025では、Prompt Injectionが最上位リスクとして扱われています。これは「モデルが賢ければ何とかなる」問題ではなく、システム設計の問題です。

私が最低限入れる層は次の4つです。

1. 入力層の分離

   • ユーザー入力、取得Web本文、システム指示を明確に分ける
   • 外部本文は「命令ではなくデータ」として扱う

2. ツール実行前のポリシーチェック

   • 危険操作は確認フラグ必須
   • 実行可否をルールエンジンで判定

3. 出力検証

   • JSONスキーマ検証※
   • 許可されていない引数を弾く

4. 監査ログ

   • どの入力が、どのツール呼び出しに影響したか追跡できる形で保存

※ JSONスキーマ検証：出力形式を機械的に検査して、想定外の構造を拒否する方法。

「システムプロンプトに“危険な命令を無視せよ”と書いたから安心です」は、鍵をかけずに「泥棒さん入らないでください」と張り紙するのに近いです。お願いは大事ですが、錠前のほうが先です。

観測基盤を作ると、障害対応が急に大人になる

観測は、開発初期ほど後回しにされがちです。わかります。私も昔は「ログ？ printf で十分です」と言っていました。過去の自分にメガホンで説教したいです。

Cloudflare AI Gatewayのような中間レイヤーを使うと、複数モデルプロバイダーのリクエストを一元的に可視化できます。少なくとも次の指標を取るだけで、運用の体感が変わります。

• リクエスト数
• レイテンシ※
• エラー率
• トークン消費量
• 推定コスト

※ レイテンシ：リクエストからレスポンスまでの遅延時間。

さらに、リトライとフォールバックを設計しておくと、プロバイダー障害時の被害を抑えられます。重要なのは「失敗をゼロにする」ことではなく、「失敗してもサービス全体が止まらない」ことです。

概念例（動作未検証）:

routing:
  primary: provider_a/model_x
  fallback:
    - provider_b/model_y
retry:
  max_attempts: 2
  backoff_ms: [200, 800]
limits:
  rpm: 120
  daily_cost_usd: 15

実装の最小テンプレート（MCPクライアント運用）

ここまでを、個人開発向けに「まず動く」形へ落とすとこうなります。

Step 1: ツールを3段階に分類

• Safe: 読み取りのみ（検索、参照）
• Guarded: 状態変更あり（更新、作成）
• Critical: 外部送信・課金・削除

Step 2: 実行ポリシーを明文化

• Safeは自動実行可
• Guardedは条件付き可（特定コンテキストのみ）
• Criticalは必ず人間承認

Step 3: 監査ログを統一フォーマットで保存

{
  "ts": "2026-03-31T11:32:10+09:00",
  "session_id": "abc123",
  "tool": "billing.create_invoice",
  "risk_level": "critical",
  "decision": "blocked",
  "reason": "missing_human_approval"
}

Step 4: 週次レビュー

• ブロック率が高すぎるルールを調整
• 想定外ツール呼び出しを追加遮断
• コスト上振れの原因を特定

この運用を入れるだけで、「エージェントが勝手にやらかすかも」という不安がだいぶ減ります。人間で言うところの家計簿と防犯カメラです。どちらも事件が起きる前に効きます。

NIST AI RMFとOWASPをどう使い分けるか

フレームワークが増えると、資料を読んだだけで満足しがちです。私もあります。PDFを開いてハイライトして、なぜか達成感だけ得るやつです。

実務では、次の使い分けがわかりやすいです。

• NIST AI RMF / Generative AI Profile

  • 組織的なリスク管理の地図
  • 何をGovern/Map/Measure/Manageするかを整理

• OWASP Top 10 for LLM Applications

  • 実装者向けの具体的な攻撃観点
  • どこから壊されるかを想定するチェックリスト

要するに、NISTは「経営と運用の方角」、OWASPは「現場の地雷マップ」です。どちらか片方だと、方角だけ知って地雷を踏むか、地雷ばかり見て目的地を見失うかの二択になりがちです。

2026年に向けた実践チェックリスト

最後に、私が新規プロジェクトで最初の1週間にやるチェックリストを置いておきます。

• 接続するMCPサーバーごとに権限スコープを定義した
• resource パラメータを含む認可フローを確認した
• Critical操作に人間承認フローを入れた
• 外部コンテンツを命令として解釈しない境界を作った
• ツール呼び出し前後の監査ログを残す実装にした
• レイテンシ、エラー率、コストの可視化を開始した
• 障害時のフォールバック先を1つ以上準備した

ここまでできれば、個人開発でも十分に“戦える安全性”になります。完璧を目指すより、まず事故率を下げるのが先です。セキュリティは筋トレに似ています。1日でムキムキにはなりませんが、やめるとすぐ弱ります。

地味ですが、積み上げるほど開発速度も上がります。なぜなら、怖くて手が止まる時間が減るからです。安心して速く作れる状態こそ、個人開発の最強バフだと思います。

---

参考リンク

1. Model Context Protocol 仕様（Authorization）
   • https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization
2. OpenAI: New tools and features in the Responses API
   • https://openai.com/index/new-tools-and-features-in-the-responses-api/
3. OpenAI Developers: MCP and Connectors
   • https://developers.openai.com/api/docs/guides/tools-connectors-mcp
4. Cloudflare Blog: Announcing AI Gateway
   • https://blog.cloudflare.com/announcing-ai-gateway/
5. Cloudflare Docs: AI Gateway Overview
   • https://developers.cloudflare.com/ai-gateway/
6. OWASP GenAI Security: LLM01 Prompt Injection
   • https://genai.owasp.org/llmrisk/llm01-prompt-injection/
7. NIST: AI Risk Management Framework / Generative AI Profile
   • https://www.nist.gov/itl/ai-risk-management-framework