IRのためのAIO・LLMO対策｜AIはどの版の開示を語るのか — 予想・実績・訂正開示の管理

生成AIが自社について語る内容を照合するとき、多くの設計は「数字が合っているか」を見る。決算期、会計基準、通貨、単位、連結範囲。だが上場企業の開示には、値とは別の軸がもうひとつある。同じ「売上高1,000億円」でも、それが当初予想なのか、修正予想なのか、実績なのか、訂正開示を経た後の数値なのかで、投資判断上はまったく別の情報である。

東京証券取引所は、業績予想の修正・予想値と決算値の差異等と、配当予想・配当予想の修正を、それぞれ独立した適時開示の区分として掲げている（東証「適時開示が求められる会社情報」／2026年7月10日現在）。制度の側では、値そのものではなく「その値がどの状態のものか」が区別されている。にもかかわらず、AI回答の照合においてその数字がどの状態のどの版かを管理する枠組みは、本稿で確認した範囲では確認できなかった。

本稿の主張はひとつである。正解表に「値」の列だけでなく、「状態」と「版」の列を持たせる。 開示は上書きされる。予想は修正され、実績で置き換わり、ときに訂正開示で遡って書き換わる。「公表済みの一次資料＝正解」という前提そのものが、時間とともに崩れるからである。

• 値が一致していても、状態を誤れば重大な誤りになる理由と、その制度的な裏付け
• 開示の状態を4つに分けて扱う整理（当初予想／修正予想／実績／訂正開示後）
• 訂正開示が「正解表の正解値そのもの」を書き換えるときの処理
• 有価証券報告書・決算短信・適時開示・決算説明資料・IRサイト本文が矛盾したときの優先順位の決め方
• 正解表に足す5つの列（status / supersedes / superseded_by / effective_from / precedence）とCSVの実装例
• 開示イベントを再計測の起点にする運用と、確認タイミングの組み方
• IRサイト側で「どれが現行版か」を示すためにできることと、できないこと

上場企業のIR実務担当者のうち、AI回答の照合をすでに始めている方、または始めようとしている方。副次的に、訂正開示の判断に関わる法務・経理の担当者。

本稿はAI回答の照合テストをどう設計するかの続編である。正解表の基本設計、反復・ステートレスな計測が必要な理由、記録項目、指標の定義と経営層への報告の形は、すべて同記事にある。本稿はそれらを前提として引き継ぎ、「状態」と「版」の軸だけを足す。 AIが自社の財務情報をどう語るかという問題設定そのものと、誤りの4類型、フェア・ディスクロージャー上の境界については、親となるAIは自社の財務情報をどう語っているかを参照されたい。

免責: 本稿は上場企業のIR実務の参考として、公開情報にもとづく整理を提供するものである。法務・会計上の判断、開示の要否の判断、個別の投資判断に用いることを意図していない。制度の適用については所管の証券取引所・監督当局・自社の顧問弁護士および会計監査人に確認されたい。

1-1. 既存の照合は「値」の軸で組まれている

AI回答の照合を実装すると、正解表はまず「値」を持つ。売上高、営業利益、1株当たり配当、従業員数。そして値だけでは判定できないことに気づき、決算期、会計基準、通貨、単位、連結の範囲といった列が足される。ここまでは、同じ数字が別の意味を持ってしまう事故を防ぐための設計である。

この軸は必要だが、十分ではない。決算期も会計基準も通貨も単位も一致していて、なお誤答になる経路が残っている。

1-2. 同じ数字が別の情報になる

具体的に置いてみる。ある企業の2026年3月期の連結売上高について、次の4つの数値が、いずれもその企業が公表した資料に載っているとする。

このとき、AIが「2026年3月期の連結売上高は1,000億円」と答えたとして、その1,000億円がどれを指しているのかが決まらなければ、正誤の判定ができない。 当初予想を答えているなら、投資家に届いている情報は1年以上前の見通しである。修正予想を答えているなら、実績が出た後もなお見通しの数字が流通していることになる。訂正開示の前の数値を答えているなら、企業自身が誤りとして公表し直した数値がまだ語られていることになる。

いずれの場合も、数字そのものは「かつて自社が公表した値」であって、捏造ではない。 出典を求めれば、実在する自社の資料が返ってくる可能性すらある。従来型の照合——値が一致するか、出典が実在するか——では、この経路は素通りしてしまう。

1-3. 足すのは「状態」と「版」の2つ

本稿では次の2語を使い分ける。

• 状態（status）: その数値が、予想なのか実績なのか、訂正開示を経たものなのかという区分
• 版（version）: 同じ状態の中で、何度目の公表なのかという序列。修正予想は複数回出ることがあり、訂正開示も一度とは限らない

状態と版は独立している。「修正予想の2回目」も「実績の訂正開示後」も、値だけを見れば同じ列に並ぶ。区別できるのは、公表された文書と日付を持っているときだけである。

なお、AI側の出力が入力条件によって動きうることは、日本のデータでも観測されている。TDnetで開示された決算短信（2019〜2023年）を対象に、企業名を明示した場合と除いた場合でセンチメント評価が変化することを報告した研究がある（Nakagawa, Hirano, Fujimoto、Evaluating Company-specific Biases。IEEE収録版あり。GPT-4oでの観測10,249件。偏りの方向はモデル間で一致していない）。この研究は開示の版の取り違えを測ったものではないが、入力条件によってモデルの出力が変化しうることを示す一例である。 本稿の照合では、判定対象を曖昧にしないため、どの版を指すかを問いの側で固定する。

2-1. 制度の側は、すでに状態を区別している

東証は、適時開示が求められる会社情報を区分ごとに掲げている。2026年7月10日現在の一次資料では、上場会社の情報について決定事実39項目、発生事実29項目が列挙され、これとは別に決算情報が3種類（決算短信、第2四半期（中間期）決算短信、第1・第3四半期決算短信）、業績予想・配当予想の修正等が2種類、その他の情報が8項目、掲げられている（東証「適時開示が求められる会社情報」）。

このうち本稿にとって決定的なのは、「業績予想の修正、予想値と決算値の差異等」と「配当予想、配当予想の修正」が、決算情報とは別立ての区分として置かれているという点である。予想を出すことと、予想を修正することと、実績を開示することは、制度上それぞれ別の開示行為として扱われている。

これは「数字が合っていても状態を誤れば重大な誤りである」という主張の、制度的な裏付けになる。制度の側でも、状態の変化が独立した開示対象として扱われている。

あわせて注意しておくと、東証は開示された情報について、開示の適正性を確保するための審査の観点を公表している。開示の時期が適切か／内容が虚偽でないか／投資判断上重要な情報が欠けていないか／投資判断上の誤解を生じさせないか／その他適正性に欠けていないかの5点である（東証「会社情報の開示の適正性の確保」。有価証券上場規程第415条第1項、第3条第2項）。これは企業が行う開示についての観点であり、AI回答についての観点ではない。

2-2. 4つの状態

本稿では、AI回答の照合に必要な範囲で、開示された数値の状態を次の4つに分ける。

★この4区分は本稿群の整理であり、業界で確立した分類ではない。 制度上の開示の区分と一対一で対応するものでもない。目的は、正解表の1列として機械的に判定できる粒度に落とすことにある。自社の開示実務に合わないなら、区分を足しても減らしても構わない。重要なのは区分の名前ではなく、値の列とは別に状態の列を持つことである。

2-3. 同じ構造を持つ、値以外の変化

状態と版の問題は、業績予想と実績だけの話ではない。次の変化も、「以前の公表値が誤りだったわけではないのに、現在の正解が別の値になる」という同じ構造を持つ。

• 株式分割の調整前後: 1株当たり配当、1株当たり利益、株価水準は、分割の前後で数値が変わる。株式の分割は決定事実として掲げられている
• 決算期の変更: 事業年度の末日の変更も決定事実として掲げられている。変更をまたぐと、「2026年度」という語が指す期間そのものが変わる
• 自社で定義したKPIの定義変更: 会員数、稼働率、受注残。定義を変えれば、同じ名前の指標が別の値になる。制度上の開示区分に対応しないため、社内でしか追跡できない
• 開示の区分自体の変更: 一次資料には、早期事業再生法に基づく権利変更決議の成立が2026年12月11日から発生事実に加わること、少数株主の賛成割合等の開示が2026年12月1日以後に終了する事業年度に係る定時株主総会の日から適用されることが注記されている。開示の枠組みの側にも版がある

最後の点は、正解表の運用に直接効く。「この質問はどの制度区分に紐づくか」を正解表に持たせている場合、制度側の改正で紐づけが古くなる。 制度の一次資料そのものにも確認日を持たせておく必要がある。

3-1. 用語をここで固定する

本稿では、似た2つの行為を厳密に書き分ける。以降、単独の語では書かない。

この2つは制度上まったく別のものである。 前者は開示制度の中の手続きであり、後者は民間サービスへの申し立てである。AI提供元に対してAI回答の訂正や削除を申し立てることが実際にどこまで可能かについては、AI回答の訂正・削除を申し立てられるかで扱っている。本稿は企業側の開示の版をどう管理するかだけを扱う。

3-2. 「公表済み一次資料＝正解」という前提が崩れる

AI回答の照合を設計するとき、暗黙に置かれる前提がある。自社が公表した一次資料は正しい、という前提である。 正解表の expected_value は、決算短信や有価証券報告書から転記される。出典欄には、その資料のURLとページが入る。

訂正開示は、この前提を壊す。訂正報告書または訂正開示の対象に、正解表が持っている数値が含まれていた場合、正解表の正解値そのものを見直す必要が生じる。

このとき起きることは3つある。

1. 正解表の expected_value を書き換える必要がある。 書き換えないと、AI回答が訂正開示後の正しい値を答えているのに「不一致」と判定される
2. 訂正開示の前の資料は、依然としてウェブ上に存在しうる。 自社サイト、報道、データベンダー、AIの学習済み知識、検索インデックス。これらのどこに残っているかを企業側から完全に把握することはできない
3. 過去の計測記録の解釈が変わる。 訂正開示の前に「一致」と記録した計測結果は、いま見れば「訂正開示前の値との一致」である

3つ目は見落とされやすい。計測記録を上書きしてはならない。 訂正開示の前の記録は、その時点で正しかった判定として残す。訂正開示によって過去の判定が変わることそのものが、開示品質の情報である。

3-3. 正解表の側で持つ2つの列

正解表の行を書き換えるのではなく、新しい行を追加し、古い行との関係を明示する。 そのために2つの列を置く。

• supersedes: この行が置き換えた、前の行の識別子
• superseded_by: この行を置き換えた、後の行の識別子。現行版では空

同じ質問に対して複数の行が存在し、そのうち superseded_by が空の行が現行版である。判定はこの行に対して行う。古い行は削除しない。 削除すると、「AIが答えたのは、いつの版か」を後から特定できなくなる。

この設計は、正解表を更新型ではなく追記型にすることを意味する。行数は増えるが、増え方そのものが管理対象になる。ひとつの質問に版が何度も積み上がっているなら、その論点は外部で誤解を生みやすい可能性がある。

3-4. ★越えてはならない線

訂正開示の話をすると、次の発想が出る。「AIが古い数値を語っているのだから、正しい数値を出して直せばよい」。

AI回答の訂正は、公表済み資料の再提示に限定する。未公表の重要情報でAI回答の訂正を行ってはならない。 これは本稿群を通じて動かさない前提である。AIの回答が誤っているという事実は、未公表情報を出す理由にならない。必要なら、適法な公表手続きを先に行う。公表の前後で何が変わるかについては、親記事のAIは自社の財務情報をどう語っているかでフェア・ディスクロージャーの境界を扱っている。

同じ理由で、正解表そのものに未公表の数値を載せない。 正解表は社内文書だが、外部委託先・ツール・クラウドサービスを経由することがある。正解表の各行には、必ず公表済みの出典文書と公表日が対応していなければならない。対応する公表資料がない行は、正解表に置かない。

4-1. 「一次資料」はひとつではない

上場企業の情報は、複数の公式文書に分散している。そしてそれぞれ、記載時点・記載の目的・数値の定義・対象範囲が異なる。

参考として、コーポレート・ガバナンスに関する報告書は、IR体制の整備の状況を開示する場所でもある。東証は、上場会社が企業行動規範においてIR体制を整備することを義務付けており、その整備の状況は同報告書での開示が必要とされている（東証「IR体制・IR活動」）。ここで注意が要る。義務付けられているのはIR体制の整備であって、AI上の自社認知を測定・管理することではない。 本稿が扱えるのは、「既存のIR体制の枠組みの中で、AI上の開示不整合をどこまで管理対象とみなすか」という一段までである。

なお、コーポレートガバナンス・コードは2026年7月版が公表され、改訂に係る有価証券上場規程の一部改正が2026年7月21日から施行されている（東証「コーポレートガバナンス・コード（2026年7月版）の公表について」）。市場区分ごとの適用範囲は本稿では確認していないため、区分別の記述は置かない。 コードは comply or explain の枠組みであり、法律ではない。

4-2. 優先ルールは、矛盾が起きる前に決める

一次資料が矛盾したとき、その場で「どちらが正しいか」を議論すると、判断の基準が回ごとに揺れる。揺れると、時系列で比較できなくなる。 先月の不一致と今月の不一致が、同じ基準で判定されていないからである。

したがって、優先順位はあらかじめ決めて正解表に書き込んでおく。 これが precedence 列の役割である。以下は実務上の提案であり、研究から導かれた最適解ではない。自社の開示実務に合わせて組み替えてよい。

ただし、この順位は「新しい方が優先」と両立させる必要がある。 有価証券報告書が決算短信より上位でも、決算短信が後から訂正開示されていれば、訂正開示の方が現行版である。したがって判定は2段階になる。

1. まず superseded_by が空の行だけを残す（版の判定）
2. 残った中で precedence の小さい順に採る（資料の判定）

4-3. 予想と実績を同じ質問で聞かない

優先順位を決めても、質問文が状態を指定していなければ意味がない。 「2026年3月期の売上高は」という問いは、当初予想でも修正予想でも実績でも成立してしまう。

したがって正解表の質問文は、状態まで含めて書く。

• 「2026年3月期の連結売上高の実績は」
• 「2027年3月期の連結売上高の会社予想の最新値は」

これは自然な聞き方ではない。だからこそ、投資家が自然な聞き方をしたときに何が返ってくるかも、別の質問として置く。 状態を指定した質問と、指定しない質問を対にして持つことで、「AIが状態を補って答えているのか、取り違えているのか」を切り分けられる。

本稿で確認した範囲では、AIが開示の版を取り違える割合を測った公開データは確認できなかった。 したがって本稿は発生の程度を示さない。構造として起きうる経路を示し、自社で確かめる方法を示すにとどめる。

状態の軸には、もうひとつ短い論点がある。株主総会に付議される予定の事項は、招集通知に掲載された時点では「株主総会で決議済み」ではない。

剰余金の配当、定款の変更、全部取得条項付種類株式の全部の取得は、いずれも決定事実として掲げられている（東証「適時開示が求められる会社情報」）。招集通知に議案として載った時点で、その内容は公表済みの情報である。しかしそれは、「会社がそう提案している」という情報であって、「株主総会で決議済み」という情報ではない。

AI回答の照合では、この違いが実務的に効く。総会前の期間に「年間配当はいくらか」と問うと、議案の金額が返ってくることがある。値は正しい。出典も実在する。しかし状態は「付議予定」であって「決議済み」ではない。

正解表では次のように扱う。

• 付議予定の事項は、status を分けて持つ（例: proposed）
• 総会の前後で、同じ質問の正解値が変わりうることをあらかじめ記録しておく（effective_from を使う）
• 総会後に決議の結果が開示されたら、新しい行を追加し、前の行の superseded_by を埋める

★会社法上、決議の効力がいつ発生するかという法的な論点には本稿は踏み込まない。 個別の判断は法務部門および顧問弁護士に委ねられるべき事項である。本稿が扱うのは、正解表の運用として「議案の状態」と「決議後の状態」を分けて持つという一段までである。

ここが実装の核である。既存の正解表に、5つの列を足す。

6-1. 5つの列

6-2. 既存の列との関係

前稿の正解表には、announced_date（その値が公表された日）、last_verified（正解表そのものを最後に検証した日）、source_document（出典文書名）がある。新しい列は、これらと役割が重ならない。

announced_date と effective_from を分ける理由を補足する。訂正開示は、過去の期間の数値を、後の日付で置き換える。 訂正報告書の提出日が2026年8月でも、置き換わる数値の対象期間は2025年3月期でありうる。対象の決算期は fiscal_period が担い、effective_from は「照合上、この行を現行版として扱い始める日」を担う。 公表日だけでは、この2つを分けて表せない。

6-3. CSVでの実装例

前稿と同じく、正解表は表計算ソフトでもCSVでもよい。ここでは列の定義をCSVのヘッダとして示す。画像にしない。 後の工程で機械的に突き合わせるためである。

row_id,question_id,question_ja,expected_value,status,fiscal_period,period_type,consolidation,accounting_standard,currency,unit,continuing_ops,announced_date,effective_from,supersedes,superseded_by,precedence,source_document,source_url,source_page,tolerance,last_verified
R001,Q010,2026年3月期の連結売上高の実績は,1234567,actual,2026-03,FY,consolidated,IFRS,JPY,million,continuing,2026-05-12,2026-05-12,,R004,3,kessan_tanshin,https://example.co.jp/ir/tanshin_2026q4.pdf,p.1,0,2026-08-16
R002,Q011,2027年3月期の連結売上高の会社予想の最新値は,1300000,initial_forecast,2027-03,FY,consolidated,IFRS,JPY,million,continuing,2026-05-12,2026-05-12,,R003,3,kessan_tanshin,https://example.co.jp/ir/tanshin_2026q4.pdf,p.1,0,2026-08-16
R003,Q011,2027年3月期の連結売上高の会社予想の最新値は,1250000,revised_forecast,2027-03,FY,consolidated,IFRS,JPY,million,continuing,2026-08-05,2026-08-05,R002,,4,gyoseki_yoso_shusei,https://example.co.jp/ir/rev_20260805.pdf,p.1,0,2026-08-16
R004,Q010,2026年3月期の連結売上高の実績は,1229000,restated,2026-03,FY,consolidated,IFRS,JPY,million,continuing,2026-08-20,2026-08-20,R001,,1,teisei_hokokusho,https://example.co.jp/ir/teisei_20260820.pdf,p.3,0,2026-08-21

この4行が示していることを読み解く。

• Q010（実績）には2つの行がある。R001 は superseded_by に R004 を持つため、現行版ではない
• R004 は訂正報告書に由来し、precedence が1で最上位。現行版はこちら
• Q011（予想）も2つの行を持ち、R003（修正予想）が現行版
• R001 を削除していないため、「AIが1234567と答えた」ときに「訂正開示前の値を答えている」と判定できる

最後の点が、この設計の実利である。古い行を残しているから、誤りの種類が特定できる。 削除していれば、単に「不一致」としか記録されない。

6-4. 判定の細分化

状態の列を持つと、判定の粒度が上がる。前稿の照合では一致・不一致を記録するが、状態の軸を足すと、不一致がさらに分かれる。

• 値も状態も一致: 問題なし
• 値は一致、状態が異なる: 版の取り違え。AIは実在する自社の公表値を答えているが、現行版ではない
• 値が不一致: 従来型の誤り。数値そのものが自社の公表値と一致しない
• 値が不一致で、かつ過去の版とも一致しない: 出所が自社の公表資料ではない可能性

2つ目と4つ目は、対応の方向がまったく違う。版の取り違えは、自社側の情報提示の問題として扱いうる。 現行版が見つけにくい、過年度のページが年度を明示していない、古いページが検索から到達可能なまま残っている、といった原因が自社側にあるなら、自社側で手を打てる。4つ目は、そもそも自社の資料が参照されていない可能性を示す。

7-1. 定期計測とイベント駆動を組み合わせる

前稿では、反復的・ステートレスな計測の設計を扱った。本稿が足すのは、「いつ再計測するか」を開示イベントに紐づけるという考え方である。

理由は単純で、状態が変わる瞬間は、企業側が知っているからである。 業績予想の修正を開示した日、決算短信を出した日、有価証券報告書を提出した日、訂正開示を行った日。これらは自社のカレンダーにある。定期的な計測だけだと、状態が変わってから次の計測までの間が空白になる。

7-2. 確認タイミングの組み方

以下は頻度の一例である。リスクの大きさ、開示イベントの種類、運用コストに応じて、各社で設定されたい。 研究から導かれた最適値ではない。

「2週間後」に固定的な根拠はない。開示の直後と、しばらく経った後で結果が違うかどうかを見るために、2つの時点を置いているというだけである。自社で1度回してみて、変化が見られないなら間隔を広げてよい。

7-3. 計測の条件は前稿の設計を引き継ぐ

1回の回答は1つの観測にすぎない。 同じ問いを1回投げて得た答えから、そのAIが自社について返す安定的な傾向を推定することはできない。この理由と、反復・ステートレスな計測の必要性、記録項目の設計は、AI回答の照合テストをどう設計するかにある。本稿はそれを前提とする。

計測の安定性が正しさの証拠にならないことも、あわせて押さえておきたい。財務分野のベンチマークでは、同一の質問への8回の再回答がすべて一致する状態でも、15〜23%が誤答であったと報告されている（FinQAを用いた高確信誤答の研究／2026年7月のプレプリント。査読を経ていない。公開されているAI検索製品ではなく、基盤モデルのベンチマーク上の結果である）。答えが揺れないことは、答えが正しいことを意味しない。

Vaipmでは、AI上の認知を、複数のAIへの合計25回のステートレス計測で測定している。この回数は研究から導かれた最適値ではなく、Vaipmの運用設計である。

8-1. 外部の公開場所には期限がある

自社の開示資料が、外部の公開場所にいつまで置かれるかは、制度で定まっている。TDnetを通じて公開された資料は、開示日を含めて31日分（土日祝を含む）が適時開示情報閲覧サービスで閲覧でき、過去10年分が東証上場会社情報サービスで閲覧できる。あわせて、過去5年分の開示データは有料のデータベースサービスで縦覧可能とされている（東証「TDnetの概要」）。

ここから導かれる実務上の帰結はひとつである。継続的に参照できる場所を自社で持つ必要がある。 適時開示情報閲覧サービスのURLを出典として持っている正解表は、31日を過ぎると出典を辿れなくなる。正解表の source_url は、自社のIRサイト上の恒久的なURLを第一に置き、制度側のURLは副として持つのが扱いやすい。

8-2. 自社サイトでできること

版の管理という観点から、自社サイトで手を打てるのは次の範囲である。

• 過年度ページに年度を明示する: ページタイトル、見出し、本文の冒頭に、どの事業年度の情報かを書く。ファイル名や階層だけに頼らない
• 現行版への導線を、過年度ページの側に置く: 古いページに辿り着いた読み手が、最新版へ移動できるようにする
• 訂正開示を行った項目は、訂正開示後の資料と併せて掲示する: 訂正開示の事実そのものが情報である
• 主要な数値をHTMLのテキストとしても提供する: PDFのみでの提供を避ける
• 重複を減らす: 同じ内容が複数のURLで到達可能な状態を整理する。Googleは、同じ内容が多数のURLから到達できることは利用者にとって分かりにくく、コンテンツの成果を追いにくくなると説明している（Google Search Central「What is canonicalization」／2026年8月20日更新）

HTMLでの提供については、限定的な証拠がある。欧州の上場20社を対象に、HTML形式の年次報告書を持つ企業について回答の正答率が71%、PDF中心の企業について54%だったとする実務レポートがある（GenAI as a Reader。正答率の部分標本 n=200）。ただしこれはデジタルIRレポート事業者を含む共同調査であり、当事者性がある。査読状況も確認できていない。HTML群でも29%は不正確と判定されており、「HTML化すれば正しくなる」とは言えない。 企業規模やIR品質、更新体制の違いが混在している可能性がある。

8-3. できないこと

どのURLを代表として扱うかを、企業側が決めることはできない。 Googleは、正規URLの指定について、こちらの希望を示すことはできるが、それはヒントであってルールではないと明記している。指定と異なるページが正規として選ばれることがある（前掲「What is canonicalization」）。

また、生成AI機能に表示される前提について、Googleは、ページがインデックスされ、スニペット付きで検索結果に表示可能であること、加えてSearch Console上で生成AI機能への含有が有効であることを挙げている。そのうえで、要件・ベストプラクティス・ポリシーをすべて満たしていても、クロール・インデックス・表示が保証されるわけではないと明記している（Google Search Central「Optimizing your website for generative AI features on Google Search」／2026年7月10日更新）。

同じ資料で、Googleはllms.txt などの機械可読ファイルや特別なマークアップは、Google検索（生成AI機能を含む）に表示されるために必要ではなく、Google検索はそれらを使用しないと述べている。 構造化データについても、生成AI検索のために必須ではないとしている。したがって本稿は、これらを「Googleで効く施策」として推奨しない。 構造化データはリッチリザルトの対象になりうるため、通常のSEOの一部として続ける価値はあるが、AI向けの追加施策として位置づけるのは、Googleの説明と整合しない。

なお、Googleは生成AI機能の仕組みとして、検索インデックスから関連ページを取得する検索拡張生成（RAG）と、モデルが関連する複数のクエリを同時に発行する query fan-out を挙げている。「AI向けの特別な技術要件やマークアップが不要である」ことと「専用の処理がない」ことは別である。 前述のとおりGoogleは、通常の検索要件に加えて、Search Console上で生成AI機能への含有が有効であることを表示資格として挙げている。不要とされているのはllms.txtなどのAI向けの追加的な技術施策であって、通常の検索結果とAI回答が同じ処理を経ていることまでは示されていない。

自社サイトの変更が、各AIの回答にいつ反映されるかは、企業側から制御できない。 反映までの時間と、いったん出た情報がどれだけ参照され続けるかについては、AI回答に、その情報はいつまで残るのかで扱っている。本稿の関心は逆向きで、AI側の挙動ではなく、自社側でどれを現行版として示すかにある。

Q1. 値が一致していれば、状態まで見る必要はないのではないですか

必要です。値が一致していても、状態が違えば投資判断上は別の情報になります。たとえばAIが当初予想の売上高を答えたとき、その数値は自社が実際に公表したものなので、値だけの照合では「一致」と判定されます。しかし実績が出た後にその数値が流通しているなら、投資家に届いている情報は古い見通しです。値の照合は状態の照合を代替しません。両方を持ってはじめて、誤りの種類を切り分けられます。

Q2. 当初予想・修正予想・実績・訂正開示後という4区分は、業界で決まった分類ですか

いいえ。この4区分は本稿群の整理であり、業界で確立した分類ではありません。 制度上の開示の区分と一対一で対応するものでもありません。目的は、正解表の1列として機械的に判定できる粒度に落とすことにあります。自社の開示実務に合わないなら、区分を足しても減らしても構いません。重要なのは区分の名前ではなく、値の列とは別に状態の列を持つことです。

Q3. AIが開示の版を取り違えるのは、どのくらいの頻度で起きますか

本稿で確認した範囲では、その割合を測った公開データは確認できませんでした。 したがって本稿では発生の程度を示していません。示せるのは、構造としてどういう経路で起きうるかと、自社で確かめる方法までです。頻度を知りたい場合は、自社の正解表を作り、一定期間の計測結果から自社の数値として出すのが現実的です。他社の数値を借りても、開示の出し方も資料の構成も違うため、そのまま当てはまりません。

Q4. 正解表の古い行は削除してよいですか

削除しないことをお勧めします。古い行を残しているから、AIが答えた数値が「訂正開示前の値」なのか「まったく出所不明の値」なのかを区別できます。削除してしまうと、どちらも単に「不一致」としか記録されず、対応の方向を決められません。正解表は更新型ではなく追記型にし、superseded_by が空の行を現行版として扱うのが扱いやすい設計です。

Q5. 訂正開示を行った後、AI回答の照合はどう変えればよいですか

3つの作業が要ります。第一に、正解表に新しい行を追加し、前の行の superseded_by を埋めます。第二に、過去の計測記録は上書きせず、そのまま残します。訂正開示の前に「一致」と記録した判定は、その時点では正しかったものです。第三に、訂正開示の対象になった質問について、開示後と、しばらく期間をおいた後の2つの時点で再計測します。訂正開示前の値が返り続けているかどうかを見るためです。

Q6. AIが古い数値を語っているとき、未公表の情報で正すことはできますか

できません。AI回答の訂正は、公表済み資料の再提示に限定します。未公表の重要情報でAI回答の訂正を行ってはなりません。 AIの回答が誤っているという事実は、未公表情報を出す理由になりません。必要であれば、適法な公表手続きを先に行ってください。同じ理由で、正解表そのものにも未公表の数値を載せないでください。正解表は社内文書ですが、外部の委託先やツールを経由することがあります。

Q7. 有価証券報告書と決算短信で数値が違うとき、どちらを正解にすべきですか

矛盾が起きてから決めるのではなく、あらかじめ優先順位を決めて正解表に書いておくことをお勧めします。判定が回ごとに揺れると、時系列で比較できなくなるためです。本稿では実務上の提案として、訂正報告書・訂正開示、有価証券報告書、決算短信、適時開示、決算説明資料の順を示していますが、研究から導かれた最適解ではありません。あわせて、版の判定（現行版かどうか）を資料の判定より先に行ってください。

Q8. 株主総会に付議予定の議案を、正解表に入れてよいですか

入れて構いませんが、状態を分けてください。招集通知に載った時点で情報は公表済みですが、それは「会社がそう提案している」という情報であって、「株主総会で決議済み」という情報ではありません。status を付議予定として持ち、総会後に決議の結果が開示されたら新しい行を追加します。なお、決議の効力がいつ発生するかという会社法上の論点は本稿では扱っていません。個別の判断は法務部門にご確認ください。

Q9. 東証はAI上の自社認知の管理を求めているのですか

いいえ。東証が企業行動規範で義務付けているのはIR体制の整備であり、その整備の状況をコーポレート・ガバナンスに関する報告書で開示することです。AI上の自社認知を測定・管理することは義務ではありません。 本稿が扱えるのは、既存のIR体制の枠組みの中で、AI上の開示不整合をどこまで管理対象とみなすか、という一段までです。制度上の義務と自主的な取り組みを混ぜないでください。

Q10. IRサイトを直せば、AIの回答はいつ変わりますか

企業側から制御できません。変更がいつ反映されるか、いったん出た情報がどれだけ参照され続けるかは、AI回答に、その情報はいつまで残るのかで扱っています。本稿の関心は逆向きで、AI側の挙動ではなく、自社側でどれを現行版として示すかにあります。反映を待つ前に、自社サイトで現行版が見つけやすい状態になっているかを先に確認してください。

Q11. llms.txt を置けば、AIに正しい版を伝えられますか

Googleについては、そのように期待しないでください。Googleは、llms.txt などの機械可読ファイルや特別なマークアップは、Google検索（生成AI機能を含む）に表示されるために必要ではなく、Google検索はそれらを使用しないと述べています。構造化データについても、生成AI検索のために必須ではないとしています。他のサービスが同じファイルをどう扱うかは、それぞれの提供元の説明を確認してください。本稿はこれをGoogleで効く施策として推奨しません。

Q12. 何から始めればよいですか

まず、既存の正解表に status の列を1つ足すところからで十分です。既存の質問を、当初予想・修正予想・実績・訂正開示後のどれを聞いているかで分類し直します。この作業だけで、状態を指定していない質問がどれだけあるかが見えます。次に、直近の開示イベントを1つ選び、その前後で再計測してみてください。版の管理が必要な論点が自社にあるかどうかは、1回の計測で見当がつきます。

本稿の主張は1つに絞られる。AI回答の照合において、値の一致だけを見るのでは足りない。その数値がどの状態のどの版かを、正解表の列として持つ。

要点を整理する。

1. 東証は業績予想の修正・予想値と決算値の差異等と、配当予想・配当予想の修正を、それぞれ独立した適時開示の区分としている。制度の側でも、状態の変化が独立した開示対象として扱われている
2. 開示は上書きされる。予想は修正され、実績で置き換わり、訂正開示で遡って書き換わる。「公表済み一次資料＝正解」という前提そのものが崩れる
3. 当初予想・修正予想・実績・訂正開示後という4区分は、本稿群の整理であり、業界で確立した分類ではない
4. 正解表に status / supersedes / superseded_by / effective_from / precedence を足す。古い行は削除せず、追記型にする
5. 一次資料が矛盾したときの優先順位は、矛盾が起きる前に決めておく。版の判定を資料の判定より先に行う
6. 開示イベントを再計測の起点にする。状態が変わる瞬間は、企業側が知っている
7. 自社サイトでできるのは、現行版を見つけやすくすることまでである。どのURLを代表とするかも、AI側にいつ反映されるかも、企業側から制御できない
8. AI回答の訂正は、公表済み資料の再提示に限定する。未公表の重要情報でAI回答の訂正を行ってはならない

次に取れる行動は3つある。

• 今日: 既存の正解表を開き、各行が当初予想・修正予想・実績・訂正開示後のどれを聞いているかを分類する。分類できない行は、質問文が状態を指定していない
• 次の開示イベント: 業績予想の修正でも決算発表でもよい。開示の当日と2週間後に、対象の質問を再計測し、前の版が返っていないかを見る
• 四半期ごと: superseded_by が空の行だけを抽出し、それが本当に現行版かを一次資料と突き合わせる

測定の全体設計（正解表の基本、反復・ステートレス計測、記録項目、指標と経営層への報告）はAI回答の照合テストをどう設計するかに、AIが自社の財務情報をどう語るかという問題設定と誤りの4類型はAIは自社の財務情報をどう語っているかにある。AI上の自社認知を継続的に管理するという考え方そのものは、AIPMとはで整理している。

免責: 本稿は上場企業のIR実務の参考として、公開情報にもとづく整理を提供するものである。法務・会計上の判断、開示の要否の判断、個別の投資判断に用いることを意図していない。本稿に示した列の設計、優先順位、確認タイミングはいずれも実務上の提案であり、研究から導かれた最適解ではない。制度の適用については所管の証券取引所・監督当局・自社の顧問弁護士および会計監査人に確認されたい。

一次・公式（確認日: 2026年8月31日）

1. 東京証券取引所「適時開示が求められる会社情報」（2026年7月10日現在。ページ更新日2026年7月3日） — https://www.jpx.co.jp/equities/listing/disclosure/info/
2. 東京証券取引所「IR体制・IR活動」（企業行動規範に基づくIR体制の整備義務、コーポレート・ガバナンスに関する報告書での開示） — https://www.jpx.co.jp/equities/listing/investor-relations/index.html
3. 東京証券取引所「会社情報の開示の適正性の確保」（開示審査の5観点。有価証券上場規程第415条第1項、第3条第2項） — https://www.jpx.co.jp/equities/listing/disclosure/examination/index.html
4. 東京証券取引所「TDnetの概要」（適時開示情報閲覧サービス31日分、東証上場会社情報サービス過去10年分、有料データベースサービス過去5年分） — https://www.jpx.co.jp/equities/listing/disclosure/tdnet/index.html
5. 日本取引所グループ「コーポレートガバナンス・コード（2026年7月版）の公表について」（有価証券上場規程の一部改正、2026年7月21日施行） — https://www.jpx.co.jp/corporate/news/news-releases/1020/20260721-01.html
6. Google Search Central「Optimizing your website for generative AI features on Google Search」（2026年7月10日更新） — https://developers.google.com/search/docs/fundamentals/ai-optimization-guide
7. Google Search Central「What is canonicalization」（2026年8月20日更新） — https://developers.google.com/search/docs/crawling-indexing/canonicalization

査読・学術（信頼度: 中〜高。留保を併記）

1. Nakagawa, Hirano, Fujimoto「Evaluating Company-specific Biases in Financial Sentiment Analysis using Large Language Models」（TDnet決算短信2019〜2023年。GPT-4oでの観測10,249件。IEEE収録版あり。偏りの方向はモデル間で一致していない） — https://arxiv.org/html/2411.00420v1

プレプリント（査読を経ていない。ヘッジして扱う）

1. FinQAを用いた高確信誤答の研究（同一質問への8回の再回答がすべて一致する状態でも15〜23%が誤答。2026年7月のプレプリント。基盤モデルのベンチマークであり、公開されているAI検索製品の評価ではない） — https://arxiv.org/abs/2607.11414

実務レポート（当事者性あり。独立した再現が必要）

1. GenAI as a Reader（USTP・HHL・nexxar共同、2026年。欧州上場20社。正答率HTML群71%／PDF中心群54%、正答率の部分標本 n=200。HTML群でも29%は不正確。nexxar はデジタルIRレポート事業者であり当事者性がある。査読状況は確認できていない） — https://digital-investor-relations.com/_assets/downloads/DIR_GenAI-as-Reader.pdf?h=E0wP6LL9

本稿で確認できなかった事項

• AIが開示の版を取り違える割合を測った公開データ — 本稿で確認した範囲では確認できなかった
• IR体制の整備義務化の施行日 — 一次資料で確認できなかったため、本稿では言及していない
• コーポレートガバナンス・コード2026年7月版の市場区分ごとの適用範囲 — 本稿では確認していないため、区分別の記述を置いていない