MCP導入前に考えるセキュリティ設計|認証・権限・ログ管理の基本

MCP(Model Context Protocol)を利用すると、AIアプリケーションから外部のデータやツールへ接続し、情報取得やAPIの呼び出しなどを行えるようになります。MCPサーバーが公開するツールをAIから利用できるため、活用範囲を広げやすい一方、接続先や与える権限によっては、機密情報へのアクセスや外部システムの操作にも関わります。

そのため、MCP導入では「接続できるか」だけでなく、誰が利用するのか、どのデータやツールへのアクセスを許可するのか、どの操作まで実行できるのか、実行後に何が起きたかを追跡できるのかまで設計する必要があります。

この記事では、MCP導入前に整理しておきたいセキュリティ設計を、認証・認可、権限管理、ログ・監査の3つを中心に解説します。

目次

MCP導入前にセキュリティ設計が必要な理由

MCPを業務で利用する際は、接続設定だけでなく、その接続によってAIが何を参照し、何を実行できるようになるのかを把握する必要があります。
AIがツールを利用して外部システムへ働きかける構成では、利用者本人の権限だけでなく、AIを介して実行できる操作の範囲まで含めて考えることが重要です。

MCPではAIから外部ツールやデータへアクセスできる

MCPは、AIアプリケーションと外部のデータやツールを接続するための共通的な仕組みです。MCPサーバーはツールを公開でき、AIアプリケーションはそれらを通じてデータの取得、APIの呼び出し、各種処理の実行などを行えます。

そのため、MCPサーバーを追加する際は、サーバー名だけを確認しても十分ではありません。どのツールを公開しているのか、そのツールはどのシステムやデータへアクセスするのか、読み取りだけなのか更新や削除まで可能なのかを確認しなければ、実際の影響範囲を把握できません。

MCPそのものの仕組みを理解していない場合は、先にMCPクライアント、MCPサーバー、外部ツールの関係を整理しておくと、セキュリティ設計の考え方も理解しやすくなります。

接続できることと安全に利用できることは別

MCPサーバーへの接続に成功しても、それだけで安全な利用環境が完成するわけではありません。情報参照だけで十分な用途に更新や削除まで可能な権限を与えれば、誤操作や不正利用が起きたときの影響範囲は広がります。

また、MCPのセキュリティでは、認証やアクセストークンだけでなく、過剰な権限、認可フロー、MCPサーバー自体の信頼性、実行環境なども考える必要があります。特にローカルで動作するMCPサーバーは、実行環境で許可されたファイルやネットワークへアクセスできる場合があるため、どのサーバーを利用するか、どの権限で動かすかも確認が必要です。

導入前には、認証・認可で「誰に利用させるか」、権限管理で「何を許可するか」、ログ・監査で「何が行われたかを追跡できるか」を分けて整理します。

MCPの認証・認可は「誰が何を利用できるか」で考える

MCPのセキュリティ設計では、認証と認可を分けて考える必要があります。認証は利用者やシステムが誰なのかを確認する仕組みで、認可は確認された利用者やシステムに対して、どのリソースや操作へのアクセスを許可するかを制御する仕組みです。

認証と認可は役割が異なる

利用者が正しく認証されていても、その利用者にすべての操作を許可してよいとは限りません。MCPでも、「接続を許可された利用者だから、MCPサーバーの全機能を利用できる」と考えると、必要以上に権限が広がる可能性があります。

利用者や用途に応じてアクセス範囲を分け、必要な操作だけを許可することが基本です。認証で利用主体を確認し、その後に認可で利用できるリソースや操作を絞るという順序で考えると、それぞれの役割を整理しやすくなります。

また、個人の利用者だけでなく、システム同士が連携する場合にも、どの主体にどの権限を与えるのかを明確にする必要があります。認証済みであることと、安全な権限設定ができていることは別の問題として扱います。

HTTPで認可を実装する場合はOAuth 2.1を基礎に考える

HTTPを利用するMCPで認可を実装する場合、OAuth 2.1を基礎とした仕組みを利用します。MCPクライアントはアクセストークンを使って保護されたMCPサーバーへアクセスし、MCPサーバー側では受け取ったトークンを検証します。また、スコープを使って要求するアクセス範囲を制御する考え方もあります。

ただし、MCPを使うすべての構成でOAuth 2.1による認可が必要になるわけではありません。たとえばstdioを利用する実装では、HTTP向けの認可仕様に従うのではなく、環境から認証情報を取得する方法が基本となります。

そのため、「MCPを導入するならOAuthを設定すればよい」と一律に考えるのではなく、どの接続方式を利用するのか、どのシステムへ接続するのか、誰が利用するのかを整理したうえで、適切な認証・認可の方法を選ぶ必要があります。

認証情報やアクセストークンの扱いも設計する

認証・認可の仕組みを用意しても、認証情報そのものの管理が不十分であれば安全性は保てません。アクセストークンやリフレッシュトークン、APIキーなどをどこへ保存するのか、誰が参照できるのか、不要になった際にどう失効させるのかまで決める必要があります。

MCPサーバーでは、自分向けに発行されたアクセストークンを適切に検証し、別のサービス向けのトークンをそのまま受け入れたり、下流のサービスへそのまま転送したりしないことも重要です。

企業では退職や異動、担当変更によって必要なアクセス権限が変わります。導入時の設定だけで終わらせず、認証情報の保管、更新、失効まで含めて管理方法を決めておきます。

MCPの権限は必要最小限に設計する

認証された利用者でも、業務に不要な操作まで許可すれば、事故や不正利用が起きた際の影響範囲が広がります。
MCPの権限設計では、「利用できるか、できないか」だけではなく、どの接続先、ツール、データ、操作を許可するのかまで分解して考えることが重要です。

接続先・ツール・データ・操作の4段階で権限を整理する

まず、利用者がどのMCPサーバーを利用できるのかを整理します。次に、そのMCPサーバーでどのツールを利用できるのか、ツールからどのデータへアクセスできるのか、最終的にどの操作を実行できるのかを確認します。

つまり、権限は「MCPサーバーへの接続を許可する」という一段階だけで考えるのではなく、接続先、ツール、データ、操作の4段階に分けることが重要です。

たとえば、同じMCPサーバーから複数のツールを利用できる場合でも、すべての利用者がすべてのツールを必要としているとは限りません。さらに、同じツールでも扱えるデータの範囲や実行できる処理を限定できる場合があります。

利用目的から必要な範囲を逆算し、不要なツールやデータへのアクセスを許可しない設計にします。

読み取りと更新・削除では必要な権限を分ける

情報検索が目的なら、データの更新や削除まで許可する必要はありません。読み取りだけで業務要件を満たせる場合は権限を限定することで、誤操作や不正利用が発生した際の影響を抑えられます。

書き込みが必要な用途でも、作成、更新、削除をすべて同じ権限として扱う必要はありません。作成は必要だが削除は不要、特定のデータだけ更新できればよいなど、業務内容に応じて必要な操作を分けます。

権限を広く付与して「削除はしない」「このデータには触れない」といった運用ルールだけで制御するよりも、不要な操作をシステム上で実行できない状態を作る方が安全です。MCP導入時には、必要最小限の権限から始め、必要性を確認しながら範囲を広げる考え方が適しています。

影響の大きい操作には利用者の確認を組み込む

MCPのツールを利用できても、すべての処理を確認なしで自動実行させる必要はありません。データ削除、外部への情報送信、重要な設定変更など、実行後の影響が大きい操作では、利用者が実行内容を確認し、必要に応じて拒否できる仕組みを設けます。

特に、元に戻すことが難しい操作や外部への影響が大きい操作では、AIが処理を選択した後に人が確認してから実行する方法も考えられます。

どこまでAIへ任せ、どの操作では人の確認や承認を挟むのかを導入前に分類しておけば、利便性を維持しながら重要な操作だけを慎重に扱えます。

MCP経由の操作を追跡できるログ・監査設計を行う

認証と権限を適切に設定しても、想定外の操作を完全になくせるわけではありません。問題が発生した際に原因や影響範囲を調査できるよう、MCP経由の操作を追跡できるログ・監査の仕組みも必要です。

ログを残す目的を明確にする

ログは保存すること自体が目的ではありません。不正利用の確認、誤操作の原因調査、インシデント発生時の影響範囲の特定、権限が想定どおり利用されているかの監査など、何を確認するために記録するのかを決めます。

ここで注意したいのが、MCPプロトコルのLogging機能と、企業がセキュリティ管理のために残す監査ログは同じものではないことです。現行のMCP仕様ではプロトコル内のLogging機能は非推奨となっていますが、MCP経由で行われた操作を監査できる状態を作る必要性がなくなったわけではありません。

そのため、MCPの機能としてログを出力することと、企業が業務やセキュリティ管理のために操作履歴を記録することを分けて設計します。

「誰が・いつ・何をしたか」を追跡できる状態にする

監査では、利用者、実行日時、利用したMCPサーバーやツール、実行した処理、対象となったデータやシステム、処理結果などを関連付けて追跡できることが重要です。

外部システム側に更新履歴が残っていても、どのMCPツールが呼び出され、どの利用者の操作を起点として実行されたのかが分からなければ、原因調査が難しくなります。AIアプリケーション、MCPサーバー、接続先システムをまたいで処理を追えるようにします。

ただし、監査のためにすべての入力内容を保存すればよいわけではありません。監査目的に必要な情報を選び、必要に応じて相関IDやトレースを利用して一連の処理を結び付けます。

ログそのものの保護も必要になる

企業が監査目的で独自に記録するログでは、利用者名、処理対象、実行結果などを扱う場合があり、設計によっては機密情報や個人情報が含まれる可能性があります。そのため、監査に必要な情報だけを記録し、ログへのアクセスも適切に制御する必要があります。

ログを閲覧できる担当者を限定し、保存期間や削除方法を決めることも重要です。また、アクセストークンやAPIキーなどの認証情報をログへ記録しないようにします。

なお、MCPプロトコルのLoggingメッセージにも、認証情報や秘密情報、個人識別情報などを含めないようにする必要があります。

ログを詳しく残すほど安全になるわけではありません。調査や監査に必要な情報を確保しながら、ログそのものが新たな情報漏えいの原因にならないように管理します。

MCP導入前に決めておきたいセキュリティ運用

認証、権限、ログを個別に設定するだけでは、導入後の運用で抜けが生じる可能性があります。MCPを継続して利用するなら、接続先や利用者、権限が変化することを前提に管理ルールを作る必要があります。

利用するMCPサーバーと接続先を把握する

まず、社内で利用するMCPサーバーを把握し、それぞれがどの外部システムやデータへ接続するのかを整理します。MCPサーバー名だけでなく、公開するツール、接続先、扱う情報、実行可能な操作まで確認します。

外部から提供されるリモートMCPサーバーや、利用者が追加するローカルMCPサーバーについては、提供元や配布元が信頼できるかも確認します。

MCPサーバーや接続先が増えるたびに確認する管理手順を設け、組織として把握できないMCPサーバーが増えないようにします。誰が追加を許可できるのか、利用開始前にどの項目を確認するのかまで決めておくと、導入後も管理しやすくなります。

利用者と権限の管理ルールを決める

誰がMCPを利用できるのか、誰が新しいMCPサーバーや権限を追加できるのかを決めます。また、権限付与の申請・承認方法、管理責任者、異動や退職時の変更・削除方法まで整理します。

特に機密性の高いデータや更新・削除を伴うツールでは、情報参照だけを行うツールより厳しい権限管理が必要です。認証基盤を用意して終わりにせず、実際の業務運用と権限管理を結び付けます。

MCPを利用する部門や用途が増えれば、当初想定していなかった権限が必要になる場合もあります。その際も、既存の権限を広げるだけではなく、誰が何のために必要としているのかを確認したうえで追加します。

権限とログは定期的に見直す

導入時に適切だった権限が、その後も必要とは限りません。業務内容や担当者、接続するシステム、MCPサーバーが変われば、必要なアクセス範囲も変化します。

不要になったMCPサーバーやツールへのアクセスを削除し、利用者に過剰な権限が残っていないか定期的に確認します。ログも保存するだけではなく、異常な利用や想定外の操作がないか確認できる運用を設けます。

また、MCPサーバーや接続先の変更によって、新しいツールや操作が追加される場合もあります。導入時に確認したから安全だと考えるのではなく、構成変更に合わせて権限や監査対象を見直します。

MCPの導入範囲が広がるほど、接続先、権限、利用者、ログを一体として管理し、変更に合わせて見直せる状態が重要になります。

まとめ|MCPのセキュリティは接続前の設計から始める

MCPを利用すれば、AIと外部システムをつなぎ、情報取得からツール実行までAI活用の範囲を広げられます。一方、接続できるシステムや実行できる操作が増えれば、管理すべき範囲も広がります。

MCPのセキュリティ設計では、まず認証・認可によって「誰が利用できるのか」を管理します。次に、接続先、ツール、データ、操作ごとに権限を分け、「何をできるのか」を必要最小限に制限します。さらにログ・監査によって、「誰が何を実行したのか」を後から追跡できる状態を作ります。

重要なのは、この3つをMCP接続後に追加する対策として考えないことです。MCPで実現したい業務を整理し、その目的に必要な接続先と権限を決め、操作を追跡する方法まで設計してから導入します。

また、導入時の設定を固定したまま運用するのではなく、利用者、接続先、ツール、業務内容の変化に合わせて権限やログ管理を見直すことも必要です。

認証、権限、ログを導入前から一体で設計すれば、MCPの利便性を活かしながら、必要以上にアクセス範囲を広げない運用につなげられます。


シーサイドでは、各種AIツールの活用に関するご相談も受け付けております。
お困りやご相談がありましたら、まずはお気軽にお問い合わせください。

目次