← ブログに戻る

2026年7月25日

MCPサーバー連携のセキュリティ設計:OAuth 2.0・PKCE・SSRF対策まで

「AIチャットボットが社内システムに接続する」。ビジネス側には魅力的な話ですが、情報システム部門にとっては新たな攻撃対象領域(アタックサーフェス)が広がる話でもあります。

MCPとは何かの解説記事では仕組みとメリットを紹介しました。本記事はその続編として、MCP連携を安全に運用するためのセキュリティ設計を、OneBotの実装をもとに解説します。ベンダー選定時のチェックリストとしてもお使いください。

MCP連携で新たに生まれる4つのリスク

MCP連携は「AIが外部サーバーのツールを呼び出す」構造です。ここには従来のチャットボットにはなかったリスクが生まれます。

#リスク何が起こりうるか
1認証情報の漏洩接続先システムのトークンが盗まれ、なりすましアクセスされる
2SSRF(サーバーサイドリクエストフォージェリ)悪意あるURL登録により、内部ネットワークへの不正アクセスの踏み台にされる
3暴走・過剰実行AIがツールを無制限に呼び続け、対象システムに負荷・意図しない操作
4過剰な権限付与必要以上の操作権限をAIに与え、事故の影響範囲が拡大

以下、それぞれにどう対処すべきか(OneBotがどう実装しているか)を見ていきます。

対策1:認証はOAuth 2.0+PKCEを標準に

接続先システムへの認証で最も避けるべきは、「APIキーを平文で渡して終わり」という運用です。

OneBotのMCP連携は3つの認証モードに対応しています。

  1. 認証なし(社内の閉じた検証環境など限定用途)
  2. ヘッダー認証(APIキー等をヘッダーで送信)
  3. OAuth 2.0(推奨)

OAuth 2.0モードでは、次の標準仕様に準拠しています。

  • Authorization Code + PKCE:認可コード横取り攻撃への標準的対策
  • RFC 8414(サーバーメタデータ検出):接続先の認可サーバー情報を自動検出し、発行者(issuer)の整合性を検証
  • RFC 7591(動的クライアント登録):対応サーバーには手動設定なしで安全にクライアント登録

取得したアクセストークン・リフレッシュトークンは暗号化して保存され、期限切れ時は自動更新されます。管理画面には接続ごとのリダイレクトURIが表示され、OAuthプロバイダー側への登録もコピー1回で済みます。

チェックリスト観点: ベンダーに「OAuth対応」とだけ聞くのではなく、「PKCE対応か」「トークンは暗号化保存か」「自動更新の実装は」まで確認しましょう。

対策2:SSRF対策で「どこに接続できるか」を検証する

MCP連携の見落とされがちな急所がSSRFです。管理者が登録したURLに向けてサーバーがリクエストを送る構造上、悪意ある(あるいは誤った)URL登録が内部ネットワークへの入口になりえます。

OneBotでは多層の防御を実装しています。

  • URL・IPレンジ検証:接続先URLを解決した実IPを検証し、内部ネットワーク帯への接続を遮断
  • DNSピンニング:検証時と接続時でIPが差し替わる攻撃(DNSリバインディング)への対策として、検証済みIPに接続を固定
  • リダイレクト追跡時の再検証:リダイレクト先も同じ基準で再検証
  • 送信ヘッダーの制御:接続先へ送るヘッダーを制限し、内部情報の漏出を防止
  • 接続テストの保護:管理画面の「接続テスト」機能自体にもレート制限と記録を適用

チェックリスト観点:「任意のURLを登録できる機能」があるツールには、必ずSSRF対策の有無を確認してください。ここが最も差が出るポイントです。

対策3:実行制限でAIに「ブレーキ」を組み込む

AIエージェントの実務リスクで最も現実的なのは、悪意ある攻撃よりも過剰実行です。ツール呼び出しが際限なく連鎖すれば、接続先システムへの負荷や意図しない多重実行につながります。

OneBotのエージェントループには、構造的なブレーキが組み込まれています。

制限
接続できるMCPサーバー数最大5つ/プロジェクト
ツール数最大50個/サーバー
ツール実行回数最大5回/1応答
実行時間合計25秒以内/1応答(個別呼び出しにも上限)

上限に達した場合、AIはそれまでに取得した情報で回答を生成し、処理を打ち切ります。「最悪の場合でもここまで」が数値で保証されていることが、情シス説明での説得材料になります。

対策4:記録と可視性で「何が起きたか」を追える状態にする

インシデント対応の基本は記録です。OneBotでは次が標準で確認できます。

  • どのツールを・いつ・何回呼び出したか(会話単位で記録)
  • ツール呼び出しに使われたAI利用量(トークン使用量ダッシュボードに計上)
  • 接続設定の変更(サーバー追加・認証変更などの管理操作)

「AIが何をしたか説明できない」状態を避けることは、社内統制の面でも監査対応の面でも必須要件です。

プラットフォーム基盤のセキュリティ

MCP連携部分だけでなく、基盤側の対策も選定時の確認事項です。OneBotの場合:

  • 学習データの保存時暗号化:アップロードされた文書は暗号化して保存
  • テナント分離:顧客(テナント)間のデータアクセスをアプリケーション層で遮断
  • 会話履歴の保持期間管理:設定した保持期間を過ぎた履歴の自動削除
  • 公開フォームのbot対策:reCAPTCHAによる不正送信防止
  • データ所在:すべて日本国内サーバーで処理・保管。APPI(個人情報保護法)に準拠した運用が可能

情シス向け:MCP連携ベンダー選定チェックリスト

最後に、本記事の内容をチェックリストにまとめます。

  • OAuth 2.0 + PKCE に対応しているか
  • トークンは暗号化保存され、自動更新されるか
  • SSRF対策(IP検証・DNSピンニング・リダイレクト再検証)があるか
  • ツール実行の回数・時間上限が数値で明示されているか
  • ツール呼び出しの記録が会話単位で残るか
  • 学習データ・認証情報の保存時暗号化があるか
  • データの国内保管とAPPI準拠が明言されているか

よくある質問(FAQ)

Q1. MCP連携を有効にしなければ、これらのリスクはありませんか?

はい。MCPサーバーを登録しない限り、チャットボットは従来どおり文書ベースの回答のみを行います。連携は必要になった時点で有効化すれば問題ありません。

Q2. 読み取り専用の連携に限定できますか?

接続するMCPサーバー側で公開するツールを照会系に限定すれば、実質的に読み取り専用として運用できます。書き込み系ツールを含める場合は、実行制限と記録を前提に設計してください。

Q3. OAuthに対応していない社内システムはヘッダー認証で問題ありませんか?

閉域環境や検証段階ではヘッダー認証も実用的です。本番運用で外部公開されたシステムに接続する場合は、OAuth 2.0への移行を推奨します。

Q4. 接続先のMCPサーバーが乗っ取られた場合は?

影響はそのサーバーが公開するツールの範囲に限定されます。実行回数・時間の上限と呼び出し記録により、異常な挙動の検知と影響範囲の特定が可能です。

Q5. 通信は暗号化されますか?

MCPサーバーとの通信はHTTPSで行います。プラットフォーム側でも保存データの暗号化を実装しています。

Q6. セキュリティ資料を情シスに提出したいのですが。

トライアルお申し込み後、本記事のチェックリスト項目に対応した技術説明をご案内できます。お問い合わせください。

まとめ

  • MCP連携の主リスクは「認証情報」「SSRF」「過剰実行」「過剰権限」の4つ
  • OneBotはOAuth 2.0+PKCE、多層SSRF防御、数値で保証された実行制限、会話単位の記録を実装
  • 基盤側も暗号化・テナント分離・日本国内サーバーでAPPI準拠運用に対応

セキュリティ設計を含め、実際の管理画面はトライアルで確認できます。14日間無料・カード登録不要です。

👉 無料トライアルを開始する