AIに同じ指示を繰り返すのをやめた。Issue駆動開発という最小運用

AIコーディングエージェントを使うほど、コードを書く以外の仕事が増えるという問題提起から始まる。「前回どこまでやったか」「この修正は本当に終わったか」「CIは通ったがproductionは大丈夫か」。実装を自動化しても、これらを毎回人間が思い出して指示していては、人間の頭は空かない。筆者は変更ごとにGitHub Issueへ「Goal（何を実現するか）」「Done when（何が成立したら終わりか）」「Do not（何をしないか）」「Verify（何で確認するか）」の四項目だけを書くことにした。すると、agentへの指示はかなり短くできる。agentはそのIssueを監査し、Done条件が未達なら原因を直して再検証し、成立したらCloseする。

面白いのは、Issueを「現在の仕様書」ではなく「短命な変更契約」として扱う発想だ。Spec-Driven Developmentの仕様書は、実装後に捨てるか、維持するか、正本にするかで悩みがちだが、筆者は多くの変更で寿命を短くした方が楽だったという。Issueは今回の変更の契約、Closed Issueは変更履歴、mainはリポジトリの現在状態、productionは利用者から見える現在状態、と役割を分ける。Closeすることで、そのIssueは未来の実装と同期し続ける責任から解放される。古くならない文書を作るのではなく、古くなってよい文書を割り切るわけで、ここは本当に腹落ちする整理だ。恒久的に守りたいものだけをテスト、スキーマ、CIへ移すという考え方も、同じ割り切りの延長にある。

もう一つ膝を打つのは、失敗をIssueに戻す流れだ。失敗する、Issueに証拠が残る、原因を直す、固定したDone条件で再検証する、成立したらCloseする。この循環なら、失敗のたびに人が新しいプロンプトを書く必要はなくなる。筆者はこれを、人間が「次の細かい指示」から降りるための仕組みと位置づけている。人間に残すのは、価値判断、優先順位、公開、削除のような重要な判断でよいという。

中小企業の実務に効くのは、社内のIT依頼や業務改善の依頼を「目的・完了条件・やらないこと・確認方法」の四行で書く習慣だ。AIに頼むときも、社員や外注先に頼むときも、完了の定義を先に書いておけば、「やったつもり」による手戻りは確実に減る。