Codex-maxxing forlong-running work
https://cdn.openai.com/pdf/8a9f00cf-d379-4e20-b06f-dd7ba5196a11/OAI_WhitePaper_Codex-maxxing26.pdf
の翻訳概要です。
「環境を完璧に構築すれば、ロングランが成功する」と、よく言われていますが、
そもそもその「完璧な環境」の構築が大変なのです。
どうやったら、自然に、無理なく、精度よく、 Codex をロングランさせる環境を作るか、というガイドラインです。
全体要約
このホワイトペーパーは、Codexを単なる「コードを書くAI」ではなく、作業の文脈・記憶・ツール・レビュー・定期実行をつなぎ、長く続く仕事を前に進める作業拠点として使う考え方を説明しています。
中心となる考えは、1回のプロンプトで完結する使い方ではなく、Codexに作業の流れを持たせることです。つまり、会話スレッドに文脈を蓄積し、音声入力で曖昧な考えも渡し、途中で方向修正し、必要な情報をメモリに保存し、Slack・Gmail・Calendar・GitHub・ブラウザ・ローカル環境などを使わせ、定期的に再開させることで、作業を継続的なループに変える、という内容です。
Durable threads：長く使う作業スレッド
重要な作業には、毎回新しいチャットを作るのではなく、固定された長期スレッドを使うことが推奨されています。
長期スレッドには、過去の判断、好み、未完了タスク、進行中の課題が蓄積されます。たとえば「Chief of Staff」「OpenAI CLI」「Agents SDK」「オープンソース対応」「SNS反応監視」など、作業テーマごとにスレッドを分けておくと、Codexが毎回文脈を失わずに続きから作業できます。
ただし、長いスレッドは文脈量が増えるため、短い新規スレッドより実行コストが高くなる可能性があります。それでも、重要な作業では継続性の価値が上回る、という整理です。
Voice input：音声入力で思考をそのまま渡す
音声入力の価値は、単に速いことではありません。むしろ、まだ整理されていない思考や曖昧な記憶を、そのままCodexに渡せることが重要です。
たとえば「SlackでBenという人が何か言っていた気がする。正確には覚えていないから探して」といった、文章にすると雑に見える指示でも、実務ではよくあります。音声入力なら、こうした未整理の文脈や違和感、半分だけ覚えている情報を自然に伝えられます。
会議、通話、立ち話、ラフな音声メモも、Codexに渡すことで、計画、ドラフト、成果物、次のアクションへ変換できます。
Steering：作業中に方向修正する
Steeringとは、Codexが作業している途中で、追加指示や方向修正を入れることです。
たとえば、WebページやUIをレビューしながら「ここを小さくして」「この文言は違う」「余白が変」「終わったらPRを開いて」「プレビューリンクを先に見せて」といった指示を追加できます。
これにより、Codexの作業を一方通行にせず、人間がレビューしながら次の行動をキューに積む形にできます。音声入力と組み合わせると、作業中の細かい気づきを即座に反映しやすくなります。
Memory：会話外にレビュー可能な記憶を持たせる
長期作業では、会話履歴だけに頼るのでは不十分です。そこで、Codexが参照できるメモリ保管庫のような仕組みが重要になります。
この資料では、メモリは「作業のためのノートブック」として扱われています。人の好み、プロジェクトの状態、決定事項、未完了ループ、日次メモなどを保存します。
重要なのは、メモリをブラックボックスにしないことです。GitHub上に置けば、Codexが何を重要だと判断して書き残したかをdiffで確認できます。
「リポジトリはコードを持つ場所、メモリ保管庫は作業周辺の流動的な文脈を持つ場所」と分けて考えるのがポイントです。
Computer and browser use：Codexに触らせる範囲を決める
スレッドとメモリがあると、次に重要になるのは「Codexに何を使わせるか」です。
資料では、作業面を次のように分けています。
$browser：ローカルWeb画面、プレビュー、注釈@chrome：ログイン済みブラウザ、認証済みタブ@computer：GUI操作が必要なデスクトップ作業- Connectors：Slack、Gmail、Calendar、GitHubなど
- Skills：繰り返し使えるワークフロー
ローカルアプリを確認するならブラウザ、ログイン状態が必要ならChrome、デスクトップアプリ操作が必要ならcomputer use、というように、作業対象に応じて使い分けます。
また、一度うまくいった手順はSkills化し、毎回Codexに説明し直さなくてよい形にすることが推奨されています。
Remote control：長い作業を別端末から見守る
Remote controlは、Codexが長時間の作業をしているときに、スマホなど別端末から確認・承認・方向修正できる仕組みとして説明されています。
たとえば、机で作業を開始し、外出中にスマホから進捗を見て、次の判断を承認したり、別方針を指示したりできます。
ただし、リモート操作はレビューを省略するためのものではありません。むしろ、長時間ループを止めないために、人間が必要なタイミングで関与するための仕組みです。
Thread automations：スレッドを定期的に再起動する
Thread automationsは、現在のスレッドに紐づいた定期実行のような仕組みです。
通常のプロンプトが「今これをやって」という指示なのに対し、Thread automationは「定期的に確認し、変化があれば進めて」という指示です。
たとえば、30分ごとにSlackとGmailを確認し、未返信で対応が必要そうなメッセージを探し、文脈を調査し、返信案を作る。ただし送信はユーザー承認なしに行わない、という使い方が紹介されています。
対象は、PR、Slackスレッド、受信箱、デプロイ状況、ドキュメント、カスタマーサポート、長時間コマンドなどです。
Three examples of loops：3つの実用ループ
資料では、Codexの力は「文脈、ツール、メモリ、定期実行、レビュー」を組み合わせたループにあると説明しています。
1つ目は「Chief of Staff」ループです。CodexがSlackやGmailを定期確認し、対応が必要なメッセージを見つけ、関連文脈を調べ、返信案を作ります。最終的な送信判断、トーン、タイミングは人間が決めます。
2つ目は「フィードバック監視」ループです。Slack上のアニメーションへのフィードバックを監視し、Remotionプロジェクトを更新し、再レンダリングし、レビュー用リンクや修正メモを用意します。創造的判断や公開判断は人間が行います。
3つ目は「返金対応」ループです。カスタマーサポート担当者が参加したかをCodexが定期確認し、会話が進んだら次の返信案や証拠、推奨アクションを準備します。ただし、承認や不可逆な操作は人間が決めます。
Goals：Codexが検証できるゴールを設定する
弱いゴールは「このMarkdownの計画を実装して」のようなものです。
強いゴールは、期待される挙動、レビュー基準、制約、完了条件を含みます。
資料では、ライブラリ移植の例が紹介されています。単に「Rustに移植する」のではなく、「公開APIの互換性を保ち、元のユニットテストが通ることを成功条件にする」と指定することで、Codexが自分の作業を検証しやすくなります。
つまり、Codexには「何を作るか」だけでなく、何をもって完了とみなすかを明確に渡すべきだということです。
Side panel：成果物を作業ループの一部にする
Side panelは、単なるプレビュー画面ではなく、Codexが作っている成果物を人間とCodexが一緒に確認する作業面として位置づけられています。
Markdown、スプレッドシート、CSV、PDF、スライドなどをその場で確認でき、コメントや修正指示を作業文脈として使えます。
また、index.html、Storybook、Remotion Studio、Slidev、Streamlit、Jupyterなどの小さなWeb成果物も、アプリ内ブラウザで確認・操作できます。
この資料では、Side panelを「Codexが単なるチャットアプリを超えて、実際に仕事が進む場所になる部分」と捉えています。
結論
この資料の主張は、Codexを「1回質問して1回答えるAI」として使うのではなく、継続する仕事の実行環境として使うことです。
長期スレッドで文脈を保持し、音声入力で未整理の思考を渡し、Steeringで作業中に修正し、Memoryで判断や状態を保存し、各種ツールやコネクタで現実の作業面に接続し、Thread automationで定期的に戻らせ、Side panelで成果物を確認する。
この組み合わせにより、作業は「毎回ゼロから説明するもの」ではなく、途中から再開し、レビューし、改善し続けるループになります。
