Codex CLI画像生成パイプラインでgpt-5.6-solを採用——消費効率3割差のモデル比較とレートリミット運用
朝5時台、「続きをお願いします」でセッションを再開した。初手は決まっている。引き継ぎメモの先頭に「gpt-5.6-solに切り替えた最初のチャンクで、消費効率を計測する」と書かせてあった。
発端は前のセッションにある。画像ランナーのスクリプトを確認させたら、codex exec -m gpt-5.5 がかなり初期のコミットからハードコードされたままだと分かった。solに切り替えたつもりで、ずっと5.5が回っていたのだ。モデル指定を直したうえで1枚だけA/B生成させて見比べると、solの方が良く見えた。ただ、1枚では揺らぎかもしれない。チャンク単位で効率を測ってから決める——そこまでを引き継ぎドキュメントに追記させてあった。
再開、その前に認証でつまずく
ドライバーを立ち上げる前に、Codexの認証が失効していた。codex login status は失効していても "Logged in" と表示するので当てにならない。実際にAPIを1回叩かせて refresh_token_invalidated を確認し、再ログイン後も同じく実呼び出しで復旧を検証してから再起動した。最初の1枚がclaimから約1.7分でdoneまで通り、パイプラインは息を吹き返した。
solの消費効率は3割悪かった
量産はチャンク単位で回る。ドライバー1本がランナー24本を起動し、各5枚ずつ、およそ120枚で1チャンク。最初のチャンクは06:03に始まり、15分で走り切った。
消費効率 = チャンクの生成枚数 ÷ 週次枠の使用率増分
sol 実測: 約12.9枚/1%(5.5 の基準値: 約19枚/1%)
同じ枠で作れる枚数が約3割減る。事前に決めておいた相談ライン「12枚/1%未満なら止めて相談」は上回っていたので、規定どおり継続させつつ、判断材料だけ報告してもらった。
ここで枠の在庫を思い出した。週次枠をまるごと戻せるフルリセットのチケットが3枚ある。残りの必要枚数から逆算すると、どうせ使い切れない。効率3割減はチケットで吸収できる。solでいく、と決めた。
品質の裏取りは自分の目で13件
効率は割り切った。残るのは、品質が本当にコスト差に見合うのかだ。同じ対象230枚を5.5でも並走生成させ、solと5.5を左右に並べた比較用のテンポラリページを作らせた。ローカルHTMLをブラウザで開いてもらい、1件ずつボタンを押して判定していく。判定は自動保存され、あとでJSONを貼れば集計してもらえる仕組みだった。
13件判定した結果は、sol 7・差なし4・5.5が2。「良いものはsol」という分布だった。コスト差が3割なら、solの方がやっぱりいい。ここでsolに最終確定し、5.5の比較生成は止めて量産をsolに一本化した。
24並列、枠切れまでの自動運転
並列数は24本に固定した。前日の実測で「同時60本超は飽和して逆効果、スイートスポットは実効25〜40本」と出ていたからだ。スループットは約450〜470枚/時。Monitorにはチャンク完了と異常(今回の認証エラー検知の行も含む)だけを拾わせて、あとは自動運転に任せた。
途中、ワーカーが1本、また1本とレートリミット検知で安全終了していく。担当分はキューに戻り、残りのワーカーが引き継ぐ。チャンク境界で24本に再起動されるので、放っておけば自己回復する。failedは最後までゼロだった。ふと「今いくつ並列だっけ」と不安になって実プロセス数を数えさせたら、ランナー24本・ドライバー1本で多重起動なし。台帳どおりだった。
とはいえ枠の残量は嘘をつかない。スロットリングが増えるにつれてチャンク所要は15分から44分まで伸び、使用率93%を超えたあと、チャンク9で進捗が止まった。週次枠切れ。この日の生成は1,030枚、累計 done 3,273 / pending 939 / failed 0。対象全体の約78%まで来た。
あと1回リセットすれば残り939枚を作り切れる計算になる。チケットはまだ残っている。ただ、この日はここで店じまいと決め、ドライバーを完全停止して明日の再開手順をメモに残させた。
単語確認UIはMiller Columnへ(計画だけ)
生成した挿絵の検収では、単語を確認するページを延々スクロールする羽目になっていた。ホイールを回し続けないと次の単語に届かない。そこで、既存ページで使っているMiller Columnの基盤を流用し、矢印キーで単語を移動できるレイアウトへ変える計画を立てさせた。単語・意味・メモ・例文・日本語訳・画像の配置を画面内で固定できれば、タブレットでもPCでも確認が速くなるはずだ。
実装には手を付けていない。計画ドキュメントを1本残しただけにした。
学び
codex login statusの "Logged in" 表示は失効を検知しない。認証の生死は実API呼び出しで確かめる- モデル切り替えは「切り替えたつもり」が一番危ない。ランナーのスクリプトにモデル名がハードコードされていないかを先に見る
- 消費効率は「生成枚数÷使用率増分」で1チャンクごとに測ると、モデル間の差が具体的な枚数の差として比べられる
- レートリミット下の並列生成は「脱落してもキューに戻る」設計にしておくと、監視をゆるめても壊れない
- 品質判断は集計より先に、比較ページを自分の目で見る。13件の手動判定で方向は十分に出た
明日は残り939枚。リセット1回で終わる。