「MCP」とは何か ーMCPにおける認証/認可の仕組みを理解しよう
はじめに
近年、AIは驚くほどのスピードで進化を遂げています。このAIによる推論には、情報の意味付けや関連性を示す「コンテキスト」が不可欠です。AIエージェントは、使用するツールやサービス間でこのコンテキスト情報を共有することで、多岐にわたるタスクを高精度に実行できます。
このコンテキスト共有を容易にするためのプロトコルとして登場したのが「MCP(モデルコンテキストプロトコル)」です。しかし、AIに任せるタスクによってはコンテキスト情報に機密性の高いデータが含まれることもあり、漏洩すれば深刻な問題につながります。MCPの登場によりAIの利便性は高まる一方で、AIシステムのセキュリティの重要性もより一層高まっています。
本連載では、MCPのセキュリティを支えている認証/認可の仕組みについて紐解いていきます。さらに、OSSである「Keycloak」を用いて、MCPに認証/認可を導入する実装方法についても取り上げます。第1回となる今回は、MCPの概要とその認証/認可の仕様について解説します。
AIにとって「コンテキスト」とは何か
AIは近年の進化により、単に指示されたタスクを正確にこなすツールというだけでなく、コンテンツの生成・設計・改善点の指摘など、より高度なレベルで人間の生活を支援する存在となりつつあります。
一方で、AIが人間と共生する上で大きな障壁となるのが、人間が日常的に使う言葉に内在している「曖昧さ」です。AIは様々な情報から人間の意図を推測し実行しますが、必ずしもそれが人間の意図と合致するとは限りません。
この曖昧さをAIが理解する鍵となっているのが「コンテキスト」です。いかに人間がコンテキストを適切に設計しAIに扱わせるかが、AIとのコミュニケーションの質を高める重要なポイントです。まずは、このコンテキストの本質を探っていきましょう。
私たちの周りには、無数の「データ」が存在しています。例えば“80”や“2025-07-07”という情報がデータです。これらは単なる文字列や記号の集まりであり、それ自体に特定の意味を持ちません。
このデータに「意味」や「解釈」が付随すると、データは「情報」に変わります。例えば、“80”というデータが「体重が80kgである」ことを示すという解釈、“2025-07-07”というデータが「“-”は年/月/日の区切りを意味し、現在の日付が2025年7月7日である」ことを示すという解釈が加わることで、データを「情報」として扱うことができるようになります。
そして、これらの情報が相互に意味を持って関連付けられた集合体が、AIにとってのコンテキストであり、これがAIによる推論の基盤となります。
例えば、身長と体重からやせ気味なのか太り気味なのかをAIに推論させるとします。このとき、当然「体重がXXkgである」という情報からだけでは体型を推論することはできませんが、「身長がYYYcmである」という情報も加えたらどうでしょうか。人間はこれらの情報からおおよその体型を推論し、やせ気味なのか太り気味なのかを推測できるようになります。これは、人間は知識や経験から体重と身長の情報が意味を持って関連付いていることを認識しており、そこから推論を行えるためです。
しかし、コンピュータにとっては「体重がXXkgである」「身長がYYYcmである」という情報だけではそれ以上の意味を持ちません。AIがこれらの情報から体型を推論するためには、「これらの情報が体型という観点からどういう意味を持って関連付いているのか」を認識している必要があります。この関係性をAIに認識させることこそがコンテキストの役割なのです(図1)。
図1：データ・情報・コンテキストの関係イメージ
MCPとは何か
AIは様々な外部ツールやサービスと連携することで、多岐にわたる作業を実行できます。しかし、前述したコンテキストの構造がツールやサービスごとにバラバラだと、連携の開発や運用に手間がかかります。
その課題を解決するために登場したのが、MCP(Model Context Protocol)です。MCPとはコンテキスト情報のデータ構造を標準化する共通ルール(プロトコル)で、これによりAIと外部ツール・サービス間の通信を統一された方式で接続できます。MCPは複数のAIサービスを活用する上で欠かせない技術となっています。
例えば、AIが異なる3つのサービスとやりとりしたいとき、従来はAIとサービスの組み合わせの数だけプロトコルを個別に考える必要がありました。しかし、MCPという共通のプロトコルを用意してサービス側がMCPに対応したサーバを提供することで、それぞれの連携を個別に構築する必要がなくなり、利便性が向上します(図2)。
図2：MCP導入前後の比較
MCPのアーキテクチャは以下のように構成されており、MCPサーバおよびアクセスするリソースの場所により大きく3パターンに分けられます(図3)。
- MCPサーバもリソースもローカルコンピュータにあるケース
- MCPサーバがローカルコンピュータ、リソースがインターネットにあるケース
- MCPサーバもリソースもインターネットにあるケース
図3：MCPアーキテクチャ
- MCPホスト：「Claude Desktop」「Cursor」といったAIアプリケーション。ユーザはこのMCPホストを通じて、AIに質問や指示を送っている
- MCPクライアント：MCPホストの内部に組み込まれているコネクタ(中継役)。各MCPサーバと1対に接続している
- MCPサーバ：外部ツール・サービスを呼び出すサーバ。MCPクライアントから受け取ったリクエストに応じてデータの取得や変更など特定の操作を実行し、その結果をMCPクライアントに返す
- リモートサービス：MCPサーバがインターネットを介して利用できる外部ツール・サービス
- ローカルデータソース：ローカルホスト内のファイルやデータベース。MCPサーバは、これらのローカルデータソースにアクセスすることもある
MCPの処理フロー
MCPには、サーバ・クライアントそれぞれが様々な機能を提供しています。
Specification - Model Context Protocol
MCPサーバが提供する機能の1つに「ツール」というものがあります。これは、MCPクライアントがファイル操作やAPI呼び出し等のアクションを実行するために呼び出せる関数を指します。また、MCPの通信レイヤでは「JSON-RPC 2.0」というプロトコルが使用されており、リクエスト・レスポンスはJSON形式で表現されます。
このツールを例にMCPの処理フローを追ってみましょう。MCPサーバ・MCPクライアント間でどのようなメッセージのやり取りがされているかについても、併せて見ていきましょう。
ここでは、アメリカ国立気象局(National Weather Service)より公開されているMCPサーバを利用します。このMCPサーバは、指定した地点(経度・緯度)の天気情報を取得できる「get_forecast」というツールを提供しています。このツールを例にすると、MCPの処理フローは図4のようになります。
図4：「get_forecast」におけるMCPの処理フロー例
1つずつ、処理フローを見て行きましょう。
- ClaudeなどのAIアプリの設定ファイルにMCPサーバの情報を記述することで、MCPクライアントとMCPサーバが接続される。このとき、MCPクライアントはMCPサーバへ使用可能なツール一覧を取得するためのリクエストを送る。
{ "method": "tools/list", "params": null, "jsonrpc": "2.0", "id": 1 } - MCPサーバは、MCPクライアントへツール情報のレスポンスを返す。
{ "jsonrpc": "2.0", "id": 1, "result": { "tools": [ { "name": "get_forecast", "description": "Get weather forecast for …”, <…> - ユーザがAIアプリに「サンフランシスコの天気を教えて」と入力する。
- MCPクライアントがユーザからの入力をLLMに送る。このとき2.で取得したツールの情報も併せて送る。
- LLMは入力内容を分析し、ツール“get_forecast”をどのように実行すれば良いか、具体的な操作内容をMCPクライアントへ返す。
- MCPクライアントは、この操作内容に基づいてMCPサーバにツール実行をリクエストする。
- MCPサーバはリクエスト内容に応じてツールから天気取得APIを呼び出す。
- MCPサーバはツールの実行結果のレスポンスをMCPクライアントへ返す。
{ "jsonrpc": "2.0", "id": 3, "result": { "content": [ { "type": "text", "text": "This is the weather forecast for …" <…> - MCPクライアントはレスポンスの内容をLLMに送る。
- LLMはレスポンスの内容を踏まえてユーザへの最終的な応答メッセージを生成し、MCPクライアントに送る。
- AIアプリに最終的な応答が表示される。
{
"method": "tools/call",
"params": {
"name": "get_forecast",
"arguments": {
"latitude": xxx,
"longitude": yyy,
}
},
"jsonrpc": "2.0",
"id": 3
このように、AIがタスクを遂行するうえで、どのMCPサーバのどの機能を使うべきかを自律的に判断し、活用できるのがMCPの特徴です。
MCPにおける認証/認可
MCPの利便性が向上する一方、MCPサーバの利用に対して認証/認可をどのように実装するかは、セキュリティの観点からとても重要です。
Authorization - Model Context Protocol
MCPが提供しているこのドキュメントには、Authorizationに関する仕様が書かれています。この仕様は標準的な認可プロトコル「OAuth2.1」をベースに作られており、これを満たすようにMCPサーバ・MCPクライアントを実装することでセキュアなMCPシステムを構築できます。
OAuth2.1は「OAuth2.0」をベースに周辺仕様を取り込んでセキュリティを強化したプロトコルです。OAuth2.0の概要については、こちらの記事を参照してください。
MCPにおけるAuthorization仕様は2025年3月26日に追加されたばかりで、依然として多くの課題を抱えており、改善に向けて議論がなされています。
ここでは、執筆時点での最新版である2025年6月18日版を使って、MCPのAuthorization仕様のうち中心となる項目である「Authorization Flow」について読み解いていきます。
図5はOAuth2.1のAuthorization Codeフローを基に作られた、MCPの認証/認可フローの一例です。このフローについて順を追って説明していきます。
図5：MCPの認証/認可フロー例
- まず、トークン無しでMCPサーバに対しMCPリクエストを発行する。
このときMCPサーバは「401 Unauthorized」を返すが、RFC9728に基づいてWWW-Authenticateヘッダを使用し、リソースメタデータ(そのデータ自身についての付加的なデータ)のURLをMCPクライアントに通知する。このリソースメタデータには少なくとも1つの認可サーバのフィールドが含まれる。 - MCPクライアントは取得したURLからリソースメタデータの取得をリクエストし、取得したメタデータから使用する認可サーバを決定する。
- MCPクライアントは認可サーバのメタデータを取得する。
- 動的クライアント登録(Dynamic Client Registration)を使用する場合はMCPサーバを利用するためのクライアント登録処理が走り、MCPクライアントは認可サーバからクレデンシャル情報を入手する。
- PKCEに使用するパラメータ(“code_challenge”および”code_verifier”)を作成する。また、RFC8707(OAuth2.0におけるクライアントがアクセス要求する保護リソースを認可サーバに明示的に通知するための仕様)に基づいて以降のリクエストにはresourceパラメータを付与する(PKCEの概要についてはこちらの記事を参照)。
- ブラウザから認可URLにアクセスし、ユーザ認証/認可を実行する。
認可が完了すると、MCPクライアントはアクセストークンの発行に必要な認可コードを取得する。 - 取得した認可コードを用いてアクセストークンの発行をリクエストする。
- MCPクライアントは発行されたアクセストークンでMCPサーバの機能を利用できる。アクセストークンには有効期限があり、トークンの期限内であればユーザは再度認証する必要なくMCPサーバを利用できる。また、アクセストークンに特定のスコープを設定することで、ユーザがアクセスできるリソースを制限できる。
このような認証/認可フローを適用させることで第三者によるMCPサーバ経由でのリソースアクセスを防ぐことができ、セキュアなMCPシステムを構築することができます。
おわりに
今回は、昨今のAI進化を支える技術であるMCPの概要と、MCPにおける認証/認可について解説しました。AIの利便性を向上させる技術として注目されているMCPですが、セキュリティリスクへの対処は必要不可欠です。MCPにおけるAuthorization仕様も登場してからまだ日が浅く、MCPの利用者は今後の認可仕様の動向に注目する必要があります。
次回以降は、MCPの認可サーバにKeycloakを用いた実装をハンズオン形式で解説していきます。
