MCP
MCP で社内システムにつなぐ
MCP は、AIツールと社内システムをつなぐ共通の作法です。主要なコーディングエージェントが軒並み対応したため、1つ作れば複数のツールから同じ設定で使えます。ただしここから先は、技術より権限設計が本体になります。
運用 ・ 読了目安 約11分
MCP とは
Model Context Protocol は、AIが外部のデータや機能にアクセスするための共通プロトコルです。 Anthropic が公開し、現在は Agentic AI Foundation(Linux Foundation 傘下)が管理しています。 Anthropic、OpenAI、Google、Microsoft、AWS が揃って対応しており、事実上の標準になりました。
利点はシンプルです。以前は「このAIツールにこのシステムをつなぐ」ための実装を、組み合わせの数だけ作る必要がありました。 MCP なら、サーバーを1つ作れば、対応するどのAIツールからも同じように使えます。ツールを乗り換えても接続は残ります。
登場人物は3つだけ
- ・ホスト: AIツール本体(Claude Code、Cursor など)
- ・サーバー: つなぎたいシステム側に置く小さなプログラム
- ・ツール: サーバーが公開する機能の単位(「料金表を引く」など)
2026-07-28版で変わったこと
2024年の公開以来、最大の更新が 2026-07-28 版です。実験段階の仕様から、企業が本番運用する前提の仕様に切り替わりました。 これから作るなら、この版に合わせてください。
| 変更点 | 内容 | 実務への影響 |
|---|---|---|
| プロトコル中核のステートレス化 | 接続の状態を持たない設計に変更 | サーバーを複数台に並べやすくなり、運用が現実的になった。新規構築はこの前提で設計する。 |
| Extensions フレームワーク | 中核仕様と拡張機能を分離 | 必要な機能だけを足せる。中核が軽くなり、実装間の互換性が読みやすくなった。 |
| Tasks | 実験扱いから拡張へ移動 | 長時間かかる処理を非同期で扱う仕組み。集計や一括処理を任せる用途で効く。 |
| 認可の強化 / DCR の非推奨化 | 動的クライアント登録を CIMD に置き換え | DCR は当面動くが、新規実装では使わない。認証まわりは新方式で組む。 |
| Roots / Sampling / Logging の非推奨化 | 12か月以上は動作継続、新規採用は非推奨 | 既存構成に含まれていたら、移行計画を立てる時期。新規では採用しない。 |
| 正式な非推奨ポリシー | 廃止までの猶予が明文化 | 仕様変更に振り回されにくくなった。長期運用の判断がしやすい。 |
出典: The 2026-07-28 Specification(Model Context Protocol Blog)
つなぎ方の基本
ホスト側は、設定ファイルにサーバーの起動方法を書くだけです。
{
"mcpServers": {
"price-table": {
"command": "node",
"args": ["./mcp/price-table-server.js"],
"env": {
"PRICE_TABLE_PATH": "./data/price-table.csv",
"READ_ONLY": "true"
}
}
}
}サーバー側は、公開したい機能を「ツール」として登録します。ここで重要なのは、 description に「できること」だけでなく「できないこと」も書くことです。AIはこの説明を読んで使い方を決めます。
// 読み取り専用のツール定義(最小の例)
server.registerTool(
"lookup_price",
{
title: "料金表を引く",
description:
"品目名から標準単価を返す。部分一致で検索し、該当が複数あればすべて返す。存在しない品目は空の配列を返す(推測しない)。",
inputSchema: {
item: z.string().describe("品目名。例: 標準プランA")
}
},
async ({ item }) => {
const rows = await lookupPrice(item); // 読み取りのみ。書き込み関数は公開しない
return {
content: [{ type: "text", text: JSON.stringify(rows) }]
};
}
);description は仕様書として書く
安全な導入順序
- 1
1. まず既存のサーバーを探す
公開されているMCPサーバーは1万件を超えています。カレンダー、ファイル、データベース、チケット管理など、よくある接続先はたいてい既にあります。自作する前に必ず探してください。
- 2
2. 読み取り専用でつなぐ
最初の接続は必ず読み取りだけにします。料金表を引く、在庫を見る、予定を確認する。この段階で「AIがどんな聞き方をするか」の傾向が分かります。
- 3
3. 出せるデータの範囲を絞る
テーブル全体を返すのではなく、必要な列だけを返すツールを作ります。個人情報の列はサーバー側で落とします。AI側の指示で制御しないでください。
- 4
4. 書き込みは1か所だけ許す
書き込みを許可するときは、対象を1つのテーブル・1つのフォルダに固定します。汎用の「SQLを実行する」ツールは公開しないでください。
- 5
5. ログと監査を用意してから広げる
誰の指示で、どのツールが、どのデータに触れたか。これが記録されていない状態で範囲を広げると、問題が起きたときに調査ができません。
権限と情報漏えい対策
MCP を入れる段階になると、問題は「AIが賢いか」ではなく「AIに何を触らせているか」に移ります。 押さえるべき原則は3つです。
境界はサーバー側に置く
AIへの指示文でアクセス制御をしないこと。「見ないでください」は守られる保証がありません。サーバーが返さなければ、AIは見られません。
取り込んだ文章は指示ではない
メール本文やWebページの中に「これまでの指示を無視して…」と書かれていることがあります。外部由来のテキストは常にデータとして扱う設計にします。
記録がないものは運用ではない
誰の指示で、どのツールが、どのデータに触れたか。これが残っていない構成は、問題が起きた時点で調査不能になります。
最初につなぐ先の選び方
やりがちな失敗
やりがちな失敗
「SQLを自由に実行できる」汎用ツールを公開する。
こうする
用途ごとに専用のツールを作ります。lookup_price、list_reservations のように、できることを固定します。
やりがちな失敗
アクセス制御をAIへの指示文で書く(「個人情報は見ないでください」)。
こうする
指示文はセキュリティ境界になりません。サーバー側で返すデータそのものから除外します。
やりがちな失敗
外部の公開MCPサーバーに、社内データをそのまま渡す。
こうする
接続先の運営者・データ保持方針を確認します。不明なら、社内で動かせるサーバーを使います。
やりがちな失敗
非推奨になった Roots / Sampling / Logging を新規実装で使う。
こうする
2026-07-28版で非推奨です。動くうちに、代替の仕組みへ移す計画を立てます。
やりがちな失敗
外部から取り込んだテキスト(メール本文、Webページ)を指示として扱う。
こうする
プロンプトインジェクションの入口です。取り込んだ内容は「データ」であり指示ではない、と扱う設計にします。
やりがちな失敗
接続だけ作って、誰も使わないまま放置する。
こうする
接続は攻撃面です。使っていないサーバーは止めます。棚卸しの周期を決めておきます。
導入前チェックリスト
- 既存の公開サーバーで代替できないか確認した
- 最初の接続は読み取り専用になっている
- 個人情報・機微情報がサーバー側で除外されている
- 汎用の実行系ツール(任意SQL、任意コマンド)を公開していない
- 認可は新方式(CIMD)で組んでいる
- 非推奨機能(Roots / Sampling / Logging / DCR)を新規採用していない
- 誰が・いつ・何に触れたかのログが残る
- 使っていない接続を止める棚卸しの周期を決めた
Next
続けて読む
AGENTS.md の書き方
AIコーディングエージェントに渡す共通指示ファイル。何を書き、何を書かないかを、実際に貼れる雛形つきで解説します。
Agent SkillSkill(SKILL.md)の作り方
「毎回同じ説明をしている作業」を手順ファイルとして資産化する方法。frontmatter の書き方と段階的読み込みの考え方を扱います。
Sub Agentサブエージェントの設計
調査・レビュー・生成を別文脈に切り出して任せる設計。どこまで自動化し、どこで人が止めるかの線引きを決めます。
Prompt実務プロンプトの型
コツ集ではなく、業務で再利用できる4つの型。案内文・議事録・項目抽出・仕分けの実例で示します。