旧社名は消さず、橋にする。社名変更・移転のLLMO

新しい社名の名刺が刷り上がり、コーポレートサイトのロゴも差し替え、取引先への挨拶メールも送り終えた。その数週間後、商談の冒頭で相手がこう言う。「事前にChatGPTで御社を調べたんですが、前の社名と、前の住所が出てきましたよ」。社名変更や本社移転のあとに起きるこの現象は担当者の更新漏れではなく、AI検索が会社情報を拾う仕組みそのものに由来する。この記事では、旧情報が残り続ける構造を分解し、旧社名・旧住所を「消す」のではなく「新情報への橋として残す」実務手順をまとめる。

先に結論を書く。2026年9月時点で、ChatGPT・Gemini・Perplexity・GoogleのAI Overviewはいずれも、学習済みのモデル内知識と、回答生成時に参照する検索結果の両方を材料にしている。前者は自社から直接書き換えられず、各社とも反映時期を公表していない。したがって打ち手は次の3点に集約される。

1. 旧社名・旧住所と新社名・新住所の対応を1ページで言い切る移行アナウンスページを、自社ドメインに常設する
2. Organization構造化データのalternateNameに旧社名を追加し、legalName・address・WebSiteのサイト名までを新旧整合させる
3. 登記・法人番号公表サイト・Googleビジネスプロフィール・業界データベースという外部の裏付け情報を、依存関係の順に更新する

そして全体を貫く原則は1つ。旧社名・旧住所を削除しないこと。削除すると、Web上から「旧と新が同じ法人である」と示す自社発の証拠が消え、AIは第三者サイトに残った旧情報だけを頼りにする状態になる。

社名変更・移転時のLLMO対策とは何か

社名変更・移転時のLLMO対策とは、商号（社名）や本店所在地の変更後に、生成AIや AI検索が旧社名・旧住所を回答し続けないよう、自社サイトと外部データソースの双方で「旧情報と新情報が同一法人を指す」ことを機械可読な形で明示し、その更新を主要な情報源へ波及させる一連の実務を指す。

平常時のLLMO対策が「AIに正しく理解され、引用されるための情報設計」であるのに対し、変更イベント時の対策は性質が違う。相手が持っているのは誤りではなく、かつて正しかった情報だからだ。AIから見れば旧社名は矛盾のない事実であり、上書きの動機がない。だから作業の中心は「新情報を足す」ではなく「新旧をつなぐ関係性を、複数の独立した情報源に置く」になる。

もう1つ押さえておきたいのは、AIやクローラーが「A社とB社が同一法人である」ことを自力では確信できない点だ。人間なら社名変更のお知らせを1本読めば納得するが、機械は同名他社やグループ内の別法人との区別まで含めて判断する必要がある。表記のゆれを平常時に統一する考え方は社名の表記ゆれとAI検索で扱っているが、変更イベント時の主題はゆれの統一ではなく新旧の橋渡しであり、成果の基準も「旧社名で質問しても社名変更に言及されるか」に変わる。

旧情報が残り続ける仕組み。AIが参照する3層を分けて見る

対処を誤らないために、AIが会社情報をどこから得ているかを3層に分けて把握する。層ごとに、自社で打てる手がまったく違う。

誤答のパターンは、この層の違いでほぼ説明がつく。検索を使わない素の応答で旧社名が出るなら第1層由来で、こちらは待つしかない。検索を使っているのに旧社名が返るなら第2層の問題で、上位に残る旧社名時代の第三者記事や古い企業DBが引用元になっている。後者は改善余地が大きく、優先して手を入れる価値がある。どちらなのかは後述の定点観測で切り分けられる。

AIが企業を文字列ではなく実体（エンティティ）として扱う全体像はLLMOのエンティティ対策で詳しく扱っている。社名変更は、この同一性が一時的に揺らぐイベントだと捉えると以降の手順の意味が通る。すでに誤った説明が出ている状態からの巻き戻しはAIが自社を間違って説明するときの訂正手順と重なるため、そちらも併読したい。

変更の型を4つに分ける。打ち手の重さはここで決まる

「社名変更」と一言で言っても、実務の重さは変更内容で大きく変わる。着手前にどの型かを確定させると、無駄な作業と抜け漏れの両方を減らせる。

型4は他と難易度の桁が違う。社名変更だけでもAI側の参照情報が揺らぐところに、URL単位の評価引き継ぎという別の不確実性を重ねることになるからだ。リダイレクトとAI引用の関係は301リダイレクトでAI検索の引用は消えるか、評価の引き継ぎ全般はサイトリニューアルのLLMO対策で個別に扱っている。可能ならドメイン変更は時期をずらし、同時に実施せざるを得ない場合もリダイレクトマップを発表前に確定させ、URL階層やナビゲーションの刷新はさらに別の時期に分ける。変数を一度に3つ動かすと、回答が乱れたときに原因を切り分けられなくなる。

自社サイト側の実装。移行アナウンスページと構造化データ

移行アナウンスページを常設する

発表と同時に用意すべきなのが、新旧の対応関係を1ページで言い切る移行アナウンスページだ。プレスリリースは配信後に流れていくが、このページは自社ドメインに常設し、削除しない。「旧社名で検索した人（および検索を経由するAI）が、必ずここに行き着いて新社名へ橋渡しされる」状態を作るのが目的である。

冒頭の1文は、そのまま引用されても成立する自己完結型にする。実際に使える完全形は次のとおりで、丸括弧内を自社の情報に置き換えればそのまま公開できる。

<pre><code>株式会社サンプル（法人番号 0000000000000）は、2026年4月1日付で商号を 「株式会社サンプル商会」から「株式会社サンプル」へ変更しました。あわせて 2026年5月7日に本店を東京都千代田区（旧本店）から東京都港区（新本店）へ 移転しています。法人番号・事業内容・代表者・取引条件に変更はありません。 旧商号「株式会社サンプル商会」（英文表記 Sample Shokai Co., Ltd.、通称 サンプル商会）は、現在の「株式会社サンプル」と同一の法人です。</code></pre>

この文には、社名変更・移転・法人番号・継続情報・英語表記・略称・同一法人であることの宣言がすべて入っている。一部だけが切り出されても新旧の対応が読み取れる密度か、を基準に推敲するとよい。

あわせて、会社概要ページとフッターにも「（旧社名：◯◯）」の併記を一定期間残す。過去のお知らせやプレスリリースは原文のまま残し、冒頭に注記を1行足す方式にする。原文を書き換えると、その記事が持っていた発表当時の一次情報としての価値まで失われる。

Organization構造化データで見直すプロパティ

自社サイト側の機械可読な更新の中心はOrganization構造化データである。Google Search Centralの組織向けドキュメント（2026年9月8日更新・同年9月13日閲覧）では、alternateNameは「組織が一般に使われている別名」、legalNameは「nameと異なる場合の、登記された正式名称」と定義されている。同ドキュメントは、一部のプロパティが他組織との曖昧性解消のために裏側で使われ、logoなどは検索結果やナレッジパネルの表示に影響し得ると説明している。

alternateNameに旧社名を入れる一点が、この局面でいちばん費用対効果が高い。追加コストはほぼゼロで、「別名である」という関係を明示できる標準プロパティだからだ。ただし構造化データは宣言にすぎず、本文・会社概要・外部データベースと矛盾しない状態にして初めて裏付けとして機能する。

構造化データ以外にも、会社情報はサイト内に散在している。会社概要、特定商取引法に基づく表記、採用ページ、PDFの会社案内、フォームの自動返信文、メール署名テンプレート。1箇所でも旧住所が残っていると「同じサイト内に2つの住所がある」状態を検索経由で拾われ、どちらが答えられるかが不安定になる。公開ディレクトリを旧社名・旧住所・旧郵便番号・旧電話番号の4パターンで全文検索し、意図した残存（過去のお知らせ）と更新漏れに仕分けするのが確実だ。更新したページの更新日は実態に合わせて動かす。日付だけを機械的に新しくする運用は逆効果になり得る（dateModifiedの設計実務）。

サイト名とインデックスの入れ替え。ここを忘れると検索結果に旧社名が残る

見落とされやすいのが、検索結果に表示されるサイト名だ。Google Search Centralのサイト名ドキュメント（2025年12月10日更新・2026年9月13日閲覧）によると、サイト名はホームページの内容とWeb上の参照をもとに自動で決定され、その判断材料としてトップページのWebSite構造化データ（nameが必須、alternateNameは任意で複数を優先順に指定可）、og:site_name、ページタイトル、見出しなどが使われる。Organization構造化データを直しても、WebSite側のnameが旧社名のままなら、検索結果の見出し部分に旧社名が出続けることがある。

同ドキュメントは反映について「クロールには数日から数週間かかることがある」と述べ、トップページの更新が下層ページへ伝わるまでさらに時間がかかる場合があるとしている。自社ができるのは、URL検査ツールでホームページのクロールを依頼することと、トップページ上の表記を新社名で統一することの2つだ。

ドメイン変更を伴う場合は、さらにリダイレクト設計が重なる。Google Search CentralのURL変更を伴うサイト移転ドキュメント（2026年8月20日更新・同年9月13日閲覧）では、サーバー側の恒久的リダイレクト（301・308）が推奨され、リダイレクトの連鎖は5ホップを超えないこと（可能なら3以下）、リダイレクトは最低1年維持し、ユーザー体験の観点からは無期限の維持も検討するよう案内されている。Search Consoleのアドレス変更ツールはドメインまたはサブドメイン間の移転にのみ使うもので、HTTPS化やwwwの有無の変更、同一ドメイン内のパス変更では不要とされている。

更新の通知にはIndexNowという選択肢もある。公式ドキュメント（2026年9月13日閲覧）によれば、16進数のキーファイルで所有権を示し、単一URLはGET、まとめる場合はPOSTで最大1万URLまで送れる。ただし通知先は参加検索エンジンであり、生成AIサービスが直接これを読む保証はない。会社情報ページの再クロール依頼の一手段、という位置づけで使う。

外部データソースの更新順序。登記を起点に、依存関係の順で

自社サイトの外にある会社情報データベースは、AIとその検索基盤にとっての裏付け資料だ。ここが旧情報のままだと、サイトをいくら整えても矛盾が残る。更新には依存関係があるので、順序を決めて進める。

順序の考え方はシンプルで、「公的な裏付け（登記・法人番号）→ プラットフォームが直接持つデータ（ビジネスプロフィール）→ 第三者の参照データ」の順に固める。逆順で進めると、Wikipediaの編集者や企業DBの運営者が裏を取ろうとしたときに公的情報が旧社名のままで、更新が保留・差し戻しされることがある。

法人番号公表サイトの変更履歴は、この局面で特に価値がある。「旧商号Aの法人が、同じ法人番号のまま新商号Bになった」という事実が、無料で機械可読な一次データとして残るからだ。移行アナウンスページには法人番号を必ず書き、公表サイトの自社ページへリンクしておくと、AIや検証する人間が自社の主張を独立に照合できる経路ができる。

プレスリリースの書き方も見直したい。社名変更のリリースは配信サービス経由で多数のニュースサイトに転載され、それ自体が引用源になる。本文に旧社名・新社名・変更日・法人番号を明記しておけば、転載された記事群がそのまま裏付けネットワークとして機能する。旧社名を書かないと「新社名の会社が突然出現した」ように見え、接続が弱いまま記事だけが増える。

グループ内の複数ブランドや持株会社体制が絡む場合は、エンティティ設計の粒度が一段上がる（グループ会社・複数ブランドのエンティティ整理、AI検索とWikidata）。

よくある失敗例。「全部新しくする」が誤答を長引かせる

現場で実際に起きがちな失敗を挙げる。いずれも「早く新しい姿に切り替えたい」という自然な動機から生まれるが、AI検索の観点では逆効果になる。

失敗例1：旧社名を含むページを一括削除・一括置換する。 旧社名が載った過去のお知らせをまとめて削除する、あるいは本文中の旧社名を機械的に新社名へ置換してしまうケース。Web上から新旧をつなぐ自社発の情報が消え、AIは第三者サイトに残った旧社名情報だけを参照することになる。正しい処理は、過去のリリースを原文のまま残し、冒頭に「当社は2026年◯月に◯◯から◯◯へ社名を変更しました」の注記を1行足すことだ。

失敗例2：移転後すぐに旧住所の記載を全部消す。 請求書送付先や配送先の変更が取引先に浸透する前に旧住所への言及を消すと、外部DBに残る旧住所と自社サイトの新住所が「別々の会社の情報」に見える期間が生まれる。移転から一定期間は「旧本店：◯◯（2026年◯月まで）」の形で新旧を並記する。

失敗例3：Googleビジネスプロフィールを新規作成する。 同一拠点の移転なのに新しいプロフィールを別に作ると、旧プロフィールが旧住所のまま残り続け、地図やAI Overview経由の回答が旧住所を返す原因になる。クチコミ・写真の蓄積も引き継がれない。同一事業の移転は既存プロフィールの所在地編集で対応する。複数拠点を持つ企業の設計思想は多店舗チェーンのAI検索対策で扱っている。

失敗例4：AIのチャット欄で訂正を繰り返す。 「うちの社名は変わった」とチャットで伝えても、その会話がモデルの知識を書き換えることはない。各サービスに回答へのフィードバック機能はあるが、個別企業の情報修正を受け付ける訂正窓口として運用されているとは公表されておらず、反映の可否・時期も明らかにされていない（2026年9月時点）。労力は情報源の更新に振り向ける。

失敗例5：発表と同時に全部を動かす。 社名変更・本店移転・ドメイン変更・サイト全面リニューアルを同じ日に実施すると、回答が乱れたときに原因を切り分けられない。少なくともドメイン変更とサイト構造変更は時期を分け、分けられない場合はリダイレクトマップと変更前URLの一覧を発表前に保全しておく。

失敗例6：掲載先の棚卸しを広報だけに任せる。 会社情報は採用媒体、業界団体の会員名簿、展示会の出展者情報、クラウドサービスの請求先データにも散っている。広報部門だけでは全体像が見えず、各部門から集める形にしないと必ず漏れる。

実装チェックリスト。1枚で抜け漏れを点検する

ここまでの手順を、社内の進捗管理にそのまま使える形へ集約する。フェーズの区切りは、発表前・効力発生後・運用の3段階で考えるとよい。

6番以降は、変更イベントに限らず平常時のLLMO運用へそのまま接続する。イベント対応で作った掲載先一覧表と観測記録は使い捨てにせず、継続運用の資産として引き継ぐ。新拠点の立ち上げを伴う場合は開業時のLLMO対策の手順も重なる。

反映状況の確認。新社名と旧社名の2系統で観測する

更新を終えたら、反映状況を定点観測する。観測の基本設計はAI検索でブランド名を調べた時に確認すべき回答パターンの枠組みが流用できるが、変更イベント時に固有なのは、質問を新社名で聞く系統と旧社名で聞く系統の2つに分ける点だ。

これをChatGPT（検索ありと検索なしの両方）・Gemini・Perplexity・GoogleのAI Overviewで定期的に実施し、回答本文と参照元URLを記録する。参照元に旧情報のページが出てきたら、それがそのまま次の更新依頼先リストになる。「どこを直せば回答が変わるか」を推測ではなく実データで特定できるのが、観測を続ける最大の実利だ。

読み解き方の目安はこうだ。検索ありでは新社名、検索なしでは旧社名という結果なら、第2層の補正は効いており、残りは学習データの更新待ちと判断してよい。検索ありでも旧社名が返るなら、引用されている旧情報ページを特定して個別に潰す。どちらでも新社名が返り、旧社名の質問でも社名変更に言及されるなら、この局面の対応はほぼ完了と見てよい。

反映までの期間は各社とも公表しておらず、サービスと質問によってばらつくため、特定の日数を前提にした社内計画は立てないほうがよい。観測の記録方法や継続の型はAI回答に引用されているかをモニタリングする方法にまとめている。

よくある質問

旧社名の情報は、いつまで残しておくべきですか

移行アナウンスページと構造化データのalternateNameに入れた旧社名は、恒久的に残してよい。過去の受賞歴・導入実績・報道・特許は旧社名で記録されているため、接続情報を消すメリットがほとんどない。一方で、フッターや会社概要の「（旧社名：◯◯）」併記は、主要な外部データソースの更新が完了し、定点観測で旧社名の質問に対して社名変更が言及される状態になったら外してよい。判断の軸は年数ではなく、観測結果である。

社名変更とドメイン変更は同時にやっても大丈夫ですか

避けられるなら時期をずらすことを勧める。同時に行う場合は、全URLの301リダイレクトを用意し、Search Consoleのアドレス変更ツールで移転を通知する。Googleの公式ドキュメントはリダイレクトを最低1年維持するよう案内しており、ユーザー体験の観点からは無期限の維持も検討するとしている。リダイレクトの連鎖は短く保ち、5ホップを超えないようにする。

AIに「社名が変わった」と直接報告する窓口はありますか

各サービスに回答へのフィードバック機能（評価ボタンや報告フォーム）はあるが、個別企業の情報修正を受け付ける公式な訂正窓口として運用されているとは公表されておらず、反映の可否・時期も明らかにされていない（2026年9月時点）。主軸は情報源側の更新に置き、フィードバックは補助として使う。

合併や持株会社化で旧社名が複数ある場合はどうしますか

旧社名ごとに新社名との対応を明示する。移行アナウンスページには沿革として「A社とB社が合併して◯◯となった」という構造を書き、alternateNameには主要な旧社名を複数入れる。法人とブランドが分離する体制（持株会社と事業会社、統一ブランドと複数法人など）では、そもそも「どの名前がどの実体を指すか」の設計から見直す必要があり、単純な商号変更より整理の粒度が上がる。

屋号やサービス名だけを変える場合も同じ対応が必要ですか

法人格が変わらないぶん公的手続きは軽くなるが、AI検索側の課題はほぼ同じだ。旧サービス名で検索した人が新サービス名へ橋渡しされる経路が必要で、移行アナウンスページとalternateNameへの旧名称追加は同様に効く。むしろ登記という公的な裏付けが使えないぶん、自社サイトでの宣言と第三者メディアでの言及に依存する度合いが高くなる。プレスリリースと主要媒体への掲載更新を、法人の商号変更時より丁寧に設計したい。

結論

社名変更・本店移転のあとにAIが旧情報を答え続けるのは、担当者の更新漏れというより、学習済みの知識・回答時の検索参照・外部データベースという3層それぞれに旧情報が残る構造の問題だ。自社が直接動かせるのは第2層と第3層であり、実務は3本柱に集約される。新旧の対応を1文で言い切る移行アナウンスページを常設すること。alternateNameに旧社名を残したうえでlegalName・address・サイト名まで整合させること。登記を起点に、法人番号公表サイト、Googleビジネスプロフィール、第三者データベースの順に外部を更新すること。

そして一貫した原則は、旧社名・旧住所を消さないことだ。旧情報は誤情報ではなく、新情報へ渡るための橋である。橋を落としてしまえば、AIは第三者サイトに残った古い岸からしか自社を見られなくなる。

社名変更や移転を控えていて、自社が今AIにどう説明されているか、どの情報源が旧情報の発生源になりそうかを事前に把握しておきたい場合は、UravationのLLMO診断で現状の回答パターンと参照元の棚卸しから始められる。着手は登記より前、発表計画の段階が理想だ。

参考・出典

• Google Search Central — Organization (Organization structured data)
• Google Search Central — Site names on Google Search（サイト名）
• Google Search Central — Site move with URL changes（URL変更を伴うサイト移転）
• 国税庁 法人番号公表サイト
• IndexNow 公式ドキュメント

※ 上記は執筆時にアクセスして確認した一次情報です。制度・仕様は変わるため、最新の内容は各公式ページで確認してください。