この記事は、新しい最適化アルゴリズムを提案するものではないと明言している。問いはもっと絞られたもので、著者によればそのほうが有用だという。すなわち、人がすでに手作業で回していたプロンプトチューニングのプロセスを、エージェントが駆動するループ（ループエンジニアリング）で再現できるか、そして同じ精度にどれだけ速く到達できるか、という問いである。移し替えられるループはおなじみのものだ。推論を実行して正解と比較し、誤ったサンプルを開いてモデルの出力、モデルが述べた推論理由、画像を確認し、なぜ誤ったのかを突き止め、プロンプトの定義や例を書き換え、再評価し、何が効いて何が悪化したかを記録する。これをファッション属性ごとに繰り返すため、著者の報告によれば 1 プロジェクトあたり数週間を費やすこともあったという。
分解は一対一であり、それは意図的なものである。著者がこれまで行っていた 5 つのステップのそれぞれに、/tune として呼び出される Claude Code スキルの構成要素が 1 つずつ割り当てられている。そのうち 4 つはサブエージェント、1 つは単なるスクリプトである。失敗を調べる analyzer、定義と判断のずれを特定する planner、プロンプトを書き換える improver、F1 を再計算する評価スクリプト、そして何が効いて何が効かなかったかを教訓ファイルに追記する retrospector である。著者は教訓ファイルを、人間のチューニング担当者が蓄積していく記憶を意図的に再現したものとして提示している。またスキル自体の SKILL.md は、ループを駆動する以外に何もしないオーケストレーター（115 行で、実質的な処理はエージェントファイルに委ねられている）として位置づけられ、それと並んで、改善の優先順位、採用／却下の判断、停止条件について全サブエージェントが従う単一のポリシーファイルが置かれている。
この分解の根底には、記事全体の土台となる捉え方がある。著者は F1 を損失（どれだけずれているかを示すスカラー）に、モデルが述べる推論理由を勾配（どの方向に動かすべきか）に対応づけており、これによってループは、プロンプトをパラメータとする勾配降下法となる。記事は、LLM の出力を自己改善のシグナルとして用いる既存研究にも同じ考え方が見られると述べ、この設計を著者独自のアイデアとしてではなく、その考え方の応用として慎重に提示している。
要点
- 掲げられた目標は、アルゴリズムを発明することではなく人間の手順を移植することである。この経験から著者が勧めるのは、エージェントの設計はまず自分がそのタスクをどう解いていたかを分解し、それをそのままエージェントに載せるところから始めるべきだということである。また記事は、設計が最初から正しかったわけではなく、ループを回すうちに教訓ファイルや戦略ファイルが積み上がっていったと報告している。
- F1 を損失、モデルの推論理由を勾配として扱い、プロンプトを更新対象のパラメータとする。そのためには、推論ステップが抽出した属性と並べて推論理由を構造化出力として出す必要があり、著者は、そもそもこのシグナルを利用可能にしているのはこの点だと述べている。
- アブレーションは、この捉え方を記事自身が 1 つのタスクで検証したものである。最適化を行うモデルに推論理由を与える場合（条件 A）と与えない場合（条件 B）を比較した。与えない場合のほうが訓練スコアは高かった（イテレーション 7 で 0.8513、対して A はイテレーション 3 で 0.8403）が、テストスコアでは差が開いた。A は 0.8641 に達した一方、B は訓練スコアが最良だった同じイテレーションでテスト 0.7983 にとどまった（B 自身の最良テストスコア 0.8494 はそれより前のイテレーションで出ている）。著者はこれを B が訓練セットに過学習したものと読み、A の優位は、推論理由によって最適化側が視覚言語モデルの考え方をより多く見られたためだとしている。
- 手作業でチューニングしたベースラインがある唯一のタスクでは、自動化されたループが leaf F1 で訓練 0.8403、テスト 0.8641 に達し、人間の 0.8165 と 0.8473 を上回った。しかも出発点の初期プロンプトは、属性の定義を列挙しただけでプロンプトエンジニアリングを一切施していないものだった。著者は、人間側はより多くの情報と試行回数（約 30 イテレーションに加えてドメイン知識）を使えたにもかかわらず上回れなかったと指摘し、このようなループが人間の作業を代替しうることを示唆するものとして提示している。
- 工数は 2 つの粒度で報告されており、その区別が重要である。1 回のチューニングサイクルは約 6 時間から約 2.5 時間（およそ 2.4 倍）に短縮された一方、評価サイクル全体（チューニング、ドメインエキスパートによる定性レビュー、その結果のフィードバックを最大 3 回繰り返すもの）は約 3.5 週間から約 1 週間（およそ 3.5 倍）に短縮された。著者は大きいほうの数値について、イテレーション数の減少と、ドメインエキスパートをめぐる日程調整や待ち時間の両方を反映したものだと説明し、これらの数値は実測値だと述べている。
- スキーマ構造の異なる 3 つのタスクすべてで leaf F1 が改善し、テストで悪化したタスクはなかった。著者は、訓練での最大の改善幅（あるタスクで +34.3%）を、とりわけ良い結果というよりも訓練時のベースラインが異常に低かったことの反映と読んでいる。そして、同じタスクのテスト時ベースラインがはるかに高いこととの差を、難しいサンプルが訓練データの分割に偏っていたためだと解釈している。
- 停止は曖昧にせず定義されている。ループは、すべての feature と leaf の F1 が 0.7 に達する、10 イテレーションに達する、3 イテレーション連続で収束する（leaf F1 の改善が 0.005 未満で、改善した leaf の数に変化がない）のいずれかが最初に起きた時点で停止する。
- 運用して報告された注意点は次のとおり。精度が上がるにつれてプロンプトが着実に長くなったこと。著者が最も注意深く監視したのは過学習であり、最低限でも訓練とテストの分割は用意すべきだと勧めていること。そして、各ループがすべての画像に対して推論を実行するため API 料金が積み上がり、設計の悪いループはバックエンドで推論を実行し続けて、想定外にコストを押し上げかねないこと。
- 著者は、結果は 1 回の実行によるもので繰り返し実行はしていないため、実行ごとのばらつきは評価していないと述べている。今後の課題として、DSPy などの既存フレームワークとの比較、サンプル数の拡大、そしてこの手法を社内ツールとして汎用化することを挙げている。
背景
この記事は、このウィキが ループエンジニアリング の項で記録している転換、つまり良いプロンプトを書くことから、モデルにプロンプトを与えるループを設計することへの転換の具体例である。著者自身もその言葉で述べており、この分野の関心がプロンプトから、エージェントを駆動する仕組みの設計へと一段上に移ったと説明し、エージェントハーネス を、モデルそのものを除いた、モデルを取り巻くすべてのものと定義している。
また、この記事は、エージェント駆動の自己改善に関するこのウィキの他の資料と並ぶ位置にあるが、改善対象が別のモデルのためのプロンプトである点に特徴がある。最適化を行うエージェントは Claude Code で、テスト対象のモデルは Gemini であるため、勾配として読まれる推論理由は、書き換えを行うのとは別のシステムから来ている。著者はこの取り組みを、モデルの出力の正しさを守ることに関する自身の以前の取り組みから一歩進め、今回は精度そのものを狙ったものとして位置づけている。