オープンAIのCodex白書(マキシングガイド)を翻訳解説【長く続く仕事を任せる10の方法】

「便利そうなのに、結局1回試して終わってしまう」。生成AIをそう感じたことがあるなら、それはツールの性能ではなく、仕事が”続く場所”を持っていないことが原因かもしれません。

2026年、OpenAIは「Codex-maxxing for long-running work(長く続く仕事のためのCodex活用術)」と題したホワイトペーパーを公開しました。Codexはもともと開発者がコードを書くための道具ですが、この資料が示しているのは、1回の指示で完結しない仕事を、プロンプトをまたいで前に進め続けるという、職種を問わない使い方です。
この記事は、全27ページの公式ホワイトペーパーの中身を、プログラミングに詳しくない経営者やビジネス職の方が手元に置けるよう、図版と一緒に日本語で再構成したものです。

なぜ「1回の指示」で終わらせないのか

多くの人がAIを使うとき、頭の中は「質問する、答えをもらう、終わり」という単発のやり取りで止まっています。
ところが現実の仕事は、1回の返答では終わりません。返信を待ち、状況が変わり、誰かの承認をはさみ、翌日また続きに戻る。こうした時間をまたいで続く仕事こそ、本来いちばん手間がかかる部分です。

OpenAIのホワイトペーパーは、Codexがこの「続く仕事」を担えるようになった鍵を、5つの要素に整理しています。コンテキスト(文脈)を集める場所、ツールへの接続、記憶(メモリ)、定期的な再実行、そして出力をレビューできる場です。
この5つが1つの輪としてつながったとき、仕事は前進と振り返りをくり返しながら進みます。私たちは、この輪を頭に入れておくだけで、AIの使い方が単発の質問から「続く仕事の運用」へと変わると考えています。

Codexはコードを書く道具として優れていますが、より大きな変化は、開発者でなくても使える「仕事の運び方」が手に入った点にあります。長時間タスクの実行については、OpenAIがCodexの基盤を強化してきた流れも参考になります(OpenAIがOnaを買収｜Codexの長時間実行)。どのツールが自社の内製化に向くかを整理したい場合は、Claude Code・Codex・Copilotの比較もあわせてご覧ください。

01｜永続スレッド：仕事に「住処」を与える

重要な仕事の流れには、ピン留めした「永続スレッド」を1本用意します。
そのスレッドは、文脈・好み・過去の決定・やりかけの懸案が時間をかけて積み上がっていく「住処」です。毎回まっさらな会話を立ち上げるのではなく、同じ場所に戻ることで、AIは前回の続きから動けるようになります。

永続スレッドの「複利効果」とコストの考え方

永続スレッドは、会話が長くなっても履歴を参照できる状態に保ち、それをメモリ・ボールト(記憶の保管庫)へ蓄えていきます。
同じスレッドが過去のやり取りと変更履歴を抱えたまま走り続けるので、回を重ねるほど指示が短くて済み、精度も上がっていきます。これが「複利効果」です。

ただし、トレードオフもあります。
長く動き続けるスレッドは大量の文脈を抱えるため、まっさらな短いスレッドよりも1回あたりの実行コストが高くつきがちです。それでも重要な仕事では、毎回ゼロから説明し直す手間が消える分、継続性の価値がコストを上回り、かえって管理しやすくなることが多いと整理されています。AIの利用料が読みにくいと感じる場合は、定額と従量で使える量がどう変わるかもあわせて押さえておくと、判断の助けになります。

02｜音声入力：自分の「生の思考」をそのまま渡す

音声入力は、Codexが受け取るコンテキストの「種類」を変えます。利点はスピードだけではありません。
話し言葉には、しばしば仕事の未編集バージョンが含まれます。うろ覚えの名前、ざっくりした方向性、確信の持てなさ。きれいにタイプするのはためらうけれど、声でなら自然に出てくるものです。

一見あいまいですが、これは十分に有用な指示です。
というのも、現実の仕事はしばしばこういう不完全な形で始まるからです。通話、会議、廊下での立ち話、ざっくりした音声メモ。こうした生の素材を出発点に、Codexは計画・下書き・成果物・次のアクションへと変える手伝いができます。文字起こし(トランスクリプト)も同じように使えます。

03｜ステアリング：動いている最中に方向を直す

ステアリングとは、Codexがすでに作業している最中に、次の指示を追加していくことです。
方向を修正したり、文脈を足したり、次のステップを承認したり、ツールを呼び出したあとのアクションを予約したりできます。音声入力と組み合わせると、思いついたことをそのまま流し込めるので、さらに使い勝手が上がります。

ポイントは、作業を一度止めて指示し直すのではなく、流れを止めずに方向だけ微調整する点にあります。
人が隣で「あ、そこはこうして」と声をかけるのに近い感覚です。終わってから全部やり直すより、途中で軌道を直すほうが、結果として速く正確に仕上がります。

04｜メモリ：あとから「レビューできる」記憶にする

スレッドが長く続くほど、会話の外側に置く「メモリ」が必要になります。メッセージ履歴も役には立ちますが、それだけでは埋もれてしまいます。
ホワイトペーパーが勧めるのは、有用な文脈を開いて・編集して・差分(diff)を取って・再利用できる形にすることです。その具体的なパターンが「ボールト(vault＝保管庫)」と呼ばれるフォルダ構造です。

vault/
├── AGENTS.md          # ボールトの運用ルール
├── TODO.md            # プロジェクト横断の優先事項
├── projects/          # 進行中の案件ごとの状態
│   ├── README.md      # アクティブな案件の索引
│   ├── agents-sdk/
│   └── rust-migration-blog/
├── agent/
│   ├── USER_CONTEXT.md # 作業上の好み・文脈
│   └── daily-summary-*.md # 日々の決定とフォローアップ
├── people/           # 人物・関係性のメモ
└── notes/

大切なのは、コードを置く場所と文脈を置く場所を分けることです。
リポジトリはコードを保持し、ボールトは仕事まわりの「流動的な文脈」を保持します。人物、決定、やりかけの懸案、日々のメモ、案件の状態、スレッドの狭間で失われがちな細部。こうしたものをボールトに集約します。

このボールトをGitHubのような場所に置くと、差分(diff)がそのまま記憶のレビュー画面になります。
Codexが「書き留めるほど重要だ」と判断した内容を、人が目で見て確かめられるわけです。長く動くスレッドに、あいまいな印象を黙って溜め込ませるのではなく、「何が変わったか」を記録させる。このレビューの一手間が、信頼できる記憶をつくります。

05｜コンピュータ／ブラウザ操作：触れてよい範囲を決める

スレッドにメモリを持たせたら、次は実務的な問いに移ります。「それは何を使ってよいのか」です。
ここで登場するのがコネクター(Connectors)です。Slackのスレッド、受信トレイ、カレンダー、ドキュメント、Issue管理など、仕事が最初に現れる場所へCodexを広げます。操作の対象を「面(surface)」として切り分けると、安全に運用しやすくなります。

使い分けの考え方はシンプルです。手元のアプリを直しているならブラウザ面、ログイン状態や複数タブに依存するならChrome、デスクトップアプリ経由でしか終わらない作業なら、権限とレビューをはっきりさせたうえでコンピュータ操作を使います。
一度うまくいったワークフローはスキル(Skills)として手順・参照資料・スクリプトごとパッケージ化でき、次回から一から教え直す必要がなくなります。

こうした外部ツール連携やブラウザ操作は、Codexに限った話ではありません。仕組みの全体像は外部ツール連携(コネクタ)でできることや、CodexにPC操作を任せる導入手順でも整理しています。どの面まで触らせるかを決めることが、安全運用の第一歩になります。

06｜リモート操作：長いループを「持ち運べる」状態に

リモート操作は、長時間動き続けるタスクに寄り添い続けることを楽にします。
Codexは、あなたのファイルや権限、ローカル環境がすでにあるマシン上で作業を続けられます。あなたは別のデバイスから状況を確認し、見つかったものをレビューし、質問に答え、次のステップを承認し、必要なら方向を変えられます。これが効くのは、Codexがすでに時間のかかる何かをやっている最中です。

ただし、リモートで動かせることは、レビューを省いてよい理由にはなりません。
むしろリモート操作は、ループに十分な注意を払い続け、次の一手で詰まったときにすぐ解消するための手段です。離れていても、判断するのは人のままです。

07｜スレッドオートメーション：戻ってくるスケジュールを組む

スレッドオートメーションは、いまのスレッドに紐づいた「起こし呼び出し」です。心拍(ハートビート)のようにくり返し発火し、Codexを一定のリズムで同じ会話へ戻します。
毎回ゼロから始めるのではなく文脈を保ったまま再開する点が、通常のプロンプトとの決定的な違いです。1つのスレッドに複数のスケジュールを持たせたり、条件を満たすまで走らせたり、状況に応じて頻度を変えたりできます。

監視の対象は幅広く、プルリクエスト、Slackスレッド、受信トレイ、デプロイ、ドキュメント、カスタマーサポートのやり取り、長時間実行のコマンドなどが考えられます。
たとえば次のように設定すると、Codexは定期モニターを自分で作り、承認なしには何も送らない約束のもとで下書きだけを用意し続けます。

「30分ごとに、SlackとGmailを確認して、対応が必要かもしれない未返信メッセージを探して。背景を調べて返信案を下書きして。ただし、承認なしには何も送らないで。」

自然言語の指示を定期実行の仕組みに変える発想は、開発の現場でも広がっています。関連する考え方は自然言語の指示をGitHub Actionsに変えるAIエージェントの仕組みでも扱っています。

08｜ループの実例3つ：人の承認をどう残すか

ここまでの機能は、単体でも便利ですが、本当の力は複数の機能をまたぐ「ループ」として組み合わさったときに出ます。冒頭で示した「コンテキスト → ツール → メモリ → 反復 → レビュー」の輪です。
ホワイトペーパーは、このループの実例を3つ挙げています。いずれにも共通するのは、Codexが用意するものと人が決めることを、はっきり分けている点です。

ループ1：参謀役(Chief of Staff)

Codexがスケジュールに従ってSlackとGmailを確認し、対応が必要そうなメッセージを見つけ、その背景を調べ、返信案を下書きします。何を送るかは、人が決めます。

Codexが用意するもの

未対応のメッセージ

関連する背景情報

返信の下書き

判断が要る質問の洗い出し

あなたが決めること

送るかどうかの承認

トーン(言い回し)

送るタイミング

最終決定

ループ2：フィードバックの監視

Codexが作品へのフィードバックをSlackで監視し、制作プロジェクトを更新し、作り直してレビュー用に用意します。
このループは複数のツールをまたぎます。意見の収集にSlack、レンダリングに制作ツール、アップロードやレビューでGUIが要るときはコンピュータ操作、という具合です。

ループ3：返金を取り付ける

Codexがカスタマーサポートの担当者が参加したかどうかを確認し、会話が動いたら次の応答を用意します。
ユーザーが離席している間もタスクは続きますが、アクションは許可された範囲に限定されたままです。不可逆な操作は、必ず人の手に残します。

09｜ゴール設定：Codexが「検証できる」基準を与える

弱いゴールは、Codexに「計画を実装して」と頼むだけです。これだと、何をもって完了とするかが本人にも分かりません。
より強いゴールは、Codexに照合できる基準を与えます。期待される挙動、レビュー基準、制約条件、あるいは「完了の明確な定義(definition of done)」です。

ホワイトペーパーが挙げる具体例が「RichをRustへ移植する」プロジェクトです。
ゴールは単にライブラリを移植することではなく、元のユニットテストを通せる形で移植することでした。このテストスイートが実行に本物の基準を与えるため、新しい実装が同じテストを通すまで、その仕事は「完了」になりません。この一線があるだけで、AIに任せた作業の善し悪しを、人が感覚で判断せずに済みます。

この考え方は、コードに限りません。資料作成なら「この観点が全部入っていれば完成」、メール対応なら「この条件を満たした下書きならOK」というように、合否を判定できる基準を先に渡すほど、AIの成果は安定します。あいまいな「いい感じにして」は、強いゴールに言い換えるのが近道です。

10｜サイドパネル：成果物をループの一部にする

サイドパネルは「プレビュー画面」と説明すると簡単ですが、それでは過小評価になります。
サイドパネルは、Codexが単なるチャット以上の存在になる場所です。あなたはCodexが操作しているのと同じオブジェクトをその場で検査でき、コメントを残し、変更をレビューし、その成果物をスレッドの中に保ったままにできます。

仕事のための「システム」を、素早く組む

ここまでの10機能を貫いているのは、たった1つの発想です。AIを単発の道具ではなく、仕事が住み続けるシステムとして扱うこと。
プロジェクトを前に進める手段がそろうと、タスクは文脈を失わずに引き継ぎ・レビュー・継続ができるようになります。人は、やり直しに費やす時間を減らし、すでに動いているものの上に積み上げる時間を増やせます。

経営や現場の仕事に置き換えると、示唆はさらにはっきりします。
永続スレッドは「案件ごとの引き継ぎ場所」、メモリは「属人化しない決定の記録」、検証可能なゴールは「成果物の合格基準」、そしてレビューは「人が責任を持つ最後の関所」です。これらはAIの話であると同時に、組織の仕事の進め方そのものでもあります。AIエージェント時代に役割や評価がどう変わるかは、組織と人事評価はどう変わるかでも掘り下げています。

出典: OpenAI「Codex-maxxing for long-running work」(英語)。本記事は同社の公開ホワイトペーパー(全27ページ)の内容を、図版とともに日本語で再構成したものです。製品名・機能名はホワイトペーパー時点の表記に基づきます。

よくある質問(FAQ)