3行まとめ
非秘密の構造化入力だけをMCPクライアント内で扱います。
credentialや支払いなどは外部URLへ分離します。
誰が何を許可したかを人間が確認できる形にします。
便利さより先に、入力の種類と見せてよい範囲を決めます。
- MCP Elicitationは、MCPサーバーが必要な追加情報をユーザーへ求めるための仕組みです。AIに自由質問させる機能ではなく、クライアントが表示、拒否、キャンセル、検証を担う入力要求として扱います。
- form modeは非秘密の構造化入力、URL modeはcredentialや支払い情報などMCPクライアントを通してはいけない外部操作に使い分けます。パスワード、APIキー、access token、支払い情報をformで集めてはいけません。
- MCP authorizationはMCPクライアントとMCPサーバーの認可、第三者OAuthは外部APIの認可です。Elicitationを導入する前に、この2つと人間承認UIを別々に設計してください。
この記事でわかること
ElicitationはUIだけでなく、認可と監査ログまで含めて設計します。
この記事では、MCP Elicitationを実務のAIエージェントに入れるときの判断軸を整理します。確認日は2026年6月3日です。本文の技術的な根拠は、MCP公式仕様の2025-11-25版、client concepts、authorization、security best practices、公式GitHubに限定しています。
指定Xアカウントの直近72時間投稿も需要シグナルとして確認を試みましたが、通常のWeb表示と公開検索では安定して本文を確認できませんでした。そのため、Xは事実確認の根拠には使いません。今回の題材は、既に公開済みの<a href="https://ai-dev.blog.mo-gmo.com/mcp-tools-resources-prompts-permission-design/">MCPとは何か</a>で扱ったTools、Resources、Promptsの次に、実務で迷いやすい「ユーザーに追加情報を求める境界」を扱うものです。
Elicitationで判断する4つの境界
最初に決めるべきことは、Elicitationを使うかどうかではありません。扱う情報を次の4つに分けることです。
| 判断対象 | 主な問い | 初期方針 |
|---|---|---|
| form mode | MCPクライアント内で表示してよい非秘密情報か | 名前、設定値、検索条件、承認理由などに限定する |
| URL mode | クライアントやLLMに中身を見せてはいけない操作か | credential、支払い、外部OAuthなどを外部URLへ逃がす |
| MCP authorization | MCPサーバーへ誰としてアクセスするか | HTTP transportでは仕様に沿った認可とユーザー識別を使う |
| 人間承認 | 実行前に人間が何を確認するか | サーバー名、要求理由、入力項目、ドメイン、取り消し方法を出す |
この記事で扱わないこと
この記事はElicitationの概念整理と安全設計が目的です。特定クライアントでのUI実装、OAuth provider別の設定、実在サービスへcredentialを保存する手順、攻撃手順の再現は扱いません。実装に進む場合は、対象クライアントがElicitationをサポートしているか、対象MCPサーバーがどの仕様版に沿っているかを必ず確認してください。
前提知識: Elicitationはサーバーからユーザーへの入力要求
- 1Server
処理に必要な追加情報を要求します。
- 2Client
要求元、理由、入力項目をユーザーに表示します。
- 3User
accept、decline、cancelを選びます。
- 4Server
結果に応じて処理を続行または停止します。
LLMに自由質問させるのではなく、プロトコル上の入力要求として扱います。
MCPでは、ユーザーが直接触るアプリケーションをhost、特定のMCPサーバーと通信するプロトコル上の部品をclient、ツールやリソースを提供する側をserverとして分けて考えます。Elicitationは、このclientを通じてserverがユーザーに追加情報を求める仕組みです。
たとえば旅行予約のMCPサーバーが、座席の希望、部屋タイプ、緊急連絡先、最終確認をユーザーに聞きたい場合があります。このとき、サーバーが勝手にLLMへ質問文を投げるのではなく、クライアントが「どのサーバーが、なぜ、何を求めているか」を表示し、ユーザーが入力、拒否、キャンセルできる形にするのがElicitationの役割です。
ToolsやResourcesとの違い
Toolsはサーバー側の操作をAIやクライアントから呼び出すための入口です。Resourcesはサーバー側のデータや文脈を読むための入口です。Promptsは定型の指示やテンプレートを提供します。
Elicitationは、そのどれとも違います。サーバー処理の途中で、ユーザーの追加判断や入力が必要になったときの戻り道です。ここを曖昧にすると、AIエージェントが「不足情報を自分で推測する」「秘密情報をチャット欄に書かせる」「外部サービスのログインをクライアント内で処理しようとする」といった事故につながります。
2025-11-25仕様でURL modeが入った意味
MCP仕様2025-11-25版では、Elicitationがform modeとURL modeに分かれています。form modeは、MCPクライアント内で構造化された入力を集めるためのものです。一方、URL modeは、MCPクライアントを通してはいけない外部操作のために、ユーザーを外部URLへ案内するためのものです。
ここで重要なのは、URL modeが「便利なリンク表示」ではないことです。公式仕様では、URL modeは2025-11-25で導入された新しい機能で、将来の仕様改訂で変わり得るとされています。採用する場合は、仕様版、クライアント対応、表示UI、監査ログ、リトライ方法まで一緒に決める必要があります。
結果: 最初に決めるのは、扱う情報の種類
formかURLかは、UI都合ではなく情報の安全分類で決めます。
MCP Elicitationの導入可否は、次の順で判断するのが安全です。
- その情報は、LLMやMCPクライアントに見えてよいか。
- その情報は、MCPサーバーが保存してよいか。
- その入力は、ユーザーが拒否またはキャンセルできるか。
- その操作は、MCP authorizationで扱う範囲か、第三者OAuthで扱う範囲か。
- その完了状態は、session IDだけではなく認証済みユーザーに紐づけられているか。
form modeでよい入力
根拠
form modeに向いているのは、MCPクライアント内に表示しても問題のない、短く、構造化できる入力です。たとえば次のようなものです。
- GitHub Issueを作る前のラベル候補
- 社内ナレッジ検索の部署名や期間
- レポート生成前の出力形式
- 予約や申請の最終確認
- 非秘密の連絡先やプロフィール情報
- 実行前レビューで人間が残す承認理由
公式仕様では、form modeのrequestedSchemaはJSON Schemaの制限されたサブセットとして扱われます。フラットなobjectとprimitiveなpropertiesに限定されるため、複雑なネスト構造や、認証フローそのものをformで表現しようとしないほうがよいです。
URL modeへ逃がす入力
注意点
form modeで扱ってはいけないものは明確です。パスワード、APIキー、access token、支払い情報など、アクセス権や取引承認につながる秘密情報はform modeで求めてはいけません。この種の入力は、URL modeや正式なOAuthフローで扱います。
たとえばGitHub、Google、Stripe、X APIのような外部サービス連携で、ユーザーの認可が必要な場合を考えます。MCPサーバーが外部サービスのOAuth clientとして認可URLを作り、URL modeでユーザーを外部の安全なページへ案内し、認可完了後にMCPサーバー側でtokenを安全に保存する。この流れなら、credentialはMCPクライアントやLLMを通りません。
もちろん、URL modeにすれば自動的に安全になるわけではありません。URLを自動で開かない、完全なURLとドメインを人間が確認できる、疑わしいURIへ警告を出す、完了しない場合にキャンセルや再試行ができる、というクライアント側の設計が必要です。
OAuthと人間承認を混ぜない
確認項目
OAuthは、誰がどのresourceにアクセスできるかを認可する仕組みです。人間承認は、その認可済みの権限を使って、この場で何を実行してよいかを確認する仕組みです。
この2つを混ぜると、認可済みだから自動実行してよい、という危ない設計になりやすいです。たとえば「Google Driveへの読み取り権限を認可済み」と「このフォルダ内の全ファイルをAIに読ませてよい」は別の判断です。MCP Elicitationは、この後者の確認に使える場面があります。
form modeを使うなら、schemaより先に聞いてよい情報を決める
表示名、設定値、承認理由などに限定します。
フラットなobjectとprimitiveなpropertiesで扱います。
declineやcancelでも安全に停止できるようにします。
入力値の保存目的と監査ログの範囲を分けます。
入力欄を作れることと、その情報を聞いてよいことは別です。
form modeのrequestedSchemaは入力欄を作るための仕様であり、セキュリティ境界そのものではありません。schemaにformat: "email"を書くとメールアドレスらしい形式は検証できますが、そのメールアドレスを集めてよいか、保存してよいか、AIに渡してよいかまでは決まりません。
requestedSchemaは入力制約であって権限ではない
評価基準
安全に使うなら、まず情報の分類を決めます。
| 入力例 | form mode可否 | 理由 |
|---|---|---|
| 表示名 | 使える | 一般的なプロフィール情報として扱える。ただし公開範囲は説明する |
| メールアドレス | 条件付きで使える | 連絡や予約に必要な場合だけ。保存目的を表示する |
| APIキー | 使わない | 外部サービスへのアクセス権を与えるcredential |
| OAuth access token | 使わない | tokenをクライアントやLLMに渡す設計にしてはいけない |
| 支払いカード情報 | 使わない | URL modeや正規の決済ページへ分離する |
| 実行前の承認理由 | 使える | 監査ログに残す非秘密の説明として扱える |
schemaは、この分類の後に書きます。先にschemaを書いてしまうと、「画面に出せるなら聞いてよい」という発想になりがちです。
accept、decline、cancelを前提にする
Elicitationでは、ユーザーが要求を受け入れるだけでなく、拒否やキャンセルもできる前提で設計します。これは地味ですが、AIエージェント運用では重要です。
拒否された場合にAIが推測で埋めると、Elicitationの意味が消えます。キャンセルされた場合に同じ要求を何度も出すと、ユーザー確認が形だけになります。実務では、次の3つを先に決めておくと扱いやすくなります。
- acceptなら、入力内容、入力者、対象サーバー、対象操作を監査ログに残す
- declineなら、任意の理由を残し、代替手順や処理停止を返す
- cancelなら、その操作を未完了として扱い、自動再実行しない
悪い例とよい例
悪い例は、AIにそのまま聞かせる設計です。
ユーザーにGitHub tokenを入力してもらい、以後のAPI操作に使ってください。この形では、credentialがチャット、LLM、ログ、MCPクライアントのどこを通るか見えません。form modeでも使ってはいけない入力です。
よい例は、非秘密の選択肢に限定する設計です。
{
"mode": "form",
"message": "Issue作成前に公開範囲と優先度を確認してください。",
"requestedSchema": {
"type": "object",
"properties": {
"visibility": {
"type": "string",
"enum": ["internal", "public-draft"]
},
"priority": {
"type": "string",
"enum": ["low", "medium", "high"]
},
"approvalReason": {
"type": "string",
"maxLength": 200
}
},
"required": ["visibility", "priority"]
}
}この例では、入力は意思決定と監査に必要な非秘密情報です。外部APIのcredentialは扱っていません。
URL modeを使うなら、クライアントが中身を見ない設計にする
- 1要求
サーバーが外部URLと目的を提示します。
- 2確認
クライアントが完全なURLとドメインを表示します。
- 3同意
ユーザーの明示的な操作でURLを開きます。
- 4完了
サーバーが認証済みユーザーに状態を紐づけます。
URL modeは、MCPクライアントやLLMに秘密情報を通さないための分離です。
URL modeは、外部ページへ誘導するための仕組みです。ここでの原則は、MCPクライアントやLLMが外部ページの内容やユーザー入力を見ないことです。
公式仕様では、クライアントがURLを自動で開いたり、事前にメタデータを取得したりすることは禁じられています。ユーザーに完全なURLを表示し、明示的な同意を得てから、安全な方法で開く必要があります。
自動オープンしない
AIエージェントが「認可が必要です」と判断した瞬間にブラウザを開く設計は避けます。ユーザーには、どのMCPサーバーが、どのURLを、何のために開こうとしているかを確認する時間が必要です。
特に企業導入では、URL表示と同意ログを省略しないほうがよいです。後から「誰がどの外部サービスへの認可を始めたのか」を追えないと、権限事故の調査が難しくなります。
ドメイン表示とphishing対策を入れる
確認項目
URL modeでは、ドメインを人間が確認できる表示が必要です。サブドメインの紛らわしさ、Punycode、リダイレクト先、短縮URLなどは、AIエージェント側ではなくUIとポリシー側で扱います。
記事として強く勧めたいのは、URL modeを導入する前に許可ドメインの一覧を決めることです。たとえばGitHub連携なら、認可開始URL、callback先、MCPサーバーの自社ドメインを明示します。ユーザーに表示する文面も「GitHubへログインしてください」では足りません。「このMCPサーバーがGitHub OAuthを開始します。開くURLはこのドメインです」まで出したほうが安全です。
完了通知とリトライを設計する
URL modeでは、外部ページで認可や入力が終わったあと、MCPサーバー側で完了状態を持ちます。仕様には、URL modeのElicitation完了通知や、URL modeが必要な場合のエラーも定義されています。
実務で大事なのは、完了しなかった場合です。ユーザーが外部ページを閉じた、OAuthが失敗した、callbackが届かなかった、途中でキャンセルした。これらをAIに推測で続行させないでください。再試行、キャンセル、手動確認のUIを用意し、元の操作は未完了として扱うのが安全です。
MCP authorizationと第三者OAuthを分ける
認可が通っていても、具体的な操作には別の承認が必要です。
MCP authorizationは、MCPクライアントが制限付きMCPサーバーにアクセスするための認可です。HTTP-based transportのMCP実装では、OAuth 2.1、Protected Resource Metadata、Authorization Server Metadataなどの仕様に沿った発見と認可が関係します。
一方、第三者OAuthは、MCPサーバーがGitHub、Google、Stripe、Xなどの外部APIにアクセスするための認可です。ElicitationのURL modeは、この第三者OAuthを開始する導線として使われることがあります。
MCPサーバーへの認可
MCPサーバー自体が制限付きの社内サーバーなら、まずMCPクライアントがそのサーバーへ誰としてアクセスしているかを決めます。ここが曖昧なままElicitationを使うと、サーバーは「誰の入力か」「誰の権限で操作するか」を判断できません。
仕様では、remote MCP serverでユーザー識別が必要な場合、可能な限りMCP authorizationで取得したcredentialからユーザー識別を導くことが求められています。単に「ユーザーがフォームに自分のメールアドレスを書いた」だけでは、本人確認にはなりません。
外部APIへの認可
外部APIへのOAuthでは、MCPサーバーが第三者サービスのOAuth clientとして振る舞うことがあります。この場合、URL modeで外部認可URLを提示し、ユーザーは第三者サービスの画面で認可します。認可後、MCPサーバーはtokenをユーザーIDに紐づけて保存し、以後のAPIアクセスに使います。
ここでtokenをMCPクライアントやLLMに返してはいけません。tokenを使う処理はMCPサーバー側に閉じ、toolの入力には「どの操作をするか」という非秘密の指示だけを渡します。
状態をsession IDだけに結びつけない
失敗条件
Elicitationの状態管理では、session IDだけに頼らないことが重要です。session IDは接続や会話の都合で変わることがあり、ユーザー本人の識別にはなりません。
MCPサーバーは、ElicitationのelicitationId、認可フローのstate、外部OAuthのcallback、保存したcredentialを、認証済みユーザーに結びつける必要があります。session IDだけで結びつけると、別ユーザーの完了状態を誤って使う、古い認可を再利用する、監査ログから本人を追えない、といった事故につながります。
失敗点: Elicitationで起きやすい事故
APIキーやtokenをformで集めてしまう。
外部URLを自動で開き、ドメイン確認を省く。
declineやcancelの後にAIが値を補って進める。
session IDだけで完了状態を扱う。
UIだけではなく、保存先、認可、失敗時の停止条件まで確認します。
Elicitationの失敗は、実装ミスよりも境界の混同から起きます。よくある事故を先に潰しておくと、MCPサーバーの設計レビューがかなり楽になります。
秘密情報をformで集める
一番危ないのは、APIキーやaccess tokenをform modeで集める設計です。これはMCP仕様の意図に反します。非秘密の設定値とcredentialは同じ入力フォームに置かないでください。
URLをLLMやクライアントに読ませる
URL modeは、外部ページの内容をLLMに読ませるためのものではありません。むしろ逆で、MCPクライアントやLLMを通してはいけない内容を外に分離するためのものです。
たとえば「このURLのログインページを開いて、ユーザーが入力した内容を見て、次の手順を進める」という設計は避けます。ユーザー入力は外部ページとMCPサーバー側の安全な処理に閉じます。
ユーザー確認なしに実行する
Elicitationを使っていても、ユーザーが何に同意したかが表示されなければ安全とは言えません。承認UIには、最低でも次の情報を出します。
- 要求しているMCPサーバー名
- 入力や認可が必要な理由
- 実行予定の操作
- formなら入力項目と保存目的
- URLなら完全なURLとドメイン
- accept、decline、cancelの選択肢
サーバー名とドメインを隠す
「AIが必要だと言っています」という表示では足りません。どのMCPサーバーが要求しているのか、URL modeならどのドメインを開くのかを明示します。AIエージェントは複数のMCPサーバーや外部ツールを扱えるため、要求元を隠すとユーザーは判断できません。
実務で使うなら
- 1
read-only MCPで非秘密の入力確認から始めます。
- 2
form modeのschemaと拒否時の動作を決めます。
- 3
監査ログに残す項目と残さない項目を分けます。
- 4
URL modeや第三者OAuthは別レビューで追加します。
いきなり書き込み権限や外部OAuthへ進まず、確認UIを先に固めます。
最初からURL mode、第三者OAuth、書き込みtool、人間承認、監査ログを全部入れようとすると、設計が大きくなりすぎます。最初はread-only MCPと小さなform modeから始めるのが現実的です。
read-only MCPから始める
最初のElicitation用途は、外部操作ではなく検索条件や確認理由の入力に限定します。たとえば社内ドキュメント検索MCPで、部署、期間、公開範囲をform modeで確認する。GitHub Issueを読むだけのMCPで、対象リポジトリやラベル候補を確認する。この程度なら、credentialを扱わずにUIと監査ログの設計を試せます。
そのあとで、書き込みtoolを追加するか、URL modeで第三者OAuthを始めるかを判断します。MCPの基本設計に不安がある場合は、先に<a href="https://ai-dev.blog.mo-gmo.com/mcp-tools-resources-prompts-permission-design/">MCPとは何か</a>でTools、Resources、Promptsと権限境界を確認しておくと、Elicitationの位置づけが見えやすくなります。
監査ログに残すもの
Elicitationを実務で使うなら、ログには入力値を全部残せばよいわけではありません。むしろ、個人情報や秘密情報をログに残しすぎると別のリスクになります。
ログに残す候補は次の通りです。
- request IDとelicitation ID
- MCPサーバー名
- 対象toolまたは処理名
- form modeかURL modeか
- ユーザーのaction、accept、decline、cancel
- 入力schemaのバージョン
- URL modeなら表示したドメイン
- 外部OAuthなら認可完了の有無
- 実行結果と取り消し方法
入力値そのものは、保存目的がある場合だけ、最小限に絞ります。credentialやtokenはログに残しません。
チームルールに入れる文言
AGENTS.mdやMCP運用ルールに入れるなら、次のような文言が使えます。
MCP Elicitationのform modeで、password、API key、access token、payment credentialを要求してはいけない。
外部認可やcredential入力が必要な場合はURL modeまたは正規のOAuth flowを使い、完全なURL、要求元サーバー、拒否/キャンセル手段をユーザーに表示する。
Elicitation完了状態はsession IDだけに紐づけず、認証済みユーザーIDと監査ログに結びつける。チーム向けのルール整備そのものは、<a href="https://ai-dev.blog.mo-gmo.com/agents-md-change-review-instruction-drift-permission-conflict-tests/">AGENTS.mdを変更レビューに入れる前に</a>も合わせて読むと、指示のdriftや権限競合を避けやすくなります。
セキュリティ・コスト注意
MCP Elicitationは入力UIだけでなく、運用ルールごと設計します。
Elicitationはモデル料金よりも、権限事故とログ設計のほうが先に問題になります。特にMCPサーバーが外部API、社内データ、個人情報に触れる場合、入力欄の設計だけでなく、保存、監査、削除、再認可を含めて考える必要があります。
コストよりも権限事故のほうが先に問題になる
Elicitationそのものは、LLM呼び出し回数を大きく増やす機能ではありません。むしろ、ユーザー入力を待つために処理が止まることのほうが運用上の影響として見えやすいです。
ただし、Elicitationで外部API操作を承認させる場合、API課金、rate limit、書き込み操作の取り消し、サポート対応まで影響します。<a href="https://ai-dev.blog.mo-gmo.com/x-api-mcp-agent-permissions-cost-human-approval/">X API MCPをAIエージェントに渡す前に決めること</a>で扱ったように、投稿権限やAPIコストが絡むMCPでは、人間承認と権限範囲を先に固定したほうが安全です。
個人情報とcredentialの扱いを分ける
個人情報とcredentialは、どちらも慎重に扱う必要がありますが、同じカテゴリではありません。メールアドレスや名前はform modeで扱える場合があります。ただし、目的、保存期間、ログへの残し方、共有範囲を表示する必要があります。
credentialは別です。credentialはアクセス権や取引承認そのものにつながります。form modeで集めない、ログに残さない、LLMに見せない、MCPクライアントを通さない。ここは強いルールとして固定してください。
仕様変更に備える
URL modeは2025-11-25仕様で導入された新機能です。導入時点では、対象クライアントが対応しているか、仕様がどの版に基づいているか、サーバーとクライアントで期待する動作が一致しているかを確認します。
また、MCP authorizationも仕様更新の影響を受けます。仕様更新時の確認観点は、MCPカテゴリの更新記事や<a href="https://ai-dev.blog.mo-gmo.com/category/mcp/">MCPカテゴリ</a>で追うのがよいです。更新通知をまとめて追いたい場合は、<a href="https://ai-dev.blog.mo-gmo.com/newsletter/">ニュースレター</a>でも新しい検証記事を案内しています。
FAQ
構造化された入力要求として扱います。
formではなくURL modeや正規の認可フローに分けます。
明示的同意とドメイン確認が必要です。
無理に同じ体験を再現せず別フローを用意します。
迷ったら、秘密情報をMCPクライアントやLLMに通さない側へ倒します。
Elicitationはpromptで質問させるのと何が違いますか
promptで質問させる場合、LLMが質問文、入力欄、拒否時の処理、ログの扱いを曖昧に抱え込みやすくなります。Elicitationは、MCPサーバーが必要な情報を構造化して要求し、クライアントがユーザーに提示し、accept、decline、cancelを扱うためのプロトコル上の仕組みです。
OAuthログインはform modeでできますか
できると考えないほうが安全です。OAuthのcredentialやaccess tokenをform modeで集める設計は避けます。外部サービスのOAuthが必要なら、URL modeや正規の認可フローを使い、tokenはMCPサーバー側で安全に保存します。
URL modeなら安全ですか
URL modeは、MCPクライアントやLLMに見せてはいけない外部操作を分離するための仕組みです。ただし、完全なURL表示、明示的同意、自動オープン禁止、ドメイン確認、phishing対策、状態管理がなければ安全とは言えません。
MCPクライアントがElicitation非対応ならどうしますか
無理に同じ体験を再現しないほうがよいです。対応していないクライアントでは、サーバー側がElicitation前提の処理を返しても、ユーザーに安全な確認UIを出せない可能性があります。その場合は、処理を停止する、外部管理画面へ誘導する、またはElicitationを使わない別フローを用意します。
prompt injection対策とどう関係しますか
Elicitationはprompt injection対策そのものではありません。ただし、外部Docs、Issue、MCP toolの出力を読ませる前に「何を信じるか」「何を実行しないか」を決める流れとは強く関係します。prompt injectionの観点は、<a href="https://ai-dev.blog.mo-gmo.com/ai-coding-agent-prompt-injection-issues-docs-mcp-guardrails/">AIコーディングエージェントのprompt injection対策</a>で整理しています。
関連資料と導線
Tools、Resources、Promptsの境界を確認します。
外部API操作の人間承認を決めます。
AGENTS.mdや運用ルールに禁止事項を入れます。
Elicitationだけで閉じず、MCP全体の権限設計として扱います。
MCP Elicitationは、MCPサーバーを作る人だけでなく、AIエージェントをチームに入れる人にも関係します。特に、社内データ、外部API、書き込みtoolを扱う場合は、Elicitation、MCP authorization、人間承認、監査ログを同じ設計レビューの中で見るべきです。
MCP Server Starter KitやAIコーディング導入時の権限設計レビューが必要な場合は、<a href="https://ai-dev.blog.mo-gmo.com/contact/">お問い合わせ</a>から相談できます。この記事は広告ではなく、導入前レビューで最初に見るチェックリストとして使えるように書いています。
次に読むなら
参照した主な情報源
- MCP Elicitation specification 2025-11-25: https://modelcontextprotocol.io/specification/2025-11-25/client/elicitation
- MCP client concepts: https://modelcontextprotocol.io/docs/learn/client-concepts
- MCP Authorization specification 2025-11-25: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
- MCP Security Best Practices: https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
- Model Context Protocol official GitHub: https://github.com/modelcontextprotocol/modelcontextprotocol
更新履歴
- 2026-06-03
MCP仕様2025-11-25と公式ドキュメントを確認しました。
- 注意
URL modeは将来仕様が変わる可能性があります。
導入時は最新仕様と対象クライアントの対応状況を確認してください。
- 2026-06-03: 初版。MCP仕様2025-11-25のElicitation、Authorization、client concepts、Security Best Practices、公式GitHubを確認しました。指定Xアカウントの直近72時間投稿本文は通常Web表示と公開検索で安定確認できなかったため、需要シグナルとしても採用せず、本文の事実確認は公式一次情報に限定しました。URL modeは2025-11-25仕様で導入された機能であり、将来仕様が変わる可能性があるため、導入時は最新仕様と対象クライアントの対応状況を確認してください。