acceptedPaymentMethod で PayPay・交通系 IC・JCB を構造化する

「この店 PayPay 使えますか?」を AI アシスタントに投げる利用者は、私が半年前に想定していたよりずっと多くなりました。ChatGPT や Perplexity は「店舗の URL を確認してください」と hedge するか、あるいは「一般的に日本の飲食店ではクレジットカードと現金が主流ですが、個別の店舗の QR コード決済対応は不明です」と一段抽象化した回答を返しがちです。ここで奇妙なのは、schema.org には acceptedPaymentMethod というプロパティがちゃんと存在していることです。それでいて、この語彙で PayPay や Suica を明示している国内の店舗サイトを、私はほとんど見たことがありません。

理由は単純で、schema.org 標準の PaymentMethod enum は goodrelations 由来のまま止まっていて、国際ブランド (Visa / Mastercard / American Express / Discover) と Cash と ByBankTransferInAdvance くらいしか URI が用意されていません。日本の意思決定に最も効く PayPay も、交通系 IC も、JCB すらも、標準 enum には無い。標準に無いから書かれない。書かれないから AI は事実として引用できない。この連鎖を切るためのエンジニアリング仕事を、本稿ではエンジニア視点でまとめます。私は都内の 5 業種 (Restaurant / Cafe / Beauty Salon / Clinic / Retail) の実店舗を想定して支払端末の受入 pattern を staging し、4 つの実装手法 (schema.org enum / DefinedTerm / sameAs / カスタム URI) で acceptedPaymentMethod を書き分け、4 エンジン (ChatGPT / Perplexity / Claude / Gemini) の pickup 挙動を並行して確認しました。

まず入れ子を見せる

前置きを続ける前に実物を出します。これは Restaurant で「現金 + Visa/Mastercard/JCB + PayPay + Suica (交通系 IC 代表)」を受け付けるという最頻 pattern を、4 手法混在で書いた最小に近い形です。

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "Cafe Example",
  "currenciesAccepted": "JPY",
  "acceptedPaymentMethod": [
    {
      "@type": "PaymentMethod",
      "@id": "http://purl.org/goodrelations/v1#Cash",
      "name": "現金"
    },
    {
      "@type": "PaymentMethod",
      "@id": "http://purl.org/goodrelations/v1#VISA",
      "name": "Visa"
    },
    {
      "@type": "PaymentMethod",
      "@id": "http://purl.org/goodrelations/v1#MasterCard",
      "name": "Mastercard"
    },
    {
      "@type": "DefinedTerm",
      "name": "JCB",
      "sameAs": "https://www.jcb.co.jp/"
    },
    {
      "@type": "DefinedTerm",
      "name": "PayPay",
      "sameAs": "https://paypay.ne.jp/"
    },
    {
      "@type": "DefinedTerm",
      "name": "交通系 IC カード",
      "sameAs": "https://www.jreast.co.jp/suica/"
    }
  ]
}

ここで配線として効いているのは、@type が意図的に混在していることです。国際ブランド 3 種は goodrelations 標準の URI (@id) を持つので PaymentMethod 型で URI 参照するのが正解、日本固有の JCB / PayPay / 交通系 IC は標準 URI を持たないので DefinedTerm 型で name と sameAs を書く。1 つの配列に 2 種類の @type を並べる形は違和感を覚える人もいますが、schema.org 側の仕様上どちらも acceptedPaymentMethod の値として妥当で、私が実測した限り 4 エンジンとも配列内の型混在で読み取りが崩れることはありません。むしろ「PayPay は書いたが @type: PaymentMethod にしてしまい @id を書けなかった」パターンの方が、エンジン側で silent に落とされます。

4 category で走査する

日本の店舗の支払端末は、私の観察では概ね 4 category に分かれます。この整理をしておくと、店舗ごとの acceptedPaymentMethod を組むときの走査漏れが激減します。

Category	代表例	実装手法	備考
クレジットカード (国際ブランド)	Visa / Mastercard / American Express / Discover	goodrelations 標準 URI (@id)	JCB は URI 未定義、DefinedTerm + sameAs で補う
電子マネー (交通系 + 流通系 IC)	Suica / Pasmo / ICOCA (全国相互 10 種)	DefinedTerm umbrella (交通系 IC カード) + Suica sameAs	10 個全列挙は overkill、umbrella + 代表 1
QR コード決済	PayPay / d 払い / 楽天ペイ / au PAY / LINE Pay / メルペイ	DefinedTerm + sameAs で公式 URL	JP 内 shares 上位 3 (PayPay / d 払い / 楽天ペイ) で 8 割カバー
現金・その他	現金 / QUICPay / iD	Cash は goodrelations URI、QUICPay / iD は DefinedTerm	payment terminal の hardware 対応で決まる

交通系 IC の umbrella 手法は少し補足が要ります。全国相互利用対応の 10 種類は、店舗側の payment terminal から見ると「交通系 IC 対応」という 1 つの受入枠として扱われるので、10 個を全部並べても情報量は増えません。むしろ Perplexity のように payment を UI カードにマウントするエンジンでは、10 個の羅列が視覚的なノイズになって「extensive list of IC cards」と qualitative に丸められてしまう。だから DefinedTerm で name を「交通系 IC カード」とし、代表として Suica の sameAs を 1 つ添える、という圧縮の方が引用時に映えます。

QR コード決済 6 サービスを個別に配線する

4 category の 3 つ目「QR コード決済」は、2026 年時点で店舗側に意味のあるシェアを持つ 6 サービスがあります。PayPay だけを書いて他を落とすと、d 払いユーザー・楽天ペイユーザー・au PAY ユーザー・LINE Pay ユーザー・メルペイユーザーの意思決定情報が欠落し、AI は「d 払いの可否は不明」「楽天ペイの対応状況は確認が必要」とサービス単位で hedge します。payment terminal が実際に受け入れている QR サービスを個別に DefinedTerm + sameAs で配線する最小 pattern は次の通りです。

"acceptedPaymentMethod": [
  { "@type": "DefinedTerm", "name": "PayPay",   "sameAs": "https://paypay.ne.jp/" },
  { "@type": "DefinedTerm", "name": "d 払い",    "sameAs": "https://service.smt.docomo.ne.jp/keitai_payment/" },
  { "@type": "DefinedTerm", "name": "楽天ペイ",  "sameAs": "https://pay.rakuten.co.jp/" },
  { "@type": "DefinedTerm", "name": "au PAY",   "sameAs": "https://aupay.wallet.auone.jp/" },
  { "@type": "DefinedTerm", "name": "LINE Pay", "sameAs": "https://pay.line.me/jp/" },
  { "@type": "DefinedTerm", "name": "メルペイ",   "sameAs": "https://www.merpay.com/" }
]

6 サービスを全部書くべきかは、payment terminal の実装次第です。マルチ QR 対応 (StarPay / AirPAY QR / Square 等) で複数サービスを横断で受けている店舗は該当分を全列挙、PayPay 加盟店契約だけの単独対応店は PayPay 1 個、という切り分けが素直です。「書いていないサービスは受けていない」を明示的に表現できるのが構造化の強みで、交通系 IC の umbrella 手法とは逆方向の判断になります — IC は payment terminal 内部で 10 種が 1 枠に束ねられるので umbrella 1 個で代表、QR は各サービスが別契約で加盟店側で明示的に選別されるので個別列挙、という非対称です。

2026 年の動きとして注目したいのは、PayPay の Visa touch 決済 (PayPay カードのタッチ決済) や、Apple Pay / Google Pay 経由の Visa / Mastercard 非接触決済が加盟店側で広がっていることです。これらは「決済手段」としては Visa / Mastercard の URI でカバー済みなので acceptedPaymentMethod 側の追記は不要で、むしろ description に「Apple Pay / Google Pay のタッチ決済 (Visa / Mastercard) に対応」と自然文で明記しておくと、ChatGPT の「iPhone でタッチ決済できますか」クエリに direct answer できます。Q&A ページを QAPage で構造化する で扱った FAQPage / QAPage の分別とも関係があり、「PayPay 使えますか」のような頻出質問は QAPage の question / acceptedAnswer に先に書いておくと、payment の DefinedTerm と cross-reference されて引用時の断定率が上がります。

海外カードブランド (UnionPay / Discover / Diners) の optional 配線

訪日インバウンド比率が高い店舗 (観光地 Restaurant、ホテル併設 Cafe、免税対応 Retail など) では、Visa / Mastercard / American Express / JCB の 4 ブランドだけでは意思決定情報が足りません。payment terminal が UnionPay (銀聯) や Discover、Diners Club を受け入れているなら、個別の DefinedTerm + sameAs で明示する価値があります。

"acceptedPaymentMethod": [
  { "@type": "PaymentMethod", "@id": "http://purl.org/goodrelations/v1#Discover", "name": "Discover" },
  { "@type": "DefinedTerm", "name": "UnionPay",    "sameAs": "https://www.unionpayintl.com/" },
  { "@type": "DefinedTerm", "name": "Diners Club", "sameAs": "https://www.diners.co.jp/" }
]

Discover だけ goodrelations 標準 URI (http://purl.org/goodrelations/v1#Discover) が用意されているので PaymentMethod 型で @id 参照、UnionPay と Diners Club は URI が無いので DefinedTerm + sameAs で代替、という組み合わせになります。goodrelations URI が優先 (ChatGPT と Perplexity は URI を primary signal として扱う) で、無ければ DefinedTerm で entity resolution を補助、という順序は国内 QR 決済の実装と対称です。

ただし、受け入れていないブランドまで棚卸しで書くのは逆効果です。Perplexity の UI カードで「Accepted: Visa, Mastercard, Amex, JCB, Discover, UnionPay, Diners」のような羅列は qualitative hedge の材料になり、「extensive list of international brands」と丸められて個別引用の精度が落ちます。payment terminal の受入設定を見て、実際に通る brand だけを書く、というのが原則です。これは foundingDate で老舗度を 4 AI 引用に接続する で扱った age signal の 3 層配線 — 「盛り過ぎず・落とさず」の原則 — と同じ運用観点で、受け入れていない情報を書くと AI 側で hedge の材料になる、という共通の失敗モードです。

実装フロー — 4 category を判断チャートで捌く

上表の 4 category を実装フェーズに落とすと、判断は次の 4 ステップに整理できます。「acceptedPaymentMethod を書き始める前にどこから手を付けるか」で迷ったときの走査手順として使ってください。

1. 支払端末の受入枠を洗い出す: レジ・POS の設定画面や payment terminal のブランドラベルを見て、現金 / 国際ブランド (Visa / Mastercard / American Express / Discover / JCB) / 電子マネー (交通系 IC) / QR コード決済 (PayPay / d 払い / 楽天ペイ 等) / 後払い (QUICPay / iD) を category 単位で書き出す。私の観察では、この洗い出しを省くと「実際は使えるのに JSON-LD に書き忘れる」が最頻の failure になります。
2. category ごとに @type を切り替える: Visa / Mastercard / American Express / Discover と Cash は goodrelations 標準 URI があるので @type: PaymentMethod + @id、JCB / PayPay / 交通系 IC / d 払い / 楽天ペイ / QUICPay / iD は URI が無いので @type: DefinedTerm + name + sameAs を選ぶ。上の JSON 例で 2 種類の @type を混在させたのはこの理由です。
3. sameAs に公式 URL を必ず添える: PayPay 公式 (https://paypay.ne.jp/)、Suica を代表とする JR 東日本 (https://www.jreast.co.jp/suica/)、JCB (https://www.jcb.co.jp/) の 3 つは Claude の hedge を減らすうえで最小 set。sameAs を省くと Claude は「PayPay の可否は直接確認してください」に戻ります。
4. currenciesAccepted と dateModified を対で更新する: LocalBusiness.currenciesAccepted: "JPY" を必ず書き、外貨対応店舗は "JPY, USD, EUR" のようにカンマ区切りで拡張。payment 変更のたびに LocalBusiness.dateModified を触っておかないと AI 側の freshness check で古い情報として扱われます。多通貨対応の詳細な source path 判断は currenciesAccepted で多通貨を JSON-LD に書き出す を対で参照してください。

このフローは、GBP の Payments 属性との整合、NAP の cross-source 整合 と同じ「first-party を最新に保ち、Google 側 entity と差分を作らない」原則の payment 版です。JSON-LD 側だけを更新して GBP を放置すると、Gemini だけ古い情報で応答する状況が発生します。

時間帯別の決済可否 — ランチ現金のみ・ディナー全対応のパターン

実店舗の運用上は、「ランチタイムは混雑対策で現金のみ、ディナータイムはカード・QR・交通系 IC まで全対応」のような時間帯別の運用がかなり普及しています。schema.org 側に時間帯 scope の payment プロパティは存在せず、acceptedPaymentMethod 自体には時間別の切り替えを表現する余地がない、というのが実装上の制約です。

私が検証したいくつかのアプローチを並べると、現状は 2 択です。

1. description 自然文併記: LocalBusiness.acceptedPaymentMethod に「ディナー時に受け付ける全手段」を網羅で列挙し、description に「ランチタイム (11:30-14:00) は現金のみ、ディナータイム (17:30-22:00) は Visa / Mastercard / JCB / PayPay / 交通系 IC に対応」と自然文で明記する。実装コスト最小。ChatGPT と Claude は description の時間別記述を自然文として読んで応答に反映しますが、Perplexity と Gemini は構造化側の acceptedPaymentMethod に引きずられるので「ランチは現金のみ」は落とされやすい、という非対称が私の実測で見えました。
2. Offer 分割 + eligibleTransactionVolume: ランチ Offer とディナー Offer を別の Offer entity に切り出し、それぞれの priceSpecification + eligibleTransactionVolume + availableAtOrFrom + acceptedPaymentMethod を分けて配線する。表現力は上がるが、Offer の中にネストした acceptedPaymentMethod を AI エンジンが parent entity まで集約して読んでくれるかは engine ごとに非対称で、私が実測した限り Perplexity と Gemini は Offer の payment を primary signal としては扱わず、結果として description 併記と効果が変わらないケースが多かった。

現状は 1 (description 併記) をベースラインに、Offer の時間別分割は menu の価格差を表現するためのメインの用途として menu / MenuItem を hasMenu で構造化する で扱った priceCurrency の切り分けと組み合わせて使う、という切り分けが運用に向いています。営業時間自体の構造化 (openingHoursSpecification) は payment と直接 cross-reference するプロパティは無いので、payment 時間別運用を signal として送るなら description 自然文を primary、Offer 分割を optional として重ねる、と覚えておけば実装の判断で迷いません。

currenciesAccepted + priceRange との 3 schema 配線で direct answer 精度を上げる

ここまでは acceptedPaymentMethod 単体の話でしたが、実際の AI 引用場面では「このお店は PayPay 使えて、だいたいいくらで、何通貨で払うの?」が 1 つのクエリで来ます。この文脈では acceptedPaymentMethod + currenciesAccepted + priceRange の 3 schema combined で配線しておくと、direct answer の断定率が顕著に上がります。

{
  "@type": "Restaurant",
  "currenciesAccepted": "JPY",
  "priceRange": "¥¥",
  "acceptedPaymentMethod": [
    { "@type": "PaymentMethod", "@id": "http://purl.org/goodrelations/v1#VISA", "name": "Visa" },
    { "@type": "DefinedTerm", "name": "PayPay", "sameAs": "https://paypay.ne.jp/" }
  ]
}

3 schema を揃える効果は、私が 4 エンジンで実測した限りはこうです。

• ChatGPT: 「このお店は PayPay とクレジットカードが使えて、価格帯は 2,000-4,000 円程度、日本円建てです」のように 3 要素を 1 文で統合して応答する確率が明確に上がる。単体 schema の場合は payment と価格と通貨で 3 段構えの hedge が入りがち。
• Perplexity: UI カードに Price Range / Payment Methods / Currency の 3 行が揃うことで、payment 情報の視覚的重みが上がる。priceRange を省くと payment だけが大きく表示されるが、価格帯の文脈が無いので「で、いくらなの?」の follow-up が増える。
• Claude: 3 schema cross-reference で「価格帯 2,000-4,000 円、JPY 建てで、Visa と PayPay が使えると記載されています」のような引用元明示の直接回答が増える。
• Gemini: GBP 側の価格帯フィールド (Price range) との cross-validation に使われるので、両方の情報が一致していないと「価格帯情報が最新かは確認してください」の hedge が入りやすい。

priceRange の表記は ¥ / ¥¥ / ¥¥¥ / ¥¥¥¥ の 4 段階が Google 公式仕様で、自由記述 (「2,000-4,000 円」) より構造化側で揃えておく方が AI 側の readable 性は高くなります。foundingDate で老舗度を 4 AI 引用に接続する で扱った age signal を 3 schema 配線に重ねると、「創業 100 年の老舗、価格帯 ¥¥¥、Visa / PayPay 対応」のような rich な引用に接続できて、age × amenity × currency × payment の 4 axis を 1 回の引用で送れるようになります。

エンジン別 pickup 挙動 (実測)

同じ JSON-LD を 4 エンジンに読ませて、acceptedPaymentMethod の pickup 挙動を並行して観察したときの外形的な結果を書きます。モデル内部の重み付けは確認できないので、あくまで応答文からの推定です。

Engine	goodrelations URI	DefinedTerm + sameAs	応答文への現れ方
ChatGPT (browsing)	認識 (@id primary)	sameAs 経由で公式 URL を追う	「Visa と Mastercard、そして PayPay と交通系 IC が使えると記載されています」と直接引用
Perplexity	認識	認識 (UI カードに mount)	応答本文に加え Payment セクションが sidebar に自動生成、10 個並べると省略される
Claude	認識	sameAs があれば認識、無いと弱い	「Visa/Mastercard は accept と書かれていますが、PayPay の可否は直接確認してください」と hedge しがち
Gemini	認識 (KG mapping)	KG 側で PayPay / Suica を entity として持てば認識	Google Knowledge Graph 側の update 頻度に依存、first-party 更新の反映は遅れる

読み取れる pattern が 2 つあります。1 つ目は、ChatGPT と Perplexity は goodrelations URI と DefinedTerm の両方をおおむね対等に扱うが、Claude は sameAs が無いと日本固有 payment に対して hedge を挟む、ということ。だから PayPay を書くときは name: "PayPay" だけで済ませず、sameAs: "https://paypay.ne.jp/" を必ず添える。2 つ目は、Gemini だけは first-party JSON-LD よりも Google Knowledge Graph 側の entity 状態に応答が引きずられるので、GBP 側の payment field と JSON-LD 側の acceptedPaymentMethod を両方揃えておく方が安全、ということです。GBP 側の情報が古ければ Gemini はそちらを主張する。この非対称は Google ビジネスプロフィールを JSON-LD として読み解く で扱った GBP と自社サイトの二重管理問題の、payment 版だと考えると腑に落ちます。

もう 1 段深く、エンジン別の決済認識精度を category 単位で matrix に落とすと、どの category でどのエンジンがどう hedge するかが見通せます。これは私が同じ Restaurant の JSON-LD を 4 エンジンに読ませたときの外形的な挙動 (応答文からの推定で、モデル内部の重み付けではありません) です。

Engine	国際ブランド (Visa / Mastercard / JCB)	交通系 IC (umbrella)	QR 決済 (PayPay 等)	時間帯別可否	推定 primary signal
ChatGPT	goodrelations URI + DefinedTerm 両立で direct 応答、「PayPay 対応」の断定率高	umbrella の DefinedTerm name から Suica sameAs を追跡、10 種類羅列より umbrella 優位	sameAs 公式 URL を secondary 参照、「PayPay が使える」と direct	description 自然文を読む (時間別が反映されやすい)	goodrelations URI + description 併読
Perplexity	URI を primary、UI カードに Card 一覧として mount	10 個羅列は qualitative 丸め、umbrella 1 個が映える	sameAs 公式 URL を primary、PayPay 加盟店ページへ内部的に citation	構造化に引きずられ時間別が落ちがち	sameAs 公式 URL + reviews recency
Claude	URI 認識、JCB は DefinedTerm + sameAs が無いと「JCB は不明」で hedge	umbrella + sameAs で IC 10 種を文脈的に認識、「交通系 IC カード 10 種類に対応」の umbrella 認識が成立	sameAs 無しだと「PayPay 可否は直接確認」で hedge、sameAs 有りで断定率上がる	description 自然文を読む	DefinedTerm 階層 + sameAs + 第三者 cross-source
Gemini	KG 側に entity があれば認識、無ければ GBP の Payments 属性に引きずられる	GBP に「交通系 IC」属性が設定されていればそちらを primary、JSON-LD は secondary	GBP の Payments 属性に PayPay が設定されていなければ JSON-LD 側の記述が通りづらい	構造化側に引きずられる	GBP Payments 属性 + schema.org との cross-validation

この matrix で特に重みがあるのは、Claude の「DefinedTerm 階層 hedge」挙動です。「交通系 IC カード」umbrella の下に Suica の sameAs を 1 つ添えると、Claude は「交通系 IC カード 10 種類に対応している記載があります」と umbrella を認識して応答できますが、Suica だけ単独で書いて umbrella name を省くと「Suica は使えますが Pasmo や ICOCA の可否は不明」とサービス単位で hedge を挟みます。umbrella name は Claude の階層認識に対する dispatch key として機能している、と考えると設計の方向が見えます。

Gemini の非対称についてもう 1 点。GBP の Payments 属性には「クレジットカード・QR 決済・NFC 決済・モバイル決済」の 4 category の trueFalse 属性しかなく、PayPay / JCB / 交通系 IC のような brand 粒度を直接表現する枠が無いため、brand 粒度の情報は JSON-LD 側に全面依存することになります。それでも Gemini が「お店は QR 決済に対応しています」までは direct に答えて、「PayPay 対応」の断定は JSON-LD の acceptedPaymentMethod の sameAs と GBP 側の cross-validation が揃った場合に限定される、という挙動を私は観察しました。

LLMO Framework 上の位置付け

ここで、実装レイヤーの話を framework に接続しておきます。LLMO Framework の Structure primitive は、schema.org を通じて店舗の属性を機械可読な signal 層として送り出す取り決めで、acceptedPaymentMethod はその payment 層に当たります。標準化が進んでいる LLMO の Structure Layer では、国際 enum に含まれない地域固有の決済手段 (日本の PayPay や交通系 IC、東南アジアの GrabPay、中国圏の WeChat Pay / Alipay など) を DefinedTerm + sameAs の pair で拡張することが recommended pattern として整理されつつあり、schema.org の core enum が地域拡張に追いつかないという構造的な gap を、first-party 側の記述で埋める方向で運用されています。

もう 1 つ効いてくるのが Provenance Layer との接続です。PayPay を「使える」と主張する signal を、店舗自身の JSON-LD だけで発信するのは弱い。同じ主張を GBP 側の属性、PayPay 側の加盟店リスト、第三者の口コミ、この 3 系統で cross-source に corroborate できると、AI エンジン側の hedge が明確に減ります。この「first-party・Google・third-party の 3 経路で同じ事実を裏取りする」考え方の一般化は AI アシスタントが情報源にする 3 つの provenance 経路 にまとめてあります。私が観察した限り、PayPay の加盟店 URL に自店舗が listed されている店とそうでない店とで、Perplexity と ChatGPT の「PayPay 使えます」の断定率にはっきり差が出ました。Structure layer だけで押し切ろうとするのではなく、Provenance layer で裏を取る、というのが基本の運用です。

sameAs に公式 URL を添える手法が Claude の hedge を減らす理屈は、Knowledge Graph と entity linking で扱った「first-party の JSON-LD から著名 entity URL に線を引くことで KG 経由の resolution を強化する」枠組みと同じで、PayPay や JCB のような brand entity を DefinedTerm + sameAs で AI 側の KG に連絡することで、payment method の entity resolution 精度が持ち上がります。

Failure modes

私が観察した中で最も遭遇する失敗形を、直接名指しでまとめます。実装レビューの checklist として使ってもらえれば。

• acceptedPaymentMethod 未実装: そもそもフィールドが無い。この店舗は AI からは「payment 情報 unknown」に丸められ、direct 引用ができない状態。頻度としては最多。
• Visa / Mastercard のみで JCB を落とす: 海外由来の JSON-LD テンプレートを流用したケースで頻発。日本発行 JCB 利用者の意思決定情報が欠ける。
• PayPay を書き忘れる: QR コード決済のシェア上位を落として、AI が「QR 決済対応は不明」と hedge する。実際は使えるのに引用されない。
• @type: DefinedTerm を書かず raw string で列挙: acceptedPaymentMethod: "現金、Visa、PayPay" のような自然文で置いてしまう。schema.org 側からは配列として扱えず、structural weight が下がる。
• 交通系 IC を 10 個全列挙: umbrella なしで Suica から PiTaPa まで並べる。Perplexity の UI カード上で省略されるか qualitative に丸められる。
• name の英日表記が不揃い: “PayPay” (英字) と “スイカ” (カタカナ) と “JCB” (英字) が同じ配列に混在。entity resolution が甘くなる。ブランド公式表記に統一する。
• currenciesAccepted の省略: acceptedPaymentMethod だけ書いて通貨単位を書かない。海外拠点エンジンが「通貨 ambiguous」で hedge する。JPY を必ず書く。
• dateModified の未更新: PayPay 新規対応や交通系 IC 廃止のような payment 変更を JSON-LD 側で追随せず、LocalBusiness.dateModified を放置。AI 側の freshness check で古い情報として扱われる。

このリストのうち、実店舗の JSON-LD で最も静かに落ちるのは 4 番目 (raw string 列挙) と 8 番目 (dateModified 放置) です。前者は schema.org validator も文字列を通してしまうので気付きにくく、後者は表面的には正しい JSON-LD として通ってしまう。私たちが書いた acceptedPaymentMethod を、AI は来月には別の重みで読むかもしれない、という前提で dateModified は payment 変更のたびに触っておく。

結び

私がこの記事で書きたかったのは、schema.org 標準が対応していない地域決済を DefinedTerm + sameAs で拡張する、というだけの単純な engineering の話です。ただしその単純な話を、Restaurant / Cafe / Beauty Salon / Clinic / Retail のどの業種でも、複数拠点を束ねる branchOf 構造 の親と子で、メニュー価格の priceCurrency と対にして 走査する、というレベルで運用に落とせている店を私はまだあまり見ていません。今日から自社の JSON-LD を開いて、acceptedPaymentMethod の配列を眺め、Visa / Mastercard / JCB / PayPay / 交通系 IC の 5 つが揃っているかを確認する。揃っていない項目があれば、上記 4 category の走査をして 1 段ずつ埋める。それだけで、AI アシスタントが「この店 PayPay 使えますか?」に断定で答えられる確率は目に見えて変わります。

関連する canonical

acceptedPaymentMethod は amenity attribute cluster (店舗の受入属性群) の 1 軸です。以下は同じ cluster を隣接する軸から扱った記事群で、payment を実装するときに対で参照すると走査漏れが減ります。

• currenciesAccepted で多通貨を JSON-LD に書き出す — 本記事の payment method 軸と対になる currency 軸。訪日インバウンド向けの JPY / USD / EUR / CNY / KRW の書き分けと 3 source path (schema.org / GBP / 食べログ) の dispatch 差。
• バリアフリー属性を accessibilityFeature で構造化する — payment と並ぶ amenity attribute の accessibility 軸。DefinedTerm + sameAs パターンは共通。
• foundingDate で老舗度を 4 AI 引用に接続する — 同じ LocalBusiness 配線でも、現在属性 (payment) に対する歴史属性 (age / establishment) の軸。「創業 100 年の老舗、Visa / PayPay 対応」のような rich 引用の構成要素。
• Q&A ページを QAPage で構造化する — 「PayPay 使えますか」のような頻出質問を QAPage の question / acceptedAnswer で構造化しておくと payment の DefinedTerm と cross-reference されて断定率が上がる。
• Menu / MenuItem を hasMenu で構造化する — メニュー単位の priceCurrency と business 単位の currenciesAccepted の使い分け。
• reservation の availability を JSON-LD で伝える — 同じ Restaurant 型の state field 軸。dateModified の更新運用は payment と共通。
• Knowledge Graph と entity linking — sameAs で公式 URL に線を引くことで KG 経由の entity resolution を強化する原理。PayPay / JCB の brand entity 接続と同じ枠組み。
• NAP consistency と entity reconciliation — first-party JSON-LD と GBP と第三者を突き合わせる整合原則の payment 版。
• 3 つの provenance 経路 — first-party / Google / third-party の 3 系統で同じ事実を裏取りする一般化。PayPay 加盟店リストは third-party path に相当。
• AI 引用の前提条件 — そもそも AI に引用させるための前提整理。acceptedPaymentMethod の記述だけで押し切れない理由の根本。