AI検索のための構造化データ、いま何が効くのか

構造化データがAIアシスタントに対して実際にしていること

「近くで一番の歯医者」や「この部品はどこで買えるか」といった質問に答えるAIアシスタントは、まずクローラー、つまりウェブページを訪れて内容を写し取るプログラムを送り出し、あなたのサイトを読みます。ラベルがなければ、そのクローラーには文字の壁が見えるだけで、意味を推し量るしかありません。「555-0134」は電話番号でしょうか、それとも製品コードでしょうか。構造化データは、JSON-LDと呼ばれる小さなコードの塊で事実を包むことで、この当て推量を取り除きます。それはページ上に静かに置かれ、事実上こう述べます。これが電話番号、これが価格、これが開店時刻だ、と。

OpenAI自身のドキュメントは、同社のクローラーGPTBotが従来の検索エンジンとほぼ同じやり方で公開されたウェブページを取得すると認めていますし（OpenAI）、Googleの構造化データの案内は、これらのラベルがプログラムに「ページの内容を理解する」助けになると明言しています（Google Search Central）。どちらの会社もこのラベル付けを無視するとは言っていません。したがって実務上、従来の検索のために追加するのと同じJSON-LDの塊が、あなたの顧客が移りつつあるアシスタントにも読まれています。一度も追加したことがないなら、今日あなたの事業について答えているアシスタントは、事実ではなく推測を頼りに動いています。

手間をかける価値のある4つの型

schema.orgはRecipeからMovie、Airportまで数百の型を列挙していますが、ふつうの中小企業なら、アシスタントが引用しそうな事実のほとんどを覆うのに4つで足ります。これらを入れて、残りは気にしないでください。

• Organization。あなたの事業を名前を持つ一つの実体として確立し、ロゴと公式ソーシャルプロフィールへのリンクを添えます。これでInstagramのアカウントとウェブサイトが同じ「ドロレスのパン屋」に属することをアシスタントが判別できます。
• LocalBusiness。実店舗や対応地域を持つ人のために作られたOrganizationの拡張で、営業時間、電話番号、地域を運びます。「いま開いているか」に答えるためにアシスタントが必要とするのは、まさにこの細部です。
• ProductとOffer。売っているものに実際の価格、通貨、在庫状況を結び付けます。これでアシスタントは競合数社の推測を平均するのではなく、あなたの本当の数字を引用します。
• FAQPage。質問と回答の組を、アシスタントがすでに好んで抜き出し、そのまま利用者に返す形そのままで並べたものです。

機械が読める確認が、実体の同定に何をもたらすか

オースティンでパン屋を営むドロレスを思い浮かべてください。彼女にはGoogleビジネスプロフィール、Yelpのページ、Instagramのアカウント、そしてウェブサイトがあります。「ドロレスのパン屋」への言及がインターネット上に四つ散らばっているわけです。アシスタントが安心して彼女を推薦するには、まず実体の同定を解かねばなりません。四つの言及がすべて同じ実在の事業を指すのか、それともそのうち一つは別の街の別のドロレスのパン屋なのか、という判断です。

構造化データはアシスタントに近道を与えます。sameAsというschema.orgのプロパティを使えば、ドロレスは自分のサイトのOrganizationマークアップの中に、Instagram、Facebook、YelpのURLを直接列挙できます。これらのアカウントは自分のものだという、彼女自身の言葉による機械可読の確認です（schema.org）。これは、完全には信用していない情報源をまたいで似た名前と住所から一致を推測するより強い信号です。ドロレス本人が、読み違えようのない形式でそのつながりを保証しているのですから。

名前をめぐる競合が増えるほど、これは重みを増します。人口八千人の町に「ドロレスのパン屋」が一つなら、同定はたやすく片づきます。似た名前の四つの診療所と競う「リバーサイド歯科」は、区別につながるあらゆる細部、つまり正確な住所、正確な電話番号、確認済みのソーシャルリンクを必要とします。アシスタントが通りの先のライバルと混ぜてしまわないようにするためです。

今週すぐ手直しできる、コピー可能なJSON-LDの例

これをゼロから書くのに開発者は要りません。必要なのはテンプレートを埋めることです。ローカルビジネス向けのJSON-LDの塊は、application/ld+jsonという型を指定した一つのscriptタグの中に収まり、語彙をschema.orgのコンテキストとして宣言する行から始まります。その中で型をLocalBusinessに設定し、続けて正確な事業者名を入れたname項目と、ロゴを指すimage項目を置きます。

次に住所が来ます。これはPostalAddress型の入れ子のオブジェクトとして書き、streetAddress、addressLocality（市区町村）、addressRegion（都道府県や州）、postalCode（郵便番号）に分けます。一行のテキストではなくラベルの付いた四つの項目にするのは、そうすることで郵便番号を部屋番号と読み違えることなく「これは近いか」にアシスタントが答えられるからです。続いてtelephone項目と、priceRange項目（手ごろな価格帯なら「$」といった単純なもので構いません）が来ます。openingHoursSpecification項目は、曜日と時間を文章ではなく構造化された形式で列挙するので、「日曜定休」が「月曜定休」と読み違えられることがありません。最後にsameAs項目が、URLの配列を保持します。Instagram、Facebookのページ、Yelpの掲載、そして紛れもなくあなた自身である他のプロフィールです。

書き上げたら、その塊をトップページのコードの上のほうに一度だけ貼り付け、あとは触らずにおきます。Squarespace、Wix、Shopifyのようなサイト作成サービスを使っているなら、いまはたいていカスタムコードや構造化データのための設定欄が用意されており、サイトの他の部分に手を触れずにここへ追加できます。

省いてよいもの

schema.orgのすべての型が手間に見合うわけではありませんし、全部を追いかけるのは、先の4つに使うべき労力の無駄遣いです。

• BreadcrumbListのマークアップは、サイトの階層構造（ホーム＞メニュー＞ケーキ）を表し、従来の検索結果でナビゲーションの道筋を見せる助けにはなりますが、あなたの事業の事実についてはアシスタントに何も伝えません。過去の作業ですでに入っているのでなければ、省いてかまいません。
• 実際のレビューの裏づけのないAggregateRating。Google自身の構造化データのガイドラインは、実際には持っていない評価を偽って示すマークアップを明確に禁じています（Google Search Central）。裏づけのない水増しスコアをアシスタントに繰り返させるのは、勝ちではなく評判上の危険です。
• すべてのページでの深い入れ子や重複したマークアップ。Organizationとしての正体は、たいていトップページで一度きちんと宣言すれば足ります。何十ものページでばらばらに繰り返すと、アシスタントが突き合わせるべき矛盾した版を作ることになり、一度正しく宣言するより悪い結果になります。
• できたばかりで、ほとんど対応されていないschema.orgの型。この語彙自体は、レシピや空港といった狭い用途のために作られた型を数百も並べています（schema.org）。検索エンジンやアシスタントが実際に使うと文書化されているひと握りの型に入っていないなら、そのラベルは今日のあなたには何もしてくれません。

構造化データがちゃんと働いているか確かめる方法

コードを足すのは仕事の半分にすぎず、残り半分は読めることを確認することです。Googleの無料のリッチリザルトテストなら、ページのURLかコードそのものを貼り付けて、どの型が検出され、どの項目が欠けているかを正確に確かめられます（Google）。変更のたびに実行しておけば、打ち間違い、たとえばカンマ一つの欠落が塊全体を黙って壊してしまうような事故を、代償を払う前に捕まえられます。

そのテストが教えてくれるのは、コードが妥当だということです。ChatGPTが実際に確認済みの営業時間を回答に使ったかどうか、Perplexityがいまも競合を先に挙げているかどうかは教えてくれません。それは別の問いであり、Growliが答えるために作られたのはまさにその問いです。私たちはアシスタントが各プラットフォームで事業について実際に何と言っているかを追跡し、正しいコードと正しい回答のあいだにまだ隔たりがある箇所を示します。マークアップが役目を果たしていると決めつけるのではなく自分の結果を確かめたいなら、仕組みの説明をご覧ください。

FAQ