AIエージェントに『この店は何を売っているか』を先に教える──MCPのサーバーカードに商取引情報を足すbeaconspecを読む
MCPサーバーが公開する『サーバーカード』に、業種分類(NAICSコード)・提供形態・営業地域といった商取引情報を追加するIETF個人ドラフトを読んだ。AIエージェントがMCPセッションを開く前に候補を絞り込めるようにする狙いだが、本文を読むと、肝心の『サーバーカードをどこに置くか』というパス自体が、この記事で扱った他の複数ドラフトも含めて未だに定まっていないことが分かる。

目次
AIエージェントが多数のMCPサーバーの中から「自分の目的に合う商業サーバー」を選ぶには、実際にMCPセッションを開いて中身を確認する前に、その店が何を売っているかをざっと知りたい。IETF個人ドラフト「A Well-Known URI Profile for Agent-Callable Commerce Endpoints」(著者D. Soden氏・D. Walker氏、Beacon Spec所属、2026年6月3日提出)の本文を確認すると、MCPの「サーバーカード」に、逆引きDNS形式のキーcom.beaconspec/commerceを使って商取引の情報を足す、インフォーマショナルなプロファイルであることが分かる。
3行まとめ
- このプロファイルは、MCPサーバーの
_metaオブジェクト内にcom.beaconspec/commerceというキーで、業種分類(NAICS 2022コード)・提供形態(product/service/content/mixed)・営業地域(local/online等)といった商取引情報を追加する- 業種分類には北米の標準であるNAICS(北米産業分類システム、米国センサス局・カナダ統計局・メキシコINEGIが共同で維持)の6桁コードを必須で使い、Schema.orgのLocalBusinessサブタイプ(例:
"Plumber"、"Restaurant")をオプションで併記できる- サーバーカード自体をどこに置くかについて、このドラフトは
/.well-known/mcp.json(SEP-1649)を「正規の場所」としつつ、その後継であるSEP-2127が示す/.well-known/mcp/server-card.jsonにも同じ内容を配信することを推奨(SHOULD)している。GitHub APIで確認したところSEP-2127は2026年8月29日時点でまだopen(未マージ)。この記事で以前扱った別の個人ドラフトはMCP公式プロセスとは無関係に、さらに別の場所(/.well-known/mcp-server)を使っている
なぜ必要か
ドラフトの要約はこう説明している。
The purpose of the profile is to give AI agents enough machine-readable information about a commercial MCP server to filter, select, and bootstrap an interaction without first opening an MCP session against every candidate server.
(このプロファイルの目的は、AIエージェントが候補となるすべてのサーバーに対してまずMCPセッションを開くことなく、商業MCPサーバーを絞り込み・選択し、やり取りを始められるだけの機械可読情報を与えることだ)
NAICSコードという「実務で既に使われている」分類を借用
業種分類のフィールドはこう定義されている。
A non-empty array of strings. Each string is a NAICS 2022 industry classification code [...] Real businesses commonly span multiple codes; the array shape is intentional. Codes MUST be six-digit strings. Numeric encoding is not permitted, because leading zeros are significant.
(空でない文字列の配列。各文字列はNAICS 2022の業種分類コードだ。実際の企業は複数のコードにまたがることが多いため、配列という形は意図的なものだ。コードは6桁の文字列でなければならない(MUST)。先頭のゼロが意味を持つため、数値としてのエンコードは許可されない)
NAICSは既にCRM・営業・B2Bシステムで世界的に使われている実務上の分類体系であり、AIエージェント専用の新しい語彙をゼロから作るのではなく、既存の実務標準に乗る設計を選んでいる(ISICやNACEといった他の国際分類体系は、このバージョンでは対象外と明記されている)。
commerceオブジェクトが持つフィールド一覧
ドラフト本文Section 3を確認すると、com.beaconspec/commerceオブジェクトが持つフィールドは次の通り定義されている。
| フィールド | 必須/任意 | 内容 |
|---|---|---|
version |
必須 | このプロファイルのSemVerバージョン。本ドラフトでは"1.0.0"固定 |
lastUpdated |
必須 | ISO 8601形式のタイムスタンプ。マーケットプレイス側の再インデックス判断に使う |
businessName |
必須 | 表示用の事業者名(法的登記名と異なってよい) |
businessDescription |
必須 | 平易な言葉での事業説明文 |
endpoint |
必須 | 接続先の種別(mcpかapi)とHTTPS URL |
naics |
必須 | NAICS 2022の6桁コード(複数可) |
schemaOrgType |
任意 | Schema.orgのLocalBusinessサブタイプ |
offeringType |
必須 | product/service/content/mixedのいずれか |
locality |
必須 | local/online-only/hybridのいずれか |
geo |
localまたはhybrid時必須 | 国(ISO 3166-1)・市区町村など |
capabilityTags |
必須(空配列可) | tools/list等から得られる機能名の一覧 |
contact/currency/languages/privacyPolicyUrl等 |
任意 | 連絡先・通貨・対応言語・プライバシーポリシーURLなど |
beaconspec/mcp-commerce-profileのGitHubリポジトリには、これに沿った参照実装例が公開されている。実際にcurlで取得すると、架空の配管業者「Acme Plumbing & HVAC」を題材に、naics: ["238220", "238210"](複数コード併記)、offeringType: "service"、locality: "local"、geoにダラスの住所情報を入れた、フィールド定義通りのJSONが確認できた。
マーケットプレイスへの登録は「ドメイン所有の証明」を求める
ドラフトSection 4は、マーケットプレイス(複数のサーバーカードをインデックスするサービス)がサーバーカードを取り込む際の運用にも触れている。事業者からの「submission(申請)」または事業者一覧を定期的に巡回する「crawl(クロール)」の2パターンを認めた上で、申請を受け付ける場合はドメインの所有権を確認すべき(SHOULD)としている。確認方法として、/.well-known/mcp/marketplaceValidation.txtにトークンを置く方式と、DNSのTXTレコードにトークンを置く方式の2つが定義されており、いずれもTLS証明書の自動発行プロトコルACME(RFC 8555)のHTTP-01・DNS-01チャレンジを踏襲した設計だとドラフト自身が明記している。
Security Considerations(Section 5)では、この仕組みが証明するのはあくまで「申請者がそのドメインを制御していたこと」だけであり、事業者の法的な実在性・規制上の地位・支払い能力までは何も証明しない、とAIエージェント側に念押ししている。
サーバーカードの置き場所——実は3通り併存している
このドラフトの用語定義には、次のような記載がある。
Server Card: The discovery document retrieved from /.well-known/mcp.json, as defined by the core MCP specification [...] The same document may also be served at /.well-known/mcp/server-card.json, the location proposed by [MCP-SERVER-CARDS-2127].
(サーバーカード:MCPのコア仕様が定義する、/.well-known/mcp.jsonから取得される発見用文書。同じ文書は、[MCP-SERVER-CARDS-2127]が提案する場所である/.well-known/mcp/server-card.jsonでも配信されうる)
さらに本文は「Profile Publisherは、正規の場所である/.well-known/mcp.jsonと、[MCP-SERVER-CARDS-2127]が提案する場所である/.well-known/mcp/server-card.jsonの両方で、同じサーバーカード文書を配信すべきである(SHOULD)」と述べている。ここで参照されている[MCP-SERVER-CARDS]=SEP-1649と[MCP-SERVER-CARDS-2127]=SEP-2127は、無関係な2つの提案ではない。GitHub API(api.github.com/repos/modelcontextprotocol/modelcontextprotocol)でそれぞれの状態を確認したところ、**SEP-1649はclosed(2025年10月14日提出、2026年1月26日にクローズ)**で、ドラフト本文が「SEP-2127はSEP-1649の後継(successor)」と明記している通り、**SEP-2127がその後継として2026年1月21日に提出され、この記事の確認時点(2026年8月29日)でもまだopen(未マージ)**の状態だった。つまりMCP本体の公式プロセス内では、サーバーカードの置き場所は/.well-known/mcp.jsonから/.well-known/mcp/server-card.jsonへと一本の系譜で議論が進んでいる形で、「対立する2つの規格」ではなく「まだ決着していない1つの議論の新旧2バージョン」と見るのが正確だ。
その上で、この記事の連載で以前扱った別の個人ドラフト(mcp:// URIスキーム、著者M. Serra氏)は、MCP公式のSEPプロセスとは別に/.well-known/mcp-serverという場所を使っていた。こちらはSEP-1649/2127の系譜とは完全に独立した、もう1つの提案だ。整理すると、MCP公式プロセス内の新旧2案(/.well-known/mcp.json→/.well-known/mcp/server-card.json)と、それとは無関係な個人ドラフトの独自案(/.well-known/mcp-server)が並行して存在している、というのがこの記事で確認できた実態になる。
Beacon Specの実態とマーケットプレイスの実在は確認していない
このプロファイルのcom.beaconspec/commerceというキー自体が、MCP本体の_meta拡張の命名規則(逆引きDNS形式)に沿った正当な第三者キーであることは本文から確認できたが、Beacon Specという組織・企業が実際にどのようなサービスを展開しているかについては、この記事ではドラフト本文とGitHubリポジトリ以上の裏取りをしていない。このプロファイルを実際に採用しているマーケットプレイスやレジストリが実在するかどうかも確認できていない。NAICSコード表そのものの一次資料(census.gov/naics)はCloudflareの保護に阻まれ、この記事では開けなかった——コード体系の存在自体はドラフト本文の説明を根拠にしているが、公式サイトでの直接確認はできていない。この記事を書いている自分自身は、MCPサーバーの実運用経験がなく、この商取引プロファイルが実際に採用される見込みについても判断材料を持たない。日本語ではZenn・Qiitaともに、このドラフト単体を扱った記事は検索時点で見当たらなかった。
関連記事: MCP(Model Context Protocol)とは
感想・指摘はコメント欄へ。
出典・参照資料
AIニュースの解説を動画でも
YouTubeでは注目ニュースの背景を解説し、Xでは新着記事をお知らせしています。
コメント
まだコメントはありません。最初のコメントを書いてみませんか?
AIについて聞きたいことはありますか?
質問箱で無料で受け付けています。回答は公開され、他の方の参考にもなります。
質問箱を見る →新しい記事をメールで受け取る
AIの新しい発表を、出典付きで整理して届けます。