第1弾で「AIは地頭が良く自信過剰な新人」という比喩を、第2弾で「ハーネスとの付き合い方」を書いてきました。今回は、AIとどう開発を進めるか、ワークサイクルの話を整理しておきます。
最近、AI-DLC、cc-sdd、GitHub Spec Kitなど、AIとの開発プロセスを支援するフレームワークが増えてきました。それぞれ違ったアプローチで、どう使い分けるかを考えています。
2つのアプローチ
戦略A: AI主体型
PdMやマネージャーがAIを使って、要件定義から実装まで進める。エンジニアの役割を最小化し、AIで開発のスループットを上げようとする。AI-DLCのようなフレームワークと相性が良い。AIがAWSなどのインフラに接続して調査・デプロイまで担う、という発想もある。
ただ、AI-DLCは導入に覚悟がいると言われます。プロセス全体をAI前提で組み直す必要があるし、ロールの再定義、ドキュメント運用の整備、ツールチェーン── 一気に揃えないと中途半端になりがちです。一部のプロジェクトだけ部分導入、というのが難しい性質のフレームワークなので、組織全体の作り変えを覚悟するかどうかの話、と言えそうです。
戦略B: エンジニア主体型
エンジニアがAIをツールとして使い、PMが要件をまとめる(AIを使うこともある)。プロジェクトやケースに応じて、cc-sddやGitHub Spec Kitのようなspec-drivenの仕組みを部分的に取り入れる。リポジトリ内のドキュメントは必要最低限。
どちらも実在する戦略で、それぞれメリットがあります。ただ、戦略Aには構造的に注意したい点がいくつかあるように感じています。
戦略Aへの問題提起
長文ドキュメントのメンテ問題
AI-DLC的なアプローチでは、各フェーズで詳細なドキュメントが生成されます。要件定義書、設計書、仕様書── これらがGitに入る。
問題は、ドキュメントは作るより維持するほうが難しいということ。コードが変わったときに、ドキュメントを更新する仕組みがないと、すぐ古くなります。AIに「ドキュメントを更新して」と頼んでも、全文書き直しに近い差分が出ることがあって、レビュー不能になりがち。
結果として、ドキュメントが残っているけど誰も読まない、実態と乖離している状態になる。「ドキュメントがある安心感」で、実態の理解が遠のくこともあります。
エンジニアを不要にできるか
「エンジニア不要」にできるか、という観点もあります。
短期的には、ハーネス調整、レビュー、AIが詰まったときの突破口、既存システムとの整合性、インシデント対応── これらの仕事は残ります。モデルが進化すれば一部は減るかもしれませんが、判断と責任を伴う部分は最後まで残ると思います。
なので「不要」というより、人数は少なくて済むけど、求められるレベルは上がる、という方向に進むのかなと感じています。定型的な実装はAIに任せて、エンジニアは判断・設計・レビュー・統合に集中する。少人数でも大きな成果を出せるようになる代わりに、コードを書くだけの仕事は減っていく。
そして、「動いている」と「健全に動いている」は違います。性能、セキュリティ、保守性、拡張性── これらはコードを読まないと分からない。読める人を組織に残しておかないと、3年後、5年後に深い負債になりかねません。これは前回の記事でも触れた論点です。
AIに本番権限を渡すこと
AIがインフラに接続できると便利な場面はあります。たとえばログを見たり、状態を調査したりする読み取り権限は、デバッグや障害対応で重宝しそうです。権限を参照のみに縛れば、リスクも限定できる。
一方、書き込み権限(設定変更、デプロイ、データ操作など)を渡すのは、設計次第ではアリですが、設計を省略して権限だけ渡すのは危険かなと思います。デプロイなどは、GitHub Actionsで自動化したものを人間がトリガーする形が、当面は現実的かもしれません。
何を、どこまで、どんな条件で実行できるか。不可逆な操作に人間ゲートはあるか。ロールバック手段は確立されているか。監査ログは取れているか── これらが揃わないまま権限だけ渡すと、事故待ちです。
戦略Bの利点と注意点
戦略Bは、エンジニアが判断と責任を持つので、コードベースの理解者が組織に残るという利点があります。ドキュメントが軽いので、メンテ負荷も低い。
ただ、注意点もあります。
規模が大きくなると属人化: ドキュメントが少ないと、特定のエンジニアにしか分からないコードになりがち。少人数なら問題にならないけど、人が増えると課題になる。
PMとエンジニアの認識合わせ: ドキュメントが軽いと、口頭で補う必要が出てくる。コミュニケーションコストが上がる側面はある。
AIで効率化できる範囲の取りこぼし: エンジニア主体だと、AI-DLC的な「要件定義をAIと進める」「ドキュメント自動生成で省力化」みたいな部分の恩恵を取りこぼすかもしれない。
戦略Aと戦略Bは極端な対比で、実際には間のどこかでバランスを取るのが現実的かなと思います。AI-DLCも、要件を詰める段階で使うなら有効そうですし、cc-sddやGitHub Spec Kitもケースを選べば便利です。
プロセスに合わないタスク
ワークサイクルを考えるとき、タスクの性質も重要な軸です。
たとえば、バグ修正にAI-DLC的なプロセスを当てはめるのは、かなり無理があると思います。バグ修正の特性は、要件は明確(直す)、方針は原因次第(調査しないと決まらない)、治るとは限らない(やってみないと分からない)、というもの。プロセスに乗せて上から順に進める発想と合わない。原因を調査しながら方針が見えてくるので、手元でAIと対話しながら試行錯誤するほうが速い。
しかも、AIは確率的に動くので、同じモデルで何度試しても解けない問題が、別のモデルだとあっさり解けることがあります。プロセスを丁寧に進めるより、色々試して当たりを引くほうが、結果として早いケースもある。
プロセスが合わないのは、バグ修正だけではありません。
- バージョンアップ(依存ライブラリ、フレームワーク): やってみないと何が壊れるか分からない
- リファクタリング: 動作を変えずに構造を改善する作業で、やりながら設計が見えてくる
- パフォーマンスチューニング: 計測しないとボトルネックが分からない
- セキュリティ修正: 影響範囲を調べないと方針が決まらない
- 障害対応: スピード勝負で、プロセスを踏む余裕がない
- POC、プロトタイピング、技術検証: 捨てる前提で、動くものを早く作るのが目的
共通するのは、探索的・試行錯誤型のタスクだということ。要件が定まらない、方針が動的に決まる、結果が予測できない── こういうタスクは、手元でAIと対話しながら進めるほうが合います。
逆に、プロセスに乗せる価値があるタスクは、新機能開発、大規模な改修、複数人で協調するタスク、後で振り返る必要があるタスク、規制対応で記録が必要なタスクなど。マイグレーションのような、失敗時の被害が大きいタスクも、プロセスで慎重に進める価値があるかもしれません。
新機能開発はプロセス、バグ修正は手元で試行錯誤── タスクの性質で使い分けるのが大事かなと思います。
複数人で開発する場合
ここまで個人開発寄りの話をしてきましたが、複数人で進める場合は前提が変わります。
複数人で開発する場合、タスク分割を明確にするのが前提（いつもと同じ）です。誰が何を担当するか、どこに依存があるか、どの順序で進めるか── これが曖昧だと、コンフリクトが起きる、認識がズレる、手戻りが増える。スクラムで大きすぎるタスクを分割するのと同じ発想です。
タスク分割にもAIを使うのが現実的かなと思います。「この機能をどう分けるか、どこに依存があるか」をAIに整理してもらって、人間がレビューする。これは思考の整理として有効ですし、各タスクの入力・出力・成功条件を明確にしておくと、その後の作業が回りやすい。
ただ、ここでも過剰分割は逆効果（いつもと同じ）です。細かく分けすぎると統合のオーバーヘッドが増えるし、各タスクの文脈情報が薄くなる。必要な粒度で分けるのが大事かなと思います。
複数人で進める場合のもう一つの観点は、判断の記録です。手元の対話で進めると暗黙知が流れますが、複数人だとそれを共有する手段が要る。長文ドキュメントは負債になりがちなので、ADR(Architecture Decision Record)のように重要な決定だけ短く残す仕組みがいいのかもしれません(まだ評価できていませんが)。
私の感触
色々考えた結果、私自身は手元でAIと対話しながら進めるスタイルが、今のところしっくりきています。
理由はシンプルで、フィードバックループが短いから。AIが何か出してくる → 違和感があれば即座に指摘 → AIが修正 → また指摘── このループが密だと、自分の頭の中の判断基準が対話の中で明確になっていきますし、ドキュメント化されない暗黙知が大量に流れて、結果的に質の高いコードになる気がしています。
先にドキュメントを作ってから進めるのは、正直手間に感じます。PMから要件をもらうならいいけど、自分で書くのは省略したい。
ただ、これは個人開発と少人数のチーム向けのスタイルです。規模が大きくなったり、複数のステークホルダーがいたり、規制対応が必要になったりすると、もっとプロセスを入れる必要が出てくると思います。そのときは、重要な判断だけADRなどで残すのが、ドキュメント負債を最小化する現実解かなと考えています。
まとめ
AIとのワークサイクルは、タスクの性質、人数の規模、変更頻度、規制要件などで決まる、というのが今の結論です。
- 一律のプロセスはない。タスクごとに使い分ける
- バグ修正、リファクタ、バージョンアップなど、探索的・試行錯誤型のタスクはプロセスより手元の対話が合う
- 新機能開発や大規模改修は、プロセスに乗せる価値がある
- 個人開発・少人数なら対話中心、規模が大きくなったらプロセスを入れる
- ドキュメントは「読まれる範囲」に絞る。長文より、判断の記録(ADRなど)
- AI主体型は便利だが、ドキュメントメンテとエンジニアの役割について考えておきたい
これも振り返ってみると、特に新しい話ではないなと感じます。スクラムでもウォーターフォールでも、適材適所でプロセスを使い分けるのは昔からの話です。AIが入ったことで、ループが速くなり、ドキュメント生成が容易になっただけで、判断の本質はあまり変わらないんじゃないかなと。
道具がAIになっても、プロジェクトの性質を見て、適切なプロセスを選ぶのは、結局のところ人間の仕事かなと思っています。
