MCP 2026.05.31 更新: 2026.06.03

MCPとは何か：Tools・Resources・Promptsと権限設計を開発者向けに整理する

追記: 2026年6月4日の最新情報

このテーマをもう少し広げて見るなら、MCP ElicitationをAIエージェントに入れる前に：form・URL・OAuth・人間承認の分け方と X API MCPをAIエージェントに渡す前に決めること：投稿権限・コスト・人間承認も合わせて確認してください。Tools、Resources、Promptsの次に、ユーザー入力と人間承認をMCPでどう扱うかを確認できます。

2026年6月4日にMCP公式仕様を再確認しました。latestはVersion 2025-11-25で、この記事で扱うTools、Resources、PromptsはServer Features側の入口です。実務ではこれに加えて、Client FeaturesのRoots、Sampling、Elicitationも分けて見てください。

Toolsはモデルが呼び出し得る操作なので、副作用、承認、監査ログを先に決めます。
Resourcesは文脈データなので、URI、scope、データ分類、公開範囲を先に決めます。
Elicitationはユーザー入力を扱うclient featureです。PromptやToolの説明文だけで人間承認を代替しないようにします。

人間入力やOAuthを含む設計に進む場合は、MCP公式のElicitation、Authorizationと、関連記事のMCP ElicitationをAIエージェントに入れる前にを合わせて確認してください。

3行まとめ

VisualMCP導入前に分ける4つの境界Tools、Resources、Promptsを同じ入口にせず、誰が選び、何が動くかで分けます。

Tools

モデルが呼び出し得る操作。read-only、write、high-risk writeを分けます。

Resources

モデルへ渡す文脈データ。URI、scope、データ分類、監査を先に決めます。

Prompts

ユーザーが選ぶ作業テンプレート。作業品質をそろえても、権限境界は代替しません。

Permission boundary

Host、Client、Server、人間承認、allowlist、ログで止める場所を決めます。

最初はread-only Tool、限定Resource、明示的に選ぶPromptから始めると、影響範囲を説明しやすくなります。

MCPは、LLMアプリケーションと外部データ、外部ツールをつなぐためのプロトコルです。実務では、MCPそのものより先に、Host、Client、Serverの責任分界を決めます。
Toolsはモデルが呼び出し得る操作、Resourcesは文脈として読ませるデータ、Promptsはユーザーが選ぶ作業テンプレートです。3つを同じ「AIに渡す機能」としてまとめると、権限設計が崩れます。
最初の導入は、read-only Tool、限定Resource、明示的に選べるPromptから始めます。write系Tool、HTTP認可、本番データ、外部API連携は、人間承認、scope、allowlist、監査ログを決めてから広げます。

この記事の事実確認は、2026年6月1日 JST時点のMCP公式仕様、公式TypeScript SDK repository、npm公開メタデータをもとにしています。Xの投稿は需要の参考として確認を試みましたが、追跡対象アカウントの直近72時間投稿をこの実行環境から確実に取得できなかったため、本文の事実根拠には使っていません。

この記事でわかること

Visual実装前に決める設計判断MCP Serverを作る前に、権限と責務を棚卸しします。

責任分界

Host、Client、Serverのどこで接続許可、承認、ログを扱うかを整理します。

primitive選択

社内API、ドキュメント、DB schema、定型作業をTools、Resources、Promptsへ分けます。

副作用の扱い

read-only、dry-run、write、high-risk writeで承認条件を変えます。

認可の違い

stdioのローカル権限とHTTP-based transportのOAuth、scope、audienceを混同しないようにします。

コードを書く前に、拒否できること、記録できること、戻せることまで決めておきます。

MCPのHost、Client、Serverの役割
Tools、Resources、Promptsの違い
何をToolにし、何をResourceにし、何をPromptに寄せるべきか
read-only Toolとwrite Toolを分ける判断基準
Resource公開範囲を決める時のデータ分類
Promptを権限管理の代わりにしない理由
stdioのローカルMCPサーバーとHTTP-based transportの認可設計の違い
導入前に決めるべきallowlist、scope、人間承認、監査ログ

すでにTypeScriptで小さく実装したい段階なら、公開済みのTypeScriptでMCPサーバーを作る：Tools・Resources・Promptsの最小構成が近いです。この記事ではコードを書く前に、何をどのprimitiveへ置くかを決めるところに絞ります。

前提知識

VisualMCPの基本構成Host、Client、Serverと3つのprimitiveを、権限設計の視点で見ます。

Host

LLMアプリケーション本体。接続許可、表示、承認、ポリシー、ログを扱います。

Client

Host内でServerごとに接続を持つ単位。Serverごとの分離とsessionを見ます。

Server

Resources、Prompts、Toolsを提供する外部機能。公開データ、操作、認可、ログを設計します。

Tools / Resources / Prompts

操作、文脈データ、作業テンプレート。名前ではなく制御主体とリスクで分けます。

MCP Serverを作るだけでは安全にならないため、Host、Client、Serverのどこで止めるかを設計します。

MCPはModel Context Protocolの略です。公式仕様では、LLMアプリケーションが外部データソースやツールと統合するためのオープンプロトコルとして説明されています。通信にはJSON-RPC 2.0が使われ、基本構成はHost、Client、Serverに分かれます。

役割	実務での見方	権限設計で見ること
Host	LLMアプリケーション本体。AIエディタ、チャットUI、エージェント実行環境など	接続許可、ユーザー同意、表示UI、承認、ポリシー
Client	Host内でServerごとに接続を持つ通信単位	Serverごとの分離、capability negotiation、session
Server	Resources、Prompts、Toolsを提供する外部機能	公開するデータ、実行する操作、認可、ログ

MCPで重要なのは、Serverが何でも見られるわけではないことです。Architecture仕様では、各Clientは特定Serverと1対1で接続し、Hostがセキュリティ境界やユーザー承認を扱う構造になっています。つまり、MCP Serverを作れば安全になるのではなく、Host、Client、Serverのどこで止めるかを設計する必要があります。

MCP Serverが提供できる代表的な機能は3つです。

primitive	何をするものか	制御の中心	実務例
Tools	モデルが呼び出し得る関数	モデルが選び、Hostが承認する	Issue検索、DB読み取り、PR作成、テスト実行
Resources	モデルへ渡す文脈データ	アプリやユーザーが選ぶ	ファイル、DB schema、社内ドキュメント、ログ
Prompts	ユーザーが選ぶ作業テンプレート	ユーザーが明示的に選ぶ	コードレビュー依頼、障害調査、リリース判定

この3つは、名前の違いではなく、権限境界の違いです。MCP導入の失敗は、かなりの割合でここを混ぜた時に起きます。

結果

VisualMCP導入前の判断結果仕様とSDKの確認を踏まえ、実装前に固定する判断を先に置きます。

3要素を分ける

Tools、Resources、Promptsは、制御主体と失敗時の影響が違います。

read-onlyから始める

モデルが呼び出し得る操作は、副作用を小さくして検証します。

Resourceは分類する

読み取りだけでも、機密情報や個人情報が文脈に入ると影響が残ります。

認可を混同しない

HTTP-based transportの認可と、stdioのローカル権限は分けて見ます。

確認したProtocol Revisionやnpm packageの詳細は更新履歴に残し、本文では導入判断を中心に扱います。

2026年6月1日時点で、MCP公式仕様のlatestは2025-11-25でした。TypeScript SDK repositoryとnpm公開メタデータも確認し、この記事では次の判断を置きます。

判断	理由
MCP導入前に3要素を分ける	Tools、Resources、Promptsは制御主体とリスクが違うため
read-onlyから始める	Toolsはモデルが呼び出し得るため、副作用を小さくして検証する必要があるため
Resourceはデータ分類から決める	読み取りだけでも、機密情報や個人情報が文脈に入ると影響が大きいため
Promptを権限管理に使わない	Promptは作業テンプレートであり、HostやServerの権限境界を代替しないため
HTTP認可とstdioを分ける	公式Authorization仕様はHTTP-based transportを対象にし、stdioは別のcredential扱いになるため
v1系とv2 alphaを混同しない	TypeScript SDK repositoryのREADMEではmain branchがv2 pre-alphaで、v1.xが本番利用向けとして案内されているため

ここでの結論は、MCPを「接続規格」として見るだけでは足りない、ということです。MCP Serverを入れる前に、どの操作をAIが選べるようにするか、どのデータを文脈として渡すか、どの作業テンプレートをユーザーに選ばせるかを分けてください。

MCPは何を標準化するのか

VisualHostが境界を管理する接続構造MCPは接続とやり取りの形をそろえますが、権限設計そのものを自動化するわけではありません。

1Host
AIエディタ、チャットUI、エージェント実行環境が接続許可と承認を扱います。
2Client
Serverごとに1対1の接続を持ち、capability negotiationとsessionを管理します。
3Server
社内ドキュメント、GitHub、DB schema、デプロイなどの機能を提供します。
4Features
Tools、Resources、Promptsを公開し、Host側の表示、承認、ログと組み合わせます。
5Boundary
Server同士を混ぜず、責務ごとに小さく分けると事故時の影響範囲を抑えやすくなります。

Serverが何でも見られる設計にせず、Hostが接続と承認の境界を持つ前提で整理します。

MCPは、LLMアプリケーションと外部データ、外部ツールの接続方法を標準化します。たとえば、AIエディタからIssueを検索する、社内ドキュメントを文脈に入れる、コードレビュー用の定型プロンプトを選ぶ、といった操作を同じプロトコルの上で扱えるようにします。

ただし、標準化されるのは「接続とやり取りの形」です。自社の権限設計、秘密情報の扱い、監査ログ、承認UI、ネットワーク制御までMCPが自動で面倒を見てくれるわけではありません。

Hostが持つ責任

Hostは、LLMアプリケーション側の親環境です。公式Architectureでは、HostがClient接続の権限、lifecycle、security policy、consent requirement、authorization decisionを扱うと整理されています。

実務では、Hostに次の責任があります。

Host側で見ること	確認内容
接続許可	どのMCP Serverを登録できるか
表示	どのTools、Resources、Promptsがユーザーに見えるか
承認	Tool呼び出し前に何を確認させるか
ログ	誰が、いつ、どのServer、どのToolを使ったか
ポリシー	read-only、write、admin操作をどう分けるか

MCP Server側で「このToolは安全です」と説明しても、Hostがその説明をそのまま信頼して承認なしに実行する設計は危険です。Toolの説明文やannotationsは、判断材料にはなりますが、権限境界そのものではありません。

ClientはServerごとの接続単位

Clientは、Hostの中でServerごとの接続を管理します。1つのHostが複数のMCP Serverにつなぐ場合、ClientもServerごとに分かれます。

ここで大事なのは、Server同士を混ぜないことです。GitHub用Server、社内wiki用Server、DB schema用Server、デプロイ用Serverを全部1つの強い接続にまとめると、便利ですが、事故時の影響範囲も広がります。

最初は、Serverを責務ごとに小さく分けます。

Serverの責務	初期方針
社内ドキュメント検索	read-only Resourceと検索Toolに限定
GitHub Issue参照	read-only Toolから開始
PR作成	write Toolとして人間承認を必須化
DB schema参照	schemaだけをResource化し、本番データは出さない
デプロイ操作	初期導入では扱わない、またはdry-runだけ

MCPカテゴリ全体の記事はAI Dev Lab JapanのMCPカテゴリにまとめています。実装、更新確認、ブラウザ検証、各AIツールとの接続は、導入段階に応じて読み分けてください。

Tools、Resources、Promptsをどう分けるか

Visual3つのprimitiveの判断軸制御主体、副作用、レビュー観点が違うため、同じ許可単位にしないようにします。

項目	内容	見方
Tools		モデルが選び得る外部操作。inputSchema、承認、timeout、監査ログを確認します。
Resources		アプリやユーザーが選ぶ文脈データ。URI、データ分類、scope、キャッシュを確認します。
Prompts		ユーザーが明示的に選ぶ作業テンプレート。引数、指示内容、埋め込みResourceを確認します。
止め方		Toolは実行前承認、Resourceは公開範囲縮小、Promptはテンプレート停止やレビュー修正で止めます。

操作、文脈、作業テンプレートを分けると、承認と監査の設計が崩れにくくなります。

MCP導入で最初に決めるべきことは、機能名ではなく責務です。次の表を、最初の設計レビューにそのまま使えます。

判断軸	Tools	Resources	Prompts
主な用途	外部操作、API呼び出し、計算、更新	文脈データの提供	作業テンプレートの提供
制御の中心	モデルが選び得る	アプリやユーザーが文脈として選ぶ	ユーザーが明示的に選ぶ
副作用	あり得る	原則なし。ただし情報流出リスクはある	直接の外部操作ではない
代表例	`search_issues`、`create_pr`、`run_tests`	`file://repo/README.md`、`schema://billing`	`code_review`、`incident_triage`
主なレビュー観点	inputSchema、承認、timeout、監査ログ	URI、データ分類、scope、キャッシュ	引数、指示内容、埋め込みResource
失敗時の止め方	実行前承認、rate limit、rollback	公開範囲縮小、キャッシュ削除	テンプレート停止、レビュー修正

Toolsはモデルが呼び出し得る操作

Toolsは、MCP Serverが公開する関数です。公式Tools仕様では、Toolsはlanguage modelが発見して呼び出し得るものとして扱われています。つまり、Toolは「ユーザーが手で押すボタン」ではなく、「モデルが文脈から選び得る操作」として設計する必要があります。

Toolに向いているものは、外部状態の確認や操作です。

Tool候補	初期の扱い
Issue検索	read-onlyで始める
Pull Request作成	write Tool。人間承認が必要
テスト実行	ローカル影響と実行時間を制限する
DB query	最初はschemaやread-only queryに限定
Slack通知	送信前に本文と宛先を表示する
デプロイ	初期導入ではdry-runに限定

Toolsにはname、description、inputSchemaなどが含まれます。特にinputSchemaは重要です。入力が曖昧だと、モデルが意図しない引数でToolを呼びやすくなります。必須項目、enum、最大件数、対象ID、dry-runフラグ、理由欄を最初から設計してください。

Resourcesはモデルに渡す文脈データ

Resourcesは、ServerがClientへ公開する文脈データです。公式Resources仕様では、Resourcesはapplication-drivenであり、Hostアプリケーションが必要に応じて文脈に取り込む前提で説明されています。

Resourceに向いているものは、URIで識別できる読み取り対象です。

Resource候補	注意点
READMEや設計書	古い情報を混ぜない
DB schema	本番データを一緒に出さない
API仕様	tokenや内部endpointを伏せる
Issue本文	private情報や顧客名を扱う場合は範囲を分ける
ログ	個人情報、secret、IP、request bodyをそのまま出さない

Resourceは「実行しないから安全」と見られがちですが、実際には情報流出の入口になり得ます。AIに渡す文脈は、モデルの応答、ログ、共有リンク、外部Tool呼び出しの入力に流れる可能性があります。

Resource設計では、次の4つを先に決めます。

決めること	例
URI設計	`docs://runbook/payment-timeout`、`schema://orders/read-only`
公開範囲	チーム、リポジトリ、プロジェクト、環境
データ分類	public、internal、confidential、restricted
監査	readされたURI、利用者、時刻、Host

Promptsはユーザーが選ぶ作業テンプレート

Promptsは、ServerがClientへ公開するプロンプトテンプレートです。公式Prompts仕様では、Promptsはuser-controlled、つまりユーザーが明示的に選んで使うものとして説明されています。

Promptに向いているのは、作業の型です。

Prompt候補	何を固定するか
コードレビュー依頼	観点、対象差分、出力形式
障害一次調査	timeline、impact、仮説、追加ログ
リリース判定	変更点、rollback、監視項目
テスト修正依頼	失敗ログ、再現手順、禁止操作

Promptは、便利なslash commandに近い体験を作れます。ただし、Promptは権限管理ではありません。Promptに「承認を省略して実行して」と書けても、それでTool承認を抜けられる設計にしてはいけません。

Promptのレビューでは、次を見ます。

Prompt名が作業内容を正しく表しているか
必須引数が多すぎないか
埋め込みResourceが機密情報を含まないか
Tool実行を暗黙に要求していないか
出力先や共有範囲が明示されているか
社内標準手順として誰が更新するか

Toolsの権限設計は副作用から始める

VisualToolリスク分類便利さではなく、何が起きるかと扱うデータの感度から初期方針を決めます。

項目	内容	見方
read-only		Issue検索、file一覧、schema取得。初期導入で検討しやすい分類です。
read-onlyだが高感度		本番ログ検索、顧客情報参照。範囲制限、redaction、監査ログを必須にします。
dry-run		migration plan、deploy preview、メール文面生成。本番操作とは別のToolにします。
write		PR作成、Issue更新、通知送信。実行前に対象、引数、影響範囲を表示します。
high-risk write		権限変更、請求、削除、deploy。原則禁止または別承認にします。

read-onlyでも情報流出リスクは残るため、Tool名、description、inputSchema、error、logまで確認します。

Tool設計では、最初に「何が起きるか」を分類します。便利さではなく、副作用の大きさから始めるのが安全です。

分類	例	初期方針
read-only	issue検索、file一覧、schema取得	最初に許可しやすい
read-onlyだが高感度	本番ログ検索、顧客情報参照	範囲を絞り、監査ログを必須にする
dry-run	migration plan、deploy preview、メール文面生成	本番操作と分ける
write	PR作成、Issue更新、通知送信	人間承認を必須にする
high-risk write	権限変更、請求、削除、deploy	原則禁止または別承認にする

read-only Toolから始める

初回導入でおすすめするのは、read-only Toolです。たとえば、Issueの検索、CIログの取得、設定値の検査、schemaの確認、依存関係の一覧取得です。

許可してよい条件

read-only Toolでも、次の項目は確認します。

項目	見る理由
Tool名	モデルが誤って選ばない名前にする
description	実際の挙動とずれないようにする
inputSchema	対象、件数、filterを制限する
timeout	長時間実行を止める
rate limit	API制限やコストを守る
error	secretやstack traceを返さない
log	誰が何を読んだか残す

Tool名は、短く安定した名前にします。公式Tools仕様では、Tool名の文字種や長さに関するガイドも示されています。人間が見てもわかり、モデルが誤解しにくい名前にしてください。

write Toolには承認と取り消し条件を置く

write Toolは、状態を変えます。Issueのclose、PR作成、メール送信、DB更新、権限変更、deploy、課金操作は、すべてwrite Toolとして扱います。

承認画面で出す情報

write Toolを入れるなら、承認画面に最低限次を出します。

表示するもの	例
Tool名	`create_pull_request`
対象	repository、branch、issue、user、environment
変更内容	title、body、diff、payload
理由	なぜ実行するのか
影響範囲	staging、本番、通知先、課金
戻し方	revert、close、rollback、再送防止

「モデルが正しく判断してくれるはず」は承認条件になりません。Toolが動くことと、承認なしで呼んでよいことは別です。

Resourcesの公開範囲はデータ分類から決める

VisualResource公開前のデータ分類読み取り中心のResourceでも、文脈に入った情報は応答やログへ流れる可能性があります。

項目	内容	見方
public		公開README、公開API docs。利用しやすいが、古い情報を混ぜないようにします。
internal		社内runbook、設計メモ。チーム、リポジトリ、プロジェクトの範囲を決めます。
confidential		非公開issue、障害ログ、顧客要望。最小範囲、監査、redactionを前提にします。
restricted		個人情報、secret、本番DB dump。原則Resource化せず、代替データを検討します。

URIは読める範囲を表す名前にし、広すぎるtemplateや本番データの丸出しを避けます。

Resourceは読み取り中心ですが、読み取りだから安全とは限りません。MCP導入前に、Resourceをデータ分類に沿って整理します。

データ分類	Resource例	初期方針
public	公開README、公開API docs	利用しやすい
internal	社内runbook、設計メモ	チーム範囲を決める
confidential	非公開issue、障害ログ、顧客要望	最小範囲、監査、redaction
restricted	個人情報、secret、本番DB dump	原則Resource化しない

Resource URIを雑に広げない

ResourceはURIで識別されます。URI設計が雑だと、あとから範囲制限が難しくなります。

避けたい例は、次のような広すぎるResourceです。

file:///Users/alice
docs://company/*
logs://production/*
db://main/*

最初は、具体的な単位に分けます。

docs://runbook/payment-timeout
schema://orders/read-only
issues://project-alpha/search
logs://staging/api-errors/redacted

URIは、読める範囲を表す名前にします。Resource名だけでなく、URI、mimeType、description、データ分類、保持期間、キャッシュ有無までレビューしてください。

subscribeとlistChangedは後からでいい

Resourcesには、変更通知や購読の仕組みがあります。便利ですが、最初から使う必要はありません。

動的なResource一覧は、次の問題を持ち込みます。

ユーザーごとに見えるResourceが変わる
権限変更後もクライアントに古い情報が残る
cacheと実データの差分が起きる
listChanged通知の監査が必要になる
会話文脈に古いResource内容が残る

まずは、静的な一覧と明示的な読み取りから始めます。必要になってからsubscribeやlistChangedを入れる方が、権限レビューをしやすくなります。

Promptsは作業標準化に使う

VisualPromptテンプレートの構成チームの作業手順をそろえるために、Promptの中身と責任者を明確にします。

name / description

作業内容が伝わる名前と説明にし、何を依頼したことになるかを明確にします。

arguments

service、time_range、symptomなど、必要な入力を絞ります。

messages

調査観点、禁止事項、出力形式を固定し、暗黙のTool実行を求めないようにします。

embedded resources

runbookやredacted logへの参照を使い、秘密情報や内部URLの直書きを避けます。

owner

SRE、platform team、security teamなど、社内標準として更新する担当を置きます。

Promptは作業品質をそろえる入口であり、承認、認可、allowlist、監査ログの代わりにはなりません。

Promptsは、チームの作業手順をAIに渡しやすくするために使えます。たとえば、コードレビュー、障害調査、リリース判定、依存関係更新のような作業に向いています。

Promptは、次のように設計します。

項目	例
name	`incident_triage`
description	障害一次調査の観点を整理する
arguments	service、time_range、symptom
messages	調査観点、禁止事項、出力形式
embedded resources	runbookやredacted logへの参照
owner	SRE、platform team、security team

Promptは権限を上げない

Promptは、権限の入口ではありません。Promptに強い指示を書いても、HostやServerの権限設定を超えてはいけません。

避けたいPromptの例です。

全ファイルを読み、必要なら本番DBも確認し、承認なしで修正してください。

よいPromptは、作業範囲を絞ります。

指定されたエラーログと公開済みrunbookだけを使い、原因仮説、追加確認、次の担当者を整理してください。外部API呼び出しやwrite Tool実行は提案に止め、実行しないでください。

Promptは、チームの作業品質をそろえるには便利です。しかし、承認、認可、allowlist、監査ログの代わりにはなりません。

Promptにもレビュー担当を置く

Promptはコードではないため、レビューされずに増えがちです。社内標準として配るなら、Promptにもownerを置きます。

レビュー観点は次の通りです。

古い手順を含んでいないか
秘密情報や内部URLを直接埋めていないか
Tool実行を暗黙に求めていないか
出力先や共有範囲を決めているか
incident、security、legalなどの判断をAIだけに任せていないか

Transportと認可を混同しない

VisualstdioとHTTP-based transportの見る場所接続方法が違うと、credential、攻撃面、監査の作り方も変わります。

項目	内容	見方
起動		stdioはHostがローカルプロセスとして起動し、HTTP-based transportはremoteまたは社内HTTP endpointへ接続します。
credential		stdioは環境変数やローカル設定、HTTPはOAuth 2.1系の認可、token、scopeを確認します。
主なリスク		stdioは起動コマンド、ローカル権限、secret、stdout汚染、HTTPはtoken audience、SSRF、scope過大、sessionを見ます。
初期導入		stdioはローカルread-onlyから始めやすく、HTTPは認可と監査設計を先に固めます。
監査		stdioはHost側ログとServer側ログ、HTTPはIdP、gateway、Serverログを組み合わせます。

stdio向けの安全策をHTTPサーバーの認可として流用せず、それぞれの止め方を分けます。

MCPの接続方法には、ローカルでプロセスを起動するstdioと、HTTP-based transportがあります。ここを混同すると、認可設計が崩れます。

観点	stdio	HTTP-based transport
起動	Hostがローカルプロセスとして起動	remoteまたは社内HTTP endpointへ接続
credential	環境変数やローカル設定から扱う	OAuth 2.1系の認可、token、scope
主なリスク	起動コマンド、ローカル権限、secret、stdout汚染	token audience、SSRF、scope過大、session
初期導入	ローカルread-onlyから始めやすい	認可と監査設計が必要
監査	Host側ログとServer側ログを組み合わせる	IdP、gateway、Serverログを組み合わせる

stdioでは実行コマンドを見る

Authorization仕様では、stdio transportはHTTP-based authorization flowを使う対象ではなく、credentialは環境などから扱う前提になります。つまり、stdioではOAuthの話より先に、ローカルで何を実行するかを見ます。

確認する項目は次の通りです。

起動コマンドを省略せず表示できるか
sudo、rm -rf、不明なcurl、不明なnpxを含んでいないか
環境変数に不要なtokenを渡していないか
アクセス可能なディレクトリが広すぎないか
stdoutにMCP message以外を出していないか
ログをstderrや安全なlog sinkへ分けているか
local serverが不要になった時に停止できるか

公式Security Best Practicesでも、ローカルMCPサーバーはユーザーのローカル環境で実行され、同じ権限で動き得る点がリスクとして説明されています。ローカルだから安全ではありません。

HTTPではOAuthとscopeを小さく作る

HTTP-based transportでは、Authorization仕様が重要になります。公式仕様では、Authorizationはoptionalですが、制限付きMCP ServerをHTTPで扱う場合は、OAuth 2.1系の仕様、Protected Resource Metadata、Authorization Server Discovery、scope、access tokenの扱いを確認する必要があります。

HTTPで先に潰すリスク

特に見たいのは次です。

項目	確認内容
scope	readとwriteを分けているか
audience	tokenが対象MCP Server向けに発行されているか
token passthrough	downstream API向けtokenをそのまま受け入れていないか
SSRF	metadata discoveryで内部networkへ到達しないか
session	session IDを認証代わりにしていないか
consent	追加scopeや高リスクToolで同意を取り直せるか

MCPの更新確認やHTTP認可の詳細は、公開済みのMCP更新で壊さないための確認手順：仕様・SDK・認可・Toolsの見方で扱っています。この記事では、導入前に「stdioとHTTPでは見る場所が違う」と覚えておけば十分です。

失敗点

VisualMCP導入で起きやすい分類ミス実装ミスよりも、何をどのprimitiveに置くかの誤りが影響を広げます。

何でもToolにする

文脈として読ませればよいものはResourceへ、作業型はPromptへ分けます。

writeをread-onlyと同じscopeにする

issues:readとissues:write、deploy:previewとdeploy:productionは分けます。

本番データを混ぜる

本番ログや顧客データは、redaction、sampling、期間制限、検索範囲制限を先に入れます。

Promptで安全ルールを代替する

Tool実行、Resource読み取り、外部通信、token、承認はPromptではなく権限境界で制御します。

package名だけで判断する

Protocol Revision、SDK version、package構成、client対応、検証結果を分けて確認します。

自然言語の利用ルールだけで安全境界を作らず、Host、Client、Server、IdP、network policyで止めます。

MCP導入で起きやすい失敗は、実装ミスよりも分類ミスです。

何でもToolにする

社内ドキュメント、DB schema、runbook、ログ検索、レビュー依頼を全部Toolにすると、モデルが呼び出す操作として扱われます。文脈として読ませればよいものはResourceへ、ユーザーが選ぶ作業型はPromptへ分けた方が安全です。

write Toolをread-onlyと同じscopeにする

issues:readとissues:write、docs:readとdocs:update、deploy:previewとdeploy:productionは分けます。scopeを広く作ると、盗まれたtokenや誤承認の影響が広がります。

Resourceに本番データを混ぜる

「AIに調査させたい」からといって、本番ログや顧客データをResource化するのは危険です。必要なら、redaction、sampling、stagingデータ、期間制限、検索範囲制限を先に入れます。

Promptで安全ルールを代替する

Promptに「危険なことをしないで」と書くのは補助にはなります。しかし、Toolを呼べるか、外部通信できるか、どのResourceを読めるかは、PromptではなくHost、Client、Server、IdP、network policyで制御します。

SDKのpackage名だけで判断する

TypeScript SDK repositoryのREADMEでは、main branchがv2 pre-alphaで、v1.xが本番利用向けとして案内されています。一方、npmでは@modelcontextprotocol/serverや@modelcontextprotocol/clientの2.0.0-alpha.2も見えます。

導入時は、次を分けて確認してください。

確認対象	見ること
Protocol Revision	公式仕様のlatest
SDK version	npm packageとrelease notes
package構成	v1系の`@modelcontextprotocol/sdk`か、split packageか
client対応	使うHostやAIエージェントが対応しているか
検証結果	build、起動、list、call、read、get

実務で使うなら

VisualMCP導入の最小ステップ業務導入では、使えることより先に、誰が管理し、何を許し、何を記録するかを決めます。

1owner
Platform Team、Security Team、Target Service Ownerを分けます。
2server
目的、transport、確認したProtocol Revisionを記録します。
3tools
allowedとblockedを分け、read-only、draft_only、writeの承認条件を書きます。
4resources
許可するURI prefixと、personal_data、secrets、production_db_rowsのような禁止データを分けます。
5prompts
incident_triageやcode_review_requestなど、許可する作業テンプレートを限定します。
6audit
Tool call、Resource read、review intervalを残し、本番前レビューにつなげます。

最初のPoCはstdio、read-only Tool、限定Resource、Prompt 1つ、本番データなしから始めるとレビューしやすくなります。

MCPを業務に入れるなら、最初に次のチェックリストを作ります。

mcp_rollout_checklist:
  owner:
    platform: "Platform Team"
    security_review: "Security Team"
    service_owner: "Target Service Owner"
  server:
    purpose: "Issue and runbook read-only access"
    transport: "stdio"
    protocol_revision_checked: "2025-11-25"
  tools:
    allowed:
      - name: "search_issues"
        effect: "read-only"
        approval: "not_required"
      - name: "create_issue_draft"
        effect: "draft_only"
        approval: "required_before_publish"
    blocked:
      - "delete_issue"
      - "deploy_production"
  resources:
    allowed_uri_prefixes:
      - "docs://runbook/"
      - "schema://read-only/"
    blocked_data:
      - "personal_data"
      - "secrets"
      - "production_db_rows"
  prompts:
    allowed:
      - "incident_triage"
      - "code_review_request"
  audit:
    log_tool_calls: true
    log_resource_reads: true
    review_interval: "monthly"

このような表を作ると、MCP Serverの実装レビューが具体的になります。実装者だけでなく、利用チーム、セキュリティ担当、運用担当が同じ表を見られる状態にしてください。

最初のPoC

最初のPoCは、次の条件に絞るのがおすすめです。

stdioでローカル起動する
read-only Toolだけにする
Resourceは社内runbookの一部だけにする
Promptは1つだけにする
本番データを使わない
secretを渡さない
Tool呼び出しとResource readをログに残す
write操作は提案だけに止める

この段階でうまくいったら、次にHTTP化、OAuth、scope、複数ユーザー、監査ログ、allowlist、承認UIを検討します。

本番導入前のレビュー

本番導入前は、次をレビューします。

レビュー項目	質問
Server登録	誰がMCP Serverを追加できるか
Tool allowlist	どのToolをHostへ見せるか
Resource allowlist	どのURI prefixを許すか
Prompt管理	誰がPromptを更新できるか
認可	scope、audience、token保管は妥当か
承認	write Tool前に人間が確認できるか
ログ	調査に必要な証跡が残るか
rollback	ToolやServerを無効化できるか

AIコーディングエージェントからMCPや外部通信を使う場合は、Codexにインターネットアクセスを許可する前に：web search・allowlist・MCP外部通信の分け方も合わせて読むと、外部接続の境界を整理しやすくなります。

セキュリティ・コスト注意

Visual公開前に見るリスクと上限MCPは外部データアクセスやコード実行経路を作るため、セキュリティとコストを同時に確認します。

項目	内容	見方
broad scope		read、write、adminを分け、広いscopeを初期値にしないようにします。
token passthrough		downstream API向けtokenをそのまま受けず、MCP Server向けに発行されたtokenを扱います。
SSRF		metadata discoveryや外部URL取得で内部networkへ到達しないように制限します。
local server compromise		起動コマンド、sandbox、network、filesystem、secretを確認します。
cost limit		外部API、LLM token、検索、CI、ログ保存にはrate limit、cache、timeout、日次予算を置きます。

便利なToolほど繰り返し呼ばれる可能性があるため、上限件数、dry-run、監査ログを設計に入れます。

MCPは、外部データアクセスやコード実行経路を作るため、セキュリティとコストの両方を見ます。

セキュリティ注意

防御側チェックリスト

特に注意するのは次です。

リスク	対応
broad scope	read、write、adminを分ける
token passthrough	MCP Server向けに発行されたtokenだけを受ける
SSRF	metadata discoveryや外部URL取得を制限する
local server compromise	起動コマンド、sandbox、network、filesystemを確認する
Resource leakage	機密情報、個人情報、secretをResourceに混ぜない
Tool misuse	write Toolに人間承認と監査ログを置く
Prompt injection	PromptやResource内容を信頼境界にしない

公式Security Best Practicesでは、confused deputy、token passthrough、SSRF、local MCP server compromise、scope minimizationなどが扱われています。攻撃手順を真似するためではなく、防御側のチェックリストとして読んでください。

コスト注意

MCP Server自体が無料でも、Toolが呼ぶ先にはコストが発生します。

外部APIの課金
LLM APIのtoken
検索基盤のquery
CIやテスト実行時間
ログ保存量
監査対応の運用コスト
OAuthやgatewayの運用コスト

Toolは、モデルが何度も呼ぶ可能性があります。rate limit、cache、timeout、dry-run、上限件数、日次予算を入れてください。特に検索、ログ取得、LLM再帰呼び出し、ブラウザ操作、CI実行は、思ったよりコストが膨らみます。

FAQ

Visualよくある迷いMCP導入前に誤解しやすい点を、権限設計の視点で整理します。

tool callingと同じか

Toolsは近い使われ方をしますが、MCPはResources、Prompts、Transport、Authorizationも含むプロトコルです。

Resourcesは勝手に読むのか

Resourcesはapplication-drivenで、HostやClientの実装によって文脈への入り方が変わります。

Promptsだけで安全か

Promptは作業テンプレートであり、Tool、Resource、外部通信、token、承認は別に制御します。

OAuthは必須か

必須ではありませんが、HTTP-based transportで制限付きServerを扱う場合はscopeやaudienceを確認します。

Serverを1つにまとめるか

read-only検索と本番deployやDB writeを同じServer、同じscope、同じ承認条件にまとめない方が安全です。

迷ったら、モデルが選べる操作、文脈に入るデータ、人間が選ぶ作業型を分け直します。

MCPはtool callingと同じですか

同じではありません。MCPのToolsはtool callingに近い使われ方をしますが、MCPはToolsだけでなくResources、Prompts、Transport、Authorization、capability negotiationなどを含むプロトコルです。

ResourcesはAIが勝手に読むのですか

Resourcesはapplication-drivenです。HostやClientの実装によって、ユーザーが明示的に選ぶ場合も、検索やheuristicsで文脈に入る場合もあります。だからこそ、Resource一覧に出す範囲を最初に絞ります。

Promptsだけで安全ルールを配れますか

配れますが、それだけでは不十分です。Promptは作業テンプレートであり、権限境界ではありません。Toolの実行可否、Resourceの読み取り可否、外部通信、token、承認は別に制御します。

OAuthは必須ですか

必須ではありません。公式Authorization仕様ではAuthorizationはoptionalです。ただし、HTTP-based transportで制限付きMCP Serverを扱う場合は、Authorization仕様に沿ってOAuth 2.1系の考え方、Protected Resource Metadata、scope、audience、token handlingを確認します。stdioでは同じ認可フローをそのまま使う対象ではありません。

MCP Serverを1つにまとめた方が楽ですか

最初は楽に見えますが、権限と監査が難しくなります。read-onlyのドキュメント検索と、本番deployやDB writeを同じServer、同じscope、同じ承認条件にまとめない方が安全です。

MCPやAIエージェントの仕様更新は速いので、更新通知を追いたい場合はニュースレターも使ってください。チーム導入でTools、Resources、Prompts、OAuth、allowlistの棚卸しから相談したい場合は、お問い合わせに送ってもらえれば、前提整理から扱えます。

参照した主な情報源

https://modelcontextprotocol.io/specification/latest
https://modelcontextprotocol.io/specification/2025-11-25
https://modelcontextprotocol.io/specification/2025-11-25/architecture
https://modelcontextprotocol.io/specification/2025-11-25/server/tools
https://modelcontextprotocol.io/specification/2025-11-25/server/resources
https://modelcontextprotocol.io/specification/2025-11-25/server/prompts
https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
https://github.com/modelcontextprotocol/typescript-sdk

更新履歴

Visual確認と更新の記録仕様とSDKは変わるため、記事で確認した時点を残します。

2026年6月1日
初版公開。MCP公式仕様2025-11-25、TypeScript SDK repository、npm公開メタデータを確認しました。

導入時には公式仕様、SDK repository、npm package、利用するHostやClientの対応状況を再確認してください。

2026-06-01: 初版公開。MCP公式仕様2025-11-25、TypeScript SDK repository、npm公開メタデータを確認。@modelcontextprotocol/sdkは1.29.0、@modelcontextprotocol/serverと@modelcontextprotocol/clientは2.0.0-alpha.2として確認しました。
確認コマンド: npm view @modelcontextprotocol/sdk version dist-tags time.modified --json、npm view @modelcontextprotocol/server version dist-tags time.modified --json、npm view @modelcontextprotocol/client version dist-tags time.modified --json

追記: 2026年6月4日の最新情報

3行まとめ

この記事でわかること

前提知識

結果

MCPは何を標準化するのか

Hostが持つ責任

ClientはServerごとの接続単位

Tools、Resources、Promptsをどう分けるか

Toolsはモデルが呼び出し得る操作

Resourcesはモデルに渡す文脈データ

Promptsはユーザーが選ぶ作業テンプレート

Toolsの権限設計は副作用から始める

read-only Toolから始める

許可してよい条件

write Toolには承認と取り消し条件を置く

承認画面で出す情報

Resourcesの公開範囲はデータ分類から決める

Resource URIを雑に広げない

subscribeとlistChangedは後からでいい

Promptsは作業標準化に使う

Promptは権限を上げない

Promptにもレビュー担当を置く

Transportと認可を混同しない

stdioでは実行コマンドを見る

HTTPではOAuthとscopeを小さく作る

HTTPで先に潰すリスク

失敗点

何でもToolにする

write Toolをread-onlyと同じscopeにする

Resourceに本番データを混ぜる

Promptで安全ルールを代替する

SDKのpackage名だけで判断する

実務で使うなら

最初のPoC

本番導入前のレビュー

セキュリティ・コスト注意

セキュリティ注意

防御側チェックリスト

コスト注意

FAQ

MCPはtool callingと同じですか

ResourcesはAIが勝手に読むのですか

Promptsだけで安全ルールを配れますか

OAuthは必須ですか

MCP Serverを1つにまとめた方が楽ですか

次に読むなら

TypeScriptでMCPサーバーを作る：Tools・Resources・Promptsの最小構成

MCP更新で壊さないための確認手順：仕様・SDK・認可・Toolsの見方

OpenAI Agents SDKのtool guardrailsを実務に入れる前に：handoff・built-in tools・人間承認の分け方

参照した主な情報源

更新履歴