なぜ基本のマークアップでは足りないのか？

多くのサイトはOrganization・Article・FAQPageをページごとにバラバラに出しています。しかしAIエンジンから見ると、トップページの「株式会社○○」と記事ページの「株式会社○○」が同一エンティティかどうかは自明ではありません。@graphと@idを使うと、「この記事の著者は、トップページで定義したこの組織である」という関係を明示できます。つまり応用の目的は「リッチリザルト」ではなく、エンティティの同一性の機械可読な保証です。基本実装は構造化データ・技術実装を参照してください。

@idアンカーはどう設計するか？

@idには永続的で一意なURL形式の識別子を使います。慣例として「公式URL＋#org」「＋#product」のようなフラグメント識別子が使われます。設計の規律は3つです：

  • 組織の@idはサイト全体で1つだけ——全ページのJSON-LDが同じ@idを参照する
  • 記事・FAQ・商品のJSON-LDは、author／publisher／brandで組織の@idを指す
  • sameAsで公式アカウント・Wikidata・ディレクトリへ双方向に接続し、外部のエンティティ台帳と一致させる——エンティティ設計

実行チェックリスト

  1. OrganizationのJSON-LDを「正典」として1箇所で定義し、@id・名称・別名（alternateName）・sameAsを確定する
  2. 全ページのJSON-LDを@graph構造に整理し、エンティティ間の関係を@id参照で結ぶ
  3. 多言語サイトは全言語版で同じ@idを使い、言語間でエンティティを分裂させない——多言語GEO
  4. テストツールで構文検証し、@idの参照切れがないか確認する
  5. 構造化データの値を四半期の棚卸し対象に含め、台帳とのドリフトを是正する

よくある落とし穴

最も多い失敗は@idの乱立です。テンプレートごとに異なる@idが発行され、同じ会社が5つの別エンティティに見える状態です。2つ目は構造化データと画面表示の不一致で、JSON-LDだけ立派に書いても、ページ本文や外部情報源と矛盾すればグラウンディングで弾かれます。構造化データは「宣言」であり、宣言は事実と一致して初めて信頼されます。効果の検証は計測SOPの引用率とブランド認知で行ってください。

よくある質問

@graphを使わないとだめ？
必須ではありませんが、ページ横断でエンティティの同一性を保証する現実的な方法は@id参照しかありません。バラバラのマークアップは検証ツール上は正しくても、関係グラフとしては機能しません。
@idはどんな文字列でもよい？
技術的には任意ですが、永続的で一意なURL形式（例：公式URL＋#org）が強く推奨されます。ドメイン移転やURL変更で@idが変わると、積み上げた同一性の保証が失われます。
構造化データを入れれば引用は増える？
直接の順位・引用レバーではありません。役割は事実の機械可読化とエンティティ同一性の保証で、グラウンディングの通過率を上げる土台です。効果は設置の有無ではなく引用率の変化で測ってください。