@vivinko

Claude CodeやCodexに「実装して」と頼むだけでは開発が安定しない｜SPEC・PLAN・TASK入門

Last updated at 2026-07-14Posted at 2026-07-10

続編を公開しました

開発ルールや資料の作成・点検・更新までAIへ任せ、人は要件の採否や工程の承認に集中する方法を、個人開発で実際に起きた問題とプロンプトを交えてまとめました。

未実施を完了扱いしない方法、工程ごとの承認、Asset管理、Git監査、別チャットへの引き継ぎ、失敗からルールを改善する方法を紹介しています。

Claude Code・Codexの開発ルールまでAIに作らせる｜手間を増やさず育てたAI駆動開発12ルール

この記事は、AIへ実装を任せる前に、依頼をSPEC・PLAN・TASKへ分ける考え方を紹介する入門編です。

実際のプロジェクトで運用を続けるための共通ルール、レビュー、Git監査、引き継ぎ、ルール改善については、上記の続編で詳しく紹介しています。

「実装は完了しました。テストもすべて成功しています」

AIからそう返ってきたので差分を確認すると、頼んだ画面が既存の画面遷移につながっていない。

対象外だった設定ファイルまで変更されている。
テストは成功しているが、こちらが想定した動作は確認されていない。

Claude CodeやCodexなどのコーディングエージェントを使っていると、こうしたことがあります。

AIがコードを書けないから、という話ではありません。

たとえば、次の一文で実装を依頼したとします。

ログイン画面を追加してください。

一見すると、十分伝わりそうな依頼です。

しかし、実際には次のことが決まっていません。

どの認証方式を使うのか
既存画面からどう移動するのか
入力エラーをどこへ表示するのか
ログイン状態をどこへ保存するのか
既存の設計や命名規則へどう合わせるのか
何をテストすれば完了なのか
今回は何を作らないのか

条件が書かれていなければ、AIは不足している部分を自分で補います。

その判断がこちらの想定と合えば、実装は一気に進みます。合わなければ、追加修正を繰り返すことになります。

変更が小さいうちは、チャットで修正を重ねても大きな問題になりません。

ところが、変更が複数の画面、クラス、設定、テストへ広がると、次第に「どこで認識がずれたのか」が分からなくなります。

問題は、AIへコードを書かせたことではありません。

仕様、実装計画、今回の作業、完了確認を、一度のチャットへ混ぜていることです。

そこで、AIへいきなり実装を頼まず、依頼を次の3つへ分けます。

ファイル	決めること
SPEC	何を実現し、どの状態なら完了か
PLAN	どこを、どの順番で、どう変更するか
TASK	今回、AIが具体的に何を行うか

この記事では、この進め方をSPEC・PLAN・TASK型のAI支援開発ワークフローと呼びます。

この記事の後半には、README.md、SPEC.md、PLAN.md、TASK.mdの最小テンプレートを載せています。

最初から大きな仕組みを作るのではなく、次の機能追加を一つだけ選んで試せる内容です。

前回の記事では、生成AIへ「どのような仕事を任せるか」を整理しました。

生成AIはGoogle検索ではない。SE・リーダーが「部下に頼む仕事」を先に任せる使い方

今回は、その仕事を安定して任せるために、何を残し、どの順番で進めるかを扱います。

前回の記事を読んでいなくても、そのまま読み進められます。

チャットだけで進めると、どこでずれたのか分からない

チャットだけで開発を進めると、依頼、追加説明、修正指示が会話の中へ積み重なります。

次の図では、左側がチャットだけで進めた場合、右側がSPEC・PLAN・TASKを残した場合です。

右側の進め方でも、AIの間違いは起きます。

違いは、原因を次のように分けて確認できることです。

SPECの内容が間違っていた
PLANに変更箇所が抜けていた
TASKの作業範囲が曖昧だった
AIがTASKに書かれた範囲から外れた
実装はされたがテストが不足していた

チャットだけの場合、途中で決めた内容が別の会話へ埋もれます。

新しいチャットへ移ると、どこまで説明し直せばよいかも分かりません。

ファイルとして残しておけば、次のチャットや別のAIへ、現在有効な情報だけを渡せます。

AI開発ワークフローとは何か

今回扱う全体の流れは、次のとおりです。

縦一列では長くなるため、実装前と実装・確認の2段に分けています。

初めて見る言葉もあるため、先に整理します。

用語	この記事での意味
現行確認	現在のコード、画面、資料がどうなっているかを調べること
SPEC	何を実現し、どの状態なら完了かを定める資料
影響調査	変更によって影響する機能、画面、ファイル、既存仕様を調べること
PLAN	どこを、どの順番で、どう変更するかを定める資料
TASK	今回AIへ実行させる具体的な作業
実装後レビュー	予定した変更と、実際のファイルやテスト結果が一致するかの確認
正本	今後はこの内容を正しいものとして参照すると決めたファイル

「コンテキスト」という言葉もAI開発ではよく使われます。

コンテキストとは、AIが回答や作業の判断に使える情報です。会話、コード、仕様書、画像、コマンドの実行結果などが含まれます。

「SPEC・PLAN・TASK型のAI支援開発ワークフロー」は、この記事内で説明のために使う呼び方です。

業界全体で、この工程に完全一致する固有名称が決まっているわけではありません。

広い分類では、仕様を先に明文化して開発を進めるSpec-Driven Developmentに近い考え方です。

ただし、この記事では仕様作成だけでなく、次の運用まで含めます。

現在のコードや資料を確認する
変更の影響範囲を調べる
実装計画を作る
AIへ今回の作業を指定する
実際の変更ファイルを確認する
次回参照する正本を更新する

SPEC・PLAN・TASKは何が違うのか

SPEC、PLAN、TASKは、すべてMarkdownで書けます。

そのため、最初は同じような資料に見えます。

違いは、それぞれが答える質問です。

簡単に言えば、次の違いです。

SPECは完成条件
PLANは変更方法
TASKは今回の作業指示

ログイン機能を例にして、実際に分けてみます。

SPECは、何を正しい状態とするかを決める

SPECでは、何を作るかだけでなく、何を作らないかも決めます。

# ログイン機能

## 目的

登録済みユーザーだけがメイン画面を利用できるようにする。

## 対象

- ログイン画面を追加する
- メールアドレスとパスワードを入力する
- 認証成功時はメイン画面へ移動する
- 認証失敗時は画面内にエラーを表示する

## 対象外

- 新規会員登録
- パスワード再発行
- 外部サービスによるログイン

## 完了条件

- 正しい認証情報でメイン画面へ移動できる
- 認証失敗時にエラーを表示できる
- メールアドレスまたはパスワードが未入力の場合は認証しない

「ログイン画面を追加する」だけでは、画面が表示された時点で完了なのか、実際に認証できて完了なのかが分かりません。

完了条件まで書くことで、実装後に何を確認すればよいかが決まります。

対象外も書く

AIは、依頼をより便利にしようとして、頼んでいない機能まで追加することがあります。

そこで、今回は作らないものも書きます。

対象外を明記しておけば、追加実装が親切なのか、依頼範囲から外れた変更なのかを判断できます。

実装方法は書きすぎない

SPECは、何を正しい状態とするかを決める資料です。

現行コードを確認する前から、クラス名やメソッド名まで固定すると、既存設計と合わないSPECになることがあります。

実装方法は、次のPLANで決めます。

PLANは、どこをどう変更するかを決める

PLANでは、SPECを現在のプロジェクトへどのように組み込むかを整理します。

# 実装計画

## 現行確認

- 起動時はメイン画面を直接表示している
- 認証処理を行うサービスは存在しない
- 画面はMVVM構成で作られている

## 実装手順

1. 認証処理を行うサービスを追加する
2. 認証サービスの単体テストを追加する
3. ログイン画面とViewModelを追加する
4. 起動時の遷移先をログイン画面へ変更する
5. 認証成功後にメイン画面へ移動させる
6. 正常系、認証失敗、未入力を確認する

## 変更予定ファイル

- `Services/AuthenticationService.cs`
- `Views/LoginView.xaml`
- `ViewModels/LoginViewModel.cs`
- `App.xaml.cs`
- `Tests/AuthenticationServiceTests.cs`

PLANを作る前には、できるだけ現行コードを確認します。

既存の構成を調べずにPLANを作ると、存在しないクラスや設計を前提とした計画になりやすいためです。

ファイル一覧だけでは足りない

変更予定ファイルを書く場合は、なぜ変更するのかも分かるようにします。

たとえば、App.xaml.csとだけ書くより、「起動時の遷移先を変更する」と書いた方が、実装後レビューで確認しやすくなります。

TASKは、今回AIへ何を実行させるかを決める

TASKは、AIが今回行う作業です。

SPECとPLANの内容をすべてコピーする必要はありません。

参照する資料と、今回の作業範囲を指定します。

# 今回の作業

## 参照する資料

- README.md
- docs/SPEC.md
- docs/PLAN.md

## 実施内容

- SPECとPLANを読んでから実装する
- PLANの順序に沿ってログイン機能を追加する
- 既存の命名規則とMVVM構成へ合わせる
- 必要な単体テストを追加する
- ビルドとテストを実行する

## 実施しない内容

- 新規会員登録
- パスワード再発行
- 外部サービスによるログイン
- SPECにない設計変更

## 完了時の報告

- 変更したファイル
- ファイルごとの変更内容
- ビルド結果
- テスト結果
- 未完了または確認できなかった項目

TASKには「何をするか」だけでなく、「何を報告するか」も書きます。

AIから作業結果を受け取ったあと、実際の変更内容を確認するためです。

AIが「完了しました」と報告したことと、実際に作業が完了していることは別です。

完了判定は、変更ファイル、差分、ビルド結果、テスト結果を確認して行います。

影響調査は、PLANを作る前に変更範囲を確認する

小さな修正であれば、影響調査を独立した資料にする必要はありません。

複数の画面、クラス、データ、設定へ変更が広がる場合は、PLANの前に影響範囲を整理します。

ログイン機能なら、次のような観点があります。

観点	確認する内容
画面	ログイン画面、メイン画面、画面遷移
処理	認証サービス、ViewModel、入力チェック
データ	ログイン状態、設定、セッション
共通機能	エラー表示、ログ出力、DI
テスト	認証テスト、画面遷移、既存テスト
資料	README、現行仕様、操作方法

この段階では、実装を始めない方がよい場合があります。

AIへ調査だけを依頼するなら、次のように書けます。

README.mdと現行仕様を読んだうえで、ログイン機能に関係するコードを確認してください。

この段階ではファイルを変更しないでください。

次を整理してください。

- 現在の起動画面と画面遷移
- 認証に利用できそうな既存処理
- 変更が必要になりそうなファイル
- 既存の命名規則
- テストへの影響
- 不明点

確認できた事実と、推測した内容を分けてください。

AIが出した影響調査も、そのまま正しいとは限りません。

関連ファイルの見落としや、存在しない構成を前提とした説明がないかを確認します。

実装後レビューでは、予定と実ファイルを比べる

実装後レビューでは、AIの作業報告を読み直すだけでは不十分です。

次の3つを一つのレビューへ集め、完了か残修正かを判断します。

確認する内容は次のとおりです。

SPECの完了条件を満たしているか
PLANに書いた変更が行われているか
PLANにないファイルが変更されていないか
予定外の変更には理由があるか
ビルドが成功しているか
必要なテストが実行されているか
未確認項目を完了扱いにしていないか

実装したAIへレビューも依頼できます。

その場合は、作業報告を要約させるのではなく、実ファイルをもう一度確認させます。

作業報告だけを根拠にしないでください。

SPEC、PLAN、現在の実ファイル、Git差分、テスト結果を確認し、予定した変更と一致しているか判定してください。

未変更、未テスト、確認不能な項目は完了扱いにしないでください。

どのAIで使えるのか

このワークフローは、Claude CodeやCodexだけのものではありません。

適用しやすさは、製品名よりも次の条件で決まります。

プロジェクト内のファイルを読める
複数のファイルを編集できる
Markdownの指示書を参照できる
コマンドやテストを実行できる
変更差分を人が確認できる

大きく分けると、次の3種類があります。

分類	適用のしやすさ
ファイルを読み、編集やコマンド実行まで行えるコーディングエージェント	一連の工程を適用しやすい
IDE内のエージェント型支援	IDEを中心に適用しやすい
通常のチャットAI	SPECやPLANの作成には使えるが、ファイルの受け渡しを人が補う必要がある

代表的なツール

以下は2026年7月時点の公式情報を基に整理しています。

製品名、提供状態、設定ファイル名は今後変更される可能性があります。

ツール	プロジェクト指示の例	適用の目安
Claude Code	`CLAUDE.md`	ファイルの読取・編集・コマンド実行ができ、そのまま適用しやすい
OpenAI Codex	`AGENTS.md`	リポジトリ内の指示を参照しながら適用しやすい
GitHub Copilot	`.github/copilot-instructions.md`、`AGENTS.md`など	IDEやGitHubを中心に適用しやすい
Gemini CLI	`GEMINI.md`	ローカルファイルとコマンドを扱える環境で適用しやすい
Gemini Code Assist	Agent mode	提供状態を確認したうえでIDE内に適用できる
Cursor	Project Rules、`AGENTS.md`	AgentやPlan Modeと組み合わせやすい
Kiro	Specs、Steering	仕様、設計、タスクを扱う仕組みと相性がよい
Devin Desktop	`AGENTS.md`、`.devin/rules/`	エージェント機能を使って適用できる
Cline	Rules	ファイル編集とターミナル実行を含めて適用できる
Roo Code	`.roorules`、Custom Instructions	モードやツール権限と組み合わせて適用できる
Aider	`CONVENTIONS.md`など	対象ファイルと参照資料を明示して適用できる

通常のChatGPT、Claude、GeminiなどのチャットAIでも、SPEC、PLAN、TASKの作成やレビューはできます。

ただし、ローカルファイルへ直接アクセスできない使い方では、次の作業を人が行います。

必要なコードや資料をAIへ渡す
AIが作ったSPECやPLANをプロジェクトへ保存する
実装結果のファイルや差分をもう一度AIへ渡す
最終結果を人が確認する

Plan Mode、Rules、Custom Instructions、Memoryなどは、開発手法ではありません。

今回のワークフローを実行しやすくする、各ツールの機能です。

この方法のメリット

このワークフローを導入しても、AIの能力そのものが上がるわけではありません。

変わるのは、AIへ渡す判断材料と、人が確認する場所です。

毎回すべてを説明し直す負担を減らせる

プロジェクトの目的、起動方法、命名規則などをREADMEや共通ルールへ残せば、新しいチャットで同じ説明を最初から書き直す負担を減らせます。

AIごとの回答のぶれを抑えやすい

AIやモデルを変えると、同じ依頼でも実装案が変わります。

SPECで完成条件、PLANで変更方針を決めておけば、実装方法が多少違っても、確認する基準をそろえられます。

変更対象と対象外を分けられる

SPECへ対象外を書けば、頼んでいない機能や設計変更が入りにくくなります。

完全に防げるわけではありませんが、範囲外の変更を発見しやすくなります。

複数ファイルの変更を追いやすい

PLANへ変更予定の画面、クラス、設定、テストを書けば、実装後に予定と実ファイルを比較できます。

ファイルが変更された理由も追いやすくなります。

別のAIや別チャットへ引き継ぎやすい

会話の全文を渡すよりも、現在有効なSPEC、PLAN、TASKを渡した方が、次のAIが状況を把握しやすくなります。

人へ引き継ぐ場合にも使えます。

実装前に考慮漏れを見つけやすい

PLANを作る段階で、画面だけではなく、データ、設定、既存仕様、テストへの影響を確認できます。

実装後に不足へ気づくより、計画時点で見つけた方が手戻りを小さくできます。

人とAIの担当範囲を分けやすい

AIへ任せやすいこと	人が判断すること
現行調査の補助	開発の目的
SPEC案の作成	要件の確定
PLAN案の作成	優先順位
コード実装	案の採否
テスト実行	最終レビュー
差分の整理	正本の確定

AIが資料を作っても、その内容を正しいと確定するのは人です。

デメリットもある

この方法は、すべての開発へ適用すればよいものではありません。

最初に資料を作る手間がかかる

すぐにコードを書き始める場合と比べると、SPECやPLANを確認する時間が増えます。

手戻りが大きくなりやすい変更では効果がありますが、数分で終わる修正では割に合わないことがあります。

小さな修正では工程の方が重くなる

ラベルの誤字修正だけで、現行確認、SPEC、影響調査、PLAN、TASK、実装後レビューをすべて作る必要はありません。

工程を省略できない運用にすると、テンプレートを埋めることが仕事になります。

文書が増えると、どれが正しいか分からなくなる

次のようなファイルが並ぶと、人もAIも参照先を判断できません。

SPEC.md
SPEC_修正版.md
SPEC_最終版.md
SPEC_最終版2.md

次回参照する正本を一つに決め、古い資料や中間資料を整理する必要があります。

AIが形式だけを整えることがある

見出しがそろったSPECやPLANでも、現行コードを確認せずに作られていれば使えません。

文章が整っていることと、内容が正しいことは別です。

ワークフローを守っても、正しさは保証されない

SPECが間違っていれば、SPECどおりに実装しても失敗します。

PLANに影響箇所が抜けていれば、TASKを守っても修正漏れが残ります。

資料を増やすほど安全になるわけではありません。

次の作業で本当に参照する資料だけを残すことが重要です。

最初は4ファイルで十分

最初から複雑なフォルダ構成や大量のテンプレートを用意する必要はありません。

まずは、次の構成で始められます。

project/
├─ README.md
├─ docs/
│  ├─ SPEC.md
│  ├─ PLAN.md
│  └─ TASK.md
└─ src/

ファイル	内容
README.md	プロジェクトの目的、起動方法、重要なルール
SPEC.md	何を作り、何を完了とするか
PLAN.md	どこを、どの順番で変更するか
TASK.md	今回AIへ実行させる作業

README.mdの最小テンプレート

# SampleApp

## 目的

社内の申請状況を確認するためのデスクトップアプリ。

## 起動方法

- Visual Studio 2022でSampleApp.slnを開く
- SampleAppプロジェクトを起動する

## 重要なルール

- 既存の命名規則へ合わせる
- UIから直接データベースへアクセスしない
- 作業前に対象ファイルと影響範囲を確認する
- 実装後は変更ファイル、ビルド結果、テスト結果を報告する

READMEには、毎回の作業で必要になる情報を残します。

今回だけの細かな指示をすべてREADMEへ書くと、すぐに読みにくくなります。

SPEC.mdの最小テンプレート

# 機能名

## 目的

この変更によって、何を実現するかを書く。

## 対象

- 今回追加・変更する内容

## 対象外

- 今回は追加・変更しない内容

## 完了条件

- 完了と判断できる具体的な状態

## 未決事項

- まだ決まっていない内容

未決事項は、無理に埋める必要はありません。

決まっていないことをAIに推測させ、決定済みのように扱う方が危険です。

PLAN.mdの最小テンプレート

# 実装計画

## 現行確認結果

- 現在の構成
- 関連する既存処理
- 利用する既存パターン

## 影響する機能・ファイル

- 対象ファイルと変更理由

## 実装手順

1. 最初に行う作業
2. 次に行う作業
3. 最後に行う作業

## テスト方針

- 正常系
- 異常系
- 既存機能への影響

## リスク・未決事項

- 実装前に確認が必要な内容

PLANは、現行コードを確認した結果に基づいて作ります。

存在しない構成を前提としていないか、人が確認します。

TASK.mdの最小テンプレート

# 今回の作業

## 参照する資料

- README.md
- docs/SPEC.md
- docs/PLAN.md

## 実施内容

- 今回AIへ実行させる作業

## 実施しない内容

- 今回変更してはいけない範囲

## 中止・確認する条件

- 仕様と現行コードが矛盾している場合
- PLANにない大きな設計変更が必要な場合
- 対象外の変更が必要になった場合

## 完了時の報告

- 変更ファイル
- ファイルごとの変更内容
- ビルド結果
- テスト結果
- 未完了項目
- 人による確認が必要な点

TASKには、中止条件も書けます。

AIが判断に迷ったとき、勝手に大きな設計変更へ進むのを避けるためです。

すべての変更で全工程を行う必要はない

変更規模に応じて、必要な工程を変えます。

変更規模	基本工程
文言修正、明確な1行修正	直接依頼、またはTASKのみ
小規模な機能修正	簡易SPEC＋TASK
複数ファイルへ影響する変更	SPEC＋影響調査＋PLAN＋TASK
大規模な追加・設計変更	現行確認＋SPEC＋影響調査＋PLAN＋TASK＋実装後レビュー

この表は絶対的な規則ではありません。

小さな変更まで重い工程へ乗せると、実装より資料作成の方が負担になります。

迷った場合は、次の3点で判断します。

完了条件を一文で説明できるか

修正内容と完了条件を一文で誤解なく説明できるなら、SPECを省略できる場合があります。

影響する場所が明確か

変更ファイルが明確で、他機能への影響がほとんどない場合は、影響調査やPLANを簡略化できます。

複数の画面、サービス、データ、設定へ広がる場合は、先に影響を調べた方が安全です。

後日、判断理由を確認する可能性があるか

設計変更や対象外の判断をあとから説明する可能性があるなら、SPECやPLANへ理由を残します。

資料を作らない判断も、ワークフローの一部です。

似ている開発手法

今回の方法だけが、仕様や計画を整理する方法ではありません。

似た考え方との関係を簡単に整理します。

Spec-Driven Development

仕様を先に明文化し、その仕様を基準として設計や実装を進める考え方です。

GitHubのSpec Kitは、仕様、実装計画、タスクへ分けてコーディングエージェントへ渡す流れを提供しています。

KiroのSpecsも、要求、設計、実装タスクを段階的に扱います。

今回の方法に最も近い考え方です。

ただし、この記事では仕様作成だけでなく、現行確認、影響調査、実ファイルによる実装後確認、正本更新まで含めています。

Requirements-Driven Development

利用者要求や業務要求を起点に、設計や実装へ落とし込む考え方です。

SPECより前に、「誰が何に困っているか」「業務として何を実現するか」を重視する場合に近いものです。

Test-Driven Development

テストを先に書き、そのテストを通す実装を進める方法です。

SPEC、PLAN、TASKの代わりではありません。

PLANで「この機能はテストを先に作る」と決めるなど、実装工程の中で併用できます。

Behavior-Driven Development

利用者や業務から見た振る舞いを、具体例やシナリオで表現する方法です。

「未入力でログインボタンを押した場合、画面内にエラーを表示する」といった受け入れ条件をSPECへ書く際に利用できます。

Docs as Code

仕様書や手順書をMarkdownで管理し、Git、差分確認、レビューなど、コードと近い方法で扱う考え方です。

今回のファイル管理を支える考え方ですが、SPEC・PLAN・TASKという工程そのものを指すわけではありません。

ワークフローは、失敗に合わせて育てる

最初から必要なルールをすべて予測することはできません。

一度使い、起きた失敗を短いルールへ変えます。

たとえば、AIが古い設計書を参照したとします。

失敗：

AIが古い設計書を参照して実装した。

追加するルール：

docs/current/を現行仕様の正本とする。

archive/配下は、履歴確認を依頼された場合を除いて実装根拠にしない。

AIが完了と報告したのに、実際には未変更のファイルがあった場合は、次のようにします。

失敗：

AIは完了と報告したが、一部のファイルが変更されていなかった。

追加するルール：

完了判定は作業報告だけで行わない。

変更ファイル、Git差分、ビルド結果、テスト結果を確認する。
未確認の項目は完了扱いにしない。

失敗するたびに新しい文書を増やす必要はありません。

README、SPEC、TASK、AI向け共通ルールなど、既存の資料へ統合できないかを先に考えます。

まず1機能だけで試す

最初からプロジェクト全体を整理する必要はありません。

次に予定している小さな機能追加を一つ選びます。

SPECへ目的、対象、対象外、完了条件を書く
AIまたは人が現行コードを確認する
PLANへ変更箇所、順番、テスト方針を書く
TASKへ今回の作業と報告内容を書く
AIへSPEC、PLAN、TASKを読ませて実装させる
変更ファイルとテスト結果を確認する
不足していた情報を一つだけルールへ反映する

最初の1回で、完璧なワークフローにはなりません。

実際に使うことで、自分のプロジェクトに必要な資料と、不要な工程が分かります。

まとめ

AI開発ワークフローは、AIが間違えないようにする仕組みではありません。

仕様、計画、今回の作業、実際の結果を分けて、人が確認しやすくする仕組みです。

最初は、次の4ファイルで十分です。

README.md
SPEC.md
PLAN.md
TASK.md

小さな修正では工程を省略します。

複数のファイルや既存仕様へ影響するときに、影響調査や実装後レビューを追加します。

大切なのは、資料の数ではありません。

今回、何を正しい状態とするか
どこをどう変更する予定か
AIへ何を任せるか
実際に何が変更されたか

この4点を比較できる状態にしておくことです。

AIへコードを書かせる前に、まずは次の機能追加を一つ選び、SPEC、PLAN、TASKへ分けてみる。

それだけでも、チャットだけで進めたときとは、実装後の確認しやすさが変わります。

次回は、今回の最小構成から一段進めて、次の内容を扱います。

現行確認と影響調査
正本、変更中資料、過去資料の分け方
実装後レビュー
AIの完了報告を検証する方法
古い資料と中間資料の整理
別のAIや別チャットへの引き継ぎ
失敗からルールを育てる方法

続編：ルールや資料もAIに作らせる

Claude Code・Codexの開発ルールまでAIに作らせる｜手間を増やさず育てたAI駆動開発12ルール

この記事で紹介したSPEC・PLAN・TASKを実際に運用しながら、ルール作成、TEST、Git監査、引き継ぎまでAIへ任せる方法をまとめています。

参考資料

各ツールの機能は、2026年7月時点で公式情報を確認しています。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up