MCP連携の実装パターンを業務適用視点で完全整理｜Claude・SaaS・社内DB3層接続の権限設計

こんにちは！株式会社雲海設計の技術部です。

「mcp連携をPoCで動かしたが、本番に乗せる時の権限設計が分からない」「Claude DesktopにMCPサーバーを繋いだら社内DBが丸見えになりそうで怖い」「外部SaaSと社内システムをMCPで横断するときの設計図がない」——2026年6月現在、mcp連携(Model Context Protocol連携)に関する設計レビュー相談が、技術部に毎週寄せられています。本記事では、MCP連携の実装パターンを業務適用視点で類型化し、Claude・外部SaaS・社内DBの3層接続と権限設計の実務勘所を整理します。

• TL;DR

• mcp連携はAnthropicが2024年末に公開した、LLMと外部ツール/データソースを接続する標準プロトコル。2026年現在、OpenAIやGoogleも対応表明し業界標準として定着

• 業務適用は「LLMクライアント層 / MCPサーバー層 / バックエンド層」の3層に分けて設計するのが鉄則。1層に詰め込むと権限事故が起きる

• 権限設計は「MCPサーバーが持つ権限 ≠ 利用者の権限」を出発点に。サーバー側で利用者IDをトークンに紐づけ、バックエンドAPIで再認可する二段構えが定石

• 実装パターンは大別して(1) 外部SaaS接続型 (2) 社内DB接続型 (3) ハイブリッド型の3類型。ROIが立ちやすいのは(1)→(3)→(2)の順

• 本番運用では監査ログ・レート制限・読み取り専用デフォルトの3点セットが必須。書き込み権限はホワイトリスト方式で個別に解放する

そもそもMCP連携とは何か？

結論から言うと、MCP(Model Context Protocol)はLLMと外部ツール・データソースを接続するための標準プロトコルで、Anthropicが2024年11月にオープン仕様として公開しました。2026年6月現在、OpenAI・Google・各種IDEベンダーが対応を表明し、AIエージェント時代の事実上の標準となっています。

従来のAPI連携と何が違うのか

従来のLLM連携は、各社が独自にFunction CallingやTool Useの仕様を定め、ベンダー固有の実装が必要でした。MCPはこの「LLMと外部リソースの接続方式」を標準化し、一度MCPサーバーを書けばClaude・ChatGPT・社内エージェントなど複数のクライアントから再利用できる構造を提供します。

MCPはLLM版のUSB-Cである——Anthropicの公式ドキュメントは比喩的にこう表現しています。差し込み口を統一することで、ツール側もクライアント側も組み合わせの自由度が一気に上がる、という思想です。

MCPの基本要素

• MCPホスト: LLMを動かすクライアント (Claude Desktop, Claude Code, 各種IDE)

• MCPサーバー: 外部リソースをLLMから使える形に変換するアダプタ層

• リソース: ファイル・DB行・API応答などの参照可能データ

• ツール: LLMが呼び出せる関数 (検索・更新・実行)

• プロンプト: 再利用可能なテンプレート

RAGとの違いを問われることが多いのですが、RAGが「検索して文脈に詰める」一方向の仕組みなのに対し、MCPは「LLMが能動的にツールを呼び出す」双方向のプロトコルです。両者は競合ではなく、MCPサーバー内部でRAGを使うケースも多いです。RAGの基礎はRAGとは何か？仕組み・業務適用・ハルシネーション抑制を実装目線で解説でも整理しています。

なぜ今、業務適用視点でMCP連携を論点化するのか？

結論から言うと、2026年6月時点でMCPサーバーの公開実装が爆発的に増え、PoCを越えて本番投入する企業が急増しているからです。Anthropicの公式リポジトリだけでも数百のサーバー実装が並び、Slack・GitHub・Google Drive・Notion・Salesforce・主要DBへの接続が「コピペで動く」状態になっています。

しかし、ここに業務適用上の落とし穴があります。OSS実装の多くは「個人の開発端末で動かす」前提で書かれており、エンタープライズ用途の権限分離・監査ログ・ネットワーク境界を満たしていません。動くMCPサーバー ≠ 業務に乗せられるMCPサーバーです。

2025年と2026年の変化

MCP連携の業務適用パターンは何種類あるのか？

結論として、業務適用視点では3つのパターンに類型化できます。それぞれROI・難易度・リスクが大きく異なるため、自社が今どの位置にいるかを把握することが導入の第一歩です。

パターン1: 外部SaaS接続型 (Slack/GitHub/Notion等)

最も導入しやすく、ROIが立ちやすい型です。既存SaaSのAPIをMCPサーバーで包み、Claudeから「Slackの#dev-incidentsを要約して」「GitHubの直近PRをレビュー観点で整理して」といった指示を実行させます。

• 難易度: ★☆☆ (OSSサーバーをそのまま使えるケース多数)

• ROI: 高 (情報集約タスクの工数を50〜70%削減)

• リスク: 中 (SaaSのOAuthスコープ設定が肝)

パターン2: 社内DB接続型 (基幹DB/データウェアハウス)

難易度は最も高いが、当たれば破壊力が大きい型です。Snowflake・BigQuery・社内PostgreSQLなどに対し、MCPサーバー経由で自然言語クエリを投げます。

• 難易度: ★★★ (権限・監査・SQLインジェクション対策が必須)

• ROI: 非常に高い (アナリストへの問い合わせ削減効果)

• リスク: 高 (権限設計を誤ると個人情報事故に直結)

パターン3: ハイブリッド型 (SaaS×社内DB横断)

「営業案件(Salesforce) × 受注実績(社内DB) × Slackの顧客やりとり」を横断するエージェント型ユースケースです。2026年現在、最も発注相談が増えている領域です。

• 難易度: ★★☆

• ROI: 高 (横断分析という新ユースケースを開拓)

• リスク: 中〜高 (データ突合における権限境界が論点)

3層接続アーキテクチャをどう設計するか？

結論として、「LLMクライアント層 / MCPサーバー層 / バックエンド層」の3層に明確に分離するのが2026年現在の定石です。この分離を怠ると、権限が漏れる・監査ログが取れない・運用負荷が爆発する、の三重苦に陥ります。

各層の責務

3層接続の最小構成例

graph LR
  U[利用者] --> C[Claude Desktop]
  C -->|MCP| S1[MCP Server: Slack]
  C -->|MCP| S2[MCP Server: Internal DB]
  S1 -->|OAuth| SaaS[Slack API]
  S2 -->|JWT| API[社内API Gateway]
  API --> DB[(PostgreSQL)]
  S1 --> L[(監査ログ)]
  S2 --> L

MCPサーバーの最小実装例 (TypeScript)

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const server = new Server(
  { name: "internal-db", version: "1.0.0" },
  { capabilities: { tools: {} } }
);

server.setRequestHandler("tools/call", async (req) => {
  const userId = process.env.MCP_USER_ID;
  // 1. 利用者IDを必ず伝搬
  // 2. バックエンドAPIで再認可
  const res = await fetch(`${API}/query`, {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${await mintJwt(userId)}`,
      "X-MCP-Tool": req.params.name,
    },
    body: JSON.stringify(req.params.arguments),
  });
  // 3. 監査ログを書き出す
  await audit({ userId, tool: req.params.name, ts: Date.now() });
  return { content: [{ type: "text", text: await res.text() }] };
});

await server.connect(new StdioServerTransport());

ポイントは「MCPサーバーが直接DBを叩かない」こと。必ず社内APIゲートウェイ経由にして、最終的な権限判定はバックエンド側で行います。

権限設計の実務勘所はどこにあるか？

結論として、権限設計の出発点は「MCPサーバーが持つ権限 ≠ 利用者の権限」を徹底することです。OSS実装の多くは、サーバー起動時の環境変数にAPIトークンを埋め、そのトークンの権限で全ての操作を行います。これは個人利用なら問題ありませんが、業務では絶対NGです。

権限設計の5原則

1. 利用者IDの伝搬: MCPホストからサーバーへ、サーバーからバックエンドへ、必ず利用者の identity を引き継ぐ

2. 読み取り専用デフォルト: 書き込み・削除・実行は明示的なホワイトリストでのみ許可

3. 最小権限の原則: SaaS側のOAuthスコープは必要最小に絞る

4. 監査ログ完全保存: 誰が・いつ・どのツールを・どの引数で呼んだか

5. レート制限とサーキットブレーカー: LLMの誤動作で連打されても被害を抑える

権限事故が起きやすい典型シナリオ

セキュリティ面の全社設計はAIセキュリティ対策実装ガイド2026もあわせてご確認ください。プロンプトインジェクション経由でMCPツールが誤発動する攻撃ベクトルが2026年に増えています。

本番運用で押さえるべき監視・ガバナンスは？

結論として、本番運用は「監査ログ・コスト監視・暴走対策」の3本柱です。PoCで動いたMCPサーバーをそのまま本番に乗せると、必ずどこかで火を噴きます。

監査ログの設計

• イベント単位: tool_call_started / tool_call_completed / tool_call_failed

• 必須フィールド: user_id, tool_name, arguments_hash, latency_ms, result_size

• 保管期間: 業務システム同等の1〜7年を推奨 (内部統制対象なら確実に7年)

• 引数の生データは個人情報の温床なのでハッシュ化 or マスキングを基本に

コスト監視

MCP経由のツール呼び出しは、LLM側のトークン消費を急増させます。1回の対話で10ツール呼ばれることも珍しくありません。利用者別・ツール別のトークン消費ダッシュボードを最初から仕込んでください。コスト設計の考え方はトークン課金を“原価”に落とす方法を参考にしてください。

暴走対策 (ガードレール)

AIエージェントの95%が本番で失敗する最大の理由は、評価ループとガードレールの欠如である——Gartnerの2026年Q1レポートでもこの点が繰り返し指摘されています。

MCPツールには必ず(1) 引数バリデーション (2) レート制限 (3) 危険操作の承認フローを入れます。詳細はハーネスエンジニアリング ガードレール設計で実装パターンを整理しています。

MCP連携導入のロードマップは？

結論として、「外部SaaS接続 → ハイブリッド → 社内DB接続」の順で段階導入することを強く推奨します。いきなり社内DB接続を狙うと、権限・監査の整備に半年溶かし、現場の熱が冷めます。

3ヶ月単位のステップ

雲海設計の支援領域

当社ではmcp連携の設計・実装・運用伴走を、IT コンサルから受託開発まで一気通貫で提供しています。特に「PoCは動いたが本番設計で詰まった」「権限設計の第三者レビューが欲しい」というご相談が増えています。

• アーキテクチャレビュー: IT コンサルティング

• MCPサーバー受託開発・基盤整備: DX ソリューション

• 業務システムへの組み込み: Web 開発・デザイン

よくある質問

Q. MCP連携とFunction Callingは何が違いますか？

A. Function CallingがLLMベンダーごとの独自仕様であるのに対し、MCPはクライアントとサーバーを切り離すオープン仕様です。Claude向けに書いたMCPサーバーをChatGPTやIDEから再利用できる点が決定的な違いで、2026年現在は標準としての地位を固めつつあります。

Q. MCPサーバーは自作すべきですか？OSSを使うべきですか？

A. 外部SaaS接続は公式OSSから入り、社内システム接続は自作するのが基本です。ただしOSS実装でも、業務利用前に権限・ログ・ネットワーク境界を必ず監査してください。「コピペで動く」ものがそのまま本番に乗せられるとは限りません。

Q. MCP連携にハルシネーションのリスクはありますか？

A. あります。MCPは外部データを取りに行く分、誤ったリソースを掴んだまま自信満々に回答するリスクがあります。ハルシネーションを防ぐプロンプト設計10選と評価ハーネスの併用が必須です。

Q. クラウドのClaude DesktopではなくBedrock経由でもMCPは使えますか？

A. 2026年6月現在、Bedrock側もMCP対応を進めています。エンタープライズ要件(VPC・KMS・監査)が厳しい場合は、Claude Code × VSCode × Bedrock 実践構築ガイドで扱うBedrock構成と組み合わせるのが現実的です。

Q. MCP連携の費用感はどれくらいですか？

A. ライセンス料は不要(OSS仕様)で、コストはほぼ(1) LLM API利用料 (2) 開発・運用工数です。外部SaaS接続型のPoCなら数十万円〜、社内DB接続を含む本番構築は数百万〜千万円規模が目安です。お見積りはお問い合わせからお気軽にどうぞ。

MCP連携は、AIエージェントが「触れる世界」を一気に広げる強力なプロトコルである一方、権限と監査の設計が業務適用の成否を決めます。本記事の3層アーキテクチャと5原則を出発点に、自社の段階に合った導入順を選んでいただければ幸いです。設計レビューや実装伴走のご相談は、いつでも雲海設計までお声がけください。