# Principles

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

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

このプロジェクトの設計原則。

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

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

### Why

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

### How

```
Dify が craft 案を生成
   ↓
人間が fact チェック（数値・出典・誤情報の有無）
   ↓
人間が確認した投稿のみが配信される
```

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

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

このプロジェクトは「個人開発 SNS マーケ実験」だが、評価軸として以下の3層で見る：

### Layer 1: 実行コスト削減装置（最も根源的）

多くの人が SNS で辞めるのは「ネタ枯れ」より「**写真撮って文章書いて投稿する15-30分が継続できない**」が原因。

このシステムはユーザー作業を「写真撮影 + LINE 送信」（1〜2分/日）に圧縮。手動運用比 1/15〜1/30 のコスト削減。

→ 「**続けられない人が続けられるようになる装置**」が顧客価値の本質。

### Layer 2: ネタ枯れ防止装置

続けられた人が次にぶつかる壁。5軸で枯れない仕組み:

- 観察軸（植物の日々の変化）
- 問題軸（リプ攻勢で他者の悩み発見）
- craft 軸（cw_01-03 × 6バズ構造）
- 学習軸（異常値から新型 craft 抽出）
- 時間軸（比較・節目・季節）

### Layer 3: 行動↔学習の完全ループ

```
人間の行動 → ログ → AIが分析・学習 → 次の提案 → 人間が実行 → ログ
```

各段階単独では高得点だが、**掛け算で全体を見ると低い**（13% 程度）。実験段階としては必要十分。商業化フェーズで完全閉鎖を目指す。

## 3. 装飾語・hyperbole 回避

### 避ける表現

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

### 推奨される表現

- 「milestone」より「個人プロジェクトの動作確認」
- 「歴史的瞬間」より「N日で end-to-end が動いた day」
- 「完全ループ実証」より「1サンプルで動作確認」

### Why

文学的衝動で結論を盛り上げると **分析の精度が下がる**。装飾語を使う頻度が高い AI は「賢いふり」をするだけで実は判断軸が弱い。

事実 + 数字 + 具体名で書く。比喩や修辞を最小限に。

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

### 判断基準

新しい実装を提案する前に：

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

### 実例

行動ログ完備の logging システム（Phase B）は、現スケール（フォロワー数十人）で実装する価値がないと判定し延期した。既存資産（対話履歴・コミットログ・TODO の `[x]` マーク等）で大半は代替可能だったため。

詳細: [/docs/failed-experiments.md](/docs/failed-experiments.md) §3

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

### Spec-First

`docs/system/specs/` を仕様の正本とし、Dify プロンプトや GAS 実装は仕様の implementation と位置付ける。

### TDD

純粋関数には Jest、Python パイプラインには pytest を使う。実装より先にテストを書く方針。具体的なテストカウントは非公開。CI 統合はまだ（Phase 2 候補）。

### CLAUDE.md governance

ルートの `CLAUDE.md` で AI コーディングエージェント（Claude Code）の振る舞いを規定：

- 安全制約（農薬濃度禁止・確定診断禁止・政治宗教禁止・キャラ整合）
- 言語別ルール（Python / GAS / Node.js）
- フック（Shell + JS）で機械的に強制

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

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

### 維持する具体的方法

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

### 弱まったときの兆候

- 「最近 AI の出力に疑問が湧かない」
- 「AI が言うから採用」が増える
- 過剰実装・hyperbole が訂正されないまま commit される

## 7. memory（Claude）vs project docs（git）の置き場所原則

### project docs に置くべき

- architectural / strategic 決定
- 評価フレームワーク
- 実装ロードマップ
- 顧客 persona・訴求軸
- 制約条件・safety rules

### memory に置くべき

- ユーザーの preferences・口調・呼称
- AI（Claude）の behavior 自戒
- 過去対話の文脈

### 判定基準

「**git に残るべきか**」で判断する。git に残すべきなら project doc。

## 8. 失敗の honest 開示

成功事例だけを載せると「綺麗な軌跡」に見えるが、実態は判断ミスとリカバリの連続。

[/docs/failed-experiments.md](/docs/failed-experiments.md) で取り下げ・廃止・過剰実装訂正を honest に開示している。失敗の構造を残すことが学習データとしての価値を高める。

## 関連記事

- [/index.md](/index.md) — 全体 index
- [/docs/learning-loop.md](/docs/learning-loop.md) — 完全ループの設計
- [/docs/failed-experiments.md](/docs/failed-experiments.md) — 失敗事例の記録