TL;DR
- 製品データ向けMCPサーバーを使うと、AIエージェントはModel Context Protocolを通じてブランドのカタログに直接問い合わせることができます。MCPは2024年11月にAnthropicが立ち上げたオープンな仕様で、2025年12月からはLinux FoundationのAgentic AI Foundationのもとで運営されています。
- MCPはサーバーに三つの構成要素を与えます。モデルが呼び出せるツール、アプリケーションが読み込めるリソース、ユーザーが選べるプロンプトです。アクセス制御にはOAuth 2.1を使い、サーバーは呼び出し元ごとにそのトークンが許可するものだけを見せることができます。
- MCPサーバーは、GS1 Digital Linkリゾルバー、デジタルプロダクトパスポート、schema.orgマークアップに取って代わるものではありません。同じGTINをキーとし、同じ信頼できる情報源に通じるもう一つの入口として使うのが最も効果的です。
製品データ向けMCPサーバーとは、AIエージェントが扱えるように設計された形で、自社製品に関するエージェントの質問に答えるサービスです。たとえば、このGTINの仕様は何か、このバリエーションは現行品か、適合宣言書はどこにあるか、といった質問です。Model Context Protocol(MCP)は、AIアプリケーションがこうしたサーバーに接続する方法を定めたオープンなプロトコルです。チューリッヒで開催された人間とAIエージェントのためのeコマースに関するW3C/GS1ワークショップのプログラムにも取り上げられました。コマースに特化したものではないため、多くの開発者が最初に出会うエージェントプロトコルでもあります。
本ガイドでは、MCPとは何か、誰が運営しているか、その構成要素をわかりやすく説明します。そのうえで、ブランドやメーカーがMCPサーバーを使って識別子、仕様、コンプライアンス情報、パスポートデータ、供給状況を公開しつつ、制限すべきデータを制限したままにする方法を解説します。以下の内容はすべて2026年10月時点のものです。
Model Context Protocolとは何か
MCPは公開されたオープンな仕様です。現行リビジョンは、MCPを、大規模言語モデルで構築されたアプリケーションと外部のデータソースやツールを接続するためのオープンなプロトコルと説明しています。メッセージはJSON-RPC 2.0でやり取りされ、仕様はApache License 2.0のもとで公開されています。
Anthropicは2024年11月25日にMCPを発表し、仕様とソフトウェア開発キットをGitHubで公開しました。2025年12月9日、AnthropicはMCPをAgentic AI Foundationに寄贈しました。これはAnthropic、Block、OpenAIが共同で設立した、Linux Foundation傘下のdirected fundです。ガバナンスモデルは変わっていません。技術的な決定はメンテナーが行い、仕様の変更はSpecification Enhancement Proposals(SEP)を経て行われます。メンテナーの席は企業ではなく個人に属します。
| 日付 | 出来事 |
|---|---|
| 2024年11月25日 | AnthropicがMCPを発表し、仕様とSDKをオープンソース化 |
| 2025-03-26 | Streamable HTTPトランスポートを導入したリビジョン |
| 2025-11-25 | 開始時のハンドシェイクとセッションを前提とした最後のリビジョン |
| 2025年12月9日 | MCPがLinux Foundation傘下のAgentic AI Foundationに寄贈される |
| 2026年7月28日 | リビジョン2026-07-28が公開。2026年10月時点の現行バージョン |
| 2027年7月28日 | 2026-07-28で非推奨とされた機能を削除できる最も早い日付 |
MCPのバージョンは、後方互換性のない最後の変更が行われた日付で命名されます。2026-07-28リビジョンはプロトコルをステートレスにしました。セッションも開始時のハンドシェイクもなく、すべてのリクエストが自らのプロトコルバージョンとクライアント機能を伴うため、どのサーバーインスタンスでも応答できます。ロードバランサーの背後にある製品データサービスにとって、これは実質的な簡素化です。同じリビジョンでは三つのクライアント機能(Roots、Sampling、Logging)が非推奨となりましたが、本ガイドで紹介するパターンにはいずれも必要ありません。
MCPはどのように機能するのか、わかりやすく言うと?
ホストは、アシスタントやエージェントなど、人が使うAIアプリケーションです。その中でクライアントが一つのサーバー、つまりデータやアクションを提供するサービスに接続します。製品データ向けMCPサーバーを構築するブランドはサーバー側にあたり、エージェントプラットフォームはホストにあたります。
サーバーは三種類の機能を提供し、仕様はそれらを誰が制御するかによって区別しています。
| 構成要素 | 制御する主体 | 内容 | 製品データの例 |
|---|---|---|---|
| ツール | モデル | モデルが呼び出すかどうかを判断できる関数。入力スキーマが定義され、出力スキーマは任意 | GTINで製品を検索する。あるバリエーションが現行品かどうかを確認する |
| リソース | アプリケーション | ホストがコンテキストとして添付する、URIで識別されるデータ | 技術データシート。適合宣言書 |
| プロンプト | ユーザー | 人がメニューなどから選ぶテンプレート | 「この二つの製品を、私にとって重要な仕様で比較して」 |
各ツールには名前、モデル向けに書かれた説明、入力用のJSON Schemaがあります。ツールが出力スキーマを宣言している場合、サーバーはそれに適合する構造化された結果を返さなければなりません。これが、エージェントが文章から「約2 kg」と読み取ることと、値と単位を備えた重量を受け取ることの違いです。リソースはURIテンプレートで記述できるため、サーバーは数百万件の項目を列挙する代わりに、GTINごとに一つのパターンを公開できます。
トランスポートは、メッセージがやり取りされる方法です。仕様はstdio(ホストがサーバーをローカルプロセスとして実行する)と、Streamable HTTP(サーバーが単一のエンドポイントを持つWebサービスである)を定義しています。Web上でエージェントにカタログを公開する場合はStreamable HTTPを使います。
認可は任意で、HTTPトランスポートに適用されます。OAuth 2.1に従い、MCPサーバーはリソースサーバーとして機能し、別個または同居の認可サーバーがアクセストークンを発行します。MCPサーバーは、クライアントがトークンの取得先を見つけられるよう、Protected Resource Metadata(RFC 9728)を公開しなければなりません。トークンはその特定のサーバー向けに発行されたものでなければなりません。
なぜブランドは製品データ向けMCPサーバーを運用するのか?
エージェントは見つけられる製品データをもとに行動し、そのデータがブランドに近いほど推測が減るからです。AIエージェントのための製品アイデンティティに関する記事では、これを一言で表しました。名前は説明し、識別子は識別する。MCPサーバーがあれば、ブランドは識別子をキーとして、エージェントの質問に直接答えることができます。
- ライブデータ。 リコール状況、販売終了したバリエーション、文書のバージョンは変わります。ツール呼び出しは今日の答えを返し、クロールされたページは最後のクロール時点の答えを返します。
- 構造化された回答。 出力スキーマが単位とフィールド名を固定するため、どのエージェントも同じ仕様を同じ形で受け取ります。
- 段階的なアクセス。 仕様では、サーバーが各リクエストの認可に応じて一覧表示するツールやリソースを変えることができるため、一般の呼び出し元と認証済みのパートナーが同じサーバーを利用できます。
限界もあります。エージェントプラットフォームの側からサーバーに接続する必要があり、MCPはそれだけでサーバーを発見可能にするわけではありません。また、MCPの仕様はGTIN、GS1 Digital Link、デジタルプロダクトパスポートに言及していません。本ガイドの以降で述べる、それらの組み合わせ方は私たちの解釈です。
どの製品データをエージェントに公開すべきか?
エージェントが適切な製品を選ぶために答えを必要とする質問と、すでに管理していて責任を持てるデータから始めましょう。
- アイデンティティ。 GTIN、GS1 Digital Link URI、ブランド、製品名、バリエーション、パックサイズ。他のすべての回答はこれに紐づきます。
- 仕様。 寸法、重量、素材、互換性、組成を、固定された単位で。
- コンプライアンス情報。 適合宣言書、安全情報、取扱説明書、認証。MCPは、すでに提供している文書を届けるもう一つの手段です。
- パスポートデータ。 デジタルプロダクトパスポートの公開部分は誰にでも、制限部分は適切な役割を持つ認証済みの呼び出し元に。パスポートが何を保持するかはデジタルプロダクトパスポートのデータ要件のガイドで説明しています。
- 供給状況。 バリエーションが現行品か、販売終了か、リコール対象か。取引パートナー向けには在庫やリードタイム。小売価格と在庫は通常、小売業者の側にあります。
目安として、パッケージ、公開製品ページ、パスポートの公開部分に記載されている事実であれば、MCPサーバー上で公開してかまいません。機密性のある事業情報や、法律が特定の関係者に限定しているデータは、認可の背後に置くべきです。
実践的なアーキテクチャ

この表は、MCPの構成要素が製品データにどう対応するかを示す出発点となる設計です。MCPやGS1が定めたスキーマではありません。
| 公開するもの | ツールかリソースか | 公開か認証済みか |
|---|---|---|
| GTINによる製品検索:アイデンティティと主要仕様 | ツール(出力スキーマ付き) | 公開 |
| 属性によるカタログ検索 | ツール | 公開 |
| 製品のGS1 Digital Link URI | ツールの結果の中でhttps://リンクとして返す | 公開 |
| データシート、取扱説明書、安全情報 | リソース(URIテンプレートでGTINごとに一つ) | 公開 |
| 適合宣言書、証明書 | リソース | 公開。現在公表していない場合は認証済み |
| デジタルプロダクトパスポートの公開部分 | リソース | 公開 |
| 修理業者、リサイクル業者、当局向けの制限付きパスポートデータ | リソース | 認証済み、役割ごとにスコープを設定 |
| 現行品、販売終了、リコール対象の状況 | ツール | 公開 |
| 取引パートナー向けの在庫とリードタイム | ツール | 認証済み |
質問にはツール、文書にはリソース。 何を調べるかを自ら判断するエージェントにはツールが必要です。ツールはモデルが制御するものだからです。ホストや人がコンテキストとして添付する文書はリソースに適しています。検索ツールは、構造化データに加えて、関連するリソースへのリンクを返すことができます。
Digital Link URIを公開アドレスとして使う。 仕様は、クライアントがMCPサーバーを介さずにWebから直接取得できる場合に限り、リソースにhttps://スキームを使うべきだとしています。GS1 Digital Link URIはまさにそれに当たります。公開情報については、サーバーがDigital Link URIを返し、エージェントに解決させればよいでしょう。制限データについては、独自のURIスキームを使い、トークンを確認したうえでコンテンツを提供できます。
tool: lookup_product(gtin) → identity, specs, links
public: https://id.example.com/01/09506000134352
template: dpp-restricted://{gtin}/{lot}
既存の役割に合わせてアクセスのスコープを設定する。 OAuthのスコープは、一般、取引パートナー、修理業者またはリサイクル業者、当局といったアクセス階層をそのまま反映できます。仕様のセキュリティガイダンスは、最初は最小限のスコープとし、特権的な操作が試みられたときにだけ追加を要求することを推奨しています。ESPRのもとでは、どの関係者がどのパスポートデータを閲覧できるかは製品グループごとの委任法が定め、MCPサーバーはその決定を執行するだけです。こうした階層についてはデジタルプロダクトパスポートのアクセス権のガイドで扱っています。
現行リビジョンでは、データを一覧表示または読み込む結果にも、キャッシュのスコープと有効期間が付きます。公開製品データはpublicとしてマークできますが、認証済みの呼び出し元に返すものはすべて、共有の中継サーバーにキャッシュされないようprivateとしてマークすべきです。
MCPサーバーはリゾルバー、パスポート、schema.orgとどう組み合わさるのか?
新しいチャネルにつきもののリスクは、データの新たなコピーができ、それが元のデータからずれていくことです。MCPサーバーは、同じGTINをキーとする同じ製品レコード上の、もう一つのインターフェースとして扱いましょう。
GS1 Digital Linkリゾルバーは、すでに機械に応答しています。GS1-Conformant Resolver Standardのもとでは、application/linkset+jsonメディアタイプでlinksetを要求したクライアントは、その製品に登録されたすべてのリンクをJSONで受け取ります。リンクには、製品情報ページを示すgs1:pipなど、GS1 Web語彙による種類が付けられています。解決の仕組みはGS1 Digital Linkリゾルバーのガイドで説明しています。リゾルバーはブランドが管理する公開アドレスであり続け、MCPサーバーはその上に構造化された検索と認証付きアクセスを加えます。
デジタルプロダクトパスポートには、アクセス、データキャリア、バックアップコピーに関する独自のルールがあり、そのいずれもMCPに言及していません。MCPサーバーはエージェントにパスポートデータを提供できますが、製品上のデータキャリアに取って代わるものではありません。私たちの解釈では、MCPサーバーは同じパスポートレコードから読み込むべきです。そうすれば、エージェントとパッケージをスキャンする人が同じ値を目にします。
schema.orgマークアップとフィードは今も重要です。schema.orgのProduct型にはgtin、offers、countryOfOrigin、hasCertificationといったプロパティがあり、製品ページ上のマークアップは、誰も接続を設定しなくてもクローラーに読み込まれます。フィードは、あなたのサーバーを決して呼び出さないプラットフォームにも届きます。
| チャネル | 得意なこと | 苦手なこと |
|---|---|---|
| schema.orgマークアップ | クローラー側の設定なしで見つけてもらえる | ライブデータと制限データ |
| 製品フィード | 既知のチャネルへの一括掲載 | 更新と更新の間の鮮度 |
| GS1 Digital Linkリゾルバー | 製品ごとに一つの、ブランドが管理する公開アドレス | 質問への回答、きめ細かな認可 |
| MCPサーバー | ライブで構造化された回答と役割ベースのアクセス | 到達範囲:プラットフォームの側から接続する必要がある |
QRコードはアイデンティティに役立ちます。パッケージ上のGS1 Digital Link QRコードは、MCPサーバーが返すのと同じURIをエンコードしているため、スキャンする買い物客と問い合わせるエージェントは同じ製品にたどり着きます。ただし、エージェントとのやり取りそのものには役立ちません。エージェントはサーバーを呼び出すためにパッケージをスキャンするわけではないからです。
仕様はセキュリティについて何と言っているか?
仕様は、MCPはプロトコルレベルでセキュリティを強制できないと述べ、同意、認可、アクセス制御をアプリケーションに組み込むよう実装者に求めています。製品データサーバーにとって最も重要なのは次の点です。
- 検証し、制御し、制限し、無害化する。 サーバーは、すべてのツール入力を検証し、適切なアクセス制御を実装し、ツール呼び出しにレート制限をかけ、ツール出力を無害化しなければなりません。リソースURIは検証しなければならず、機微なリソースにはアクセス制御を設けるべきです。
- エンドポイントを保護する。 Streamable HTTPでは、サーバーはDNSリバインディング攻撃を防ぐために
Originヘッダーを検証しなければならず、すべての接続を認証すべきです。 - 自分宛てのトークンだけを受け付ける。 サーバーは、他のサービス向けに発行されたトークンを受け付けたり、クライアントのトークンを下流のシステムにそのまま渡したりしてはなりません。PIMやERPを呼び出すときは、サーバー自身の認証情報を使います。
- スコープを小さく保つ。 何でも許すスコープは避け、各操作に必要なものだけを付与します。
ホスト側については、仕様はツール呼び出しを拒否できる人間が介在することを想定しており、信頼できるサーバーからのものでない限り、ツールのアノテーションを信頼できないものとして扱うようクライアントに求めています。これは、ツールの説明を正確かつ控えめに書く十分な理由になります。
今すべきこと
- まずアイデンティティを整える。 エージェントに扱わせたいすべての製品に、GTINと、GS1準拠のリゾルバー上で機能するGS1 Digital Link URIが必要です。
- 信頼できる情報源を一つに決める。 MCPサーバーは新しいデータベースとしてではなく、正式な製品レコードを読み込むものとして計画します。
- 質問を書き出す。 エージェントが最も答えを必要とする十の質問を書き出し、出力スキーマを備え、わかりやすく説明されたいくつかのツールに落とし込みます。
- 公開と制限を分ける。 該当する場合はパスポートのアクセス階層を使い、各フィールドを公開、パートナー限定、役割限定に分類します。
- コードの前にスコープを設計する。 それらの分類を最小限のOAuthスコープに対応付け、認可サーバーを選びます。
- リビジョン2026-07-28に合わせて構築する。 Streamable HTTPを使い、非推奨の機能は使いません。
- 他のチャネルも維持する。 サーバーと並行して、schema.orgマークアップとフィードを保守します。
Digital LinkはGS1のソリューションパートナーです。私たちのプラットフォームは、すべての製品に、準拠したリゾルバーを備えたGS1 Digital Link URIとQRコード、構造化された製品レコードを提供し、パスポートの公開データと制限データを分けて管理します。そのレコードこそがMCPサーバーが読み込むべき唯一の情報源であり、それによってエージェント、買い物客、検索エンジンが同じ製品を目にします。自社カタログのうち何をAIエージェントに公開し、何を制限したままにすべきかを検討したい場合は、お問い合わせください。私たちのチームがあなたのケースを確認します。
よくある質問
Model Context Protocolは誰のものですか?
AnthropicがMCPを作成し、2024年11月に立ち上げました。2025年12月からは、Anthropic、Block、OpenAIが共同で設立したLinux Foundation傘下のdirected fundであるAgentic AI Foundationに置かれています。技術的な決定は、プロジェクトのメンテナーが公開の提案プロセスを通じて行います。
MCP仕様の現行バージョンは何ですか?
2026年10月時点では、2026年7月28日に公開されたリビジョン2026-07-28です。開始時のハンドシェイクとプロトコルレベルのセッションを廃止してプロトコルをステートレスにし、Roots、Sampling、Loggingの各機能を非推奨にしました。
MCPサーバーはAPIと同じものですか?
AIアプリケーション向けに標準化された形を持つAPIです。MCPに対応したホストであればどれでも、独自のエンドポイントを学習する代わりに、あなたのツールやリソースを一覧表示し、その説明とスキーマを読み、同じ方法で呼び出すことができます。多くのチームは、既存の製品APIの上に薄いレイヤーとして構築しています。
AIエージェントがMCPサーバーを使うにはGS1 Digital Linkが必要ですか?
いいえ。MCPの仕様はGS1の識別子に言及していません。私たちの解釈では、すべてのチャネルをGTINとそのGS1 Digital Link URIをキーとすることで、エージェントに曖昧さのない一つのアイデンティティを与えられ、類似製品の取り違えを防げます。
MCPサーバーで一部の製品データを非公開にできますか?
はい。認可はOAuth 2.1に従い、サーバーは各リクエストのトークンに応じて一覧表示するツールやリソースを変えることができます。サーバーは、こうした確認をすべての呼び出しで実施しなければなりません。
MCPサーバーがあればデジタルプロダクトパスポートに準拠したことになりますか?
いいえ。パスポートの内容、データキャリア、アクセス権は、ESPRと製品グループごとの委任法によって定められており、そのいずれもMCPに言及していません。MCPサーバーは、同じレコードから読み込んでパスポートデータを提供する追加の手段になり得ます。





