目次

1. はじめに：ループエンジニアリングでまず直面する問題は、品質よりもループが終わらないこと
2. 3種類の終了条件で場合分けをする
3. 品質チェックを成功条件から外した
4. 打ち切りの判断は、回数ではなく失敗の中身を見る
5. 次のアクションに繋がる失敗にする
6. ループが止まったあとの設計が重要
7. 最後のソースコードが、いちばん良いとは限らない
8. おわりに

1.はじめに：ループエンジニアリングでまず直面する問題は、品質よりもループが終わらないこと

ループエンジニアリングの仕組みを構築して、最初に困ることは生成物の品質ではなく、ループが終わらないことでした。

具体的には、実装されたソースコードに対し、テストが通らない。修正する。別のテストが通らない。修正する。...といった往復が続いてしまうことです。そのサイクルを人が監視していれば「筋が悪い」と止められますが、自動でループしている間は気づくことができないため、こういった状態にならないように設計する必要があります。

ループエンジニアリングの解説は、どうループを回すかを語られることが多くあります。しかし、実際に構築してみると、使用し始めることよりも、状態を検知し止めることが重要で難しいことに気づきます。

本記事では、当社で実際に構築している「ループを止める場合の設計」を紹介します。適切に止めることができることで、不必要なコスト上昇を避けることはもちろん、スムーズな後続処理への受け渡しにより、開発期間の短縮にも効果を発揮しています。

2.3種類の終了条件で場合分けをする

ループの終了条件を1種類にせず、複数用意することがポイントです。当社では3つに分けています。

［図1］終了条件の3分類

3つを分けずに「終了条件」として一括りにすると、成功と失敗で後続の処理が異なることに対応できなかったり、失敗を分けた場合でも、「使い切った」「見込みがない」を判断しないと、人に正しい情報が渡せず、判断の労力がかかります。

重要なポイントは停滞検知です。「このまま進めても見込みがなさそう」といった状態を判断し、実行にかかる費用や時間の浪費を避けています。

3.品質チェックを成功条件から外した

当社では、検証を階層ごとに分けており、成功条件に含めるのは下から2層までとしています。

L3を必須にすると、ループが収束しにくくなります。可読性や設計の妥当性はAIに判定させると評価が揺れ、同じコードでも実行のたびに合否が変わるためです。

ただし、L3の検証自体は実行します。結果は参考情報として扱い、通過の条件にはしません。厳しくするほど品質が上がるように見えて、実際には終わらなくなるためです。

なお、L2はできる限り機械判定になるような設計にしています。受入条件とテストケースを紐づけることで、「受入条件を満たしているか」の判定は、テストが通ったかで判断できます。判定を機械的にできるようになると、終了判断の品質が安定します。

4.打ち切りの判断は、回数ではなく失敗の中身を見る

停滞の検知には、失敗の内容を見て判断しています。

同じ失敗を繰り返しているかどうかを判定するために、失敗の署名を作ります。エラーの出力をそのまま比較しても、行番号やタイムスタンプが混ざるため一致しません。ファイルパス、エラーの種別、失敗したテスト名といった要素だけを取り出して正規化し、同じ失敗かどうかを判定できるようにしています。

この署名が一定の範囲内で繰り返し現れたら、停滞と判断して処理を打ち切ります。

停滞の兆候は、大きく3つあります。

• 同じ失敗の署名が繰り返し現れる
• 評価のスコアが一定回数改善しない
• 差分が振動している。直しては戻し、また同じ方向に直す

3つ目は特に厄介です。往復しているので毎回「何かは変わって」おり、単純な差分の比較では検知できません。過去の試行の履歴を保持し、同じ内容の修正を再び試みていないか見る必要があります。

5.次のアクションに繋がる失敗にする

停滞を検知したとき、常に同じ対処をする必要はありません。失敗にはパターンがあり、パターンごとに対処方法が異なります。

［図2］失敗パターンと対処

内容で判断をせず、回数だけで判断をすると、これらすべてが「上限に達しました」という同じ結果になります。それでは、人に渡されたときに情報量が不足し、その後の調査に工数を要します。

そして、停滞パターンの統計は、仕組みを改善するための最良のデータ源でもあります。どの型の失敗が多いかが分かれば、修正すべきはプロンプトなのか、渡している情報なのか、そもそもタスクの分け方なのか...開発のベース部分の改善に活かすことができます。

6.ループが止まったあとの設計が重要

打ち切った後の挙動も設計することが大切です。

人に、打ち切り・ループが止まったことの通知は飛ぶものの、誰が何をするかが決まっていないと、都度人の判断が必要になり、余計な工数がかかります。

当社では、打ち切りの理由ごとに次の動きを定義しています。判定の設計と同じだけ、判定後の設計にも留意することです。

7.最後のソースコードが、いちばん良いとは限らない

打ち切ったとき、手元には最後の試行結果があります。しかし反復改善は単調に良くなりません。例えば、途中の3回目が一番良く、その後の修正で悪化してしまうことも生じます。

そのため、各試行の結果を評価し、その時点で最も良いものを保持するようにしています。打ち切る際に採用するのは、最新ではなくこの最良のものとすることが大切です。

このとき、良し悪しの比較方法にも判断が必要です。複数の指標に重みを付けて合計し、一つのスコアで比較する方法は分かりやすいのですが、テストが1件落ちる代わりに可読性が上がった結果、合計点では改善しているといった事態が起きます。

指標に優先順位を付け、上位の指標から順に比較する方法を採っています。テストの通過数が減っていれば、他がどれだけ良くなっていても悪化と判定します。合計点で誤魔化さないための留意ポイントです。

8.おわりに

ループの打ち切りについて、当社の設計を紹介しました。ポイントは次の4点です。

• 終了条件は3種類ある。成功条件、打ち切り条件、停滞検知を分けて設計する
• 成功条件には、揺れる評価を入れない。判定は機械に寄せるほど安定する
• 失敗は分類できる。パターンごとに次の一手を変える
• 止め方と同じだけ、止まった後の動きを設計しておく

回数の上限は必要ですが、それだけでは足りません。上限に到達する前に見切りをつけられるかどうかが、実用に耐えるかどうかを分けます。

次回は、検証そのものを扱います。ループを回すには、生成物の良し悪しを機械が判定できなければなりません。しかしAIによる評価は、唯一「信頼できない判定器」です。評価する側をどう検証するのか。その設計を書きます。

本記事で示した閾値や分類は当社の一例です。適した設計は、扱うシステムのリスクや既存のテスト資産によって変わります。自社の場合どこから手をつけるべきか整理したい方は、お気軽にご相談ください。