社内システムをAIエージェントにつなぐMCPサーバー自作ガイド｜公開範囲・トランスポート・権限の設計判断【2026年8月版】

執筆: 武石幸之助（x3d株式会社 代表取締役）
公開日: 2026年7月28日
最終更新日: 2026年8月5日

【結論】MCPサーバーの自作とは、社内システムをAIから呼び出せる形に変換する接続プログラムを、自社の要件に合わせて実装することです。

• 自作が必要になる境界は「既製のMCPサーバーが存在しない社内DB・基幹システム・独自SaaS」の3領域
• 実装の前に決める設計判断は3つ。公開範囲（tools / resources / prompts）・トランスポート（stdio / Streamable HTTP）・権限設計
• 2026年8月時点の現行仕様（Current）は 2026-07-28。ステートレス化済みのため、これから作るサーバーは現行仕様を基準に設計する

この記事では、自社システムをAIエージェントから使えるようにしたい開発者・情報システム部門向けに、コードを書き始める前に決めるべき設計判断と、社内展開までの進め方を解説します。

---

※本記事はMCPサーバーの「設計判断」（公開範囲・トランスポート・権限）に焦点を当てています。仕組みの基礎解説はMCPサーバーとは？（x3d 公式ガイド）、実装6ステップはMCPサーバーの作り方、Claude Codeからのクライアント側連携手順はClaude CodeでMCP連携する方法にまとめています。

MCPサーバーの自作とは — 既製で足りなくなる境界線

MCPサーバーの自作とは、社内システムをAIから呼び出せる形に変換する接続プログラムを、自社の要件に合わせて実装することです。MCP（Model Context Protocol）は、AIアプリケーションと外部のツール・データソースを接続するオープン標準で、サーバー側が「ツール（tools）」「リソース（resources）」「プロンプト（prompts）」を公開し、クライアントがそれを発見して呼び出します。

重要なのは、自作が必要になるのは限られた領域だけだという点です。GitHub・Notion・Sentry・Stripe などの主要SaaSは、提供元自身が公開する first-party のMCPサーバーを利用できます。検証済みサーバーは公式のMCPレジストリ（registry.modelcontextprotocol.io、2025年9月8日からプレビュー提供）で検索できます。自作の判断が必要になるのは、次の3領域に限られます。

逆に言えば、既製サーバーが存在する接続先を自作するのは工数の無駄です。x3dの支援現場でも、最初に「既製で済む接続先」と「自作が必要な接続先」を仕分ける工程を必ず挟みます。既製と自作の使い分け基準はMCP連携で何ができるのか（ユースケースと選定基準）で詳しく整理しています。

設計の前に：2026年8月時点の仕様バージョンを確認する

MCPの仕様は日付形式（YYYY-MM-DD）でバージョン管理され、後方互換性を壊す変更があったときだけ更新されます。ここを確認せずに設計を始めると、公開直後に作り直しになります。

2026年8月5日時点の状況を、公式の versioning ページとGitHubリリース履歴で確認すると次のとおりです（出典: modelcontextprotocol.io/specification/versioning）。

現行リビジョン 2026-07-28 は、公式ブログで「launch 以来で最大のリビジョン」と位置づけられており、サーバー設計に直接影響します（出典: The 2026-07-28 Specification）。主な変更は、initialize ハンドシェイクと Mcp-Session-Id ヘッダの廃止（ステートレス化）、Streamable HTTP での Mcp-Method / Mcp-Name ヘッダ必須化、一覧結果への ttlMs / cacheScope 付与、W3C Trace Context による分散トレース伝搬の明記、Roots / Sampling / Logging の非推奨化（削除までは最低12か月の猶予）です。

設計上の実務的な結論は2つです。第一に、アプリケーション側の状態をプロトコルのセッションに依存させないこと。状態を持ち越す必要があるなら、ツールの戻り値として明示的なID（例：basket_id）を返し、モデルに次の呼び出しで渡させる設計にします。第二に、スティッキーセッション前提のインフラ設計を避けること。ステートレス化後は、通常のラウンドロビン負荷分散で水平スケールできます。

なお、MCPは2025年12月9日にAnthropicからLinux Foundation傘下の Agentic AI Foundation（AAIF）へ移管され、Apache License 2.0 のもとで運営されています。単一ベンダーの事業判断で仕様が変わる構造ではなくなったため、社内の技術選定で「標準として長期採用できるか」を判断しやすくなっています。

設計判断①：AIに何を公開するか（tools / resources / prompts）

MCPサーバーが公開できる要素は3種類あります。切り分けを最初に決めないと「とりあえず全部ツールにする」設計になり、AIが正しいツールを選べなくなります。

実装の入口としては、tools を1〜3個だけ定義した最小構成から始めるのが定石です。resources と prompts は「必要になってから足す」で問題ありません。

ツール定義で成否を分けるのは、コードよりも説明文（description）と入力スキーマの設計です。AIはツール名と説明文を読んで呼び出すかどうかを判断するため、説明文が曖昧だと呼ばれない、あるいは誤って呼ばれます。「顧客名の一部で社内DBを検索する。完全一致は不可」のように、できること・できないことを両方書くのが実務的です。この「AIに渡す情報の設計」という観点は、より広くはコンテキストエンジニアリングの領域と重なります。

設計判断②：トランスポートをstdioかStreamable HTTPで選ぶ

MCPの標準トランスポートは2種類です。HTTP+SSE は2025年3月のリビジョンで非推奨化されているため、新規実装での選択肢は実質的に stdio と Streamable HTTP の二択になります。

判断の順序としては、まず stdio でPoCを作り、使われることが確認できてから Streamable HTTP に移すのが安全です。Streamable HTTP で公開すると認可設計・監査ログ・レートリミットの実装が同時に必要になり、「そもそも使われるのか」の検証と「安全に公開する」実装を並走させることになるためです。

ただし、stdio 前提で作ったサーバーをそのままHTTPで公開するのは典型的な事故パターンです。stdio ではOrigin検証やトークン検証が不要なため、公開時にその実装が抜けたまま外部到達可能になります。移行時は認可を実装する前提でコードを分離しておきます。

設計判断③：認証・権限・監査を最初から設計に含める

MCPサーバーは「AIが業務システムを操作する経路」になるため、権限設計を後回しにすると、公開後に作り直すことになります。設計に含めるべき要素は4つです。

1. 最小権限（誰の権限で実行するか）
MCPサーバーが単一のサービスアカウントで動くと、AIを使う全員が同じ権限を持ちます。人事データや原価情報を扱う場合、これは許容できません。実行者の権限を引き継ぐ設計（利用者のトークンで下流APIを呼ぶ）か、ツール単位で参照範囲を絞る設計のいずれかを選びます。

2. 認可（Streamable HTTP の場合）
現行仕様では OAuth 2.1 + PKCE、Resource Indicators（RFC 8707）、Protected Resource Metadata（RFC 9728）が要件です。現行の 2026-07-28 リビジョンでは認可が強化され、クライアントは認可レスポンスの iss パラメータを RFC 9207 に従って検証することが求められます。1つのクライアントが多数のサーバーに接続するMCPの利用形態で起きやすい mix-up 攻撃への対策です。

3. 監査ログ（何を残すか）
「いつ・誰が・どのツールを・どの引数で呼び、何が返ったか」を残します。粒度が足りないと問題を追跡できません。引数や戻り値には機密情報が入るため、マスキング方針をログ設計と同時に決めます。

4. 破壊的操作のガード
削除・送金・外部送信などの不可逆な操作は、公開前に「人の承認を挟むか」を決めます。承認フローの設計はHuman in the Loop（HITL）が出発点になります。外部から取り込んだテキストがツールを誤発火させるプロンプトインジェクションの対策も、この段階で設計に含めます。

組織の運用ルールに落とす段階では、総務省・経済産業省の「AI事業者ガイドライン」が参照点になります。2026年3月31日に第1.2版が公表され、AIエージェントに関する定義とリスクの記述が追記されました。法的拘束力のないソフトローですが、国内で事実上の標準として機能しています。

最小実装から社内展開までの流れと、つまずく5つのポイント

公式SDKを使えば、プロトコル層（JSON-RPC 2.0）の実装はSDKが吸収します。開発者が書くのは、ツール名・説明文・入力スキーマ・実行ロジックだけです。modelcontextprotocol の GitHub Organization には、2026年7月時点で TypeScript・Python・Java・Kotlin・C#・Go・Rust・Swift・Ruby・PHP の10言語のSDKリポジトリが公開されており、既存の社内システムと同じ言語を選べるケースが多くなっています。

擬似コードで表すと、最小構成のサーバーは次の構造になります。

サーバーを生成（名前・バージョンを宣言）

ツールを1つ登録:
  名前        = "search_customers"
  説明        = "顧客名の一部で社内顧客DBを検索する（完全一致検索は不可）"
  入力スキーマ = { query: 文字列, 上限件数: 整数（既定20） }
  実行処理    = 既存の社内DB検索ロジックを呼び、結果をテキストで返す
              （実行者の権限で検索し、閲覧不可の列はマスクする）

トランスポートを選んで待ち受け開始（PoC段階では stdio）

※構造を示す擬似コードです。SDKのAPIはバージョンにより変わるため、実装時は公式SDKドキュメントを参照してください。

社内展開までの流れは、5フェーズで進めるのが現実的です。

社内展開で頻出するつまずきは、次の5つです。

• ツールが多すぎてAIが選べない：1サーバーに20個も並べると誤選択が増えます。業務単位でサーバーを分けます
• スキーマ変更で既存の使い方が壊れる：引数名を変えると、それを前提にしたプロンプトや手順書が動かなくなります
• 監査ログの粒度が足りない：「呼ばれた」だけでは問題を再現できません。引数と結果の要約まで残します
• 権限が実質的に全開になっている：サービスアカウント1つで動かすと、参照権限のない情報までAI経由で見えます
• PoCの成功を本番の成功と誤認する：運用フェーズで必要になる観測・コスト・権限の設計はAIエージェントを本番運用するための基盤設計で解説しています

MCPサーバーの自作は、AIエージェント開発全体の一部です。エージェント側の設計を含む進め方はAIエージェントの作り方、開発フロー全体のAI化はAI駆動開発（AIDD）を参照してください。技術判断と組織設計を切り分ける枠組みとしては4層理論が指針になります。

よくある質問（FAQ）

---

参考文献・出典

• Model Context Protocol — Versioning（公式仕様バージョン一覧）（2026年8月5日確認：Current は 2026-07-28）
• The 2026-07-28 Specification — Model Context Protocol Blog
• modelcontextprotocol/modelcontextprotocol — Releases（リビジョン履歴）
• Introducing the MCP Registry — Model Context Protocol Blog（2025年9月8日）
• modelcontextprotocol — GitHub Organization（公式SDKリポジトリ一覧）
• 総務省「AI事業者ガイドライン」掲載ページ（第1.2版・令和8年3月31日公表）
• Linux Foundation Announces the Formation of the Agentic AI Foundation

本記事は2026年8月時点の公開情報に基づいています。MCPの仕様は更新が速いため、最新情報はmodelcontextprotocol.ioをご確認ください。

---

武石幸之助
x3d株式会社 代表取締役。2017年より企業のAI導入支援に従事し、これまで1,800社超の法人支援、5,000名超の研修登壇実績を持つ（受講満足度99%／2024年度研修アンケート）。AIエージェント・MCP連携の設計から社内定着までを一貫して支援し、技術実装と組織設計の両面から企業のAI活用を伴走している。

---

x3d株式会社では、本記事で解説したMCPサーバーの設計・構築・運用定着に関する企業研修・導入支援を提供しています。
まずはお気軽にご相談ください。

→ 無料相談・お問い合わせはこちら