SASmall AI System

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"
      }
    }
  }
}
READ_ONLY のような環境変数で、サーバー側の挙動を明示的に絞っておく。

サーバー側は、公開したい機能を「ツール」として登録します。ここで重要なのは、 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 は仕様書として書く

「存在しない品目は空の配列を返す(推測しない)」のように、返り値の約束まで書きます。 ここが曖昧だと、AIは結果を都合よく解釈して先に進みます。

安全な導入順序

  1. 1

    1. まず既存のサーバーを探す

    公開されているMCPサーバーは1万件を超えています。カレンダー、ファイル、データベース、チケット管理など、よくある接続先はたいてい既にあります。自作する前に必ず探してください。

  2. 2

    2. 読み取り専用でつなぐ

    最初の接続は必ず読み取りだけにします。料金表を引く、在庫を見る、予定を確認する。この段階で「AIがどんな聞き方をするか」の傾向が分かります。

  3. 3

    3. 出せるデータの範囲を絞る

    テーブル全体を返すのではなく、必要な列だけを返すツールを作ります。個人情報の列はサーバー側で落とします。AI側の指示で制御しないでください。

  4. 4

    4. 書き込みは1か所だけ許す

    書き込みを許可するときは、対象を1つのテーブル・1つのフォルダに固定します。汎用の「SQLを実行する」ツールは公開しないでください。

  5. 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)を新規採用していない
  • 誰が・いつ・何に触れたかのログが残る
  • 使っていない接続を止める棚卸しの周期を決めた