AIエージェントを使った開発が広がる中で、「ループエンジニアリング」という言葉を見かけるようになってきました。
まだ新しい言葉ということもあり、人によって多少意味は異なりますが、大まかにはAIエージェントが実行・検証・修正を繰り返しながら、ゴールに向かって自律的に作業できる仕組みを設計する考え方と捉えられます。
この記事では、まずループエンジニアリングの一般的な考え方を整理します。
そのうえで、EM兼AI駆動エンジニアとして実際にAIを使った開発を行っている筆者が、
- ループエンジニアリングで本当に重要だと思っていること
- AIに何を任せ、人間は何を作るべきなのか
- どんなタスクと相性がいいのか
について、実務ベースで考えてみます。
ループエンジニアリングとは
ループエンジニアリングとは、AIエージェントに一度指示を出して終わりにするのではなく、実行 → 検証 → 修正 → 再実行というサイクルを繰り返せるように、AIの作業工程そのものを設計する考え方です。
一度きりの指示と、ループを回す指示では、こういう違いになります。
重要なのは、単純に「AIに何度もやり直させること」ではありません。
AIが自分で結果を確認し、次の行動を決定できる状態を作ることがポイントです。
そのためには、
- 何をゴールとするのか
- AIにどこまで操作を許可するのか
- 何をもって成功とするのか
- いつ作業を終了するのか
といった、AIの外側にある仕組みも設計する必要があります。
プロンプトだけでAIを制御しようとしない
ここからは筆者自身の考えです。
ループエンジニアリングでかなり重要だと思っているのが、AIをプロンプトだけで縛ろうとしないということです。
「このファイルは変更しないでください」「この操作は絶対にしないでください」とプロンプトに書くこと自体はできます。
ただ、AIエージェントをある程度自由に動かすのであれば、それだけに依存するのは少し怖いと思っています。
筆者としては、むしろAIにはかなり自由に作業してもらいたいです。その代わり、やってはいけないことは、そもそも物理的にできないようにする。
AIの判断力を細かいプロンプトで縛るよりも、環境やプログラム側で境界線を作るイメージです。
境界線の中では自由に動いてもらう。ただし、境界線の外には出られない。
この状態を作ることが、ループを安定して回すうえでは重要だと思っています。
ループとハーネスはセットで考える
この話は、最近よく使われる「ハーネスエンジニアリング」ともかなり近いです。
AIにループを回してもらうのであれば、そのAIが安全に動ける環境も必要になります。だから筆者は、この2つを完全に別物として考える必要はないと思っています。
実装はAI、答えは人間が作る
もう一つ、筆者がループエンジニアリングで重要だと考えているのが、人間とAIの役割分担です。
かなり極端に言えば、実装はAIに任せ、答えは人間が作る。という分け方です。
例えば、あるAPIを作るとします。
人間が「この関数を作って、この条件分岐を書いて、このライブラリを使って……」と実装方法まで決めるのではありません。
代わりに人間が作るのは、入力と期待する出力のセットです。
AIは実装し、テストし、失敗したケースを確認して修正する。最終的に200件すべてが通るまでループしてもらいます。
人間が実装方法を細かく指定するのではなく、何が正解なのかだけを高い解像度で定義する。ここが重要です。
「答え」に人間の意図を載せる
この方法で、人間の設計意図がなくなるわけではありません。むしろ逆です。
設計意図をコードの具体的な書き方として表現するのではなく、期待する結果として表現することになります。
例えば感情分析APIなら、単純なケースだけでなく、境界ケースも用意します。
どの入力をpositiveと判断し、どこからnegativeと判断するのか。そこにプロダクトとしての考え方が現れます。
つまり、人間がコードを直接書かなくても、テストケースを設計することで、実装に意図を載せることができるということです。
TDDに近いが、もっと「答え」に寄せる
この考え方はTDDにも近く、シナリオテストやE2Eテストとして書いてもいいと思います。
ただ、筆者自身はもっとシンプルに、入力と出力を並べたCSVでも十分だと考えています。
input,expected_output
"今日は最高だった","positive"
"最悪の一日だった","negative"
"最高ですね。もう使いません","negative"
重要なのはテストフレームワークではありません。AIが「現在の実装が正しいのか」を機械的に判断できる答えが存在していることです。
これを100件、200件と用意しておけば、AIにとってかなり明確なゴールになり、200件中200件がGreenになるまで修正するという非常に単純なループを作ることができます。
AI時代は「コードの具体」より「周辺の具体」が重要になる
この考え方を進めると、人間が見る場所も少し変わってきます。
「AIに具体を任せるから、人間は抽象だけ考えればいい」という話ではありません。
むしろ、コードの具体を見なくなる代わりに、それ以外を今まで以上に具体化する。
これが、筆者が考えるAI駆動開発の重要な変化です。
どんなタスクと相性がいいのか
この方法は、すべての開発に使う必要はありません。
特に相性がいいと感じているのは、正解となる実装方法は定義しにくいが、期待する入出力は定義できるものです。
逆に、明確な数式やアルゴリズムで答えを定義できるものについては、この方法はオーバーだと思います。
感情分析の場合、「このアルゴリズムを使えば100%正しい」という数式を人間が最初から書くことは難しいです。
しかし、「この文章ならpositive」「この文章ならnegative」という具体例なら作れます。
そこで人間は大量の具体例を作り、その答えに近づく実装をAIに探してもらう。こういう問題とはかなり相性がいいと思います。
人間の仕事はなくなるのではなく、場所が変わる
AIに実装をほぼ任せると聞くと、「ではエンジニアは何をするのか」という話になります。
筆者の感覚では、エンジニアの仕事が消えるというより、コードを書くことから、正解と境界を設計することへ移動するという方が近いです。
人間が担うのは、
- 何を作るのか決める
- 何を正解とするのか決める
- 正解となる具体例を十分に作る
- AIが触っていい範囲を設計する
- AIが物理的にできない操作を決める
といった部分です。
そして、その範囲の中でAIには自由に実装してもらう。
細かい実装を人間がマイクロマネジメントするのではなく、正解とガードレールを人間が作るイメージです。
まとめ
ループエンジニアリングは、単純にAIへ「成功するまで何度もやって」とお願いするテクニックではありません。
AIが実装 → 評価 → 修正 → 再評価を自律的に繰り返せる状態を作る考え方です。
そして筆者自身は、実務で使ううえでは次の3つが特に重要だと考えています。
AIには自由にコードを書いてもらう。しかし、何が正しいのかは人間が決める。そして、やってはいけないことは環境側でできなくする。
個人的には、この役割分担がかなり重要だと感じています。
AI時代のエンジニアリングは、「どうコードを書くか」だけではなく、AIが正しい答えにたどり着ける場をどう設計するかへと、少しずつ重心が移っているのかもしれません。
