はじめに

ビルドが成功し、テストがすべて通れば完了と判断できるタスクは、一度で検証できます。一方、難しい最適化問題を解くには、変更のたびに評価し、その結果を次の試行に反映する作業を何度も繰り返す必要があります。Codex は現在の出力を確認して採点し、次に何を変えるかを決めます。十分な品質が得られるまで、この手順を繰り返します。

このようなタスクには、進捗を目で確認できるカスタム UI が適しています。Codex に各試行の出力と生成した成果物を記録させます。 アプリでは、Codex が作業を続ける様子を見ながら、対象の成果物やモデルの出力、生成したアセットがどう改善されていくかを確認できます。 そのためには、評価指標を算出し、確認用の成果物を生成するためのスクリプトを Codex に渡します。

評価方法の設計

タスクを始める前に、何をもって成功とするか、その測定方法を決めます。通常は、次の 2 つの評価方法を組み合わせると効果的です。

• 決定論的な評価： 制約違反の有無や、コードで一意に算出できる指標など、スクリプトで直接採点できる項目が対象
• LLM による評価： 類似度、読みやすさ、有用性、全体的な品質など、コードでは厳密に定義しにくい項目が対象。テキストや画像の出力をもとに、LLM が採点基準に沿って評価

主観的な評価が重要な場合は、たとえば Responses API を使ってモデルを呼び出し、スコアを構造化形式で返すスクリプトを Codex に渡します。決定論的な評価は引き続き使い、通常なら人が目で見て判断する部分は、モデルに一貫した基準で評価させます。

評価結果を機械可読な形式で毎回保存し、過去の結果と簡単に比較できるようにしておくと、改善を進めやすくなります。

Codex の終了条件

難しいタスクでは、プロンプトに「改善を続けてください」とだけ書くと、どこで終えればよいか分からず、作業の方向が定まりにくくなります。終了条件を明示しましょう。

たとえば、次のように設定します。

1. 総合スコアの目標値を決めます。
2. LLM による評価の平均スコアにも、別途目標値を設定します。
3. 両方のスコアがそれぞれの目標値を超えるまで作業を続けるよう Codex に指示します。

たとえば、質の高い成果物を目指すなら、総合スコアと LLM による評価の平均スコアがどちらも 90% を超えるまで続けるよう Codex に依頼します。こうすれば、Codex は目標に届いているか、どの項目が足りないか、直近の変更で改善したかを判断できます。

試行ごとの記録

長時間にわたる作業では、チャットのコンテキストだけに頼るよりも、Codex が試行の経過を記録しておく方が、確実に作業を進められます。

ログには次の内容を記録します。

• これまでの最高スコア
• 直近の試行で変更した内容
• 評価結果から見て改善した点と悪化した点
• Codex が次に試す予定の変更

タスクが長時間にわたる場合は、この記録が特に重要です。ログは、作業を再開するときの引き継ぎに使えるほか、今回の実行で Codex が自身の作業をどう評価したかを示す記録にもなります。

ログと成果物の確認

難しいタスクでは、コードの差分と指標の値だけでは判断できないことがあります。Codex に、生成した成果物そのものも確認させましょう。

生成画像やレイアウト、レンダリング結果など、見た目を評価する出力は、Codex に直接確認させます。たとえば、出力が画像としてディスクに保存されている場合は、その画像を過去の最良の結果と比較させるか、所定の採点基準に照らして確認させます。

こうすると、各試行で次のように改善を進められます。

• 評価用スクリプトでスコアを確認
• 成果物を見て、スコアに表れなかった点を把握
• 両方を踏まえて次の変更を決定

この組み合わせは、試行のたびに手探りでコードを変えるよりもはるかに効果的です。

各試行の手順

Codex に、毎回同じ手順で作業するよう依頼します。

1. 現時点のベースラインを評価します。
2. スコアと成果物から、最も大きな問題を特定します。
3. その問題に絞って、変更を 1 つ加えます。
4. 評価を再実行します。
5. 新しいスコアと、変更によって改善したかどうかを記録します。
6. 各スコアが終了条件を満たすまで繰り返します。

毎回この手順を守ることが重要です。一度に多くの変更を加えると、Codex はどの変更がスコアの向上につながったかを判断できません。記録を省くと、作業の結果を信頼しにくくなり、中断後の再開も難しくなります。