AIに仕事を渡すための「工程」がない問題

Claude CodeやCodexを使い始めると、最初は素直に驚く。自然言語で頼めば、ファイルを読み、コードを書き、テストを走らせ、エラーを見て直す。以前なら半日かかった作業が数分で形になる。

ただ、しばらく使うと別の問題にぶつかる。速い。たしかに速い。けれど、方向を間違えると速く間違える。

テストが薄いまま「できました」と返ってくる。既存の設計を見落とす。小さな修正のはずが、関係ないファイルまで触る。レビューしてみると、表面は整っているのに、肝心な前提がずれている。

ここで多くの人が「やっぱりAIは信用できない」と結論を出す。Qiitaに先日掲載されたエンジニア @gaop2560 の記事は、この感覚に対してかなり正確な診断を下している。問題はAIの能力ではなく、AIに仕事を渡す工程がないことだ、と。

人間に仕事を頼む場合でも同じで、「いい感じに全部やって」と言えば、相手が優秀でも事故る。目的、制約、判断基準、確認方法、失敗したときの戻し方が必要だ。AIエージェントも同じ。違うのは、AIは人間よりずっと速く動くので、工程が弱いと失敗も速く広がる点だ。

4つのフロー：Plan・Work・Review・Compound

記事が提案するのは、開発工程を以下の4つに分けるフレームだ。

  • Plan：作らせる前に、仕事を設計する
  • Work：小さく作らせ、実行結果を見ながら進める
  • Review：出てきたものを、人間と別の仕組みで検品する
  • Compound：一度の学びを、次の仕事が楽になる形で残す

注目したいのは、最後が「完了」ではなく「Compound」になっている点だ。普通の開発フローはタスクが終わるとそこで終わりになりがちだが、AIエージェントを使うと同じ種類の失敗が繰り返し起きる。毎回テストを書き忘れる、毎回既存の命名規則を外す、毎回README更新を忘れる──という「毎回」が積み重なると、人間のレビュー負荷だけが増えていく。Compoundはその構造を変えるための考え方だ。

Plan：「書かせる前に観察させる」が鉄則

Planのフェーズで最も効くのは、最初の依頼を実装指示にしないことだ。

記事ではこんな対比が示されている。ダメな例は「検索機能を追加してください」という一文。これだと、AIは検索対象・UI・状態管理・API・テスト範囲・既存設計との関係をかなりの部分で推測して埋める。推測が当たれば速いが、外れれば後始末が重くなる。

代わりに勧められているのは、こういう頼み方だ。

まだ実装しないでください。
このリポジトリを読んで、検索機能を追加する場合に
どのファイルを確認すべきか、どの設計に合わせるべきか、
どんな実装案がありそうかを整理してください。
コード変更はまだしないでください。

「作業」ではなく「観察」を頼む。AIエージェントは頼めばすぐ作り始めるので、人間側が止める役割を持つ。

Planで決める項目として挙げられているのは、目的・非目的・入力・変更範囲・判断基準・テスト・停止条件の7つ。特に「非目的」の明示が効く、と記事は強調する。AIは親切なので、つい周辺まで直しにいく。小さなUI修正のつもりが、コンポーネント構造まで整理し始めることがある。だから「今回はAPIの仕様変更・DBスキーマの変更・デザインシステムの更新はしないでください。必要に見えても提案に留めてください」という一文が事故を大幅に減らす。

もう一つ実務的な指摘がある。Planが安定しない原因のひとつは、前提が毎回消えることだ。昨日のレビューで決めた命名規則、先週の障害調査で分かった危ない依存関係、チームで避けることにした実装パターン──こういったものがAGENTS.mdやCLAUDE.mdに書かれていなければ、次のPlanには戻ってこない。記憶ツールやproject memoryを評価するときも「記憶できますか」では足りない。古い記憶をどう捨てるか、間違った記憶をどう直すか、リポジトリ単位でルールを分けられるか、まで見ないと実務では機能しない。

Work：小さく動かし、実行結果で判断する

Planが通ったらWorkに入るが、ここで大事なのは「薄く一歩進める」切り方だ。記事では、まず実装ファイルだけを変更させて、テストはまだ追加しない、という区切り方が示されている。その後でテストを追加させ、関連テストだけを実行させ、失敗したら「まず原因を1段落で説明してから最小の修正案を出してください」と返す。

このループが重要なのは、AIに「書いて終わり」にさせないためだ。実行して失敗を見る、原因を読む、修正する、もう一度走らせる。このサイクルがあるだけで、AIの出力は仕事に近づく。「すぐ修正せずに原因を説明させる」という一手を入れるだけで、場当たり的な修正が減る。

Workの段落で記事が掘り下げているのが、実行環境の設計だ。ローカルPCで自由にコマンドを打たせると、AIは作業環境に近すぎる。ファイル、環境変数、認証情報、SSH鍵、ブラウザのログイン状態──人間が普段あまり意識しないものにエージェントが触れる。sandboxやリモート実行環境の話がここで出てくる。「この agent は賢いか」ではなく、「この agent は、失敗しても被害が広がらない場所で動いているか」という問いを立てると、実行環境設計の優先度が見えてくる。

Review：全部読むより「見る場所」を決める

AIエージェントを使うと、作業量は増える。自動化するのに増えるのは逆説的に聞こえるが、理由は単純で、作れる量が増えるからだ。

記事が提示するのは5点のレビューチェックだ。

  1. 最初の目的から外れていないか
  2. 変更範囲が広がりすぎていないか
  3. テストが実装の都合に寄りすぎていないか
  4. 既存の設計・命名・責務分担に合っているか
  5. 空状態、エラー、権限、境界条件の見落としがないか

この5点を別のエージェントに投げることもできる。Claude Codeで実装し、Codexでdiffレビューする。Codexで実装し、Geminiで長い文脈の第三者レビューをかける。どの組み合わせでも構わないが、実装した同じ流れのまま「問題ないよね？」と聞かないことが重要だ。同じ文脈に浸かっていると、AIも人間も前提を疑いにくくなる。

記事が引用しているのが、SQLiteのAGENTS.mdだ。「AIが生成したコードをそのまま受け入れるわけではない。一方で、再現可能なテストケースを含むバグ報告は受け入れる」という判断基準が示されている。AIの参加を完全に拒むのではなく、どの形なら価値があり、どの形は危ないかを分ける。これは実務の判断軸として使える。

AIおじさんの見方：これは「プロンプト技術」の話ではない

ここからは読み方の話をする。

この記事の価値は、プロンプトの小技を増やすことではない。AIエージェントを工程に組み込む、という視点の転換にある。多くの「AI活用術」は、どう上手く頼むか、どんな呪文を書くか、という「AIとの対話スキル」の話をしている。が、この記事が問うているのはそこではなく、仕事の流れ全体をどう設計するか、だ。

開発現場で起きていることの構造で見ると、今は「AIがコードを書く」段階から「AIを工程に入れる」段階に移行しつつある時期だと思う。最初の段階ではCopilotやChatGPTで補完・生成が便利、という体験が広まった。次の段階がClaude CodeやCodexのようなエージェント型で、ここでは「動かし続ける」ことができる。ただ、動かし続けられるからこそ、工程設計がなければ速く壊れる。この記事はその移行期の実務感覚を整理したものだ。

実務に落とすと、小〜中規模のチームでこのフレームを使うときの最初のボトルネックはおそらく「Plan」ではなく「Compound」だと感じる。Plan・Work・Reviewは、慣れれば個人でも実践できる。しかしCompoundは、学びを次の入口に戻す仕組み、つまりAGENTS.mdやチェックリストやevalを継続的に育てる文化がないと機能しない。ここはチーム設計の問題になる。

もう一点、期待値の調整として言っておきたい。この記事が提案するフローは、AIエージェントを「万能な実装者」ではなく「人間が判断しやすくなる材料を出す存在」として使う設計だ。AIの出力を完成品として扱わず、再現手順・失敗するテスト・変更候補・diffの論点整理など、「次の判断を楽にする材料」として使う。この距離感は、現時点では正直なところだと思う。AIエージェントが「完成品を出す存在」になるのはもう少し先の話で、今は「人間の判断の質と速度を上げる存在」として設計した方が、実務での失敗が少ない。

次に問題になる論点

記事が第0回という位置づけで、今後Plan・Work・Review・Compoundをそれぞれ掘り下げる予定のようだ。続きで見えてくるはずの論点をいくつか置いておく。

レビューの量的限界。エージェントが並行して動き、PRが増えるほど、人間のレビュー時間は物理的に足りなくなる。5点レビューのフレームは有効だが、「どのPRをどの深度で見るか」の優先付けロジックが次の問いになる。

Compoundの腐敗問題。AGENTS.mdやチェックリストに溜め込んだ「学び」は、プロジェクトが変われば負債になることもある。古いルールが新しい文脈で悪さをするケース、間違った学びがそのまま固定化されるケース──Compoundを「育てる」だけでなく「刈り込む」設計が必要になる。

実行環境の標準化。sandboxや隔離実行環境の話は記事でも出てくるが、小規模チームでこれを整備するコストはまだ高い。この部分のツールやサービスが成熟するかどうかが、「AIを工程に入れる」の普及速度を左右する気がする。

AIエージェントを使い始めた現場の人間が「なんかうまくいかない」と感じているとき、その原因のほとんどはプロンプトではなく工程設計にある。この記事はその診断と処方をかなり地に足のついた形で書いている。続編が楽しみなシリーズだ。

参考元: Claude Code / Codex時代の開発フロー──Plan、Work、Review、CompoundでAIを工程に入れる 第0回（Qiita）