AI駆動開発のために

このリポジトリに既にある規範のうち、実装の大半を AI に書かせる前提だと 自然には守られなくなるものだけを集めた。

内容は新しくない。元は 本・業界の原典から自分のノートにある。 ここにあるのはその差分、つまり「同じ規範を守り続けるために、 何を追加で書き留めておく必要があるか」だけ。

なぜ3本目のツリーなのか

**既存の2ツリーは出所で分かれている。**原典があるか、ないか。 このツリーはその軸に乗らない。原典があるかどうかではなく、 誰が読むか・誰が書いたものを受け取るかで切っている。

ツリー切り方中身
best-practices原典がある書籍と web の一次情報源から書いたもの
experiences原典がない現場で決めた判断、設定ファイル、構文メモ
ai-driven(ここ)読み手が AI、または書き手が AI上の2つから派生させた運用ルールと、貼るための資材

**だからこのツリーは原典ではない。**各ページの source: には web の URL でも書籍でもなく、このリポジトリ内の元ページが入っている。 主張の根拠を知りたいときは元ページを読む。ここにあるのは元ページの言い換えではなく、 元ページの規範が AI 相手だとどう崩れるかと、崩さないために何を仕掛けるか

各ページの形

4つの節が必ずこの順で並ぶ。

元の規範        どのページの、どの記述を前提にしているか
何が崩れるか    AI に書かせると、その規範がどう自然に破られるか
どう仕掛けるか  人間の注意力ではなく仕組みで止める方法
そのまま貼る    コピー&ペーストで使える本文

**「そのまま貼る」だけを拾って使ってよい。**上3つは、 半年後にその指示を消してよいか判断するための材料として置いてある。

中身

  • 原則 — AI に委譲できない判断はどれか。既存の原則との対応
  • レビュー — 変更の粒度が最初に壊れる。人間のレビュー帯域が律速になったときの配分
  • テスト — 「通るテスト」に最適化される。信頼できないテストは無い方がましという前提が直撃する
  • セキュリティ — 秘密情報、依存の実在確認、生成コードの流入経路
  • バージョン管理 — 取り消せる単位でコミットする。これが唯一効くブレーキになる
  • ハーネスに書く — CLAUDE.md / settings.json / hooks の使い分けと、全部入りのコピペ

元ページとの対応

ここ崩れ方の要点
原則原則推測が高速に大量生産される。確かめる負荷が人間に一極集中する
コードレビューの進め方レビュー100行が適度・1000行は大きすぎるという基準が、数分で破られる
コードレビュー(書籍第9章)レビュー「まったく新しいコード」の比率が上がり、設計レビューの比重が増す
テストテスト挙動ではなく実装詳細を、状態ではなく相互作用をテストしがち
テストテスト本物 > フェイク > スタブの優先順位が、明示しないと反転する
秘密情報の管理セキュリティ読ませない・出力させない・コミットさせないの3箇所すべてに口ができる
依存関係セキュリティ提案されたパッケージが実在するとは限らない
静的解析レビュー / ハーネスに書く「機械が指摘できるものを人間に見させない」の価値が上がる
バージョン管理 / Git の運用バージョン管理1セッションに複数の関心事が混ざり、コミットが分かれない
継続的インテグレーションバージョン管理戻す判断が、唯一まともに効くブレーキになる

このツリーの寿命

リポジトリの中で最も速く古くなる階層。

README の「古くなった記述を見直すとき」にある規則を、 そのままこのツリーに当てはめるとよく分かる。

反転しやすい   「こう書け」と勧めている記述
               とくにブラウザの実装や、フレームワークの流儀が変わる領域

このツリーは全体が「こう書け」で、しかも道具の流儀が最も速く変わる領域にある。 settings.json のキー名も、hooks のイベント名も、そのうち変わる。

だから2つに分けて書いてある。

部分寿命
「元の規範」「何が崩れるか」長い。 元ページと同じ寿命。人間の側の性質に依存している
「どう仕掛けるか」「そのまま貼る」短い。 特定の道具の設定形式に依存している

設定の形式が変わっていたら、上2つを読んで書き直す。 このツリーを丸ごと捨てて書き直すことにはならないはず、という前提で分けてある。

6件のページ