はじめに
前回は、Backstageのカタログを「AIエージェント向けコンテキスト源」として設計する際の判断軸を整理しました。⇒AI Ready な IDP の設計とは？
今回はその続きとして、実際にAIエージェントがBackstageを呼び出す経路、つまりMCP（Model Context Protocol）サーバーとしての公開を、どう安全に運用していくかを扱います。
本番運用に耐えうるMCPサーバーの要件とは？
MCPは、AIクライアントとツール・データソースの間の通信規約を定めた標準です。ここで押さえておきたいのは、MCPはあくまで「接続の仕方」を定めた仕様であって、認証・レート制限・監査ログといった運用上の安全対策は仕様の範囲外だという点です。
Backstageに実際にMCPプラグインを組み込んだ事例でも、この点は明確に意識されています（Turning Backstage into an AI-Ready Platform with MCP）。プラグイン自体は比較的簡単に組み込めるものの、本番環境でAIエージェントにカタログへの書き込み権限を与えることは、認証・レート制限・監査ログについて慎重に検討すべき課題だと位置づけられており、実際にその事例では最初の導入を開発環境限定にとどめ、設定の切り替えによって本番環境にはMCPプラグイン自体を存在させないという構成を取っています。
つまり、「MCPサーバーとして動かせること」と「安全に本番運用できること」の間には、埋めるべき溝があります。以下、その溝を埋めるための4つの論点（認証、権限分離、レート制限、監査ログ）を順に見ていきます。
認証：静的トークンでの検証から、サービスアカウントベースの本番運用へ
MCPサーバーを最初に試すときは、固定のBearerトークンを使った認証で十分です。実際のBackstage導入事例でも、開発環境での実験段階では静的トークンを使い、外部アクセス設定にトークンとアクセス対象のプラグインを紐づける形で始めています（Digital Applied「MCP Server Security Best Practices: 2026 Engineering Guide」）。
ただし、これはあくまで実験段階の割り切りです。本番運用に進める際には、静的トークンをサービスアカウントベースの認証に置き換え、Backstageが備えている権限フレームワークと紐づけて、「どのクライアントが」「どの権限で」呼び出しているかを追跡できるようにする必要があります。MCPの仕様自体は、リモートサーバーの認証方式としてOAuth 2.1を標準的な選択肢として位置づけており（MCP Beast「MCP Authentication & OAuth 2.1 Explained」）、トークンの署名・有効期限・対象範囲（audience）・スコープをサーバー側で検証する構成が前提になっています。静的トークンはあくまで「動作確認のための踏み台」であり、最終形ではないと捉えておくのが安全です。
権限分離：読み取りツールと書き込みツールを最初から分けて考える
AIエージェントにBackstageへのアクセスを許可する際、最初から検討しておきたいのが「読み取り」と「書き込み」の分離です。カタログを検索する、依存関係を確認する、といった読み取り系のツールは比較的広く公開しやすい一方、コンポーネントを登録する、Scaffolderのテンプレートを実行する、といった書き込み系のツールは、より厳格な制御の対象にすべきです。
実際のBackstage導入事例でも、読み取りツールは広く公開しつつ書き込みツールはより厳しい制御の下に置くという方針が、今後詰めるべき課題として挙げられています（Turning Backstage into an AI-Ready Platform with MCP）。これは前回扱った「段階導入は読み取り専用・開発環境限定から始める」という考え方の延長線上にある論点です。
権限を細かく絞ることには、セキュリティ上の理由だけでなく別の利点もあります。エージェントに渡す情報の範囲を絞ることで、コンテキストウィンドウを不要に膨らませず、結果としてハルシネーションのリスクを下げるという効果も期待できます。「権限を絞る」ことは、安全性の問題であると同時に、エージェントの挙動を安定させるための設計でもあるわけです。
レート制限：AIエージェント特有のトラフィックパターンへの対処
人間が操作するAPIのレート制限は、「1秒間に何回まで」といった比較的穏やかな前提で設計されることが多いですが、AIエージェントのトラフィックパターンはこれとは性質が異なります。エージェントはエラーに遭遇すると即座に、時には数秒間に何十回もリトライを繰り返すことがあり、レート制限という歯止めがないと、こうしたループがサーバーや依存先のAPIを圧迫してしまいます。
実際に、暴走したエージェントが数時間で12万回を超えるAPI呼び出しを行い、数万ドル規模のクラウド費用を発生させた事例も報告されています（MintMCP「MCP Rate Limiting: Why Your AI Agent Needs Traffic Controls」）。金額の大小はさておき、「エージェントは人間よりもずっと速く、ずっと執拗にリトライしうる」という前提でレート制限を設計する必要がある、という点は押さえておくべきです。
実務的には、クライアントやエージェントの識別子ごとにリクエスト数を追跡し、閾値を超えたら明確なエラーを返す、という基本的な仕組みに加えて、読み取りツールと書き込みツール（ミューテーション系のツール）で異なる上限を設定することが推奨されています（Digital Applied「MCP Server Security Best Practices: 2026 Engineering Guide」）。制限に達した際にはリトライまでの待機時間を示すヘッダーを返し、エージェント側は指数的に待機時間を伸ばしながら再試行する、という組み合わせが一般的な対処法です。
監査ログ：MCP標準の仕組みだけでは不十分
MCP自体が備えているログ機能は、主にデバッグ用途を想定した軽量なもので、多くの場合セッションが終了したりプロセスが再起動したりすると失われてしまいます。複数のエージェント・複数のツールが本番環境で動く状況において、後から「いつ・誰が・何を・なぜ実行したか」を追跡する必要がある監査要件を満たすには、これでは不十分です。
Backstageの文脈でも、AIエージェントが本番システムに触れる以上、何を照会し、何を変更したかを明確に追跡できるログが必要だという点が、今後取り組むべき課題として挙げられています（Nitin Jain「Turning Backstage into an AI-Ready Platform with MCP」（Medium、2026年3月））。実務上は、MCPサーバー自体のログに頼るのではなく、エージェントとサーバーの間に立つ仲介層（ゲートウェイ的な構成）を通じて、すべてのやり取りを一元的に記録する構成を検討する価値があります。ここで重要なのは、ログに記録すべきなのは「呼び出しの内容と主体」であって、認証に使ったトークンやシークレットそのものではない、という点です。ログには鍵のIDや参照情報を残し、生のシークレットは残さない設計が望ましいとされています。
段階導入の道筋
ここまでの論点を踏まえると、導入の進め方は次のような段階を踏むのが妥当だと考えられます。
- 開発環境限定・静的トークン：まずは動作確認。設定の切り替えによって、本番環境にはMCPサーバー自体を存在させない
- 本番・読み取り専用・限定権限：サービスアカウントベースの認証に切り替え、読み取り系ツールのみを、絞った権限で公開。監査ログとレート制限をここで整備する
- 本番・書き込み解禁：監査ログとレート制限の運用実績を踏まえ、書き込み系ツールを、より厳格な権限とkill-switch（問題が起きたツールだけを即座に無効化できる仕組み）付きで解禁していく
一足飛びに書き込み権限まで開放するのではなく、段階を意識しておくと、問題が起きたときの影響範囲を小さく保つことができるはずです。
制約・注意点
- 本記事で扱った内容は、Backstage向けのMCPプラグイン自体がまだ発展途上であることを前提にしています。認証方式やツールの粒度は、今後のアップデートで変わる可能性があります。
- MCPゲートウェイ製品（商用の集中管理基盤）の比較・選定は本記事の範囲外としました。自組織でBackstage単体にMCPを組み込む場合の論点に絞っています。
- レート制限や監査ログの具体的な閾値・保持期間は組織のポリシーやコンプライアンス要件によって大きく異なるため、本記事では一般的な考え方の整理にとどめています。
まとめ
- MCPは接続の規約であり、認証・レート制限・監査ログといった運用上の安全対策は自分たちで設計する必要があります。
- 認証は、静的トークンでの実験から、サービスアカウントベースの本番運用へと段階的に移行するのが妥当です。
- 読み取りツールと書き込みツールは最初から分けて考え、権限を絞ることでセキュリティとハルシネーション抑制の両方にメリットがあります。
- AIエージェントはリトライを含め人間より高頻度・高強度のトラフィックを生みうるため、ツール種別ごとに異なるレート制限を設ける必要があります。
- MCP標準のログは監査要件を満たさないため、仲介層を通じて一元的に記録する構成を検討する必要があります。
参考リンク
- Nitin Jain「Turning Backstage into an AI-Ready Platform with MCP」（Medium、2026年3月）
- Digital Applied「MCP Server Security Best Practices: 2026 Engineering Guide」
- MintMCP「MCP Rate Limiting: Why Your AI Agent Needs Traffic Controls」
- ByteBridge「Implementing Audit Logging and Retention in MCP」（Medium）
- MCP Beast「MCP Authentication & OAuth 2.1 Explained」
注意事項
本ブログに掲載している内容は、私個人の見解であり、
所属する組織の立場や戦略、意見を代表するものではありません。
あくまでエンジニアとしての経験や考えを発信していますので、ご了承ください。