ビジネスを Knowledge Graph に配線する: sameAs・@id で AI 引用の同定を確かにする
「店名と住所を統一しましょう」は文字列レベルの症状対処だ。その上にある決定層、すなわち @id と sameAs による URI 明示宣言で店舗エンティティを Knowledge Graph に配線する層を、コードと依存関係の表でエンジニア視点から読み解く。
一見すると些末で、実は些末でない問題があります。あなたの店舗は、Web 上に少なくとも 3 通りの文字列として存在しています。自社サイトには「ワインバル アイリス 青山店」、ディレクトリには「ワインバル アイリス（青山）」、そしてタベログには「ワインバル アイリス 青山」。人間はこの 3 つを一目で同じ店だと分かります。ところが「青山でワインが飲める店は?」と聞かれた AI アシスタントは、あなたを引用するかどうかを判断する前に、まずこの 3 つが同じ店を指すと決めなければなりません。そして AI には、頼れる人間の直感がありません。手元にあるのは、3 つの文字列が同一エンティティを指すという証拠か、さもなくば当て推量だけです。
ローカルビジネスの最適化の多くは、この問題を「3 つの文字列を完全に一致させる」ことで解こうとします。これが NAP 一貫性のレイヤーです。店名・住所・電話番号を一字一句揃えて、モデルの文字列比較を楽にしてやる。NAP 一貫性をエンティティ解決の問題として読む で詳しく書いたとおり、これは確かに効きます。ただし、ある一点までは。その一点こそが、本稿の出発点です。文字列照合は推論だからです（モデルは「これらはたぶん同じ店だ」と結論づける）。そしてその上には、モデルに推論させるのをやめ、直接告げるレイヤーがあります。それがエンティティリンクであり、その 2 つの道具が @id と sameAs です。
推論と宣言の違い
この区別を鋭く立てておく価値があります。議論の全体がここに乗っているからです。
2 つの schema fragment がどちらも "name": "ワインバル アイリス 青山店"、"telephone": "+81-3-..." を持っているとき、エンティティを解決するモデルは文字列と属性を比較し、両者が同一を指す確率を割り当てます。きれいな NAP はその確率を上げます。しかしモデルは依然として「これらは同じ店に見える」と推論しているにすぎません。片方の surface で店名の文字列が変わったら（新しい支店サフィックス、ローマ字とカナの切り替え、リブランド）、確率は落ちます。あなたが与えた証拠は、文字列が一致しているという事実そのものだったからです。
@id と sameAs は、証拠の種類を変えます。「これらの文字列は似ている」ではなく、「この fragment とあの fragment は同じ識別子を担っている」と宣言する。モデルはもう表層特徴から同一性を推定しているのではなく、宣言を読んでいます。名前が揺れても同定は保たれます。そもそも同定は名前に乗っていなかったのですから。
これは四半期ごとに重みを増していきます。AI 引用を記述するフレームワークが、まさにこの一点に収束しつつあるからです。現在もっとも精密な LLMO は、エンティティの同定を「NAP フィールドからモデルが確率的に再構成すべきもの」ではなく「解決可能な URI で宣言するもの」として扱います。LLMO の急速な普及によって、エンティティ配線はもはや表記合わせの問題ではなく URI 宣言の問題として扱われつつあるのが現状です。LLMO Framework の Knowledge Clarity コンポーネント は、実質的に「あなたのエンティティが、単に綴りが一貫しているだけでなく、曖昧さなくアドレス可能であること」を要求しています。これは「文字列を一致させる」とは別の最適化対象であり、リブランドを生き延びるのはこちらのほうです。
@id: ビジネスに主キーを与える
@id は、あなたが店舗エンティティに割り当てる安定した URI です。いわば主キーです。一度これを持てば、サイト全体のあらゆるページで、あらゆる @type の中で、「その店についての」fragment はすべてこの @id を指せるようになり、モデルはそれらを 1 つのノードへ畳み込めます。
{
"@context": "https://schema.org",
"@type": "BarOrPub",
"@id": "https://wine-iris.example/#aoyama",
"name": "ワインバル アイリス 青山店",
"address": {
"@type": "PostalAddress",
"streetAddress": "3-13-14 Minamiaoyama",
"addressLocality": "Minato",
"addressRegion": "Tokyo",
"postalCode": "107-0062",
"addressCountry": "JP"
},
"telephone": "+81-3-xxxx-xxxx"
}ここでの @id は、あなたが管理する URI、すなわち自社ドメイン上の canonical なページに紐づけたフラグメント識別子（#aoyama）です。これは生きた文書として解決される必要はありません（解決されるに越したことはありませんが）。必要なのは、それが安定していることだけです。最大の過ちは、ページ URL が変わったときに @id まで変えてしまうことです。その瞬間、あなたはモデルに「古いエンティティは消滅し、新しいエンティティが出現した」と告げたことになります。
見返りは、これを再利用したときに来ます。メニューページが発行する Offer の offeredBy が {"@id": "https://wine-iris.example/#aoyama"} を指す。口コミページが発行する aggregateRating が同じ @id に付く。問い合わせページが完全な LocalBusiness を発行する。3 つのページ、3 つの @type 文脈、しかし同定は 1 つ。サイトをクロールするモデルは、推測せずにこれらを突き合わせます。その offeredBy 参照こそが、宙に浮いたメニューと、モデルがこの店のものだと知っているメニューを分ける配線です。
sameAs: 権威グラフへつなぐ
@id は同定を自社の surface の内側で解決します。sameAs はそれを世界の側に対して解決します。あなたのエンティティが、モデルが既に信頼しているグラフ内のノードと同一だと宣言するのです。
{
"@context": "https://schema.org",
"@type": "BarOrPub",
"@id": "https://wine-iris.example/#aoyama",
"name": "ワインバル アイリス 青山店",
"sameAs": [
"https://www.wikidata.org/wiki/Q00000000",
"https://www.instagram.com/wineiris_aoyama/",
"https://www.google.com/maps/place/?q=place_id:ChIJ...",
"https://tabelog.com/tokyo/A1306/A130601/00000000/"
]
}この配列の各 URI は、別種の裏付けです。Wikidata の QID は、多くのモデルの事前学習の土台にある構造化された公開知識グラフへあなたを錨で留めます。Google Place ID の URL は、Google 自身の surface が射影するエンティティへリンクします。公式サイトと認証済み SNS は、retrieval パスがもっとも到達しやすいオープン Web のノードです。タベログのような日本のディレクトリは、日本語圏のローカル文脈でモデルが繰り返し遭遇する第三者レコードです。これらが束になって、こう告げます。「この @id のエンティティは、あなたが既に別の名前で知っているこれらすべてと同じ実体だ」と。
どのエンジンがどの sameAs ターゲットをどれだけ重視するかは、公開仕様にもとづくアーキテクチャ推定であって実測された引用挙動ではありません（documented architecture-based inference, not measured citation）。各システムがエンティティ解決をどう行うかの公開記述を読み、どの錨が荷重を担うかを推論することはできますが、モデルが重みを割り当てる瞬間を観察することはできません。その但し書きを明示したうえで、私が作業の拠り所にしている地図がこれです。
sameAs ターゲット | 何に錨づけるか | なぜ重みを持つか |
|---|---|---|
| Wikidata QID | 公開された構造化知識グラフ | 事前学習に頻出し、言語を横断する canonical な曖昧性解消子 |
| Google Place ID の URL | Google の Knowledge Graph 射影 | Google 統合エンジンが最初に読む surface とエンティティを揃える |
公式サイト（@id のホスト） | 自社の first-party canonical | ループを閉じる: 権威グラフが、宣言した同定へ戻って指す |
| 認証済み SNS | オープン Web の裏付け | retrieval パスで到達可能、鮮度を補強 |
| タベログ等の日本ディレクトリ | 第三者のエンティティレコード | 裏付け密度は上がるが、Wikidata や認証済みプロフィールより信頼は低い |
順序づけが実用上のキモです。1 本の Wikidata リンクは、10 本のディレクトリリンクより多くの曖昧性解消をこなします。後者がモデルに「信じてくれ」と差し出す文字列を増やすだけなのに対し、前者はモデルが既に保持しているグラフに対してあなたを解決するからです。自社がもし Wikidata 項目を持てるだけの著名性があるなら（あるいは持てるよう育てられるなら）、その 1 本の URI は配列の中で最大のレバレッジを持つエントリです。
レイヤーがどこで積み上がるか
スタック全体を一度に見ておくと役立ちます。各レイヤーは、下のレイヤーにはこなせない仕事をしているからです。これは JA engineering スタックの「GBP を読む → type を選ぶ → NAP 文字列で照合する → URI で配線する」という 4 層の依存関係でもあります。本稿はその最上層にあたります。
| レイヤー | 道具 | モデルに何を告げるか | 取り除く失敗モード |
|---|---|---|---|
| 文字列一貫性 (NAP) | 一致する name / address / telephone | 「これらはたぶん同一を指す」 | surface 間のランダムな表記ゆれ |
| 内部同定 | ページ横断で再利用する @id | 「これらの fragment はすべて 1 つのエンティティ」 | メニュー / 口コミ / 営業時間が別の店として読まれる |
| 外部同定 | 権威 URI への sameAs | 「その 1 つのエンティティは、この既知のノードだ」 | モデルが既知の事実とあなたを結びつけ損なう |
NAP 一貫性は床であって天井ではありません。必要ではあります。矛盾した電話番号は、どれだけ良い sameAs 配列を持っていてもあなたを沈めます。GBP の射影そのものがどう @id を運んでいるかは GBP を JSON-LD として読み解く で扱いました。けれど NAP がこなしているのはもっとも弱い種類の仕事であり、時間とともに変化していくビジネスの平凡なエントロピーに、もっとも晒されたレイヤーでもあります。@id と sameAs は、文字列が動いたときに持ちこたえるレイヤーです。
ここに正直な皮肉があります。NAP がきれいであるほど、sameAs 配列が救済すべきものは少なくて済む。逆に、支店とリブランドとバイリンガル表記でこんがらがった現実であるほど、sameAs の出番は増える。エンティティリンクをもっとも必要とするビジネスは、まさに文字列を整然と保てないほど絡まったビジネスなのです。MEO 業者がよく訴える「店名と住所を統一しましょう」は、この絡まりに対する文字列レベルの症状対処です。URI 配線という決定層を置かない限り、同定は最後まで確率任せのままになります。
今日できる 1 つのこと
もっとも重要な店舗を 1 つ選び、それに本物の @id（自社ドメイン上の安定した URI）を与えてください。次に sameAs 配列を加えます。最低でも、認証済みの Google Place ID の URL、公式サイト、主要な認証済み SNS の 3 本。Wikidata 項目を見つけられる（あるいは作れる）なら、その QID を先頭に置きます。
そのうえで、エンティティが実際に解決されるかを確認します。
curl -sL https://your-domain.example/ \
| grep -oE '<script type="application/ld\+json">[^<]+</script>' \
| sed -E 's|</?script[^>]*>||g' \
| python3 -c 'import sys,json; d=json.load(sys.stdin); print("@id:", d.get("@id")); print("sameAs:", d.get("sameAs"))'@id が None で返ってきたら、あなたのビジネスには主キーがなく、それについてのすべての fragment は独立に宙を漂っています。sameAs が None で返ってきたら、あなたはモデルに「推論だけで権威グラフと私を結びつけてくれ」と頼んでいることになります。どちらも午後 1 回で直せますし、見た目より安く済みます。新しい事実を足すのではなく、モデルが既に持っている事実すべてが 1 つのエンティティに属する、とだけ告げる作業だからです。AEO や GEO が回答文面の言い回しを最適化するのとは、層が違います。エンティティリンクが最適化するのは、モデルが「何を言うか」に至る前に「あなたが誰か」を解決できるか。もっと手前の、もっと低い層です。用語の境界が曖昧なままなら、LLMO と SEO・AEO・GEO の整理 が私の一段落より丁寧に線を引いてくれます。
最後の但し書きは、この層のすべてに当てはまるものと同じです。エンジンが今日どう権威 URI に重みづけるかは snapshot であり、snapshot は動きます。それでも、根底にある命令文、すなわち「これが私の識別子で、これがその同一物だ」は、構造化データで言えることの中でおそらくもっとも長持ちします。文字列は揺れます。よく選ばれた URI は、揺れません。
関連記事
- NAP 一貫性をエンティティ解決の問題として読む: 本稿が積み上がる土台となる、文字列照合の床のレイヤー
- GBP を JSON-LD として読み解く: Google 自身の射影が既に運んでいる
@idと、それに矛盾せず合わせる作法 - Knowledge Clarity（LLMO Framework）: 曖昧さなくアドレス可能なエンティティが、一級の引用入力として扱われる理由