AI検索 構造化データの優先順位｜最初に入れる3つと確認手順

AI検索向けに構造化データを入れるなら、順番はOrganization（組織情報）、Article（記事情報）、FAQPage（よくある質問）の3つからです。この3つを、それぞれバラバラのタグではなく@graphという入れ物で1つにまとめ、@idで相互に結びつけるところまでやれば、最初の一巡は終わりです。

この記事は、自社サイトをWordPressなどで運用していて、AI検索（AI OverviewsやChatGPT、Perplexityなど）を意識し始めた広報・Web担当の方に向けて書いています。読み終わる頃には、どの型から手を付けるか決められて、コピペできるJSON-LDと公開前チェックリストを持って作業に入れる状態を目指します。

扱うのは「AI検索を意識したときの優先順位と実装・確認」です。そもそも構造化データが何なのかという基礎や、AI検索対策全体の進め方はGEO対策のやり方を7手順で解説｜AIに引用される会社の始め方で扱っているので、全体像から知りたい方は先にそちらをどうぞ。

Contents / 目次

1. AI検索向けの構造化データは、Organization・Article・FAQPageの3つから入れる
2. AI検索で構造化データが効く場所と、効かない場所
3. JSON-LDの入れ方。3つをまとめて実装する5ステップ
4. 構造化データでよくある失敗5つと回避法
5. 入れたあとに何が変わるか。測れる変化と、測れない変化
6. 導入して分かる落とし穴。プラグイン任せと外注見積もりで見落とすところ
7. まず自社サイトのソースを開いて、いま何が出ているか数えてください

AI検索向けの構造化データは、Organization・Article・FAQPageの3つから入れる

優先順位は、Organization、Article、FAQPageの順です。理由は単純で、AI検索が答えを組み立てるときに困るのが「誰が言っているのか」「いつの話なのか」「質問と答えの対応はどれか」の3点だからです。この3つの型は、ちょうどその3点を機械が読める形で置き直したものになります。

構造化データとは、ページに書いてある内容を、決められた語彙（schema.org）を使って機械が読める形式で書き添えたものです。人が読む本文はそのままで、裏側に「この文字列は会社名」「この日付は更新日」というラベルを付けるイメージだと思ってください。

逆に、いきなりProductやHowToから入れる必要はありません。型を増やすほど本文との食い違いが増え、あとで直す箇所も増えます。まず3つ、そのあと自社に該当する型を足す、という順番が結局いちばん早いです。

型	AI検索に伝わること	置く場所	優先度
Organization	この情報を出しているのはどの会社か。所在地・連絡先・公式SNSまで含めた「実在する組織」の輪郭	全ページ共通（サイト全体のテンプレート）	1番目
Article	記事の見出し・著者・公開日・更新日。いつの情報で、誰が書いたか	コラム・お知らせなど記事ページのテンプレート	2番目
FAQPage	質問と答えの対応関係。どの答えがどの問いに対応しているか	本文にQ&Aを実際に載せているページのみ	3番目
BreadcrumbList	サイト内でのそのページの位置づけ	全ページ（多くのテーマ・プラグインが自動で出力）	すでに出ていれば触らない
Product / HowTo / LocalBusiness など	商品情報、手順、店舗情報	該当ページのみ	3つが終わってから

3つを別々に入れないこと。Organization、Article、FAQPageを3つの独立したscriptタグでバラバラに置くと、機械から見ると「関係が書かれていない3つのデータ」になります。@idで結びつけて1つの@graphにまとめるところまでが、この作業のゴールです。

この章の結論として、迷ったらOrganizationを先に固めてください。記事の著者も発行元も、最終的にはここへつながります。ここが曖昧なまま記事側だけ整えても、つなぎ先のない参照が増えるだけになります。

AI検索で構造化データが効く場所と、効かない場所

構造化データは「入れれば引用される」ものではありません。AI検索に表示させるための特別なマークアップや専用ファイルがあるわけではなく、考え方は通常の検索と同じです。最新の要件はGoogle検索セントラル「構造化データの仕組みについて」で確認してください。

では何のために入れるのか。効くのは「解釈のブレを減らすこと」です。本文に書いてある情報を、機械が拾い間違えたり、他社の情報と取り違えたりする余地を減らす作業だと考えてください。

たとえば「更新日」。本文の隅に小さく書いた日付を、機械が公開日と読むか更新日と読むかは保証がありません。datePublishedとdateModifiedで明示しておけば、少なくとも取り違えは起きません。

一方で、効かない場所もはっきりしています。次の3つは、構造化データをどれだけ丁寧に書いても解決しません。

• 本文が薄いこと：本文に書いていない価値は、マークアップからは生まれません。構造化データは本文の要約であって、追加情報ではありません。
• そもそも読まれていないこと：クローラーがページを取得できていない、robots.txtでAIクローラーを止めている、といった手前の問題は別の話です。AIクローラーの拒否設定｜学習用と検索用のボットを分ける手順で、どのボットを通すかを先に確認しておくと安全です。
• 引用の保証：どの情報源を引くかは各AIサービス側の判断です。マークアップは、選ばれる候補として誤解なく理解される確率を上げるものであって、順位や引用を約束するものではありません。

FAQPageが検索結果にどう表示されるかは、Google側の仕様によって変わります。現在の扱いはGoogle検索セントラル「FAQ（よくある質問）の構造化データ」で、対象や表示条件を確認してください。表示の有無にかかわらず、質問と答えの対応関係を機械が読める形にしておく価値は残ります。表示枠を狙って設問を水増しするのではなく、実際に聞かれた質問だけを残す方向で運用してください。

この章の結論はこうです。構造化データは「引用されるためのスイッチ」ではなく「誤解を減らす保険」です。だから、本文の質を上げる作業と並行して、コストの低いところから淡々と入れるのが正解になります。検索1位なのにAIに引用されない状態が続いているなら、原因はマークアップより手前にあることが多いので、検索1位でもAIに引用されない理由と、引用される会社の共通点もあわせて確認してみてください。

JSON-LDの入れ方。3つをまとめて実装する5ステップ

実装形式はJSON-LDで構いません。どの形式を使うかはGoogle検索セントラル「構造化データの仕組みについて」で現在の扱いを確認してください。HTMLの本文に属性を埋め込むmicrodata形式と違い、本文と分離しているので修正箇所が1か所にまとまります。

ここからは、3つの型を1つの@graphにまとめるまでを5つのステップに分けて説明します。作業量は、既存の出力状況とテンプレートの数で大きく変わります。着手前に、直すテンプレートが何本あるか、組織情報や著者ページの整理が要るかを数えてから予定を組んでください。

ステップ1. サイト全体の情報をOrganizationで1つに固める

最初にやるのは、会社情報の「正本」を1つ決めることです。会社概要ページ、フッター、Googleビジネスプロフィール、SNSのプロフィール欄で表記が食い違っていると、機械側でも同じ会社だと結びつきません。

Organizationで埋める項目は、次の7つから始めると実務で足ります。どのプロパティが使えるかはschema.org「Organization」、Googleが求める要件はGoogle検索セントラル「組織（Organization）の構造化データ」で確認してください。

プロパティ	入れる値	つまずきやすい点
name	登記上の正式名称	「株式会社」の位置と、略称の混在をなくす
url	トップページのURL	httpsとwwwの有無を、実際に表示されるURLに揃える
logo	ロゴ画像の絶対URL	相対パスは不可。透過PNGなど実在するファイルを指定
description	事業内容を1〜2文で	会社概要ページの記述と同じ内容にする
address	PostalAddressで郵便番号・都道府県・市区町村・番地	1行の文字列ではなく、項目ごとに分ける
contactPoint	電話番号と対応言語	電話番号は国番号付き（+81-97-…）で書く
sameAs	公式SNS・公式アカウントのURL配列	止まっているアカウントは載せない

sameAsは、この会社が別の場所でも同じ会社として存在していることを示す項目です。運用が止まったアカウントを並べるより、動いている2〜3個に絞るほうが実態と合います。会社情報そのものの整え方はAI検索に引用される会社概要の作り方｜5ステップと構造化データで詳しく扱っています。

ステップ2. 記事ページにArticleを足して著者と更新日をつなぐ

Articleで先に埋めておきたいのは、authorとdateModifiedです。誰が書いたか、いつ更新したかは、本文からは機械が判別しにくく、取り違えが起きやすい情報だからです。

著者はPersonで書き、可能なら著者ページのURLをurlと@idに指定してください。著者ページが無い場合は無理に作らず、まず組織名義（authorにOrganizationの@idを指定）で運用し、あとから人へ切り替えるほうが破綻しません。著者情報の詰め方は著者構造化データの書き方｜AI検索に引用されるJSON-LD実装で解説しています。

日付はISO 8601形式（2026-08-12T09:00:00+09:00）で、タイムゾーンまで入れておくと、公開・更新の前後関係があいまいになりません。日付の書式についてはGoogle検索セントラル「記事（Article）の構造化データ」で現在の指定方法を確認してください。

ステップ3. 本文にあるQ&AだけをFAQPageにする

FAQPageは、本文に実際に表示されているQ&Aだけをマークアップします。ユーザーに見えない内容のマークアップについては、Google検索セントラル「構造化データに関する一般的なガイドライン」の「コンテンツの品質に関するガイドライン」で扱われているので、実装前に一読してください。

設問は、実際に問い合わせで来た質問をそのまま使うのがいちばん確実です。acceptedAnswerのtextには、本文の答えと同じ内容を入れます。要約して短くしすぎると、本文と構造化データで内容がずれる原因になります。

1ページあたりの設問数に決まりはありません。数を目標にせず、本文に実際に載せているQ&Aの数だけをマークアップしてください。設問の作り方はAIに引用されるFAQの作り方｜実際に聞かれた質問で作る5手順を参考にしてください。

ステップ4. 3つを@graphで1つのscriptにまとめる

ここが山場です。@graphは、複数の構造化データを1つのまとまりとして書くための入れ物で、@idを使ってお互いを参照できます。下のコードは、そのまま値を差し替えれば動く完成形です。

<!-- 前提1. 記事ページのテンプレート（single.php等）の </head> 直前に出力する
     前提2. URL・日付・名称は［ ］の箇所を自社の値に置き換える
     前提3. FAQ部分は、本文にQ&Aを表示しているページだけ残し、
            無いページでは "FAQPage" のブロックごと削除する -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.co.jp/#organization",
      "name": "［株式会社サンプル］",
      "url": "https://example.co.jp/",
      "logo": {
        "@type": "ImageObject",
        "url": "https://example.co.jp/wp-content/uploads/logo.png"
      },
      "description": "［事業内容を1〜2文。会社概要ページと同じ文言にする］",
      "address": {
        "@type": "PostalAddress",
        "postalCode": "［870-0000］",
        "addressRegion": "［大分県］",
        "addressLocality": "［大分市］",
        "streetAddress": "［寿町0-0］",
        "addressCountry": "JP"
      },
      "contactPoint": {
        "@type": "ContactPoint",
        "telephone": "+81-97-000-0000",
        "contactType": "customer support",
        "areaServed": "JP",
        "availableLanguage": "Japanese"
      },
      "sameAs": [
        "［https://www.youtube.com/@自社チャンネル］",
        "［https://x.com/自社アカウント］"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://example.co.jp/#website",
      "url": "https://example.co.jp/",
      "name": "［サイト名］",
      "publisher": { "@id": "https://example.co.jp/#organization" },
      "inLanguage": "ja"
    },
    {
      "@type": "Person",
      "@id": "https://example.co.jp/author/sample/#person",
      "name": "［著者名］",
      "url": "https://example.co.jp/author/sample/",
      "jobTitle": "［役職］",
      "worksFor": { "@id": "https://example.co.jp/#organization" }
    },
    {
      "@type": "Article",
      "@id": "https://example.co.jp/column/sample/#article",
      "isPartOf": { "@id": "https://example.co.jp/column/sample/" },
      "mainEntityOfPage": { "@id": "https://example.co.jp/column/sample/" },
      "headline": "［記事タイトル。本文のH1と同じにする］",
      "description": "［記事の要約を1〜2文］",
      "image": [ "https://example.co.jp/wp-content/uploads/eyecatch.jpg" ],
      "datePublished": "2026-08-12T09:00:00+09:00",
      "dateModified": "2026-08-12T09:00:00+09:00",
      "author": { "@id": "https://example.co.jp/author/sample/#person" },
      "publisher": { "@id": "https://example.co.jp/#organization" },
      "inLanguage": "ja"
    },
    {
      "@type": "FAQPage",
      "@id": "https://example.co.jp/column/sample/#faq",
      "isPartOf": { "@id": "https://example.co.jp/column/sample/" },
      "mainEntity": [
        {
          "@type": "Question",
          "name": "［本文に載せている質問文をそのまま］",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "［本文に載せている答えをそのまま。要約しない］"
          }
        },
        {
          "@type": "Question",
          "name": "［2問目の質問文］",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "［2問目の答え］"
          }
        }
      ]
    }
  ]
}
</script>

ポイントは@idの使い方です。Organizationにhttps://example.co.jp/#organizationというIDを1回だけ定義し、あとは{ "@id": "..." }で参照します。同じ会社情報を何度も書き写す必要がなくなり、住所が変わったときの修正も1か所で済みます。

＃（シャープ）以降のIDの付け方は自由ですが、途中で変えないでください。#organizationと#orgが混在すると、機械から見ると別々の組織になります。実装前に「組織は#organization、サイトは#website、著者は#person」のように命名を決めて、社内メモに残しておくと後で助かります。

ステップ5. 3つのツールで確認して、公開後にもう一度見る

確認は、役割の違う3つを順番に使います。1つで済ませようとすると、片方で通ってもう片方で落ちる状態を見逃します。

1. Schema Markup Validatorで、構文とプロパティ名がschema.orgの仕様に合っているかを見る。
2. Googleのリッチリザルトテストで、Googleが認識できているかを見る。ここで「検出された構造化データ」に3つの型が並べば、まず合格。
3. Google Search Consoleで、公開から数日〜数週間後に、実際にクロールされたページの状態を見る。どのレポートが表示され、何が確認できるかは対象のサイトと構造化データの種類によって変わるので、リンク先のヘルプで現在の画面名と対象範囲を確認してください。

3つ目が大事です。テストツールで通っても、本番でキャッシュやCDNが古いHTMLを返していたり、特定のテンプレートだけ出力が抜けていたりします。エラーが出たときは、次のチェックリストを上から順に当てていくと、原因の切り分けができます。

公開前のチェックは、次の10項目で足ります。

• JSON構文：末尾のカンマ、閉じカッコの過不足がないか
• URLの絶対指定：logo・image・urlが相対パスになっていないか
• @idの一貫性：参照側と定義側の文字列が1字も違わないか
• 本文との一致：headlineがページのH1と、FAQの文言が本文と同じか
• 日付の形式：ISO 8601でタイムゾーン（+09:00）が入っているか
• 二重出力：ページのソースに同じ型のJSON-LDが2つ以上ないか
• FAQの実在：FAQPageを入れたページに、実際にQ&Aが表示されているか
• 画像の実在：指定した画像URLをブラウザで開いて表示されるか
• テンプレート横断：記事・固定ページ・トップで、想定どおりの型が出ているか
• レンダリング：ソース表示（Ctrl+U / Cmd+U）の時点でJSON-LDが入っているか

JSON-LDのたたき台をAIに書かせるときの渡し方と確認ポイント

JSON-LDの下書きは、生成AIに任せると速いです。手で書くと必ずカンマ抜けが出るので、AIに骨組みを作らせて、人が値と@idを確認する分担が現実的です。

渡すのは完成されたプロンプトではなく、材料です。次の4つを添えれば、あとはAIとやり取りしながら詰められます。

• 会社情報の正本：会社概要ページのテキストをそのまま貼る（表記揺れを持ち込まないため）
• 対象ページのHTML：本文のH1・見出し・Q&A部分。マークアップは本文の写しなので、原文が要る
• @idの命名ルール：「組織は#organization、著者は#person」など、自社で決めた形
• 出力条件：@graphで1つにまとめること、本文に無い情報を足さないこと

seedとしてはこの程度の短い指示で足ります。

あなたはschema.orgのJSON-LDに詳しいWeb担当者です。
下に貼るページ情報から、Organization・Article・FAQPageを
@graphで1つにまとめたJSON-LDを作ってください。

条件
- 本文に書かれていない情報は絶対に足さない（推測で埋めない）
- 値が分からない項目は ［要確認］ と書いて残す
- @idの命名は ［自社ルールを記載］ に従う

［ここに会社概要のテキストとページのHTMLを貼る］

そして、AIの出力で人が必ず見るのは次の3点です。ここを見ないなら、AIに任せる意味がありません。

1. 足されていないか。設立年、従業員数、受賞歴など、渡していない情報が入っていたら削除する。AIは空欄を埋めたがります。
2. プロパティ名が実在するか。それらしいが存在しないプロパティが混ざることがあります。Schema Markup Validatorに通せば一発で分かります。
3. @idが揃っているか。参照と定義でスペルが違っても、JSONとしては正しいのでエラーになりません。目視で突き合わせてください。

この章の結論です。作業の重心は「書くこと」ではなく「@idを揃えることと、本文との一致を確認すること」にあります。コードはAIに書かせて構いませんが、この2つの確認だけは人が引き受けてください。

構造化データでよくある失敗5つと回避法

ここで挙げるのは、構造化データの実装でしか起きない失敗です。どれも、テストツールでエラーが出ないまま静かに効かなくなるタイプなので、心当たりがあれば先に確認してください。

失敗1. プラグインとテーマで同じ型を二重に出している

起きる状況はこうです。WordPressのSEOプラグインがすでにArticleやOrganizationを出力しているのに、テーマのfunctions.phpや記事本文にも自前のJSON-LDを追加してしまう。ページのソースにapplication/ld+jsonが2つ、3つと並びます。

どうなるか。同じ型で内容の違うデータが並ぶと、どちらが正なのか判断できません。片方だけ更新して、もう片方に古い会社名や旧ロゴが残り続けるケースが特に厄介です。

防ぎ方はシンプルで、実装前にページのソースを表示してld+jsonで検索し、すでに何が出ているかを数えることです。すでにOrganizationが出ているなら、自前で足すのではなくプラグインの設定画面側で値を直します。どうしても自前に寄せるなら、プラグイン側の構造化データ出力を止めてから入れ替えてください。

失敗2. @idを振らず、組織・記事・著者がつながっていない

起きる状況は、型ごとにコードを検索して貼り付けたときです。Organization、Article、Personがそれぞれ独立して存在し、参照関係がありません。

どうなるか。テストツールはすべて「有効」と表示します。エラーが出ないので気づけません。ただし機械から見ると、記事の著者と会社の関係が書かれていないので、「この会社の誰が書いた記事か」が伝わりません。E-E-A-T（経験・専門性・権威性・信頼性）を構造で支えるつもりが、支えられていない状態です。

防ぎ方は、ステップ4の@graphにまとめること、そして@idの命名を先に決めることです。すでにバラバラに入っている場合は、型を足すより先に、既存のものを1つの@graphに統合する作業から始めてください。

失敗3. 本文に無いFAQや実績をマークアップしている

起きる状況は、「AIに拾わせたい情報」を構造化データにだけ書いてしまうときです。本文には載せていない想定Q&Aや、まだ公開していない受賞歴を入れてしまう。悪意なく、良かれと思ってやってしまうのがこのパターンです。

どうなるか。ユーザーに見えない内容のマークアップの扱いは、Google検索セントラル「構造化データに関する一般的なガイドライン」に書かれています。措置の内容や条件は同ページで確認してください。そもそも、構造化データの内容が実態と合っていなければ、読んだ人の信頼を落とすだけです。

防ぎ方は、公開前チェックの「本文との一致」を必ず1項目ずつ目で追うことです。ルールは1つ、構造化データは本文の写しであって、追加情報を置く場所ではないと覚えてください。

失敗4. dateModifiedだけ更新して本文を直していない

起きる状況は、更新日を新しくすれば評価が上がると考えて、記事の中身は触らずに日付だけ書き換えるケースです。CMSによっては、誤字1文字の修正でもdateModifiedが自動で更新されます。

どうなるか。日付だけを新しくしても検索順位が上がるわけではありません。「更新日が新しいのに中身が古い」ページは、読んだ人の信頼を落とすだけです。dateModifiedは、本文を実際に手直ししたときに動かす項目だと考えてください。

防ぎ方は、更新の基準を先に決めることです。数値・仕様・手順のいずれかを実際に直したときだけdateModifiedを動かし、誤字修正は動かさない。CMSの自動更新が邪魔なら、更新日を手動指定できる設定に切り替えます。更新日と一次情報の扱い方はAIに引用される記事に直す手順｜更新日と一次情報の書き方で詳しく整理しています。

失敗5. JavaScriptで後から挿入していて、クローラーが取れていない

起きる状況は、タグマネージャーなどでJSON-LDを配信したときです。ブラウザの検証ツールで見ると確かに存在するので、実装できたと思ってしまいます。

どうなるか。ブラウザの検証ツールはJavaScript実行後のDOMを表示しています。実行前のHTMLしか取得していないクローラーからは、人には見えていて機械には見えていない状態になります。

防ぎ方は、確認をブラウザの検証ツールではなく「ページのソースを表示」（Cmd+U / Ctrl+U）で行うことです。ここにJSON-LDが無ければ、サーバー側で出力する方法へ切り替えます。WordPressならwp_headで出力するのが基本形です。

この章の結論として、5つのうち4つは「テストツールでエラーが出ない失敗」です。だから、エラーゼロを確認して終わりにせず、ソース表示での二重出力チェックと、@idの突き合わせを手作業で1回やってください。

入れたあとに何が変わるか。測れる変化と、測れない変化

正直に書くと、構造化データ単体の効果を数字で切り出すことはできません。同時に本文も直しているのが普通ですし、AI検索側の判断はブラックボックスです。「構造化データを入れて問い合わせが何件増えた」と言い切る記事は、その因果を確かめていないと思ってください。

そのうえで、確認できるものが2つあります。

見るもの	どこで見るか	変化のタイミング
構造化データの検出状況とエラーの有無	Search Console（表示されるレポートは対象サイトと型による）	クロール後、数日〜数週間
自社名で聞いたときのAIの答え方	ChatGPT・Perplexity等で手動確認	各サービスの情報更新次第

2つ目の手動確認は、月1回でいいので習慣にしてください。やり方は、自社名・サービス名・「（業種）＋（地域）＋おすすめ」の3パターンを聞いて、返ってきた答えのうち「事実として間違っている箇所」だけをメモします。所在地が違う、やっていない事業が挙がる、旧社名で呼ばれる、といった具体的なズレが見つかります。

そのズレの多くは、Organizationの情報が古いか、サイト内で表記が割れていることが原因です。構造化データを直す優先順位を決めるうえで、これがいちばん実用的な材料になります。

流入側の計測は、参照元の判定が難しい部分があります。設定の具体的な手順はSearch ConsoleでAI検索の表示回数を確認する手順｜GA4で補うにまとめているので、レポートを作る前に一度目を通しておくと迷いません。

この章の結論です。構造化データの成果は「引用が増えたか」ではなく、まず「エラーゼロを維持できているか」と「AIが自社を事実どおりに説明するか」で見てください。この2つが安定して初めて、流入の増減を議論する意味が出てきます。

導入して分かる落とし穴。プラグイン任せと外注見積もりで見落とすところ

実装より運用のほうが面倒だ、というのが現場の実感です。1回入れて終わりに見えて、あとから手が要る箇所が決まっています。

まずプラグイン任せの限界です。構造化データを自動で出力してくれるSEOプラグインは複数ありますが、出力できる型と項目はプラグインごとに違います。@graphの中に独自の型を差し込みたい、著者の@idを自社ルールに合わせたい、という段階で、標準の設定画面だけで届くかどうかが分かれます。まずは使っているプラグインの設定画面を一通り開いて、変えられる項目を確認してください。コードを書く場合は、更新のたびに壊れないよう子テーマかカスタムプラグインに置く前提で考えます。

次にコストの見落としです。構造化データの費用は「初回の実装費」だけで見積もられがちですが、実際に効いてくるのは更新の手間のほうです。住所変更、代表者交代、SNSアカウントの開設と閉鎖。これらが起きるたびにOrganizationを直す担当を決めておかないと、1年後には実態と違う会社情報を機械に配り続けることになります。

外注する場合は、見積書の「構造化データ対応」という一行を分解して聞いてください。確認するのは次の4つです。

• 対象の型と範囲：どの型を、どのテンプレート（記事・固定ページ・商品ページ）に入れるのか
• 既存出力の扱い：いまプラグインが出している構造化データを止めるのか、活かして上書きするのか
• @idの設計：組織・サイト・著者のIDをどう命名し、どこに記録として残すのか
• 更新時の手順：会社情報が変わったとき、自社の誰がどの画面で直せるのか（毎回外注に依頼が必要か）

この4つに即答できない相手だと、納品後に「直したいけど誰も触れない」状態になりがちです。逆に、4つ目まで具体的に答えてくれる会社は、運用まで考えて設計しています。外注先の見極め方全般はAIO対策に強い会社の選び方｜比較5軸と依頼前の確認10問で整理しています。

もう1つ、役割の混同にも触れておきます。実店舗があるとLocalBusinessを入れたくなりますが、あれは地図・営業時間・来店動線のための型で、AI検索に記事を引用させる話とは目的が違います。店舗集客が主目的ならGoogleビジネスプロフィール側の整備が先で、Webサイトの構造化データはその裏付けという位置づけになります。両方を同じ施策として管理すると、どちらも中途半端になります。

なお、たたき台の生成はAIに任せて、@idの整合と本文との一致だけ人が見る、という分担で十分回ります。この線引き自体はステップ4と5で書いたとおりなので、ここでは繰り返しません。

この章の結論です。構造化データで判断が必要になるのは、実装そのものではなく「既存出力をどう扱うか」と「誰が更新し続けるか」の2点です。この2つを先に決めてから着手すると、あとで作り直しになりません。

まず自社サイトのソースを開いて、いま何が出ているか数えてください

今日すぐできる最初の一歩は、自社サイトのトップページでソースを表示し（Cmd+U / Ctrl+U）、ld+jsonで検索して、いくつヒットするかを数えることです。2つ以上出ていれば、失敗1の二重出力を疑うところから始まります。そのうえでAI検索全体の打ち手を組み立てたい方は、LLMOとAIOとSEOの違いと実務の使い分け｜AI検索に引用される手順が次に読む1本として合っています。

ここまで読んで、「@idの設計や既存プラグインとの兼ね合いを自社で判断するのは難しそうだ」と感じた方もいると思います。構造化データは、入れること自体より、既存の出力と衝突させずに運用へ乗せるところで手が止まります。AIに引用される記事づくりと構造化の設計についてはAI検索で引用される記事制作の詳細はこちらで紹介しています。いまのサイトの状態を一緒に見るだけでも構いませんので、気軽にお声がけください。