Shuichiro Ogawa
English

ノート · updated 2026-10-21 · Markdown 版

このサイトの AIO：AI 検索に出典として引かれるために何を入れ、何を入れなかったか

学術のノートを公開する個人サイトが、AI 検索と生成 AI の回答に正しい出典として引かれるために、根拠のある手段は何かを、提供者の公式文書と標準の草案、査読研究で確かめ、このサイト（jamjet-iqbal.com）に実装した記録である。書き方の手法には根拠がない。

目次（7）
  1. このサイトが望むこと
  2. 根拠のある手段と無い手段の線引き
  3. 取得の許可と利用の選好を分けて伝える
  4. 同じ内容を機械が読みやすい形で配る
  5. 書誌を構造化して付ける
  6. 入れなかったもの
  7. どう確かめるか

このサイトが望むこと

このサイトのノートは、末尾に参照文献を並べ、できるかぎり DOI か URL を添える決まりで書かれている。 読者の多くは検索から来るが、2025 年から、検索の結果の上に AI の要約が出て、AI のチャットが Web を読んで答えるようになった。 AI の回答に出典として引かれるための仕事には AIO、GEO、AEO、LLMO という呼び名があり、産業界では計測と制御の争いになっている（AIO（AI 検索への最適化）の産業界の潮流：何が測られ、何が売られ、何が争われているか）。 その整理を踏まえて、このサイト自身に何を入れるかを決めたのが本ノートである。

望むことは二つに絞った。 一つは、AI の回答がこのサイトのノートの内容を使うとき、著者、日付、ノートの URL、ノートが引いた文献が揃った形で引かれることである。 もう一つは、人が読む HTML と AI が読む形で、本文と参照文献の内容が一致していることである。 クリックを取り戻すことは望みに入れなかった。 AI の要約が出ると外部へのクリックは減り、AI の回答から出典へ移る人は少ない（Pew Research Center の実測で 8% 対 15%、Reuters Institute の調査で常によく押す人は 4%。AIO（AI 検索への最適化）の産業界の潮流：何が測られ、何が売られ、何が争われているか）。 学術のノートにとって、読まれる数より、正しく帰属されることのほうが先にある。

根拠のある手段と無い手段の線引き

AIO の助言の多くは書き方の手法である。 統計を足す、引用文を足す、文章を短い塊に切る、問いと答えの形にする、といった助言が、引用されやすさを上げるとされる。 その出発点になった論文は、Google の上位 5 件の文書から GPT-3.5 が回答を作る実験系で、最良の手法が基準より最大 40% 見えやすさを上げたと報告した（Aggarwal ほか 2024）。 後続の検証はこれを支持しなかった。 C-SEO Bench は、同種の手法を商品の推薦と質問応答の複数の分野で新しい LLM を使って調べ、54 の条件のうち順位の改善が有意だったのは 3 つで、効いたのは検索で上位に来て文脈の先頭に置かれるという従来の要因だった（Puerto ほか 2025）。

提供者の公式見解も同じ方向を向く。 Google は 2026 年 5 月に生成 AI の機能向けの指南を新設し、AEO と GEO は Google 検索から見れば SEO と同じだとしたうえで、llms.txt のような機械向けのファイルは Google 検索が使わないので見えやすさに益も害もなく、文章を細切れにする必要もなく、Web 上で不自然な言及を集めても見かけほど役に立たない、と書いた（Google Search Central 2026a）。 AI 要約と AI Mode に出るために新しい機械向けのファイルやマークアップは要らず、特別な schema.org の構造化データも要らない、とも書いている（Google Search Central 2026c）。 Microsoft の Bing の担当者は、見出し、リスト、表、問答の形、構造化データを勧めるが、効果を示す数値は添えていない（Madhavan 2025）。

この線引きから、本ノートは書き方の手法を採らず、次の三つだけを入れた。 取得の許可と利用の選好を分けて伝えること、同じ内容を機械が読みやすい形で配ること、書誌を構造化して付けることである。 三つとも、提供者の公式文書か標準の草案に、その仕組みが実際に読まれるという記述がある。 効果の大きさを示す測定は、Markdown のトークン数を除いて、どれにも無い。

取得の許可と利用の選好を分けて伝える

AI の提供者は、検索のための取得と学習のための取得を別々のクローラーに分け、サイトの側が robots.txt で別々に制御できるようにしている。 OpenAI は、OAI-SearchBot を許して GPTBot を拒めば、ChatGPT の検索には出るが学習には使われない、と書く（OpenAI 2026）。 Anthropic は、学習用の ClaudeBot、検索の質を上げる Claude-SearchBot、利用者の問いに応じて頁を読む Claude-User を分け、Claude-SearchBot や Claude-User を拒むと利用者向けの検索での見えやすさが下がりうる、と書く（Anthropic 2026）。 Perplexity も、検索結果に載せるための PerplexityBot と、利用者の問いに応じて頁を読む Perplexity-User を分け、どちらも学習には使わないと書く（Perplexity 2026）。

Google は、Google-Extended という制御用の名前で、Gemini の学習と検索結果に基づく根拠づけ（grounding）への利用を止められるようにしており、これは検索への掲載や順位には影響しないとする（Google Search Central 2026d）。 一方で Google の AI 要約と AI Mode は検索の一部なので、Googlebot を許すかどうかがそのまま制御になる（Google Search Central 2026c）。

robots.txt は、もともと全体を許可する 2 行だけだった。 許可の状態は変えず、検索用と利用者の求めに応じた取得（OAI-SearchBot、ChatGPT-User、Claude-SearchBot、Claude-User、PerplexityBot、Perplexity-User）を名指しで許可し、チャットの API の経路だけを除いた。 名指しの許可は、既定の許可と結果は同じだが、将来に既定を絞るときにも検索用の取得を保つ意図を、ファイルの上で読めるようにするためである。

取得の許可とは別に、取得した後の利用についての選好を伝える仕組みが 2025 年から動いている。 Cloudflare は 2025 年 9 月に Content Signals Policy を公開し、robots.txt に Content-Signal: search=yes, ai-train=no のような行を書く形を示した。 search は検索の索引とリンクと短い抜粋の表示を指し、AI による検索の要約を含まない。 ai-input は検索拡張生成（retrieval-augmented generation）や AI 検索の回答への入力を指し、ai-train は学習と微調整を指す。 書かれていない信号は許可でも拒否でもなく、選好を表明していないことを意味する（Allen 2025）。 IETF の aipref 作業部会も、学習（train-ai）、AI の利用（ai-use）、検索（search）を分ける語彙と、それを HTTP の見出しと robots.txt に付ける方法を草案にしている（Keller と Thomson 2026、Illyes と Thomson 2026）。

このサイトは search=yes, ai-input=yes を書いた。 検索の索引に入ることと、AI の回答の入力に使われることは、このサイトが望むことそのものだからである。 ai-train は書かなかった。 学習に使われることは、引用にも帰属にもつながらず、望みの外にあるが、拒む理由も確かめていない。 選好を表明しないという選択を、Content Signals の仕様が許しているので、そのとおりにした。

どちらの仕組みも、守るかどうかは取得する側に委ねられている。 robots.txt の標準は、その規則がアクセスの認可ではないと定めており（Koster ほか 2022）、Cloudflare 自身も、信号は選好の表明であって技術的な対策ではなく、無視する会社もありうると書いている（Allen 2025）。 表明は、守る提供者にだけ効く。

同じ内容を機械が読みやすい形で配る

llms.txt は、業界では AIO の手法として語られるが、提案の目的はエージェントがサイトを使う助けになる情報を一つのファイルにまとめることにある。 提案は、サイトの名前を H1 に、短い要約を引用の形に、ページへのリンクの一覧を H2 の節に置く形を定め、あわせて各ページの Markdown 版を、URL に .md を付けた場所で配ることを勧める。 HTML からは rel="alternate" と type="text/markdown" の link で Markdown 版を指せる（Howard 2026）。 OpenAI と Perplexity の開発者向け文書は、この形で llms.txt と各ページの Markdown 版を置いている（OpenAI 2026、Perplexity 2026）。

Markdown 版を置く理由は、トークンの量にある。 Cloudflare は 2026 年 2 月に、Accept: text/markdown の要求に対して HTML を Markdown に変換して返す機能を公開し、あるブログ記事が HTML では 16,180 トークン、Markdown では 3,150 トークンになったと示した（Martinho と Allen 2026）。 AI が頁を読むとき、ナビゲーション、スクリプト、装飾の要素は意味を持たずにトークンを消費する。 同じ本文を Markdown で配れば、AI が読む量は減り、本文の構造（見出し、箇条書き、参照文献の節）はそのまま伝わる。

公開ノートごとに Markdown 版を /notes/<slug>.md（英語版は /en/notes/<slug>.md）に置いた。 Markdown 版の先頭には、題、著者、初出と更新の日、正規の HTML の URL、相手言語の版の URL、言語、キーワード、要約を並べ、そのあとに本文を置く。 本文は、人が読む HTML と同じ規則で作る。 下書きのノートは出さず、未公開の研究を隠すブロックは除き、ノート間のリンクは絶対 URL に直す。 HTML の head には Markdown 版への alternate の link を置き、本文の冒頭にも Markdown 版へのリンクを出した。 llms.txt は、サイトの説明と、全ノートの Markdown 版への一覧（英語版、日本語版の順）と、アーキテクチャ、参照論文、引用ネットワークのページを載せる Optional の節で構成した。 sitemap.xml は、公開ページと全ノートの HTML と Markdown 版を更新日つきで列挙し、robots.txt から参照した。

Google 検索は llms.txt も Markdown も使わないと明言している（Google Search Central 2026a）。 読みに来る取得者も、今のところ少ない。 Ahrefs が 2026 年 5 月に自社の解析ツールを入れた 137,210 のドメインのログを集計すると、約 28% が llms.txt を置いていたが、そのうち 97% のファイルにはその月に一度も要求が無かった（Ahrefs 2026）。 この集計は要求の有無を数えたもので、取得した内容が使われたかどうかは示さない。 この二つが効くのは、llms.txt を読むエージェントと、Markdown 版を取りに来る取得者に対してだけであり、それがどれだけいるかは、このサイトのログで見るしかない。 Google に対しては、HTML の本文がそのまま読まれる。

書誌を構造化して付ける

三つめは、ノートの書誌を機械が読める形で頁に付けることである。 schema.org の ScholarlyArticle は、題、要旨、著者、言語、初出と更新の日、所属するサイト、参照した文献（citation）を持てる型で、Article の下位型にあたる（schema.org n.d.）。 Google は、Article の構造化データが頁の理解に役立つとし、著者の名前と URL、初出と更新の日、見出しを推奨の属性に挙げる（Google Search Central 2026e）。 同時に Google は、AI 要約と AI Mode に出るために特別な構造化データは要らないとも書いている（Google Search Central 2026c）。 構造化データに期待できるのは、AI の機能への掲載ではなく、頁が誰の、いつの、何を引いた文章かを、取得する側が誤らずに読めることである。

公開ノートごとに ScholarlyArticle の JSON-LD を head に置いた。 題、要約、言語、キーワード、初出の日（wiki の更新記録の初出）、更新の日、著者、所属するサイト、Markdown 版の在りか、相手言語の版、そして参照文献の節の各項目を citation に入れた。 トップページには、サイト（WebSite）と著者（Person）の JSON-LD を置き、著者の他のページ（LinkedIn、researchmap）を sameAs で結んだ。 参照文献を citation に入れたのは、AI の回答がこのサイトのノートを引くときに、ノートが何に基づいているかが、本文を読まなくても機械に分かるようにするためである。

入れなかったもの

書き方の手法は入れなかった。 文章を短い塊に切ること、問いと答えの形に書き換えること、Web 上で言及を集めることは、根拠が実験室の条件の結果に限られ、Google が不要と明言している（Google Search Central 2026a、Puerto ほか 2025）。 ノートの文章は、読者のために決めた規範で書き、AI のために変えない。

取得の拒否と対価の仕組みも入れなかった。 産業界では、学習用の取得を拒み、取得に対価を求める動きが出版社を中心に進んでいる（AIO（AI 検索への最適化）の産業界の潮流：何が測られ、何が売られ、何が争われているか）。 このサイトは引かれることを望む側なので、検索用の取得を拒む理由がない。 学習については、上に書いたとおり選好を表明していない。

Accept: text/markdown による内容交渉も入れなかった。 Cloudflare の機能は有料の契約で有効になり、静的な配信にはない。 URL に .md を付ける形で同じ目的を果たせるので、提案の形に従った。

どう確かめるか

入れたものが動いていることは、ビルドの出力で確かめた。 robots.txt、sitemap.xml、llms.txt、全ノートの Markdown 版、各頁の JSON-LD が生成され、Markdown 版にノート間のリンクの記法が残っていないことを機械で見た。

入れたものが効いているかは、まだ測っていない。 Google の Search Console には生成 AI の機能での表示を数える報告があり、Bing Webmaster Tools には AI の回答での引用を数える機能がある（AIO（AI 検索への最適化）の産業界の潮流：何が測られ、何が売られ、何が争われているか）。 アクセスログの user agent を集計すれば、どの取得者が Markdown 版と llms.txt を読みに来たかが分かる。 これらを始めてから、本ノートに結果を足す。

効果が出るとしても、引用されるかどうかは提供者の側の選択と揺れに左右される。 何が引用されるかは従来の検索の上位と重なりが小さく、週単位で動き、同じ問いへの推薦が一致する確率は 100 分の 1 未満だった（AIO（AI 検索への最適化）の産業界の潮流：何が測られ、何が売られ、何が争われているか）。 このサイトにできるのは、引かれたときに正しく帰属される形を整えておくことまでである。

関連ノート

未検証事項

0 件。参照した文書はすべて本文を取得して照合した。

参照文献

書いた人：小川 修一郎（デザイン研究者／デザインコンサルタント） 経歴を見る →