「分析したい」→「じゃあ毎回CodexかWorkを起動する」。便利ではある。でも、長く回す研究や記事工場では、これを通常運転にすると途中で止まりやすい。
今回の節約術は、CodexやWorkを使わないことではない。最初の重い準備だけ任せて、その後の反復分析をChatへ戻すことだ。
なぜわざわざChatへ寄せるのか
理由は単純で、WorkとCodexには明確な利用枠があるからだ。
OpenAIの現行ヘルプでは、Codex、ChatGPT Work、ChatGPT for Excel、Workspace Agentsは、利用可能なプランでは共通のエージェント利用枠とクレジットプールを使うと説明されている。Codexには5時間と週次の利用期間もあり、上限へ達すると、そのターン終了後はリセットを待つか、利用可能なら追加クレジットなどを使うことになる。
長いコード作業、巨大リポジトリ、大量ファイル、長時間エージェント実行は、この共有枠をかなり食いやすい。実際、調査や研究を何工程も連続でやらせると、「まだ途中なのに今週分が終わった」が起きる。
一方、通常ChatはWork/Codexの共有エージェント枠とは別の利用体系だ。Chatにもモデル別・機能別の上限はあり、Proでも完全な無制限とは言えない。ただし、Work/Codexの5時間・週次枠を消費する反復作業をChatへ移せば、少なくともエージェント枠の枯渇による強制中断をかなり減らせる。
要するに、節約したいのは「AI」ではなく「重い実行面」である。
毎回ショベルカーを呼ばず、最初に道路だけ作って、あとは普通の車で走る。
結論：CodexとWorkは工事、Chatは研究室
役割を三つに分ける。
- 外から取る・つなぐ・変換する：Codex / Work / ローカル
- Chatが何度でも読める共通形式へ固める：Parquet / CSV / JSON / manifest
- 仮説・比較・再計算・文章化を繰り返す：Chat
一番大事なのは2番だ。一度Chat向けの材料を作れば、その後は条件を変えるたびにCodexへ戻らなくていい。
記事工場ではどう分けるか
Codexに残すのは、リポジトリ全体の大改修、新しい取得スクリプト、デプロイ修復、大量ファイルの初回変換などだ。
日常運転はChatへ寄せる。
- 会話から記事化
- 日本語編集
- 12言語化
- 個人情報・重複・説明不足の確認
- タイトルと見出し改善
- 追加調査
- source draftのGitHub投入
- 既存記事の再編集
記事1本できるたびに「Codex召喚！」をやると、記事工場ではなくCodex召喚工場になる。
記事だけの変更で毎回重いCIを回さない、通常処理をChat中心にする、という考え方も同じだ。
価格分析ではさらに効く
市場研究では最初のデータ準備だけが重い。
Codex側で最初にやるのは、たとえば次だけでいい。
- API接続
- 大容量データ取得
- DBNなどbinaryのdecode
- timestamp整合
- raw hash保存
- Discovery / Validation / Finalの時系列分割
- 共通Parquetへの変換
その後はChatで、ES / NQ / 6E / 6J、BTC / ETH、bitbank全JPYペアなどを何度でも比較する。
- queue
- cancel
- partial fill
- adverse selection
- spread capture
- inventory cost
- maker rebate
- latency stress
- placebo
- parameter近傍
- 月別・年別安定性
- 市場×戦略ランキング
を見る。
ここで狙うのは「次に上がるか」ではない。誰が急いで売買しているか、どこで流動性が消えるか、どの待ち順位なら対価が残るか、片側だけ約定した在庫をどう処理するかだ。
Chat用データは巨大rawそのままにしない
理想は、再現性を残した分析用bundleだ。
research-bundle/
DATA_MANIFEST.json
CHECKSUMS.sha256
DATA_QUALITY.csv
SPLITS.json
discovery/*.parquet
validation/*.parquet
final_sealed/*.parquet
RESEARCH_STATE.json
CHECKPOINT.md
板データなら列もなるべく共通化する。
ts_event, ts_recv, venue, symbol, event_type,
side, price, size, order_id, sequence, action
L2市場にorder_idがなければnullにする。ない情報を「たぶん」で生やすと、研究が急にファンフィクションになる。
Finalは最初から見ない
Discovery、Validation、Finalは先に切る。
- Discovery：仮説を作る
- Validation：候補を壊す
- Final：ルール凍結後に一度だけ開く
Chatで何でも分析できるからといって、最初からFinalを見ながら条件調整すると過学習になる。節約できても研究が壊れたら意味がない。
WorkやCodexに残すべき仕事
| 仕事 | 向いている場所 |
|---|---|
| ログインが必要なサイト操作 | Work |
| 大容量binary取得・変換 | Codex / ローカル |
| リポジトリ全体の実装・テスト | Codex |
| 24時間WebSocket収集 | ローカル常駐collector |
| 取得済みデータの分析 | Chat |
| 仮説生成・反証・比較 | Chat |
| Python集計・simulation | Chat |
| 記事化・翻訳・編集 | Chat |
Chat万能論ではない。一度しかやらない工事と、何十回も繰り返す研究を分けるだけだ。
一番もったいない使い方
- 毎セッション同じデータを再取得する
- 条件を一つ変えるたびにCodexへ戻る
- 巨大ZIPを毎回丸ごと投げる
- 普通の検索だけなのにWorkを使う
- 研究状態を会話の記憶だけに置く
raw hash、manifest、partition、RESEARCH_STATE.json、CHECKPOINT.mdを残せば、かなり防げる。
完成形
外部サイト / API / GitHub / 市場データ
↓
Codex / Work（必要時だけ）
↓
共通Parquet + manifest
↓
Chat
仮説 → 分析 → 反証 → 再分析
↓
Validation → Final
↓
記事 / レポート / GitHub
外部へ手を伸ばす仕事は少ない。手元の材料を何度も考え直す仕事は多い。
だから、重い実行面は入口だけに使い、その後はChatへ戻す。
節約術は「Codexを使わない」ではない。
最初にCodexへ、Codexを毎回呼ばなくても済む環境を作らせることである。
参考資料（4件）
- OpenAI Help Center: https://help.openai.com/en/articles/11369540
- GPT-5.6 in ChatGPT: https://help.openai.com/en/articles/20001354-gpt-56-in-chatgpt
- ChatGPT Work and Codex: https://help.openai.com/en/articles/20001275-chatgpt-work-and-codex
- Databento Pricing: https://databento.com/pricing
