ループ・エンジニアリングが注目を集めています。技術フォーラムを覗けば、AIエージェントを、巧妙なプロンプトでコーチングするチャットボットのように扱うのはもうやめるべきだと主張する声が至る所で見つかるでしょう。代わりに彼らが提唱しているのは、「ループ」を設計することです。つまり、エージェントが計画、実行、自己検証、そして反復を、私たちが眠っている間に自律的に行えるサイクルを構築することです。その提案は非常に魅力的です。ループが適切に構築されていれば、エージェントは絶え間ない人間の監視なしに軌道を維持し、生の意図を一晩で完成したアウトプットへと変えてくれるからです。
その約束は、理論上は素晴らしいものです。しかし実践においては、ほとんどのエージェントがすでにループを行っています。コードを生成し、コンパイラエラーやテストの失敗を検査し、コードを修正し、再びテストスイートを実行する。この基本的なフィードバックサイクルは新しいものではありません。現在、支持者が求めているのは、より野心的なものです。単なる構文エラーだけでなく、タスク全体を統括する「アウター・ループ（outer loop）」です。しかし、そのアウター・ループの構築こそが困難な部分です。なぜなら、ソフトウェアエンジニアリングが、固定されたルールを持つ閉鎖的なシステムであることは稀だからです。
ループ設計の問題点
製品の目標は混沌としています。「完了（done）」の完璧な定義から始まることはめったにありません。むしろ、開発に没頭している最中に、真の目標に気づくことの方が多いのです。ホワイトボードの上では単純に聞こえた要件が、実際には解決策の形を根底から変えてしまうようなエッジケースを持っていることが判明します。エージェントを硬直したループの中に閉じ込めてしまうと、その硬直性が足かせとなります。ループは、間違っているかもしれないターゲットに対して、ひたすら叩き込みを続けます。さらに悪いことに、柔軟すぎるループは、デッドロックを解消するために、生成できたアウトプットに合わせて密かに目標を変更してしまうことがあります。どちらの結果も有用ではありません。一方は計算リソースを浪費し、もう一方は自信満々にゴミをリリースします。
より深刻な問題は、仕様策定のコストです。ループを無人で実行させたいのであれば、ほぼすべての事態を想定した仕様を書かなければなりません。エージェントは何を正確に変更すべきか？ どの既存の挙動が神聖不可侵であり、維持されなければならないのか？ どのような正確な条件下でエージェントは反復を停止すべきか？ どのリスクが許容され、どの副作用が即時停止をトリガーすべきか？ その文書を作成する作業は、単にエージェントの隣に座ってリアルタイムでタスクを誘導するよりも時間がかかることがあります。検証コストが実行コストよりも劇的に安くない限り、自動化の恩恵は受けられません。つまり、多額の前払いコストを支払っていることになるのです。
ループが真価を発揮する場面
それは、ループ・エンジニアリングが無用であることを意味するわけではありません。それは、汎用的な戦略ではなく、特化したツールであることを意味しています。ループが真価を発揮するのは、検証コストが累積し、成功基準が明確な場合です。これには主に3つの場面があります。
定型的な機械的作業。 シニアエンジニアが引退を考えたくなるようなタスクを思い浮かべてください。特定の順序でアプリケーションを起動する、デプロイUIをクリックして各ステージを確認する、リリース後に既知のエラー文字列をログからgrepする、あるいは設定ファイルがすべての正しいノードに書き込まれたかを検証する、といった作業です。これらのステップは人間にとっては退屈ですが、検証は容易です。ループはプロセスを見守り、再起動のたびにヘルスエンドポイントを確認し、異常の兆候があれば即座にロールバックを行うことができます。人間は依然としてロールアウト計画を定義します。ループは、午前2時の機械のような忍耐強さで、それを単に実行するだけです。
測定可能な最適化目標。 成功が数値で表されるとき、ループは圧倒的な効果を発揮します。p99レイテンシを150ミリ秒未満に下げる。メモリ使用量を20%削減する。ホットパスをPythonからRustに移行し、既存のすべてのユニットテストがパスすることを確認する。ループは変更を生成し、ベンチマークを取り、成果が出たバリアントを保持し、それ以外を破棄することができます。検証が自動化されており、探索空間が広いため、ループがなければ手動レビューの累積コストによって、この作業は非現実的なものになります。目標は固定されており、経路は未知である。これこそがスイートスポットです。
オペレーショナル・プレイブック。 インシデント対応やサポートチケットは、人間がすでに解明しているパターンに従うことがよくあります。特定の種類のプロダクションエラーでは、常に資格情報のローテーションとキャッシュのクリアが必要です。特定のカテゴリのサポートリクエストは、3つの特定の条件が満たされた場合に返金で解決できます。ループはそれらのトリガーを監視してプレイブックを実行し、パターンが崩れたときにのみエスカレーションを行います。ループはプレイブックが正しいかどうかを判断するのではなく、オンコールエンジニアには到底及ばない規模とスピードで、一貫性を強制するだけなのです。
リファレンス設定者ではなく、レギュレーターとして
現在の議論の多くにおいて、極めて重要な区別が見落とされています。ループとは「調整器（レギュレーター）」です。サーモスタットが部屋の温度を72度に保つのと同じように、ループはシステムをあらかじめ決められた目標に沿わせる役割を果たします。しかし、サーモスタットが自ら「72度」を選ぶわけではありません。誰かがまず、それが適切な温度であると決める必要があるのです。
これをソフトウェアに当てはめると、ループ内のエージェントは、一日中バグを修正したり、関数をリファクタリングしたり、パラメータを調整したりすることができます。しかし、どの機能が実際に顧客の役に立つのか、あるいは次のリリースまでにそのバグを修正する価値があるのかを判断することはできません。そうした選択には、ビジネスの文脈、ユーザーの痛み、そして戦略的な優先順位に関する判断が必要です。エージェントは「実行」し、人間は「決定」します。この二つを混同してしまうと、チームは「間違った問題を解決する、見事に最適化されたシステム」を作り上げてしまうことになるのです。
ループ・エンジニアリングは有用ですが、その範囲は限定的です。それは、規律とスピードを持ってマシンを動かす助けにはなります。しかし、どのようなマシンを作るべきか、それは誰のためなのか、あるいは人間的な観点での「成功」とはどのようなものか、といったことを決定してくれるわけではありません。どの機能が重要か、どのリスクが許容できるか、そしていつ目標そのものを変更すべきかといった判断は、あなたに委ねられています。自動的に検証できるほど十分に理解している作業に対しては、ループを構築してください。それ以外のすべてについては、あなた自身が主導権を握り続けてください。
この記事は、Isaac Hagoel氏が「Loop Engineering Minus The Hype」で最初に論じたアイデアに基づいています。さらなるエンジニアリングに関する議論については、Telegramの学習コミュニティにご参加ください。