WEARの「似合う」判定に使うVLMのプロンプトは、誤答を見て・原因を考えて・直して・再評価して、を特徴の数だけ繰り返す職人芸だった。1プロジェクトに数週間。ZOZOのデータサイエンス部は、この地道な反復をまるごとClaude CodeのSkillに渡してみた——プロンプトチューニングというクリエイティブな作業は、本当にループに落とし込めるのか、という実務レポートを読む。
プロンプトの推論理由（reasoning）を改善の勾配として使うという設計思想と、4つのsub-agentへの分解の仕方。チューニングサイクルが6時間→2.5時間、全体評価が3.5週間→1週間に縮んだ実測値と、人間の判断がどこに残ったかまで。
WEARの「似合う」判定は、全身コーディネート画像から特徴を抽出するVLM（Vision Language Model）のプロンプト精度に左右される。ZOZO TECH BLOG「ループエンジニアリング実践」は、このプロンプトチューニングを「失敗を見る→直す→再評価する」というループとして描く。厄介なのは、アイテム・着こなし・サイズ感などファッション特徴の数だけ、このループを繰り返す必要がある点だ。
人手で回すと、1回のチューニングサイクルに約6時間。誤答分析から全体評価まで含めたサイクル（最大3回）には約3.5週間を要し、試したプロンプトのバージョンは約30回に及ぶこともあったという。プロジェクト単位で数週間、というのが記事の書き出しだ。
記事の核心は一つの比喩に集約されている。「reasoning ≒ 勾配（どの方向に直せば良くなるか）」。VLMが判定を出すときの推論理由（reasoning）を、プロンプトという"パラメータ"を更新するための"勾配"とみなす——プロンプトチューニングを勾配降下法になぞらえる発想だ。
これを実行する/tuneスキルは、4つのsub-agentに役割を分解している。
誤答サンプルのVLM出力・reasoning・画像を読み、何が起きているかを言語化する。
定義と実際の判断のズレ、過検出や見落としのパターンを特定し、改善方針を立てる。
定義の補足・例示の追加・曖昧な表現の排除といった具体的な修正をプロンプトに反映する。
効いた施策・悪化した施策をlessons.mdにDO/DONTとして書き残し、次のイテレーションが同じ失敗を繰り返さないようにする。
この4つが行き当たりばったりに動かないよう、optimization-policy.md（改善の優先順位・採用棄却の判定基準・停止条件を集約した単一の方針ファイル）と、prompt-design-strategies.md（Gemini公式のプロンプト設計手法を要約した参照資料）が判断の土台として常時参照される。
「クリエイティブな作業までループに任せて大丈夫か」という懐疑への答えが、この記事の一番実務的な部分だ。
experiment_config.json（モデル・パラメータ・最大イテレーション数・データセットなどを集約したファイル）をユーザーが確認してから、自動最適化サイクルが始まる。ここが自動化の落とし穴。ablation実験では、reasoningを参照せずに改善したプロンプトはtest精度0.7983にとどまり、trainには効くがtestで伸びない過学習の兆候を示した。reasoningを参照した条件はtest精度0.8641まで汎化した。「reasoningを勾配として使う」という設計そのものが、単なる思いつきではなく検証された選択だったことが分かる。
| 指標 | 人手 | Claude Code自動化 | 変化 |
|---|---|---|---|
| チューニングサイクル | 約6時間 | 約2.5時間 | 約2.4倍速 |
| 全体評価サイクル | 約3.5週間 | 約1週間 | 約3.5倍速 |
| イテレーション数 | 約30回 | 10〜20回 | 減少 |
| 精度（T1タスク・test） | 0.8473 | 0.8641 | +0.017 |
スキーマ構造が異なる複数タスク（T1〜T3）すべてで改善が見られ、特定のタスクに過適合した改善ではなかった点も記事は強調している。
個人開発でも、AIに任せる委任プロンプトを書くだけで終わらせず、停止条件と検証の仕組みをセットで設計するという考え方はそのまま応用できる。「reasoningを勾配として使う」の核は、AIの判断理由そのものを次の改善の入力データにするという一般化可能な発想であり、プロンプトチューニングに限らず、誤答分析を伴う反復作業全般に転用できそうだ。
出典: ZOZO TECH BLOG — ループエンジニアリング実践：プロンプトチューニングをClaude Codeに任せてみた