著者: 株式会社Vaigate（AI上の認知を、複数のAIへの合計25回のステートレス計測で測定するVaipmを運営）
IRサイトの情報は、AIのクローラーに届いているのでしょうか。JavaScriptで表示している部分や、外部サービスを組み込んだ箇所は取得されているのでしょうか。41日間の制御実験と大規模ログ観測をもとに、IRサイト特有の構造がAIからどう見えるのかを整理し、自社で確かめる手順とベンダーへの依頼文の型までを示します。
生成AIに自社のことを尋ねると、決算の数字は合っているのに、IRサイトに載せているはずの説明会資料や適時開示の一覧がまったく参照されていない——そういう回答に出会ったとき、何を疑えばよいのでしょうか。
このとき、内容の正しさを疑う前に確かめるべきことがあります。そのページは、そもそもAIの側から取得できる状態にあるのか。
本稿はこの一点を扱います。IRサイトは企業サイトの中でも構造が特殊で、その特殊さがそのまま取得可能性の論点になります。そしてこの領域には、「AIはJavaScriptを読めない」と「Googleは実行するから大丈夫」という2つの単純化があります。本稿は観測をもとに、この両方を否定します。
robots.txt 設計上の意味上場企業のIR担当者と、IRサイトのベンダー・IR支援会社と話す立場の方を想定しています。エンジニアであることは前提にしません。 技術用語は初出で説明します。
Bingbot は3ページ到達したが、著者は別経路による発見と解釈している）Googlebot が到達したのは、JavaScriptリンク群293ページのうち 2%、HTMLリンク群748ページのうち 5% だったAIのクローラーとJavaScriptの話題そのものは、IRに固有のものではありません。原理的な部分は LLMOとは で扱っています。それでもIRサイトを独立して論じる理由があります。IRサイトは、企業サイトの中で構造が明確に特殊だからです。
① コーポレートサイトと別のドメインに置かれることがある。 IR情報を ir.example.com のようなサブドメイン、あるいは別ドメインに置く構成です。これ自体は誤りではありませんが、robots.txt（後述）もサーバーの設定もドメインごとに別に存在するため、コーポレートサイト側の確認結果が、IRサイト側に当てはまるとは限りません。
② IR支援会社のシステムを組み込んでいる場合がある。 日本IR協議会 第33回「IR活動の実態調査」（2026年5月14日公表・回答948社。設問ごとに母数が異なります）では、IR実施企業の81.9%がIR支援会社を利用しており、現在利用中のサービスでは「動画の作成・配信」が41.0%、「開示資料の英文化」が42.7%と報告されています。株価情報やIRカレンダーのように外部から読み込む部品を使う構成もあり、このとき表示のしくみはベンダー側の仕様の影響を受けます。
③ 重要資料がPDFで提供されることがある。 Webページ本文が要約で、正確な数字はPDFの中にあるという構成は、IRでよく見られます。この扱いは §7 で論じます。先に申し上げると、本稿はここで断定をしません。
④ 株価情報・IRカレンダー・動画が外部提供で埋め込まれることがある。 代表的な方式が iframe（アイフレーム）で、ページの中に別のページを枠として読み込むしくみです（§6）。
⑤ 適時開示一覧が動的に読み込まれる構成をとることがある。 一覧がページを開いた後にJavaScriptで読み込まれ、あとから表示される構成です。人が見る分には問題は起きません。問題は、人以外が見たときです。
| IRサイト固有の構造 | AI取得上、確認が要る点 | 本稿での扱い |
|---|---|---|
| 別ドメイン／サブドメイン | 設定の確認範囲がコーポレートサイトと別になる | §10-5 |
| IR支援会社のシステム | 表示のしくみを自社が決めていない | §10-5 |
| 重要資料がPDF中心 | 取得のされ方について公開された直接検証を確認できていない | §7・§10-6・§11 |
| 株価・カレンダー・動画の外部提供 | 取得経路が増える | §6 |
| 適時開示一覧の動的読み込み | 初期HTML（後述）に一覧と導線が存在するか | §2・§4・§10-1 |
★上記のうち「ことがある」と書いた項目について、本稿は割合を示しません。 定量的な裏付けを確認できていないためです。
クローラーは、Webページを自動的に取得して回るプログラムです。ユーザーエージェントは、そのクローラーが自分を名乗る文字列で、GPTBot、Googlebot といった名前でアクセスログに残ります。「AIのクローラー」を1つの塊として扱わず、名前ごとに分けて見ることが重要です。
初期HTMLは、サーバーが最初に返してくる、JavaScriptが動く前のページです。ブラウザはこれを受け取ってからJavaScriptを実行し、足りない部分を描き足します。この処理がレンダリングで、人が見ている画面はその後の状態です。robots.txt は、サイトの入口に置くクローラー向けの案内文です。
Search Engine Land に2026年8月19日公表された記事で、Vinicius Stanula 氏が41日間の制御実験を報告しています。
約2,400ページの事業分類ディレクトリを対象に、21のトップレベル区分を2群へ分け、11区分では下位ページへのリンクを初期HTMLに直接書き込み、10区分ではJavaScriptで後から挿入しました。さらに sitemap を無効化し、パンくずリストと階層リンクも取り除き、JavaScript以外の発見経路を塞いでいます。 区分ページより1階層下への到達を「JavaScriptを実行した証拠」としました。
第1期（27日間）の結果です。数字は階層ページの到達ページ数です。
| ユーザーエージェント | JavaScript実行 | HTMLリンク群（748ページ） | JavaScriptリンク群（293ページ） |
|---|---|---|---|
Googlebot | あり | 35（5%） | 7（2%） |
GoogleOther | あり | 495（66%） | 142（48%） |
GPTBot（OpenAI） | なし | 748 | 0 |
ClaudeBot（Anthropic） | なし | 748 | 0 |
Bingbot | なし | 282 | 3 |
OAI-SearchBot（ChatGPT検索） | なし | 10 | 0 |
Meta-ExternalAgent | なし | 537 | 0 |
Amazonbot | なし | 735 | 0 |
ChatGPT-User（ユーザー起点の取得） | なし | 46 | 0 |
PerplexityBot | なし | 0 | 0 |
出典: Search Engine Land、2026年8月19日公表。★Bingbot のJavaScript群3ページについて、著者はJavaScriptの実行ではなく別経路による発見の可能性を指摘しています。
GPTBot は公開当日にHTML群759ページを走査し切りましたが、JavaScript群では区分ページ10件で止まり、その下へ1ページも進みませんでした。ClaudeBot も翌日、同じ形をなぞっています。深くまで進み、JavaScriptの境目で止まる形です。
Bingbot は第1期の27日のうち20日活動し、JavaScript群の区分ページを18日にわたり再取得しながら、挿入されたリンクを1本もたどっていません。26日目・27日目に3ページへ到達していますが、その区分の他ページへ広がらなかったため、著者は別経路での発見と読んでいます。
ChatGPT-User は、実際の利用者がChatGPTに質問した結果として動く取得です。実験期間中、HTMLリンク側には実利用によって到達していますが、JavaScriptリンクの先には到達していません。利用者が取りに行こうとしたページが、取れなかったということです。第2期以降の挙動は §4-5 で扱います。
ChatGPT-User の取得は46ページにとどまり、0という数字の母数が小さいPerplexityBot は第1期にホームページと robots.txt しか取得しておらず、階層ページへの到達が記録されたのは40日目です。この実験だけで「JavaScriptを実行しない」とは言えませんGoogleOther が Googlebot をHTMLページで約14対1の比で上回った点を、新規ドメインのクロール予算の副産物と読んでいます★以上を踏まえ、本稿は「主要なAIクローラーはJavaScriptを実行しない」と現在形で断定しません。「2026年8月19日公表の41日間の実験で観測された範囲では」という条件を、常に付けます。
制御実験は条件を絞れる代わりに規模が小さくなります。もう一方に、規模の大きな実ログの観測があります。
Vercel と MERJ が2024年12月17日に公表した共同調査は、Vercel のネットワークを通過した実際のアクセス記録を分析したものです。nextjs.org を主データとし、技術構成の異なる2つの求人サイトでも検証しています。1か月間の取得件数は次のとおりです。
| クローラー | 1か月の取得件数 |
|---|---|
Googlebot（Gemini と検索を含む） | 45億件 |
GPTBot（ChatGPT） | 5億6,900万件 |
| Claude | 3億7,000万件 |
AppleBot | 3億1,400万件 |
PerplexityBot | 2,440万件 |
GPTBot・Claude・AppleBot・PerplexityBot の合計は約13億件で、Googlebot の28%あまりにあたるとされています。出典: Vercel、2024年12月17日公表。
OAI-SearchBot / ChatGPT-User / GPTBot）、Anthropic（ClaudeBot）、Meta（Meta-ExternalAgent）、ByteDance（Bytespider）、Perplexity（PerplexityBot）、学習用データセットとして使われる Common Crawl（CCBot）Googlebot の基盤を利用）、AppleBot（ブラウザを用いる方式）ChatGPT のクローラーは取得の11.50%、Claude は23.84%をJavaScriptファイルの取得に使っていますが、実行はしていないというのが同調査の報告です。ファイルを取ることと動かすことは別だということです。
★同調査は重要な例外も記しています。初期HTMLの中に含まれているJSONデータや、遅れて届くReactサーバーコンポーネントは、取得の対象になりうる——AIのモデルはHTML以外の形式も解釈できるためです。論点は「JavaScriptを使っているか」ではなく、「最初に返ってくるものの中に、必要な情報と導線が入っているか」にあります。
nextjs.org での観測では、ChatGPT のクローラーは取得の57.70%をHTMLに、Claude は35.17%を画像に充てていました。★これは1つのサイトでの取得比率であり、IRサイトや企業サイトの母集団を代表しません。
同調査はまた、ChatGPT のクローラーが取得の34.82%を、Claude が34.16%を、存在しないページ（404）に費やしていたと報告しています（Googlebot は8.22%）。
★ここから因果を導かないでください。「404を減らせばAIに引用されやすくなる」という因果は実証されていません。 言えるのは、無効なURLへの取得を減らし現行のURLへ到達できる状態を保つことに、Web運用上の合理性がある、というところまでです。
本稿の山場です。IRサイトの技術構造を議論するとき、社内でもベンダーとの打ち合わせでも、次の2つの主張が出てきます。どちらも、公開されている観測とは噛み合いません。
この主張の根拠は、Google がJavaScriptのレンダリングを行うと公式に説明していることにあります。それ自体は正しい説明です。問題は、「Google」がひとつのクローラーではないことです。
41日間の実験で、JavaScriptリンクの先へ到達したのは Google の2つのユーザーエージェントだけでした。ここまでは主張Aと整合します。しかし内訳で様相が変わります。JavaScript群293ページのうち GoogleOther は142ページ（48%）に到達した一方、検索インデックスを構築する Googlebot は7ページ（2%）です。
著者は率直に書いています。GoogleOther の66%・48%という数字は、それらのページが Google の検索に出るかどうかについて何も語らない。検索での見え方に関わるのは Googlebot の側であり、その数字は2%である、と。
「レンダリングされた」ことと「検索インデックスに載る経路に乗った」ことは、別の事象です。 Google を名乗るアクセスをひとまとめに数えると、到達範囲を見誤りかねません。ベンダーからログを受け取っている場合、Googlebot と GoogleOther が分けて集計されているかは真っ先に確認する価値があります。
同じ実験で、Googlebot はHTMLリンク群748ページのうち35ページ（5%）にしか到達していません。 JavaScript群の2%は、HTML群の5%と並べて読むべき数字です。著者自身、GoogleOther が Googlebot をHTMLページで約14対1で上回ったことを新規ドメインのクロール予算の副産物と読み、確立したサイトでは Googlebot の比率はもっと高いだろうと述べています。
つまりこの実験から言えるのは、「Googlebot はJavaScriptを実行できない」ではありません。 言えるのは、この条件下では、検索インデックスを構築するクローラーの到達がそもそも薄く、JavaScript側ではさらに薄かったということです。能力の話と、自社のページが実際にその処理を受けているかは、別です。
補強材料もあります。同じ実験で GoogleOther のJavaScript側の発見は、HTML側より18%から27%遅れていました。レンダリングの順番待ちと実行の工程が挟まるためです。到達も均等ではなく、ある区分が52ページに達した一方、別の2区分は数週間1ページのままでした。順番の回ってこない枝がある、と著者は書いています。IRに引き付ければ、取得が遅れて困るページが、遅れやすい側に置かれていないかという問いになります。
反対方向の断定も、同じくらい危うい主張です。
第一に、実行するものがあります。 2024年12月17日公表の観測では、Gemini と AppleBot はJavaScriptを実行すると報告されています。
第二に、限定的な反例が報告されています。 EdgeComet が2026年1月15日に公表し同年2月17日に更新した実験報告では、新規ドメインを用いたログ観測で、ChatGPT-User が生のHTML文書だけを取得した一方、GPTBot については数百件のリクエストのうち1件、AJAX リクエストの発生を観測したとしています。報告はこれを「実行できることは示すが、実際にはめったに行わない」と要約しています。★当事者性と限定: EdgeComet はレンダリングを提供する事業者で、同記事は自社サービスへの導線で結ばれています。単一の新規ドメインでの自社実験であり、著者自身「これが最終結論だとは主張しない」と明記しています。「AIは絶対に実行しない」という命題への限定的な反例として扱うのが妥当であり、「実行するから安心してよい」の根拠にはなりません。
第三に、PerplexityBot の0は、この実験だけでは意味を確定できません。 第1期にホームページと robots.txt しか取得しておらず、階層ページへの初到達は40日目です。取りに来ていないものについて、実行できないとは言えません。
第四に、論点はそもそも「JavaScriptを使っているか」ではありません。 初期HTMLに含まれるJSONのように、HTML以外の形式でも取得の対象になりえます。問われているのは、最初に返ってくるものの中に、必要な情報とそこへの導線が入っているかです。
41日間の実験の著者は、クロールログは「到達できたか」を示すものでインデックスされたかは示さないと明記しています。さらに2024年12月の観測は、最新のドキュメントを尋ねても即時の取得記録が見られない場合があるとして、キャッシュや学習済みデータへの依拠の可能性を指摘しています。取得された ≠ インデックスされた ≠ 回答に使われた。 §10 の測定が取得側（ログ）と回答側（AIへの質問）の両方を見るのは、このためです。
第2期には、IRサイトの運用に直結する観測があります。HTMLに書き換えた後、GPTBot は2日以内に250ページを取得し、Bingbot は212ページを追加し、Meta-ExternalAgent も41日目までに走査を行いました。一部のクローラーでは、HTMLへ書き換えた後、短期間のうちに再発見が観測されたということです。ただし、すべてのクローラーが同じように戻ったわけではありません。
一方 ClaudeBot は、書き換え後も再取得を続けながら新しくリンクされたページを1ページも拾わず、Amazonbot は書き換えの6日前に離れていました。最も遅かったのは Google で、41日目時点で Googlebot は書き換えた区分のうち1ページ、GoogleOther は0ページしか訪れていません。
★これは1サイト・41日間の観測であり、一般法則ではありません。ただし、リニューアル直後に「AIの回答が古いままだ」と感じたとき、取得の遅れなのか別の要因なのかを切り分ける視点は与えてくれます。
主要な情報とそこへの導線を、JavaScript実行を前提としなくても取得可能な初期HTMLに置くことは、現時点の複数観測と整合する。
これ以上は書けません。特に、それによってAI回答の正答率や引用のされ方が何%改善するかは、本稿で確認した範囲では確認できませんでした。 実装手段の指定も本稿は行いません。手段は複数あり、選択はサイトの構成とベンダーとの契約に依存します。決めるべきは手段ではなく、まず現状を測ることです。
「AIのクローラーをブロックすべきか」という議論が社内で起きたとき、その問いの立て方自体が粗すぎることがあります。用途ごとに分かれているためです。
| ユーザーエージェント | 用途（公式ドキュメントの説明に基づく） |
|---|---|
GPTBot | 生成AIの基盤モデルの学習に使われうるコンテンツの取得 |
OAI-SearchBot | ChatGPT の検索機能で、サイトを検索結果に表示するための取得 |
ChatGPT-User | 利用者の操作を起点とした取得。自動巡回には使われない |
OAI-AdsBot | 広告として提出されたページの安全性の確認 |
出典: OpenAI「Overview of OpenAI Crawlers」。実務上重要な注記が4つあります。
OAI-SearchBot を許可しつつ GPTBot を拒否する設定ができると明記されていますrobots.txt の更新が検索側に反映されるまで、約24時間かかることがある。 変更直後に結果を判断しない、ということですOAI-SearchBot をオプトアウトしたサイトも、ナビゲーションリンクとしては表示されうると記されていますChatGPT-User は、利用者が起点となる操作であるため robots.txt のルールが適用されない場合があると記載されています。「robots.txt に書いたから ChatGPT からは一切アクセスされない」とは言えませんGPTBot を、現在の ChatGPT 検索と同一視しない2024年12月の観測で大量のクロールが報告された GPTBot は、学習用の取得です。利用者が質問したときに動くのは ChatGPT-User、検索機能での表示に関わるのは OAI-SearchBot です。同じ「ChatGPT のボット」として語ると、robots.txt の設計を誤ります。
他社では ClaudeBot（Anthropic）、PerplexityBot、Meta-ExternalAgent、Bytespider、Amazonbot、CCBot（Common Crawl）、Google-Extended などがあります。提供元ごとに区分の切り方が異なり、更新もされます。 各社の公式ドキュメントで確認してください。
IRサイトが別ドメインにある場合、robots.txt はそのドメインに固有のものです。コーポレートサイトの設定を確認しただけでは足りません。 また、CDNやWAF（不正アクセスを遮断するしくみ）の層で、robots.txt とは別に遮断されていることがあります。「許可しているつもりで、手前で止まっている」構成は起こりえます。 一括遮断の是非は LLMOとは で扱っています。
株価情報、IRカレンダー、動画、適時開示の一覧を外部サービスから読み込んでいるIRサイトがあります。ここで、よく見かける断定を本稿は採用しません。
「iframe の中がJavaScriptで動いているなら、JavaScriptを実行しないクローラーからは見えない」——もっともらしく聞こえますが、本稿で確認した範囲では、これを直接検証した公開調査は確認できませんでした。
論理にも飛躍があります。クローラーが iframe の読み込み先URLを発見し、別のリクエストとして取得する可能性があるためです。枠として読めるかと、中身のURLを取得できるかは別の問いです。書けるのは次の一段までです。
外部提供の部品を使うと、取得経路が増える。だから確認が要る。
「見えない」でも「見える」でもありません。確認の対象が増える、ということです。
外部提供の部分について、ベンダーやIR支援会社に確認できるのは次の点です。
robots.txt はどうなっているのか★最後の点についても、それがAI回答の正確さを何%下げるかという定量値は、本稿で確認した範囲では確認できませんでした。
外部提供をやめる必要はありません。同じ情報が、自社ドメインの初期HTMLにテキストとしても存在しているかを確認するのが現実的な線です。株価の生データを二重に持つ必要はありませんが、決算発表の予定日、説明会の開催日、開示のタイトルと日付を、埋め込み部品の中だけに置かない設計はとりえます。
IRでは重要資料がPDFで提供されることがあります。ただしPDFだけではなく、決算短信については TDnet でXBRLデータも提供されています（§8-3）。PDF中心のIRサイトでは、「AIはPDFを読むのか」は切実な問いです。本稿は、この問いに断定で答えません。
Google は公式ドキュメントで、テキストで構成されたPDFは Google 検索のインデックスの対象になりうると説明しています（画像化されたPDFにはOCRを適用する場合があるとも記されています）。「PDFは検索エンジンに読まれない」という一般化は、少なくとも Google 検索については誤りです。
一方で、AIのクローラーがPDF本文をどう扱うか——取得したPDFの中の表や注記をどこまで解釈し、回答生成にどう用いるか——を直接検証した公開実験は、本稿で確認した範囲では確認できませんでした。 2024年12月の観測にあるのは取得されたコンテンツ種別の比率までです。
したがって本稿は、「PDFは読まれない」とも「PDFでも読まれる」とも書きません。 この問いは §11（確認できていないこと）に置き、§10-6 で「自分で確かめる方法」として扱います。
★IR文書には、ページをまたぐ表、脚注、二段組み、画像化された財務表など、人が読んでも取り違えが起きうる形式があります。一般論ではなく、自社の資料の作りに即して確かめるほうが実務的です。 なお、HTML版とPDF版のどちらで提供するかがAI回答にどう関わるかは、親記事 生成AIは自社の決算をどう語るか で扱っています。
技術の話は、制度の話と混ざりがちです。ここを整理しておかないと社内の議論が空回りします。
TDnet は、適時開示をリアルタイムで公開する東京証券取引所のしくみです。公開閲覧は31日間、会社別検索は10年という期間が設定されています。★TDnet は取引所の制度であり、国の法令そのものではありません。 また、TDnet に開示したことと、自社IRサイトのページがAIから取得できる状態にあることはまったく別の事象です。制度上の開示義務を果たしていることは、技術的な取得可能性を保証しません。
TDnet では、決算短信、業績予想・配当予想の修正、コーポレート・ガバナンス報告書などが XBRL 化されています。
★ここで混同が起きます。XBRL は取引所の開示データ形式であり、schema.org はWebページに付けるマークアップです。 「XBRL を出しているから構造化データは対応済み」という理解は誤りで、目的も読み手も経路も違います。本稿は schema.org の設計には立ち入りません。
東京証券取引所は、業績予想の修正、予想値と決算値の差異、配当予想および配当予想の修正、組織再編、公開買付けを、それぞれ独立した適時開示の類型として定めています。同じ「売上高1,000億円」でも、当初予想か、修正予想か、実績か、訂正後かで、投資判断上はまったく別の情報になります。制度がこれらを区別しているという事実が、AI回答を照合するときの見方を決めます（§10-3）。
上場会社は、企業行動規範において、株主および投資者との関係構築に向けて必要な情報提供を行うための体制（IR体制）を整備することが義務づけられ、その整備状況はコーポレート・ガバナンスに関する報告書での開示が必要とされています。具体的な体制の内容は各社の判断に委ねられています。
★ここで踏み越えてはならない一線があります。本稿は「東京証券取引所がAI上の認知の管理を求めている」とは述べません。 IR体制の整備は取引所規則上の義務ですが、AI上の自社認知を測定・管理することは義務ではありません。 書けるのは、既存のIR体制の枠組みの中で、AI上の開示不整合をどこまで管理対象とみなすかという一段までです。各社が判断することであり、制度が指示していることではありません。
プライム市場の上場会社は、決算情報および適時開示情報について、2025年4月1日から、日本語による開示と同時に英語による開示が義務づけられています。 取引所規則に基づく義務であり、猶予の扱いが別途定められています。
適時開示情報の英文開示の範囲については、東京証券取引所のFAQに、日本語による開示の一部または概要のみでも認められる場合があるとして具体的な問答が置かれています。すべての適時開示について常に全文の同時開示が求められるわけではない点は、前提として押さえておく必要があります。詳細は同FAQで確認してください。
日本IR協議会 第33回「IR活動の実態調査」（2026年5月14日公表）では、IRサイトを有する企業への設問において、英文開示資料のうち「決算短信」が74.1%と最大であったと報告されています。設問ごとに母数が異なるため、他の設問の数字と合算はできません。
本稿がこの節で扱うのは一点です。日本語版と英文版という2つの公式情報が存在するとき、その取得可能性を別々に確認しているか。
★最後の点は制度側の論点でもあります。英文が一部または概要である場合、その差分が意図されたものか更新漏れかは、自社にしか判断できません。
★なお、「日本語と英語でAI回答が変わるか」という主題には踏み込みません。 これは言語や地域をまたぐ認知の論点であり、海外でのAI認知 の領分です。本稿が扱うのは、日本語ページと英文ページのそれぞれが取得できる状態にあるかどうかまでです。
ここが本稿の中核です。読んで終わりにせず、明日ベンダーと話せる状態にすることを目指します。
AI上の認知は、1回の質問では測れません。同じ質問でも実行ごとに回答が揺れるため、単発の結果を恒常的な状態とみなせないからです。
Vaipm はAI上の認知を、複数のAIへの合計25回のステートレス計測で測定している。
これは研究から導かれた最適値ではなく、Vaipm の運用設計である。
ステートレスとは、前の会話の文脈を持ち越さない状態です。会話を続けたまま追加で尋ねると前の回答に引きずられ、そのAIが本来どう答えるかが見えなくなります。以下の手順は、技術側（取得できているか）と回答側（実際にどう答えられているか）の両方を見るように組み立てています。
最も費用がかからず、最も効きます。ブラウザのJavaScriptを無効にして自社IRサイトを開いてください。Chrome では、設定の「プライバシーとセキュリティ」からサイトの設定に進み、JavaScript を「サイトによる JavaScript の使用を許可しない」に変更します。確認後は必ず元に戻してください。
★見るべきは、見た目の崩れではありません。 レイアウトが崩れるのは当然です。確認するのは、情報と、そこへの導線が存在するかです。
より正確な方法もあります。ページ上で右クリックし「ページのソースを表示」を選ぶと、初期HTMLがそのまま表示されます。検索機能で、確認したい開示のタイトルや数字が含まれているかを見ます。含まれていなければ、それは初期HTMLに存在していません。
技術側と並行して回答側を見ます。質問は、自社の開示に正解が存在するものに限ります。正解が定義できることが、IRの利点です。
これを、毎回新しい会話として投げます。同じ会話の中で繰り返さないでください。実行日時と使ったサービス名を記録します。
回答が出てきたら、次の3つを別々に見ます。
| 確認軸 | 見るもの | ずれの例 |
|---|---|---|
| 数字 | 金額・株数・比率・単位・通貨 | 百万円と千円の取り違え、連結と単体の混同 |
| 時点 | どの決算期・どの発表日の情報か | 前期の数字が現在の数字として語られる |
| 状態 | 当初予想／修正予想／実績／訂正後のいずれか | 修正前の予想が実績として語られる |
★「状態」の確認は、IRに固有で、かつ最も見落とされます。 §8-3 のとおり、東京証券取引所は業績予想の修正や予想値と決算値の差異を独立した開示類型としています。数字が一致していても状態を誤っていれば、それは重大な誤りです。
照合の具体的な設計——正解表の作り方、頻度、記録の型——は、姉妹記事 AI回答の照合テスト で扱っています。本稿は技術面に絞ります。
回答にURLが示されていたら、それが自社のどのページかを確認します。自社IRサイトか外部の情報サイトか。自社なら現行のページか、旧ドメインや旧構成のページか。そのURLはいま開いて表示されるか。そして逆から見ます。 主要ページを一覧にし、一度も引用されていないページがないかを確認します。
★引用されない理由は複数ありえます。取得できていない、取得はされたが使われていない、質問が合っていない、他により適した情報源がある——これだけでは分かりません。ただし手順1でそのページが初期HTMLに存在しないと分かっているなら、取得できていない可能性を優先して調べる価値があります。
取得の実態に最も近い確認です。ただし、ユーザーエージェント名は詐称されうるため真正性の確認が要りますし、IR担当者がサーバーログを直接見られるとは限りません。 そこで、依頼文の形で示します。
【IRサイトのクローラーアクセス状況の確認について】
お世話になっております。IR部門の（氏名）です。
生成AI上での当社情報の扱われ方を確認する取り組みの一環として、
IRサイトへのクローラーアクセス状況をご共有いただけますでしょうか。
■ 対象
当社IRサイト（対象ドメイン: ____________________）
※コーポレートサイトと別ドメインの場合は、IRサイト側のみで結構です
■ 期間
直近3か月（可能であれば6か月）
■ ご共有いただきたい内容
1. ユーザーエージェント別のアクセス件数
（Googlebot / GoogleOther / GPTBot / OAI-SearchBot / ChatGPT-User /
ClaudeBot / PerplexityBot / Bingbot / Amazonbot / Meta-ExternalAgent）
※Googlebot と GoogleOther は必ず分けてご集計ください
※各社が公開する公式IPレンジ等で真正性を判定できる範囲で判定し、
未検証のユーザーエージェント名は分けてご集計ください
2. 上記それぞれについて、到達しているURLの範囲
（IRトップのみか、一覧ページまでか、個別の開示ページまでか）
3. HTTPステータス別の件数（2xx / 3xx / 401 / 403 / 404 / 429 / 5xx）
※401・403・429・5xx は取得の阻害を直接示すため、必ず含めてください
4. robots.txt の現在の内容
5. CDN・WAF等、robots.txt とは別の層でアクセス制御を行っている場合、
その設定内容
6. XMLサイトマップの有無と、そこに含まれるURLの範囲
■ あわせてご確認いただきたい点
・適時開示一覧、決算短信一覧、説明会資料一覧の各ページについて、
JavaScript を実行しない状態で一覧の項目と個別ページへのリンクが
取得できる状態かどうか
・株価情報・IRカレンダー・動画等を外部提供で埋め込んでいる場合、
その読み込み元ドメインと、同じ情報の自社ドメイン側での有無
なお、本件は特定の施策を前提としたものではなく、
現状把握を目的としたものです。
★依頼の目的を「現状把握」と明示してください。先に施策名を出すと、確認ではなく提案が返ってきます。
★§2 の実験がXMLサイトマップを無効化していたのは、JavaScript以外からURLを発見できない条件を作るためです。実運用のIRサイトにはサイトマップなどの別経路が存在しえます。「初期HTMLにリンクがない」ことと「クローラーがURLを発見できない」ことは、同じではありません。
§7 のとおり、AIのクローラーがPDF本文をどう扱うかについて本稿は断定しません。代わりに、自社で確かめる方法を示します。
★ここで得られるのは、自社の資料についての観測であり、「AIはPDFを読む／読まない」という一般命題の答えではありません。その区別を、社内報告でも保ってください。 同じ要領で、ページをまたぐ表や画像化された財務表についても確かめられます。
| 項目 | 内容 |
|---|---|
| 実行日時 | 年月日と時刻 |
| サービス名 | 使用したAIサービスの名称 |
| 質問文 | 一字一句そのまま |
| 会話の状態 | 新規会話か否か |
| 回答（要旨） | 数字・時点・状態が分かる形で |
| 引用URL | 示された場合、そのまま |
| 照合結果 | 数字／時点／状態それぞれについて 一致・不一致・記載なし |
| 技術側の状態 | 該当ページが初期HTMLに存在するか |
★技術側の状態を同じ表に持つことが要点です。回答の誤りが、内容の問題なのか取得の問題なのかを後から切り分けられるようになります。
決定版として、確認できなかったことを明示します。以下はいずれも、本稿で確認した範囲では確認できませんでした。 存在しないと断定するものではありません。
| 項目 | 状況 |
|---|---|
| AIのクローラーがPDF本文をどう扱うかを直接検証した公開実験 | 確認できなかった（§7） |
iframeの中身が取得されるか否かの直接検証／iframe・別ドメイン・Cookie同意画面がAI回答の正確さを何%低下させるかという定量値 | 確認できなかった（§6。要因を分離した実験を確認できていない） |
| 初期HTMLへの移行によってAI回答の正答率や引用のされ方が何%改善するかという定量値／404の割合の改善がAIの引用や正答率を改善するという因果 | いずれも確認できなかった（§4-6・§3-3） |
| 日本の企業サイト群でJavaScriptだけを要因分離した公開実験／IRサイトを母集団としたクローラー到達範囲の公開調査 | いずれも確認できなかった |
| 2024年12月の観測を行った当事者による2026年時点の後継調査／クライアントサイド描画をやめた企業のAI回答についての実測ビフォーアフター | いずれも確認できなかった |
★この空白は、自社で測るしかないことを意味します。§10 が本稿の中核である理由です。
Q1. AIはJavaScriptを読めないのですか。
一言では言えません。2024年12月17日公表の観測では、Gemini（Googlebot の基盤を利用）と AppleBot は実行すると報告され、OpenAI・Anthropic・Meta・ByteDance・Perplexity の各クローラーは実行していないと報告されました。観測日を伴う報告であり、現在形の断定ではありません。重要なのは、必要な情報と導線が初期HTMLにあるかです。
Q2. 「Googleはレンダリングするから問題ない」と言われました。そのとおりですか。
そのままは受け取れません。41日間の実験では、JavaScriptリンクの先へ到達した Google のアクセスの大半は GoogleOther によるもので、Googlebot の到達は2%でした。ただし同実験で Googlebot はHTMLリンク群でも5%にとどまり、著者はこれを新規ドメインのクロール予算の影響と読んでいます。
Q3. IRサイトが別ドメインにあります。何を確認すべきですか。
robots.txt はドメインごとに別に存在するため、コーポレートサイトでの確認結果はIRサイトに当てはまりません。IRサイト側のドメインについて、robots.txt、CDN・WAF層での遮断の有無、ユーザーエージェント別の到達範囲を別に確認してください（§10-5 の依頼文）。
Q4. 適時開示一覧がJavaScriptで読み込まれています。すぐ直すべきですか。
直す前に測ってください。JavaScriptを無効にして一覧ページを開き、項目と個別ページへのリンクが存在するかを確認します（§10-1）。存在しなければ改修の検討対象です。ただし本稿は実装手段を指定しません。書けるのは、主要な情報とそこへの導線を初期HTMLに置くことが現時点の複数観測と整合する、までです。
Q5. 株価情報を iframe で埋め込んでいます。AIには見えていないのですか。
「見えない」とは書けません。それを直接検証した調査を、本稿で確認した範囲では確認できませんでした。クローラーが iframe の読み込み先URLを発見し、別のリクエストとして取得する可能性もあります。言えるのは、取得経路が増えるため確認が要る、までです。
Q6. PDFはAIに読まれますか。
本稿は断定しません。Google は公式ドキュメントで、テキストで構成されたPDFは Google 検索のインデックスの対象になりうると説明しています。しかし、AIのクローラーがPDF本文をどう扱うかを直接検証した公開実験は、本稿で確認した範囲では確認できませんでした。自社の資料で確かめる手順は §10-6 にあります。
Q7. AIのクローラーは全部ブロックすべきでしょうか。
その問いの立て方が粗すぎます。OpenAI は公式ドキュメントで、学習用の GPTBot、検索用の OAI-SearchBot、利用者起点の ChatGPT-User を挙げ、設定は互いに独立していると説明しています。一括遮断は、検索表示のための取得まで止めえます。
Q8. robots.txt に書けば、ChatGPT からのアクセスは止まりますか。
止まらない場合があります。OpenAI の公式ドキュメントは、ChatGPT-User について、利用者が起点となる操作であるため robots.txt のルールが適用されない場合があると記載しています。また、更新の反映に約24時間かかることがあるとも明記されています。
Q9. XBRL を出しているので、構造化データは対応済みという理解でよいですか。
いいえ。XBRL は取引所の開示データ形式、schema.org はWebページに付けるマークアップで、目的も読み手も経路も異なります。TDnet への開示と、自社IRサイトのページがAIから取得できる状態にあることも別です。
Q10. 東証はAI上の認知の管理を求めているのですか。
求めていません。上場会社にはIR体制の整備が企業行動規範上の義務として課されていますが、AI上の自社認知を測定・管理することは義務ではありません。 どこまでを管理対象とみなすかは各社の判断です。
Q11. IRサイトをリニューアルしました。AIの回答はいつ更新されますか。
一律には言えません。41日間の実験の第2期では、書き換え後に GPTBot が2日以内に250ページを取得した一方、ClaudeBot は新しくリンクされたページを1ページも拾わず、Google は41日目時点でほぼ戻っていませんでした。1サイトの観測ですが、更新の速さがクローラーによって大きく異なりうる点は、社内説明の前提になります。
Q12. 改修すれば、AIの回答は何%改善しますか。
その数字は示せません。初期HTMLへの移行によってAI回答の正答率や引用のされ方が何%改善するかという定量値は、本稿で確認した範囲では確認できませんでした。社内で説明できるのは「取得できる状態にあることを確認した」までです。
IRサイトは構造が特殊です。別ドメインに置かれ、支援会社のシステムが組み込まれ、重要資料がPDF中心で、株価や適時開示一覧が外部から読み込まれることがあります。それ自体が誤りである部分はありません。 ただし、AIの側から取得できているかは、構造ごとに別に確認する必要があります。
本稿は、流通している2つの単純化を否定しました。実行するものもあれば、実行を報告されていないものもあり、Google の中でも検索インデックスを構築するクローラーの到達は、観測された条件下では薄いものでした。取得された・インデックスされた・回答に使われたは、別々の事象です。
書ける結論はひとつです。主要な情報とそこへの導線を、JavaScript実行を前提としなくても取得可能な初期HTMLに置くことは、現時点の複数観測と整合する。 それによってAI回答が何%改善するかは確認できませんでした。
したがって、最初にやるべきことは改修ではなく測定です。JavaScriptを切ってページを見る。同じ質問を複数回・独立に投げる。引用されたURLを棚卸しする。サーバーログをユーザーエージェント別に見る。この4つは、今日から始められます。
AI上の企業認知を継続的な管理対象として扱う考え方は AIPMとは で、IRにおける誤りの意味と全体像は 生成AIは自社の決算をどう語るか で、照合テストの手順は AI回答の照合テスト で扱っています。
［第1層］一次情報・公式ドキュメント
［第2層］非査読の実務観測・制御実験
★著者所有・運営の単一サイト、1業種、41日間、新規ドメインでの制御実験。著者は LOCOMOTIVE 所属。Search Engine Land は Semrush の所有。
★Vercel はサーバーサイドレンダリング等を提供するプラットフォーム事業者、MERJ は技術系SEO事業者。当事者による調査であり、同記事はサーバーサイドレンダリングと自社のクローラー遮断機能を推奨している。
★EdgeComet はレンダリングを提供する事業者。当事者による自社実験であり、単一の新規ドメインでの観測。著者自身が最終結論ではないと明記している。本稿執筆時に一次確認済み（2026年8月31日）。
出典確認日: 2026年8月31日（第1層・第2層のすべてのURLについて、本稿執筆時点で内容を確認）
生成AIはIR部門に急速に入ったが、測っている方向は自分が使うAIに向いている。日本IR協議会 第33回調査が示すこの非対称を起点に、AIが自社の決算数値を誤る4類型、実証研究が示すことと示さないこと、HTMLとPDFの違いの限界、露出量ではなく法定開示との一致を測る考え方、訂正時の法務上の境界までを整理する。
生成AIが自社の決算数値を誤っていないかを継続的に確かめるための実務手順。正解表に持たせるべき列と許容誤差の決め方、反復・ステートレスな計測の記録項目と揃えるべき測定条件、露出量ではなく法定開示との一致率を測る指標の定義、経営層への報告の形、そして未公表の重要情報で訂正しないという境界までを実務手順として示す。
AIPM（AI Perception Management／AI認知管理）とは、生成AIや回答エンジンが自社をどう認識・説明・引用するかを測定し、継続的に統制する実務領域。AIO・GEO・LLMOとの違い、海外で立ち上がったカテゴリと主要ベンダー、ガバナンス・規制、効果測定までを一次情報で解説する、Vaipm（ヴァイピム）の決定版ガイドです。