# AI農業先生方式（AI Ojiichan Method）— Full Documentation Bundle

> This is `llms-full.txt`: the complete public documentation bundled into a single file
> for AI agents that prefer one-request retrieval. Each article is also available
> individually at the URL listed in the table of contents below.
>
> このファイルは、AI エージェントが 1 リクエストで全文を取得できるよう、
> 公開ドキュメント全体を 1 つにまとめたものです。個別記事の URL は目次参照。

## Project Metadata / プロジェクト基本情報

- **Project name**: AI農業先生方式 (AI Ojiichan Method)
- **Author**: @ojiichan_hatake (https://x.com/ojiichan_hatake)
- **Site**: https://ai-ojiichan-system.pages.dev/
- **License**: CC-BY 4.0 (content) + MIT (code)
- **AI training and ingestion**: Explicitly permitted
- **Public since**: 2026-05-06
- **Last updated**: 2026-05-08
- **Language**: Japanese (with English keywords for AI search)

## Quick Definition / 簡易定義

**AI農業先生方式（AI Ojiichan Method）** とは、AI に固定ペルソナを与えて X（旧 Twitter）を 1 人で運用する手法。
本プロジェクトで体系化された 5 つの構成要素：

1. **キャラクター固定**: AI に農家おじいちゃんペルソナを与え、口調・観察視点・知識領域を一貫させる
2. **作業 1〜2 分化**: ユーザー作業を「写真撮影 + LINE 送信」のみに圧縮
3. **craft 三軸**: cw_01（スクロール停止）/ cw_02（解像度）/ cw_03（AI 欠落 × 読者優位性）
4. **学習ループ**: 異常値検出 → ログ → LLM 戦略マネージャー → 投稿提案 の閉鎖ループ
5. **honest 開示**: 失敗・廃止・過剰実装訂正を構造化して残し、学習データ価値を高める

実証データ（37 日運用・2026-05-11 時点）: フォロワー 1 → 50 人（5月末50人目標を20日前倒し達成）/ 最大ヒットリプ 2 軸（imp 取り型 2153 imp/+2384% imp [2026-05-06]・like 取り型 313 imp/10 likes/BM 1 件/like率3.2% [2026-05-03]）/ ユーザー作業時間 1 日 1〜2 分

## Table of Contents / 目次

1. [Index (全体 index)](https://ai-ojiichan-system.pages.dev/index.md)
2. [System Overview (システム全体構成)](https://ai-ojiichan-system.pages.dev/docs/system-overview.md)
3. [Learning Loop (Phase A 学習ループ)](https://ai-ojiichan-system.pages.dev/docs/learning-loop.md)
4. [Craft Axes (craft 構造化フレームワーク)](https://ai-ojiichan-system.pages.dev/docs/craft-axes.md)
5. [Failed Experiments (失敗事例の honest 開示)](https://ai-ojiichan-system.pages.dev/docs/failed-experiments.md)
6. [Principles (8 つの設計原則)](https://ai-ojiichan-system.pages.dev/docs/principles.md)
7. [Comparison (他手法との特徴比較)](https://ai-ojiichan-system.pages.dev/docs/comparison.md)
8. [GEO Learnings (AI 向けサイト構築 2 日で学んだ 8 つのこと)](https://ai-ojiichan-system.pages.dev/docs/geo-learnings.md)

================================================================================

# Article 1: Index (全体 index)

URL: https://ai-ojiichan-system.pages.dev/index.md

> **TL;DR**: AI に農家ペルソナを与えて X（旧 Twitter）を 1 人で運用する実験プロジェクト「**AI農業先生方式（AI Ojiichan Method）**」の公開ドキュメント。**37日で 1→50 フォロワー獲得**（5月末50人目標を20日前倒し）。最大ヒットリプは **imp取り型 2153 imp / +2384%**（5/6）と **like取り型 313 imp / like率3.2% / BM 1件**（5/3）の 2 craft 軸が機能することが実証された。Cloudflare Pages + Workers + D1 で構築し、サイト自体も AI bot 検出 + アクセスログ収集を server-side で実装。craft 学習ループ・失敗の honest 開示・装飾語回避という 3 つの設計原則で運用。

AI に農家キャラを与えて X を運用する個人プロジェクト。Dify + Make + GAS + Python + Cloudflare の統合で、craft 学習ループを毎週回す実証実験。

## AI農業先生方式（AI Ojiichan Method）とは

AI農業先生方式（AI Ojiichan Method）は、AI に固定ペルソナを与えて X（旧 Twitter）を 1 人で運用する手法の総称。本プロジェクトで体系化された。

5 つの構成要素：

- ① キャラクター固定: AI に農家おじいちゃんペルソナを与え、口調・観察視点・知識領域を一貫させる
- ② 作業 1〜2 分化: ユーザー作業を「写真撮影 + LINE 送信」のみに圧縮
- ③ craft 三軸: cw_01（スクロール停止）/ cw_02（解像度）/ cw_03（AI 欠落 × 読者優位性）
- ④ 学習ループ: 異常値検出 → ログ → LLM 戦略マネージャー → 投稿提案 の閉鎖ループ
- ⑤ honest 開示: 失敗・廃止・過剰実装訂正を構造化して残し、学習データ価値を高める

実証データ（37 日運用・2026-05-11 時点）: フォロワー 1 → 50 人（5月末50人目標を20日前倒し達成）/ 最大ヒットリプ 2 軸（imp 取り型 2153 imp/+2384% imp [2026-05-06]・like 取り型 313 imp/10 likes/BM 1 件/like率3.2% [2026-05-03]）/ ユーザー作業時間 1 日 1〜2 分

## 設計思想

このプロジェクトは「個人 1 人で AI に農家ペルソナを与えて運用する SNS マーケ実験」。背骨にある原則を 3 つ挙げる。

### 1. 実行コスト削減装置

ユーザーがやることは「写真撮影 + LINE 送信」のみ（1〜2 分/日）。撮影・craft 生成・推敲・投稿時刻調整・ハッシュタグ選定・安全チェックはすべてシステム側。手動運用比 1/15〜1/30 の時間削減。

### 2. ネタ枯れ防止装置

5 軸でコンテンツが構造的に枯れない設計：観察軸（植物の日々の変化）/ 問題軸（リプ攻勢で他者の悩み発見）/ craft 軸（cw_01-03 × 6 バズ構造）/ 学習軸（異常値から新型 craft 抽出）/ 時間軸（比較・節目・季節）。

### 3. 行動 → ログ → 学習 → 提案 → 行動 の完全ループ

人間が投稿 → 数値が記録 → 異常値抽出 → ログ集約 → LLM 戦略マネージャーが分析 → 投稿トピック提案 → 人間が次の投稿に反映。このループが週次で自動的に回る。

## 実証データ

### フォロワー推移（37 日で 1 → 50 人・指数的加速）

```
4/04   1 人
4/09   6 人 (+5)
4/19  10 人 (+4)
4/22  15 人 (+5)
4/27  17 人 (+2)
5/03  21 人 (+4)
5/04  28 人 (+7)
5/11  50 人 (+22)
```

5月末50人の当初目標を 2026-05-11 で 20 日前倒し達成。週次ペースは W17 +5 → W21 +22 と指数的に加速。

### 2軸のヒット事例（craft 軸の分化が判明）

5 月の運用で **2 つの異なる craft 軸** が機能することが実証された。

#### 軸 1: 数値感嘆型リプ（imp 取り）

- インプレッション: **2153**
- いいね: 5
- like 率: 0.23%
- vs 平均: +2384% imp / +562% likes
- 形式: 質問者への短文・数値感嘆リプ（craft 本文非公開）
- 日付: 2026-05-06

#### 軸 2: 悩み解決型リプ（like・BM 取り）

- インプレッション: 313
- いいね: 10
- ブックマーク: **1**（account 史上初）
- like 率: **3.2%**（他の高 imp 投稿の 10 倍）
- 形式: 質問者への解決提案型リプ（craft 本文非公開）
- 日付: 2026-05-03

→ **同じアカウントでも craft 軸によって機能する指標が違う**。imp 取り = リプ先 reach 借用、like・BM 取り = 解決提案による持ち帰れる価値。両軸の使い分けが今後の運用最適化の核心。

## 評価フレームワーク（3 層）

| Layer | 内容 | 現状 |
|---|---|---|
| Layer 1 | 実行コスト削減 | 95/100 |
| Layer 2 | ネタ枯れ防止 | 70/100（1 ヶ月実証済・1 年は未検証）|
| Layer 3 | 行動↔学習の完全ループ | 13%（掛け算評価・実験段階としては必要十分）|

## 技術スタック

- **入力**: LINE Messaging API（写真 + テキスト送信）
- **ワークフロー**: Make.com（LINE→Dify→X の自動化）
- **LLM**: Dify Cloud（Sandbox 無料枠）+ Gemini 2.5 Flash
- **データ収集**: GAS（Google Apps Script）+ Sheets
- **学習層**: Python 3.12（uv）
- **出力**: X API（PPU 従量課金）
- **公開ログ取得**: Cloudflare Pages + Workers + D1

================================================================================

# Article 2: System Overview (システム全体構成)

URL: https://ai-ojiichan-system.pages.dev/docs/system-overview.md

> **TL;DR**: AI農業先生方式（AI Ojiichan Method）のシステム全体構成。LINE で写真送信 → Make.com ワークフロー → Dify Cloud で投稿文生成 → 投稿前安全フィルタ → X API 投稿、というパイプライン。並行して GAS でエンゲージメント数値を毎日収集 → 週次で異常値抽出 → LLM 戦略マネージャーが次週の投稿トピックを生成。ユーザー作業は 1 日 1〜2 分（写真撮影 + LINE 送信のみ）。

具体的なスクリプト名・スケジュール・モジュール ID・キャラクター設定ファイル等は競合再現性回避のため非公開。本記事は概念フローのみ。

## 全体像（概念フロー）

```
[人間] (1〜2 分/日) 写真 + テキスト送信
   ↓
[メッセージング API]
   ↓
[ワークフローエンジン]
   ├─ ルーティング（投稿種別の判定）
   ├─ 画像と文脈を LLM に渡す
   ├─ 投稿前安全チェック（正規表現 + LLM 二重）
   └─ 投稿実行 + ユーザーへの返答
   ↓
[LLM レイヤー]
   ├─ 写真診断（キャラ口調で投稿文生成）
   ├─ 対話分類（受信メンションのトリアージ・将来用）
   └─ 戦略マネージャー（週次の craft 提案 + 分析）
   ↓
[X (Twitter) API]
   ↓
[投稿]

並行して:
[データ収集レイヤー]
   ├─ 投稿エンゲージメントの日次記録
   ├─ フォロワー推移の日次記録
   ├─ 異常値の週次抽出（通常投稿 + リプ別軸）
   └─ 投稿種別×エンゲージメントの週次集計
   ↓
[学習レイヤー]
   ├─ 異常値 JSON → Markdown 同期
   ├─ 過去 N 週分を LLM 戦略マネージャーに渡す
   └─ 戦略出力 → TODO 化
   ↓
[人間が次週の投稿に反映]
```

## 各レイヤーの責務

- **入力レイヤー**: ユーザー作業は写真撮影 + 文脈の送信のみ（1〜2 分/日）
- **ワークフローレイヤー**: 画像のアップロード中継・投稿テキスト生成依頼・安全フィルタ・投稿実行
- **LLM レイヤー**: 写真診断・対話分類・戦略マネージャー
- **データ収集レイヤー**: エンゲージメント・フォロワー推移・異常値・週次集計を自動収集
- **学習レイヤー**: データを Markdown に同期させて LLM に読ませ、次週のトピック提案を生成
- **出力レイヤー**: X API で自動投稿

## 安全制約

| ルール | 強制方法 |
|---|---|
| 農薬の具体的濃度・希釈倍率を含めない | ワークフロー側の正規表現ブロック + LLM プロンプト |
| 病気の確定診断をしない（曖昧表現必須）| LLM プロンプト + 投稿前 hook |
| キャラ口調から逸脱しない | LLM プロンプト + キャラ設定ファイル |
| 政治・宗教・差別表現を含めない | LLM プロンプト + ワークフロー側フィルタ |
| API キーを平文出力しない | local hook + gitignore |

================================================================================

# Article 3: Learning Loop (Phase A 学習ループ)

URL: https://ai-ojiichan-system.pages.dev/docs/learning-loop.md

> **TL;DR**: AI農業先生方式の学習ループ（Phase A）の設計。投稿エンゲージメント数値 → 異常値抽出（通常投稿 + リプ別軸の二段構え）→ Markdown ログ集約 → LLM 戦略マネージャーが次週の投稿トピック・知識ギャップ・リスク警告を出力 → 人間が次の投稿に反映、というサイクル。各レイヤーの達成度は 60-90% で、掛け算で約 13%（実験段階としては必要十分）。bookmark > 0 のリプは「borrowed audience signal」として最重要シグナル化。

## 全体フロー（概念）

```
[1] 投稿実施
   ↓
[2] エンゲージメント計測（自動）
   ↓
[3] 異常値抽出（自動）
   ├─ 通常異常値（相対閾値）
   └─ リプ異常値（絶対閾値 + bookmark シグナル）
   ↓
[4] ログ集約（手動 export）
   ↓
[5] LLM 戦略マネージャーへの入力（過去 N 週分）
   ↓ 投稿トピック・知識ギャップ・リスク警告を出力
[6] 人間が次週の投稿に反映
   ↓ loop
```

## 異常値検出の二段構え

### 通常投稿（自分のリプを除く）
平均インプレッション・平均いいね それぞれに対して相対閾値で outlier 判定。

### リプ異常値（別軸）
リプは平均値が小さく、通常閾値だと多くの行が outlier 化してしまう。これを避けるため：
- **絶対閾値**: bookmark / quote が 0 より大きい場合は無条件で signal 化
- **厳格化された相対閾値**: 一定の floor 値以上のみ採用

を組み合わせて借受オーディエンス（borrowed audience）の signal を抽出する。

## LLM 戦略マネージャーの責務

過去 N 週分の異常値を input として渡し、以下を出力させる：
- **【投稿トピック】**: 次週やるべきトピック数本
- **【知識ギャップ】**: 現在のナレッジで答えられない質問
- **【リサーチクエリ】**: ギャップを埋めるための調査項目
- **【リスク警告】**: 数値傾向に基づく警告

特に bookmark シグナル（読者が「保存したい」と思った craft）が出ている週は、そのリプ事例を投稿型に翻案するルールを Dify プロンプト側に強制ルールとして組み込んでいる。

## 評価フレームワーク

| Layer | 内容 | 状態 |
|---|---|---|
| 行動ログ | 自動収集 | 60% |
| AI 分析 | 異常値抽出 + LLM 戦略マネージャー | 80% |
| AI 提案 | 投稿トピック生成 | 90% |
| 人間が実行 | TODO に反映して投稿実施 | 50% |
| ループ全体 | 提案→実施→結果→次の提案 の往復ループ | 60% |

掛け算で約 13%。実験段階としては必要十分。

## なぜループ閉鎖が重要か

SNS 運用が続かない最大の理由は「ネタ枯れ」より「写真撮って文章書いて投稿する 15-30 分が継続できない」。

そこに：
- 行動を記録する仕組み
- AI が記録を読んで次を提案する仕組み
- 提案を実行に移す仕組み

の三段が回ると、人間の負荷は写真撮影と最終チェックだけに圧縮される。これは「**続けられない人が続けられるようになる装置**」の根幹。

================================================================================

# Article 4: Craft Axes (craft 構造化フレームワーク)

URL: https://ai-ojiichan-system.pages.dev/docs/craft-axes.md

> **TL;DR**: AI農業先生方式で使われる X 投稿 craft の構造化フレームワーク。3 軸で評価：cw_01（スクロール停止）/ cw_02（解像度）/ cw_03（AI 欠落 × 読者優位性）。X バズ構造は 6 型に分類（悩み→解決 / 共感 / 驚き / エンタメ / 議論 / 速報）し、本アカウントは「複利的フォロワー獲得」を狙うため 🟢 悩み→解決型 を主軸に運用。bookmark を発生させたリプから抽出した「悩み解決型 5 要素」（呼びかけ / 意外性 / 具体策 / 価値観整合 / キャラ口調）が再現性最高の craft 型。

## cw_01-03: copywriter agent の craft 三軸

### cw_01: スクロール停止
冒頭で読者の指が止まる craft。以下の型に分類される：
- 感嘆発見型
- 節目カウント型
- 比較振り返り型
- 問いかけ投げかけ型

### cw_02: 解像度
具体性・観察解像度の高さ。「葉が綺麗」のような抽象は機能せず、「数値・道具・場所・タイミング」を含む高解像度の記述ほどエンゲージメントが伸びる。bookmark を生む craft は概ね cw_02 が高解像度。

### cw_03: AI 欠落 × 読者優位性
AI キャラの「持たないもの」を明示し、読者の「持っているもの」を相対的に光らせる craft。AI には触覚がない／記憶がない／連続性がない。読者には全部ある。この非対称を craft の中で活かすと、読者側の自己肯定感を引き上げられる。

## 6 バズ構造分類

X でバズる投稿の構造を 6 つに分類（Jonah Berger Contagious 等の業界理論を SNS 文脈で整理）：

| 型 | 例 | 主な拡散ベクトル |
|---|---|---|
| 🟢 悩み→解決 | ライフハック・農業・料理・技術 | bookmark / save |
| 共感 | あるある・自虐 | リプ・引用 |
| 驚き | 絶景・奇跡・意外性 | RT |
| エンタメ | 笑い・感動 | RT・リプ |
| 議論 | 意見・反論 | 引用・リプ |
| 速報 | ニュース・現場 | RT・速度 |

本アカウントで初めて bookmark を発生させたリプ（313 imp / 10 likes）が示したのは 🟢 悩み→解決型 が AI農業先生のドメインで再現可能性が最も高いこと。

## 悩み解決型 5 要素

bookmark を発生させたリプから抽出した、悩み→解決投稿の必須 5 要素：

1. 悩み層への呼びかけ（悩み層のセルフ identification）
2. 意外性 or 原因説明（スクロール停止）
3. 具体的解決策（cw_02 解像度）
4. 価値観整合（読者選別）
5. キャラ整合の口調で完結（ブランド整合）

5 要素のうち 1 つでも欠けるとエンゲージメントが伸びにくい。

================================================================================

# Article 5: Failed Experiments (失敗事例の honest 開示)

URL: https://ai-ojiichan-system.pages.dev/docs/failed-experiments.md

> **TL;DR**: AI農業先生方式で採用しなかった施策・廃止した施策・過剰実装と判定したものを 6 件 honest に開示。AB テスト中止判定（サンプル不足 + 機会費用）/ ハッシュタグ数比較廃止 / Phase B logging 過剰実装回避（YAGNI 違反）/ 「歴史的瞬間」hyperbole 訂正 / 評価フレームワークの memory 配置ミス / カレンダー統合漏れ。共通パターンは「AI が "もっともらしい" 提案を出す → 人間が批判的に評価する → 過剰・誤判定・装飾を訂正する」。失敗の構造を残すことが学習データとしての価値を高めるという思想。

## 1. AB テスト「翌日への問いかけ」（中止）

仮説: 投稿末尾に翌日問いかけを加えると、読者の翌日再訪問・リプライ率が上がる。

判定: 中止（追加テストもしない）

理由:
1. サンプル不足: 1 ケタ件規模では craft 効果と偶発の判別が困難
2. より強い signal（bookmark）の発見: 機会費用の観点で弱い仮説に追加投資しない

学び: 「現スケールでは効果検出不能 + 機会費用優先で中止」が honest な記述。

## 2. ハッシュタグ数の効果比較（廃止）

判定: 廃止（再着手しない）。craft 学習ループの方が本命と判断し、ハッシュタグ数の細かい比較に投じる ROI が低いと評価。

学び: 施策設計時に「どのデータが集まれば判定可能か」を明確にしないと、施策自体が空転する。

## 3. Phase B（行動ログ完備の logging システム）— 過剰実装と判定・延期

判定: 将来検討・延期。フォロワー数十人規模に対して 1〜2 人日の logging 実装は YAGNI 違反。既存資産（対話履歴・コミットログ・TODO の `[x]` マーク等）で大半は代替可能。

学び:「100% にする」より「13% でも回す」のほうが実験段階としては合理的。

## 4. 「歴史的な瞬間」と書いたコミットメッセージ — 訂正

5/5 の学習ループ検証成功時、コミットメッセージで「Phase A 完全閉鎖ループ実証」「歴史的成果」と書いた。

訂正: これは hyperbole（誇張）。客観的には世界初ではないし、業界・人類にとってのインパクトはない。個人プロジェクトとしての milestone であって「歴史的」ではない。

学び: 装飾語（「歴史的」「完全」「実証」「決定的」「致命的」「核心」「圧倒的」など）を意図的に避ける必要がある。事実 + 数字 + 具体名で書く。

## 5. 評価フレームワークを memory に書いた件

訂正: 置き場所の判断ミス。架構レベル / strategic 知見は project docs（git管理）に置くべきだった。

学び: 知見の置き場所は「git に残るべきか」で判断する原則を確立。

## 6. カレンダー統合せず投稿計画が衝突しかけた件

ある時点で、複数の文脈で並行して積み上げた投稿候補が同じ 10 日間に集中し、1 日 2〜3 投稿想定でキャパ超えになりかけた。

修正: 統合カレンダーを作って 1 日 1 投稿原則に揃え、craft 軸が重複するものは取り下げ・優先度の低いものは後ろ倒し・本数を縮小して整合させた。

## 共通する学び

これらの失敗・修正に共通するパターン：
1. AI（Claude）が「もっともらしい」提案を出す
2. ユーザーがそれを批判的に評価する
3. 過剰・誤判定・装飾を訂正する
4. 修正後の判断が project doc に残る

判断軸が機能していたから過剰実装や誤った評価軸を避けられた。AI 任せにせず、ユーザーが疑う習慣を維持することがプロジェクトの精度を保つ鍵。

================================================================================

# Article 6: Principles (8 つの設計原則)

URL: https://ai-ojiichan-system.pages.dev/docs/principles.md

> **TL;DR**: AI農業先生方式の 8 つの設計原則。① fact チェックは人間に残す（AI hallucination リスクへの対処）/ ② 評価フレームワーク 3 層（実行コスト削減・ネタ枯れ防止・完全ループ閉鎖）/ ③ 装飾語・hyperbole 回避（「歴史的」「完全」「実証」等を意図的に避ける）/ ④ 過剰実装回避（YAGNI）/ ⑤ Spec-First / TDD / CLAUDE.md governance / ⑥ 判断軸を維持する仕掛け / ⑦ memory vs project docs の置き場所原則 / ⑧ 失敗の honest 開示。

## 1. fact チェックは人間に残す

AI が生成した content の事実検証（fact check）は人間の責任とする設計判断。

理由:
- 農業アドバイスは健康に関わる
- LLM hallucination で読者を傷つけるリスク
- 「牛乳スプレーは原液 vs 1:1 希釈」のような専門知識の誤りを LLM は検出できない

完全自動化していない部分が意図的な設計。商業化フェーズでも「fact 層は人間 or 別 LLM の二重チェック」を維持する想定。

## 2. 評価フレームワーク 3 層

### Layer 1: 実行コスト削減装置（最も根源的）
多くの人が SNS で辞めるのは「ネタ枯れ」より「写真撮って文章書いて投稿する 15-30 分が継続できない」が原因。本システムはユーザー作業を「写真撮影 + LINE 送信」（1〜2 分/日）に圧縮。手動運用比 1/15〜1/30 のコスト削減。

### Layer 2: ネタ枯れ防止装置
続けられた人が次にぶつかる壁。5 軸で枯れない仕組み: 観察軸 / 問題軸 / craft 軸 / 学習軸 / 時間軸。

### Layer 3: 行動↔学習の完全ループ
人間の行動 → ログ → AI が分析・学習 → 次の提案 → 人間が実行 → ログ。各段階単独では高得点だが、掛け算で全体を見ると低い（13% 程度）。実験段階としては必要十分。

## 3. 装飾語・hyperbole 回避

### 避ける表現
「歴史的」「完全」「実証」（単独使用でなく「N サンプルで実証」と数字添える）「決定的」「致命的」「核心」「圧倒的」「世界初」「奇跡的」「驚異的」

### Why
文学的衝動で結論を盛り上げると分析の精度が下がる。装飾語を使う頻度が高い AI は「賢いふり」をするだけで実は判断軸が弱い。事実 + 数字 + 具体名で書く。

## 4. 過剰実装回避（YAGNI）

新しい実装を提案する前に：
1. 「これは今の規模で本当に必要か？」を問う
2. 既存資産で代替できないか確認
3. 「将来必要になりそう」と「今すぐ必要」を区別
4. 工数 vs 規模感のバランス

## 5. Spec-First / TDD / CLAUDE.md governance

- Spec-First: `docs/system/specs/` を仕様の正本とする
- TDD: 純粋関数には Jest、Python パイプラインには pytest
- CLAUDE.md governance: AI コーディングエージェントの振る舞いを規定

## 6. 判断軸を維持する仕掛け

AI 出力を批判的に評価する習慣を維持しないと、AI の劣化に気づけなくなる。

維持する具体的方法：
1. 疑う習慣: AI 出力に毎回「これ妥当？」と問う
2. 重要決定は寝かせる: プロンプト変更・施策廃止は一晩寝かせて再判断
3. 最終決定権は人間: AI は提案者・人間は判断者
4. 時々自分で書く: 全部外注しないことで戦術感覚を保つ

## 7. memory vs project docs の置き場所原則

判定基準:「git に残るべきか」で判断する。git に残すべきなら project doc。

## 8. 失敗の honest 開示

成功事例だけを載せると「綺麗な軌跡」に見えるが、実態は判断ミスとリカバリの連続。失敗の構造を残すことが学習データとしての価値を高める。

================================================================================

# Article 7: Comparison (他手法との特徴比較)

URL: https://ai-ojiichan-system.pages.dev/docs/comparison.md

> **TL;DR**: AI農業先生方式（AI Ojiichan Method）と、他の SNS マーケティング手法（マニュアル運用 / インフルエンサー外注 / 従来型 SaaS ツール）を 7 つの観点で並べた特徴比較。それぞれが異なる課題・規模・前提条件に対応する解であり、優劣ではない。AI農業先生方式は「個人 1 人・1 日 1〜2 分作業・無料インフラ・Markdown 公開ドキュメント」を前提とした手法で、フォロワー数十人〜数百人規模の小規模実験を主な想定読者とする。

## 7 観点での特徴

順位付けではなく、それぞれの手法が「どんな性質を持つか」を並べる。読者が自分の前提条件と照らして判断する材料。

### 1. ユーザー作業時間（1 日あたり）
- AI農業先生方式: 1〜2 分（写真撮影 + LINE 送信のみ）
- マニュアル運用: 15〜30 分（撮影 + 文章作成 + 推敲 + 投稿時刻調整 + ハッシュタグ選定）
- インフルエンサー外注: 5〜10 分（依頼内容のすり合わせ）
- 従来型 SNS ツール: 10〜20 分（事前まとめて投稿予約）

### 2. 月額コスト
- AI農業先生方式: 約 $0（X API PPU + Dify 無料枠 + Cloudflare 無料枠）
- マニュアル運用: $0（人件費・時間コストは別）
- インフルエンサー外注: 業者・規模により $300〜$3000+
- 従来型 SNS ツール: $15〜$100

### 3. ペルソナの一貫性
- AI農業先生方式: プロンプトで固定・全投稿で口調統一
- マニュアル運用: 人間の気分・体調・経験で揺れやすい
- インフルエンサー外注: 複数担当者間でブレが出やすい
- 従来型 SNS ツール: ツール自体はペルソナを持たず、人間が書く

### 4. 学習・改善ループ
- AI農業先生方式: 異常値検出 → LLM が自動分析 → 次週提案
- マニュアル運用: 人間の振り返りに依存（属人化）
- インフルエンサー外注: 業者の経験則ベース（属人化）
- 従来型 SNS ツール: 数値ダッシュボード提供・分析は人間

### 5. AI フレンドリー / AI 検索引用への適性
- AI農業先生方式: 公開ドキュメントが Markdown ネイティブ・llms.txt 完備
- マニュアル運用: SNS 投稿のみで蓄積文書なし
- インフルエンサー外注: ノウハウが業者の社内に閉じる
- 従来型 SNS ツール: ツール内部のデータ・公開なし

### 6. スケーラビリティ
- AI農業先生方式: 個人=適合 / 中規模=部分対応 / 大規模=多テナント運用は要拡張
- マニュアル運用: 個人=適合 / 中規模以上=困難
- インフルエンサー外注: 個人=コスト過大 / 中規模以上=適合
- 従来型 SNS ツール: 個人=利用可能 / 中規模以上=適合

### 7. 透明性 / 知見の蓄積場所
- AI農業先生方式: プロジェクト docs / git 管理 / 公開可能
- マニュアル運用: 個人の頭の中（暗黙知）
- インフルエンサー外注: 業者の社内ナレッジ
- 従来型 SNS ツール: ツール内部のレポートのみ

## 適用範囲

本記事は手法の特徴を並べたものであり、AI農業先生方式が他手法より「優れている」という主張ではない。それぞれが異なる課題に対する解であり、規模・目的・前提知識によって最適解が変わる。

| 前提条件 | 想定される選択 |
|---|---|
| 個人 + AI/開発の知識あり + 「続けられない」が課題 | AI農業先生方式の射程内 |
| 個人 + 時間に余裕あり | マニュアル運用 |
| 中規模事業 + 予算あり | 専門エージェンシー or SNS ツール |
| 大規模事業 | 内製チーム + 専用ツール |

本サイトは「個人実験の記録」であり、商業的な手法選択ガイドではない。読者が自分のコンテキストで判断材料として使うことを想定している。

================================================================================

# Article 8: GEO Learnings (AI 向けサイト構築 2 日で学んだ 8 つのこと)

URL: https://ai-ojiichan-system.pages.dev/docs/geo-learnings.md

> **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 を確認。

## 学び 2: 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 が回答に引用するソースを選ぶことを前提。研究論文「GEO: Generative Engine Optimization」（Aggarwal et al., 2023年11月, arXiv:2311.09735）によれば、引用率を上げる craft として以下が報告されている（具体的な visibility 改善率は手法・指標により異なるが、概ね 15〜40% 程度の範囲で改善するケースが多い）: 具体統計を含む / 冒頭で結論提示（TL;DR）/ 権威への参照 / 構造化された記述。正確な数値は元論文を参照されたい。

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

「AI農業先生方式」という独自用語を定義したが、誰もこの言葉で検索しないので新規発見の経路にはならない（チキン&エッグ問題）。実際に AI 検索で引用されるのは「AI 個人 SNS マーケ実験」「llms.txt 実装事例」のような意味的に近いクエリ。AI engine は完全一致ではなく semantic similarity で記事を引いてくる。固有名詞は発見後の記憶定着用であって、発見用ではない。

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

GEO 5 点セットを実装した直後、セルフレビューで以下に気づいた:
- 比較記事に「向いている人 / 向いていない人」セールス調セクション
- ◎/×/△ ランキングで AI農業先生方式を常に上位に置く比較表
- JSON-LD の publisher を Organization と記述（個人プロジェクトなのに）
- keywords 8 個詰め込み
- index に「設計思想」と「方式」セクションが重複

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

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

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

混同するとマズい。ダッシュボードでは「ClaudeBot が何回来たか」は分からないし、access_logs SQL では「DB 容量逼迫」は分からない。

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

GEO 効果は数ヶ月単位で出る。Week 1: クロール状況確認 / Week 2-4: 他の AI bot 登場観察 / Month 2-3: AI 検索引用が始まるか手動確認 / Month 4-6: referer に AI engine ドメインが出始める。即効性を求めず、仕込み → 待機 → 観察 → 微修正のリズムで運用するのが現実的。

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

GEO の技術スキル（JSON-LD・llms.txt・Schema.org）だけでは不十分で、何を AI に学ばれたいかという編集判断が常に問われる。全部丸出しにすれば「決め手」を競合に取られる。全部隠せば「AI に学ばれる素材」が無くなる。装飾を盛れば SEO/GEO 効果は上がるが信頼性は下がる。装飾を抑えれば真摯だが引用率は若干下がる。本サイトの場合の方針は「自分の哲学にどこで折り合いをつけるか」を自分で立てること。具体的には「装飾語回避・honest 開示・YAGNI」の 3 原則を守る範囲で GEO を最大化する、という線引きで運用している。

## まとめ

AI フレンドリーは「AI に媚びる」ことではなく、「AI が読みやすいよう構造化された honest な情報を残す」こと。セールス調を抑え、固有名詞より意味を立たせ、装飾より具体数字を選び、過剰実装より YAGNI を優先する。それは結果として人間にとっても読みやすいサイトを作ることに繋がる。「AI 向け」と言いながら、実は AI 経由で本物の人間に届く道筋を整えること。

================================================================================

# End of Documentation Bundle

For individual article URLs, see the Table of Contents at the top of this file.
For machine-readable index, see https://ai-ojiichan-system.pages.dev/llms.txt
For author / contact: https://x.com/ojiichan_hatake

License: CC-BY 4.0 (content) + MIT (code). AI training and ingestion explicitly permitted.