専門家一覧
MCP サーバ構築

MCPサーバ構築の実践手順と設計判断｜自社データ連携を安全に進める考え方

この記事は急速に進化する技術について解説しています。最新情報は公式ドキュメントをご確認ください。

約12分で読めます
文字サイズ:
MCPサーバ構築の実践手順と設計判断｜自社データ連携を安全に進める考え方
目次

この記事の要点

  • AIエージェントと社内データの安全かつ効率的な連携を実現
  • 従来のAPI連携の課題を解決し、再利用性と開発効率を向上
  • セキュリティ設計、リスク管理、ガバナンス体制の構築を網羅

導入

社内データをAIに使わせたい、でも「どこまで見せてよいのか」「何を自動化してよいのか」が曖昧なまま進めると、実装は早くても運用でつまずきます。MCPサーバ構築が注目されるのは、まさにこの曖昧さを減らせるからです。MCPはModel Context Protocolの略で、AIモデルと外部ツールやデータをつなぐための共通のやり方を定める考え方です。AnthropicのMCP公式ドキュメントでは、MCPはモデルを外部のデータや機能に接続するためのオープンなプロトコルとして説明されています。[^1]

ここで大事なのは、MCPを「AIに何でもつなげる魔法」と見ないことです。実務では、読み取り専用でよい情報、操作権限が必要な情報、生成AIに渡すべきでない情報が混在します。MCPはその境界を設計しやすくするのが強みです。逆に言えば、設計なしで導入すると、RAGやAPI直結と同じく、便利さの裏で管理が難しくなります。

この記事では、MCP サーバ構築の基本から、Model Context Protocol 使い方、MCP SDK 実装、Claude 自社データ連携を見据えた設計の考え方までを、比較しながら整理します。特に初心者が混同しやすいResourcesとToolsの違いは、ビジネス上の役割まで踏み込んで説明します。

MCPの核心：なぜ「Model Context Protocol」がB2BのAI活用を加速させるのか

AIモデルと外部データの「共通言語」としてのMCP

MCPの価値は、AIに接続する相手ごとに個別実装を増やさず、共通の接続方式を持てる点にあります。Anthropicの公式ドキュメントでは、MCPはモデルとデータソース、ツールをつなぐための標準化された方法として位置づけられています。[^1] これはB2Bの現場ではかなり大きい意味を持ちます。

たとえば、社内の議事録、契約書、在庫台帳、チケット管理、カレンダーは、それぞれ形式も権限も違います。従来は、各システムに対して個別のAPI実装を作り、AI側のプロンプトやRAGの前処理も別々に管理しがちでした。MCPを使うと、AI側から見た接続面をそろえやすくなります。結果として、接続先が増えても設計の見通しが保ちやすい。ここが「標準」が効く場面です。

従来のRAGとの違いと優位性

RAGは、検索してから生成するアプローチです。これは今でも有効ですが、RAGだけでは「読む」ことに寄りやすい。MCPは、読むだけでなく、ツール実行や構造化された操作も含めて扱える点が違います。つまり、単なる知識参照ではなく、業務の一部を安全に委ねるための接続層として使いやすい。

比較すると、RAGは「資料を探して答える」ことに強く、MCPは「資料を探す」「状態を確認する」「許可された操作を実行する」をまとめて設計しやすい。B2Bではこの差が効きます。なぜなら、現場の要件は“答えてほしい”だけでなく、“更新してほしい”“通知してほしい”“申請してほしい”まで含むことが多いからです。

構築前の準備：開発環境のセットアップとMCP SDKの選択

MCPの核心：なぜ「Model Context Protocol」がB2BのAI活用を加速させるのか - Section Image

必要なツール群と開発の考え方

MCPサーバを作る前に、まず決めるべきは「何を作るか」より「どの運用形態にするか」です。ローカル実行で十分なのか、チーム共有まで見据えるのか、外部公開を前提にするのかで、認証・ログ・デプロイの設計が変わります。

一般的には、以下のような構成から始めると整理しやすいです。

  • 実装言語: TypeScript か Python
  • 実行環境: Node.js 系、または Python 実行環境
  • MCPクライアント: 公式ドキュメントで案内されるクライアントや、対応エディタ
  • 動作確認: MCP Inspector などの検証ツール

Cursor の公式ドキュメントでは、AIコーディング支援やコードベースの文脈利用が案内されています。MCPと組み合わせると、実装時の確認作業を進めやすくなります。[^2] ただし、どのエディタを使うかは組織の標準に合わせれば十分です。重要なのは、開発体験よりも、接続先の権限管理とログ設計です。

公式SDKの選定基準：TypeScript vs Python

MCP SDKは、対応言語ごとに選び方の軸が変わります。一般論としては、次の比較が実用的です。

  • TypeScript向き: Web APIや既存のNode資産が多い、型安全を重視したい、フロントエンドチームと共通化したい
  • Python向き: データ処理や自動化スクリプトが多い、既存の分析基盤とつなぎたい、実験を素早く回したい

どちらが正解というより、「社内で保守できるか」が最重要です。MCPサーバは作るだけでなく、権限変更、データ項目変更、障害対応が続きます。チームの得意言語と運用体制に合わせるのが、結局いちばん強い選択です。

環境変数と認証情報の安全な管理

MCPサーバ構築で見落とされやすいのが、認証情報の置き方です。APIキーやDB接続情報をコードに埋め込むのは避けるべきです。基本は環境変数、必要なら秘密情報管理サービスを使います。

特に注意したいのは、AIに渡す設定値と、人間が扱う秘密情報を混ぜないことです。AIに見せるのは、あくまで業務上必要なメタデータや許可済みのコンテキストです。接続トークンや管理用の秘密鍵は、MCPサーバ内部で閉じる。ここを分けるだけで、事故の確率はかなり下がります。

【実践】ステップバイステップで進めるMCPサーバの基本構築

プロジェクトの初期化と最小構成

まずは最小構成で動かします。いきなり社内DBや複数ツールをつなぐと、問題の切り分けが難しくなるからです。最初は「Resourcesを1つ」「Toolsを1つ」までで十分です。

// 目的: 最小構成のMCPサーバを作り、Resources と Tools の役割を分けて確認する
// 注意: 実際のSDK名やimport方法は、利用する公式SDKの最新ドキュメントに合わせて調整してください

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

// サーバ本体を作成
const server = new Server(
  {
    name: "internal-data-server",
    version: "1.0.0",
  },
  {
    capabilities: {
      resources: {},
      tools: {},
    },
  }
);

// Resources: 読み取り専用の社内情報を提供する
// 例: 議事録、FAQ、規程、商品一覧など
server.resource(
  "policy-summary",
  "internal://policy/summary",
  async () => ({
    contents: [
      {
        uri: "internal://policy/summary",
        mimeType: "text/plain",
        text: "社内規程の要約テキストです。",
      },
    ],
  })
);

// Tools: 明示的な操作を実行する
// 例: チケット起票、通知送信、在庫確認、データ更新の申請など
server.tool(
  "create-ticket",
  {
    title: "Create Ticket",
    description: "サポートチケットを作成する",
    inputSchema: {
      type: "object",
      properties: {
        title: { type: "string" },
        body: { type: "string" },
      },
      required: ["title", "body"],
    },
  },
  async ({ title, body }) => {
    // 実運用ではここでチケットシステムAPIを呼ぶ
    return {
      content: [
        {
          type: "text",
          text: `チケットを作成しました: ${title}\n${body}`,
        },
      ],
    };
  }
);

// 標準入出力で起動
const transport = new StdioServerTransport();
await server.connect(transport);

この段階では、外部API接続をまだ入れません。まずはMCPサーバがクライアントから見えているか、ResourceとToolが分けて返せるかを確認します。ここで欲張らないのがコツです。

Resources、Prompts、Toolsの実装方法

初心者が最も混同しやすいのが、この3つです。役割を業務に置き換えると理解しやすくなります。

  • Resources: AIが参照する「社内資料棚」
  • Prompts: よく使う依頼文の「定型テンプレート」
  • Tools: 実際に業務を動かす「操作ボタン」

Resourcesは、原則として読み取り中心です。たとえば、就業規則、製品仕様書、会議メモ、FAQを置く場所です。AIはこれを読んで回答しますが、資料そのものを変更するわけではありません。

Toolsは逆です。明示的な実行が伴います。たとえば「在庫を確認する」「承認フローを起動する」「Slackに通知する」などです。Toolsは便利ですが、権限管理と監査ログが必須になります。

Promptsは、業務でよくある問いを再利用しやすくするためのテンプレートです。たとえば「この議事録を要約して、未決事項を抽出して」といった定型依頼を、毎回同じ品質で呼び出せます。

動作確認とテストの考え方

MCPサーバは、単体テストだけでなく、クライアントからの見え方も確認しないと安心できません。最低限、次の3点を見ます。

  1. Resourcesが一覧できるか
  2. Toolsが正しい入力スキーマで見えるか
  3. Tool実行時にエラーが適切に返るか

特に3は重要です。エラー時に例外をそのまま返すと、AI側の対話が不安定になります。ユーザーに見せるメッセージと、内部ログに残すメッセージを分けておくと運用しやすくなります。

ビジネスユースケースへの応用：社内ドキュメントとAIを接続する

【実践】ステップバイステップで進めるMCPサーバの基本構築 - Section Image

SQLiteを用いたローカルデータベースとの連携

社内データ連携の第一歩として、SQLiteのようなローカルDBは扱いやすい選択です。理由は単純で、構造が見えやすく、検証しやすいからです。まずは議事録のメタ情報、FAQ、簡単なマスタデータを入れて、AIが参照できる形にします。

// 目的: SQLiteのデータをResourcesとして安全に公開する
// ポイント: 直接更新ではなく、まずは読み取り専用で始める

import Database from "better-sqlite3";

const db = new Database("./data/internal.db");

server.resource(
  "meeting-notes",
  "internal://db/meeting-notes",
  async () => {
    const rows = db.prepare(
      "SELECT title, summary, updated_at FROM meeting_notes ORDER BY updated_at DESC LIMIT 20"
    ).all();

    return {
      contents: [
        {
          uri: "internal://db/meeting-notes",
          mimeType: "application/json",
          text: JSON.stringify(rows, null, 2),
        },
      ],
    };
  }
);

ここでの判断軸は、AIに「何を見せるか」です。全件を渡す必要はありません。更新日時、担当者、要約など、意思決定に必要な最小限の列から始めるのが安全です。

Google SheetsやNotion APIをMCP経由で操作する

業務でよくあるのは、表計算シートやナレッジツールとつなぎたいケースです。こうした外部サービスは、MCPのToolとして包むと整理しやすくなります。AIに直接APIを触らせるのではなく、MCPサーバが代理で実行する形です。

この構造の利点は2つあります。1つ目は、APIキーや認証更新をサーバ側に閉じ込められること。2つ目は、実行可能な操作を限定できることです。たとえば「行の追加はできるが削除はできない」といった制御がしやすくなります。

Claude 自社データ連携を考えるときの設計ポイント

Claude 自社データ連携を考えるとき、重要なのは「AIが賢いか」ではなく「AIにどの境界まで任せるか」です。MCPサーバを挟むことで、参照できるデータ、実行できる操作、記録すべきログを整理できます。

実務では、次のような分離が有効です。

  • 参照系: Resources
  • 定型指示: Prompts
  • 変更系: Tools
  • 人間の承認が必要な操作: Toolの実行前後に確認フローを入れる

この分離ができると、AI導入の議論が「使えるかどうか」から「どこまで安全に使うか」に変わります。ここはかなり大きい前進です。

運用とトラブルシューティング：エラー対応とセキュリティの確保

運用とトラブルシューティング：エラー対応とセキュリティの確保 - Section Image 3

MCP Inspectorを用いたデバッグ手法

MCPサーバは、作って終わりではありません。接続先が増えるほど、どこで壊れているか分かりにくくなります。そこで役立つのが、MCP Inspectorのような検証ツールです。公式ドキュメントで案内されている検証手段を使うと、ResourcesやToolsの返り値をクライアント視点で確認しやすくなります。[^1]

デバッグ時は、次の順番で切り分けると早いです。

  1. サーバ起動が成功しているか
  2. クライアントが接続できるか
  3. Resource一覧が取れるか
  4. Toolのスキーマが正しいか
  5. 実行結果が期待通りか

この順番を守るだけで、原因不明の時間はかなり減ります。

よくある接続エラーとその解消法

よくあるのは、環境変数の未設定、権限不足、入出力形式の不一致です。特にMCPでは、Toolの入力スキーマが少し違うだけで、クライアント側の体験が崩れます。まずは入力項目を少なくし、必須項目を厳選するのが安全です。

また、外部APIの障害をそのままAIに返すと、会話が長く崩れます。内部エラーはログに残し、AIには「現在は取得できません。時間を置いて再試行してください」のような短いメッセージにすると、利用者の混乱を抑えられます。

B2B利用で不可欠なデータガバナンスと認可制御

B2BのMCP導入で最重要なのは、セキュリティです。これは気合いではなく設計で決まります。最低限、次の観点は外せません。

  • 誰がどのToolを実行できるか
  • どのResourceを見られるか
  • どの操作を監査ログに残すか
  • 個人情報や機密情報をどこでマスクするか

AIに与えるコンテキストは、必要最小限に絞るべきです。多く渡せば便利に見えますが、漏えい時の影響が大きくなります。MCPは「つなぐ」技術ですが、同時に「絞る」技術でもあります。

完成と次のステップ：MCPエコシステムを拡張するためのリソース

コミュニティが公開するMCPサーバの活用

MCPの良さは、自作だけに閉じないことです。公式ドキュメントやGitHub上の情報をたどると、コミュニティが公開しているMCPサーバや実装例が見つかります。これらは、設計の参考にもなりますし、自社でゼロから作る範囲を減らす判断材料にもなります。[^1]

ただし、外部公開の実装をそのまま本番に入れるのはおすすめしません。認証、ログ、入力検証、エラー処理を必ず見直してください。オープンな実装は便利ですが、業務利用では自社のルールに合わせて調整する必要があります。

組織内でのMCPサーバ共有とデプロイの検討

次の段階では、個人の試作から組織の共通基盤へ進めます。そのときのポイントは、サーバを「一つの便利ツール」として置くのではなく、「社内の接続標準」として扱うことです。

そのためには、以下を先に決めるとよいでしょう。

  • どの部署が管理するか
  • どのデータを共通化するか
  • 変更申請の流れをどうするか
  • 監査ログを誰が見るか

このあたりが曖昧なままだと、技術的には動いても運用で止まります。MCPサーバ構築は、実装よりも運用設計で差がつく領域です。

まとめ

MCP サーバ構築の本質は、AIに社内データを「見せる」ことではなく、どこまで「読ませるか」「何を実行させるか」を設計することにあります。Resourcesは参照、Toolsは操作、Promptsは定型化。この分け方ができると、Claude 自社データ連携やAIエージェント 開発は一気に現実味を帯びます。

最初から大きく作る必要はありません。まずは読み取り専用のResourcesを1つ、限定的なToolsを1つ。そこから権限、ログ、承認フローを足していく。これがいちばん安全で、いちばん再現性のある進め方です。

自社のデータ構造、権限設計、既存APIとのつなぎ方は、組織ごとにかなり違います。一般論だけでは決めきれない場面が出てきたら、要件整理の段階で専門家に相談し、どのデータをMCPに載せるか、どこを人手確認に残すかを切り分けると、導入リスクを抑えやすくなります。

参考リンク

[^1]: Anthropic Model Context Protocol 公式ドキュメントによる説明。
[^2]: Cursor 公式ドキュメントによる説明。

MCPサーバ構築の実践手順と設計判断｜自社データ連携を安全に進める考え方 - Conclusion Image

参考文献

  1. https://anthropic.com/engineering/april-23-postmortem
  2. https://app-liv.jp/articles/155944/
  3. https://www.itmedia.co.jp/news/articles/2604/17/news072.html
  4. https://japan.zdnet.com/article/35247263/
  5. https://www.youtube.com/playlist?list=PL2VK2ZJib1yRw1EkOiQwTN7elvOfBZazQ
  6. https://gigazine.net/news/20260513-anthropic-china-mythos/
  7. https://www.youtube.com/watch?v=YGE-OLDyeZQ
  8. https://note.com/makuring/n/nb6d5bf0aa3de
  9. https://www.youtube.com/watch?v=Pczg8sbkxMo

コメント

コメントは1週間で消えます
0 / 150
コメントを読み込み中...