お問い合わせ
AI NOTE — 193

MCP サーバー本番運用のガバナンス設計：権限・監査・障害対応

PUBLISHED2026.06.25
READ8 分
CATEGORYAI

MCP (Model Context Protocol) の企業導入が試験運用フェーズを越え、本番稼働へ移行するケースが増えている。この記事では、本番稼働後に情シスが継続して担う権限棚卸し・監査ログ設計・障害対応フローの整備方法を整理する。

この記事を読んだほうが良い人

  • MCP サーバーの試験導入を終え、本番稼働に入った、または移行を目前に控えている情シス担当者
  • 稼働中の MCP サーバーについて、権限の棚卸しや監査ログの収集が手つかずのままになっている方
  • MCP サーバーが停止したとき、誰が何をすべきかを事前に整理しておきたい方
  • MCP の運用ポリシーを社内文書として整備したい方

本番稼働後に「設計フェーズ」は終わらない

MCP サーバーの導入前には、接続先 SaaS の選定・OAuth スコープの最小化・ユーザーへの利用承認フローなど、設計作業が集中する。しかしこれらの判断は「稼働開始時点」の情報に基づいたものであり、稼働後の環境は変化し続ける。

本番稼働後に起きやすい変化：

  • 利用ユーザーが増え、当初想定外の使い方が生まれる
  • 接続先の SaaS に仕様変更や API 廃止が発生する
  • 担当者が異動・退職し、当初の設計意図が引き継がれない
  • 別プロジェクト用に立てたサーバーが稼働し続け、管理されなくなる

MCP サーバーが一般的なクラウドサービスと異なる点は、その接続が「AI エージェントを通じた自動・プログラム的なアクセス」である点にある。OAuth トークンは明示的に失効させない限り有効なまま残り続けるため、プロジェクトが終了しても権限が生き続けるリスクがある。権限の「スコープクリープ」が静かに進行している状態は、情シスが定期的に確認しないと気づきにくい。

MCP 権限管理と情シスの定期棚卸し

稼働後にもっとも放置されやすいのが「幽霊化した MCP サーバー」の問題だ。PoC（概念実証）のために立ち上げたサーバーが、プロジェクト終了後も停止されないまま残り続けるケースが典型で、不要な権限が有効なまま残存するリスクにつながる。

幽霊サーバーを早期に発見する手がかりとして有効なのは、「直近 30 日間にアクセスが記録されていないサーバー」の一覧を定期的に抽出することだ。接続がゼロになっているにもかかわらず OAuth トークンが有効なまま残っているサーバーは、停止の検討対象になる。

棚卸しは四半期（3ヶ月）サイクルを基本とする。

確認項目 確認方法のポイント 対応の目安
サーバーの稼働状態 稼働ログまたはヘルスチェック記録を参照 30 日以上アクセスなしなら停止を検討
OAuth トークンの有効状態 OAuth 同意管理画面から確認 90 日未使用なら失効ポリシーの対象に
接続ユーザー数と権限スコープ 管理コンソールのトークン管理から確認 スコープが当初設計から拡大していないか
オーナー・担当者の在籍確認 人事システムとの突合 不在なら引き継ぎ、または停止を判断
接続先 SaaS の仕様変更有無 サーバー設定と SaaS の変更履歴を照合 設計時の前提と乖離していないか
過去 3 ヶ月のセキュリティアラート セキュリティ監視基盤（SIEM 等）から確認 異常なアクセスパターンが出ていないか

棚卸しの結果に基づくエスカレーション基準も事前に合意しておきたい。「停止すべきサーバーが 3 台以上見つかった場合は一覧を上長に共有する」「スコープが当初設計の 2 倍以上に拡大していた場合は再設計を検討する」といった閾値を設定しておくと、担当者個人の判断で完結させず、組織として意思決定できる構造になる。

Model Context Protocol 監査ログの設計判断軸

「何のためにログを取るか」を決めずに収集の仕組みを入れると、量だけ増えて活用されないまま終わることが多い。監査ログの目的は大きく 3 つに絞れる。

  1. 不審なアクセスの事後検知：通常の操作パターンから逸脱した行動（深夜の大量データ取得、業務範囲外のファイルへのアクセス等）を特定する
  2. インシデント発生時の原因追跡：いつ・誰が・どのサーバーを通じて・何を操作したかを遡れるようにする
  3. コスト管理とトークン消費の監視：LLM API のトークン消費量が計画を大きく超えていないかを確認する

何を優先するかによって、ログの収集対象・保持期間・閲覧権限の設計が変わる。目的を先に決めてから収集経路を選ぶ順番を守ることが、過剰実装を防ぐための実務的な判断軸になる。

最低限記録しておきたいログのフィールド

目的を問わず、最低限以下のフィールドをログに含めることを目安にすると運用しやすい。

フィールド 内容 主な用途
タイムスタンプ アクセス日時（UTC 推奨） 時系列追跡・アラート基準
サーバー識別子 MCP サーバーの名称または ID 障害発生時のサーバー特定
操作種別 読み取り / 書き込み / 削除 等 異常検知・監査証跡
接続ユーザー / エージェント OAuth トークンに紐づく ID 責任追跡
接続先リソース アクセスした SaaS の対象（ファイル ID 等） インシデント影響範囲の特定
ステータス 成功 / 失敗 / 権限エラー 不正アクセス試行の検知

「インシデント対応」を最優先にするなら、タイムスタンプ・サーバー識別子・操作種別・ステータスの 4 フィールドだけでも記録を始められる。残りは必要に応じて追加する段階的アプローチで十分だ。

ログ収集経路の選択肢

SaaS 側の監査ログを活用する方法では、接続先の SaaS が記録した操作ログを分析する。実装コストが低い反面、「MCP サーバーを経由した操作か」を直接示す情報を持たないケースがある。Google Workspace なら管理コンソールのトークン管理や監査ログから AI エージェントのアクセスを確認できる。

MCP サーバー側でログを出力する方法では、操作の文脈（どのプロンプトに応じた操作か等）も記録できる一方、サーバーごとに実装が必要で管理コストが上がる。

100 名規模の企業環境では、まず SaaS 側の既存監査ログから利用可能な情報を確認し、不足している粒度についてのみ MCP サーバー側のログで補完する段階的なアプローチが現実的だ。

ログの保持期間は自社のセキュリティポリシーに合わせるが、通常の操作ログは 90 日、セキュリティインシデントに関連するログは 1 年以上を目安としている組織が多い。またログ自体へのアクセス権限も重要な設計要素だ。ログを閲覧できる担当者を情シスと IT 管理者に限定し、閲覧履歴自体もトレースできる構成にすることで、改ざんリスクを低減できる。

障害時の意思決定フロー：MCP サーバーが停止したとき

MCP サーバーが本番稼働に入ると、そのサーバーに依存した業務フローが生まれる。停止したときの影響を事前に把握し、対応フローを整備しておくことが重要だ。

対応担当の事前合意

情シス・開発担当・ベンダーの三者が関与する場合、その境界が曖昧なまま本番稼働させると障害発生時に対応が迷走する。以下の区分を事前に合意しておくことで、障害発生から 5 分以内に「自分たちが対応すべき問題か」を判断できる。

レイヤ 例 主な一次担当
インフラ・ネットワーク サーバーダウン、VPN 断 情シス or インフラ担当
認証・権限 OAuth 失効、スコープ不足エラー 情シス
接続先 SaaS の障害 外部 API 障害 等 ベンダー確認（情シスが窓口）
アプリケーション不具合 MCP サーバーのコードバグ 開発担当

意思決定の 4 ステップ

Step 1: 影響範囲の確認（発生直後）

MCP サーバーへの依存度が高い業務（自動化されたワークフロー等）と、代替手段がある業務（人が手動でも対応できる業務）を区別することが最初の判断になる。影響するユーザー数と業務の緊急度を組み合わせて対応の優先度を決め、早めにエンドユーザーへの一次連絡を出す。「現在、〇〇サービスに接続する機能に障害が発生しています。調査中です。」の一文だけでも、問い合わせを大幅に減らせる。

Step 2: 原因の大分類（10〜15 分以内）

MCP サーバー障害の原因は概ね 4 種類に分類できる。

  • インフラ層の問題（サーバー自体のダウン、ネットワーク障害）
  • 認証層の問題（OAuth トークンの失効、スコープ変更による拒否）
  • 接続先 SaaS 側の問題（API 障害、メンテナンス）
  • MCP サーバーアプリケーション自体の問題（コード不具合、設定ミス）

大分類の判断材料は、サーバーのヘルスチェック結果・OAuth エラーログ・接続先 SaaS の公式ステータスページの 3 点で足りることが多い。なお、OAuth トークンの失効による認証エラーは頻出する障害原因だ。深夜のバッチ処理中に失効して翌朝気づくパターンが典型的なため、OAuth エラーのアラート設定を事前に入れておくと初動を短縮できる。

Step 3: 業務継続の判断

完全復旧までの間、代替手段で業務を継続できるかを判断する。MCP サーバー停止中に「手動に戻す」という選択肢を社内で周知しておくことが、障害時の混乱を抑える。

Step 4: 復旧後の棚卸し

復旧後に「なぜこの障害が発生したか」「権限設定に見直しが必要か」を確認し、次回の定期棚卸しのチェック項目に反映させる。障害を「個別の出来事」として処理して終わりにせず、ガバナンスの改善インプットとして活用することが、長期的な安定稼働につながる。

運用ポリシーを文書化する

個別の棚卸しや監査対応を属人的に進めているだけでは、担当者が変わったときに継続性が失われる。最低限、以下の 4 点を文書として整備しておくことを勧める。

  • MCP サーバー台帳：名称・接続先 SaaS・オーナー・スコープ・稼働開始日
  • 棚卸し手順書：実施サイクル・確認項目・判定基準・記録の保管先
  • 監査ログ収集設計書：収集対象・収集経路・保持期間・閲覧権限
  • インシデント対応フロー：初動確認ステップ・エスカレーション先・事後記録の形式

サーバー台帳の最小構成

台帳はスプレッドシートで十分だ。1 サーバーにつき 1 行、以下のカラムを最低限持たせることで、棚卸し時に必要な情報を一覧で把握できる。

カラム名 記載内容 入力例
サーバー名 識別可能な名称 sales-crm-mcp-prod
接続先 SaaS 何に接続しているか Google Workspace Drive
オーナー 担当者氏名 + 連絡先 IT 担当 (it@example.com)
付与スコープ OAuth スコープの概要 読み取り専用 / ファイル全般
稼働開始日 本番リリース日 2026-04-01
最終アクセス日 直近のアクセス記録 2026-06-20
棚卸し済み日 直近の確認実施日 2026-06-25

台帳と手順書はスプレッドシートや社内 Wiki で管理するだけでも機能する。ツールの精巧さより、実際に運用を回し続けることのほうが重要だ。設計変更や棚卸し結果を記録する際、「いつ・誰が・何を変更したか」の更新履歴を残しておくと、監査対応や障害調査のときに変更の経緯を追跡しやすくなる。

まとめ

MCP サーバーの本番運用ガバナンスは、導入設計が完了した後に始まる継続的な作業だ。権限の棚卸し・監査ログの収集・障害対応フローの 3 本柱を整備することで、「稼働し続けることへの対応力」が生まれる。

実務のポイントは 3 点に集約される。棚卸しは四半期サイクルで幽霊化した接続をつぶし続けること、監査ログは目的を先に決めてから収集経路を選ぶこと、障害対応は「誰の守備範囲か」を事前合意しておくことだ。

まずサーバー台帳と四半期棚卸しから始め、監査ログとインシデント対応フローを段階的に整備していく順番が、現場で回し続けられる現実的な進め方になる。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。

CONTACT

御社の IT 部門、ここにあります。

「ITのことはあまりわからない」── そのような状態からで、まったく問題ございません。まずはお気軽にご相談ください。

無料相談を予約する → サービス詳細を見る
一社ずつ、一から。