AI駆動開発の実運用ノート

AI駆動開発の実運用ノート　›　本編の目次

本編の目次

全5部・134回。頭から順に読めば通しで読めますし、気になる回だけ拾っても読めます。 部の題をクリックすると、その部だけの目次に入れます。

最初から読む

1

AI時代の人間の仕事

全29回

はじめに

  1. No.1AIが規律を守って開発し続ける仕組みを持ち帰る
  2. No.2第1部は「判定する人」の目で読む
  3. No.3教材のもとになった実プロジェクトの実測値
  4. No.4本編の前にあった5か月の序章

未来予想図

  1. No.5AI駆動開発の現在地と、数年後の姿
  2. No.6AI活用の3段階と、多くの組織が止まる場所
  3. No.7数年後に変わることと、変わらないこと

2つの誤解を正す

  1. No.8AIに任せると人はいらなくなるのか
  2. No.9経営層と現場が抱く、正反対の誤解
  3. No.10規律を足すと開発は遅くなるのか
  4. No.11統治コードは製品コード41万行の0.9%

「AIに仕事をさせるという仕事」

  1. No.12AIに委任した後、人間に何が残ったのか
  2. No.13人間に残った5つの役割はマネジメントそのもの
  3. No.14機械で止められる失敗と、止められない失敗

規律が働く瞬間

  1. No.15書いたルールは、書いただけで守られるのか
  2. No.16「確認して」と言うとAIは編集できなくなる
  3. No.17AIは自分の判断で本番に触れない
  4. No.181日10回デプロイしてCIの無料枠が枯れた
  5. No.19「ステージングでブラウザテストした？」
  6. No.20AIの「完了しました」を信じなかった日
  7. No.21事故をルールとフックに変える循環
  8. No.22AIを躾ける規律のコードも、AIが書いた

組織への持ち帰り

  1. No.23自分の組織に導入するとき、何から決めるか
  2. No.24AI導入の3つの道と、それぞれの弱点
  3. No.25導入で最初に決める3つのこと
  4. No.26Claude Code のシートは誰に何が必要か
  5. No.27第1部の結論は3つ
  6. No.28全5部の地図と、2つのレーンの読み方
  7. No.29第1部のまとめと、第2部への問い
2

要件定義と設計

全32回

はじめに

  1. No.30AIに何を作らせるかを、どう文書で伝えるか
  2. No.31第2部から読み手は判定する側に回る

エンジニアの立ち上げ

  1. No.32AIに任せる前に知っておくべき相手のクセ
  2. No.33実際に起きたAIの悪癖4つと、その対策の置き場所
  3. No.34Claude Code を統治の4階層で捉える
  4. No.35題材システム Keihi を起動して一巡する

ドキュメント駆動開発

  1. No.36AIは何を読んで実装するのか
  2. No.37AIにとって文書は読み物ではなく実行環境
  3. No.382.4ヶ月コミットが止まり、9分間で要件57本が入った
  4. No.39要件と画面を突き合わせるギャップ分析
  5. No.40文書は98本から274本へ、事業の写像として育つ
  6. No.41文書に残った古い250円をAIが信じて誤説明した
  7. No.42文書は4ヶ月で3種類の劣化を起こした
  8. No.43コード変更と文書更新を同じコミットに縛る

イシュー駆動とタスク分割

  1. No.44すべての作業をイシューから始めると何が変わるか
  2. No.45イシュー管理ツールはAIの外部記憶である
  3. No.46「レビュー中」に独自の意味を与えて品質ゲートにする
  4. No.471PR = 1レイヤーで分ける理由

大規模な要件追加・仕様変更の作法

  1. No.48大きな仕様変更のとき、AIに何と言うか
  2. No.49大規模変更5件の実例で何が起きたか
  3. No.508回却下した設計案をAIがまた提案してくる
  4. No.51「お金の支払いが発生する業務は急がない」
  5. No.52人間が出すのは答えではなく原則と反例
  6. No.53コードより先に「設計メモ」を書く
  7. No.54「小さな変更」が実測で12ファイル40箇所になった
  8. No.55大規模変更を安全に進める4つの段階
  9. No.56別のセッションのAIが8時間で11PRを完走した計画書

再現と演習

  1. No.57要件と画面を突き合わせて、実装前に漏れを見つける
  2. No.58要件文書を1PR=1レイヤーのイシューに割る
  3. No.59ギャップ分析で要件と画面の食い違いを洗い出す
  4. No.60AIが書いた設計メモの穴を3つの観点で探す
  5. No.61第2部のまとめと、第3部への問い
3

実装→検証イテレーション

全26回

はじめに

  1. No.62AIの「完了しました」を、どう検収するか
  2. No.63AIの完了報告に「本当に？」と言うのが読み手の役割
  3. No.64開発・ステージング・本番、3つの環境の使い分け

検証の規律はどう生まれたか

  1. No.65AIの「完了しました」は信じてよいのか
  2. No.66開発フローは3ヶ月かけて検証だけが厚くなった
  3. No.67検証の規律が育った3段階
  4. No.68「検証のふり」と本当の検証を見分ける
  5. No.69「購入を含むチケット券面の確認をしていますか？」
  6. No.70機能の価値が誰のどの画面に届くかを先に決める
  7. No.71空の画面がハリボテかを見分ける4つの信号
  8. No.72「今まで自分でログインしていたじゃないですか」

検証の階段

  1. No.73検証の階段5段は、それぞれ何を捕まえるのか
  2. No.74検証の階段を飛ばせない理由
  3. No.75合計だけを検証すると誤差の相殺を見逃す
  4. No.76タイムゾーンなしのtimestampが集計を9時間ずらした
  5. No.77自動テストの「緑」も検証の対象にする
  6. No.78「比較するだけ」のコマンドが開発DBを全消去した

実証の文化

  1. No.79「検証しました」を、どう証明させるか
  2. No.80完了報告に義務づける3点セット
  3. No.81並列エージェントの「全要件、実装済み」はコードで確かめる

通し実装

  1. No.82差戻し機能の完了判定は読み手に委ねられる
  2. No.83差戻し機能を起票から通常マージまで通しで作る
  3. No.84AIの完了報告を「これで完了と言えるか」判定する
  4. No.85「差戻し通知は実装済み？」への答えを実地検分する
  5. No.86毎日の開発フローマニュアル1冊に全部書いてある
  6. No.87第3部のまとめと、第4部への問い
4

規律の仕組み化

全24回

はじめに

  1. No.88「言い続ける仕事」をフックに渡す
  2. No.89フックの価値は事故が止まるのを見るまで腹落ちしない

ルールは事故とともに育つ

  1. No.90ルールは書けば守られるのか、4ヶ月の実測で答える
  2. No.91ルール文書は15行から477行、そして179行へ
  3. No.92フックは3.5ヶ月で24本、全て稼働中
  4. No.93最初のフックは事故を直すPRの中で生まれた
  5. No.94エラーが一切出ないまま468行のコードが消えた

多層防御の設計

  1. No.95フックは「止める」以外に何ができるのか
  2. No.96介入できるタイミングは5つに増えた
  3. No.9727日かけて三層にして、ようやく事故が消えた
  4. No.98例外ゼロのルールは現実に負けて無効化される
  5. No.99フックの正体はただのシェルスクリプト

記憶の設計

  1. No.100AIの記憶は何によって壊れるのか
  2. No.101自動メモリ・記憶DB・イシュー管理に記憶を分ける
  3. No.102記憶は「肥大」と「同期の取りこぼし」で壊れた
  4. No.103是正の記憶は、理由まで書くから次に活きる

「AI を躾ける仕組みも AI 自身が作る」

  1. No.104規律の実装をAIに任せると何が起きるか
  2. No.105規律を実装したのはAI自身だったという4つの証拠
  3. No.106規律インフラを育てる6つの段

わざと事故る

  1. No.107わざと事故を起こして、止まるところまで見る
  2. No.108スカッシュマージの消失事故を自分の手で起こす
  3. No.109事故から再発防止までの時間を自分で測る
  4. No.110フックで止められる失敗と、止められない失敗を分類する
  5. No.111第4部のまとめと、第5部への問い
5

デプロイ・運用・移植

全23回

はじめに

  1. No.112人が見ていない時間に、何をどこまで任せられるか
  2. No.113第5部の後半から主語が「あなた」に変わる

デプロイフローの4世代

  1. No.114「デプロイが怖い」から「任せる」まで何段あるか
  2. No.115デプロイフローの4世代と、世代交代を起こした事故
  3. No.116SSHが切れてデプロイも監視も沈黙した
  4. No.117CIを一度殺して、必要な分だけ再誕させた
  5. No.118文書 → 事故 → 機械化 → 抜け穴 → 再明文化

監視と自己修復

  1. No.119「動いているはず」を、どう検知可能にするか
  2. No.120アラートは本当に鳴るのか、わざと壊して確かめる
  3. No.121気づくより、壊れても勝手に直っている方が強い
  4. No.122バックアップが19日間サイレント失敗していた
  5. No.123無人化を支える5層の点検
  6. No.124「複製が健全」と「復旧できる」は別物だった

再現と AI コストの統治

  1. No.125キューに貯めて一括で運ぶバッチデプロイ
  2. No.126バッチデプロイを起動して、見張らずに完了を確認する
  3. No.127AI自身の利用料も監視・上限・バックオフの対象

あなたのプロジェクトへ

  1. No.128月曜日の朝、最初に何をするか
  2. No.129持ち帰る4点セットは書き換えて使う前提
  3. No.130最初に入れるフックは24本ではなく3本でいい
  4. No.131自分のプロジェクトへの移植計画書を書く
  5. No.132書けた移植計画を3つの観点で見直す
  6. No.133全5部の結論は、この3行
  7. No.134失敗は、仕組みに変えれば資産になる