MCPサーバーの構築手順を解説——社内ツールをAIから呼び出す実装ガイド

MCPサーバーとは何か——AIと社内ツールをつなぐ「標準プロトコル」

AIツール連携の課題——個別実装が乱立していた背景

ChatGPTやClaudeといったAIを社内システムと連携させようとすると、これまでは個別の実装が必要でした。たとえば、顧客管理システム（CRM）との連携、社内ナレッジベースへのアクセス、在庫管理ツールの呼び出しを実現するには、それぞれ専用のコードを書き、APIの仕様変更のたびに修正対応が発生していました。

連携するツールが増えるほど、保守コストは比例して膨らみます。AI側の仕様変更とツール側の仕様変更が重なれば、対応工数はさらに大きくなります。このような「個別実装の乱立」が、AI活用を検討する企業にとって現実的な障壁になっていました。

MCPが解決すること——標準プロトコルによる統一接続

MCP（Model Context Protocol：モデルコンテキストプロトコル）は、Anthropicが2024年11月に公開した、AIと外部ツールをつなぐための標準規格です。USBポートのように「接続の口を統一する」ことで、個別実装を繰り返す必要をなくすことを目的としています。

MCPに対応したツールやシステムであれば、AIからの呼び出し方法を共通化できます。新しいツールを追加する際も、MCP仕様に沿ったサーバーを用意するだけで済むため、連携先が増えても保守コストが一定の範囲に収まります。

MCPの三層構造——ホスト・クライアント・サーバーの関係

MCPは、次の三つの役割で構成されています。

• ホスト：AIとユーザーが対話するアプリケーション。ClaudeのデスクトップアプリやCursorなどが該当します。
• クライアント：ホストの内部に組み込まれ、MCPサーバーとの通信を仲介するコンポーネントです。
• MCPサーバー：社内ツールやデータベースへの接続口となるプログラムです。クライアントからの要求を受け取り、実際のシステム操作や情報取得を実行して結果を返します。

簡単に言えば、「ホストがAIの顔、MCPサーバーが社内システムへの窓口、クライアントがその二つをつなぐ橋渡し役」です。社内システムごとにMCPサーバーを用意することで、AIはホストを通じて複数の業務ツールを統一された方法で呼び出せるようになります。

MCPサーバーで何ができるか——社内システム連携の具体的なユースケース

MCPサーバーを構築することで、AIは「テキストを生成するだけの存在」から「社内システムを操作できるエージェント」へと変わります。具体的に何が実現できるのかを、業務の文脈に沿って整理します。

Tool・Resource・Promptの違いと使い分け

MCPには、AIが利用できる機能を定義する三種類の要素（Primitive）があります。それぞれの役割は以下のとおりです。

• Tool（ツール）：AIが能動的に実行するアクション。データベースへの検索クエリの発行、APIの呼び出し、ファイルの書き込みなど、副作用を伴う処理を担います。
• Resource（リソース）：AIが参照する情報源。社内ドキュメント・ログファイル・設定値など、読み取り専用のデータを提供します。
• Prompt（プロンプト）：業務に特化した指示のテンプレート。「稟議書の下書きを作成する」「障害報告書のフォーマットに沿って整理する」といった定型タスクを再利用可能な形で登録します。

意思決定者が押さえるべき点は、ToolとResourceの使い分けです。データを「取得して参照させたい」だけであればResource、「操作・更新まで行わせたい」ならToolを実装する、という基準で判断できます。

社内DBや業務APIをAIから呼び出す活用例

MCPサーバーを経由することで、AIは次のような業務処理を実行できるようになります。

• 社内データベースへの問い合わせ：在庫状況・顧客情報・売上データをAIが自然言語で検索し、担当者の質問に即答します。SQLを書けない担当者でも、会話形式でレポートを取り出せます。
• ファイルシステムの読み書き：議事録フォルダへの自動保存、テンプレートファイルの読み込みと加工といった処理を、AIが直接実行します。
• 社内APIの呼び出し：勤怠管理・経費申請・プロジェクト管理ツールが独自APIを持っている場合、MCPのToolとして登録することでAIから操作できます。

既存SaaSとのMCP連携——Slack・Notionなど公式サーバーの現状

MCPはすでに主要SaaSでの対応が進んでいます。SlackやNotionはAnthropicと連携した公式MCPサーバーを提供しており、導入企業はゼロからの実装なしにAIとの連携を始められます。たとえばSlackのMCPサーバーを接続すると、AIが指定チャンネルへのメッセージ送信や過去スレッドの検索を直接行えるようになります。

一方、自社独自のシステムや内製ツールとの連携は、公式サーバーが存在しないためカスタム実装が必要です。どの業務システムをAIに開放するかを優先度順に整理したうえで、公式サーバーの活用とカスタム構築を組み合わせる方針が現実的です。

MCPサーバー構築の全体像——作業ステップと事前に把握すべき前提

MCPサーバーの構築に着手する前に、作業全体の流れを把握しておくことが重要です。各ステップの意味と順序を理解せずに実装を始めると、設定ミスや手戻りが発生しやすくなります。ここでは、構築の全体像・技術スタックの選び方・事前に確認すべき前提条件を整理します。

構築ステップの全体フロー——5段階の作業概要

MCPサーバーの構築は、大きく以下の5段階で進みます。

1. 環境準備：Python（または TypeScript）の実行環境を整え、必要なパッケージをインストールします。
2. サーバー実装：MCP SDK を使ってサーバーの骨格となるコードを記述します。
3. ツール定義：AIが呼び出す「ツール」（＝社内システムへの操作関数）を定義します。どのような操作をAIに許可するかを、この段階で決定します。
4. クライアント設定：Claude などのAIクライアントに対して、構築したMCPサーバーの接続情報を設定ファイルへ記述します。
5. 動作確認：AIからツールが正しく呼び出されるかをテストし、エラーハンドリングや応答内容を検証します。

これらのステップは順序依存性が高く、前段階が不完全なまま次に進むと問題の切り分けが困難になります。特にツール定義とクライアント設定は互いに密接に関係するため、両者をセットで理解しておく必要があります。

PythonとTypeScript、どちらのSDKを選ぶか

MCPサーバーの実装には、公式が提供するPython SDKとTypeScript SDKの2種類が選択できます。それぞれに向くケースを以下に整理します。

• Python SDK：データ処理・機械学習ライブラリとの親和性が高く、社内のデータ基盤やAPIをPythonで管理している組織に向いています。実装の記述量が少なく、プロトタイプを素早く立ち上げやすい点も特徴です。
• TypeScript SDK：フロントエンド資産との統合や、Node.js ベースのシステムと連携する場合に適しています。型安全性が高く、開発チームがTypeScriptに慣れている場合は保守性の面で優位になります。

どちらのSDKも機能的な差異は小さく、最終的には自社のエンジニアが日常的に扱う言語を優先するのが現実的な判断基準です。本記事では、多くの企業で採用実績が豊富なPython SDKを用いた構築手順を中心に解説します。

構築前に確認すべき前提条件——Python環境・パッケージ管理

実装に入る前に、以下の前提条件を満たしているかを確認してください。

• Pythonのバージョン：Python 3.10以上が推奨されます。MCPの公式SDKが依存するライブラリの一部が、それ以前のバージョンでは動作しないケースがあります。
• パッケージ管理ツール：pipに加えて、uvまたはpoetryなどの仮想環境管理ツールを用いることで、依存関係の競合を防ぎやすくなります。
• ネットワーク・権限まわりの確認：社内システムのAPIへアクセスする場合、ファイアウォールのルールやAPIキーの発行権限を事前に整理しておく必要があります。構築後に判明すると手戻りが大きくなるため、情報システム部門との調整は早めに進めることが望ましいです。

これらの前提を整えた状態で次のステップに進むことで、実装フェーズをスムーズに進めやすくなります。

MCPサーバーの構築手順——Python SDKを使ったステップバイステップ解説

ここでは、Python SDKを使ってMCPサーバーを実際に構築する手順を順を追って解説します。コードの全体像を把握することで、開発委託時の要件定義や工数見積もりの精度を高めることができます。

Step1：SDK・依存パッケージのインストール

Python向けの公式MCP SDKは、pipコマンド一行でインストールできます。

pip install mcp

Pythonのバージョンは3.10以上が必要です。社内プロキシ環境ではpipの接続先を変更する設定が別途必要になるケースがあります。依存パッケージの管理には、仮想環境（venv）やPoetryの利用が推奨されます。

Step2：サーバーインスタンスの初期化と基本設定

SDKをインポートし、サーバーインスタンスを生成します。このインスタンスがMCPプロトコルの通信窓口になります。

from mcp.server import Server
server = Server(“social-db-mcp”)

引数に渡す文字列はサーバーの識別名です。Claude側の設定ファイルと対応させるため、用途が分かる名称にしておくと管理しやすくなります。

Step3：Toolの定義——関数・スキーマ・説明文の書き方

Toolとは、AIが「呼び出せる操作」として認識する単位です。関数本体・入力スキーマ（JSON Schema形式）・説明文の3つをセットで定義します。

社内DBへの検索クエリを発行するToolを例に示します。

• 関数名：search_customer_db
• 説明文：「顧客名または顧客IDで社内顧客データベースを検索し、基本情報と契約状況を返す」
• 入力スキーマ：query（文字列、必須）を受け取り、最大件数をオプションで指定可能

説明文はAIがToolを選択する際の判断材料になります。「何を渡すと何が返るか」を具体的に書くほど、AIが適切なタイミングでToolを呼び出しやすくなります。曖昧な説明文は誤呼び出しの原因になるため、要件定義の段階で精度を高めておくことが重要です。

Step4：サーバーの起動——STDIOトランスポートとSSEトランスポートの違い

MCPサーバーの起動方式には、大きく2種類があります。

• STDIO（標準入出力）トランスポート：ローカル環境でClaudeデスクトップアプリと通信する方式。設定がシンプルで、社内PCへの検証導入に向いています。
• SSE（Server-Sent Events）トランスポート：HTTPベースで複数クライアントからの接続を受け付ける方式。社内サーバーへの集中配置や複数部門での共有運用を想定する場合に適しています。

最初の検証はSTDIOで行い、本番運用に向けてSSEへ移行するという段階的なアプローチが現実的です。

Step5：動作確認——MCP Inspectorでのローカルテスト

Anthropicが提供する開発ツール「MCP Inspector」を使うと、ブラウザ上からToolの呼び出しをシミュレーションできます。Claude本体に接続する前の段階で、定義したToolが期待通りに動作するかを確認できるため、デバッグコストを抑えられます。

npx @modelcontextprotocol/inspector python server.py

起動後はlocalhost上のUIからToolの一覧確認・引数の入力・レスポンスの検証が行えます。スキーマの不整合や説明文の記述ミスは、この段階で大半を発見できます。

ClaudeへのMCP接続設定——claude_desktop_config.jsonの書き方

MCPサーバーを構築しても、AIクライアント側に接続設定を行わなければ実際には呼び出せません。Claude Desktopの場合、claude_desktop_config.jsonというファイルに接続先の情報を記述することで、ClaudeがMCPサーバーを認識できるようになります。

claude_desktop_config.jsonの構造と各フィールドの意味

設定ファイルの基本構造は以下のとおりです。

• command：MCPサーバーを起動するための実行コマンド。Pythonスクリプトであれば「python」、Node.jsであれば「node」を指定します。
• args：commandに渡す引数の配列。スクリプトのファイルパスをここに記述します。
• env：環境変数の指定。APIキーやデータベース接続文字列など、外部に公開したくない認証情報をここに設定します。

たとえば社内ナレッジ検索用のサーバーであれば、commandに「python」、argsに「[“/opt/mcp/knowledge_server.py”]」、envにAPIキーを記述する形になります。

複数MCPサーバーを並行して登録する方法

claude_desktop_config.jsonでは、mcpServersオブジェクト内に複数のキーを並べることで、複数のサーバーを同時に登録できます。たとえば「knowledge」「crm」「schedule」といった名前を付けてそれぞれ定義すれば、Claudeは用途に応じて対象のサーバーを自動的に呼び分けます。各サーバーのcommand・args・envは独立して設定できるため、異なる言語やランタイムで構築したサーバーを混在させることも可能です。

設定が反映されないときに確認すべきポイント

「設定を変えたのにClaudeがツールを認識しない」というケースでは、以下を順番に確認してください。

1. Claude Desktopを再起動しているか：設定ファイルはアプリ起動時に読み込まれるため、変更後は必ず再起動が必要です。
2. ファイルパスに誤りがないか：argsに記述するパスは絶対パスで指定することを推奨します。相対パスは実行環境によって解釈が変わるため、原因の特定が困難になります。
3. JSONの構文エラーがないか：末尾カンマや括弧の閉じ忘れなど、軽微な記述ミスでファイル全体が無効になります。JSONバリデーターで事前に確認する習慣をつけておくと安全です。
4. envに設定した認証情報が正しいか：APIキーの誤記やスペースの混入は、サーバー起動後に認証エラーとして現れるため、ログを併せて確認します。

設定ファイル自体はテキストファイルであるため、変更履歴をGitで管理しておくと、どの変更後から問題が発生したかを追跡しやすくなります。

社内システム連携を本番運用に乗せるために——セキュリティと運用設計の論点

PoCで動作確認が取れても、本番環境への移行には別の準備が必要です。「試作はできたが、本番に上げる前に何を整えるべきか」——この問いに答えるために、セキュリティと運用設計の主要な論点を整理します。

認証・認可の設計——誰がどのToolを呼べるかを制御する

MCPサーバーが公開するToolは、呼び出せる操作の範囲そのものです。社内システムに接続する以上、「誰が・どのToolを・どの権限で呼べるか」を制御する仕組みが不可欠になります。

具体的には、RBAC（Role-Based Access Control：ロールベースアクセス制御）の考え方を適用します。たとえば営業担当者はCRMの参照Toolのみ利用可、システム管理者はレコードの更新Toolまで利用可——といった役割ごとの制御です。MCPサーバー側でリクエストに含まれるユーザー情報やトークンを検証し、Tool実行前にロールチェックを挟む実装が現実的です。

シークレット管理——APIキーをコードに書かないための設計

社内システムへのアクセスに必要なAPIキーやパスワードをソースコード内にハードコードすることは、セキュリティ上のリスクになります。Gitリポジトリに誤ってコミットされたシークレットが外部に漏れるケースは少なくありません。

対策として有効なのが環境変数による管理です。本番環境ではAWS Secrets ManagerやHashiCorp Vaultといったシークレット管理サービスからランタイムに値を注入する構成が標準的です。開発環境では.envファイルを使い、.gitignoreで確実に除外します。コードとシークレットを分離する原則を徹底することが重要です。

ログ・監査設計——AIが何を呼び出したかを追跡可能にする

AIがどのToolをいつ・どのパラメータで呼び出したかを記録することは、インシデント発生時の原因調査だけでなく、コンプライアンス対応においても重要です。

MCPサーバーの本番運用では、以下の情報を構造化ログとして記録する設計を推奨します。

• 呼び出されたTool名と入力パラメータ
• 実行ユーザーまたはセッションの識別子
• 実行日時とレスポンスのステータス
• エラー発生時のスタックトレース

ログはアプリケーション内に閉じず、CloudWatch LogsやDatadogなどの集中ログ管理基盤に転送し、一定期間の保持と検索性を確保することが望ましいです。

オンプレ社内システムへのアクセス経路設計

クラウド上で動作するMCPサーバーがオンプレミスの社内システムに接続する場合、ネットワーク経路の設計が必要になります。主な選択肢は2つです。

VPN経由の接続は既存のVPN基盤を活用できるため、導入コストを抑えやすい反面、VPNゲートウェイがボトルネックになるケースがあります。ゼロトラストネットワークアクセス（ZTNA）を採用する場合は、ユーザーやデバイス単位で接続を制御できるため、MCPサーバーからのアクセスを細かく制限しやすい利点があります。

どちらを選ぶかは既存のネットワーク構成や情報セキュリティポリシーに依存しますが、「MCPサーバーがアクセスできる内部リソースの範囲を最小化する」という原則は共通です。必要なエンドポイントのみを許可リストで管理し、過剰な権限を与えない設計が本番運用の基本姿勢になります。

MCPサーバー構築で陥りやすい失敗パターンと対処法

MCPサーバーの構築手順そのものは比較的シンプルです。しかし実務では、動作はするものの「AIが意図通りにToolを呼び出してくれない」「本番環境でサーバーが落ちてもエラーの原因が追えない」といった問題が頻発します。以下に、現場で起きやすい失敗パターンと対処法を整理します。

Tool説明文が曖昧だとAIが正しく呼び出せない——記述のコツ

MCP ツール実装において見落とされがちなのが、Tool定義のdescription（説明文）の質です。AIモデルはToolを選ぶ際に、ツール名とdescriptionを読んで「このToolを使うべきか」を判断します。つまり、descriptionが曖昧であれば、AIは正しいToolを選べません。

たとえば description: "データを取得する" と書いた場合、類似するToolが複数あると、AIはどれを呼ぶべきか判断できず、誤ったToolを呼び出すか、呼び出し自体を諦めるケースがあります。対処法は、「いつ・何のために使うToolか」を一文で明示することです。"社員番号を引数に取り、人事システムから当該社員の所属部署と役職を返す" のように、入力・目的・出力を端的に記述してください。

スキーマ定義ミスと型エラーへの対処

inputSchemaの型定義ミスも、MCPサーバー構築でよく起きるトラブルです。たとえば、数値を受け取るべきパラメータを "type": "string" と定義していると、AIが文字列として値を渡してしまい、処理内部で型エラーが発生します。

対処としては、スキーマ定義後に必ずダミー入力で動作確認を行うことが有効です。また、Toolの実装側でも型変換処理を入れておくと、定義のズレによる障害を抑えられます。

タイムアウト・エラーハンドリングの設計漏れ

本番運用を見据えたMCPサーバー構築では、タイムアウトとエラー応答の設計が欠かせません。外部APIや社内システムへの接続が遅延した場合に、Toolが応答を返さないまま止まると、AI側のセッションごとハングアップするケースがあります。

また、サーバーがクラッシュしてもAI側のUIにはエラーメッセージが出ないことが多く、原因の特定が困難になります。対処としては以下を設計段階で組み込んでおくことが重要です。

• 全Toolに接続タイムアウト値を明示的に設定する
• エラー発生時はAIが解釈できるメッセージ形式（例：{"error": "接続タイムアウト：3秒超過"}）で返す
• サーバーのクラッシュログを外部監視ツールで補足する

これらは後付けで対応しようとすると改修コストがかかるため、初期設計の段階で盛り込んでおくことが望ましいです。

自社構築vs外部委託——意思決定者が判断するための比較整理

MCPサーバーの構築手順を把握したうえで、次に判断が必要になるのが「自社で構築するか、外部に委託するか」という選択です。技術的な難易度だけでなく、社内リソースの状況・セキュリティ要件・スピード感によって、最適な進め方は異なります。

内製が向くケース・委託が向くケースの比較

以下の比較表を判断の出発点として活用してください。

• 内製が向くケース：Python等の開発リソースが社内にある、段階的に機能を拡張していきたい、外部にソースコードを開示したくない
• 委託が向くケース：既存の社内システムとの連携設計が複雑、セキュリティ要件が厳しく設計レビューが必要、早期にPoC（概念実証）を動かして効果検証したい

特に、ERPや基幹システムとの社内システム連携を伴うMCPサーバー構築では、API仕様の整理・認証フローの設計・エラーハンドリングの作り込みなど、開発以外の設計工数が想定以上にかかるケースが少なくありません。こうした場面では、内製にこだわることで逆にリードタイムが延びるリスクがあります。

MCPを活用したAI組み込み開発をCLANEに依頼する場合の進め方

CLANEは、LLM（大規模言語モデル）と社内システムを接続するAI組み込み開発を手がけています。依頼から着手までの流れは、概ね以下のステップになります。

1. 要件ヒアリング：連携対象のシステム・利用シーン・セキュリティ要件を整理します
2. 構成設計：MCPサーバーの構築方針・ツール定義・認証方式を提案します
3. PoC開発：小さな範囲で動作を確認し、業務フィットを検証します
4. 本番実装・運用設計：スケーラビリティとセキュリティを考慮した設計で本番環境に展開します

MCPサーバー構築を自社で進めるか外部に委託するかの判断は、技術力だけでなく、連携するシステムの複雑さと求められるスピードを軸に検討することが実態に即しています。

まとめ——MCPサーバー構築の要点と次のアクション

本記事で解説したMCPサーバー構築の要点を、意思決定の判断材料として以下に整理します。

• MCPの役割：AIと社内ツールをつなぐ標準プロトコルです。個別のAPI連携を都度開発する手間を省き、ツール追加時の拡張性を高めます。
• 構築ステップ：Python SDKによるサーバー実装、claude_desktop_config.jsonへの接続設定、動作確認の順に進めます。ローカル環境であれば小規模なPoCは1〜2日程度で着手できます。
• セキュリティ設計：認証・認可（RBACによるアクセス制御）、通信経路の暗号化、ログ設計は本番運用前に必ず整備が必要です。後付けでの対応はコスト増につながるため、設計段階での組み込みが前提になります。
• 失敗パターン：PoC環境と本番環境のギャップ、スキーマ設計の甘さ、エラーハンドリングの省略が主な要因です。仕様の詰めが浅い段階で本番移行すると手戻りが大きくなります。
• 自社構築vs外部委託：社内にPython経験者がいてPoC検証が目的なら自社構築が現実的です。本番運用・セキュリティ要件が厳しい場合は外部委託の検討が合理的です。

次のアクションは、現状の課題感によって異なります。「まず仕組みを試したい」場合はローカル環境でのPoC着手が最初の一歩です。「本番運用を見据えて要件を固めたい」場合は、連携対象のシステム一覧・認証方式・セキュリティポリシーを社内で整理するところから始めると、その後の判断がスムーズになります。