【ITニュース解説】What Happens When an AI Agent Goes Through a Real Development Workflow?

AI駆動開発、つまり人工知能（AI）エージェントがソフトウェア開発の一部を自動で行うという新しいアプローチについて説明する。多くの人はAIがコードを自動で書くことに注目しがちだが、実際に重要なのは、コードが書かれる前と後の工程をどのように設計するかという点だ。この記事では、ある開発チームが構築した具体的なワークフローを通じて、この考え方と実践を見ていく。

このワークフローは「要件定義」「仕様策定」「計画」「テスト」「コード作成」「レビュー」という六つの段階で構成されている。通常と異なるのは、テストがコード作成の前に位置することだ。なぜなら、もしAIがコードを書いてからテストも同じAIが書いた場合、両方に同じ誤解が含まれてしまう可能性があるからだ。そこで、このワークフローでは、まず人間が要件に基づいてテストケースを定義し承認する。この承認されたテストケースが、後でコードが正しく実装されたかを判断する独立した基準となる。開発者の役割は、コードの隅々まで書くことではなく、AIエージェントに何をさせ、何をさせないかを決め、その結果が正しいことをどう証明するかを考えることにシフトする。

まず「要件定義」の段階では、Kanbanボード上のタスク（「ログイン機能の修正」のような一行の記述）を、AIエージェントが実際に作業できる具体的な「作業単位」に変換する。この際、AIが作業するための隔離された環境、すなわち専用のブランチとワークツリー（作業ディレクトリ）が自動で作成される。もし環境作成に失敗した場合は、部分的な状態が残らないよう、全ての作業がロールバックされるという厳格な仕組みが導入されている。また、ブランチ名の生成時には、ベトナム語のような特殊な文字も適切に処理し、読みやすい名前にする工夫が凝らされている。この段階の終わりには、AIエージェントは作業に取り掛かる前に、作業場所と指示ファイルが用意された状態になる。

次に「仕様策定」と「計画」の段階は同時に進行する。仕様策定では、要件定義で得られたタスク記述を、ユーザーの視点からのストーリーと、それぞれのストーリーが満たすべき受け入れ基準（その機能が「完了した」と判断される条件）という構造化された形式に変換する。このとき、曖昧な点を明確にし、実装後に発覚する可能性のある問題を手戻りのコストが低い段階で解決することを目指す。計画段階では、使用する技術スタック、ディレクトリ構造、データモデル、各コンポーネント間の連携方法などを具体的に定義する。これらの計画は、AIがコードを書き始める前に人間のレビューアに提示され、実装の方向性を確認するための具体的な記述として機能する。これらの段階には人間の承認ポイントが設けられており、これにより実装に入る前に仕様や計画の誤りを修正できる。人間がいつ介入し、どこで意思決定を行うべきかという設計は、AI開発会社にとって非常に重要な課題となる。

「テスト」の段階は、前述の通りコード作成の前に来る。仕様に基づいて人間がテストケースを定義し承認する。これにより、テストケースはAIが書いたコードとは独立した「真実の源」となり、AIが生成したコードが、人間の意図を正しく反映しているかを評価する際の確固たる基準となる。承認されたテストケースに基づいて、AIエージェントが実際のテストコードを書き、それが正しく動作するかを確認する。

「コード作成」の段階では、AIエージェントがコードを生成する反復的なプロセスに入る。このプロセスは最大5ラウンドという制限が設けられており、もしそれ以上修正が必要な場合は、自動的に次のラウンドに進まず、人間の介入を促すサインとして扱われる。AIエージェントがコードを変更するたびに、システムは自動でコミットを行い、変更履歴を細かく残す。これにより、過去の任意の時点の状態に復元することが可能になる。また、AIエージェントの自己申告だけでなく、ファイルに残されたチェックボックスのような痕跡も読み取り、独立した方法で作業の進行状況や状態を確認する仕組みがある。これは「監視対象からの自己申告だけを鵜呑みにしない」という原則に基づいている。

このコード作成の段階では、AIの使用にかかるコスト（特に、AIモデルとのやり取りで消費される「トークン」の量）を最適化するための工夫も凝らされている。一つは、毎回新しいセッションを開始せず、前回のセッションを引き継ぎ、必要な情報だけを「差分」としてAIに送ることで、以前の会話履歴を再送信するコストを削減する。二つ目は、プロンプトの構成を工夫し、頻繁に変わる情報（現在のラウンド数など）をプロンプトの後ろに配置することで、AIのキャッシュが効率的に利用されるようにする。そして最も大きな改善点として、AIエージェントが実行するシェルコマンドの出力が膨大になり、これがトークンコストの大部分を占めることが判明したため、コマンド出力に圧縮層を導入した。これにより、冗長な出力をフィルタリング・要約し、トークン消費量を大幅に削減することに成功した。

最後の「レビュー」段階では、人間のレビューと機械によるチェックが並行して行われる。人間のレビューアは、ステージ4で承認したテストケースを基準に、AIが生成したコードが承認された内容と一致しているかを確認する。もし修正点があれば、インラインコメントとしてAIエージェントに直接フィードバックされ、AIは同じブランチ、同じセッションで作業を続ける。機械によるチェックでは、コードがワークスペースを離れる前に、決定論的なルールに基づいてコードを検査する。例えば、特定の危険なパターンを正規表現で検出したり、AIによるセキュリティレビューが最新のコミットに対して実行されたかを確認したりする。セキュリティレビュー自体の判断を絶対的なブロック条件にはせず、レビューが完了しているかどうかをチェックするという点が重要だ。また、誤検出を避けるために、人間が明確な理由を付けてチェックを上書きできる仕組みも用意されている。これらのチェックを通過したコードは、最終的にリポジトリにマージされ、同時に使用済みとなったワークスペースやブランチは自動でアーカイブ・削除され、手動でのクリーンアップ作業を不要にする。

現在のところ、UI上での承認ボタンが未実装であることや、プランのステータス表示が不十分なこと、AIエージェントが将来のタスクを知らないこと、停止条件の計算ミス、通知機能の不足、不必要なファイルのスキャンによるディスクI/Oコスト、セキュリティガードのカバー範囲の偏り、マージ時の詳細なコミット履歴の欠落など、いくつかの課題が残されていることも明記されている。

しかし、これらの経験から得られた重要な教訓がある。一つは、人間の介入ポイントは開発プロセスの早い段階に置くべきだということだ。仕様策定段階での修正は、実装後に同じ誤解が発見されるよりもはるかにコストが低い。二つ目は、AIエージェントが「完了した」と自己申告するだけではなく、コミット履歴、ファイル内の状態、テスト結果など、独立した証拠に基づいてその状態を検証することの重要性だ。そして三つ目は、AI利用のコストを考える際、AIへの指示（プロンプト）だけでなく、AIが使用するツール（シェルコマンドなど）からの出力が大きな割合を占めることがあるため、その「ツールとの境界」でもコストを測定し、最適化する必要があるということだ。

最終的に、AI駆動開発の真の課題は、より高性能なAIモデルを使うことだけではない。それは、スコープ定義、受け入れ基準の確立、明確な人間による判断ポイントの設定、そして適切な決定論的チェックの活用といった、従来のソフトウェアエンジニアリングで培われた信頼性の高いプラクティスを、AIを組み込んだワークフローにいかに適用するかという、馴染みあるエンジニアリングの問題に集約される。AIは単なるコード生成ツールではなく、開発プロセス全体を再構築し、より効率的で信頼性の高いものにするための手段として捉えられている。