AI駆動開発のルールを紹介すると、こう思われるかもしれません。
SPEC、PLAN、TASK、TEST、チェックリスト、引き継ぎ資料……。
それを全部人が書くなら、AIを使う前より手間が増えていない？
その疑問は正しいと思います。
人が大量の管理資料を手書きしなければ成立しないのであれば、AIで開発を効率化しているとは言いにくいからです。
私が趣味で開発している個人アプリでは、コードだけでなく、次の作業もAIへ任せています。
- 現行コードと資料の調査
- SPECのたたき台作成
- 影響範囲の抽出
- PLANとTASKへの分解
- TEST項目の作成
- 作業結果のレビュー
- Git差分とリポジトリ状態の監査
- 失敗原因の分析
- 再発防止ルールの提案
- 既存ルールとの重複・矛盾確認
- 引き継ぎ資料の作成
人が担当するのは、すべてを手書きすることではありません。
何を実現するか、どの案を採用するか、どこまでAIへ許可するか、完了として受け入れるかを判断することです。
この記事では、個人開発で実際に起きた問題をAIに分析させながら、少しずつ育ててきた12のルールを紹介します。
この記事の事例は、筆者が趣味で開発している個人アプリで実際に起きた内容を基にしています。
公開に不要なアプリ名、画面名、作業ID、ファイル名は匿名化・一般化しています。業務案件の情報を基にした記事ではありません。
実際には、次のような問題が起きました。
- AIの作業中に未コミット変更が約50ファイルまで増えた
- 「実装完了」と報告されたが、高解像度確認や性能計測は未実施だった
-
TASK-004を依頼したのに、完了済みのTASK-003を再検証し始めた - デザイン採用済みの画像を、生成経路や利用条件の確認前に組み込もうとした
- 新しい処理へ切り替えたあとも、古いfallbackが残り続けそうになった
- 別チャットへ移ったとき、未完了事項や後続作業が抜け落ちそうになった
こうした問題が起きるたびに、人がゼロからルール文を考えたわけではありません。
問題の事実、関連資料、実際の差分をAIへ確認させ、原因と改善案を出させました。
その案を人が確認し、承認した内容だけをAIに反映させています。
この記事には、次のコピペ用プロンプトを掲載しています。
- AI駆動開発のベースを作らせるプロンプト
- 失敗からルール案を作らせるプロンプト
- Git監査と復帰点作成を任せるプロンプト
- 別チャット・別AIへの引き継ぎを作らせるプロンプト
前回の記事
前回は、AIへいきなり実装を依頼せず、SPEC・PLAN・TASKへ分ける基本形を紹介しました。
今回は、その運用を実際に続けたあと、どのように開発ルールをAIと育てているかを扱います。
前回の記事を読んでいなくても、このまま読み進められます。
先に結論：人が作るのは文書ではなく、判断基準
AI駆動開発のベースを作るために、人がすべての資料を手書きする必要はありません。
基本的な役割分担は次のとおりです。
| AIへ任せること | 人が判断すること |
|---|---|
| 現行コード・資料の調査 | 何を実現したいか |
| SPEC案の作成 | 要件として採用するか |
| 影響範囲の抽出 | どこまで変更を許可するか |
| PLAN・TASKへの分解 | その進め方でよいか |
| TEST項目の作成 | 合格条件として妥当か |
| 実装・ビルド・テスト | 実装を受け入れるか |
| 差分・Git状態の監査 | commit・pushを許可するか |
| 失敗原因の分析 | 再発防止が必要か |
| ルールの追加・修正案 | ルールを採用するか |
| 重複・矛盾の点検 | 統合・削除してよいか |
| 引き継ぎ資料の作成 | 次の作業を何にするか |
人が最初に伝える情報は、長い文書でなくても構いません。
たとえば、次のような要望から始められます。
トップ画面を刷新したい。
現在の機能は維持する。
見た目は大きく変える。
他の画面はまだ変更しない。
この要望を基に、AIへ現行調査をさせ、質問を出させ、SPEC案へ整理させます。
人は、AIが作った案を読んで判断します。
AIが案を作る
↓
人が採用・修正・不採用を判断する
↓
承認した内容だけAIが反映する
この役割分担がないと、AIを使うための管理作業が人へ集中します。
ルールもAIと育てる
実際の運用は、次の循環です。
人が行うのは、ルールの文章をゼロから考えることではありません。
AIが出した案に対して、次を判断します。
- 本当に再発防止が必要か
- 特定の一度きりの問題へ過剰反応していないか
- 既存ルールの修正で対応できないか
- 開発を重くしすぎないか
- 今回だけのTASKへ書くべき内容ではないか
- 次回も毎回必要なルールか
個人開発で育てた12のルール
今回紹介するルールは次の12個です。
| No. | ルール |
|---|---|
| 1 | ルールや資料もAIに作らせる |
| 2 | AIへいきなり実装させない |
| 3 | 変更とTASKをIDで管理する |
| 4 | 工程ごとに承認を分ける |
| 5 | 対象外と停止条件を明記する |
| 6 | 現在有効な仕様と過去資料を分ける |
| 7 | 未実施を成功扱いしない |
| 8 | 条件付き合格を認める |
| 9 | AI生成Assetもコードと同様に管理する |
| 10 | 旧処理の削除を独立TASKにする |
| 11 | Git監査と復帰点作成もAIへ任せる |
| 12 | 引き継ぎとルール改善もAIへ任せる |
1. ルールや資料もAIに作らせる
最も重要なルールです。
SPEC、PLAN、TASK、TEST、チェックリスト、ルールファイルを、人が毎回ゼロから手書きする必要はありません。
AIへ現在のコード、既存資料、要望を確認させれば、必要な資料の案を作らせられます。
AIへ作らせられる資料
- 現行調査結果
- SPEC
- 影響調査
- PLAN
- TASK
- TEST一覧
- REVIEW
- Asset台帳
- Gitチェックリスト
- 引き継ぎ資料
- 共通ルール
- 既存ルールの重複・矛盾一覧
- 不要資料の整理案
人が最初に全部を決める必要もない
要件が曖昧な場合は、AIから質問を出させます。
画面を刷新したいが、細かい仕様はまだ決めていません。
現行コードと資料を確認し、仕様を決めるために必要な質問を整理してください。
質問は次の分類に分けてください。
- 目的
- 利用者
- 必須機能
- 見た目
- 操作
- 対象範囲
- 対象外
- 互換性
- 性能
- テスト
- 未決事項
この段階では、ファイルを変更しないでください。
回答後、AIへSPEC案を作らせます。
先ほどの回答と現行調査結果を基に、SPEC案を作成してください。
決定済み、提案、未決事項を混在させないでください。
次の構成にしてください。
- 目的
- 背景
- 対象
- 対象外
- 機能要件
- 非機能要件
- 完了条件
- 未決事項
- 後続変更候補
この段階では実装しないでください。
人が行うのは、SPECを書くことではなく、SPEC案の内容を決定することです。
AI駆動開発のベースを作らせるプロンプト
既存プロジェクトへ初めて導入する場合も、AIにたたき台を作らせられます。
このプロジェクトへ、AIを利用した開発運用の最小構成を導入したいです。
最初にREADME、既存資料、ソースコード、ビルド方法、テスト方法、Git状態を確認してください。
この段階ではファイルを変更しないでください。
次を提案してください。
1. 現在有効な仕様を置く場所
2. 今回の変更資料を置く場所
3. 過去資料を置く場所
4. AIが毎回参照する共通ルール
5. SPEC・PLAN・TASK・TEST・REVIEWの最小テンプレート
6. 承認を挟む工程
7. 小規模変更では省略できる工程
8. 現在のプロジェクト構成と衝突する点
9. 既存資料を移動・変更する必要があるか
10. 最小構成で開始する手順
新しいファイルやフォルダを増やすことを目的にしないでください。
既存構成を活用できる場合は、既存ファイルへの統合を優先してください。
提案を確認し、採用する構成だけを反映させます。
2. AIへいきなり実装させない
資料作成もAIへ任せますが、最初からコード変更までは許可しません。
基本の流れは次です。
要望
↓
現行確認
↓
SPEC案
↓
人が承認
↓
影響調査
↓
PLAN案
↓
人が承認
↓
TASK作成
↓
実装
現行確認をせずに実装させると、次の問題が起きやすくなります。
- 既存の共通処理を重複実装する
- 他機能で使用中のファイルを削除対象にする
- 古い設計を前提に変更する
- 存在しないクラスやファイルを想定する
- 変更してはいけない範囲まで触る
調査もAIに任せる
対象機能に関係する現行コード、仕様、設定、Assetを確認してください。
この段階では、コード、資料、設定、Assetを変更しないでください。
次を整理してください。
- 現在の処理
- 関係するファイル
- 呼び出し元
- 他機能からの利用状況
- 現行仕様と実装の差
- 変更した場合の影響範囲
- 不明点
- 推測した内容
確認できた事実と推測を分けて報告してください。
調査結果を人が全部読み解く必要もありません。
AIへ、重要度と判断が必要な箇所を分けさせます。
調査結果を次の3つへ分類してください。
- 実装前に人の判断が必要
- PLANで対応方法を決めればよい
- 既存パターンに従えばAIが判断可能
判断が必要な理由も書いてください。
3. 変更とTASKをIDで管理する
チャットだけで作業を管理すると、次第に呼び方が曖昧になります。
- 前に頼んだ画面修正
- その次の確認
- 古い処理を消す作業
- 前チャットで残った対応
そこで、変更単位とTASK単位へIDを付けます。
ID案もAIに作らせます。
今回の変更について、既存の命名規則とID重複を確認してください。
次を提案してください。
- 対応内容名
- 変更ID候補
- TASK分割案
- 各TASKの目的
- 前提TASK
- 後続TASK
- 並行実行できるTASK
- 独立させるべき削除・移行TASK
この段階では、作業登録とファイル作成を行わないでください。
たとえば、画面刷新をUIREF001として登録した場合、次のように分けます。
UIREF001
├─ TASK-001 現行確認
├─ TASK-002 共通部品整理
├─ TASK-003 画面実装
├─ TASK-004 高解像度確認
└─ TASK-022 旧処理撤去
完了済みTASKを再実行された
実際に、TASK-004を依頼したとき、AIが完了済みのTASK-003を再検証し始めたことがありました。
その失敗をAIへ分析させ、次のルール案を作らせました。
今回実行するTASKはTASK-004です。
TASK-003は完了済みです。
TASK-003の再実行、再検証、再編集は行わないでください。
TASK-004の開始条件、対象、対象外を確認し、TASK-004だけを実施してください。
IDを付けるだけではなく、次の3点を明記します。
- 今回実行するTASK
- 完了済みのTASK
- 再実行してはいけないTASK
4. 工程ごとに承認を分ける
AIに資料作成を任せる場合でも、資料作成の許可と実装の許可は分けます。
次の承認は別です。
作業登録
SPEC作成
SPEC確定
PLAN作成
PLAN確定
TASK作成
TASK実装
TEST結果
旧処理削除
commit
push
承認状態の表もAIに更新させます。
## 承認状態
| 工程 | 状態 |
|---|---|
| 作業登録 | 承認済み |
| 現行確認 | 承認済み |
| SPEC作成 | 承認済み |
| SPEC確定 | 承認済み |
| PLAN作成 | 承認済み |
| PLAN確定 | 確認待ち |
| TASK作成 | 未承認 |
| 実装 | 未承認 |
| TEST | 未承認 |
| commit・push | 未承認 |
AIへは、現在の承認範囲を確認させます。
作業を始める前に、現在の承認状態を確認してください。
今回許可されている工程と、未承認の工程を分けて報告してください。
未承認の工程へは進まないでください。
承認状態が不明な場合は、推測せず作業を止めてください。
工程ごとの承認は、AIを遅くするための仕組みではありません。
人の判断が必要な境界だけで止め、それ以外の作業をAIへまとめて任せるための仕組みです。
5. 対象外と停止条件を明記する
対象だけを書いても、AIは関連していると判断した範囲まで変更する場合があります。
SPECとTASKには、対象外と停止条件を入れます。
対象外の案も、現行調査からAIへ抽出させられます。
今回の変更に関連するファイルと機能を確認し、次を分類してください。
- 今回の対象
- 今回の対象外
- 後続変更として登録すべきもの
- 他機能で使用中のため変更禁止とすべきもの
- 人の追加承認があれば変更可能なもの
分類理由と根拠となる参照箇所も示してください。
対象外の例
## 対象外
今回の作業では、次を変更しない。
- 対象TASKに記載されていない画面
- 共通設定
- データ形式
- 他機能で使用中の共通処理
- 承認されていないAsset
- 過去のSPEC、REVIEW、TEST証跡
- 後続変更として登録済みの機能
停止条件
## 作業を停止する条件
次のいずれかに該当する場合は、推測で作業を続けない。
- 現在有効な仕様とSPECが矛盾している
- PLANにない大きな設計変更が必要
- 対象外のファイル変更が必要
- データ形式や保存形式の変更が必要
- 他機能へ影響する共通処理の変更が必要
- 利用条件が未確認のAssetを使用する必要がある
- 必須TESTを実行できない
便利な追加機能を思いついたとしても、今回実装してよいとは限りません。
便利かどうかと、今回許可されているかは別です。
6. 現在有効な仕様と過去資料を分ける
AIがプロジェクト全体を検索できても、どの資料が現在有効なのかを必ず正しく判断できるわけではありません。
SPEC.md
SPEC_修正版.md
SPEC_最終版.md
SPEC_最終版2.md
旧SPEC.md
この状態は、人にもAIにも判断しづらい構成です。
そこで、資料の役割を分けます。
.ai-workflow/
├─ AI開発の共通ルール
├─ 作業登録・承認ルール
└─ REVIEW・Git・引き継ぎルール
docs/
├─ 20_現行仕様/
│ └─ 現在有効な機能・設計・制約
│
├─ 30_変更作業/
│ └─ 今回のSPEC・影響調査・PLAN・TASK・REVIEW
│
└─ 90_履歴/
└─ 過去の判断経緯として必要な資料
この整理もAIに行わせられます。
既存資料を確認し、次の分類案を作成してください。
- 現在有効な仕様
- 進行中の変更資料
- 過去の判断経緯
- 重複している資料
- 内容が矛盾している資料
- Git履歴だけで確認できる可能性がある資料
- 削除候補
この段階では、移動・削除・更新を行わないでください。
各資料の分類理由と、判断できない点を報告してください。
ソースコードと仕様が食い違った場合
どちらか一方を常に正しいものとは扱いません。
| 確認したいこと | 基準 |
|---|---|
| 現在どう実装されているか | 実際のソースコード |
| 現在の機能・設計上のルール | 現在有効な仕様 |
| 今回どの状態へ変更するか | 承認済みSPEC |
| 今回どの方法で変更するか | 承認済みPLAN |
矛盾の発見もAIへ任せますが、どちらへ合わせるかは人が判断します。
7. 未実施を成功扱いしない
AIの作業報告で注意しているのが、「すべて完了しました」という表現です。
ビルドが成功しても、手動確認や特定環境での確認が終わっているとは限りません。
あるTASKでは、結果を次のように分けました。
| 確認項目 | 結果 |
|---|---|
| 共通描画処理 | 合格 |
| 基準解像度・日本語表示 | 合格 |
| 基準解像度・英語表示 | 合格 |
| Debugビルド | 合格 |
| Releaseビルド | 合格 |
| 2560×1440での実行確認 | 未実施 |
| 3840×2160での実行確認 | 未実施 |
| 物理4K環境での確認 | 未実施 |
| 描画性能計測 | 未実施 |
| 総合判定 | 条件付き合格 |
未実施は、不合格ではありません。
ただし、合格でもありません。
TEST単位の状態
| 状態 | 意味 |
|---|---|
| 合格 | 条件を満たすことを確認した |
| 不合格 | 条件を満たさないことを確認した |
| 未実施 | 確認していない |
| 対象外 | 今回の確認対象ではない |
| 環境不足 | 必要な環境がなく確認できない |
| 確認不能 | 証跡不足などで判断できない |
TEST一覧の作成もAIへ任せます。
SPECの完了条件、PLAN、変更ファイルを確認し、必要なTEST一覧を作成してください。
各TESTに次を付けてください。
- TEST ID
- 確認内容
- 実行方法
- 合格条件
- 必要な環境
- 自動実行可能か
- 手動確認が必要か
- 証跡
- 未実施時の扱い
実際に確認していない項目は合格にしないでください。
8. 条件付き合格を認める
すべての確認が終わるまで作業全体を不合格にすると、開発が止まる場合があります。
一方で、未実施項目を無視して合格にすると、後から問題になります。
そこで、作業全体では次の状態を使います。
| 状態 | 意味 |
|---|---|
| 合格 | 必須条件を満たし、必要な確認も完了 |
| 条件付き合格 | 現時点の必須条件は満たすが、残確認や制約がある |
| 再承認待ち | 仕様やPLANの変更が必要 |
| 不合格 | 必須条件を満たしていない |
| 保留 | 前提条件や環境が整っていない |
AIには、勝手に総合判定させません。
判定案と根拠を出させます。
TEST結果と証跡を基に、総合判定案を作成してください。
次を分けてください。
- 合格済み
- 不合格
- 未実施
- 環境不足
- 確認不能
- 残リスク
- 後続TASK候補
条件付き合格を提案する場合は、条件と未完了事項を明記してください。
最終判定は確定せず、判定案として提示してください。
人は、判定案を確認して最終状態を決めます。
9. AI生成Assetもコードと同様に管理する
個人アプリでは、背景、ロゴ、ボタン、パネルなどの画像Assetも扱います。
生成AIで作った画像は、見た目がよければそのまま組み込めるわけではありません。
少なくとも次の段階を分けます。
デザイン採用
↓
生成・入手経路確認
↓
利用条件・第三者権利確認
↓
品質確認
↓
runtime利用方法確認
↓
組み込み
デザインとして採用したことと、アプリへ同梱してよいことは別です。
Asset台帳もAIに作成・更新させます。
# Asset台帳
## 基本情報
- Asset ID：
- ファイル名：
- 用途：
- 利用画面：
- consumer：
- 生成日：
- 登録日：
## 生成・入手経路
- 生成サービス：
- 使用プラン：
- 生成方法：
- 元画像の有無：
- 外部素材の有無：
- 加工内容：
## 利用条件
- 商用利用：
- 改変：
- 再配布：
- アプリ同梱：
- 帰属表示：
- 第三者権利：
- 確認根拠：
## 技術情報
- 幅：
- 高さ：
- 色形式：
- 透過：
- ファイル形式：
- SHA-256：
## 状態
- デザイン採用：
- 生成経路確認：
- 利用条件確認：
- 品質確認：
- runtime配置：
- consumer確認：
AIにファイルを検査させ、解像度、形式、透過、ハッシュ、参照箇所を記録させられます。
ただし、利用条件や第三者権利について、根拠が確認できない項目をAIの推測だけで「利用可能」にしないことが重要です。
10. 旧処理の削除を独立TASKにする
AIによる改修では、新しい処理を追加しても、古い処理やfallbackが残りやすくなります。
古い処理をすぐ削除すると、切り戻しづらくなります。
一方で「念のため残す」を続けると、新旧両方を保守することになります。
そこで、旧処理の撤去を独立TASKにします。
削除候補もAIに抽出させます。
新しい処理への参照切替後、旧処理と旧Assetの利用状況を調査してください。
次を分類してください。
- 削除可能
- 他機能で利用中
- consumer不明
- 履歴として残す
- registryやcatalogの同期が必要
- 回帰TESTが必要
この段階では削除しないでください。
参照元、consumer、削除した場合の影響を報告してください。
削除対象と開発履歴を混同しないことも重要です。
過去のSPEC、REVIEW、TEST証跡は、runtimeの旧処理と同じ理由では削除しません。
11. Git監査と復帰点作成もAIへ任せる
ある時点で、未コミットの変更が約50ファイルまで増えていました。
複数TASKの変更、資料更新、生成物、検証ファイルが混在していました。
この状態で次のTASKへ進むと、次の問題が起きます。
- どの変更がどのTASKによるものか分からない
- 不具合が起きても戻す単位がない
- TASK外の変更が混ざる
- 不要な生成物をcommitする
- 個人環境の絶対パスをcommitする
- push済みと思っていた変更がlocalにしかない
Codexなど、ターミナルとリポジトリを操作できるAIを利用している場合、人がGitコマンドを一つずつ入力する必要はありません。
AIへ必要な監査を行わせ、結果を報告させます。
commit前のGit監査
現在のTASKをcommitする前に、リポジトリの状態を監査してください。
必要なGitコマンドや検索コマンドは、自分で選んで実行してください。
次を報告してください。
- 現在のbranch
- HEADのcommit hash
- upstream
- ahead／behind
- stagedファイル
- modifiedファイル
- untrackedファイル
- 未pushのcommit
- merge／rebaseの途中状態
- 今回のTASKに属する変更
- TASK外と思われる変更
- 不要な生成物
- secretや認証情報の疑い
- 個人環境に依存する絶対パス
- commit前に修正すべき問題
この段階ではcommitとpushを行わないでください。
問題がある場合は、対象ファイル、問題、推奨対応を報告して停止してください。
実際に、この監査でC:/Users/...形式の絶対パスを発見し、ファイル名だけを記録する形へ修正したことがあります。
承認後のcommit・push
確認済みの変更のうち、今回のTASKに属するものだけを一つの論理単位としてcommitしてください。
commit後、upstreamへpushしてください。
push後に次を確認してください。
- commit hash
- pushが成功したこと
- localとupstreamのcommit hashが一致すること
- 未pushのcommitがないこと
- staged、modified、untrackedの残件
- working treeがcleanであること
一致しない場合や残件がある場合は、完了扱いにしないでください。
AIには調査と操作を任せます。
人は、次を判断します。
- 今回のTASKに属する変更か
- commit単位として妥当か
- pushしてよいか
- 残件を許容できるか
- 次のTASKへ進めてよいか
12. 引き継ぎとルール改善もAIへ任せる
別チャットや別AIへ移るたび、人が引き継ぎ文を手書きする必要はありません。
現在の資料、実ファイル、Git状態、REVIEWをAIへ確認させれば、引き継ぎ資料を作らせられます。
引き継ぎ資料を作らせる
現在のプロジェクト状態を確認し、別チャットまたは別AIへ渡す引き継ぎ資料を作成してください。
前の作業報告だけを根拠にせず、実ファイル、Git状態、SPEC、PLAN、TASK、TEST、REVIEWを確認してください。
次を含めてください。
- プロジェクトの目的
- 開発環境
- 現在のbranch
- 最新commit hash
- upstream
- 現在有効な仕様
- 対象の変更ID
- 完了TASK
- 条件付き合格
- 未完了TASK
- 未実施TEST
- 既知の問題
- 後続変更
- 変更禁止範囲
- 次に行う作業
- 最初に確認するファイル
引き継ぎ先では、最初から実装を始めず、資料と実ファイルの一致確認から始めるよう明記してください。
失敗からルール案を作らせる
ここが、この記事で最も伝えたい部分です。
問題が起きたとき、人が再発防止ルールを一から書く必要はありません。
今回の作業で、未実施の高解像度確認と性能計測が、完了したように報告されました。
現在のSPEC、PLAN、TASK、TEST基準、作業報告、実ファイルを確認してください。
次を整理してください。
1. 実際に起きたこと
2. どの工程またはルールが不足していたか
3. 同じ問題を防ぐためのルール案
4. 既存ルールの修正で対応できるか
5. 反映すべきファイル
6. 既存ルールとの重複・矛盾
7. 修正前後の差分案
8. ルール追加によって増える手間
9. 小規模変更では省略できるか
この段階ではファイルを変更しないでください。
新しいファイルやルールを増やすことを前提にせず、既存ルールへの統合を優先してください。
人が案を承認したあと、反映もAIへ任せます。
承認した案だけを既存ルールへ反映してください。
新しいルールファイルは作成しないでください。
反映後に次を報告してください。
- 変更したファイル
- 追加した内容
- 修正した内容
- 削除した内容
- 重複を統合した箇所
- 採用しなかった案
- SPEC、PLAN、TASK、TESTへの影響
ルールを増やしすぎない点検もAIに任せる
AI開発の共通ルール、README、SPEC、PLAN、TASK、TEST・REVIEWルールを確認してください。
次を一覧化してください。
- 重複しているルール
- 内容が矛盾しているルール
- 今回だけの指示が共通ルールへ残っている箇所
- 特定機能だけのルールを全体へ適用している箇所
- すでに役割を終えたルール
- 統合候補
- 削除候補
- 短文化できる箇所
この段階では変更しないでください。
削除・統合した場合の影響も報告してください。
AI開発のルールは、増やすだけでは育ちません。
追加、修正、統合、削除の作業までAIに任せ、人が最終判断します。
AIへ任せても、人の承認が必要な理由
AIが資料やルールを作れるなら、そのまま自動反映してもよいように見えます。
しかし、自動採用すると次の問題が起きます。
- 一度の失敗へ過剰適応したルールが増える
- 同じ内容が複数ファイルへ追加される
- 小さな変更まで重い工程が必須になる
- 特定機能の事情が全体ルールになる
- 古い問題への対策が残り続ける
- AIが自分に都合のよい完了条件を作る
そのため、役割を分けます。
AI：事実を調べる
AI：原因と改善案を作る
AI：反映先と差分案を示す
人：採用・修正・不採用を判断する
AI：承認された内容だけ反映する
AI：反映後の矛盾を点検する
人：最終的に受け入れる
人が担当するのは、文章入力ではなく意思決定です。
すべての変更へ12ルールを適用しない
手間を増やさないためには、変更規模に応じて工程を減らすことも重要です。
| 変更規模 | 基本工程 |
|---|---|
| 文言修正・明確な1行修正 | 直接依頼またはTASKのみ |
| 小規模な機能修正 | 簡易SPEC＋TASK＋確認 |
| 複数ファイルの変更 | SPEC＋影響調査＋PLAN＋TASK＋TEST |
| 大規模な刷新 | 現行確認＋SPEC＋影響調査＋PLAN＋TASK＋TEST＋REVIEW |
| Assetを含む変更 | 上記＋Asset台帳＋利用条件・品質確認 |
| 破壊的変更・旧処理撤去 | 上記＋独立TASK＋Git復帰点 |
どの工程が必要かという判断案もAIへ作らせられます。
今回の変更規模とリスクを評価し、必要な工程を提案してください。
次を考慮してください。
- 変更ファイル数
- 影響する機能
- データ互換性
- UI変更
- Asset変更
- 破壊的変更
- 切り戻し難易度
- TEST可能範囲
- 未決事項
- 失敗時の影響
SPEC、影響調査、PLAN、TASK、TEST、REVIEW、Git復帰点のうち、必要なものと省略可能なものを理由付きで示してください。
重い運用を固定するのではなく、事故の可能性に応じて統制の強さを変えます。
まず導入するなら、この5つ
最初から12個すべてを導入する必要はありません。
まずは次の5つで十分です。
- 現在有効な仕様の置き場所を決める
- SPEC・PLAN・TASKの案をAIに作らせる
- 対象外と停止条件を書く
- 未実施を合格扱いしない
- TASK単位でGitの復帰点を作る
そして問題が起きたら、AIへ原因とルール案を作らせます。
小さく使う
↓
問題が起きる
↓
AIが原因を分析する
↓
AIがルール案を作る
↓
人が採否を決める
↓
AIが承認案を反映する
↓
次の変更で効果を確認する
最初から完璧なフォルダ構成やルール集を作るより、実際の問題を基に少しずつ育てた方が、自分の開発に合ったベースになります。
Claude Code・Codexのルールファイルとの関係
Claude CodeではCLAUDE.md、CodexではAGENTS.mdを利用できます。
Codexの公式資料では、AGENTS.mdを作業開始時に読み、プロジェクト固有の指示として利用すると説明されています。
また、繰り返し使う指示をAGENTS.mdへ移し、実際に同じ失敗が起きたときに振り返りと更新を行う運用が紹介されています。
ただし、すべての仕様や変更資料を一つのルールファイルへ詰め込む必要はありません。
| 内容 | 置き場所 |
|---|---|
| 毎回守る短い共通ルール |
CLAUDE.md、AGENTS.mdなど |
| 現在の機能・設計 | 通常の仕様書 |
| 今回の完成条件 | SPEC |
| 今回の変更方法 | PLAN |
| 今回AIへ行わせる作業 | TASK |
| 実際の確認結果 | TEST・REVIEW |
| 過去の判断経緯 | Gitまたは履歴資料 |
これらのファイル作成や更新もAIへ任せ、人が内容を承認します。
まとめ
個人開発で育ててきた12のルールは、次のとおりです。
- ルールや資料もAIに作らせる
- AIへいきなり実装させない
- 変更とTASKをIDで管理する
- 工程ごとに承認を分ける
- 対象外と停止条件を明記する
- 現在有効な仕様と過去資料を分ける
- 未実施を成功扱いしない
- 条件付き合格を認める
- AI生成Assetもコードと同様に管理する
- 旧処理の削除を独立TASKにする
- Git監査と復帰点作成もAIへ任せる
- 引き継ぎとルール改善もAIへ任せる
この記事で最も伝えたいことは、12個のルールそのものではありません。
AI駆動開発のベースを、人がすべて手書きして作る必要はないということです。
コードだけでなく、次のものもAIに作らせられます。
- SPEC
- 影響調査
- PLAN
- TASK
- TEST
- REVIEW
- Asset台帳
- Git監査結果
- 引き継ぎ資料
- 再発防止ルール
- 重複・矛盾の整理案
人が担当するのは、資料を書く作業ではありません。
- 何を実現するか
- どの案を採用するか
- どこまで変更を許可するか
- どの工程へ進めてよいか
- 何を完了とするか
- 次回も残すルールは何か
を判断することです。
「AIの実装完了を信用しない」というのも、AIを信用しないという意味ではありません。
人とAIが、同じ完了条件と証拠を確認できる状態を作るという意味です。
AIを使うための手間を人へ追加するのではなく、開発ルールを作り、点検し、改善する作業までAIへ任せる。
そのうえで、人は意思決定へ集中する。
それが、現在目指しているAI駆動開発です。
この記事のプロンプトやテンプレートは、そのまますべて導入する必要はありません。
自分のプロジェクトで繰り返し発生している手作業を一つ選び、その作業自体をAIへ任せるところから始めるのがおすすめです。
あとでルール改善やGit監査、引き継ぎ用プロンプトを使う場合は、記事をストックしておくと戻りやすくなります。
あわせて読みたい
SPEC・PLAN・TASKの役割と、最初に試せる最小テンプレートをまとめています。
参考資料
製品固有の説明は、2026年7月14日時点の公式資料を基にしています。