構造化データのOrganizationの書き方｜LLMO対策の観点で実装解説

会社概要ページに会社名やロゴ、代表者情報をしっかり掲載していても、「ChatGPTに聞いてみたら自社のサービス内容を間違えて説明された」「Google AI Overviewsに社名すら出てこない」といった悩みは珍しくありません。

その原因の多くは、Organization構造化データの実装がJSON-LDの記述ミスや@type選定の甘さによって、検索エンジンやAI検索が会社情報を正確に読み取れていないことにあります。単に項目を埋めただけでは、生成AIの文脈理解にはつながりにくいのです。

そこで本記事では、LLMO対策を専門支援するAIコマース研究所が、Organization構造化データの基本的な書き方から、実装後に「本当に生成AIへ正しく伝わっているか」を検証する独自の「関係一致率」という考え方まで、支援・診断現場の知見をもとに解説します。読み終える頃には、自社サイトのどこから着手すべきかが具体的に見えているはずです。

Organizationが正しく認識されないと何が起きるか

Organization構造化データが未実装、あるいは記述に不備があると、検索エンジンやAI検索が「会社名・代表者・提供サービス」といった基本情報を正しく紐付けられず、検索結果やAI回答の中で企業情報が欠落・誤認識されるリスクが高まります。

検索結果・ナレッジパネルでの表示崩れ

Googleの検索結果では、公式ロゴが正しいURLとして認識されないとナレッジパネルやリッチリザルトに反映されず、社名で検索しても他社のロゴや無関係な画像が表示されてしまうことがあります。

Googleは組織のロゴについてschema.orgのOrganizationマークアップをサポートしており、ロゴ画像の場所を明示するマークアップを行うことで、検索結果に使用したい画像を優先して表示させるための強いシグナルになるとしています。逆に言えば、この記述がなければ、Google側にロゴ画像の意図が正しく伝わらないということです。

ChatGPTやPerplexityが会社情報を誤答・回答不能になるリスク

生成AI検索は、Webページの本文だけでなくJSON-LDのような構造化データも手がかりにサイトの内容を理解しようとします。Organizationの記述が不十分だと、「この会社の代表者は誰か」「何を専門とする会社か」といった質問に対し、ChatGPTやPerplexity、Google AI Overviewsが誤った回答をしたり、そもそも会社名を認識せず回答自体を避けたりする傾向が確認されています。

これは単なる表示上の問題ではなく、企業の実体そのものが生成AIの知識グラフの中で正しく紐付いていないことを意味します。

Organization構造化データとは

Organization構造化データとは、会社名・ロゴ・連絡先・所在地といった組織の基本情報を、検索エンジンやAI検索が機械的に読み取れる形式で記述するためのschema.orgの語彙です。

会社名・ロゴ・住所・sameAsなど基本項目の意味

一般的にマークアップされる主要な項目には、会社タイプ（@type）、会社名（name）、公式サイト（url）、住所（address）、公式ロゴ（logo）、説明文（description）、そして公式SNSアカウントなどを記述するsameAsがあります。

特にsameAsは、X（旧Twitter）やFacebookなど自社の公式アカウントURLを列挙することで、「このサイトとこのSNSアカウントは同一の組織である」という同一性を検索エンジン・AI検索の双方に伝える役割を持ちます。会社の公式SNSアカウントを運用している場合は、このsameAsを含めることが推奨されています。

@typeは「Organization」で十分か、より具体的な型を選ぶべきか

@typeは可能な限り具体的な型を選ぶことが推奨されています。schema.orgでは、組織を表す型として汎用的な「Organization」だけでなく、教育機関向けの「EducationalOrganization」、報道機関向けの「NewsMediaOrganization」など、業種に応じたより具体的なサブタイプが用意されています。

例えば航空会社であれば「Organization」ではなく「Airline」を指定できるように、自社の事業実態に近い型を選ぶことで、検索エンジンに伝わる情報の精度が上がると考えられます。schema.orgのOrganizationページに掲載されている「More specific types」の一覧から、自社に合った型を確認しておくとよいでしょう。

JSON-LDでのOrganization構造化データ記述例

Organization構造化データの記述形式にはJSON-LD・Microdata・RDFaの3種類がありますが、実装・保守のしやすさから、現在はJSON-LD形式で記述するのが一般的です。HTML本文の構造に手を加える必要がなく、scriptタグとして独立して差し込めるためです。

最小構成の記述例

Google検索セントラルで案内されている構成を踏まえると、最小構成では以下のようなプロパティを記述します。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "会社名",
  "url": "https://www.example.com",
  "logo": "https://www.example.com/images/logo.png",
  "description": "会社の説明文",
  "sameAs": [
    "https://x.com/example",
    "https://www.facebook.com/example"
  ],
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "番地・建物名",
    "addressLocality": "市区町村",
    "postalCode": "郵便番号",
    "addressCountry": "JP"
  }
}
</script>

Googleはこの情報について、サイトの全ページに重複して埋め込む必要はなく、トップページや会社概要ページなど、組織の説明を掲載した単一のページに配置することを推奨しています。

Person・WebSite・Articleとの紐付け方（sameAs／@id活用）

Organizationの真価は、単体で完結させるのではなく、PersonやWebSite、Articleといった他のエンティティと紐付けることで発揮されます。

例えば記事ページのArticle構造化データの中でauthorとしてPersonを記述し、そのPersonのworksFor（所属先）としてOrganizationを参照させることで、「この記事は、この会社に所属するこの人物が書いた」という関係を検索エンジン・AI検索の双方に伝えられます。

複数ページで同じOrganizationを参照する場合は、フルの記述を繰り返すのではなく@idを使って参照する設計にすると、情報の一貫性を保ちやすくなります。

WordPress・プラグインでの実装方法

WordPressサイトであれば、コードを直接編集しなくてもSEOプラグインの設定画面から組織名・ロゴ・連絡先などを入力するだけで、Organization構造化データを自動生成できます。エンジニアリソースが確保しにくい場合は、まずプラグインでの実装から着手するのが現実的です。

プラグインで自動生成する場合の設定項目

代表的なSEOプラグインには、サイト全体の基本情報（Organization・WebSite・Personなど）を自動生成する設定画面が用意されています。

会社名・ロゴ画像・連絡先・SNSアカウントのURLといった項目を入力欄に沿って埋めていくだけで、裏側でJSON-LDが自動的に組み立てられる仕組みです。

プラグインを使う場合は、同種の構造化データを複数のプラグインで同時に出力してしまうと、同じタイプの構造化データが重複して出力され、検索エンジンに正しく認識されなくなる点に注意が必要です。

手動でheader.phpに実装する場合の注意点

サイト全体で共通して出力したいOrganizationやWebSiteのような構造化データは、テーマのheader.phpに追記することで全ページへ一括適用できます。

ただし、親テーマのheader.phpを直接編集すると、テーマのアップデート時に変更内容が失われてしまうため、必ず子テーマを作成し、子テーマ側のheader.phpに追記する運用にしてください。

この方法であればテーマ更新による上書きリスクがなく、コードを一箇所で管理できるというメリットがあります。

実装後の検証方法（リッチリザルトテスト・Search Console）

Organization構造化データは、実装して終わりではなく、正しく認識されているかを検証するところまでが一連の作業です。実装前・実装後のそれぞれのタイミングで、異なるツールを使い分けて確認します。

実装前の構文チェックには、Googleのリッチリザルトテストを使用します。対象URLを入力し、エラーや警告が出ていないか、対応するリッチリザルトの種類が意図通りに認識されているかを確認してください。

実装後は、Search Consoleの「URL検査」からインデックス登録をリクエストしてクロールを促し、「拡張」セクションの各タイプ別レポートでエラー数・有効数を定期的に確認します。

構造化データはGoogleの仕様変更の影響を受けやすいため、実装したら終わりにせず、月次程度の頻度で確認する運用が望ましいでしょう。

「Organization関係一致率」で生成AIへの伝わり方を検証する方法

ここまでの検証方法は、あくまで構造化データの記述が「構文として正しいか」を確認するものです。しかし、多くの企業が本当に知りたいのは、その先にある「実際に生成AIが自社をどう理解しているか」ではないでしょうか。

AIコマース研究所では、この問いに答えるための独自の効果測定指標として「Organization関係一致率」という考え方を診断現場で用いています。

改善前後で生成AIに同じ質問をして正答率を記録する

やり方はシンプルです。Organization周辺の情報設計を改善する前後で、ChatGPTやPerplexity、Google AI Overviewsなどの生成AIに、自社に関する同じ質問を投げかけます。具体的には「○○社の代表者は誰ですか」「○○社は何を専門としていますか」「○○社が提供しているサービスは何ですか」「○○社では誰が記事を書いていますか」「○○社が運営しているメディアは何ですか」といった、Organizationと他のエンティティとの関係を問う質問です。

そのうえで、Organization→Person、Organization→Service、Organization→WebSite、Organization→Article、Organization→専門領域という関係ごとに、生成AIが正しく回答できたかを○×で記録します。例えば5つの関係のうち、改善前は2つしか正しく回答できなかったものが、改善後に4つ正答できるようになれば、Organization周辺の関係認識が改善した可能性を観測できる、という考え方です。

構造化データだけが要因とは限らない点への留意

ただし、この関係一致率の変化は構造化データの実装だけで説明できるものではありません。本文の記述内容、内部リンクの設計、外部からの言及情報、さらには生成AIモデル側のアップデートなど、複数の要因が影響するため、構造化データの改善だけが正答率向上の原因であると断定することはできません。

あくまで「関係認識が変化した可能性を観測するための一つの指標」として活用することが重要です。

Organization構造化データ実装でよくある失敗パターン

診断現場で実際によく見られる失敗パターンとして、次のようなものが挙げられます。

1つは、@typeを汎用的な「Organization」のままにしており、自社の事業実態により近いサブタイプを検討していないケースです。

2つ目は、sameAsに古いSNSアカウントや運用停止したアカウントのURLが残ったままになっているケースです。

3つ目は、複数のSEOプラグインを併用したことで同じ種類の構造化データが重複出力され、Search Consoleの拡張レポートで警告が出ているにもかかわらず放置されているケースです。

いずれも実装そのものより、実装後の点検・更新が抜け落ちていることが原因である傾向が見られます。

自社サイトのOrganization情報を客観的にチェックする方法

Organization構造化データは、正しく実装できているかどうかをリッチリザルトテストやSearch Consoleで確認できますが、それだけでは「生成AIに実際どう認識されているか」までは分かりません。

まずは自社で、先ほど紹介した5つの質問（代表者・専門領域・提供サービス・執筆者・運営メディア）をChatGPTやPerplexityに実際に投げかけ、どの関係が正しく回答されないかを洗い出すところから始めてみてください。

その上で、構造化データの記述だけでなく本文や内部リンクも含めた総合的な原因分析が必要になる場合は、AIコマース研究所のLLMO無料診断でも、こうした関係認識の状況を診断項目として確認しています。自社での洗い出しだけでは判断が難しいと感じた際の選択肢として、活用いただけます。

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

構造化データにおけるOrganizationとWebSiteの違いは？

Organizationは会社そのもの、WebSiteはサイトという「入れ物」の情報を表す点が違います。両者は別のプロパティを持ちますが、Organizationのpublisherとしてサイトに紐付けると、より正確に情報を伝えられる傾向があります。

構造化マークアップとは何ですか？

検索エンジンやAI検索にページの内容を機械的に伝えるためのコード記述です。文章だけでは伝わりにくい「会社名」「代表者」などの意味を、決まった語彙で明示する役割を持ちます。

構造化データを実装するとSEO効果はありますか？

検索順位を直接押し上げる効果は確認されていませんが、リッチリザルトの表示やAI検索での情報認識の向上につながる傾向があります。実装しないことによる直接的なデメリットはないとされています。

画像に関する構造化データも実装すべきですか？

ロゴ以外の画像もImageObjectとしてマークアップ可能ですが、まずはOrganizationのlogoプロパティを優先するのが一般的です。商品画像等は必要に応じて別途検討します。

Organizationを実装すればリッチリザルトは必ず表示されますか？

実装だけで表示が保証されるわけではありません。Googleのアルゴリズムによる審査を経て表示可否が決まるため、構文エラーがない状態を保つことが前提条件になります。

Organization構造化データの実装を外注する場合、費用相場はどれくらいですか？

サイト規模や紐付けるエンティティの数によって幅があり、一概には言えません。手動設計を伴う場合は工数が増える傾向があるため、見積もり段階で範囲を明確にすることが重要です。

@typeの選定を間違えるとペナルティを受けますか？

ペナルティの対象にはなりませんが、実態と異なる型を指定すると情報が正しく認識されにくくなる傾向があります。可能な範囲で事業実態に近い型を選ぶことが推奨されます。

Search Consoleで構造化データのエラーが出た場合はどうすればいいですか？

まず「拡張」レポートでエラー内容とエラーが出ているページ数を確認します。必須プロパティの不足や型の記述ミスが原因であるケースが多く、修正後に再度クロールをリクエストします。

構造化データのOrganizationに関するまとめ

Organization構造化データは、会社名やロゴといった基本情報を検索エンジンとAI検索の双方に正しく伝えるための土台です。@typeの選定やsameAsによる同一性の証明、JSON-LDでの適切な記述、そして実装後のリッチリザルトテストやSearch Consoleでの継続的な検証まで行って、初めて意味を持ちます。

さらに一歩進んで、実装した構造化データが実際に生成AIへどう伝わっているかを「関係一致率」のような指標で確認することで、自社の情報発信が生成AI時代に対応できているかを客観的に把握できるようになります。まずは自社サイトの現状を、簡単な質問投げかけから確認してみてはいかがでしょうか。