AIに会社を正しく伝える構造化データの書き方。OrganizationとFAQの実装手順

構造化データの書き方を調べても、会社情報のどこまでを書けばよいのか迷っていませんか。見本のコードをそのまま貼ると、自社の内容と合わない項目が残ることもあります。

結論として、ページに見えている会社情報と同じ値をJSON-LDで書くことが基本です。Organizationで会社の基本を伝え、FAQPageとArticleは中身が合うページにだけ付けます。この記事では、Googleの公式ドキュメントで確かめられる範囲に絞って項目の選び方から確認の手順までを整理しました。

読み終えるころには、自社サイトに入れる項目と入れる場所まで判断できるようになります。

1. AIが構造化データを読む意味

構造化データを書く意味は、会社名・所在地・連絡先を機械が取り違えない形で渡せることにあります。人が読む文章は、同じ情報でも書き方がページごとに揺れます。検索エンジンやAIは、その揺れを文脈から読み解く必要があります。構造化データは項目名と値の組で書くため、どの文字列が社名でどれが電話番号かがはっきりします。

Googleは公式ドキュメントで、構造化データはページの内容を理解する手がかりになると説明しています。一方で、ChatGPTやGeminiなどの生成AIが構造化データをどこまで回答に使うかは、各社が細かく公表していません。そのため「入れればAIに出る」と考えるのではなく、誤解の余地を減らす下準備として位置づけるのが現実的です。会社情報なら、項目は10個前後から始めるのが目安です。

現場でよくある失敗は、構造化データだけを整えてページの文章を古いまま放置することです。両者が食い違うと、どちらが正しいのか機械には判断できません。まずは会社概要ページを開き、社名・所在地・電話番号が最新かを確かめてください。

文章だけで伝える場合の限界

文章の中の会社情報は、表記の揺れが起こりやすい部分です。「株式会社」を前に付けるか後ろに付けるか、電話番号にハイフンを入れるかで見え方が変わります。フッター・会社概要・お問い合わせの3ページで表記が違うと、同じ会社だと読み取られにくくなります。正式な表記を1つに決めて構造化データに書けば、揺れを抑える基準になります。まずは3ページの表記を書き出し、違いがないかを並べてみてください。

AIの回答と会社情報の関係

生成AIは質問に答えるとき、ウェブ上の情報を集めて文章にまとめます。その途中で所在地や事業内容を取り違えると、回答の中で誤った説明が広がります。構造化データの使われ方は公表されていませんが、公式サイトの情報を明確にしておくことは取り違えを防ぐ土台になります。とくに移転や社名変更の後は、古い情報が残りやすい時期です。AIに自社名を聞いてみて、回答の所在地や事業内容が合っているかを確かめてください。

関連記事：llms.txtは意味ないのか？置く前に確かめたい役割と限界

2. JSON-LDで書く理由

構造化データは、Googleが推奨するJSON-LDという形式で書くのが最も扱いやすい方法です。構造化データの形式にはJSON-LD・Microdata・RDFaの3つがあります。MicrodataとRDFaは、ページのHTMLタグの中に属性として埋め込む書き方です。JSON-LDは本文とは別の1つのかたまりとして書けるため、デザインの修正に影響されにくくなります。

JSON-LDは、scriptタグのtype属性に「application/ld+json」を指定して書きます。置く場所はhead要素の中でも本文の中でもかまいません。中身は「@context」でschema.orgを指定し、「@type」で種類を決めて、その下に項目を並べる形です。会社情報の1かたまりなら、20〜40行ほどに収まるのが目安です。

よくある失敗は、テーマのHTMLにMicrodataが残ったまま、JSON-LDを重ねて書くことです。同じ会社の情報が2つの形式で別々に出ると、値の食い違いが起こりやすくなります。書き始める前に、今のページに構造化データがあるかを確認ツールで調べてください。

本文と切り離せる利点

JSON-LDの利点は、見た目のHTMLに手を入れずに情報を足せることです。デザインを作り直しても、JSON-LDのかたまりを残しておけば構造化データは消えません。反対にMicrodataは、タグを書き換えた拍子に属性が外れることがあります。担当者が替わっても壊れにくい点は、長く運用するサイトほど効いてきます。サイトの改修を予定しているなら、その前にJSON-LDへ移しておくと手戻りが減ります。

書き方の基本の形

JSON-LDは、波かっこで囲んだ中に「項目名」と「値」を組にして並べます。項目名と値はどちらも半角の二重引用符で囲み、組と組の間をカンマで区切ります。住所のように中にさらに項目を持つものは、波かっこを入れ子にして書きます。最後の組の後ろにはカンマを付けないという決まりがあり、ここが書き間違いの多い場所です。まずは会社名とURLの2項目だけで書き、確認ツールで通るかを試してください。

3. Organizationに入れる会社情報

Organizationには、会社概要ページに載っている基本情報をそのまま入れます。Googleの公式ドキュメントでは、Organizationに必須の項目は定められていません。そのため、自社が実際に公開している情報の中から、取り違えてほしくないものを選びます。項目を増やすほど良いわけではなく、ページで確かめられる値だけを書くのが決まりです。

最初に入れたいのは、name・url・logo・descriptionの4項目です。次に住所のaddress、電話番号のtelephone、問い合わせ用のemailを足します。公式のSNSがあれば、sameAsにそのURLを並べて同じ会社だと示せます。設立日のfoundingDateや正式名称のlegalNameも、会社概要に載せているなら入れておきます。

実務で多いのは、ロゴにサイズの小さい画像を指定してしまうケースです。Googleはロゴの画像に112×112ピクセル以上を求めています。ロゴのURLをブラウザで開き、画像が表示されて大きさが足りているかを確かめてください。

名前と説明文の決め方

nameには、ふだん名乗っている表記を入れます。「株式会社」を含めるかどうかは、サイトのロゴや見出しと同じにそろえます。登記上の名前が違う場合は、legalNameに正式名称を分けて書けます。descriptionは事業内容を1〜2文でまとめた説明にすると、ほかのページの文章と食い違いにくくなります。会社概要ページの冒頭の文を、そのまま書き写すところから始めてください。

sameAsで公式の窓口をつなぐ

sameAsは、公式サイト以外にある自社のページを並べる項目です。公式のSNSアカウントや、会社のことを説明した公的なページのURLを入れます。並べたページの社名や所在地が公式サイトと違うと、かえって情報の食い違いが目立ちます。入れる前に各ページのプロフィールを最新に直しておくのが順番です。まずは使っているSNSを書き出し、運用をやめたアカウントは外してください。

4. 所在地・連絡先の書き方

所在地は、addressの中に都道府県・市区町村・番地を分けて書くのが基本です。addressには、PostalAddressという種類の入れ子のかたまりを使います。1行にまとめて書くこともできますが、項目を分けたほうがどこが市区町村かが機械にはっきり伝わります。電話番号は、国番号と市外局番を含めた形で書くようGoogleの公式ドキュメントで勧められています。

PostalAddressの項目は、postalCode・addressRegion・addressLocality・streetAddress・addressCountryの5つです。addressRegionに都道府県、addressLocalityに市区町村、streetAddressに町名・番地・建物名を入れます。addressCountryには、日本なら「JP」と書きます。telephoneは「+81」で始め、市外局番の先頭の0を外した形が国番号付きの書き方です。

よくある失敗は、移転したのに構造化データの住所だけが古いまま残ることです。ページの住所は直しても、テーマやプラグインの設定に書いた値は見落とされがちです。移転や電話番号の変更があったら、構造化データの値も同じ日に直す手順にしてください。

本社と店舗が複数あるとき

本社と別に店舗や営業所がある会社は、Organizationを1つにまとめて会社全体を表します。各店舗の住所や営業時間は、店舗ページごとにLocalBusinessで書き分けます。会社全体のかたまりに複数の住所を詰め込むと、どれが本社なのか分かりにくくなります。1ページに1つの拠点を書く形にすると、ページの中身と構造化データがそろいます。拠点の一覧を作り、どのページにどの住所を書くかを先に決めてください。

電話番号とメールの表記

電話番号は、ページに見えている番号と同じ番号を書きます。代表番号と問い合わせ窓口の番号が違うなら、どちらを載せるかを決めてから書きます。メールアドレスを公開していない会社は、emailを入れないほうが安全です。公開していない情報を構造化データにだけ書くと、ページの内容と合わなくなります。会社概要ページに載っている連絡先だけを選び、そのまま書き写してください。

あわせて読みたい：GEO対策のための「構造化データ」完全ガイド：AI検索時代に生き残るためのSchema.org実装術

5. FAQPageを付けるページの選び方

FAQPageは、質問と回答がページの本文にそのまま見えているページにだけ付けます。Googleのガイドラインでは、構造化データの内容はページを見る人にも見えている必要があります。本文に無い質問をFAQPageにだけ書くのは、このガイドラインに反します。質問はサイトの側で書いたものに限り、利用者が答えを投稿するページにはQAPageという別の種類を使います。

2023年8月から、GoogleはFAQのリッチリザルトを表示する対象を政府や健康分野の権威あるサイトに絞りました。多くの会社のサイトでは、検索結果に質問が開いて並ぶ表示は出ません。それでも質問と回答の組を明確に示す書き方として、FAQPageは今もschema.orgの正しい語彙です。付けるページは、よくある質問のページや記事の終わりに質問をまとめたページが候補になります。

現場でよくあるのは、全ページに同じ質問を入れたFAQPageを付けてしまう失敗です。同じ質問がサイト中に並ぶと、どのページの答えなのかがぼやけます。質問はそのページの内容に合うものだけを選び、1ページあたり3〜5問ほどを目安にしてください。

付けてよいページの条件

FAQPageを付けてよいのは、1つの質問に1つの答えが書かれているページです。答えが利用者の投稿で複数並ぶページは、FAQPageではなくQAPageの対象になります。広告を目的とした質問と回答に使わないことも、Googleのガイドラインに書かれています。回答の全文を構造化データにも入れるのが決まりで、途中で切った要約にはしません。よくある質問のページを開き、質問ごとに答えが1つにまとまっているかを確かめてください。

同じ質問をくり返さない

同じ質問と回答が複数のページに載っている場合、Googleはサイト全体で1か所だけに印を付けるよう求めています。たとえば料金の質問をサービスページとよくある質問のページの両方に載せているなら、どちらか一方に絞ります。残すのは、その質問への答えが最も詳しいページです。ページごとに質問を書き分けると、各ページの役割もはっきりします。サイト内の質問を一覧にして、重なりがないかを先に洗い出してください。

6. 記事ページに付けるArticleの基本

記事ページには、題名・公開日・更新日・書き手を伝えるArticleを付けます。Googleの公式ドキュメントでは、Articleに必須の項目はなく、当てはまる項目を足すほど内容が伝わりやすいとしています。記事は会社の考え方や専門性が出る場所なので、誰が書いたかを示す意味があります。会社情報のOrganizationとつなげておくと、記事と会社の関係もはっきりします。

入れたい項目は、headline・image・datePublished・dateModified・authorの5つです。headlineには記事の題名、imageにはアイキャッチなどの画像のURLを入れます。日付は「2026-10-12」のような決まった形で書き、時刻とタイムゾーンを添えることもできます。authorには書き手の名前を入れ、会社として書いた記事ならOrganizationを書き手に指定できます。

よくある失敗は、記事を書き直したのにdateModifiedが公開日のままになっていることです。反対に、中身を変えていないのに更新日だけを新しくするのもページとの食い違いになります。記事を直したときは、本文の更新日と構造化データの日付を同じ日にそろえてください。

書き手の情報を添える

authorには、書き手の名前と、その人の経歴を紹介したページのURLを入れられます。Googleは、書き手が複数いるときは1人ずつ分けて書くよう案内しています。会社として発信する記事なら、書き手にOrganizationを指定して会社名と公式サイトのURLを入れます。名前だけで経歴のページが無いと、誰が書いたかを確かめる手がかりが少なくなります。書き手を紹介するページを1つ用意し、記事からそのページへ案内してください。

公開日と更新日の扱い

datePublishedは最初に公開した日で、記事を書き直しても変えません。dateModifiedは、本文に意味のある修正を加えた日に新しくします。誤字を1文字直しただけの日に更新日を変えると、読み手には中身が変わったように見えます。更新日を変える基準を社内で決めておくと、日付の付け方がぶれません。数字や手順を直したときだけ更新日を変えるなど、基準を1文で書いておいてください。

7. WordPressでの入れ方

WordPressでは、テーマ・プラグイン・コードの追加のどれか1つに決めて構造化データを入れます。方法を混ぜると、同じOrganizationが2つ出るなどの重複が起こります。SEO用のプラグインの多くは、設定画面で会社名やロゴを入れるとOrganizationを自動で出力します。テーマによっては、最初から記事用の構造化データを出しているものもあります。

手で書く場合は、テーマのfunctions.phpに処理を足し、wp_headというフックでhead要素の中にJSON-LDを出す形が一般的です。テーマのファイルを直接直すと更新で消えるため、子テーマを使うかコードを追加するプラグインを使います。作業の前には、サイト全体のバックアップを取っておきます。設定から確認までは、会社情報だけなら1〜2時間ほどが目安です。

よくある失敗は、プラグインの自動出力を残したまま手書きのJSON-LDを足してしまうことです。値が少しずつ違う2つのOrganizationが並ぶと、どちらを信じればよいか分かりません。入れる前にページのソースを開き、「application/ld+json」で検索して今出ているものを数えてください。

プラグインで入れるときの注意

プラグインで入れる場合は、設定画面の項目をすべて埋めたかを確かめます。会社名・ロゴ・SNSのURLなどが空欄のままだと、出力されるOrganizationの中身が足りません。プラグインの更新で出力の形が変わることもあるため、更新した後は確認ツールで見直します。テーマとプラグインの両方が出力していないかも、入れた直後に確かめておきたい点です。設定を終えたら、トップページと記事ページの2ページで出力を確かめてください。

手で書くときの置き場所

手で書く場合、Organizationはトップページか会社概要ページに置くようGoogleは勧めています。全ページに出す必要はなく、値を直すときに1か所で済む作りにしておきます。FAQPageはよくある質問のページだけ、Articleは記事ページだけに出すようページの種類で出し分けます。出し分けの条件をコードの中に書いておくと、後から見た人にも分かります。どのページに何を出すかを表にしてから、コードを書き始めてください。

こちらも読まれています：名古屋市の会社が取り組むAI検索対策。ChatGPTに名前が出る条件の基本

8. 確認ツールでのチェック方法

構造化データを入れたら、リッチリザルトテストとスキーマ マークアップ検証ツールの2つで確かめます。リッチリザルトテストはGoogleが提供するツールで、検索結果で使える形になっているかを判定します。スキーマ マークアップ検証ツールは、schema.orgの語彙として正しく書けているかを広く調べます。2つを使い分けると、Googleの表示に関わる誤りと書き方の誤りの両方を拾えます。

使い方は、どちらもページのURLを入れるかコードを貼り付けてテストを実行するだけです。結果には、見つかった構造化データの種類と、エラーや警告の数が出ます。エラーは直さないと読み取られない誤りで、警告は足すと良い項目の案内です。公開した後も、テーマやプラグインを更新したときと月に1回ほどはテストをかけ直すのが目安です。

よくある失敗は、テストでエラーが出ないことを確かめただけで値の中身を見ないことです。電話番号の数字が1つ違っていても、形式が正しければエラーにはなりません。テストの結果に出た値を1つずつ開き、会社概要ページの表記と読み比べてください。

確認ツールの使い分け

リッチリザルトテストは、Googleが対応している種類だけを判定します。そのため、Googleの表示の対象から外れた項目は結果に出てこないことがあります。スキーマ マークアップ検証ツールは、schema.orgの語彙すべてを対象に項目名の綴りや入れ子の形を調べます。両方でエラーが無いことを公開の条件にしておくと、確認の抜けが減ります。まずはトップページのURLを2つのツールに入れ、結果を並べて見てください。

定期的に点検する方法

構造化データは、入れた後もテーマやプラグインの更新で中身が変わることがあります。更新の後と会社情報を変えた日には、確認ツールで同じページをかけ直します。株式会社TROBZが提供するトロパスの「AIサイト監査」では、構造化データ・llms.txt・AIの巡回ロボットへの設定を100点満点で点検できます。点検の日を毎月決めておくと、気づかないうちに壊れている状態を防げます。点検したページと結果を記録に残し、前の月と比べられるようにしてください。

9. よくある記述ミスと直し方

よくある記述ミスは、全角の記号・カンマの過不足・ページとの値の食い違いの3つに集まります。前の2つは書き方の誤りで、確認ツールでエラーとして見つかります。最後の1つは形式が正しいため、ツールでは見つからない誤りです。直す順番は、エラーの出る書き方の誤りを先にして、そのあとで値の中身を読み比べます。

書き方の誤りで多いのは、二重引用符やカンマを全角で入力してしまうことです。文章を書くソフトからコピーすると、引用符が自動で全角や曲がった形に変わることがあります。コードはテキストエディタで書き、貼り付ける前に記号が半角かを確かめます。直すのにかかる時間は、1か所なら数分ほどで済みます。

実務での傾向として、制作会社が入れた構造化データを誰も見直さず、数年前の情報が残っていることがあります。担当者が替わると、どこに書かれているかも分からなくなります。今の出力を確認ツールで読み、値を1つずつ会社概要ページと照らし合わせてください。

書き方の誤りを直す手順

エラーが出たら、確認ツールが示す行番号の前後を見ます。示された行そのものではなく、1つ前の行のカンマや閉じかっこが原因のこともあります。波かっこと角かっこの数が、開きと閉じでそろっているかを数えるのも有効です。1か所直すたびにテストをかけ直すと、どの修正で直ったかが分かります。エラーが0件になるまで、この手順をくり返してください。

値の食い違いを防ぐ方法

値の食い違いは、構造化データとページの文章を別々に直すことから起こります。防ぐには、会社情報を1つの台帳にまとめて、そこから両方を直す流れにします。台帳には社名・住所・電話番号・URL・SNSのURLを並べ、変えた日も記録します。台帳を直した日に構造化データも直すと決めておけば、片方だけが古くなることを防げます。まずは会社情報の台帳を作り、今のサイトの値と照らし合わせてください。

10. 正しい情報がAIに届くサイトを保つために

正しい情報をAIに届け続けるには、構造化データを毎月の点検に組み込むことが欠かせません。会社の情報は、移転・電話番号の変更・事業の追加などで少しずつ変わります。そのたびにページと構造化データの両方を直す流れがあれば、古い情報が残りません。2026年現在、生成AIの答えは聞くたびに変わるため、一度の確認だけでは状態をつかめません。

点検の流れは、台帳の確認・確認ツールでのテスト・AIの答えの確認の3つに分けられます。台帳とテストは毎月、AIの答えの確認は同じ質問を月に数回くり返すのが目安です。AIに自社名を聞いて、所在地や事業内容の説明が合っているかを読みます。説明の誤りが見つかったら、その情報が載っているページと構造化データを見直します。

よくある失敗は、AIの答えを1回だけ見て合っていたから大丈夫と判断することです。答えは質問の言い方やAIの種類でも変わります。点検の担当者と日付を決め、結果を記録に残すところから始めてください。

AIの答えを読んで確かめる

AIに自社のことを聞くときは、質問を固定して毎回同じ言い方で聞きます。質問を変えると、答えが変わった理由が質問のせいなのか分からなくなります。ChatGPT・Gemini・Claudeなど複数のAIに同じ質問を投げると、AIごとの違いも見えてきます。トロパスでは、6つのAIの答えの文章をそのまま保存して読み返せます。どのAIが自社をどう説明したかを、月ごとに並べて確かめてください。

ツールで点検の手間を減らす

毎月の点検を手作業で続けると、担当者の手間が積み重なります。確認ツールのテストやAIへの質問を、決まった日にまとめて行うだけでも作業は短くなります。トロパスには、店舗情報の構造化データやよくある質問を作る機能もあります。作る・確かめる・直すを同じ場所で回すと、点検の抜けが減ります。まずは毎月の点検の日を予定表に入れ、1回目の結果を記録してください。

ページと同じ会社情報をJSON-LDでそろえる

構造化データの書き方は、ページに見えている会社情報を同じ値で書き写すことが基本です。Organizationで会社の基本を伝え、FAQPageとArticleは中身が合うページにだけ付けます。入れた後は確認ツールでエラーと値の両方を確かめ、台帳と一緒に毎月見直してください。

構造化データの書き方に関するよくある質問