グループが大きいほど、AIの説明は混ざる｜複数ブランドのエンティティ整理

持株会社の下に事業会社が並ぶ企業グループでは、ChatGPTやGoogleのAIによる検索（AI Overview・AIモード）が「親会社の実績を子会社の説明に混ぜる」「同名の兄弟会社を1社として扱う」といった取り違えを起こすことがあります。結論から言うと、この混同は祈って直るものではなく、(1)法人ごとの表記統一、(2)グループサイト間のリンク構造、(3)Organization構造化データによる親子関係の宣言という3つのレイヤーで、AIが読み取れる形の「区別の根拠」を用意することで切り分けていきます。

本記事は、持株会社・複数ブランド・同名や類似名の子会社を持つ企業の広報・マーケティング担当者向けに、AIがグループ会社を混同する典型パターンと、その切り分け手順を実装レベルで整理します。単一法人の実在性シグナル（Wikipedia・Wikidataへの登録そのもの）はWikipedia・Wikidataとブランドエンティティの記事で扱っているため、本稿は「複数法人の関係性をどう区別させるか」に絞ります。

グループ会社のAI混同とは（定義）

グループ会社のAI混同とは、ChatGPT・Gemini・Perplexity・Google AI OverviewなどのAI検索が、資本関係や名称が近い複数の法人・ブランドを区別できず、ある会社の事業内容・実績・所在地・沿革を別の会社の回答に混ぜて出力してしまう現象を指します。原因は主に、(1)社名・ブランド名の表記が近く学習データ上で区別しにくい、(2)グループ各社のサイトが相互の関係を機械可読な形で説明していない、(3)第三者情報源（ニュース・データベース・Wikidata等）で親子関係が整理されていない、の3点に集約されます。対策は「どの法人が・何をしていて・他社とどういう関係か」を、自社サイト群と第三者情報源の両方で一貫して記述することです。

この定義ブロックだけ切り出されても意味が通るように書いています。AIに引用された場合も、ここが自社の説明として使われる想定です。

なぜAIはグループ会社を取り違えるのか

大規模言語モデルは「法人格」ではなく「言葉の近さ」で見ている

大規模言語モデル（LLM）は登記簿を参照しているわけではなく、学習データとWeb検索結果の中でのテキストの共起関係から回答を組み立てます。「◯◯ホールディングス」と「◯◯株式会社」と「◯◯システムズ」が同じ文脈で頻繁に登場すれば、モデル内部ではほぼ同一の存在として扱われやすくなります。人間なら「HDと事業会社は別法人」と当然に区別する場面でも、テキスト上の手がかりがなければAIは区別しません。

これはLLMの一般的な性質からの推論であり、各AIサービスが内部で法人をどう同定しているかの仕様は公開されていません。したがって本記事の対策は「AIが参照しうるすべての情報源で、区別の手がかりを最大化する」という考え方で組み立てます。「この施策をやれば必ず正しく区別される」という保証はどのベンダーも提供していない、という前提は最初に押さえてください。

混同を助長する企業側の典型条件

次の条件に当てはまるほど、混同は起きやすくなります。

• 持株会社と中核事業会社の名称が1〜2文字しか違わない（例: ◯◯HD／◯◯）
• グループ再編・社名変更・吸収合併が過去5年以内にあり、旧社名の情報がWeb上に大量に残っている
• 事業会社ごとにドメインが分かれているが、相互リンクや「グループ会社一覧」ページがない、あるいはテキストリンクでなくバナー画像だけ
• 同名・類似名の無関係な他社が存在する（地名+業種の社名など）
• プレスリリースの発信元が案件ごとに親会社と子会社で揺れている

AIがグループ会社を混同する典型5パターン

まず自社がどのパターンに当てはまるかを特定します。パターンによって効く施策が異なるためです。

パターン4（同名他社衝突）の詳細な症状確認はAIが自社を間違って説明する時の修正手順、社名の表記ゆれそのものが原因の場合は社名の表記統一の設計が近い主題です。本記事はこれらの上位にある「複数法人の関係構造」を扱います。

対策レイヤー1: 法人ごとの表記と記述の統一

「グループ共通の紹介文」をやめて、法人ごとに書き分ける

グループ各社のサイトに同じ「◯◯グループは、△△を通じて社会に貢献します」という紹介文を貼り回すのは、AIから見ると「全社が同じ事業をしている」と読める状態です。各社の会社概要・aboutページには、少なくとも次の要素を法人固有の文章で書きます。

• 正式商号（登記名）と、通称・英文名・略称の対応関係
• どの法人の100%子会社か／持株会社か（「株式会社◯◯ホールディングスの連結子会社」など資本関係を明文で）
• その法人が「やっていること」と「やっていないこと」。特に兄弟会社の主力事業を自社がやっていない場合、「△△事業はグループ会社の株式会社□□が担っています」と明示する
• 本店所在地・設立年・法人番号（国税庁の法人番号は同名他社との識別子として機能する公的情報です）

「やっていないことを書く」のは違和感があるかもしれませんが、兄弟混線パターンの切り分けでは、否定と担当の明示が最も直接的な手がかりになります。

プレスリリースの発信元を固定する

案件によって発信元が親会社になったり子会社になったりすると、第三者メディア上での事業の帰属がぶれます。原則として「事業の主体である法人」を発信元にし、親会社は「◯◯ホールディングス傘下の株式会社△△（本社：…）は」のように冒頭の会社紹介文で関係を毎回明記する運用に固定します。プレスリリース経由の引用設計はプレスリリースとAI検索引用の記事も参照してください。

対策レイヤー2: グループサイト間のリンク構造

「グループ会社一覧」はテキストリンクのハブにする

持株会社サイトの「グループ会社一覧」ページは、AIとクローラにとってグループ構造を学ぶ最重要ページです。次の状態になっているかを確認します。

• 各社の正式商号がテキストで書かれ、各社公式サイトへテキストリンクされている（ロゴ画像だけのリンクは、alt属性がなければ社名情報がリンクに乗らない）
• 各社の1行事業説明が併記されている（リンク先を読まなくても各社の違いが分かる）
• 出資比率または「連結子会社／持分法適用会社」の区分が書かれている（開示可能な範囲で）

子会社側から親会社への「上り」リンクを忘れない

親から子へのリンクは整備されていても、子会社サイトのフッターや会社概要から持株会社サイトへのリンクがないケースは多くあります。関係性は双方向のリンクで示されて初めて、独立した2サイトではなく「関係を相互に認めた2法人」として読み取れる構造になります。子会社側には「◯◯ホールディングス グループ会社一覧」への直リンクを置きます。

別ドメイン運用か、サブディレクトリ運用か

すでに運用中のドメイン構成を混同対策だけの理由で変える必要はありません。重要なのは、どちらの構成でも「弱くなる側の関係表現」をリンクと構造化データで補うことです。

対策レイヤー3: Organization構造化データで親子関係を宣言する

使うプロパティ

schema.orgのOrganizationタイプには、法人の識別と関係性を記述するプロパティが定義されています（schema.org公式の語彙定義で確認できます）。

実装上の注意点が2つあります。第一に、Googleの組織向け構造化データのドキュメント（日本語版）が例示・推奨しているのはname・alternateName・legalName・sameAs・logo・住所系などで、parentOrganization／subOrganizationはGoogleのドキュメント上の推奨プロパティとしては挙げられていません。つまり親子関係プロパティは「schema.org語彙として正当だが、Google検索の機能でどう使われるかは公表されていない」ものとして、効果を断定せずに実装します。それでも実装する価値があるのは、機械可読な関係宣言を一貫して置くこと自体が、検索エンジン・AIクローラ双方への追加の手がかりになるからです。第二に、各社のトップページ（組織を代表するページ）に、その法人自身のOrganizationを1つだけ記述し、ページごとに内容がぶれないようにします。構造化データの基本実装は構造化データとAI検索の記事を参照してください。

Wikidataでの親子関係の整理

Wikidataには組織間の関係を表すプロパティとして、上部組織（P749: parent organization or unit）・下部組織（P355: child organization or unit）・所有者（P127: owned by）が定義されています。グループ各社のWikidata項目が存在する場合、これらの関係が正しく張られているか、旧社名時代の関係のまま止まっていないかを確認します。項目の新規作成や実在性シグナルとしての位置づけはWikipedia・Wikidataの記事の主題なのでそちらに譲り、本記事の観点では「関係プロパティ（P749/P355/P127）の整合」だけをチェック対象にします。Wikidataは出典に基づく編集が原則のため、有価証券報告書・公式サイトのグループ会社一覧など検証可能な出典を添えて編集します。

どの施策から着手するかの判断表

実装チェックリスト

よくある失敗例

失敗例1: 構造化データだけ入れて本文を直さない

parentOrganizationを実装したのに混同が続く、という相談パターンです。構造化データは補助シグナルであり、AIが主に読むのは本文テキストです。会社概要の本文に資本関係と事業の書き分けがなければ、マークアップだけで区別されることは期待できません。順序は常に「本文→リンク構造→構造化データ」です。

失敗例2: グループ全社のサイトに同一のOrganizationを配信する

CMSテンプレートをグループ共通化した結果、全社のサイトが持株会社のOrganizationマークアップを出力していた、というケースです。これは各社サイトが「自分は持株会社です」と宣言している状態で、混同を能動的に作り出します。テンプレート共通化するなら、法人ごとの変数（商号・法人番号・親子関係）を差し込む設計にします。

失敗例3: 旧社名の痕跡を消しにいく

旧社名残留パターンで、過去のニュース記事やデータベースに削除依頼を一斉送付してしまう対応です。履歴が消えると、逆に「旧社名と現社名が同一法人である」というつながりの手がかりまで失われます。正しくは、自社の沿革ページで「2023年に◯◯株式会社から△△株式会社へ商号変更」と明文化し、alternateNameに旧社名を残し、新旧の連続性をAIが辿れるようにすることです。

よくある質問

グループ会社のAI混同は、どうやって発見すればよいですか

主要なAIサービス（ChatGPT・Gemini・Perplexity・Google AI Overview）に対して、「各社名＋どんな会社か」「2社の関係」「特定事業の担当会社」の3種類の質問を法人ごとに投げ、回答を日付つきで記録するのが基本です。AIの回答は同じ質問でも揺れるため、1回の結果で断定せず、複数回・複数サービスで傾向を見ます。回答の観測方法の詳細はChatGPTに自社がどう説明されるかの記事を参照してください。

対策すればAIの混同は確実に直りますか

直るとは断定できません。AI各社は法人の同定ロジックを公開しておらず、学習データの更新タイミングも制御できないためです。本記事の施策は「AIが参照しうる情報源での区別の手がかりを最大化する」ものであり、効果の保証ではなく確率を上げる取り組みとして実施してください。だからこそ、チェックリストNo.11の定点観測をセットにすることが重要です。

持株会社と事業会社、どちらのサイトから直すべきですか

症状によります。子会社の説明に親会社の情報が混ざる親子合成なら、先に直すのは子会社サイト側の情報量です。子会社サイトの会社概要が薄いほど、AIは親会社の豊富な情報で穴埋めしようとします。逆に子会社の存在自体が消えるブランド吸収なら、サービスサイト・子会社サイトへの運営会社情報の設置が先です。判断表のとおり、症状からパターンを特定してから着手してください。

非上場のグループ会社でも出資比率まで公開する必要がありますか

必須ではありません。開示できる範囲で「連結子会社」「◯◯ホールディングスのグループ会社」といった関係の種別が明文化されていれば、区別の手がかりとしては機能します。出資比率の数字そのものより、「どの法人の傘下か」が一貫して書かれていることが重要です。

まとめ: 混同の切り分けは「区別の根拠づくり」

グループ会社のAI混同への対応は、AIに苦情を言うことではなく、AIが参照するすべての場所に「この法人は何者で、他の法人とどう違うか」の根拠を積むことです。本文の書き分け、双方向のリンク構造、Organization構造化データとWikidataの関係整合。この3レイヤーを揃えた上で、定点観測で変化を追う。ここまでが1セットです。

自社グループがいまAIにどう説明されているか、どのパターンの混同が起きているかを第三者の目で整理したい場合は、LLMO診断で現状の棚卸しからお手伝いできます。まずは本記事のチェックリストNo.1、各AIへの質問と記録から始めてみてください。