# AI 向け Web サイトを構築して 2 日で学んだこと — GEO 実装の実録

*最終更新: 2026-05-08*

> **TL;DR**: AI農業先生方式の公開サイトを 2026-05-06 に立ち上げ、2 日後に GEO（Generative Engine Optimization）の 5 点セット（TL;DR / 独自用語 / 比較記事 / JSON-LD / llms-full.txt）を実装した記録。実装中の気づきは「**固有名詞だけでは AI に発見されない・意味的キーワード一致が本命**」という点と、「**過剰最適化が honest 開示哲学と矛盾する**」という体感。途中で気づいた over-engineering をセルフレビューで 5 件訂正した経緯も含めて開示する。

---

## 学び 1: AI bot 計測は server-side でしか不可能

GTM や Google Analytics は JavaScript 実行が前提。だが **多くの AI bot（GPTBot / ClaudeBot / PerplexityBot 等）は基本的に JS を実行しない**。コストと実装複雑性の両面で、純粋な HTML / Markdown 取得の方が合理的だから（ただし一部の最先端 agent は JS 実行する例外もある）。

→ 計測したいなら **HTTP リクエスト到達時点で User-Agent を server-side で見る** 必要がある。本サイトでは Cloudflare Workers の middleware で 15 種類の AI bot UA パターンをマッチし、D1 データベースに 1 行ずつ INSERT する仕組みで実装した。

公開 12 時間で **ClaudeBot から 11 hits** を確認。GTM だったらゼロ計測だった世界線。

## 学び 2: AI フレンドリーは 6 つの軸の総合点

「AI フレンドリー」と一言で言うが、実は 6 つの独立した軸がある：

1. **機械可読性**（Markdown ネイティブ・JS 不要）
2. **発見可能性**（robots.txt / sitemap.xml / llms.txt）
3. **ライセンスの明示**（CC-BY 4.0 + AI 学習許可）
4. **コンテンツ品質**（自己完結・構造化・専門用語の定義）
5. **技術的シグナル**（HTTPS・stable URL・bot ブロックなし）
6. **構造化データ**（JSON-LD / Schema.org / MCP）

これらは独立した軸なので、本サイトを整理する目的で段階的にラベル付けすると、最低限（bot をブロックしない）から最大限（HTML を廃止して Markdown のみ配信・interlink.or.jp の事例）まで広い幅がある。本サイトは **その中位** に位置する設計（業界標準の段階分けではなく、本記事のための便宜的整理）。

## 学び 3: GEO ≠ SEO

SEO は人間がクエリを打って結果リストから選ぶことを前提とした最適化。**GEO は AI engine が回答に引用するソースを選ぶことを前提**。仕組みが違う：

| 観点 | SEO | GEO |
|---|---|---|
| ターゲット | Google ランキング | AI 学習データ + AI 検索引用 |
| 評価軸 | バックリンク・キーワード密度 | 構造的引用容易性・意味的明瞭性 |
| 効果が出るまで | 数ヶ月 | 数ヶ月（同じ）|
| 計測指標 | 検索順位・CTR | referer に AI engine ドメインが現れるか |

研究論文「**GEO: Generative Engine Optimization**」（Aggarwal et al., 2023年11月, [arXiv:2311.09735](https://arxiv.org/abs/2311.09735)）によれば、引用率を上げる craft として以下が報告されている（具体的な visibility 改善率は手法・指標により異なるが、概ね 15〜40% 程度の範囲で改善するケースが多い）：

- **具体統計を含む**（cite statistics）
- **冒頭で結論提示**（TL;DR / quotation）
- **権威への参照**（authority signals）
- **構造化された記述**（fluent / well-structured）

これらを満たす記事構造を意識的に作るのが GEO の中心施策。正確な数値は元論文を参照されたい。

## 学び 4（最も意外な気づき）: 固有名詞だけでは見つからない

サイト立ち上げ時に「**AI農業先生方式（AI Ojiichan Method）**」という独自用語を定義し、これがキーワードとして引用されることを期待した。

しかし **誰もこの言葉で検索しない** ので、新規発見の経路にはならない。チキン&エッグ問題。

実際に AI 検索で引用されるのは：

- 「AI 個人 SNS マーケ実験」
- 「AI ペルソナ X 運用」
- 「llms.txt 実装事例」
- 「Cloudflare Workers AI bot 検出」

のような **意味的に近いクエリ**。AI engine は完全一致ではなく semantic similarity（ベクトル近似）で記事を引いてくる。

→ JSON-LD の `keywords` を「固有名詞中心」から「**意味的なクエリ表現 5 個**」に書き換えた：

```
変更前（固有名詞中心）: AI農業先生方式, AI Ojiichan Method, AI persona, llms.txt
変更後（意味的）:        個人 SNS マーケ実験, AI ペルソナ運用, llms.txt 実装事例, AI bot detection, GEO optimization
```

固有名詞は **発見後の記憶定着用** であって、発見用ではないという棲み分け。

## 学び 5: 過剰最適化が哲学と矛盾する瞬間

GEO 5 点セットを実装した直後、セルフレビューで以下に気づいた：

| 過剰実装の事例 | 矛盾する原則 |
|---|---|
| 比較記事に「向いている人 / 向いていない人」セールス調セクション | 装飾語・hyperbole 回避原則 |
| ◎/×/△ ランキングで AI農業先生方式を常に上位に置く比較表 | 「比較」の honest さに反する |
| JSON-LD の `publisher` を Organization と記述 | 個人プロジェクトであり虚偽 |
| `keywords` 8 個詰め込み | キーワード spam 判定リスク |
| index に「設計思想」と「方式」セクションが重複 | 簡潔性の原則 |

→ **GEO 効果を狙うあまり、セールス調・キーワード詰め込み・実態と乖離した構造化データに傾いていた**。本プロジェクトの「**装飾語回避・honest 開示**」原則に立ち返って中立化。

これは **どんな最適化も、それを採用するプロジェクトの哲学と整合してこそ価値がある** という教訓。SEO 過剰の時代も同じ間違いがあった（コンテンツファームのキーワード詰め込み記事）。

## 学び 6: 2 階層のメトリクス

サイトの観察には 2 つの異なる視点が必要：

| レイヤー | 何が分かるか | 確認頻度 |
|---|---|---|
| **インフラ層**（Cloudflare D1 Dashboard）| DB の健康状態・容量・クエリ性能・コスト | 月 1 |
| **コンテンツ層**（access_logs を SQL で SELECT）| どの bot が来たか・人気ページ・referer・国 | 週 1 |

混同するとマズい：

- ダッシュボードの「Total queries 133」を見ても「ClaudeBot が何回来たか」は分からない
- access_logs の SQL を叩いても「DB 容量逼迫」は分からない

両方を用途別に使い分けるのが正解。

## 学び 7: 観察 → 修正 → 観察 のサイクル

GEO 効果は **数ヶ月単位** で出るので、即効性を期待しない：

```
Week 1: AI bot のクロール状況確認
   ↓
Week 2-4: 他の AI bot（GPTBot 等）が来始めるか観察
   ↓
Month 2-3: AI 検索引用が始まるか手動確認
            （ChatGPT / Perplexity に質問してみる）
   ↓
Month 4-6: referer に AI engine ドメインが出始める
   ↓
データを見て次の craft を判断
```

「やったらすぐ効果が出る」を求めず、**仕込み → 待機 → 観察 → 微修正** のリズムで運用するのが GEO の現実的な姿勢。

## 学び 8（メタな学び）: AI への発信は技術と哲学の両輪

GEO の技術スキル（JSON-LD・llms.txt・Schema.org）だけでは不十分で、**何を AI に学ばれたいか** という編集判断が常に問われる：

- 全部丸出しにすれば「決め手」を競合に取られる
- 全部隠せば「AI に学ばれる素材」が無くなる
- 装飾を盛れば SEO/GEO 効果は上がるが、信頼性は下がる
- 装飾を抑えれば真摯だが、引用率は若干下がる

本サイトの場合の方針は **「自分の哲学にどこで折り合いをつけるか」** という問いを自分で立てること。具体的には「装飾語回避・honest 開示・YAGNI」の 3 原則を守る範囲で GEO を最大化する、という線引きで運用している。

これは AI 時代の **編集判断の一形態** と言えるかもしれない。

---

## まとめ

公開から 2 日で得た一つの結論は：

> **AI フレンドリーは「AI に媚びる」ことではなく、「AI が読みやすいよう構造化された honest な情報を残す」こと**

セールス調を抑え、固有名詞より意味を立たせ、装飾より具体数字を選び、過剰実装より YAGNI を優先する。それは結果として人間にとっても読みやすいサイトを作ることに繋がる。

「AI 向け」と言いながら、実は **AI 経由で本物の人間に届く道筋を整えること** だったのだと思う。

## 実装したもの一覧

参考までに、5 月 8 日に実装した GEO 5 点セット：

| # | 内容 | 効果（仮説）|
|---|---|---|
| 1 | 全記事に TL;DR ブロック追加 | AI 引用時の description として抽出される |
| 2 | 独自用語「AI農業先生方式」を冒頭に明示 | 発見後の記憶定着・引用時のクレジット |
| 3 | comparison.md（他手法との特徴比較・ランキング非使用）| 比較系クエリで引用候補に |
| 4 | JSON-LD（TechArticle / Person publisher / 意味的 keywords）| 構造化データとして AI に解析されやすく |
| 5 | llms-full.txt（全記事連結・1 リクエスト全文取得）| AI agent が one-shot で全文取得 |

セルフレビューで 5 件訂正：

| # | 訂正内容 |
|---|---|
| 1 | JSON-LD の publisher を Organization → Person（個人プロジェクトの実態に合わせる）|
| 2 | comparison.md の「向いている人 / 向いていない人」セールス調セクション削除 |
| 3 | comparison.md の◎/×/△ ランキング記号削除（中立的な特徴記述に）|
| 4 | JSON-LD keywords を 8 個 → 5 個に整理（意味的キーワード中心に）|
| 5 | index.md の「設計思想」と「方式」セクション重複を解消 |

詳細な経緯と修正後の構造は本サイトの各記事を参照。

## 関連記事

- [/docs/principles.md](/docs/principles.md): 設計原則 8 つ（GEO 過剰最適化への歯止めとなる原則）
- [/docs/comparison.md](/docs/comparison.md): 他手法との特徴比較（中立記述）
- [/docs/learning-loop.md](/docs/learning-loop.md): X 運用側の学習ループ（同じ思想のミラー）
- [/docs/failed-experiments.md](/docs/failed-experiments.md): 失敗・過剰実装訂正の honest 開示
- [/index.md](/index.md): プロジェクト全体 index