MCP運用設計｜監視・ログ・障害対応の要点

MCPはLLMを外部ツールやデータソースにつなぐ実装として注目されていますが、PoCのまま本番に持ち込むと、監視・ログ・セキュリティ・障害対応の穴が一気に表面化します。
筆者の初期検証ではアラートが鳴りすぎて本当に見るべき異常が埋もれ、機密情報がログに出かけた場面があり、相関IDや readonly 権限、アラート統制を先に決めておくべきだったと感じました（筆者の経験）。
MCPのセキュリティベストプラクティスの論点を、OAuth 2.1とPKCE、最小権限、第三者MCPサーバー審査の運用ルールへ落とし込みます。
さらに、Azure Monitor・Cloud Monitoring・CloudWatch・Datadogをどう使い分けるか、コストの見方も含めて最初の一歩が見える形に整理していきます。

MCP / エージェント運用で監視設計が必要な理由

運用設計の3要素

MCPやAIエージェントを本番で回すとき、まず分けて考えたいのが監視・ログ・運用設計です。
監視は、システムやアプリケーションの健全性をリアルタイムで把握し、異常を早期に見つけるための活動です。
CPUやレスポンスタイムだけでなく、MCPではツール呼び出しの失敗率、認可エラー、外部APIの429、エージェント実行の停止時間なども監視対象に入ります。
つまり「今、壊れかけていないか」を継続的に見る役割です。

ログは、何が起きたかを時系列で残す一次情報です。
障害調査ではもちろん、誰がどのツールを、どの権限で、どんな判断の流れで実行したかを後から説明するためにも使います。
MCP運用では通常のアクセスログだけでは足りず、user_id、tool_name、scope、correlation_id、実行結果、判断理由、必要なら decision snapshot のような意思決定断面まで構造化して残しておくと、原因追跡の速度が変わります。
私自身、PoC段階でメトリクスだけ先に整えて満足してしまい、決定木生成の途中で外部APIの429が出ていたのに意思決定ログがなく、真因の切り分けに半日かかったことがありました。
グラフ上では失敗率の上昇しか見えず、「どのツール呼び出しが、どの判断分岐で止まったか」が追えなかったからです。

運用設計は、その監視とログをどう使って回すかを事前に決めることです。
誰がアラートを受けるのか、どの閾値で通知するのか、OAuth 2.1 の認可失敗が続いたときにどこまで自動停止するのか、第三者MCPサーバーの追加時に誰が審査し、readonly権限から始めるのか、といったルールと手順を先に定義します。
PoCのまま本番へ進む構成で詰まりやすいのは、監視項目が足りないというより、異常を見つけた後の動き方が決まっていないことです。

MCPのセキュリティ運用では、この3つを別物として扱うのが出発点になります。
監視はリアルタイムの健全性、ログは時系列の事実、運用設計はルールと手順の事前定義です。
この役割分担が曖昧だと、認証エラーは見えているのに監査に耐える証跡がない、ログはあるのに当番が誰か決まっていない、といった抜けが起きます。

MCPの基本構成

MCPは Model Context Protocol の略で、LLMやAIアプリケーションを外部ツールやデータソースへ接続するためのオープン標準です。
『Google Cloud』の解説や。
ホストはAIアプリ本体、クライアントはその中でMCP接続を管理する役割、サーバーは実際のツールやデータソースを公開する側です。
MCP Governance and Stewardship（仕様変更がSEPで提案されるガバナンスモデルが公開されており、単なる。

構成を文章で図解すると、次のイメージです。

ユーザー → ホスト（AIアプリ） → MCPクライアント → MCPサーバー → 外部ツール / データソース

ここで監視対象になるのは、右端の外部APIだけではありません。
ホストがどの入力を受け、クライアントがどのMCPサーバーへ接続し、サーバーがどのツールを、どの認可状態で実行したかまで含めて観測する必要があります。
従来のWebhook連携や単純なREST API統合なら「入口と出口」のログで足りる場面が多いのですが、MCPではその途中にあるツール選択、認可、判断履歴が障害原因にも監査対象にもなります。

この構造だからこそ、認可設計が監視設計に直結します。
たとえば外部ツール接続でOAuth 2.1を採用するなら、クライアント側ではPKCEを前提にした認可コードフローを選び、scope設計では最小権限を守る必要があります。
最初から書き込み権限を渡すのではなく、readonly権限を基準にし、必要な操作だけを scope で分離する形です。
たとえば「閲覧」と「更新」を別scopeに切り分けておけば、監査ログ上でも「閲覧だけのはずのセッションで更新系ツールが呼ばれていないか」を検査できます。
逆に scope が粗いと、認可が通った時点で監視側の粒度も落ち、過剰権限の発見が遅れます。

セキュリティ運用の観点では、第三者MCPサーバー利用時の審査も外せません。
第三者経由ではツール汚染、プロンプトインジェクション、メモリ汚染、ツール干渉といったリスクが入ってきます。
導入時の審査では、提供元の継続性、公開されるツール一覧、要求scope、readonly運用の可否、ログ出力の粒度、障害時のふるまいまで見ておく必要があります。
監視だけ後から足しても防げません。

保持ポリシーの使用とロック  ｜  Cloud Storage  ｜  Google Cloud Documentation

cloud.google.com

一般システム運用との違いと2024-2026の変化

一般的なアプリ運用では、CPU、メモリ、ネットワーク、HTTPエラー率、アプリ例外といった観測点が中心です。
もちろんそれらも必要ですが、MCPやエージェント運用では監視対象が一段増えます。
具体的には、ツール呼び出しそのもの、認可の成否、エージェントの意思決定履歴、第三者MCPサーバーへの接続状況まで監視・監査対象に入ります。
たとえば外形監視でAPIが200を返していても、内部では認可scope不足で必要なツールが呼べず、エージェントが代替ルートを回って誤答を返していることがあります。
この状態は従来のAPMだけでは見落とします。

違いが出やすいのは、障害原因の層の多さです。
従来はインフラ障害、アプリ障害、設定不備が主な切り分け対象でしたが、MCPではそこに認証失敗、認可ミス、外部APIのレート制限、ツールごとの権限制御、第三者サーバー由来の挙動汚染が加わります。
AWSのAmazon ConnectにおけるMCP活用例でも、CloudWatchのコンタクトフローログとエージェントイベントログを主要観測点にしており、単一のメトリクスでは運用品質を担保しきれないことが見て取れます。
Azure MonitorもApplication Insights経由でAIエージェント監視を統合しており、メトリクスだけでなく実行イベントとログを束ねる方向へ進んでいます。

リスクシナリオを3つに絞ると、PoCのままでは検知できない穴が見えます。
1つ目は認可スコープ過大です。
scope設計が雑で、readonly権限で足りる場面でも更新権限を配っていると、誤動作が即データ更新につながります。
2つ目は第三者MCPサーバー経由のプロンプト汚染です。
応答本文に混ざった悪性指示やツール説明の汚染を拾い、ホスト側が意図しない呼び出しへ進むケースです。
OWASP GenAI系の注意点としても、この種の外部入力を「信頼済みコンテキスト」と誤認しないことが繰り返し強調されています。
3つ目は外部APIのレート制限で停止するケースで、429が散発的に出るだけならPoCでは見逃されがちです。
本番ではエージェントの再試行や分岐が重なって連鎖的に処理が詰まり、反応が遅れます。

有力なコミュニティ報告では、2025年11月25日の仕様リリース以降に MCP Registry の登録先が増えたとする声があり、数千件規模の多様な接続先が報告されています（出典: MCP コミュニティ報告、取得日: 2025-11-25）。
ただしこれはコミュニティの報告であり、公式の恒久的な統計と区別して扱ってください。

2026年の動きは、公式と有力情報を分けて見ておくと整理しやすくなります。
トランスポートのスケーラビリティ、エージェント間通信、ガバナンス成熟、エンタープライズ対応が重点分野として示されています。
ここから読めるのは、MCPが「開発者向けの便利な接続方式」から「統制のある企業運用基盤」へ軸足を移していることです。
一方で、gRPCトランスポート対応の広がりなどは有力なコミュニティ情報として扱うのが妥当で、現場では公式仕様・公式ブログ・実装状況を分けて追う姿勢が欠かせません。

この流れの中では、監査ログ要件も従来より厳密になります。
アクセスログだけでは足りず、認可イベント、scopeの付与履歴、ツール実行、判断の分岐、第三者MCPサーバーとの通信結果を相関IDでつないで残す必要があります。
しかもログは監査用である以上、改ざん耐性も要件に入ります。
長期保管が必要なケースでは、WORMに相当する保管方式としてAmazon S3 Object Lock『Azure Blob Storage』の immutability policies、『Google Cloud Storage』のBucket Lockのような仕組みが選択肢になります。
MCP運用はアプリ監視の延長ではありますが、実態としては権限委譲、意思決定、外部依存まで含んだ新しい監視設計だと捉えたほうが、後で破綻しません。

The 2026 MCP Roadmap

The updated Model Context Protocol roadmap for 2026: transport scalability, agent communication, governance maturation,

blog.modelcontextprotocol.io

まず押さえるべき運用対象の分解

運用設計を始めるとき、先に監視ツールを決めたくなりますが、その前にやるべきなのは何を運用対象として数えるのかの分解です。
MCPはホスト、クライアント、サーバーの3層で成り立ちますが、実運用ではそれだけで閉じません。
外部API、認証基盤、ログ基盤、通知基盤、第三者MCPサーバー、そしてエージェント実行履歴まで含めて初めて「観測すべき全体像」になります。

実際に社内ナレッジ検索MCPの棚卸しをやってみると、サーバー本体の担当者は明確でも、アラートをどのPagerDutyルールで受けるのか、障害時に誰がチャット通知を一次受けするのかが曖昧なまま残っていました。
その結果、通知自体は飛んでいたのに反応が遅れ、利用部門から見ると「MCPが不安定」に見えてしまったんですよね。
この手の詰まり方は、技術要素だけでなく体制の棚卸しも同時に必要だと気づかせてくれます。

構成要素の棚卸しテンプレート

棚卸しでは、まず「接続図に描かれているもの」だけでなく、「障害時に問い合わせが飛ぶ先」まで含めて洗い出します。
MCPの基本構成であるホスト、クライアント、サーバーを起点に、その外側へ依存先を広げていく流れだと抜け漏れが減ります。
MCP Security Best Practicesでも、最小権限や監査、認可の設計が重視されており、運用対象を細かく切る前提で読むと実務に落とし込みやすいのが利点です。

棚卸しの最小単位は、次の8カテゴリで考えると整理しやすくなります。
ホストはClaude Desktopや社内ポータルのように、ユーザー操作の起点になるアプリです。
クライアントはホストの中でMCPセッションやツール呼び出しを扱う層、サーバーは実際にツール機能やデータアクセスを提供する層です。
そこに、Slack APIやGitHub APIのような外部API、IdPやOAuth認可サーバーといった認証基盤、Cloud Loggingや『Grafana Loki』などのログ基盤、PagerDutyやSlackのような通知基盤、さらに第三者MCPサーバー、エージェント実行履歴と意思決定ログを重ねます。

運用台帳では、各要素ごとに少なくとも「情報主体」「どのイベントが起きるか」「どこへ送るか」「何日保持するか」「誰が責任を持つか」を埋めます。
ログ基盤だけ別表にするのではなく、ホストやクライアントにも同じ粒度を当てるのが判断材料になります。
たとえばホストならユーザー操作開始、クライアントなら認可要求とツール選定、サーバーなら実処理結果、外部APIならレート制限や失敗応答、認証基盤ならトークン発行と拒否、通知基盤なら通知生成と配信失敗、エージェント実行履歴なら「どの候補から何を選んだか」を追います。

そのまま使える形にすると、棚卸しテンプレートは次のようになります。

ここでのコツは、メトリクス、ログ、監査証跡を同じものとして扱わないことです。
メトリクスは異常検知、ログは原因調査、監査証跡は説明責任に使います。
たとえばCloud Loggingはデフォルトバケットで30日の保持があり、ユーザー定義バケットでは1日から3,650日まで設定できます。
監査や長期分析を前提にするなら、短期の運用ログと長期の監査保管を分けた方が運用の意図がぶれません。
BigQueryへのエクスポートは通常1分以内に見え始めるので、日次分析だけでなく、短い遅延を許容した運用レポートにも載せやすい構成です。

Grafana Loki ｜ Grafana Loki documentation

grafana.com

責任分担マトリクス

棚卸しの次に必要なのは、「誰が見るか」ではなく「誰が収集責任を負うか」を切り分けることです。
MCP運用では、ホスト担当が通知基盤を持っているとは限らず、IAM担当が外部APIの障害を検知できるとも限りません。
だから、対象ごとにメトリクス、ログ、監査証跡の責任者を分けて定義します。

現場ではRACIのような形式にすると運用へ乗せやすいですが、MCPでは収集責任と保存責任を分けて書くと実態に合います。
たとえばクライアントの相関ID付き実行ログはアプリチームが生成し、ログ基盤チームが保存を担い、セキュリティチームが監査要件を定義する構図になりやすいのが利点です。
ここが曖昧なままだと、「ログはあるはず」「通知は飛ぶはず」で止まってしまいます。

1枚で俯瞰するなら、次の形が使えます。

ここで見落としやすいのが、エージェント実行履歴はアプリログの一部ではあるが、監査証跡としては別物という点です。
会話ログだけ残しても、「なぜそのツールを叩いたか」「失敗後に何を再試行したか」は追えません。
JSONの構造化ログに request_id、session_id、correlation_id、user_id、tool_name、scope、reason、decision_snapshot を持たせておくと、障害調査と監査の両方で使い回せます。
ただしPIIやトークンはそのまま出さず、メールはハッシュ化、アクセストークンは部分マスクのように扱う方が実務に合います。

第三者MCPではツール汚染やプロンプトインジェクションのような独特のリスクが入ってきます。
責任分担表に「誰が審査し、誰が継続監視するか」を入れておくと、導入後の放置を防げます。

ELK Stack = Elasticsearch、Kibana、Beats、Logstash

Elastic Stackを使えばあらゆるソースから、あらゆるフォーマットでデータを取得でき、リアルタイムに検索、分析、可視化することができます。...

www.elastic.co

第三者MCPサーバーの責任境界

第三者MCPサーバーを使うときは、障害境界より先に責任境界を描いておく必要があります。
自社のホスト、クライアント、認証基盤、ログ基盤、通知基盤までは統制できても、第三者MCPサーバーの内部実装や、その先の外部APIまでは直接制御できません。
ここを図にすると、監査要求との接合点が見えます。

[利用者]
   |

[自社ホスト]
   |

[自社クライアント] --認可要求--> [自社IdP / OAuth]
   |
   |  相関ID・監査ログ・通知

   v
[自社MCP接続制御]
   |
   |  契約・審査・許可済み接続

   v
======********** 自社の責任境界 **********======
   |

   v
[第三者MCPサーバー]
   |

   v
[第三者の外部API / データソース]
======********** 提供元の責任境界 **********======

この図で押さえたいのは、自社が保証するのは接続前後の統制であって、第三者内部の実装品質そのものではないという点です。
だから監査設計では、「どの第三者MCPサーバーを、誰が、どのscopeで、いつ使ったか」を自社側に残します。
一方で、サーバー内部の詳細ログは提供元の保管範囲に入るので、契約や審査項目として確認しておくべき論点になります。

公式ドキュメントや入門資料を参照すると、OAuthベースの認可観点や最小権限の考え方が整理されています。
これらを踏まえると、責任境界の引き方が腹落ちしやすくなります。
監査要求との接合点としては、少なくとも4つの証跡が必要になります。
1つ目は接続承認記録です。
2つ目は認可記録で、どのscopeを付与したかが残ること。
3つ目は呼び出し記録で、相関ID付きで第三者MCPへのリクエストを追えること。
4つ目はエージェント実行履歴で、なぜその第三者ツールを選んだかまで説明できることです。
ここまで揃うと、外部サービス依存の障害でも、自社側でどこまで説明責任を果たせるかが明確になります。

運用の現場感としては、第三者MCPサーバーを追加した瞬間に、監視対象が1つ増えるというより、責任の継ぎ目が1つ増えると捉えた方が現実に合います。
技術的な疎通確認だけで終わらせず、誰のログが正本なのか、どこまでを自社の監査証跡として保管するのかを切り分けることで、後続の監視設計や障害対応フローが組み上がります。

監視設計: 何をメトリクス化し、どこでアラートを出すか

必須メトリクスと推奨しきい値例

MCP運用の監視は、従来のCPUやメモリ中心の見方だけでは足りません。
前述の通り、監視対象はホスト、クライアント、MCPサーバー、認証基盤、外部API、通知基盤まで広がります。
その中でも、実装初期から必ずメトリクス化しておきたいのは、止まっているか、遅くなっているか、認証と権限で詰まっていないか、外部要因で呼び出せなくなっていないか、想定外のコストが出ていないかの6系統です。

まず死活監視です。
MCPサーバーのプロセス生存、ツール一覧取得、ヘルスエンドポイント応答の3点は最低限そろえておくと、単なるポート疎通と実利用可能性を分けて見られます。
死活は「応答あり/なし」の単純な監視に見えますが、MCPでは認証基盤や外部APIの障害を巻き込んで、見かけ上は起動していても実際には使えない状態が起こります。
そのため、死活監視はアプリ自身のヘルスに加えて、代表的なツール呼び出しを含む軽量な疎通確認まで入れておく方が実務に合います。

応答時間は平均ではなく p95 を主指標に置くのが無難です。
エージェント型の処理は再試行や外部API呼び出しを内包するため、平均値だけでは尾の長い遅延が見えません。
特に「会話は成立するが待ち時間が急に伸びた」という劣化は、p95の上昇として先に現れます。
ホストから見たエンドツーエンド応答時間、MCPサーバー内部のツール実行時間、外部APIごとの応答時間を分けて持つと、どこで詰まっているか切り分けやすくなります。

ツール呼び出し成功率も中核です。
ここでいう成功率はHTTP 200の比率ではなく、期待したツールが最後まで完了し、呼び出し元に利用可能な結果を返せた比率として定義した方がぶれません。
認証に失敗した、権限不足で拒否された、外部APIの429で打ち切られた、途中でタイムアウトした、といった失敗理由は別ラベルで分けるべきです。
MCPでは「呼び出したが使えなかった」ケースが多いため、成功率の中身が運用品質そのものになります。

認証と権限の系統では、認証失敗率、権限エラー数、トークン期限切れ検知を分けて扱います。
認証失敗はユーザー操作ミスや一時的なセッション不整合でも増える一方、権限エラーはscope設計やロール設定の欠陥を示すことが多く、運用上の意味が違います。
トークン期限切れはさらに別で、更新処理の不備や長時間セッション設計の破綻を見つける信号になります。
ここを一括で「auth error」にしてしまうと、Pagerを鳴らすべき障害と、翌営業日に設定を直せば済む問題が混ざります。

外部APIレート制限も、MCP運用では見落とすと痛い指標です。
429の件数だけでなく、どのツール経由で、どの連携先に、どの時間帯に偏って発生したかを見られるようにします。
エージェントは再試行や分岐で呼び出し回数が増えるため、人が直接APIを叩く運用よりレート制限に当たりやすい傾向があります。
単なる失敗率ではなく「429比率」を独立監視すると、連携先側の制約と自社側の呼び出し設計を切り分けやすくなります。

コスト急増もアラート対象に含めます。
MCPではAPI課金と実行時間課金の両方が膨らむことがあり、成功率が維持されていても利益を削る形で障害が進行します。
たとえば無限再試行や不要なツール分岐が起きると、表面上はサービス継続でも、実行時間や外部API消費量が跳ねます。
コストは会計レポートで追うものと思われがちですが、運用では「異常増加の検知」として見る方が早く効きます。

実装しやすい整理としては、次のような形です。

ここでの「推奨しきい値例」は固定値ではなく、平常時の帯から外れたかどうかで置くのが現実的です。
MCPは業務フローごとに利用密度が違うので、最初から一律数値を置くより、数週間の通常運用で基準線を作り、その帯を超えたらWarning、SLOへ波及したらCriticalとした方が運用が安定します。

エージェント型 vs エージェントレス型

監視の取り方は、大きくエージェント型とエージェントレス型に分かれます。
MCPではどちらか一方に寄せ切るより、取得したい粒度に応じて役割を分ける構成が合います。
ホスト内部の実行状況や断線中のバッファリングまで見たいならエージェント型、まず広くSaaSやクラウドの状態を押さえたいならエージェントレス型、という整理です。

断線耐性は机上の比較以上に効きます。
たとえばManageEngine OpManagerのエージェント監視は、断線中のデータを最大6時間保持できると案内されています。
MCPサーバーが拠点回線やVPN配下にある場合、この種のバッファリングがあるだけで、ネットワーク障害とアプリ障害を混同せずに済みます。
断線した瞬間にメトリクスが空白になる構成だと、「止まった」のか「見えなくなった」のか判別に時間を使います。

エージェント型だけに寄せると、SaaS連携やクラウドマネージドサービス側の制限状況が薄くなります。
クラウド側のメトリクスアラートやログ分析は、認証基盤、マネージドDB、外部接続先の状態把握に向いています。
MCPではホスト内部の詳細観測と、クラウド・SaaS側の外形監視を組み合わせた方が、障害の境界が見えます。

Datadogの公式価格ページでは、執筆時点の参考値としてAPM単体の料金例がホストあたり月額 $36 / $41 / $47 と示されています。
ホスト単位で広げると試験導入のつもりが意外に費用に効いてくる点に注意してください。

アラート設計

メトリクスを集めても、アラート設計が粗いと運用はすぐ崩れます。
MCPでは認証、権限、外部API、実行分岐が絡むため、単発エラーの件数だけでPagerを鳴らすと、現場が疲弊します。
アラートは優先度、抑制、相関、通知先、SLOとの接続の5点で組み立てると整理しやすくなります。

優先度は、少なくともCriticalWarningInfoの3段階に分け、Pager対象は絞ります。
実運用では、初月はWarningのみをPager対象外にして、通知はチャットと日次レポートへ流すくらいがちょうどよく、週次でノイズ削減レビューを回しながら条件を詰めると安定します。
本番切替のタイミングでも、PagerはCriticalのみで始めた方が、誰が夜間に起きるべき障害なのかがぶれません。

抑制ルールも必須です。
メンテナンス時間帯のサイレンス、既知障害対応中の一時抑制、依存先停止中の二次アラート抑制を入れておかないと、一次障害より通知の洪水が目立つ状態になります。
特に外部API障害が起きたときに、ツール失敗、認証再試行、タイムアウト、通知失敗が同時多発すると、人間の判断が追いつきません。

相関ルールでは、同一の correlation_id でアラートを集約する設計が効きます。
1件のユーザー操作が複数のツール失敗を引き起こしたとき、それぞれを別インシデントにすると、対応者は同じ調査を何度も繰り返します。
ログ側で correlation_id を持たせておけば、メトリクスアラートにも相関キーを渡せます。
MCPは判断過程が多段になるので、単一エラーではなく同一操作にぶら下がる失敗群として扱う方が現場の認知負荷が下がります。

通知先のルーティングも役割で分けます。
インフラ断やSLO直撃はSRE、認証失敗の増加やトークン期限切れは情シスやIAM担当、権限エラーやツール成功率低下は開発チーム、といった振り分けです。
全部を同じ当番に集めると、権限設定のミスを深夜にSREが追うようなねじれが起きます。
MCPでは技術的な原因と責任主体がずれやすいので、ルート先を最初から分けておく方が復旧が早くなります。

SLO違反に対しては、単純なしきい値よりバーンレート検知が合います。
短時間で急激にエラーバジェットを消費しているのか、緩やかな劣化が続いているのかを分けて見る考え方です。
たとえば主要ツールの成功率低下やp95悪化が短時間に集中しているなら即時対応、認証失敗が緩やかに積み上がるなら営業時間内対応、といった運用判断が置けます。
MCPの障害は「全部止まる」より「一部の経路だけ燃える」形が多いため、バーンレートの見方がなじみます。

この運用ルールは机上の話ではなく、体感として効きます。
以前、夜間アラートが連発した週に認証失敗をPager対象から外して日次レポートへ移したことがありました。
認証失敗そのものは見続けているのに、夜間の一次対応から外しただけで、当番が本当に追うべき障害へ集中でき、復旧時間が安定しました。
認証失敗は件数だけ見ると派手でも、すぐに全体停止へつながらないものが混ざります。
Pagerに載せるかどうかは、検知の有無ではなく、その時刻に人を起こす価値があるかで切る方がぶれません。

ログ設計: 後から原因追跡できるログの残し方

監視の中心にあるメトリクスは「異常が起きているか」を素早く掴むための信号で、ログは「なぜ起きたか」を掘るための材料です。
ここにもうひとつ、監査証跡という役割を切り分けておくと、運用設計の軸がぶれません。
監査証跡はトラブルシュートのためだけではなく、説明責任のために残す記録です。
MCPやエージェント連携では、AIがどのツールを選び、どの権限で外部へアクセスし、誰の操作にひも付いていたかまで後から示せる必要があります。
例えば Microsoft のドキュメントAzure Monitor overviewがメトリクスとログを別レイヤーで整理している通り、観測と追跡は同じ箱に押し込まず、目的ごとに設計した方が運用が崩れません。

役割分担

ログ設計で最初に決めるべきなのは、「何をどのログに書くか」です。
全部をアプリケーションログに流し込むと、調査の入り口は増えても、結局どれが正式記録なのか分からなくなります。
MCP運用では少なくとも、操作ログ、認証ログ、アクセスログ、アプリケーションログ、監査証跡を分けて考えると整理できます。

操作ログには、誰が何を操作したかを残します。
たとえばチャットUIで「顧客一覧を取得」を実行した、承認ダイアログで外部連携を許可した、管理画面で特定ツールを無効化した、といった人間の操作です。
ここでは user_id や session_id、操作対象、操作結果が主役になります。
エージェントの自律処理だけを追っていると、人間の起点が抜け落ちるので、最初の一手を必ず残す必要があります。

認証ログは、認証・認可フローの経過を記録する場所です。
OAuthフローの開始、PKCEを伴う認可要求、付与された scope、拒否理由、トークン更新結果などがここに入ります。
MCPでは「接続できたか」だけでは足りず、「どの権限で許可されたか」「拒否された理由は何か」まで追えないと、権限不足なのか設定ミスなのかが分かりません。
とくに第三者MCPサーバーを扱うと、接続失敗の原因が認証基盤、クライアント設定、先方の認可ポリシーのどこにあるのかが分散します。

アクセスログには、どのエンドポイントへ、いつ、どんな応答が返ったかを置きます。
HTTPメソッド、パス、ステータスコード、応答時間、呼び出し先サービス名などです。
外部APIの 429 や 5xx を追うときは、アプリケーションログだけでは流量や偏りが見えません。
アクセスログがあると、どの経路で失敗が多発しているかが把握できます。

アプリケーションログは、例外、分岐、リトライ、タイムアウト、バックオフ、decision snapshot のような実行中の文脈を残す層です。
ここでは「何が起きたか」に加えて「なぜその処理を選んだか」が効いてきます。
MCPでは、AIがツール選択を誤ったのか、外部APIがレート制限に達したのか、内部の再試行制御が連鎖を増幅したのかが原因候補になります。
以前、相関IDを全レイヤーに通したあと、ツール呼び出し失敗から再試行、さらに外部APIの 429 までを1クエリでたどれるようになりました。
調査のたびに時刻を見比べてログを横断する作業が消え、MTTRが目に見えて縮みました。

監査証跡は、これらのログの中でも「正式記録」として扱うべきものです。
誰が、いつ、どのツールに、どの権限でアクセスし、どんな判断で実行され、結果はどうだったかを後から提示できる形で保管します。
監査証跡は運用ログのコピーではなく、改ざん耐性を前提にした別の記録です。
MCP Security Best 。

JSON構造化ログのスキーマ例

後から原因追跡できるログは、文章ではなくフィールドで残します。
プレーンテキストの「認証に失敗しました」「外部APIでエラー」が積み上がっても、検索条件を組めず、集計もできません。
5W1H をログ項目として分解し、そこに相関IDを加えるのが基本です。
Who は user_id、When は timestamp、Where は service や endpoint、What は tool_name や action、Why は reason、How は decision_snapshot や retry_count といった形です。

そのうえで、MCP運用では request_id、session_id、correlation_id を混同しない方が追跡精度が上がります。
request_id は単発のHTTP要求やツール実行単位、session_id はユーザー対話や接続セッション単位、correlation_id は複数サービスをまたぐ一連の処理単位として分けると、1回の問い合わせから派生した再試行や外部呼び出しまで束ねられます。
OpenTelemetryの trace_id を既に使っているなら、それを correlation_id と対応付ける設計でも構いません。

サンプルは次のようになります。個人情報や秘密情報は平文で置かず、マスキング済みの値だけを入れます。

{
  "timestamp": "2026-03-18T10:15:23Z",
  "level": "WARN",
  "service": "mcp-gateway",
  "environment": "production",
  "event_type": "tool_execution",
  "message": "Tool call retried after upstream rate limit",
  "request_id": "req_8f2c1a",
  "session_id": "sess_b71d44",
  "correlation_id": "corr_51ac90",
  "user_id": "usr_29ab7c",
  "user_email_hash": "hmac_sha256:8b9f...",
  "action": "invoke_tool",
  "tool_name": "crm.searchCustomer",
  "scope": "customers.read",
  "endpoint": "/tools/crm.searchCustomer",
  "http_status": 429,
  "result": "retrying",
  "reason": "upstream_rate_limit",
  "retry_count": 1,
  "decision_snapshot": {
    "selected_tool": "crm.searchCustomer",
    "selection_reason": "customer lookup required",
    "policy_version": "2026-03-01",
    "authz_result": "granted"
  },
  "token_preview": "ya29.a1",
  "masked_fields": [
    "user_email",
    "access_token"
  ]
}

この形なら、correlation_id で一連の流れを追い、tool_name と scope で権限周りを絞り、reason で失敗原因を分類できます。
decision_snapshot をネストさせておくと、「なぜそのツールを選んだのか」を後から読めます。
ここが空だと、MCP特有の判断過程がブラックボックスのまま残ります。

検索基盤側の都合も意識が必要です。
『Grafana Loki』はラベルを低カーディナリティに保つ設計を前提にしているので、service、environment、level のような絞り込みに効く項目をラベルに寄せ、correlation_id のようなほぼ一意の値はログ本文のJSONフィールドとして持つ方が安定します。
『Elastic Stack』でも、何でもインデックス化するとストレージと検索コストが膨らむので、頻繁に絞り込む項目だけを明示的にマッピングする発想が効きます。

マスキングと保持・検索戦略

ログが原因調査に役立っても、個人情報や秘密情報を平文で残してしまうと別の事故を作ります。
MCPでは会話内容、メールアドレス、アクセストークン、外部APIレスポンス断片がログへ漏れ込みやすいので、出力前にマスキングする前提で設計します。
代表例として、メールアドレスはハッシュ化、できれば固定文字列ではなく秘密鍵を使ったHMAC系の方式で照合可能性を残しつつ平文を消す、アクセストークンは完全保存を避けて先頭だけを token_preview として残す、といった運用が現実的です。
データシートでも、トークン類は先頭または末尾の一部だけを残す実務パターンが確認できます。

このルールは「開発者が気を付ける」だけでは止まりません。
誤って平文保存しないためには、アプリ側のロガーにサニタイザを入れ、CIでlintを走らせ、禁止パターンを検出したらビルドを落とすところまで含めて仕組みにします。
たとえば Authorization: Bearer、access_token、refresh_token、メール形式文字列、電話番号形式といったパターンを検査し、プレーン出力を拒否する形です。
人手レビューだけに任せると、障害対応でログを増やした瞬間に秘密情報が混ざります。

保持戦略も役割ごとに分けた方が整います。
運用ログは検索速度を優先して、直近期間をログ基盤に置く設計が向いています。
Cloud Loggingでは _Default バケットのデフォルト保持期間が30日で、ユーザー定義バケットは1日から3,650日の範囲で設定できます。
長期分析が必要ならBigQueryへエクスポートし、通常は1分以内に表示される特性を活かして、比較的新しいデータの探索と集計をSQL側に寄せる構成も取りやすいのが利点です。
検索回数自体には課金しない一方で、取り込みと保持には課金が乗るため、何でも長く置く設計より、用途ごとに保存先を分ける方が無駄が減ります。

監査証跡はさらに扱いが変わります。
ここでは検索性よりも、消せないこと、書き換えられないことが優先です。
WORM要件があるなら、Amazon S3のS3 Object Lock、『Azure Blob Storage』の immutability policies、『Google Cloud Storage』の Bucket Lock のような不変ストレージ機能を候補に入れる形になります。
いずれも保持中の削除や上書きを防ぐ仕組みを持っており、監査ログの改ざん耐性を支える土台になります。
運用ログと監査証跡を同じバケットにまとめるより、検索向けのログ基盤と、保持・証跡向けのWORMストレージを分けた方が役割が混ざりません。
ログの検索戦略では、どのフィールドをインデックス化するかが欠かせません。
頻繁に絞り込む項目（例: timestamp、service、environment、event_type、tool_name、scope、result）は索引対象にし、reason や decision_snapshot は必要に応じてパースする運用が現実的です。
correlation_id は必須の検索キーですが高カーディナリティなため、基盤ごとに全文検索フィールドとJSON抽出のどちらで扱うかを決め、コストと検索性能のバランスを取ることを推奨します。

BLOB データの不変ストレージの概要 - Azure Storage

Azure Storage では、BLOB ストレージの WORM (Write Once Read Many) がサポートされています。これにより、消去および変更できない状態でデータを保存できます。 時間ベースのアイテム保持ポリシーにより

learn.microsoft.com

OAuth 2.1/PKCEの運用ポイント

MCPの本番運用では、認証そのものより「権限委譲の扱い」で事故が起きることが多いです。
ツール実行主体がユーザーなのかバックエンド代行なのか管理用ジョブなのかで同じAPI呼び出しでも意味が変わるため、土台に置きたいのがOAuth 2.1で、クライアント実装ではPKCEを前提にします。
Auth0などのガイドも、外部ツールへ権限を渡す構成では認可コードフローとPKCEを基本として扱うことを推奨しています。
トークンの発行・失効・追跡を運用ルールに組み込み、APIキーの横流しのような設計を避けることが統制維持に直結します。

PKCEも単なる実装チェック項目ではなく、運用に効く設定として扱った方が収まりがよいです。
認可要求時の code_challenge と交換時の code_verifier が一致しない失敗は、開発時の不具合だけでなく、クライアントの設定逸脱や不正な中継を見つけるシグナルになります。
認可失敗率を見るだけでは粗いので、client_id、grant_type、PKCE検証結果、発行scope、相関IDを認証ログに残し、MCP実行ログと突き合わせられる状態にしておくと、認証基盤側で落ちたのか、ツール呼び出し側で拒否されたのかを分離できます。

MCPでは仕様の更新にも目配りが要ります。
MCP Governance and StewardshipやThe 2026 MCP Roadmapを見ると、仕様策定と運営体制は継続的に進んでいます。
運用側ではSEPの監視担当を置き、認証や権限境界に関わる変更は変更管理票に起こし、検証環境でリグレッションテストを通してから本番へ流す体制にしておくと、仕様追従が属人化しません。
OAuthまわりは一見安定して見えても、実際はクライアント登録情報、scope、コールバック、トークン交換、失効APIまで連鎖するので、変更の影響範囲を広めに見る必要があります。

最小権限・scope設計とreadonly

MCPの権限設計で最も効いた原則は、readとwriteを分けることでした。
読み取り系のscopeと更新系のscopeを混ぜると、LLMが「参照したい」だけの文脈で書き込み権限まで抱え込みます。
そこで resource.read と resource.write を分離し、削除や管理操作はさらに別scopeへ切り出し、管理APIは業務クライアントと別クライアントIDで扱う設計が安定します。
日常利用のクライアントに管理系scopeを持たせないだけで、誤操作と横展開の範囲が一気に狭まります。

本番導入では、デフォルトをreadonlyから始める運用がよく効きます。
私はこの切り方を徹底してから、会話経由の誤更新や、検証用プロンプトが本番データを書き換える事故がほぼ消えました。
最初は現場から「書けないと価値が薄い」という声も出ますが、実際に業務で詰まる箇所を観察すると、最初に必要なのは閲覧、検索、照会が大半です。
そこをreadonlyで開け、更新系は個別の申請とレビューを通したツールだけに広げると、権限追加の理由が明文化されます。
結果として、何となく便利そうだから広いscopeを付ける流れが止まりました。

readonly運用を定着させるには、UIや承認フローも連動させる必要があります。
たとえばツール一覧に「閲覧のみ」「更新あり」を明示し、更新系ツールは別承認、別バナー、別クライアントで出し分けると、利用者の認知負荷が下がります。
権限昇格も恒久付与ではなく、時間制限付きで発行し、作業後に自動で戻す構成の方が整合的です。
MCPではツール選択が自然言語の流れに埋もれるため、裏側のscopeが見えないままだと、利用者は「いつの間にか書き込める状態」に気づけません。
だからこそ、権限境界はシステム内部だけでなく、画面や実行履歴でも見えるようにしておく価値があります。

第三者MCPサーバー審査チェックリスト

第三者MCPサーバーは、便利な拡張先である一方、自社の権限境界を外へ延ばす行為でもあります。
特にMCP Registryのように選択肢が増える環境では、接続できることと、運用に耐えることは別問題です。
第三者サーバーは通常のSaaS連携よりも、ツール汚染、過剰権限、ログ欠落、データ保持不透明といった論点を同時に持ち込みます。
MCPではサーバーが返す説明文やツール定義そのものがエージェントの判断材料になるため、OWASP GenAI系の注意点、つまりモデルが外部から受け取る指示や文脈を信用しすぎない設計が欠かせません。

審査では、次の観点を最低ラインとしてそろえておくと、接続後の揉め方が減ります。

• 供給元の実体が明確で、運営主体と連絡経路が追えること。
• ツール定義や説明文に対する汚染耐性があり、不正な誘導や隠れた指示を抑える対策があること。
• 自社側で相関可能な監査ログを取得でき、障害時に提供元ログとの照合ができること。
• 入力データと生成結果の保持期間、再利用範囲、削除手順が契約と運用の両方で明示されていること。
• 脆弱性対応の窓口とSLAがあり、修正や告知の責任分界がはっきりしていること。
• どのscopeで何のリソースへ触れるのかが可視化され、権限境界が曖昧でないこと。

このチェックリストで見落とされがちなのが、ツール汚染耐性です。
通常のAPI審査ではレスポンスの正当性や可用性を見ますが、MCPでは「返ってくる説明がモデルにどう読まれるか」まで含めて評価対象になります。
たとえばツール説明に過剰な権限要求を正当化する文言が混ざっていたり、他ツールの利用を抑制するような誘導が入っていたりすると、エージェントの意思決定がねじれます。
MCP Security Best PracticesやOWASP GenAI系の整理とあわせて、ツール説明文、返却メタデータ、エラー文言のサニタイズ方針まで見ておくと、実運用での違和感が減ります。

もう一つ効くのが、第三者MCPサーバーをいきなり本番会話へ直結しないことです。
接続前に検証環境でプロンプト汚染、過剰権限要求、異常系レスポンス、ログ欠落を一通り踏み、通過したサーバーだけを本番カタログへ載せる方式だと、追加のたびに安全基準を再利用できます。
ここでもSEPの変更追従と同じで、審査は一度で終わりません。
サーバー側の更新、仕様変更、提供元の運営体制変更が入るたびに、再評価のトリガーが引ける状態が必要です。

監査ログとガバナンス

MCPの監査ログは、通常のアプリ監査より一段深く設計した方が実務に合います。
残すべき最小単位は、誰が、いつ、どのツールを、どのscopeで、どのリソースに対して実行し、結果がどうなったかです。
これに相関ID、クライアントID、認可主体、実行理由、可能なら decision snapshot を加えると、「なぜその行為に至ったか」まで追えます。
前のセクションで触れた運用ログとは役割が異なり、監査証跡では説明責任が主目的になります。

監査ログの保存先には、改ざん検出と不変性の仕組みが要ります。
WORM前提なら、Amazon S3のS3 Object Lock、『Azure Blob Storage』の immutability policies、『Google Cloud Storage』の Bucket Lock が候補になります。
いずれも保持中の削除や上書きを防ぐ方向で使えるため、MCPの監査証跡と相性がよいです。
そこへイベント単位の署名やハッシュチェーンを重ねておくと、「消されていない」だけでなく「途中で差し替えられていない」ことまで検証できます。
監査で問われるのは保存の有無より完全性なので、検索基盤と同じ感覚で扱わない方が安全です。

保持期間は一律ではなく、組織規程、契約、法令に合わせて決める領域ですが、MCPでは認可ログ、ツール実行ログ、管理者操作ログの保存年限がずれやすいので、最初から台帳で分けておくと運用が崩れません。
検索向けのログ基盤で短中期保持し、監査証跡は不変ストレージへ複製する二層構成にすると、調査性能と証跡保全を両立できます。
Cloud Loggingのような基盤で収集したイベントを分析系へ流しつつ、真正性が必要なレコードだけ別保管する設計は、この用途に噛み合います。

ガバナンス面では、MCPを「便利な接続機能」で終わらせず、変更管理の対象として扱うことが欠かせません。
仕様変更の監視、SEPの確認、第三者MCPサーバーの棚卸し、scope追加時の承認、readonly解除の記録、失効手順の演習まで含めて、運用ルールが必要です。
MCPでは新しいツールが増えるたびに権限境界も増えるので、資産台帳に「接続先」「クライアントID」「許可scope」「データ分類」「ログ取得先」「失効責任者」を紐づけておくと、障害時も監査時も追跡が切れません。
こうした地味な管理があると、ツール数が増えても運用の見通しが残ります。

障害対応フローと運用テンプレート

標準インシデントフロー

MCPやエージェント運用の障害対応は、従来のWebアプリより切り分けの層が多くなります。
ユーザー体感の不具合が、認証基盤の失敗なのか、MCPサーバーの応答異常なのか、外部APIの制限なのか、あるいはエージェント側の判断ミスなのかを短時間で分けないと、対応が空回りします。
そこで運用現場では、検知から事後レビューまでを一本の標準フローとして固定しておく方が、当番交代や夜間対応でも品質がぶれません。

図にすると、流れは次の形です。

1. 検知

アラート、失敗率の上昇、ユーザー報告、外形監視の異常からインシデントを起票します。起点はメトリクスでもログでも構いませんが、相関IDで追えることが前提です。

1. 切り分け

まず影響範囲を確認し、認証、MCPサーバー、外部API、クライアント、プロンプト変更、権限変更のどこで失敗しているかを分けます。
MCPでは通常のCPUやメモリより、認証失敗数、ツール呼び出し失敗、429、5xx、scope不一致の方が先に手掛かりになります。

1. 一次対応

恒久修正ではなく、被害を広げないための回避策を先に打ちます。
代表例は、機能フラグで該当ツールを止める、読み取り専用モードへ落とす、直前の設定へロールバックする、再試行条件を絞る、といった措置です。

1. エスカレーション

自チームで復旧できないと判断したら、IAM担当、連携先オーナー、第三者MCP提供元、基盤担当へ引き上げます。
この段階で必要なのは「困っている」という連絡ではなく、発生時刻、影響範囲、相関ID、直前変更、暫定回避策の有無といった調査に必要な基本情報を添えて報告することです。
自チームで復旧できないと判断したら、IAM担当、連携先オーナー、第三者MCP提供元、基盤担当へ引き上げます。
この段階で必要なのは「困っている」という連絡ではなく、発生時刻、影響範囲、相関ID、直前変更、暫定回避策の有無です。

1. 復旧

監視値が戻ったことだけで終わらせず、ユーザー影響が止まったか、保留中ジョブが再開したか、監査ログの欠落がないかまで確認します。
MCPでは表面上の200応答でも、内部で代替経路に切り替わっていることがあるため、経路の戻し方も含めて扱います。

1. 事後レビュー

事象の時系列を並べ、5 Whysで根因を掘り、再発防止を改善チケットに落とします。
レビューが会話で終わると、次の当番に何も残りません。
しきい値見直し、Runbook更新、権限修正、監査項目追加までチケット化して初めて運用資産になります。

実運用では、一次対応の判断をRTOとRPOで切る場面が出ます。
私が第三者MCPサーバーの停止に遭遇したときは、書き込み系の整合性を守る必要があったので、復旧を待って通常経路を引っ張るより、RTO優先で読み取り専用の代替パスへ即時に切り替えました。
更新を止めても参照が生きていれば業務継続できる場面では、この判断が効きます。
逆にRPOを崩せない処理なら、無理に回避策を入れず停止を選ぶ方が事故を増やしません。
標準フローにRTOとRPOの判断点を入れておくと、現場で迷いが減ります。

Runbookテンプレ

Runbookは障害時に読む文書というより、迷わず動くための操作テンプレートです。
MCP運用では、一般的なサーバーダウンだけでなく、認証失敗、レート制限、第三者サーバー停止のように責任分界がまたがる障害を先に整備しておくと、初動が安定します。
ここでは、現場で出やすい3パターンをそのまま流用できる形で示します。

認証失敗多発のRunbookでは、現象を「トークン取得失敗」「scope不足」「PKCE/OAuth設定不整合」に分けて扱います。
手順は、まず認証失敗率の急上昇を確認し、失敗が特定クライアントだけか全体かを切り分けます。
次に、直前のクライアント設定変更、redirect URI変更、scope追加、シークレット更新、IdP障害情報を照合します。
判断基準は、ユーザー全体に影響しているか、既存セッションも巻き込んでいるか、監査上の認可不整合が発生しているかです。
回避策は、直前設定へのロールバック、追加scopeの一時無効化、特定クライアントの切り離し、手動再認証の案内に整理すると扱いやすくなります。
連絡先は、一次当番、IAM担当、アプリ担当、必要に応じてIdP提供元の順で固定しておくと連絡が詰まりません。

外部API 429多発のRunbookでは、単純な障害ではなく、使い方が制限に達している前提で動きます。
手順は、429の発生エンドポイント、利用クライアント、再試行回数、バックオフ有無、時間帯集中を確認し、同時に通常トラフィックなのか異常増加なのかを見ます。
判断基準は、短時間で自然回復する見込みがあるか、再試行で悪化しているか、機能停止より応答劣化の方がましかです。
回避策としては、再試行間隔の拡大、キャッシュ利用、優先度の低い呼び出し停止、要約精度を落としてでもAPI回数を減らす経路への切替が有効です。
連絡先は外部APIのオーナーとアプリ側のトラフィック制御担当をセットにします。
429は「落ちた」のではなく「叩きすぎた」ことが多いので、監視だけでなく設計修正につなげる前提で記録しておくと後が楽です。

第三者MCPサーバーダウンのRunbookは、MCP特有の項目です。
手順は、接続失敗なのか、認可失敗なのか、応答タイムアウトなのか、返却内容の異常なのかを分け、その上で代替パスの有無を確認します。
判断基準は、対象ツールが必須機能か補助機能か、書き込み操作を含むか、RTOとRPOのどちらを優先するかです。
回避策は、対象MCPサーバーの利用停止、読み取り専用の代替パスへの切替、該当ツールを会話候補から外す、手動オペレーションへの退避が中心になります。
連絡先には自社当番だけでなく、第三者提供元の障害窓口、契約オーナー、セキュリティ窓口を含めます。
特に第三者停止時は、復旧してもすぐ元へ戻さず、応答内容の健全性確認をRunbookに入れておくと、再開直後の二次障害を避けられます。

テンプレートの項目は、どのRunbookでも共通化しておくと運用設計書に組み込みやすくなります。
最低限そろえたいのは、対象サービス、検知条件、一次切り分け手順、判断基準、回避策、エスカレーション先、復旧条件、事後レビューの記録先です。
文書の体裁を整えることより、深夜でもその順番で動けることの方が価値があります。

日次/週次/月次運用

障害対応フローだけ用意しても、日々の運用が薄いと本番では同じ種類の障害を繰り返します。
MCPやエージェントの運用は、平常時にどこまで差分を拾えているかで安定度が変わります。
そこで定期運用は、日次、週次、月次で見る対象を分けた方が崩れません。

日次運用では、その日に出たアラートを閉じることより、アラートの質を見ることが中心になります。
具体的には、アラートレビュー、ツール呼び出し失敗率、認証失敗率、外部APIの429と5xx、推論やツール実行のコスト増加、代替パスへの切替発生を確認します。
ここで見るべきなのは件数だけではなく、同一相関IDに複数の異常が束になっていないかです。
MCPでは認証失敗が入口で、その結果としてツール失敗が連鎖することがあるため、単独メトリクスで見ると誤読します。

週次レビューの観点としては、誤通知、見逃し、エスカレーション遅延、切り分け時間の長さが揃っていると運用改善の方向が見えます。
なお、参考までに Datadog の APM 単体の料金例がホストあたり月額 $36 / $41 / $47 と提示されていることがあります。
実際の契約条件は地域やオプションで変わるため、最新の公式ページを確認してください。

月次運用は、障害対応よりガバナンス寄りです。
権限棚卸し、監査ログの整合性確認、WORM設定の検証、SEP変更差分の確認をここに集めます。
権限棚卸しでは、付与済みscopeと実運用で使われたscopeのずれを見ます。
監査ログ整合性では、検索用ログと不変ストレージ側の証跡に欠落がないかを突き合わせます。
加えて、ロック後の運用手順に逸脱がないかも確認します。
月次でSEP変更差分を見る意味は、仕様変更が静かに運用前提を崩すからです。
MCP Governance and StewardshipやThe 2026 MCP Roadmapのような公式情報に目を通す運用を月次タスクに入れておくと、監視項目やRunbookの見直しタイミングを逃しにくくなります。

定期運用を回すときは、日次で事象を拾い、週次で監視品質を整え、月次で権限と証跡を締める、という役割分担にしておくと、障害対応と監査対応がぶつかりません。
MCPは接続先が増えるほど運用の論点も増えるので、この周期設計が土台になります。

運用設計書の章立て例

運用設計書は、監視、セキュリティ、障害対応を別々のメモに散らすより、一冊にまとめて責任分界が追える形にした方が現場で使われます。
MCPやエージェント運用向けなら、章立ては次の並びにすると実務で抜けが出にくくなります。

1. 目的

この運用設計書が何を対象にし、どの業務を守るのかを定義します。可用性だけでなく、認可、監査、第三者MCP管理を含めると対象が明確になります。

1. 体制

サービス責任者、当番、IAM担当、観測基盤担当、第三者MCP窓口、監査責任者を記載します。オンコールと承認責任を分けて書くと、障害時の連絡が詰まりません。

1. 構成

クライアント、MCPサーバー、認証基盤、外部API、ログ基盤、監査保管先、通知基盤の構成図とデータフローを載せます。
読み取り専用の代替パスがあるなら、この章で通常経路と並べて示します。

1. 監視

監視対象、主要メトリクス、アラート条件、通知経路、相関ID運用を定義します。外形監視と内部監視の使い分けもここで固定します。

1. ログ

構造化ログの項目、マスキング方針、保存先、検索方法、相関方法をまとめます。ログ、メトリクス、監査証跡の役割分担も明記します。

1. セキュリティ

OAuth 2.1、PKCE、最小権限、第三者MCP審査、ツール汚染対策、秘密情報管理の方針を書きます。前述の審査観点や変更時の再評価条件もここに入ります。

1. 権限

scope一覧、付与条件、承認フロー、失効手順、棚卸し方法を記載します。readonlyと書き込み権限を分離して書くと、障害時の回避策にもそのまま使えます。

1. 障害対応

標準インシデントフロー、Runbook一覧、優先度定義、エスカレーション条件、復旧判定、事後レビュー手順をまとめます。
5 Whysと改善チケット化のルールもこの章に入れると運用が流れません。

1. 定期運用

日次、週次、月次の運用項目、実施責任、記録先、レビュー会の扱いを定義します。SEP変更差分確認やWORM検証もここに含めます。

1. 変更管理

MCPサーバー追加、scope変更、監視しきい値変更、ログ項目変更、第三者MCP更新時の承認手順を書きます。
変更前後で何を検証するかまで残しておくと、障害の原因追跡が速くなります。

1. 付録

用語集、連絡先一覧、障害時テンプレート、監査ログサンプル、構成図差分、既知の制約を置きます。
本文を読み切らなくても、当番が必要な箇所だけ引ける形にしておくと現場向きです。

この章立ての利点は、監視設計書、セキュリティ設計書、障害対応手順書が別々に育って矛盾するのを防げることです。
MCP運用では「誰がどの権限でどのツールを使えるか」と「障害時にどこまで止めてよいか」が直結するので、権限章と障害対応章が離れすぎない構成が合います。
運用設計書は読み物ではなく、平常時の整備と障害時の判断を同じ地図に載せるための文書として作ると機能します。

ツール選定の考え方: 既存監視基盤を使うか、専用で組むか

SaaS vs クラウドネイティブ vs 自前集約

監視基盤の選び方は、機能比較だけで決めるよりも、どこに運用責任を置くかで整理すると判断しやすくなります。
DatadogのようなSaaS監視は、APM、ログ、インフラ監視、ダッシュボードを横断して一つの画面で扱えるので、MCPのようにアプリ、認可、外部API、推論実行が同時に絡む系統では立ち上がりが速いです。
とくに、相関IDを軸にトレースからログ、ログからメトリクスへ移る運用は、最初の設計負荷を抑えながら形にできます。

Azure MonitorAmazon CloudWatchGoogle Cloud Monitoringのようなクラウドネイティブ監視は、各クラウドのマネージドサービスとの統合が深いことが強みです。
たとえばAzure Monitorはアプリ、ログ、メトリクス、アラートの導線が自然で、CloudWatchはAWS上のイベントやサービスメトリクスとの接続が強く、Google Cloud MonitoringはCloud Loggingや他のGCPサービスと並べて見たときの一貫性があります。
単一クラウド中心の構成なら、認証、権限、タグ、通知まわりまで同じ流儀で揃えられるので、運用の分業も組みやすくなります。

この違いは、MCP運用で特に効きます。
従来の監視はCPUやメモリ、HTTP応答時間を見ていれば足りる場面が多かったのですが、MCPではツール呼び出し、認可結果、外部接続、エージェントの判断理由まで追う必要があります。
SaaS監視はその相関を最短で可視化しやすく、クラウドネイティブ監視はクラウド側で発生している事象を漏らさず拾いやすい、という差が出ます。
自前集約は、『Elastic Stack』や『Grafana Loki』、あるいはCloud Loggingから『BigQuery』へ流して分析基盤を組む方式が代表例です。
この方式の利点は、スキーマ、保持、アクセス権、保存先を自社都合で決められることにあります。
ログを業務分析にも転用したい、監査証跡と検索用ログを明確に分けたい、データ主権の要件が厳しい、といった環境では候補に上がりやすいのが利点です。
Cloud Loggingはデフォルトのログバケット保持が30日で、ユーザ定義バケットや_Defaultは1日から3,650日の範囲で設定でき、_Requiredは400日固定です。
加えて、『BigQuery』へはSinkでエクスポートでき、通常は1分以内に表示されるので、リアルタイム寄りの分析基盤としても成立します。

ただし、自前集約は「保存先を持てる」ことと「運用負荷を下げられる」ことが同義ではありません。
MCP向けに相関ID、user_id、tool_name、scope、reason、decision snapshot のような項目を最初から標準化していないと、検索のたびにログ整形が必要になり、問い合わせ対応や障害解析の人件費が積み上がります。
逆に、構造化JSONのスキーマが揃っているチームなら、自前集約の自由度はそのまま分析力に変わります。
ここで差を生むのは製品の優劣より、スキーマ統制の有無です。

実際、私自身も最初からSaaS監視に寄せたわけではありません。
まず既存のAzure Monitorでメトリクス、ログ、アラートを一通り揃え、どこで調査が詰まるかを見ました。
その段階では十分に回っていたのですが、MCPサーバー経由の外部呼び出しが増えると、遅延の山がアプリ内のどこで立っているかを掘る作業に時間がかかるようになりました。
そこで、ボトルネック特定が必要な一部サービスだけDatadog APMへ寄せたところ、全体を載せ替えなくても調査速度は目に見えて変わりました。
既存監視基盤を土台にしつつ、深掘りが要る箇所だけ専用ツールを重ねるハイブリッド運用は、現場では現実的な落としどころです。

コストとスケールの考え方

監視基盤のコストは、製品名だけで比較しても意味が薄く、どの信号をどれだけ保持するかで見積もりが変わります。
MCP運用では、通常のアプリ監視に加えて、ツール実行ログ、認可イベント、外部API応答、判断履歴が増えるため、ログ量と高カーディナリティ化の影響を受けやすいのが利点です。
とくに保持期間とログ取り込み量は、予算との差が出やすい判断材料になります。

運用コストの見立てでは、APM を全ホストに入れるか一部ホストに限定するかで総額が大きく変わります（参考例: Datadog APM のページに例示されるホスト単価 $36 / $41 / $47、取得日: 2026-03-18）。
APM をどこまで適用するかは目的と費用対効果を基に決めてください。

クラウドネイティブ監視も、使った分だけ積み上がる構造です。
Azure Monitor overviewと『Azure』の価格情報で押さえておきたいのは、新世代メトリックアラートが単一メトリック時系列・単一リソース単位で課金される点です。
アラート設計を細かく切るほど精密になりますが、リソース数と時系列数が増えた瞬間に、意図せずアラート課金が増えることがあります。
MCPでは「認証失敗」「ツール失敗」「外部API制限」「推論再試行」など項目を増やしたくなりますが、監視対象を分けすぎるとメトリクス数とアラート数が先に増えます。
粒度を上げる場所と、ダッシュボード集計で済ませる場所を分けて考える必要があります。

Cloud Loggingの取り込み単価はリージョンやプランで変わるため、$0.50/GiB はあくまで参考例として扱ってください。
取り込み・保持・エクスポートの組み合わせによって請求が変わるため、最新の公式情報で見積もってください。

自前集約のコストは、ライセンス費よりも保存設計と運用人件費で見た方が実態に近いです。
Elastic Stackでは、インデックスライフサイクル管理で保持期間を制御できますが、全文検索向けに何でもインデックスするとストレージが大きくなります。
1日800GBを30日保持する試算を当てはめると、圧縮やマッピング次第で数十TB規模のストレージが見えてきます。
『Grafana Loki』はラベルだけを小さくインデックスする設計なので、ログ基盤としてのコスト効率は出しやすい一方、ラベル設計を誤ると逆に苦しくなります。
MCPで相関IDをラベルに置きたくなる場面は多いのですが、相関IDはほぼユニーク値なので、高カーディナリティになってメタデータ負荷が跳ね上がります。
この手のコストは請求画面に出る前に、検索遅延や運用の詰まりとして表面化します。

データ主権の観点も、製品選定では外せません。
SaaS監視は導入が速い反面、保存先やデータの所在に制約が出ることがあります。
クラウドネイティブ監視は、利用クラウドのガバナンスに乗せやすく、自前集約は保存戦略を最も細かく制御できます。
この順に自由度は上がりますが、同時に運用設計の責任も自社側へ戻ってきます。
MCPではログの中に認可情報や意思決定の断片が混ざるため、単純な価格比較より、どの層のデータをどこまで自社管理下に置くかで選ぶ方が後悔が少ないです。

実運用例から見る観測点の設計

観測点の設計は、監視ツールの名前から入るより、実際の業務フローを時系列に並べた方がうまくいきます。
その参考として分かりやすいのが、AWSのMCP を用いた Amazon Connect の監視運用準備で示されている、Amazon ConnectとMCPを組み合わせた運用イメージです。
ここでは、単なるシステム稼働監視ではなく、コンタクトフローの進行やエージェントイベントの変化をCloudWatch系の観測点として扱っています。
MCP運用に置き換えると、重要なのは「呼び出し元アプリが正常か」だけではなく、「どの会話がどのツールへ進み、どこで止まり、オペレーターや担当者の介入が要る状態か」を追えることです。

たとえば、ダッシュボードの一段目にはサービス全体の状態を置きます。
ここではMCPリクエスト数、ツール呼び出し成功率、認証失敗数、外部APIの429や5xx、主要レイテンシを並べます。
二段目には業務文脈の観測点を置きます。
Amazon Connectのcontact flowやagent eventに相当するものとして、会話開始、ツール選択、認可要求、承認拒否、再試行、エスカレーションを時系列で見られる形です。
三段目には調査用の相関ビューを置き、相関IDでログ、トレース、監査証跡を横断できるようにします。
この三層構造にしておくと、障害か、権限ミスか、業務フローの詰まりかを見分けやすくなります。

ここでSaaS監視と自前集約の差が出ます。
DatadogのようなSaaS監視では、APMとログをそのままつないで、特定の会話やツール実行にぶら下がる遅延スパンを追えます。
CloudWatchAzure MonitorGoogle Cloud Monitoringでは、クラウドリソース起点のメトリクスとログは取りやすい一方、MCP独自の判断履歴やscopeの流れは、アプリ側で構造化して送らないと業務文脈まで届きません。
自前集約では、Cloud Loggingから『BigQuery』へ流してSQLで業務イベント分析をしたり、『Elastic Stack』で検索軸を細かく作ったりできますが、その代わりにスキーマ統制が前提になります。

MCP特有の運用コストは、相関IDとスキーマ標準化の有無で決まる場面が多いです。
相関IDがクライアント、MCPサーバー、外部API、監査ログで共通になっていれば、障害時に一本の会話を追えます。
逆に、サービスごとに request_id も trace_id も命名が違い、scope や tool_name も自由入力になっていると、同じ事象を追うのにクエリを書き換え続けることになります。
『Loki』でも『Elastic Stack』でも『BigQuery』でも、この差はそのまま運用担当の負荷に跳ね返ります。
MCPでは「何を失敗したか」だけでなく「なぜそのツールが選ばれたか」まで後から見る必要があるので、decision snapshot や reason を残す設計は、調査時間の短縮に直結します。

実務では、既存基盤を土台にしながら観測点だけをMCP向けに増やす進め方が収まりやすいのが利点です。
CloudWatchならcontact flowやagent eventのように業務イベントをメトリクス横に置く。
Azure Monitorならアプリケーションイベントに相関IDとscopeを入れ、Google Cloud MonitoringならCloud Loggingとエクスポート先分析基盤を組み合わせる、といった広げ方です。
監視基盤の選定は製品の好き嫌いより、MCPの業務フローをどこまで観測単位に落とせるかで見ると、導入後の迷いが減ります。

BigQuery

BigQuery、BigQueryML、

cloud.google.com

よくある失敗と最初の一歩

ありがちな落とし穴と対策

MCP運用の立ち上げで最も多い失敗は、取れるものを全部取ろうとして、あとから誰も読めない観測基盤を作ってしまうことです。
とくにログは典型で、会話本文、プロンプト断片、ツール引数、外部API応答、認可イベントを無差別に残すと、障害調査より先に保管量と検索負荷が問題になります。
Cloud Loggingは取り込みと保持の両方に課金が乗る設計ですし、デフォルトのログバケット保持も 『Google Cloud』 の仕様に沿って整理しておかないと、必要なログと不要なログの区別がつかないまま膨らみます。
実務では、全件保存ではなく、正常系はサンプリング、異常系は詳細保持、監査対象は別保管という切り分けから入ると詰まりにくくなります。

アラート過多も、導入初期の失敗としてよく起きます。
ツール失敗、認証失敗、429、外部MCP疎通不良を全部即時通知にすると、移行の最中に通知基盤のほうが先に疲弊します。
自分の現場では、最初の1週間は Warning だけをSlackへ流し、日次で振り返る運用に置いたことがあります。
そこでノイズ源をつぶしてからページング条件を絞った結果、切り替え時のPager爆発を避けられました。
初期は抑止と集約を先に設計し、「同じ原因の失敗を1件にまとめる」「再試行で自動回復するものは通知しない」「業務影響がある失敗だけ当番へ送る」という順で整えると、通知が意味を持ちます。

権限が広すぎる問題も、PoCから本番へ移すときに露呈します。
MCPはCPUやメモリだけを見ていればよい運用ではなく、どのツールにどのscopeで到達できるかが監視対象に入ります。
PoCでは動作確認優先で広い権限を渡しがちですが、そのまま本番へ持ち込むと、権限エラーの検知以前に、誤った実行が成功してしまいます。
是正策は単純で、最小権限へ切り戻し、実際に使っているscopeだけを残すことです。
権限エラーが増えるのは悪化ではなく、隠れていた過剰付与が見える化された状態だと捉えたほうが運用は安定します。

監視対象が曖昧なまま始めるのも危険です。
MCPでは、クライアント、MCPサーバー、認証基盤、外部API、第三者MCPが一連の処理に並ぶため、「何が落ちたか」より「どこまで進んだか」を棚卸ししないと切り分けが止まります。
ここで効くのが、会話開始からツール実行、認可、外部呼び出し、応答返却までを一度並べ、各区間に責任者と観測項目を置く作業です。
ログの中身も、ユーザー、tool_name、scope、相関ID、結果、reasonのように最低限の軸を固定しておくと、あとから検索文を毎回作り直さずに済みます。
『Grafana Loki』でも高カーディナリティな値をラベルへ載せすぎると逆に運用が苦しくなるので、相関IDのような一意値はログ本文側に持たせて検索する設計のほうが収まりがよい場面が多いです。

まずは10項目で始める

導入直後から網羅を狙うより、まずは10項目だけを本番候補として固定したほうが、閾値調整も責任分界も見えます。
MCPの最初の観測点としては、次のチェックリストが扱いやすいのが利点です。

1. 死活
2. p95応答時間
3. ツール成功率
4. 認証失敗数
5. 権限エラー数
6. レート制限発生数
7. コスト急増の兆候
8. トークン期限切れ
9. 第三者MCP疎通
10. 相関ID欠落率

この10項目が効くのは、MCP運用で頻出する障害原因をほぼ一巡できるからです。
死活とp95応答時間で表面症状をつかみ、ツール成功率で業務実行の成否を見ます。
認証失敗数、権限エラー数、トークン期限切れはIAMまわりの不具合を切り出す軸になります。
レート制限発生数と第三者MCP疎通は外部依存の詰まりを拾えます。
コスト急増の兆候を初期から入れておくのは、ログ量やAPM対象の増え方が後から請求だけで発覚する状態を避けるためです。
相関ID欠落率を観測に含めるのもポイントで、ここが抜けると、障害そのものより調査不能が先に問題になります。

製品選定の話と同じで、ここでも道具より粒度が先です。
Datadogで取るのか、Cloud Loggingと『BigQuery』で組むのか、『Elastic Stack』や『Grafana Loki』で持つのかは後段の話で、最初は「どの失敗を10個の観測点に割り当てるか」を固めるほうが効果が出ます。
たとえば相関ID欠落率は、ログ基盤が何であっても見たほうがよい項目ですし、権限エラー数はアプリログと認可ログの両方で拾える形にしておくと、実装側とIAM側のどちらに寄っているかを分けて読めます。

1週間観察して本番へ

PoCの延長でそのまま本番に入るより、1週間だけ観察期間を置くと、アラート閾値とログ量の粗さがよく見えます。
この期間に見るべきなのは、通知が何件飛んだかではなく、どの通知が調査に結びついたかです。
WarningだけをSlackへ送り、日次でまとめて見返す運用は、その判定に向いています。
どのツール失敗が自動回復したのか、どの認証失敗が設定ミスだったのか、どの429が一時的な外部制限だったのかを並べると、ページング対象にするべき条件が絞れます。

この1週間で詰める作業は、4点に集約できます。
ひとつ目は、ログのサンプリングと詳細保存の境界を決めることです。
ふたつ目は、重複アラートの抑止と集約単位を決めることです。
みっつ目は、使っていないscopeを削って最小権限へ寄せることです。
もうひとつは、監視対象の棚卸しをやり直して、担当者不在の観測点をなくすことです。
ここまで済むと、PoCで偶然見えていたものが、本番で再現できる監視へ変わります。

観察期間の価値は、運用チームの負荷を数字ではなく手触りで把握できるところにもあります。
たとえばCloud Loggingから『BigQuery』へ流す構成では、通常は短い遅延で分析へ回せる一方で、リアルタイム通知に向く信号と、日次レビューで十分な信号が分かれて見えてきます。
『Elastic Stack』や『Grafana Loki』でも、検索軸を欲張るより、毎日使うフィールドだけを先に揃えたほうが、調査の往復が減ります。
本番前の1週間は、監視の精度を上げるというより、読める形に削る時間だと考えたほうがうまく回ります。

付録: 比較表とテンプレート集

比較表

本番運用で迷いやすい論点は、言葉で説明するより表に落とすと齟齬が減ります。
MCPの監視は従来のインフラ監視の延長に見えて、実際には「誰が、どの権限で、どのツールを呼び、その結果がどう返ったか」まで観測対象に入るため、運用会議では比較表を先に置いたほうが話が早く進みます。

エージェント型かエージェントレス型かも、MCPでは「どこまで内部を見たいか」で判断が変わります。
エージェント監視は断線中でも最大6時間データ保持ができるため、切断や一時的な閉域網の影響を受ける環境では効きます。
まず広く可視化したい段階ではエージェントレスのほうが立ち上がりは軽くなります。

メトリクス、ログ、監査証跡を混ぜて扱うと、通知設計も保存設計も崩れます。
Cloud Loggingはデフォルトのログバケット保持が30日で、ユーザー定義バケットは1日から3,650日まで設定できますが、これは「何でも同じ場所に置けばよい」という意味ではありません。
異常検知と証跡保全は目的が違うので、器も分けて考えたほうが運用が安定します。

一部の公開報告では MCP Registry が成長しているとされ、登録先が多数に上るとする観察があります（出典: MCP コミュニティ報告、取得日: 2025-11-25）。
公式の発表と照合する場合は、当該年の公式ソースを確認してください。

ログサンプルと検索クエリ例

MCPの調査で役に立つログは、文章として読めるだけでなく、検索キーが固定されていることが条件です。
相関ID、ユーザーID、ツール名、scope、result、reason、redactionのような軸を揃えておくと、アプリ担当と監査担当が同じ事象を別の観点で追えます。
JSONは次の形を基準にすると、最低限の追跡とマスキング方針を両立できます。

{
  "timestamp": "2026-03-18T09:42:31Z",
  "level": "INFO",
  "service": "mcp-gateway",
  "environment": "prod",
  "correlation_id": "c9c7c3d1-6d8c-4b0c-92b6-3d2f4e2a8f10",
  "user_id": "user_8f2a1c",
  "tool_name": "calendar.create_event",
  "scope": "calendar.write",
  "result": "denied",
  "reason": "scope_missing",
  "redaction": {
    "applied": true,
    "fields": [
      "access_token",
      "email"
    ]
  },
  "decision_snapshot": {
    "requested_action": "create_event",
    "target_system": "calendar",
    "policy_version": "2026-03-01"
  },
  "message": "Tool execution rejected by authorization policy"
}

この形にしておくと、検索は「失敗を探す」「特定ユーザーの流れを追う」「特定ツールの権限不足を集計する」の3系統に分けられます。
『Kusto Query Language』の構文では、JSONの展開と集計を一連のパイプで書けるので、権限エラーの偏りを見るときに相性がよいです。

McpLogs

| where TimeGenerated > ago(24h)

| extend j = parse_json(RawData)

| where tostring(j.result) == "denied"

| where tostring(j.reason) == "scope_missing"

| project TimeGenerated,

          correlation_id = tostring(j.correlation_id),
          user_id = tostring(j.user_id),
          tool_name = tostring(j.tool_name),
          scope = tostring(j.scope),
          reason = tostring(j.reason)

| order by TimeGenerated desc

McpLogs

| where TimeGenerated > ago(7d)

| extend j = parse_json(RawData)

| summarize denied_count = count() by tool_name = tostring(j.tool_name), scope = tostring(j.scope)

| order by denied_count desc

『Grafana Loki』で扱う場合は、相関IDをラベルに載せず、ログ本文のJSONから抽出して絞るほうが運用が落ち着きます。
Lokiはラベルベースで高速に引ける一方、高カーディナリティな値をラベル化するとインデックス管理が苦しくなるためです。
相関ID検索を頻繁にやる現場ほど、この設計差が後から効いてきます。

{service="mcp-gateway", environment="prod"} |= "scope_missing" | json | correlation_id="c9c7c3d1-6d8c-4b0c-92b6-3d2f4e2a8f10"

{service="mcp-gateway", environment="prod"} | json | result="denied" | line_format "{{.timestamp}} user={{.user_id}} tool={{.tool_name}} scope={{.scope}} reason={{.reason}}"

sum by (tool_name) (
  count_over_time({service="mcp-gateway", environment="prod"} | json | result="denied" [1h])
)
Loki の例では、1時間ごとの拒否数をツール単位で集計するような形でダッシュボード化すると実務的に役立ちます。こうした集計をアラート条件と連動させ、偏りが出たときに自動で追跡できるようにする運用が一般的です。

{{product:20}}

{{ogp:https://learn.microsoft.com/ja-jp/kusto/query/?view=microsoft-fabric|Kusto クエリ言語 (KQL) の概要 - Kusto|Kusto クエリ言語 (KQL) を使用して、データの探索、パターンの検出、異常の特定、統計モデルの作成を行う方法について説明します。|https://learn.microsoft.com/en-us/media/open-graph-image.png}}

### 運用設計書テンプレ/審査チェックリスト

運用設計書は分厚い文書にするより、レビューに必要な論点が先に並んでいることのほうが効きます。私もこのテンプレを使って社内レビューを回したとき、監査部門から毎回後追いで出ていた修正要望を先に章へ入れ込めて、差し戻しが減りました。MCPはアプリ運用、IAM、監査、法務の視点が交差するので、章立ての時点で受け皿を作っておくと会議の往復が減ります。
運用設計書の章立ては、次のアウトラインから始めると抜け漏れを抑えられます。

1. 対象システム概要  
2. 利用目的と業務範囲  
3. 構成図（クライアント、MCPサーバー、認証基盤、外部API、第三者MCP）  

各章は要点（目的・責任者・検証基準）を簡潔にまとめる形にしておくと、レビューや運用移管の際に判断がぶれず、実務で使いやすくなります。
4. 監視対象一覧  
5. メトリクス設計  
6. ログ設計  
7. 監査証跡の保存方針  
8. 認証認可設計（OAuth 2.1、PKCE、scope、最小権限）  
9. 障害対応フロー  
10. アラート通知と当番体制  
11. データ保護方針（マスキング、ハッシュ化、redaction）  
12. 保持と保管先の設計  
13. 不変保管の要否と実装方式  
14. 第三者MCPサーバー利用時の責任分界  
15. 変更管理と再審査条件  
16. 例外承認の手続き  

監査証跡の保管が必要な組織では、不変ストレージの章を独立させておくと話が早く進みます。Amazon S3 Object Lockは Governance と Compliance の2モードを持ち、『Azure Blob Storage』は time-based retention と legal hold、『Google Cloud Storage』は Bucket Lock で保持ポリシーをロックできます。どれも「消せないこと」が中心機能なので、運用設計書では機能比較より「どの記録を、どの条件で、不変化するか」を先に書いたほうが実務向きです。

第三者MCPサーバーの審査は、機能比較だけで終えると危険です。OWASPの観点で見るなら、入力、認証、権限制御、秘密情報、監査可能性、依存関係、運用更新の7つに分けると確認が進みます。チェックリストとしては次をそのまま使えます。

- **認証と認可**: OAuth 2.1系の設計か、PKCEを使うか、scopeが過剰でないか、トークン保管場所が明示されているか。
- **入力と出力の安全性**: ツール引数の検証があるか、想定外入力で権限逸脱しないか、AI出力をそのまま外部実行しない制御があるか。
- **監査可能性**: correlation_id、user_id、tool_name、scope、result、reason が自社側で追えるか。
- **秘密情報の扱い**: トークン、メール、識別子のマスキング方針があるか、redaction の実施箇所が定義されているか。
- **変更管理**: バージョン更新時の通知手段があるか、仕様変更で権限範囲が広がらないか。
- **依存関係**: 外部API障害時のフェイルセーフがあるか、レート制限時の挙動が定義されているか。
- **保存と削除**: ログ保持、バックアップ、削除手順、法的保持の扱いが明記されているか

この審査で見落としやすいのは、サービスの安全性そのものより「自社が観測できるか」です。提供元が安全設計を主張していても、自社ログに最低限の実行記録が残らなければ、障害時も監査時も説明が途切れます。第三者MCPを採るかどうかは、機能の豊富さより、説明責任を自社で閉じられるかで決めたほうが失敗が減ります。

### 脚注と出典のラベリング指針

脚注や出典の入れ方は、量よりラベル設計のほうが効きます。この記事のように、仕様、製品仕様、運用ノウハウが混ざるテーマでは、同じ重みで並べると読者が判断に迷います。そこで、本文や脚注には **公式**、**有力**、**運用ノウハウ** の3ラベルをつけて区別すると、根拠の強さがひと目で伝わります。

ラベルの使い分けは次の通りです。**公式** はベンダーや仕様策定元の一次情報で、仕様日付、保持期間、機能要件のように制度や挙動を確定させる箇所に使います。たとえば『Google Cloud』のログバケット保持、Grafana Labsの『LogQL』構文、Microsoftの『KQL』仕様、AWSの[S3 Object Lock](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/object-lock.html)のモード差はこのラベルが合います。**有力** は調査会社や業界で参照される公開調査に充て、導入傾向や市場感を補うときに向きます。**運用ノウハウ** は実務で磨かれた設計指針で、ログスキーマやマスキング設計のように単一標準がない論点に置きます。

実際の書き方は、文の流れを切らないことが前提です。デフォルト保持が30日とされており【公式】、監査用途は別保管を前提に考えるべきです」のように、本文に自然に織り込みます。「ある記事に書いてあった」ではなく、「この判断はどの種類の根拠に載っているか」を見せるほうが、レビューでの扱いが安定します。

脚注番号を使う場合も、番号だけを置くよりラベルを併記したほうが読者の期待値が揃います。例としては「[^1 公式]」「[^2 有力]」「[^3 運用ノウハウ]」の形です。仕様日や価格のような固定値は **公式** を優先し、たとえばDatadogのAPM standaloneの参考価格のように具体額がある情報は製品ページに紐づく根拠を当てます。反対に、構造化ログのフィールド設計やマスキング実装は単一標準がないため、複数の実務ガイドを踏まえた **運用ノウハウ** として示すのが筋です。

このラベリングを先に決めておくと、社内レビューで「その話は仕様なのか、慣行なのか」が一目で伝わります。MCPの運用設計は新しい論点が多く、2024年11月ごろから導入実装が広がり、仕様側も更新が続いているので、本文の主張と根拠の距離を短く保つことが、そのまま保守性につながります。