MCPサーバー開発とは｜社内システム連携の始め方

本記事を読めば、自社APIや業務DBをMCPサーバー化する基本設計がわかり、AIエージェントから社内データを安全に扱う開発基盤を作れます。

AIzen株式会社は、AIエージェント開発や社内システム連携を支援する中で、MCPサーバーは単なる実装部品ではなく、業務データとAIの権限境界を定義する場所だと考えています。

本記事では、Tools・Resources・Promptsの割り当て、実装手順、トランスポート、権限設計を実務視点で整理します。

MCPサーバー開発の全体像

MCPサーバー開発とは、AIアプリケーションが外部システムやデータソースを扱えるように、操作や参照データをMCPの形式で公開する開発です。自社APIや業務DBをそのままAIに渡すのではなく、AIが安全に使える単位へ変換します。

MCPの公式仕様では、ホスト、クライアント、サーバーが分かれ、サーバーはTools、Resources、Promptsなどのプリミティブを公開します。開発者がまず理解すべきなのは、MCPサーバーは業務システムの全機能を公開するものではなく、AIに渡してよい機能だけを整理する層だという点です。

MCPサーバーの基本構造

MCPサーバーは、AIクライアントからのリクエストを受け、外部システムやデータソースにアクセスし、構造化された結果を返します。たとえば社内FAQを検索するサーバーなら、検索キーワード、カテゴリ、対象部署を入力として受け取り、該当するFAQ本文や更新日を返します。

基本構造は、MCPプロトコルのハンドラー、業務ロジック、外部システム接続、認証・認可、ログ出力に分けられます。SDKを使えばプロトコル処理の多くは隠れますが、業務ロジックと権限判定は開発者が設計する必要があります。

MCPクライアントとの関係

MCPクライアントは、Claude Code、Codex、CursorなどのAI開発環境やアプリケーション側にある接続コンポーネントです。クライアントはMCPサーバーに接続し、利用できるTools、Resources、Promptsを取得します。

開発者は、クライアントがツール一覧を見て使うことを前提に、各ツールの説明を具体的に書きます。目的が伝わる名前にしたほうが、AIも人間も扱いやすくなります。

MCPサーバーは複数のクライアントから使われる可能性があります。後からCodexや社内チャットエージェントで使うこともあるため、特定クライアントに依存しすぎない入出力設計が重要です。

社内システム連携での役割

社内システム連携におけるMCPサーバーの役割は、AIに社内データを安全に渡すことです。顧客管理、案件管理、社内FAQ、エラー監視、勤怠、請求など、業務データは多くのシステムに分散しています。

MCPサーバーを使うと、AIエージェントはそれぞれのAPI仕様を直接知らなくても、業務操作として情報を取得できます。たとえば「顧客の契約状況を確認する」「障害ログを検索する」「案件の次回アクションを抽出する」といった形です。

ただし、社内システム連携では情報区分が重要です。全データを返すのではなく、AIの判断に必要な項目だけを返す設計にします。顧客情報なら、氏名や契約プランは必要でも、支払い情報や個人メモは不要な場合があります。

MCPサーバーの機能設計

MCPサーバーの品質は、実装言語よりも機能設計で決まります。Tools、Resources、Promptsをどう割り当てるかによって、AIが実行できる操作、参照できる情報、再利用できる業務手順が変わります。

設計時は、更新処理をTools、参照データをResources、定型業務の流れをPromptsとして考えると整理しやすくなります。すべてをToolsに寄せると、操作と参照が混ざり、権限管理が難しくなります。

Toolsで扱う更新処理

Toolsは、AIアプリケーションが呼び出せる実行可能な関数です。DB検索のような読み取り処理にも使えますが、実務上はコメント投稿、ステータス変更、通知送信、レコード更新など、操作を伴う処理で特に慎重な設計が必要です。

更新系Toolsでは、操作名、入力スキーマ、実行前確認、エラー時の戻し方を決めます。たとえば案件管理でステータスを変更するToolなら、案件ID、新ステータス、変更理由、承認者IDを入力に含めます。

Tool例	目的	設計上の確認項目
create_ticket_comment	チケットへコメント投稿	投稿先、本文、投稿者、承認要否
update_deal_status	案件ステータス変更	変更可能な状態、理由、ロール制御
send_internal_notice	社内通知送信	宛先範囲、外部送信禁止、ログ保存
create_followup_task	フォロータスク作成	担当者、期限、重複チェック

更新系Toolsは便利ですが、AIが勝手に実行してよい範囲は限定します。初期導入では、更新案を作るToolと実行するToolを分けるのも有効です。

Resourcesで扱う参照データ

Resourcesは、AIが参照できるデータソースです。社内FAQ、DBスキーマ、顧客契約サマリー、プロジェクト設定、エラー分類表など、文脈として渡したい情報に向いています。

Resourcesで扱うデータは、読み取り専用で設計するのが基本です。AIが判断材料として使う情報を、必要な粒度で返します。社内FAQなら、タイトル、本文、カテゴリ、最終更新日、対象部署を返すと、回答案の根拠を示しやすくなります。

参照データでは、返却量の制御も重要です。DB全件や長大なログを返すと、AIが処理しづらくなります。検索条件、ページング、件数上限、返却フィールド制限を入れ、必要な情報だけを渡します。

Promptsで扱う定型業務

Promptsは、定型業務の指示テンプレートとして使えます。MCPの仕様上、Promptsはクライアントが発見・取得できるテンプレートであり、ユーザーが明示的に選べる形で提供されることが想定されています。

業務では、問い合わせ回答案の作成、障害一次調査、営業フォロー文面、PRレビュー観点などに使えます。たとえば「問い合わせ対応プロンプト」には、FAQを参照する、契約プランを確認する、外部送信前に人が確認する、といった手順を含めます。

Promptsを使う利点は、現場の判断基準を再利用できることです。担当者ごとのばらつきを抑え、チームで同じ業務手順を使えます。

MCPサーバーの実装手順

MCPサーバーの実装は、SDK選定、入出力スキーマ、ローカル検証、ログ確認の順で進めます。最初から複雑な社内システム全体をつなぐのではなく、1つの参照業務から小さく作るほうが安全です。

実装前に、対象業務、公開する機能、使うクライアント、認証方式、ログ保存先を決めます。ここを決めずにコードを書き始めると、後から権限や監査の修正が大きくなります。

SDK選定と開発言語

MCPサーバーは、公式SDKやコミュニティのSDKを使って実装できます。TypeScriptやPythonは導入例が多く、社内APIやDBとの接続もしやすい選択肢です。既存の社内システムがGoやC#で構築されている場合は、その言語でサーバーを作ることも検討できます。

SDK選定では、対応しているMCP仕様、Transport対応、認証実装のしやすさ、ログ出力、チームの保守体制を見ます。最新の対応状況は変わるため、公開前や導入前には公式ドキュメントで確認します。

開発言語は、AIエージェント側の都合より、社内で保守できる言語を優先します。

入出力スキーマの定義

入出力スキーマは、MCPサーバー開発で最も重要な設計項目です。AIがToolを呼ぶ際、入力パラメータの型、必須項目、説明が明確でないと、誤った呼び出しや曖昧な出力につながります。

たとえば顧客検索Toolでは、顧客名のあいまい検索を許すのか、顧客IDを必須にするのかで安全性が変わります。契約情報を返す場合も、プラン名、契約期間、担当者、制限事項など、AIの判断に必要な項目に絞ります。

出力は、人間がレビューしやすい形にします。根拠ID、取得日時、参照元、権限による省略有無を含めると、後から確認しやすくなります。

ローカル検証とログ確認

実装後は、いきなり本番データにつながず、ローカル環境や検証データで動作確認します。MCP Inspectorなどの開発ツールを使うと、一覧や呼び出し結果を確認しやすくなります。

検証では、正常系だけでなく、権限不足、対象データなし、入力不備、外部APIエラー、タイムアウトも確認します。AIエージェントは予想外の入力をすることがあるため、スキーマ検証とエラーメッセージを丁寧に作ります。

ログには、Tool名、利用者、入力の要約、結果、エラー、実行時間を残します。ただし、顧客情報や認証情報はマスキングし、保存期間も決めます。

MCPサーバーのトランスポート選定

MCPサーバーのTransportは、実行場所と利用者数で選びます。現行のMCPでは、ローカルプロセスとして動くstdioと、リモートサーバーとして動くStreamable HTTPが中心です。

SSEは過去の実装や互換用途で出てくることがありますが、新規開発では利用するクライアントと公式仕様を確認し、可能な範囲でStreamable HTTPを検討します。Transport選定は、開発しやすさだけでなく、認証、監査、チーム展開に影響します。

ローカル向けのstdio

stdioは、クライアントがMCPサーバーをローカルプロセスとして起動し、標準入出力で通信する方式です。開発者の端末上で動かすツールや、ローカルファイル、検証DB、社内CLIと連携する用途に向いています。

利点は、ネットワーク越しの公開が不要で、検証を始めやすいことです。開発初期のMCPサーバー、個人用の補助ツール、リポジトリ内の設定確認などでは扱いやすい方式です。

一方で、端末ごとの差分が出やすい点に注意します。チームで使う場合は、Node.jsやPythonのバージョン、環境変数、セットアップ手順を固定します。

複数利用向けのStreamable HTTP

Streamable HTTPは、MCPサーバーをHTTPエンドポイントとして提供する方式です。社内共通のFAQ検索、顧客管理参照、障害監視連携など、複数ユーザーや複数クライアントから使う用途に向いています。

HTTP型では、認証、TLS、アクセス元制御、監査ログを設計できます。OAuthやBearer tokenなどを使い、利用者ごとの権限判定をサーバー側で行います。

運用面では、可用性、タイムアウト、ログ保存、デプロイ手順も決めます。

SSE利用時の確認点

SSEは、過去のMCP実装や一部サーバーで使われることがあります。新規構築では、利用するクライアントがどのTransportを推奨しているかを確認し、Streamable HTTPに移行できるかを検討します。

ただし、既存のSSEサーバーをすぐ廃止できない場合もあります。その場合は、認証方式、接続維持、再接続、タイムアウト、ログ確認を明確にします。MCPサーバー側だけでなく、クライアント側がSSEをどう扱うかも確認が必要です。

本文執筆時点では仕様やクライアント対応が変わりやすいため、SSEについては断定的に扱わず、導入時点の公式情報と対象クライアントのドキュメントを確認する前提で設計します。

MCPサーバーの権限設計

MCPサーバーは、AIに業務システムを扱わせる接続口です。そのため、読み取り権限と更新権限、顧客情報の扱い、監査ログを最初から設計します。

権限設計を後回しにすると、便利なToolが増えた後で見直しが難しくなります。MCPサーバー開発では、機能追加より先に、誰が何を読めて、何を実行できるかを決めることが重要です。

読み取り権限と更新権限の分離

読み取り権限と更新権限は、Tool単位で分けます。顧客検索、FAQ参照、チケット取得は読み取り系、コメント投稿、ステータス変更、通知送信は更新系です。

初期導入では、読み取り系だけを公開するのが安全です。AIが参照結果をもとに回答案や更新案を作り、人が実行します。更新系を公開する場合は、承認フロー、取り消し手順、ログ確認を必須にします。

開発上は、同じAPIクライアントを使っていても、MCPの公開Toolを分けます。内部実装が同じでも、AIから見える操作単位を分けることで、承認やログの粒度を管理できます。

顧客情報・案件情報の取り扱い

顧客情報や案件情報は有用ですが、全項目ではなく目的に必要な項目だけを返します。

問い合わせ対応なら契約プラン、利用中機能、過去問い合わせ件数は必要でも、決済情報や個人メモは不要な場合があります。営業支援なら案件名、確度、次回アクションは必要でも、内部評価コメントは制限することがあります。

権限判定は、AIクライアント側だけに任せないことが重要です。MCPサーバー側で利用者、部署、ロール、対象データを判定し、返却内容を制御します。

監査ログと利用履歴

監査ログは、問題発生時のためだけでなく、運用改善にも使います。利用頻度、検索失敗、承認差し戻しを見れば、業務設計の改善点が見えます。

ログには、利用者、Tool名、対象ID、実行時刻、結果、エラー、承認者を残します。入力全文や返却全文を保存する場合は、個人情報や機密情報の扱いに注意します。必要に応じてマスキングや保存期間を設定します。

弊社エンジニアからのコメント：

MCPサーバー開発では、最初に万能な社内APIラッパーを作るより、読み取り専用のFAQ検索、顧客サマリー取得、案件一覧取得のように用途を絞るほうが安全です。更新系はTool名、承認者、ログ項目まで決めてから追加すると、チーム展開後の確認コストを抑えられます。

まとめ

MCPサーバー開発は、自社APIや業務DBをAIエージェントから安全に扱うための基盤づくりです。単にAPIをつなぐのではなく、Tools、Resources、Promptsの単位で業務機能を整理し、AIが使いやすく、人が監査しやすい形にします。

要点は3つです。第一に、Toolsは操作、Resourcesは参照データ、Promptsは定型業務として分けて設計することです。第二に、stdioとStreamable HTTPを用途に応じて選び、SSEは既存互換として慎重に確認することです。第三に、読み取りと更新の権限を分離し、顧客情報・案件情報・監査ログを最初から設計することです。

AIzen株式会社では、MCPサーバー開発、社内API・DB連携、AIエージェントの権限設計、運用ログ設計まで支援しています。自社データをAI活用へつなげたい場合は、まずMCP化する業務範囲の整理から無料相談で進められます。