AIに「調べて登録して」と頼んでも、社内データには届きません。Model Context Protocol（MCP）を社内システム向けに構築すれば、エージェントが外部情報の収集から自社DBへの書き込みまで一気通貫で動かせます。

この記事でわかること

  • 社内MCPが解決する課題と、エージェントネイティブ化の意味
  • WeTicket CTO Nick Vernij氏が公開した、Claudeによるキュレーション実例
  • 大規模組織が採用する社内MCPの設計パターン
  • 実務投入時に押さえるべき運用・セキュリティの要点

社内MCPが埋める「最後の1メートル」

MCP（Model Context Protocol）は、Anthropicが2024年11月にオープンソース化した接続規格です。AIアプリケーション（MCPクライアント）と外部データ・ツール（MCPサーバー）を、共通のJSON-RPCプロトコルでつなぎます。Claude Desktop、Claude Code、Cursor、VS Codeなど複数のホストが同じサーバーを共有できます。

課題は、LLMの推論力ではなく「データの所在」にあります。社内の予約管理、イベント情報、CRM、在庫DBは、モデルの学習データにも公開Webにも存在しません。従来はAPIごとに個別連携を組み、プロンプトにコピペする運用が主流でした。MCPはこの断片化を1本の規格に置き換え、ツール呼び出し・認証・エラーハンドリングをサーバー側に集約します。

Nick Vernij氏は2026年6月28日のX投稿で「社内向けMCPを構築すべきだ」と断言しています。理由は、会社をエージェントネイティブにし、生産性を上げる最短経路になるからです。彼はWeTicket（イベント主催者向けチケットプラットフォーム）のCTOであり、自身のプロダクト文脈で実装を進めています。

ClaudeがWebとMapsで調査し、MCP経由で登録する流れ

Vernij氏が公開したデモでは、Claude Sonnetが「キュレーター」として動きます。WebブラウジングとGoogle Maps MCPを使い、場所の情報を調べ、その結果を社内MCP経由で自社システムに追加します。人間が検索結果をコピーして管理画面に入力する工程が、エージェントのツール呼び出しに置き換わっています。

https://x.com/nickvernij/status/2071281661942075640

この投稿が参照する先行デモ（2026年6月25日）では、役割分担がより具体的です。Claude OpusがTebi（予約管理）とWeTicket（イベント・チケット）を統合するバックエンドとMCPサーバーを構築し、SonnetがそのMCPと会話しながらキュレーションを担当、GLM 5.2がフロントエンドを生成しています。Vernij氏本人がコードを1行も書いていない点も、エージェントネイティブな開発フローの象徴です。

https://x.com/nickvernij/status/2070227156341284865

外部情報の取得と社内データの更新が、1つの会話セッション内で連鎖する点がポイントです。Google Maps MCPは、場所検索・ルート計算・ジオコーディングなどをClaudeから直接呼び出せる仕組みで、Anthropicの公式サーバー群やコミュニティ実装（@modelcontextprotocol/server-google-mapsなど）が公開されています。一方、予約枠の確保やイベント情報の登録は、自社APIをラップした社内MCPにしか委ねられません。

大規模組織が示す社内MCPの設計指針

個人や小規模チームではローカルのstdioサーバーから始められますが、社内展開のフェーズでは「レジストリ＋クラウドホスト型」が主流です。

Pinterest Engineeringの事例では、社内クラウド上にドメイン別のMCPサーバー（Presto、Spark、Airflowなど）を配置し、中央レジストリで承認済みサーバーと接続方法を一元管理しています。レジストリのWeb UIは人間向けの発見手段、APIはAIクライアント向けのサーバー検証・権限確認に使われ、登録されていないサーバーは本番利用不可とするガバナンスが敷かれています（参考）。

Uberの事例では、10,000以上のサービスをMCP GatewayとRegistryで統制し、1,500以上の月間アクティブエージェントが週6万回超の操作を実行しています。ProtobufやThriftのIDLからMCPツール定義を自動生成するconfig-driven方式で、サービスオーナーが公開ツールと説明文を管理する仕組みです（参考）。

AWS Prescriptive Guidanceも、MCP単体ではスケールとガバナンスの課題を解決しないと指摘し、ツール設計・ホスティング・ガバナンスの3柱で戦略を組むべきだと整理しています（参考）。

実務投入で最初に決める論点

1. サーバーの粒度

Pinterestは単一の巨大サーバーではなく、ドメイン別の小さなサーバー群を採用しました。アクセス制御をサーバー単位で分け、モデルに渡すツール数を絞るためです。予約管理用、イベント管理用、社内ナレッジ用のように、業務境界で切るのが安全です。

2. ホスティング方式

ローカルstdioは実験向き、社内本番はStreamable HTTPなどのリモートトランスポートが推奨されます。Claude Codeの公式ドキュメントでも、クラウドサービス接続にはHTTPトランスポートが第一選択肢とされています（参考）。

3. 認証と権限

MCP呼び出しにはエンドユーザーのJWTとサービス間認証の二層が必要です。PinterestはレジストリAPIで「このユーザーはサーバーXを使えるか」を実行時に確認し、Spark MCPツールを特定チャンネルに限定するなど、きめ細かい制御を行っています。

4. ツール設計

Claude Codeのドキュメントが示すように、MCP接続後は「JIRAのENG-4521を実装してGitHubにPRを出して」のような自然言語指示で、複数システムを横断するワークフローが可能になります。社内MCPのツール名・パラメータ・説明文は、LLMが正しく選択できるよう、ドメインオーナーがメンテナンスする設計がUberでも採用されています。

小さく始めて社内データをエージェントに開く

Vernij氏の事例が示すのは、社内MCPが「AIの感想」ではなく「業務の自動化基盤」になる点です。外部MCP（Web、Google Maps）で情報を集め、社内MCPで自社DBに書き込む。この2層を1つのエージェントセッションに載せるだけで、調査から登録までの手作業が大幅に減ります。

最初の一歩は、最もコピペが多い業務APIを1つ選び、読み取りと書き込みの2ツールだけを持つMCPサーバーを立てることです。AnthropicはClaude Desktop向けのMCPクイックスタートと、Claude Code向けのmcp-server-devプラグインを公開しており、サーバーの雛形生成から認証設定までをガイドしています（参考）。

社内MCPは、エージェントネイティブ化のための「USB-C」です。外部の知能と社内のデータをつなぎ、Vernij氏のように「調べて、選んで、登録する」一連の実務を、エージェントに委ねられる状態を作れます。