本番を変えずに別モデルを試す――Codex影運転を日次ジョブにする

LLMを使う日次評価で別モデルを試すとき、いきなり本番を切り替えると、採点の違いと運用障害を切り分けにくくなります。そこで、本番のClaude評価を残したまま、同じ入力をCodexへ渡し、別の保存先へ結果を蓄積する「影運転」を追加しました。既存の使用量記録とは異なり、モデルを比較するための独立した実行経路です。

対象は投資関連の評価基盤ですが、本記事はソフトウェアの実装記録であり、投資推奨ではありません。採点の一致は正しさや利益の保証ではなく、結果の利用には人の確認が必要です。

実装と確認できた結果

8月29日の実装履歴には、再実行処理、日次集計、Hermes用ラッパーの追加が残っています。記事作成時には配置済みラッパーがリポジトリ版と一致し、月〜土の14時に動くno-agentジョブが登録されていることを確認しました。

初回ログでは6件が成功し、失敗0件、終了コード0でした。さらに今回は、通知を無効化し、一時的な検証用DBへ向けた1件限定ドライランを実行し、対象選定と正常終了を確認しました。今回LLMを再呼び出したわけではなく、全体テストを再実行したという意味でもありません。

流れは「読む・比較する・別に保存する」

1. 本番DBをSQLiteのURI接続 `mode=ro` で開く。
2. 直近7日の評価日から、影DBに未記録の対象を選ぶ。
3. 保存済みの本番プロンプトを使い、別モデルで再実行する。
4. 評価日・対象・処理種別をキーに、採点、使用量、成功・失敗を影DBへ保存する。
5. 対応する本番結果と突合し、順位相関やグレード一致、処理別のAPI換算コストを集計する。

Hermesは時刻管理とスクリプト起動を担当します。no-agentはHermes自身の推論を省く指定であり、スクリプト内のCodex呼び出しまで無料・無消費になるわけではありません。モデル名と推論設定も比較条件として固定します。

まず保存境界を小さく再現する

独自の再実行スクリプトは標準製品の付属機能ではありません。読者はまず、新しい空の作業フォルダでSQLiteの分離を確認できます。次のデータは架空です。

“`bash
sqlite3 demo-main.sqlite \
"CREATE TABLE inputs(id TEXT PRIMARY KEY); INSERT INTO inputs VALUES('DEMO-A');"
sqlite3 'file:demo-main.sqlite?mode=ro' \
"SELECT id FROM inputs;"
sqlite3 'file:demo-main.sqlite?mode=ro' \
"INSERT INTO inputs VALUES('DEMO-B');"
“`

最後のINSERTが読み取り専用エラーになることが期待結果です。続いて別DBへの保存を確認します。

“`bash
sqlite3 demo-shadow.sqlite \
"CREATE TABLE results(id TEXT PRIMARY KEY, status TEXT); INSERT INTO results VALUES('DEMO-A','ok');"
sqlite3 demo-shadow.sqlite "SELECT * FROM results;"
“`

この境界を再実行処理へ組み込み、入力選定、モデル呼び出し、結果検証、保存を分離します。実データを別サービスへ送る前には、利用許諾と秘密情報の混入を確認してください。

手元の構成で段階的に動かす

実装済みのプロジェクトでは、次のように独自スクリプトを起動します。パスは置換例です。

“`bash
cd /path/to/project
uv run python scripts/codex_shadow/daily.py \
–dry-run –no-notify –limit 1 \
–out /path/to/check.sqlite
“`

対象と保存先を確認後、人の判断でドライランを外し、モデルを明示して少数件だけ実行します。ログと影DBを読み戻してから、ラッパーをHermesのスクリプト配置先へ置き、no-agentで定期登録します。

Codex側では、手元の実装がユーザー設定の読み込みを抑える `–ignore-user-config` を使用しています。公式資料では認証まで無効になる指定ではありません。比較条件の分離と認証管理は別問題として扱います。

落とし穴と未完了事項

ドライランでもログや検証用DBは作成されます。「LLMを呼ばない」と「一切書き込まない」は違います。また、同じプロンプトでも検索時刻やモデル内部処理は異なるため、完全な再現実験にはなりません。

実行済み判定は成功行だけとは限らず、手元の日次処理では失敗行も再選定から外れます。未実施分の回収と失敗分の再試行を混同せず、後者は原因確認後に別途扱います。モデルやプロンプト版を変える比較では、同じキーで上書きせずDBを分ける設計も必要です。

レート制限による中断は、プロセス終了コードだけでは成功と区別できない場合があります。`PARTIAL` と結果行も監視対象にします。API換算額は請求実績とは別に表示し、単価変更時は再確認します。長期の品質評価と本番切替判断は、まだ別の検証課題です。

再現チェックリスト

• [ ] 本番DBへの書き込みが拒否される
• [ ] 結果は別DBへ保存される
• [ ] 同じキーの再処理と失敗時の扱いを説明できる
• [ ] 通知なし・1件限定ドライランで対象を確認した
• [ ] モデル、入力、設定、成功・中断を追跡できる
• [ ] 費用と品質を分け、人が切替可否を判断する

公式一次情報

以下は2026年9月7日に確認しました。

• [Hermes Agent：Scheduled Tasks / no-agent](https://hermes-agent.nousresearch.com/docs/user-guide/features/cron)
• [Codex：CLIコマンドと設定フラグ](https://developers.openai.com/codex/cli/reference/)
• [SQLite：URI接続とmode=ro](https://www.sqlite.org/uri.html)