メーカーのためのMCP実践ガイド

MCPとは何か、平たく言えば

Model Context Protocolとは、AIアシスタントが他社のシステムを呼び出し、型付けされた構造化データとして回答を受け取るための、標準的な方法である。

Anthropicは2024年11月25日にこれをオープンソースとして公開し、「AIアシスタントを、データが存在するシステムに接続するための新しい標準規格」と説明した。2025年12月9日、AnthropicはMCPをAgentic AI Foundationへ寄贈した。これはLinux Foundation傘下の指定基金で、BlockおよびOpenAIと共同で設立され、AWS、Bloomberg、Cloudflare、Google、Microsoftがプラチナ級で支援している。その時点でMCPは、SDKの月間ダウンロード数9,700万件、公開サーバー数1万件超を突破しており、ChatGPT、Claude、Cursor、Gemini、Microsoft Copilot、VS Codeが一級のクライアントサポートを提供していた。

開発者ではない意思決定者にとって重要な区別は、次の点にある。アシスタントが自社のWebサイトを読むとき、それは文書を解釈している。表を読み違えることも、脚注を見落とすことも、二つの派生品を混同することもある。アシスタントが自社のMCPサーバーを呼び出すとき、それはシステムに問い合わせている。部品を指定して要求し、フィールドを受け取り、それをそのまま報告する。前者のやり方はもっともらしい答えを生む。後者は正しい答えを生む——ただし、その背後にあるデータが正しければの話であり、実際の作業の大半はそこに存在する。

この業界で、すでに公開しているのは誰か

これはもはや机上の話ではなく、事例も参考になる程度に多様である。

• Microchip Technologyは2025年11月6日、無償かつ公開のMCPサーバーを立ち上げた。検証済みの製品仕様、データシート、在庫、価格、リードタイムをMCPのStreamable HTTP経由で公開し、コパイロット、チャットボット、企業向けエージェントを想定したJSON形式のレスポンスを返す。
• Siemensはmcp.siemens.comで公開サーバーを運用しており、ドキュメント化されたプラグイン——アセット、開発者ポータル、検索、Webコンテンツ——を認証なしで利用できる。
• Zoovuは2025年12月11日にMCPサーバーを公開し、統制された製品データへのアクセスをエージェントに提供している。互換性や用途に関する問い合わせでの正確性を訴求点としている。
• ECIAは2026年6月11日にTrustedParts.comのInventory AI Agent Serviceを開始し、正規流通の電子部品在庫をMicrosoft Copilot、ChatGPT、Claudeの中から参照できるようにした。
• Shopifyは各ストアのhttps://{shop}.myshopify.com/api/mcpでStorefront MCPサーバーを公開している。ツールにはsearch_catalog、lookup_catalog、get_productなどがあり、ストアフロント層では認証を必要としない。

注目すべき共通点が二つある。いずれも、既存の権威あるデータストアの上に載っていること。そしていずれも、公開カタログデータと、商業的に機微な情報とのあいだに線を引いていることだ。

ツールかリソースか——部品サーバーはどちらを使うべきか

仕様は両者の違いを明確に定めており、ここを取り違えると、モデルがうまく使えないサーバーができあがる。

ツールはモデル制御である。 仕様は、ツールは「モデル制御であるように設計されており、言語モデルが文脈の理解とユーザーのプロンプトに基づいて、自動的にツールを発見し呼び出せることを意味する」と述べている。発見はtools/list、呼び出しはtools/callである。各ツールはinputSchema（既定ではJSON Schema 2020-12）と、任意でoutputSchemaを持ち、そのスキーマに準拠したstructuredContentを返す。

リソースはアプリケーション主導である。 仕様は、リソースは「アプリケーション主導であるように設計されており、ホストアプリケーションが自らの必要に応じて、コンテキストの取り込み方を決定する」と述べている——典型的にはピッカー、一覧、あるいはホストによる自動的な取り込みという形をとる。各リソースはURIで識別され、テンプレートによってパラメーター付きのURIも扱える。

カタログはクエリ空間であって、固定された文書の集合ではない。4万点の部品が並ぶリソースピッカーをスクロールしたい人はいない。したがって部品サーバーの大半はツールで構成すべきであり、そこに二つの工夫を加える。大きなペイロードを埋め込むのではなく、resource_linkコンテンツブロックでデータシートやCADファイルを指し示すこと。そして、真の意味でのリソースは、分類辞書や変更履歴といった、数の限られた安定した文書のために取っておくことだ。

現行仕様の細部のうち、注意を払う価値のあるものが二つある。ツール一覧は接続ごとに変化してはならないが、リクエストで提示された認可に応じて変化してもよい。また、サーバーはツールを決定的な順序で返すべきである。順序が安定していればクライアントは一覧をキャッシュでき、プロンプトキャッシュのヒット率も上がるからだ。

2026-07-28仕様で何が変わったのか

この改訂はトランスポートの形を作り変えた。2025年の資料をもとに書かれた設計は、いくつかの具体的な点で誤りになる。

トランスポートの形は、いまや心地よいほど退屈なものになった。サーバーはPOSTを受け付ける単一のMCPエンドポイント——たとえばhttps://example.com/mcp——を公開する。JSON-RPCのリクエストは、それぞれが独立したPOSTである。クライアントはapplication/jsonとtext/event-streamの両方を列挙したAcceptヘッダーに加えて、MCP-Protocol-Versionヘッダーを送らなければならない。その値はボディの_metaの値と一致していなければならず、一致しなければサーバーは400とHeaderMismatchエラーで拒否しなければならない。サーバーはOriginヘッダーを検証し、それが存在していて不正な場合には403を返さなければならない。

インフラ担当チームにとっての実務上の帰結はこうだ。プロトコルレベルのセッションが存在しないため、MCPサーバーは、他のステートレスなHTTPサービスと同じように、素のラウンドロビン方式のロードバランサーの背後に配置できる。Roots、Sampling、Loggingは最低12か月の猶予期間を伴って非推奨となり、旧来のHTTP+SSEトランスポートも正式に非推奨となった。

OAuthで価格と在庫をどう保護するか

MCPにおいて認可は任意である。これは部品サーバーにとって、まさに適切な設計だ。公開カタログにトークンは一切必要なく、商業的に機微なツールだけが認証を要求すればよい。

実際に実装する場合、要件は具体的である。MCPサーバーは、OAuth 2.1のIETFドラフトに従うOAuth 2.1リソースサーバーとして振る舞う。Protected Resource Metadata（RFC 9728）を実装しなければならず、クライアントは認可サーバーの発見にそのメタデータを使わなければならない。クライアントはResource Indicators（RFC 8707）を実装しなければならず、認可リクエストとトークンリクエストの双方で、自社サーバーの正規URIを示すresourceパラメーターを送る。そしてサーバー側は、トークンが自らを想定audienceとして発行されたものであることを検証しなければならない。認可サーバーはRFC 9207に従ってissパラメーターを返すべきであり、クライアントはそれを検証しなければならない。Dynamic Client Registrationは現在、Client ID Metadata Documentsに取って代わられて非推奨となったが、後方互換のために引き続き利用できる。

販売代理店やメーカーにとって有効なパターンは、次のとおりである。

1. 01未認証の層——仕様、パラメトリック検索、代替品、コンプライアンス文書、CADリンク、そして公開しているなら定価。
2. 02認証済みの層——契約価格、顧客ごとの在庫状況、見積作成。403とerror="insufficient_scope"で認証を要求し、必要なスコープを明示する。そうすればクライアントは、何往復もせず一度の往復で権限を引き上げられる。
3. 03顧客識別子をツール引数に入れ、それだけをアクセス制御とすることは決してしてはならない。ハンドルは名前であって権限ではない。認可は呼び出しのたびに検証すること。

部品向けMCPサーバーは何を公開すべきか

ツールは6〜8個というのが、妥当な規模感である。それを超えると、モデルによるツール選択の精度が落ちる。

ツールの定義は、取り立てて特別なものには見えないはずだ。そして、それこそが要点である。

{
  "name": "search_parts",
  "title": "Parametric part search",
  "description": "Search the catalog by product class and typed parameter constraints. Returns matching parts with their key parametrics, units and last-verified date. Use get_part for the full record.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "product_class": { "type": "string", "description": "ETIM class code or class name" },
      "constraints": {
        "type": "array",
        "items": {
          "type": "object",
          "properties": {
            "parameter": { "type": "string" },
            "operator": { "type": "string", "enum": ["eq", "gte", "lte", "between", "in"] },
            "value": {},
            "unit": { "type": "string" }
          },
          "required": ["parameter", "operator", "value"]
        }
      },
      "limit": { "type": "integer", "default": 20 }
    },
    "required": ["product_class"],
    "additionalProperties": false
  }
}

この説明文が果たしている役割に注目してほしい。そのツールが何を返すかをモデルに伝え、さらに、どんなときに別のツールを使うべきかまで伝えている。この一つの習慣は、スキーマをどれだけ磨き上げるよりも、回答の品質に効く。

実例で追ってみる

テキサスにある受託製造メーカーの設計エンジニアが、ドイツの盤メーカーにも出荷している基板上で、生産終了になる部品を置き換えようとしている。アシスタントには、そのメーカーのMCPサーバーが接続されている。

エンジニア: 降圧段に使っている60 VのNチャネルMOSFETが生産終了になる。同じパッケージでそのまま置き換えられる品種で、ゲート駆動10 VでのR_DS(on)が12ミリオーム以下のものがほしい。それと、本当に入手できるのかどうかも知りたい。

アシスタントは4回の呼び出しを行う。

→ tools/call  get_part
   { "part_number": "XYZ-60N12-D2PAK" }
← structuredContent
   { "package": "D2PAK", "vds_v": 60, "rds_on_mohm": 11.5,
     "vgs_meas_v": 10, "lifecycle": "EOL", "last_verified": "2026-08-04" }

→ tools/call  find_alternates
   { "part_number": "XYZ-60N12-D2PAK", "basis": "form_fit_function" }
← structuredContent
   [ { "part_number": "XYZ-60N10-D2PAK", "equivalence": "drop-in",
       "rds_on_mohm": 9.8, "differences": ["lower R_DS(on)", "higher Qg"] },
     { "part_number": "XYZ-60N14-D2PAK", "equivalence": "footprint",
       "rds_on_mohm": 13.5, "differences": ["exceeds R_DS(on) limit"] } ]

→ tools/call  get_availability
   { "part_numbers": ["XYZ-60N10-D2PAK"] }
← 403 Forbidden
   WWW-Authenticate: Bearer error="insufficient_scope",
     scope="stock:read", resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"

   [client performs step-up authorisation, then retries]

← structuredContent
   { "part_number": "XYZ-60N10-D2PAK",
     "stock": [ { "location": "US-TX", "qty": 14200 },
                { "location": "DE-BW", "qty": 3800 } ],
     "lead_time_weeks": 8, "as_of": "2026-08-09T06:12:00Z" }

→ tools/call  get_compliance_documents
   { "part_number": "XYZ-60N10-D2PAK", "types": ["rohs", "reach"] }
← content: [ { "type": "resource_link", "uri": "https://…/rohs-2026-03.pdf",
               "name": "RoHS declaration (issued 2026-03-11)" } ]

そのうえでアシスタントはこう答える。候補の一つはそのまま置き換えられる品種で、オン抵抗はより低く、ゲート電荷はより大きいので、ゲートドライバーとの整合を確認する価値がある。二つ目はフットプリントは合うが、R_DS(on)の上限を満たさない。在庫は今朝の時点でテキサスに14,200個、バーデン＝ヴュルテンベルクに3,800個、リードタイムは8週間。RoHSとREACHの宣言書は、発行日とともに添付されている。

ここに書かれていることは、エンジニアリングとしては何ら目を見張るものではない。目を見張るのは商取引としてである。三つの調達判断が、人間が一度もブラウザを開くことなく下され、しかもすべての数値が、タイムスタンプ付きのレコードまで遡って確認できる。

いま実際に自社サーバーへ到達できるのは誰か

この点は取締役会に正直に伝えたほうがよい。答えは、ベンダー資料の多くがほのめかしているよりも、ずっと狭いからだ。

つまりMCPが届くのは、自分でアシスタントを設定するエンジニアと、情報システム部門が自社サーバーを登録した法人の購買担当者である。Webの尺度で見れば小さな母数だが、営業パイプラインの尺度で見れば、きわめて大きな母数だ。

エージェントはどうやってサーバーを見つけるのか

DNSレベルの発見手段は存在しない。仕組みは三つある。

1. 01公式のMCPレジストリ。registry.modelcontextprotocol.ioにあり、一般公開されたサーバーのメタデータを集約する中央リポジトリで、Anthropic、GitHub、Microsoft、PulseMCPが支援している。オープンソースであり、サブレジストリにも対応しているが、一般提供に向けたプレビュー段階にとどまっている——つまり、まだ変動が続くと見ておくべきだ。
2. 02クライアント側のディレクトリ。Claudeのコネクターディレクトリや、ChatGPTのアプリディレクトリなどで、それぞれ独自の審査プロセスを持つ。
3. 03自社のドキュメント。 今日、実際の接続の大半はこの経路で生まれている。開発者向けページにエンドポイントのURL、ツール一覧、認可スコープを記載し、顧客がそれを自分のクライアントに貼り付ける、というものだ。

ツールの大半が公開のものであっても、.well-known/oauth-protected-resourceのドキュメントは公開しておくこと。そして、エンドポイントのパスにはバージョンを付けること。ツールの構成はいずれ必ず変わる。そのときに起きるべきなのは、意図をもって進める移行であって、黙って壊れることではない。

実装チェックリスト

1. 01部品ごとに唯一の正規レコードへ名寄せする。 型付けされた属性、単位、出所、最終検証日時を備えたものにすること。プロトコルから着手してはならない。
2. 02ツールを6〜8個に絞る。 そして、それぞれについて使うべきでないのはどんなときかを記した説明文を書く。
3. 03出力スキーマを宣言し、structuredContentを返す。単位と検証日は、すべてのペイロードに含めること。
4. 04単一のPOSTエンドポイントを提供する。 Mcp-MethodとMcp-Nameヘッダーを尊重し、Originを検証し、一覧の結果にはttlMsとcacheScopeを設定する。
5. 05公開ツールと要認証ツールを分ける。 RFC 9728のメタデータを実装し、RFC 8707に従ってトークンのaudienceを検証し、スコープの提示によって一度の往復で権限を引き上げられるようにする。
6. 06ツールの順序を決定的に返し、ツール名を安定させる。そうすればクライアント側のキャッシュが機能する。
7. 07すべての呼び出しを記録する——ツール、引数、レイテンシー、そして照会が解決したかどうか。分析のないMCPサーバーは、管理できないチャネルである。
8. 08正解データと突き合わせて、精度を継続的に監視する。 古い定格値を自信たっぷりに返すツールは、ツールがないよりも悪い。

Partsgraphは、これをマネージドなレイヤーとして提供している。既存のカタログを一つの検証済みParts Graphへと名寄せし、要認証層にOAuthを備えたMCPエンドポイントをホストし、どのエージェントが何を呼び出したのか、そしてどの回答が誤っていたのかを報告する。

コードを1行も書く前に自社の現在地を知りたいなら、/auditにある無料のグレーダーで自社ドメインを診断してほしい。いま機械が自社カタログの何に到達できているのか、そしてMCPエンドポイントを立てたとして、そこに信頼に足るものを載せられるのかが分かる。