はじめに

一度で簡単に検証できるタスクもあります。ビルドが通り、テストが成功すれば完了です。一方、解決が難しく、評価ループを細かく何度も繰り返す必要がある最適化問題もあります。進むべき方向を判断するために、Codex は現在の出力を確認して採点し、次の変更を決め、十分に良い結果が得られるまで繰り返す必要があります。

この種のユースケースでは、Codex に反復ごとの出力と生成された成果物を記録させ、進捗を視覚的に確認できるカスタム UI を組み合わせると効果的です。 対象の成果物、モデル出力、生成アセットが改善されていくのを見ながら、Codex がアプリで作業を続ける様子を確認できます。 重要なのは、評価指標の生成に必要なスクリプトと、確認対象となる成果物を Codex に用意することです。

評価から開始

タスクを始める前に、成功をどのように測るかを定義します。一般に、次の要素を組み合わせるのが最も効果的です：

• 決定論的チェック： 制約違反や、コードで算出する決定論的指標など、スクリプトで直接採点できる項目
• LLM による判定チェック： 類似性、読みやすさ、有用性、全体的な品質など、厳密にコード化しにくい特性について、テキストまたは画像の出力を使ってルーブリックに基づくスコアを付けるチェック

主観的な部分が重要な場合は、たとえば Responses API を使ってモデルを呼び出し、構造化されたスコアを返せるスクリプトを Codex に用意してください。目的は決定論的チェックを置き換えることではなく、そうでなければ人が目視で評価する部分を一貫して判定し、決定論的チェックを補完することです。

評価結果が機械可読で、実行のたびに保存され、経時的に比較しやすい場合に、このループは最も効果を発揮します。

Codex の停止条件

難しいタスクでは、停止時点を示さずにプロンプトで「改善を続けて」とだけ指示すると、作業が本筋から外れがちです。停止条件を明示してください。

実用的なパターンは次のとおりです：

1. 総合スコアの目標値を設定します。
2. LLM 判定の平均スコアには、別の目標値を設定します。
3. 片方だけでなく両方がしきい値を上回るまで続けるよう Codex に指示します。

たとえば、高品質な成果物が目標なら、総合スコアと LLM 判定の平均スコアの両方が 90% を上回るまで続けるよう Codex に依頼します。これにより、タスクの達成状況が明確になります。Codex は、まだ目標を下回っているか、どこに不足があるか、直近の変更が改善につながったかを判断できます。

ループの進捗ログ

長時間にわたる作業では、Codex がチャットのコンテキストだけに頼らずループの記録を残すことで、信頼性が大幅に高まります。

進捗ログには、次の内容を記録します：

• 現時点での最高スコア
• 直前の反復で変更した内容
• 評価で改善または悪化が示された点
• Codex が次に試す予定の内容

タスクが長時間に及ぶ場合、この記録は特に重要です。ログは、タスク再開時の引き継ぎ情報となり、現在の実行についての自己評価記録にもなります。

ログだけでなく成果物も確認

難しいタスクによっては、コード差分と指標の出力だけでは不十分です。Codex は、自ら生成した成果物も確認する必要があります。

生成画像、レイアウト、レンダリング後の状態など、出力が視覚的なものである場合は、Codex にその成果物を直接確認させます。たとえば、出力が画像としてディスクに保存されている場合は、現在の結果をこれまでの最良結果や想定したルーブリックと比較させます。

これにより、ループの効果が高まります：

• 評価スクリプトがスコアを報告する
• 成果物から、スコアでは捉えられなかった点が分かる
• スコアと成果物の両方を根拠に、次の変更を決める

この組み合わせは、評価の合間に手探りでコードを変更するよりも、はるかに効果的です。

反復手順の明確化

Codex には、毎回同じループに従うよう指示します：

1. 現在のベースラインに対して評価を実行します。
2. スコアと成果物から、最も大きな失敗要因を特定します。
3. そのボトルネックに対処する変更を 1 つに絞って行います。
4. 評価を再実行します。
5. 新しいスコアと、変更が改善につながったかどうかを記録します。
6. しきい値を満たすまで続けます。

この進め方を徹底することが重要です。各反復で一度に多くの要素を変更すると、どの案がスコアの改善につながったのかを Codex が判断できません。記録を省くと、作業の信頼性が下がり、再開も難しくなります。