こんにちは、株式会社テラ AIエンジニアリングチームです。
ChatGPTやGemini、Claudeに自社の名前を聞いてみたことはありますか?
正確に説明されるケースもあれば、古い情報が出てきたり、まったく知られていなかったり、最悪の場合、間違った情報が返ってくることもあります。
当社の場合、Geminiに「株式会社テラ」を聞いたところ、英語表記が「TERRA CO., LTD.」と誤っていました(正しくはTERA Inc.)。住所も古い情報が返ってきました。これは珍しいことではなく、多くの企業で同様の問題が起きています。
AIが自社を正しく認識するために最も基本的かつ効果的な施策が、Organizationスキーマの実装です。
これは、HTMLのソースコードに「うちの会社はこういう会社です」という構造化された名刺を埋め込むようなもの。人間の目には見えませんが、AIはこのデータを読み取って「この会社は何者か」を判断しています。
しかも、この施策はGoogleが公式ガイドラインで推奨しているものであり、llms.txtと組み合わせることで相乗効果が期待できます。
この記事では、Organizationスキーマとは何か、なぜLLMOに重要なのか、Google公式の見解、llms.txtとの関係性、そして具体的にどう書いてどこに設置するのかを解説します。
Organizationスキーマとは
AIへの「公式名刺」
Organizationスキーマは、Schema.orgが定義する構造化データの一種で、組織の基本情報を機械可読な形式で記述するものです。
具体的には以下の情報を含みます。
- 組織名(name)
- 公式サイトURL(url)
- ロゴ(logo)
- 所在地(address)
- 連絡先(contactPoint)
- 設立年、事業内容などの付加情報
これらがJSON-LD形式でHTMLに埋め込まれていると、AIは「このサイトの運営者はこういう組織だ」と構造的に理解できます。
Webページのテキストに「株式会社テラ、名古屋市中区に本社を置くWeb制作会社です」と書いてあるのと、JSON-LDで同じ情報が構造化されているのでは、AIにとっての「信頼度」が全く異なります。テキストは「誰かがそう言っている」情報ですが、構造化データは「このサイトが公式に宣言している」情報です。
SEOでは「あると良い」、LLMOでは「ないと不利」
従来のSEOにおいても、Organizationスキーマはリッチリザルト(ナレッジパネル等)の表示に影響する要素でした。ただし、あくまで「あるとベター」程度の位置づけで、実装していなくても検索順位には大きな影響はありませんでした。
しかしLLMOにおいては、状況が異なります。AIは回答を生成する際、情報源の信頼性を判断するための材料として構造化データを直接参照します。Organizationスキーマが正しく実装されているサイトは「公式に組織情報を宣言している」と判断され、信頼度が高い情報源として扱われやすくなります。
つまり、SEOでは「あるとベター」だったものが、LLMOでは「ないと不利」に変わったのです。
Google公式ガイドラインが推奨している
Organizationスキーマの重要性は、個人の見解ではありません。Google公式ガイドライン(Google Search Central)が明確に推奨しているものです。
Googleは、ホームページにOrganizationスキーマを追加することで、以下が実現すると述べています。
- 組織の詳細情報をより正確に理解できるようになる
- 検索結果での曖昧性を排除する(disambiguate)
「曖昧性の排除」という言葉に注目してください。これは、同名の企業や類似の組織と混同されることを防ぐという意味です。
先ほどの「株式会社テラ」の例でいえば、同名の別企業が存在するため、AIが情報を混同するリスクがあります。Organizationスキーマに正しい情報を構造化して宣言することで、このリスクを下げられます。これはLLMOの文脈で言う「AIに正しく認識させる」と完全に同じ話です。
また、Organizationスキーマには必須プロパティが存在しません。Googleは「該当する情報をできる限り多く追加してください」というスタンスを取っています。つまり、社名とURLだけでなく、住所、電話番号、設立年、事業内容、SNSアカウントまで、書けるものは全部書いた方が良い。書けば書くほど、AIが御社を正確に理解できるようになります。
なぜLLMOにおいてOrganizationが重要なのか
1. E-E-A-Tの機械可読な証明
Googleが重視するE-E-A-T(経験・専門性・権威性・信頼性)は、テキストとして書くだけでは不十分です。「うちは専門性があります」とページに書いても、それをAIが信用する保証はありません。人間がテキストを読んで判断するのとは違い、AIは構造化されたデータの方を信頼します。
Organizationスキーマに組織名、所在地、事業内容、設立年が構造化されていれば、AIは「この情報は実在する組織が、機械可読な形式で正式に宣言している」と判断します。テキストの主張ではなく、データとしての証明。この違いは大きいです。
2. エンティティとしての認識
AIは、Web上の情報を「エンティティ(実体)」として認識しています。エンティティとは、人物、企業、場所、製品など、固有の存在として識別可能なものを指します。
Organizationスキーマは、自社を1つのエンティティとしてAIのナレッジグラフに登録するための基盤です。ナレッジグラフに登録されると、AIは御社を単なる「テキストに出てくる名前」ではなく、「固有の実体」として認識するようになります。
エンティティとして認識されれば、「〇〇について△△社によると…」という形で回答の中に言及される可能性が高まります。逆に、エンティティとして認識されていなければ、AIは御社の存在自体を「知らない」状態のままです。
3. 他のスキーマとの連携基盤
Organizationスキーマは、単体で機能するだけでなく、他の構造化データの「土台」としても機能します。
例えば、ブログ記事にArticleスキーマを実装する際、publisher(発行者)としてOrganizationを参照します。著者情報のPersonスキーマでは、worksFor(所属組織)としてOrganizationを参照します。
つまり、Organizationが正しく定義されていれば、サイト内の他のすべての構造化データの信頼性が連鎖的に高まります。逆にOrganizationが未定義だと、Articleの発行者もPersonの所属先も「不明」のまま。土台がない建物のような状態です。
Organizationスキーマとllms.txtの関係
LLMO対策において、Organizationスキーマとllms.txtは別々の施策ではなく、セットで整備すべきものです。両者はそもそも別の規格(Schema.org vs Anthropic提唱のllms.txt)ですが、AIに対して補完的な役割を果たします。
役割の違い
| 誰に読まれるか | 何を伝えるか | 形式 | |
|---|---|---|---|
| Organization スキーマ | 検索エンジン + AIクローラー | 会社情報を構造化データとして | JSON-LD(HTML内) |
| llms.txt | LLM / AIエージェント専用 | サイト全体の概要を自然言語として | Markdown(独立ファイル) |
Organizationスキーマは機械向けの構造化データです。「社名は〇〇、住所は△△、設立は19XX年」というファクトを、AIが一切の解釈なしに取得できる形で提供します。
一方、llms.txtはAI向けの自然言語です。「この会社は〇〇業界に強みがあり、△△のような課題を持つ企業からの相談に向いています」という、文脈やニュアンスを含んだ情報を提供します。
例えるなら
ビジネスの場面で考えてみてください。
- Organizationスキーマ = 名刺に印刷された肩書き・住所・電話番号。事実の証明。
- llms.txt = 名刺を渡しながらする自己紹介トーク。「うちはこういう強みがあって、こういう案件が得意で、最近はこんなプロジェクトをやりました」。
名刺だけ渡しても、相手は肩書きと社名しかわからない。自己紹介だけして名刺を渡さなければ、「あの人何て会社だっけ?」となる。両方あって初めて「何者か」が伝わるのです。
両方整備するとAIの中で何が起きるか
AIが回答を生成する際、Web上の膨大な情報から「どの情報源を信頼するか」を判断するプロセスがあります。このとき、複数のソースから同じ情報が確認できると、信頼度が上がります。
Organizationスキーマとllms.txtの両方が整備されているサイトでは、以下のようなことが起きます。
- 信頼度の確認: Organizationスキーマで「この会社は実在する、住所は〇〇、設立は19XX年」とファクトが確認される
- 文脈の取得: llms.txtで「この会社は〇〇が強みで、△△のような相談に向いている」と推薦理由が取得される
- 整合性の確認: 両方に書かれた社名・住所が一致している → AIは「この情報は信頼できる」と判断する
結果として、AIが回答に含める際の信頼度と具体性の両方が上がります。信頼度だけ高くても具体的な推薦理由がなければ言及されにくい。推薦理由だけあっても信頼度が低ければ採用されにくい。両輪が揃うことで、AIに「選ばれる」確率が高まります。
情報の一貫性が絶対条件
ここで重要な注意点があります。Organizationスキーマに書いた社名・住所と、llms.txtに書いた社名・住所は必ず一致させてください。
AIは複数のソースを照合して情報の正確性を検証します。もし、Organizationスキーマには「東京都千代田区」と書いてあるのに、llms.txtには「名古屋市中区」と書いてあったらどうなるか。AIは「どちらが正しいかわからない」と判断し、最悪の場合、どちらの情報も使わないという選択をします。
社名の英語表記(Inc. / Co., Ltd. の違い等)、住所の表記ゆれ(「4丁目1番18号」と「4-1-18」の違い等)まで含めて、すべてのソースで統一してください。この一貫性こそが、AIに「この情報は正しい」と確信させる最大の材料です。
記述すべき項目
必須レベル
| 項目 | プロパティ | 説明 |
|---|---|---|
| 組織名 | name | 正式名称 |
| サイトURL | url | 公式サイトのURL |
| ロゴ | logo | ロゴ画像のURL |
推奨レベル
| 項目 | プロパティ | 説明 |
|---|---|---|
| 説明 | description | 事業内容の要約 |
| 所在地 | address | 本社の住所 |
| 連絡先 | contactPoint | 電話番号・問い合わせ種別 |
| SNS | sameAs | 公式SNSアカウントのURL |
| 設立年 | foundingDate | 会社の設立年 |
LLMOを意識するなら追加したい項目
| 項目 | プロパティ | 説明 |
|---|---|---|
| 別名 | alternateName | 略称、英語名など。同名企業との区別に有効 |
| 事業領域 | knowsAbout | 専門とする領域(自由記述)。AIが「何の会社か」を判断する材料 |
| 受賞歴 | award | 受賞・認定情報。E-E-A-Tの権威性を裏付ける |
特にalternateNameは、同名企業が存在する場合に重要です。正式名称と英語表記の両方を登録しておくことで、AIが「この株式会社テラはTERA Inc.のことで、医薬品のテラ株式会社とは別の会社だ」と判断できるようになります。
実装例
基本的なOrganizationスキーマ
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "株式会社テラ",
"alternateName": "TERA Inc.",
"url": "https://www.cdn-tera.co.jp/",
"logo": "https://www.cdn-tera.co.jp/logo.png",
"description": "名古屋・横浜を拠点に、企業の課題整理からブランディング、Webサイト制作、システム開発、運用改善までを一気通貫で支援するクリエイティブパートナー。",
"address": {
"@type": "PostalAddress",
"addressLocality": "名古屋市中区",
"addressRegion": "愛知県",
"postalCode": "460-0011",
"addressCountry": "JP"
},
"contactPoint": {
"@type": "ContactPoint",
"telephone": "+81-52-684-6611",
"contactType": "customer service"
},
"foundingDate": "1996",
"knowsAbout": ["Web制作", "LLMO", "AI検索最適化", "ブランディング", "システム開発"],
"sameAs": [
"https://twitter.com/tera_example",
"https://www.facebook.com/tera.example"
]
}
設置場所
設置場所は、HTMLの <head> 内に <script type="application/ld+json"> として記述するのが基本です。
WordPressの場合、テーマの header.php に記述すれば、全ページに自動適用されます。静的HTMLサイトの場合は、主要ページ(トップ、会社概要、サービス等)に個別に設置してください。
注意点として、1サイトに1つのOrganizationスキーマが基本です。複数のOrganizationスキーマが存在すると、AIがどちらを信頼すべきか混乱する可能性があります。
よくある疑問
LocalBusinessとOrganizationの違いは?
LocalBusinessはOrganizationのサブタイプで、実店舗を持つビジネス向けです。Web制作会社やBtoB企業であれば、Organizationで十分です。飲食店やクリニックなど、地域密着型で来店を促したいビジネスの場合はLocalBusinessを使う方が適切です。LocalBusinessにすると、Googleマップとの連携や営業時間の表示など、実店舗向けの機能が使えるようになります。
複数拠点がある場合は?
本社をメインのOrganizationとして記述し、支社はaddressを配列にするか、別途LocalBusinessとして記述する方法があります。当社の場合、名古屋本社と横浜サテライトオフィスの2拠点がありますが、llms.txtに両方の住所を明記した上で、Organizationスキーマでは本社の住所を記述しています。
すでにSEOプラグインで自動生成されている場合は?
Rank MathやYoast SEOが自動でOrganizationスキーマを出力している場合があります。まずはGoogleのRich Results Testで現状の出力内容を確認してください。社名とURLだけの最低限の内容になっていることが多いので、プラグインの設定画面からdescription、address、foundingDate、knowsAbout等を追加することをお勧めします。
Organizationスキーマを入れればAIの回答にすぐ反映される?
すぐには反映されません。AIクローラーがサイトを巡回し、構造化データを取得するまでに時間がかかります。Perplexityのようにリアルタイムで参照するサービスでは比較的早く効果が出ますが、ChatGPTやGeminiの通常モードへの反映には数週間〜数ヶ月かかる場合があります。SEO対策で構造化データを入れてからリッチリザルトに反映されるまでに時間がかかるのと同じ構造です。
まとめ
OrganizationスキーマはLLMO対策の最も基本的な土台です。
Google公式ガイドラインが推奨しており、「組織情報の正確な理解」と「曖昧性の排除」に直接効くことが明言されています。
llms.txtが「AIへの案内パンフレット」、robots.txtが「AIへの入場ルール」だとすれば、Organizationスキーマは「AIへの公式名刺」です。名刺がない状態で商談に行く人はいないように、Organizationスキーマがない状態でLLMO対策を始めるのは片手落ちです。
そして、Organizationスキーマとllms.txtの両方を整備し、情報を一貫させることで、AIに対する信頼度と具体性の両方を高めることができます。
まだ実装していない方は、今すぐ設置してください。
Organizationスキーマの実装、ご相談ください
「自社のOrganizationスキーマを正しく実装したい」
「llms.txtとあわせてLLMO対策の土台を整えたい」
「AIに自社がどう認識されているかを確認したい」
そうした方は、ぜひ一度ご相談ください。