AI検索に会社情報を正しく伝えるには？公式情報・構造化データ・更新元の整え方

AI検索や検索エンジンに会社情報を正しく伝えたいとき、最初に増やすべきものは「AI専用のタグ」ではありません。社名、サービス、所在地、連絡先などを人が確認できる公式ページにまとめ、その内容を更新する元データと担当を決め、実ページと同じ事実を構造化データにも記述することが先です。

Googleは、AIによる概要やAIモードへ表示されるための追加要件や特別な最適化はないと案内しています。新しいAI向けファイルや特別なschema.orgの型も必要ありません。一方で、重要な情報をテキストで示すこと、ページをクロール・インデックス可能にすること、構造化データを画面上の内容と一致させることは、従来の検索と同じく重要です。

つまり、会社情報の整備は「構造化データを先に書く作業」ではなく、次の順序で進めます。

1. 会社情報の更新元を決める
2. 公式ページの表示内容をそろえる
3. 表示内容と一致する構造化データを実装する
4. 公開後の取得状態と変更差分を確認する

この順序なら、コードだけが古くなる、ページごとに社名表記が違う、移転後も旧住所が残るといったずれを減らせます。ただし、構造化データを正しく実装しても、AI回答への採用、ナレッジパネル、リッチリザルト、検索順位は保証されません。この記事では、保証できない露出を追うのではなく、会社情報を矛盾なく管理し、検索システムが理解するための手掛かりを整える実務に絞って解説します。

構造化データより先に、会社情報の「公式」を決める

会社情報は、会社概要ページだけに存在するとは限りません。トップページのフッター、サービスページ、問い合わせページ、採用ページ、特定商取引法に基づく表記、Googleビジネスプロフィール、SNSのプロフィールなどにも、社名や住所、電話番号が掲載されます。掲載箇所が多いほど、変更時に一部だけ古い情報が残る可能性も高まります。

そこで最初に、公開情報ごとの更新元を決めます。ここでいう更新元は、Webページそのものではなく、「この情報が変わったとき、何を確認して公開内容を直すか」という社内の正本です。最低限、次の項目を一覧にします。

• 法人の正式名称と、サイト上で使うブランド名・略称
• 公式サイトの代表URL
• 本社、事業所、店舗など、公開対象ごとの住所
• 代表電話、問い合わせ窓口、予約窓口などの用途別連絡先
• 会社を代表するロゴ画像と公開URL
• 主なサービスや事業内容の短い説明
• 公式として案内する外部プロフィールのURL
• 各項目の更新元、確認担当、最終確認日

大切なのは、すべての情報を一つの文書へ無理に移すことではありません。登記情報は総務、店舗営業時間は店舗運営、問い合わせ先は営業やサポートというように、元になる情報が別々でも構いません。その代わり、Web担当者が「どこを見れば最新版か」を迷わない索引を用意します。

会社概要ページは、その索引から取り出した公開情報を一箇所で確認できる中心ページにします。ただし、サービスの詳細、店舗ごとの営業時間、問い合わせ方法まで一枚に詰め込む必要はありません。会社概要には会社全体の識別に必要な情報を置き、詳細ページへ明確にリンクします。検索システムだけでなく、取引先や応募者が確認するときにも、どの情報が公式なのか分かる状態を目指します。

更新元から公式ページ、構造化データまでを一方向につなぐ

会社情報の整備で避けたいのは、公式ページと構造化データを別々に手入力し、それぞれを独立して更新する運用です。たとえば会社概要を直した後、SEOプラグインの設定画面に旧住所が残れば、画面上とコード上で矛盾します。テーマとプラグインの両方がOrganizationを出力している場合は、同じ会社について異なる値が二重に記述されることもあります。

管理の流れは「更新元→公式ページ→構造化データ→検証」の一方向にします。人が読むページと機械向けの記述を、同じ事実から更新する考え方です。

会社情報は、更新元を確定してから公式ページへ反映し、その表示内容と同じ事実を構造化データへ記述します。最後に公開ページの取得状態と差分を確認します。

実際の担当表や確認日の持ち方まで整理したい場合は、ホームページ情報の正本はどこに置く？更新元・担当者・確認日の管理方法で、情報台帳の作り方を確認できます。本記事では、その台帳から会社情報を取り出し、公開ページとOrganization／LocalBusinessへつなぐ範囲を扱います。

更新作業の起点も決めます。たとえば移転なら、総務が住所変更を確定した時点でWeb担当へ通知し、会社概要、問い合わせページ、フッター、構造化データ、外部プロフィールを同じ変更チケットで確認します。「ページを直した人が、後で構造化データも思い出して直す」という運用にしないことが重要です。

変更対象を一覧にするときは、URLだけでなく出力元も記録します。WordPressでは、本文、テーマ設定、ウィジェット、SEOプラグイン、独自コードのいずれから会社情報が出ているかが分かれます。見た目では同じ住所でも、更新画面が異なることがあります。公開ページを検索するだけでなく、どの設定がHTMLやJSON-LDを生成しているかまで把握しておくと、二重出力や更新漏れを防ぎやすくなります。

名称・住所・電話・URL・ロゴを同じ事実としてそろえる

構造化データに多くの項目を追加する前に、会社を識別する基本情報をそろえます。項目数の多さより、画面上の表示、コード、外部の公式プロフィールが同じ対象を指していることが重要です。

正式名称とブランド名を混同しない

法人名とサービス名が異なる場合は、役割を分けて表示します。会社概要では運営会社の正式名称を明記し、サービス名だけを会社名のように扱わないようにします。構造化データでは、組織を表すname、登記上の名称を区別する必要がある場合のlegalName、一般に使われる別名を示すalternateNameなど、実態に合う項目を選びます。

ただし、構造化データだけに正式名称や別名を追加しても、人が確認できるページにその関係が示されていなければ整合しません。「サービス名を運営する会社はどこか」「略称は何を指すか」がページ上でも分かるようにします。サイト名、ロゴ内表記、会社概要、フッターの表記ゆれも同時に確認します。

URLは会社全体と各拠点を区別する

urlには、その組織または拠点を代表する完全なURLを使います。会社全体のOrganizationであれば通常は公式サイトの代表URL、店舗ごとのLocalBusinessであれば、その店舗の所在地や営業時間を確認できる個別ページが候補になります。

httpとhttps、wwwの有無、末尾スラッシュの違い、移転前ドメインなどを混在させず、現在の正規URLへそろえます。旧URLから転送しているだけの状態を永続的な正本にせず、構造化データと内部リンクは最終到達URLへ更新します。SNSや業界団体などのプロフィールをsameAsへ入れる場合も、会社が公式に管理している同一組織のページに限定します。検索結果ページや、会社名がたまたま掲載された第三者記事を同一性の根拠として並べる項目ではありません。

住所と電話番号は「何の連絡先か」まで確認する

本社住所、登記住所、店舗住所、郵送先が異なる会社では、一つの住所を全ページへ機械的にコピーしないようにします。会社全体の情報としてどの住所を公開するか、来店先として案内する拠点はどこかを分けます。LocalBusinessは物理的な拠点を表すため、オンライン相談だけを提供する会社や、来訪を受け付けていない事務所に、店舗と同じ情報設計を当てはめるのは適切とは限りません。

電話番号も、代表、問い合わせ、予約、採用など用途が違います。ページ上のラベルと構造化データが同じ窓口を指すようにし、現在使っていない番号を残さないようにします。GoogleのLocalBusinessガイドでは、電話番号に国コードと市外局番を含めるよう案内されています。公開表示を国内向けの形式にする場合でも、構造化データでどの形式を採用するかを決め、変更時に同じ元データから更新できるようにします。

ロゴはファイルの存在だけでなく、取得できる状態を確認する

Organizationのlogoは、会社を代表する正式ロゴの画像URLを指定します。Googleは、ロゴ画像を112×112ピクセル以上とし、クロールとインデックス登録が可能なURL、対応する画像形式にするよう案内しています。また、白背景でも意図した見え方になるかを確認する必要があります。

ロゴを差し替えた後も古いファイルURLを構造化データに残したり、開発環境のURLを指定したりしないようにします。CDNや画像最適化機能を使う場合は、公開URLへ未ログインでアクセスできるか、robots.txtや認証で遮断されていないかも確認します。複数のロゴバリエーションがある場合は、検索結果で会社を識別する代表ロゴを一つ決めます。

OrganizationとLocalBusinessは、表したい対象で選ぶ

構造化データの型は、検索で目立ちそうなものではなく、ページが表している実体に合わせて選びます。GoogleのOrganizationガイドは、必須プロパティを定めるのではなく、内容に当てはまる推奨プロパティを追加する考え方を示しています。また、情報はホームページまたは組織を説明する一つのページに置くことを勧めており、全ページへ同じOrganizationを繰り返す必要はないとしています。

会社情報でよく検討する型の違いは次のとおりです。

表したい対象	型の候補	ページと実装の考え方
会社・団体全体	Organizationまたは実態に合う具体的なサブタイプ	公式サイトのホームページか会社概要など、一つの中心ページで会社全体を説明する
オンラインストアの運営主体	OnlineStore	販売主体、連絡先、返品・配送方針など、実際に公開している販売者情報と一致させる
顧客が利用する物理的な店舗・事業所	LocalBusinessまたは具体的なサブタイプ	拠点の住所、電話、営業時間などを掲載するページで、拠点ごとに区別する
複数店舗・複数拠点	各拠点に対応するLocalBusiness	一つの住所へ全拠点をまとめず、個別ページと個別URLを用意できるかを確認する

LocalBusinessはOrganizationのサブタイプです。店舗や来店型サービスなど、物理的な場所の情報を伝える場合に適しています。選べる場合は、RestaurantやDentistなど、事業の実態に合う具体的なサブタイプを使います。一方、所在地があるという理由だけで、すべての法人サイトをLocalBusinessにする必要はありません。会社全体の識別が目的ならOrganization、顧客が訪れる個別拠点の案内が目的ならLocalBusinessというように、ページの役割から判断します。

会社全体と店舗を両方表す場合は、「一つのJSON-LDへ何でも詰める」のではなく、どのデータが会社全体で、どのデータが拠点固有かを区別します。店舗の営業時間や電話番号を会社全体の情報として誤って使わないようにします。複数の型を関連付ける高度な設計もできますが、まずは人が見ても会社と拠点の関係が分かるページ構成を整えることが先です。

実ページにある項目だけをJSON-LDへ入れる

構造化データは、画面に表示しない会社情報を隠して追加する場所ではありません。Googleの構造化データに関する一般ガイドラインでは、構造化データが表す内容はページ上でユーザーに見えるものでなければならず、誤解を招く情報を含めないことが求められます。AI機能向けのガイドでも、構造化データをページに表示されるテキストと一致させることが示されています。

まず会社概要ページに、社名、URL、ロゴ、住所、連絡先、事業説明、公式プロフィールへのリンクなど、公開して差し支えない情報を整理します。そのうえで、実際に掲載した項目から必要なプロパティを選びます。GoogleのOrganizationには必須プロパティがないため、空欄を埋めるために未確認の項目を作る必要はありません。

以下は、架空の会社概要ページを想定した最小例です。コピーして社名だけ差し替えるのではなく、自社ページに表示している項目とURLへ置き換えます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "株式会社サンプル",
  "url": "https://www.example.com/",
  "logo": "https://www.example.com/assets/logo.png",
  "description": "株式会社サンプルは、法人向けの業務支援サービスを提供しています。",
  "telephone": "+81-6-0000-0000",
  "address": {
    "@type": "PostalAddress",
    "postalCode": "000-0000",
    "addressRegion": "大阪府",
    "addressLocality": "大阪市",
    "streetAddress": "サンプル1-2-3",
    "addressCountry": "JP"
  },
  "sameAs": [
    "https://social.example.com/sample/"
  ]
}
</script>

この例で確認すべきなのはコードの形だけではありません。会社概要に「法人向けの業務支援サービス」という説明があるか、電話番号はそのページで案内する窓口か、住所は来訪先なのか登記住所なのか、sameAsのURLは自社が管理する公式プロフィールかを確かめます。公開しない住所や使っていない電話を、例に合わせて追加してはいけません。

実装方法は、テーマ、SEOプラグイン、専用プラグイン、タグ管理、独自コードなどがあります。どの方法でも、次の点を公開前に確認します。

• 同じOrganizationが複数の機能から重複出力されていないか
• 会社名、URL、ロゴ、住所が出力元ごとに食い違っていないか
• テスト環境や旧ドメインのURLが残っていないか
• プラグイン更新やテーマ変更で出力項目が変わっていないか
• キャッシュのため、修正前のJSON-LDが配信されていないか
• JavaScriptで生成する場合、Googleが取得したHTMLにも必要なデータが現れるか

「コードを入れた」という作業記録だけでは不十分です。最終的に公開URLが返すHTMLを開き、実ページと同じ内容が一つの意図した形で出力されていることを確認します。

テストはコード、公開ページ、Googleの取得を分けて行う

構造化データの確認は、一つのツールで終わらせず、何を確認するテストかを分けます。文法が正しくても公開ページが古い、公開ページが正しくてもクロールできない、Googleが取得したHTMLではJavaScriptの実行結果が異なる、といった問題があるためです。

1. Schema.orgとしての文法と型を確認する

Schema Markup Validatorは、ページに含まれるschema.orgの構造化データ全体を検証するためのツールです。JSONの括弧や引用符、プロパティの型、入れ子の関係などを確認します。Googleの検索機能固有の判定を行うツールではないため、「エラーがない＝Googleで特別表示される」という意味ではありません。

2. Googleが解釈する構造化データを確認する

Googleのリッチリザルトテストでは、Googleがページから認識する構造化データと、対応する検索機能に関するエラーを確認します。Organizationの実装後も、コード入力だけでなく公開URLでテストします。構造化データが正しくても、特別な検索表示が必ず出るわけではありません。テストの目的は、表示保証を得ることではなく、重大な実装エラーを見つけることです。

3. 公開URLをGoogleが取得できるか確認する

公開後はSearch ConsoleのURL検査で、ページがGoogleからアクセス可能か、noindex、robots.txt、認証などで遮断されていないかを確認します。必要に応じてライブテストを行い、Googleが取得したHTML内の構造化データも見ます。会社情報を変更した直後は再クロールをリクエストできますが、反映時期や検索表示は指定できません。

Organization専用の詳細レポートがSearch Consoleに常に用意されるとは限りません。専用レポートが見当たらないから未実装と判断せず、URL検査、解析不能な構造化データ、手動による対策、リッチリザルトテストなどを組み合わせます。サイトマップに中心ページを含め、通常の内部リンクから到達できる状態も確認します。

4. 更新後の差分を確認する

会社情報の変更時は、修正したページだけでなく、変更前の値が残っていないかを検索します。旧社名、旧住所、旧電話番号、旧ロゴURLをサイト内検索やソース検索で確認し、必要に応じて外部プロフィールも更新します。テーマやプラグインを更新した後は、会社情報を変更していなくても構造化データが消えたり二重になったりしていないか再テストします。

確認日を残すときは、「2026年8月に確認」のような月単位だけでなく、確認したURL、ツール、結果、担当を記録します。次回の変更で比較できるよう、テスト結果のスクリーンショットやエクスポート、修正前後のJSON-LDを保存しておくと原因を追いやすくなります。

AI検索向けの追加作業を増やす前に確認すること

AI検索への関心が高まると、AI専用のファイル、特別なマークアップ、構造化データの大量追加を先に試したくなります。しかしGoogleは、AIによる概要やAIモードに表示されるために、新たな機械可読ファイルやAIテキストファイル、特別なschema.org構造化データは必要ないと明記しています。

優先するのは、通常の検索で必要な基盤です。

• 会社概要などの中心ページがクロール・インデックス可能である
• 重要な会社情報が画像だけでなくテキストでも読める
• サイト内リンクから中心ページへ到達できる
• ページ上の説明が利用者にとって具体的で、古くない
• 構造化データが表示内容と一致している
• 公式に運用する外部プロフィールの情報も更新されている

構造化データは、ページの意味を伝える手掛かりの一つです。会社情報の内容そのものが曖昧、ページごとに矛盾、更新停止という状態を、JSON-LDだけで解決することはできません。また、正しい実装はAI回答への引用や検索順位を保証するものではありません。評価すべき成果は、まず「社内で最新版を特定できる」「利用者が公式情報を確認できる」「ページとコードの差分を検出できる」という管理品質です。

AI検索の表示を観察する場合も、社名だけの検索結果を一度確認して終わりにしないようにします。サービス名との組み合わせ、所在地を含む質問、連絡方法を尋ねる検索など、会社情報が使われる場面を分けて確認します。誤った回答を見つけても、特定のAIサービスへ一度訂正依頼を送るだけでは根本原因が残ります。公式ページ、構造化データ、外部プロフィールに食い違いがないかを先に点検します。

近い既存記事との使い分け

Bämには「構造化データマークアップの基礎」という既存記事があり、JSON-LD、Microdata、RDFa、Product、Article、FAQなど、構造化データ全般の概要を扱っています。本記事は、すべてのスキーマを網羅する記事ではありません。会社という一つの実体を、公式情報とOrganization／LocalBusinessでどう一致させ、変更時にどう保つかへ範囲を絞っています。

また、「ホームページ情報の正本はどこに置く？」は、料金、採用、営業日、会社情報など、Webサイト全体の更新元・担当・確認日を管理する方法が中心です。本記事では、その管理方法を会社情報へ適用し、公開ページ、ロゴ、URL、構造化データ、検証までを一続きにします。

読み分けるときは、次の判断で十分です。

• 構造化データの形式や代表的な種類から知りたい：既存の基礎記事
• Webサイト全体の更新元や担当表を作りたい：正本管理の記事
• AI検索や検索エンジンに伝える会社情報を整えたい：本記事

重複を避けるため、本記事でFAQや商品、記事、求人などの個別スキーマは詳しく扱いません。会社情報を整えた後に、各ページの内容に合う型が必要になった段階で、公式ドキュメントと基礎記事を参照します。

まとめ｜公式ページと構造化データを同じ更新元から直せる状態にする

AI検索に会社情報を正しく伝えるための中心は、特別なAI対策ではなく、公式情報の一貫性です。会社情報の更新元を決め、会社概要などの中心ページで名称、URL、住所、電話、ロゴ、サービスとの関係を確認できるようにし、実ページにある事実だけをOrganizationまたはLocalBusinessへ記述します。

実装後はSchema Markup Validator、リッチリザルトテスト、Search ConsoleのURL検査を目的別に使い、公開HTMLとGoogleの取得状態を確認します。会社情報が変わるたびに、公式ページと構造化データを同じ変更作業で更新し、旧情報が残っていないかを確かめます。この運用ができれば、AI露出を保証することなく、検索システムと利用者の双方へ確認可能な会社情報を提供できます。