OpenAIが2026年6月22日に公開した白書「Codex-maxxing for long-running work」は、AIを単発の質問応答ではなく、長時間かかる仕事の運用基盤として使う考え方をまとめた資料です。中心メッセージは、Codexを“作業が住み続ける場所”として扱い、途中で文脈を失わずに進めることでした。
速報として押さえたいのは、白書が新モデルの性能競争よりも、durable threads、memory、thread automations、remote controlといった運用機能の組み合わせを重視している点です。企業導入で重要なのは、AIの賢さだけでなく、引き継ぎ、承認、再開、記録をどう設計するかだと読み取れます。
Codex-maxxing for long-running workとは？
OpenAIの紹介ページでは、この白書を「単一のプロンプトを、プロジェクトを前進させる operating loop に変えるガイド」と説明しています。PDFの目次でも、Durable threads、Voice input、Steering、Memory、Computer and browser use、Remote control、Thread automations、Goals、Side panelの10章構成になっており、長期タスクを止めずに回すための実務論に焦点が置かれています。
まず見直すべきは durable threads の使い分け
白書では、重要な仕事ほど専用のスレッドを“home for the work”にするべきだと述べています。背景には、過去の判断、未解決事項、関係者の好み、次の確認ポイントが同じ場所に蓄積されるほど、再開コストが下がるという考えがあります。一方で、長いスレッドは fresh short thread よりコストが上がる可能性も明記されており、全部を長期化するのではなく、再訪前提の業務だけを durable にする設計が現実的です。
steering と memory がないと長時間タスクは崩れやすい
OpenAIは、長時間タスクを回すうえで、途中介入できる steering と、会話外に残す memory を別物として扱っています。Steering は「終わったらPRを開いて」「プレビューを見せてから投稿して」のように、作業中に次の指示を差し込む考え方です。Memory は、会話履歴に埋もれやすい決定事項や待ち状態を、開ける・編集できる・差分確認できる形で残すことを指します。
白書中では memory に記録すべき対象として、人の好み、プロジェクトの待機状態、下した意思決定、閉じたループが挙げられています。企業導入では、議事メモ、承認条件、例外ルール、依存タスクをmemory側に逃がし、チャットは判断と作業の場に絞る運用が向いています。
ブラウザ・PC操作・コネクタは混ぜずに役割分担する
白書は、browser surface、Chrome、computer use、connectors、skills を明確に分けています。ローカルのプレビュー確認なら browser、ログイン済みタブが必要なら Chrome、GUIしか手段がないなら computer use、SlackやGmailの一次情報取得なら connectors、繰り返し手順の再利用には skills という整理です。ここを曖昧にすると、同じタスクでも毎回許可範囲や操作面がぶれて、監査と再現性が弱くなります。
remote control と thread automations が実運用の差になる
Remote control の章では、ファイルや権限がある元のマシンでCodexを動かし続け、別デバイスから進捗確認や承認だけ行う使い方が紹介されています。さらに Thread automations は、同じスレッドに定期的に戻る heartbeat 型の再開機能として説明されています。例として「30分ごとにSlackとGmailを見て、未返信があれば文脈調査と返信案作成まで行う。ただし送信は承認なしでしない」という運用が示されており、まさに企業の長時間業務に直結する設計です。
OpenAIが示した3つのループから学べること
白書の後半では、Chief of Staff、Monitor for feedback、Get a refund の3ループが紹介されています。共通点は、Codexが準備する範囲と、人が最終判断する範囲を分けていることです。前者は未返信メッセージの抽出、フィードバック要約、状況確認、返信案、根拠整理まで。後者は送信可否、公開判断、不可逆操作の承認です。つまり、AIに丸投げするのではなく、判断の手前までを高速化する思想が一貫しています。
導入前に確認したい3つの実務ポイント
第1に、ゴールは「やること」ではなく「検証できる完了条件」で定義することです。白書でも weak goal と stronger goal を対比し、テストや期待動作を success check に含める重要性を示しています。第2に、memory 更新ルールを最初に決めることです。人、案件、承認条件、保留理由をどこに残すか曖昧だと、長期タスクは再開時に崩れます。第3に、不可逆操作は必ず human approval を残すことです。返信送信、公開、返金申請のような最終アクションは、AI準備と人の承認を分けた方が安全です。
FAQ
Q. この白書は新しいモデル発表ですか？ A. いいえ。2026年6月22日公開の運用ガイドで、Codexを長時間タスクにどう使うかを整理した白書です。Q. どの機能が実務インパクト大ですか？ A. durable threads、memory、thread automations、remote control の4点です。Q. どんな部署に向きますか？ A. Slack・Gmail・レビュー待ちが多い情シス、開発、制作、Chief of Staff 的な調整業務と相性が良いです。
HelloCraftAIでは、長時間タスクを前提にしたAIエージェント運用設計、承認フロー整備、社内展開ルールの作成まで支援しています。CodexやClaude、Geminiを業務にどう定着させるか相談したい方は お問い合わせください 。
