はじめに：「AIが自律的に開発する」というとき、何が動いているのか

AIコーディングエージェントの導入が進み、「AIが自律的に開発を進める」という表現を目にする機会が増えました。

しかし、この表現は具体的に何を指しているのでしょうか。裏で常時プロセスが走っているのか、人が何かを起動しているのか、AIは何を担当しどこで人に戻るのか。導入を検討されている方々からすると、ここが分からないままでは判断ができません。

本記事では、当社が開発で実施しているループエンジニアリングの構成の大枠を紹介をします。各工程や実行担当までお伝えすることで、AI駆動開発実践のお役に立てますと嬉しいです。

なお、個別の設計判断は次回以降で扱い、今回は全体の輪郭を掴んでいただくことを目的としています。

1. 「AI駆動開発だから」で特別な工程はひとつもない
2. 誰が次の工程に進めているのか
3. ループエンジニアリングの中心はどこか
4. 二重のレビューで品質とスピードのバランスを取る
5. 人が実施する3か所と、自動化しないと決めた1か所
6. 緩めるのは簡単、締めるのは難しいから
7. おわりに

1.「AI駆動開発だから」で特別な工程はひとつもない

以下のフローで開発をしています。

［図1］フロー全体図

特別な工程はなく、概ね従来の開発フローと同じです。

AIに任せる範囲を広げても工程の増減はせず、各工程の実行者がAI or 人と変わるだけです。

補助的にAIを使う段階では、人がコードを書き、人がpushし、人がマージします。AIに委譲する段階では、実装からPR作成までをAIが担い、マージだけ人が行います。自律的に回す段階では、ループを回す起動を人が行い、以降はAIが完了まで進めます。

※ 開発におけるAI活用の進化の過程はこちらのブログでも紹介しています。ループエンジニアリングとは？生成AIエージェント時代の「回る仕組み」の設計

品質を維持しつつ、より多くの工程をAIに移譲できるように設計をすることがポイントです。

2.誰が次の工程に進めているのか

当社の構成では起動のトリガーは5種類置いています。

ループスクリプトは常駐プロセスもスケジューラも持ちません。人が起動したときだけ走り、終われば消えます。

3.ループエンジニアリングの中心はどこか

以下図の工程3でループを設計しています。

AIエージェントがコードを生成し、テストを実行し、失敗すれば修正する。これを終了条件まで繰り返します。人が1手ずつ指示を出すことはありません。

ただし、無制限に何でも、何回でも実行できるわけではありません。エージェントがコマンドを実行したりファイルを操作したりする直前に、その操作が危険かどうかを検査する仕組みを入れています。本番環境へのデプロイ、秘密情報を含むファイルの読み取り、メインブランチへの直接pushなどは、実行される前に止まります。

また、危険な操作を検知したとき、止めるのはその操作1件だけで、ループ自体は止めません。その理由はブロックされたエージェントに連携されるため、別の方法を試すか、そこで詰まったことを報告するかは、エージェントが判断します。

ループごと止めてしまうと、些細な操作でも全体が停止し、人が見張る必要が生じます。それでは自動化の嬉しさが享受できないため、止める単位を最小にすることで、自動化と安全の両立を図っています。

4.二重のレビューで品質とスピードのバランスを取る

生成されたコードをどう検査するか。ここは二段構えにしています。

pushの前に1回。使い捨ての作業ツリーを作り、そこで独立したレビューを走らせます。ここでの指摘は参考情報です。マージの正式な判定ではありません。

プルリクエストを作った後にもう1回。こちらはCI上で走り、決定論的なチェック（ビルド、テスト、静的解析）を通した後にAIによるレビューが動きます。マージを止めているのは、このジョブの終了コードです。

なぜ二重にするのか。

前者は、手戻りを早く見つけるためです。CIまで進んでから指摘されるより、pushする前に気づく方が修正コストが低く済みます。

後者は、独立性を担保するためです。CIはプルリクエストごとに新しくチェックアウトした環境で走ります。手元の環境に依存せず、同じ条件で毎回実行される。この独立性があるからこそ、正式な判定として扱えます。

もうひとつ、検査の実体が見つからない場合の挙動も決めています。素通りさせず、停止させます。検査が無いことに気づかないまま進むより、止まって人が気づく方が安全だからです。当たり前のようですが、明示的に設計しておかないと「設定漏れが事故につながる」構成になりがちです。

5.人が実施する3か所と、自動化しないと決めた1か所

どれだけ自動化しても、人の担当内容として残すべき箇所はあります。当社の構成では3つのことを人が実施しています。

1. 停止条件に該当したとき。仕様が不明瞭で判断できない、同じ失敗を繰り返している、リスクの高い変更を含むといった場合は、pushやPR作成を実行する前に止めて人に戻します。
2. ゲートで指摘が出たとき。指摘があれば実装に戻り、修正して再度通します。
3. マージの判断。自動化の度合いによって、全ての差分を人が読むか、決めた観点だけ読むか、読まずに自動でマージするかが変わります。

そして、自動化の対象にしない工程も明示的に決めています。仕様合意がそれです。技術的には要件のたたき台を生成することもできますが、合意そのものは人が行います。ここを機械の判定に委ねると、責任の所在が曖昧になるためです。

自動化の設計とは、どこまで自動にするかを決めることだと思われがちですが、実際にはどこを自動にしないかを先に決めるアプローチも採れます。自動化しない領域を決めていないと、判断ポイントが後から場当たり的に増えてしまうためです。




6.緩めるのは簡単、締めるのは難しいから

ここまでの設計判断を整理すると、共通する考え方があります。

統制から自律へは緩められますが、逆は難しい。最初から自律性を高く設定し、事故が起きてから締めるのは、組織的にも技術的にも困難です。逆に、統制の強い状態から始めて実績を見ながら緩めるのは、比較的容易に進められます。

骨格を変えずに主体だけを移す設計にしているのは、このためです。工程の並びが同じであれば、自動化の度合いを上げても下げても、フローそのものは作り直しになりません。

確実に止めたいものは、コードで保証する。人が判断する箇所をどこに置くかは運用で決められますが、その判断ポイントが確実に発火することは、仕組みとして保証しておく必要があります。運用ルールとして「ここは確認すること」と書くだけでは、忙しい時期に飛ばされてしまいます。




7.おわりに

今回は、当社が実施しているループエンジニアリングの大枠を紹介しました。以下がポイントです。

• 工程は従来と変わらず、変わるのは実行の主体である。
• 起動しているのは常に何かであり、常駐しているものは無い。
• 品質のゲートは二重にあり、正式な判定はCI側にある。
• 人が実施する箇所は3つあり、自動化しない領域は環境構築前に設計しておく。



このくらいの粒度で構造が見えていると、次に詰めるべき論点が具体的になります。

次回は、ループを打ち切るための設計を解説します。

なお、本記事で示した構成は当社の一例です。適した形は、開発組織の規模、既存のレビュー体制、扱うシステムによって変わります。どこから手をつけるべきか整理したい方は、お気軽にご相談ください。