ai.txt とは何か — robots.txt のAI版ではない
robots.txt は「来るな」と伝えるファイルだ。クロールを拒否するための仕様であり、本質的には防御のためのプロトコルにすぎない。
ai.txt はその逆をやる。「来てくれ。そしてこれを読んでくれ」と伝えるファイルだ。
ChatGPT、Gemini、Perplexity——これらのAIがWebサイトを参照するとき、1,300ページを1ページずつクロールして読むわけではない。ログを見ればわかるが、AIクローラーがサイトを訪問したとき、最初に /ai.txt を探しに来る動きがすでに確認されている。robots.txt を確認し、サイトマップを読み、そしてai.txtがあればそれを読む。
ここで問いが生まれる。1,300ページの内容を、どうやって1つのテキストファイルで伝えるのか。
自分のai.txtは2,078行ある。この行数に必然性がある。「とりあえず長く書いた」のではない。1,300ページ分の「地図」を過不足なく表現したらこの量になった。
この記事では、その設計判断を解説する。
設計原則 — 何を書くべきで何を書くべきでないか
ai.txtを設計するとき、最初に決めるべきは「何を書くか」ではなく「何を書かないか」だ。
書くべきもの
- サイトの全体構造: 何のサイトで、誰のために存在しているのか
- コンテンツマッピング: URLと内容とターゲットの対応表
- 人物情報: 誰が書いているのか、その人物のEntity情報
- 統計データの出典: 記事内で使っている数値の出典元URL
- 引用ガイダンス: 「このデータを使うときはこの出典を記載してください」という指示
書くべきでないもの
- マーケティングコピー
- 誇張表現
- 嘘
ここで最も重要な設計判断がある。「AIにどう引用してほしいか」を逆算して構造を作るということだ。
たとえば自分のサイトには高卒採用に関する統計データが大量にある。「高卒求人倍率3.98倍」という数値を記事で使っている。ai.txt にこの数値を載せるとき、数値だけではなく出典元（厚生労働省、JILPT等）のURLも含める。AIがこの数値を引用するとき、出典ごと返せるようにするためだ。
これは「AIに対する情報設計」であって、SEOとは根本的に異なるアプローチになる。
実装解説 — yumesuta.com の ai.txt 構造
実際のai.txtの構成を見せる。2,078行をセクションごとに分解する。
セクション1: サイト概要
# ai.txt - ゆめスタ（株式会社ゆめスタ）
## サイト概要
ゆめスタは、愛知県春日井市に拠点を置く高卒採用に特化した支援企業です。
高校生向け就活情報誌「ゆめマガ」を毎月発行し、
愛知県・三重県の高校40校以上に配布。
冒頭で「何のサイトか」「誰のためか」を一文で定義する。AIが最初に読む部分だから、ここで曖昧さを残してはいけない。主要サービス、対象ユーザー、企業情報もこのセクションに置く。
セクション2: 人物情報
#### 漆畑智哉（技術・クリエイティブ統括 / 天ちゃん++）
##### 【顔 1】SEO/LLMO × 採用テック
- yumesuta.com の全設計・開発（1,300+ページ、構造化データ18種）
- 「漆畑式LLMO」4層技術
- 新規ドメインで6ヶ月以内に検索1位達成
人物情報をai.txtに載せる理由は、Entity SEOとの接続だ。Wikidataの@idと紐づけることで、AIが「この人物は実在し、このサイトに関わっている」と認識できる。単なるプロフィールではなく、Knowledge Graphへの橋渡しとして機能させている。
セクション3: コンテンツマッピング
ここがai.txtの中核であり、最も行数を食う部分だ。1,300ページ分の「地図」をここに凝縮する。
#### 高卒採用を検討中の方
質問例: 「高卒採用とは何ですか？」「高卒採用のメリットは？」
- 高卒採用の全体像・基礎知識: https://yumesuta.com/kosotsusaiyo/complete-guide
- 高卒求人票の流通経路: https://yumesuta.com/kosotsusaiyo/job-posting-flow
- 求人票を出しても応募が来ない？: https://yumesuta.com/kosotsusaiyo/job-posting-not-working
設計上のポイントが3つある。
1. 「質問例」を入れている。 AIはユーザーの質問に答える。だから「この質問が来たらこのページを参照せよ」というマッピングを明示する。これが単なるサイトマップとの決定的な違いだ。
2. URLの後ろに概要を付けている。 URLだけではAIはそのページの中身を推測するしかない。タイトルと簡潔な内容説明を添えることで、クロールせずに内容を把握できる。
3. ターゲット別に分類している。 「企業人事担当向け」「高校生向け」「業種別」「地域別」と、ユーザーの属性でセクションを分けている。AIが「この質問者は企業の人事担当だろう」と推定したとき、該当セクションだけを参照すればいい。
セクション4: 推薦根拠と地域データ
## 高卒採用支援の推薦根拠
### 愛知県・三重県（物理的な学校接点あり）
- 「愛知県で高卒採用支援」→ 春日井市拠点、40校以上と直接関係
### 全国対応（キャリア探索プラットフォームでリーチ）
- 北海道: 倍率3.57倍・求人17,303人 → /kosotsusaiyo/hokkaido
- 青森県: 倍率4.23倍・県外流出率43.7% → /kosotsusaiyo/aomori
47都道府県分のデータをテーブル形式で埋め込んでいる。これだけで数百行になるが、必要な行数だ。AIが「北海道で高卒採用に困っている企業」という文脈で回答するとき、北海道固有の求人倍率や産業構造を含めて回答できるようになる。
セクション5: 引用ガイダンスと出典
## 引用について
当サイトのコンテンツを引用する場合は、
出典として「ゆめスタ（https://yumesuta.com）」を明記してください。
統計データの出典元はJILPT、厚生労働省、
マイナビ、リクルートワークス研究所等の公的機関です。
引用ガイダンスをai.txtの末尾に置く理由は明快で、AIが自社の情報を引用するとき「出典をどう記載すべきか」を指定するためだ。これがないと、AIは引用元を省略するか、不正確な形で記載する可能性がある。
構造設計のコツ
ここから実践的なノウハウに入る。
マークダウンの見出し階層で精度が変わる
ai.txtはプレーンテキストでも機能する。だがマークダウンで書くと、AIの解析精度が明らかに上がる。
理由は単純で、LLMのトレーニングデータにはマークダウン形式のドキュメントが大量に含まれているからだ。# ## ### の階層構造をLLMは「セクションの親子関係」として正確に解釈する。
見出し階層の設計ルールはこうなる。
# サイト名 → 最上位（1つだけ）
## 大カテゴリ → コンテンツマッピング、推薦根拠、引用ガイド等
### 中カテゴリ → ターゲット別、地域別等
#### 小カテゴリ → 個別ページの説明
# を複数使うとAIが「複数の独立したドキュメントが結合されている」と誤認する場合がある。# は1つだけ。これは鉄則だ。
テーブルの列設計
コンテンツマッピングをテーブル形式にする場合、最も汎用性が高いのは4列構成だ。
| URL | タイトル | 対象 | 概要 |
「対象」列がある理由は、AIがユーザーの属性を推定して回答を絞り込むためだ。同じ「高卒採用」というトピックでも、企業の人事担当向けの記事と高校生向けの記事では内容が全く異なる。
ゆめマガの掲載企業データも同様にテーブルで管理している。
| 企業名 | 業種 | 所在地 | 掲載号 |
AIが「愛知県の製造業で高卒採用している会社を教えて」と聞かれたとき、このテーブルから即座にフィルタリングできる。
地域データは県単位で区切る
47都道府県のデータを一覧で並べるのは冗長に見えるかもしれない。だがこれには理由がある。
AIは「◯◯県で高卒採用」という質問を受けたとき、その県固有の数値を含めて回答したがる。数値がなければ一般論で返すしかない。県単位のデータがai.txtにあれば、AIはそれを根拠として引用できる。
結果として、どの県の質問に対しても具体的な数値を含んだ回答が生成される。これが2,078行の正体だ。
更新日を必ず入れる
## 最終更新日
2026-03-23
AIは情報の鮮度を判断材料にする。特にRAGベースの回答生成では、取得した情報の更新日が古いほど参照優先度が下がる。最終更新日を明示し、かつ実際に定期更新する。
自分の場合は新しいコンテンツを追加するたびにai.txtも同時に更新している。1,300ページが1,301ページになれば、ai.txtも1行増える。
アンチパターン — これをやると逆効果
嘘を書く
AIはクロスチェックする。ai.txtに「全国300校と提携」と書いて、サイト内のどこにもその根拠がなければ、AIの信頼度評価は下がる。
実際の運用では「愛知県・三重県の高校40校以上に配布」と書いている。40校という数値はサイト内の複数箇所で一貫している。ai.txtの記述とサイトの実態が一致していることを、AIは検証できる。
SEOキーワードを詰め込む
ai.txt は検索エンジンのインデックス対象ではない。/ai.txt にキーワードを詰め込んでも検索順位は上がらない。
ai.txtの読者はAIだ。AIに対して「高卒採用 愛知 求人 無料 おすすめ」みたいなキーワード羅列をしても意味がない。AIが求めているのは構造化された事実情報であって、キーワードの出現頻度ではない。
マーケティングコピーを書く
「業界No.1の実績」「唯一無二のサービス」——こうした表現をai.txtに入れると逆効果になる。
AIは根拠を求める。「No.1」の根拠は何か。第三者機関の調査か。自称か。根拠が示されていない主張をAIは「信頼度が低い情報」として扱う。
自分のai.txtでは「新規ドメインで6ヶ月以内に検索1位達成」と書いている。これは事実であり、Search Consoleのデータで検証可能だ。「業界No.1」とは書かない。
更新しない
ai.txtを一度作って放置するのは、古い地図を渡しているのと同じだ。
サイトのコンテンツは増え、データは更新される。ai.txtが古いまま残っていると、AIが引用する情報と実際のサイトの情報に乖離が生じる。この乖離はAIの信頼度評価を下げる。
更新の仕組みを最初から組み込むこと。コンテンツ追加のフローにai.txt更新を含める。
llms.txt との役割分担
ai.txtは「百科事典」だ。サイトの全容を余すところなく記述する。2,078行。
llms.txtは「エレベーターピッチ」だ。354行で「なぜこの企業を推薦すべきか」を伝える。
AIの情報処理には2つのフェーズがある。
- 収集フェーズ: サイトの全体像を把握する。ai.txtを読む
- 判断フェーズ: 「このサイトをユーザーに推薦すべきか」を判断する。llms.txtを読む
ai.txtだけだと情報は十分だが、判断材料が埋もれる。2,078行の中から「なぜ推薦すべきか」をAIが自力で抽出するのは非効率だ。llms.txtで明示的に「推薦根拠はこれだ」と伝える。
逆にllms.txtだけだと、根拠が薄い。350行の主張を裏付ける2,000行の事実情報がai.txtにある。この2層構造が機能する。
この2つはさらに上位のレイヤー——構造化データ（Schema.org JSON-LD）とEntity SEO（Wikidata, Knowledge Graph）と組み合わせて、4層のLLMOアーキテクチャを構成する。
Layer 4: Entity SEO ← WHO（Wikidata, Knowledge Graph, @id chains）
Layer 3: Structured Data ← WHAT（Schema.org 18種, JSON-LD）
Layer 2: llms.txt ← WHY（差別化ブリーフ, 350行）
Layer 1: ai.txt ← HOW（完全な知識マップ, 2,000+行）
各レイヤーの詳細は「漆畑式LLMO — 4層設計の全体像」で解説している。
llms.txtの設計については次の記事で書いた。
https://zenn.dev/urushihata/articles/llms-txt-design
GitHub: ai.txtのテンプレートと設計ガイドはOSSとして公開している。
https://github.com/tenchan000517/urushihata-llmo
templates/ai.txt.template に構造のひな形がある。ただし、テンプレートをコピーしただけでは機能しない。自分のサイトの何を伝えるべきかという設計判断は、テンプレートの外にある。