Claude Code 自走開発シリーズ 第2弾
← 前の記事：Claude Code・Codexに動作確認まで自走させる｜ビルド・操作・録画・証跡を残す開発フロー
以前、Claude CodeやCodexに、実装後のビルド、起動、操作、録画、証跡作成まで任せている方法を書きました。
そこまで自動化しても、しばらくは自分が毎回こう指示していました。
「次はこのTaskを進めて」
「Serverが終わったのでWebを見て」
「結果を確認したので次へ進んで」
コードを書く作業はAI側へ移ったのに、自分がずっとTaskを配る係のままでした。
これでは、AIが速くなるほど自分が次の指示を出す回数も増えます。
そこで最近は、この作業も減らしています。
Server、Web、Client、Integrationのように役割を分け、それぞれが正本とTask状態を見て、次に実行できる仕事を判断する形です。
この記事は設定手順ではなく、「AIへ毎回1Taskずつ依頼する以外の使い方もある」という考え方を紹介する記事です。
具体的なbranch / worktree、定期実行、lock、heartbeatなどは後の記事で扱います。
自走 = 完璧なものが自動で完成する、ではありません。
自走は「人の次指示を待たずに工程を進める仕組み」です。
仕様が曖昧なら、技術的には動き、テストも通るのに、欲しかったものとは違う成果物を高速で作ることもあります。
AIを「1Taskずつ依頼する相手」から変える
最初は、1つのチャットへ順番に依頼していました。
Serverを作る
↓
結果を見る
↓
Webを作る
↓
結果を見る
↓
Clientを作る
↓
最後につなぐ
これでも十分便利です。
ただ、AI側の作業が速くなるほど、
結果を読む
次のTaskを考える
指示を書く
実行させる
という人側の制御が目立つようになりました。
そこで、最初から担当を分けます。
実際にやってみると、AIを4つ起動するだけでは何も解決しませんでした。
各担当が次を判断できる状態にします。
自分の担当はどこか
何を正本として読むか
次に実行可能なTaskは何か
何をもって完了とするか
何が起きたら止まるか
モックやPoCでは「全部完成してから接続」しない
この方法が特に使いやすいのが、モックやPoCです。
各構成を順番に完成させると、全体をつなぐのが最後になります。
そこで、まず一連の流れを細く通します。
後から整理すると、vertical sliceに近い進め方です。
一度つながれば、
必要なAPIが足りない
レスポンスがClientで扱いにくい
エラー形式が揃っていない
認証方式が構成に合わない
といった横断的な問題を早めに見つけられます。
自走には3つのモードがある
「自走前にどこまで仕様を作るか」は、いつも同じではありません。
今の運用を後から整理すると、だいたい次の3段階に分かれます。
| モード | 目的 | 仕様の細かさ | AIへ任せる幅 |
|---|---|---|---|
| 探索 | まず動くものを見る | 粗め | 広め |
| 収束 | 決めた完成形へ寄せる | 具体的 | 狭め |
| 本番品質 | 正式採用できる状態へ持っていく | 例外・非機能まで | 厳しく制限 |
最初から「探索モード」「収束モード」「本番品質モード」という名前で設計していたわけではありません。
実際に、まず作って直す時期と、完成形へ寄せる時期でAIへ任せる範囲が変わっていたため、後から3段階に整理しています。
探索モード
モックやPoCでは、安全なbranch / worktreeなどに範囲を限定したうえで、承認待ちを減らし、一度動くところまで一気に作ることがあります。
最低限の目的を決める
↓
自走させる
↓
人が触る
↓
違和感を見つける
↓
仕様を調整する
↓
もう一度自走
ここでは、最初から頭の中の完成形と一致しなくても構いません。
違うものができたことで、欲しい仕様に気づくこともあります。
収束モード
方向性が決まったら自由度を下げます。
SPEC
最終画面イメージ
操作フロー
API契約
TEST
を具体化し、狙った形へ寄せます。
本番品質モード
正式採用へ進む段階では、
性能
セキュリティ
ログ
障害復旧
受入証跡
変更影響
まで含め、重要Gateは人の判断に戻します。
探索では「AIに任せる余地」を残し、収束では「AIに解釈させたくない部分」を固定します。
この2つは矛盾ではなく、開発段階による使い分けです。
最終画面イメージを置くと、UIのブレが減った
UIでは、文章だけで完成形を共有するのは難しいです。
例えば、
見やすい一覧画面にする
主要操作を分かりやすくする
情報を整理して表示する
だけでは解釈の幅が大きくなります。
そこで、
Figma
ワイヤーフレーム
手書きラフ
既存画面のスクリーンショット
参考画面
AIで作ったモック画像
などをTargetとして渡します。
ただし、画像だけでも足りません。
押したときの動作
フォーカス順
0件時
読込中
エラー時
権限不足時
遷移条件
アニメーション時間
はSPECやTEST側に持たせます。
見た目はTarget画像、振る舞いはSPEC / TESTと分けると扱いやすくなりました。
作った後に「違う」と気づけるようにする
事前に作り込んでも、ズレは残ります。
BuildとTESTがPASSしていても、
動く
要件も満たす
でも触ってみると違う
ことがあります。
そのため、完成後のレビューにもズレ検知を入れます。
確認するのはピクセル一致だけではありません。
情報の優先順位
主要操作の位置
画面の密度
操作数
利用シナリオ
最初に決めた目的
まで戻ります。
違和感も、
「なんか違う」
で終わらせず、
UX-001 主要操作に気づきにくい
FLOW-001 完了までの操作数が想定より多い
UI-001 Targetより情報密度が高い
のように記録し、次のSPEC / TEST / Taskへ戻します。
自走の価値は「一発で正解を出すこと」だけではありません。
作る → 触る → 違いに気づく → 仕様を直す → また作るという反復を速く回せることにもあります。
Task間も自走させる
1Taskが終わるたびに、
人が結果を見る
↓
「次へ進んで」と指示する
なら、Task内部は自走していてもTask間は人がつないでいます。
依存関係と停止条件が明確なら、
Task A DONE
↓
依存関係を再評価
↓
次のREADY Taskを選ぶ
↓
開始条件を確認
↓
Task B
まで進められます。
ただし、
仕様判断が必要
重要Gateへ到達
Git状態が想定外
時間・利用量上限
なら止めます。
人の介入を減らすほど、継続条件と停止条件は具体的にします。
人は「毎回の指示」から「判断」へ移る
AI側へ任せやすいものは、
Git状態確認
正本確認
実装
build
test
画面操作
ログ取得
証跡整理
です。
一方、
仕様そのものが妥当か
操作感を許容できるか
アーキテクチャを変えてよいか
本実装へ移るか
リリースしてよいか
は人のGateとして残します。
自走で減らしたいのは、人の判断ではありません。
判断を必要としない「次へ進んで」という指示です。
AIで開発の手間を減らしたいのに、AIへ仕事を配る管理作業が増え続けるのは本末転倒です。
自分が自走化したかった理由は、AIにすべてを決めてもらうためではなく、こうした管理作業を減らすためでした。
複数担当を継続的に動かすと利用量は増えます。
2026年7月時点でClaude CodeはPro / Max、Team / Enterpriseなどから利用できますが、プランや利用上限は変わります。実運用前にはAnthropicの最新情報を確認してください。
まとめ
自走とは、AIに正解を丸投げすることではありません。
担当を決める
正本を用意する
Task状態を持たせる
継続条件と停止条件を決める
探索・収束・本番品質で自由度を変える
完成後にズレを検知する
ことで、人が毎回指示しなくても開発サイクルを回せる範囲を増やす方法です。
そして、実際にこれを動かすと次の問題が出てきます。
複数担当が同じRepositoryで動くとき、どうやって互いの作業を壊さないようにするか。
次の記事では、Server、Web、Client、Integrationを分けるための正本、Task、branch / worktree、API契約を扱います。