前回の記事を読んでいない方は、先にこちらからどうぞ。今回はその続編にあたる内容です。
AI時代のドキュメント駆動開発
生成AIのコーディングエージェントが登場してから、それなりの年月が経った。その間もモデルの進化は止まらず、2026年に入った頃から「ループエンジニアリング」という言葉を耳にするようになった人も多いのではないだろうか。
これは、人間がコードを書くのではなく、実装 → レビューのサイクルを生成AIが自律的に回し続け、要件を満たすまで実装を継続していく開発スタイルのことを指す。
たしかに、これによって開発効率は飛躍的に向上した。しかしその一方で、ハルシネーションのリスクや、想定以上にコストが膨らんでしまうといった課題も同時に浮かび上がってきている。
そこで本記事では、前回紹介した「AI時代のドキュメント駆動開発」の考え方を土台に、こうしたループエンジニアリング的な開発をDevOpsにどう組み込んでいくかを考えてみたい。
起こりうるリスク：ハルシネーション
これはループエンジニアリングをしていない人でもよく感じることだと思うが、AIとのやり取りを続けていくと、だんだんと方向性がずれていくことがある。
人間がチャットでやり取りをしながらレビューし、実装を進めていく方法であれば、ズレが生じたその時点で気付いて是正できる。しかし、レビューまでAIに任せてしまうと、気づいた時にはすでに手遅れになっている、ということが起こり得る。
どのように対策していくか
ここでの対策として、前回の記事「AI時代のドキュメント駆動開発」を参照してほしい。
つまり、最初にAIに対してロードマップを敷いてあげるということだ。そして、レビューもそのロードマップとの照らし合わせによって行う。
とはいえ、それだけで完全に防げるわけではない。というより、完全に防ぐことは構造上不可能だ。ただし、仕組み次第で発生確率をさらに下げることはできる。
どのようにループエンジニアリングを実務に対応させるか
まず、重要な前提が2つある。
- ループエンジニアリングは、1つのループだけで完結するものではない。その1つのループの中にも、さらに多数のループが存在する。つまり、ループの集合体として捉えること
- できるだけ細分化を行いながら実装を進めること
多くの場合、ループエンジニアリングは「実装 → レビュー」のループをAIが実行するものとして語られている。しかし、私はそれだけでは足りないと考えている。
私が考えるループ構成は、以下のようなものだ。なお、これは機能ごとに回すループであり、全機能の設計が終わってから一括で実装フェーズに入るわけではない。1つの機能につき「フェーズ1→フェーズ2」を一通り回し、それを機能の数だけ繰り返していくイメージだ。
フェーズ1：要件・設計
- 要件定義 → レビューのループ
- 設計 → レビューのループ
ここまでをAIが一通り行い、その後、人間が仕様のレビューを行う。要件・設計を満たしていなければ、再度ループを回す。これを繰り返す。
フェーズ2：実装・テスト
フェーズ1で仕様のレビューを通過したら、次はこちらのループに移る。
- 実装 → レビューのループ
- テスト → レビューのループ
ここまでをAIが行う。このとき、テストカバレッジを示したドキュメントと、実装仕様書を必ず成果物として出力させる。
その後、実装仕様書が設計時点の内容と変わっていないかをレビュー・修正するループを行う。続けて、テストカバレッジの検証を人間が行い、十分だと判断できれば、全体を通したレビューを行わせる。
ここで大事なのは、たとえMVPであっても、できるだけ細かく実装内容を分けてループを回すことだ。
ペアプロとモブプロの違いから考える
この違いを、ペアプログラミングとモブプログラミングの違いに例えて考えてみたい。
ペアプロを行うときは、レビュー係の人間と実装係の人間がそれぞれ存在した。人間同士がレビューしながら実装を進めていく、この構図がそのまま、ループエンジニアリング以前の従来のAIを用いた開発にも当てはまる。つまり人間がレビュー係、AIが実装係という役割分担だ。
一方でループエンジニアリングは、AIに「モブプロ」をさせるようなものだと言える。
とはいえ、AIにチケットを振って作業してもらうと言っても、完全に任せきりにはできない。まずやってほしい範囲を決め、その認識にズレがないよう打ち合わせを行い、その上で実装を進めてもらう。
つまり、これは人間に対して仕事を依頼することと、それほど変わらない。違いがあるとすれば、相手が少し忘れん坊だという程度だ。だからこそ、「相手はAIだから」と特別扱いするのではなく、人間の同僚と同じように扱っていくことこそが、ループエンジニアリングを実務に導入するための条件なのではないかと思う。
ループエンジニアリングをDevOpsにどう対応させるか
これまでDevOpsといえば、CI/CDによって滞りなくリリースを行う、という考え方が主流だった。この方向性自体は今後も変わらないだろう。しかし、開発プロセス自体がループエンジニアリングによって多層化・細分化していく以上、CI/CDの側にも、より細かい粒度のループが求められるようになると考えている。
具体的には、機能ごとのループが完了した時点で、AIが自動的にPRを作成し、小さくデプロイまで回す、という流れを考えている。
さらに言えば、これは実装フェーズだけの話ではない。DevOpsのループには一般的に、Plan → Code → Build → Test → Deploy → Operation → Monitor → Feedback というフェーズがある。この中の「Feedback → Plan」のフェーズにおいても、同じ考え方を活かせるはずだ。つまり、得られたフィードバックが本当にこの実装内容で対応すべきものなのかを、細かく検証するフェーズとしてループを組み込むということである。
ここで重要なのは、Plan・Code・Build・Test・Deploy・Operation・Monitor・Feedbackというそれぞれのフェーズにおいて、「具体的な成果物 → レビュー」という流れをそのまま適用できるという点だ。つまり、単に「実装 → レビュー」という1つの大きなループだけを見るのではなく、DevOpsを構成する各フェーズそれぞれに小さな「成果物 → レビュー」のループを作り、その小さなループの集合体として、DevOps全体という大きなループを回していく。これこそが、ループエンジニアリングをDevOpsへ導入するということの本質ではないかと考えている。
まとめ
ここまで、ループエンジニアリングという新しい開発スタイルと、そこに潜むリスク、そしてDevOpsへの応用について考えてきた。
ループエンジニアリングは、人間がプロンプトを打ち続ける代わりに、AIを自律的に走らせる仕組みそのものを設計するという、開発における抽象度の一段上のシフトだ。効率化の可能性は大きい一方で、レビューまでAIに委ねてしまうと、気づかぬうちに方向性がずれていき、手遅れになるというリスクを構造的に抱えている。
この記事で提案したのは、大きく2つの考え方だ。
1つ目は、ループを「実装 → レビュー」という単一の粒度で捉えるのではなく、要件定義・設計・実装・テストのそれぞれに小さなループを持たせ、それを機能ごとに積み重ねていくという発想だ。前回の記事で紹介した「AI時代のドキュメント駆動開発」でロードマップを敷き、各ループのレビューをそのロードマップに照らして行うことで、ドリフトの発生確率を下げていくことができる。
2つ目は、この「小さなループの集合体」という考え方をDevOps全体にも広げるということだ。Plan → Code → Build → Test → Deploy → Operation → Monitor → Feedbackという既存のDevOpsループの各フェーズに、それぞれ「成果物 → レビュー」の小さなループを組み込み、その集合体として大きなDevOpsループを回していく。機能ごとのループが完了するたびに、AIが自動的にPRを作成し、小さくデプロイまで回す。そうした仕組みが、これからのDevOpsの前提になっていくのではないかと思う。
そして最後に、実務にループエンジニアリングを取り入れる上で私が最も大事だと思っているのは、AIを特別扱いしないことだ。チケットを振り、認識を合わせ、任せた範囲の中で働いてもらう。これは人間の同僚に仕事を依頼するプロセスと、本質的には変わらない。
ループという仕組みそのものは中立であり、それを活かすも殺すも、設計する人間の側にかかっている。ループエンジニアリングをDevOpsに対応させるということは、結局のところ、AIという新しいチームメンバーをどう迎え入れ、どう仕組みの中に位置づけるか、という組織づくりの話でもあるのだと思う。