はじめに
OpenAIが公開したAI Adoption記事 「Codex-maxxing for long-running work」 と、そこからリンクされているホワイトペーパーについて解説します。
この記事のテーマは、Codexを単に「コードを書かせるツール」として使うのではなく、長く続く仕事を進めるための作業場として使う、というものです。
ここでいうCodexは、単体のコード補完機能ではなく、スレッド、リポジトリ、ブラウザ、コネクタ、成果物レビューを組み合わせて、長期作業を進める作業環境としてのCodexを指します。
なお、このホワイトペーパーはベンチマークや効果測定レポートではなく、Jason Liu氏の実践ワークフローをもとにした活用ガイドです。そのため、本記事でも「どれだけ生産性が上がるか」ではなく、どう設計するとCodexを長期作業に使いやすくなるかに注目します。
従来のAI利用は、次のような単発依頼が中心でした。
この関数を書いて
このエラーを直して
このREADMEを要約して
一方で、今回の記事が示しているのは、もう少し先の使い方です。
このプロジェクトの文脈を維持して
定期的に状況を確認して
必要な差分を作って
成果物をレビュー可能な状態にして
次に人間が判断すべきことを提示して
つまり、Codexを「1回のプロンプトに答えるAI」ではなく、作業の文脈・記憶・ツール・レビューを持つ継続的なワークスペースとして扱う、という考え方です。
OpenAIのホワイトペーパーでも、Codexは現在もコーディング、diff作成、リポジトリ変更、レビュー支援に強いが、durable thread、shared memory、tool access、recurrence、output reviewを組み合わせると、作業が1回のプロンプトを超えて継続できると説明されています。
この記事の結論
要約すると、ポイントは次の1文です。
Codexの価値は「コードを書けること」だけではなく、「作業を中断しても、同じ文脈で再開できること」にある。
特に重要なのは以下の7点です。
| 観点 | 内容 |
|---|---|
| Durable threads | 作業ごとに長期スレッドを持つ |
| Voice input / Steering | 雑な思考を渡し、作業中に軌道修正する |
| Memory | 会話履歴ではなく、レビュー可能な記憶を持つ |
| Computer and browser use | Slack、Gmail、GitHub、ブラウザなど、作業場所に接続する |
| Remote control / Thread automations | 長い作業を止めず、同じ文脈へ定期的に戻る |
| Verifiable goals | Codexが検証できる完了条件を与える |
| Side panel | 成果物そのものをレビュー面にする |
1. Durable threads：作業ごとに「場所」を作る
ホワイトペーパーでは、重要なワークストリームには pinned thread / durable thread を使う、という考え方が紹介されています。
たとえば、以下のような単位でスレッドを分けます。
- OpenAI CLI
- Agents SDK
- Social feedback monitoring
- Codex for open source
- Chief of Staff
各スレッドには、その作業に関する文脈、好み、過去の判断、未解決事項が蓄積されていきます。OpenAIの資料では、重要なワークストリームに対して、文脈・好み・過去の決定・open loopsが蓄積される場所としてdurable threadを使うと説明されています。
これは、通常のチャットAI利用とは発想が異なります。
普通は、毎回こうなります。
前提を説明する
依頼する
回答をもらう
また別の日に前提を説明する
durable threadの発想では、こうなります。
この作業の文脈は、このスレッドに蓄積されている
次回もここから再開できる
ただし、長期スレッドは万能ではありません。ホワイトペーパーでも、長く続くスレッドは文脈を保持する一方で、短い新規スレッドより実行コストが高くなる可能性があるとされています。
そのため、何でも長期スレッドにするのではなく、継続性に価値がある業務だけを長期化するのが現実的です。
2. Voice input：雑な思考をそのまま渡す
興味深いのは、音声入力の評価です。
音声入力というと「入力が速い」ことがメリットに見えます。しかしこの記事では、それ以上に、曖昧な思考をそのままCodexに渡せることが重要だとされています。
たとえば、次のような指示です。
SlackでBenという人が何か言っていた気がする。
正確には覚えていないけど、ちょっと探して。
テキストで書こうとすると雑すぎる指示ですが、実際の仕事はこういう曖昧な状態から始まることが多いです。
ホワイトペーパーでも、音声入力の価値はスピードだけでなく、半分覚えている名前、不確かな方向性、タイプしづらいが口では自然に出る内容をCodexに渡せる点にあると説明されています。
これは、AIに渡す情報をきれいに整えすぎない、という話でもあります。
整理された仕様だけを渡す
のではなく、
考え途中のメモ
会議の録音
Slackで見た曖昧な記憶
レビュー中の違和感
を渡して、Codexに計画・ドラフト・成果物・次のアクションへ変換させる、という使い方です。
3. Steering：作業中に軌道修正する
Steeringは、Codexが作業している途中に次の指示を追加する考え方です。
たとえば、UIレビュー中であれば次のような指示を重ねます。
ここは小さくして
このコピーは違う
余白が広すぎる
終わったらPRを開いて
デプロイされたらプレビューリンクを見せて
従来のAI利用では、1つの指示に対して1つの回答を待つ形になりがちです。
しかし長期作業では、途中で状況が変わります。レビューしているうちに、別の問題に気づくこともあります。Codexがツール実行中に、人間が次の判断を追加したくなることもあります。
Steeringの考え方では、人間は最初に完璧な指示を書く必要はありません。作業が進むにつれて、キューを整え、方向を変え、承認し、次のアクションを積むことができます。ホワイトペーパーでも、steeringはCodexが既に作業中の状態で次の指示を追加し、方向修正や承認、次アクションのキューイングを行うものとして説明されています。
4. Memory：会話履歴ではなく「レビュー可能な記憶」を持つ
この記事で最も実務的だと感じたのが、Memoryの扱いです。
長期スレッドでは、会話履歴だけに文脈を閉じ込めると危険です。
なぜなら、会話履歴は次第に見通しが悪くなり、何が重要な記憶として残っているのかを人間がレビューしづらいからです。
そこで紹介されているのが、vault/ のような記憶領域です。
vault/
├── TODO.md
├── people/
├── projects/
├── agent/
└── notes/
ホワイトペーパーでは、長期スレッドでは会話外のmemoryが必要になり、有用な文脈は開ける・編集できる・diffを取れる・再利用できるものにすべきだと説明されています。
この発想は重要です。
リポジトリ = コードを置く場所
vault = 作業周辺の文脈を置く場所
という分離です。
たとえば、vault/people/ には人ごとの好みや関係性、vault/projects/ にはプロジェクトの状態、vault/notes/ には意思決定の背景や日次メモを置けます。
# projects/codex-adoption.md
## 現在の状態
- 社内PoC中
- 対象は開発ドキュメント作成とPRレビュー補助
## 決定事項
- 初期段階では外部送信をCodex単独に任せない
- PR差分の作成までは許可するが、PR作成とmergeは人間が承認する
## 未解決事項
- Slack連携の権限範囲
- vaultをどのリポジトリに置くか
GitHub上にvaultを置けば、Codexが何を「重要な記憶」として書き残したかをdiffで確認できます。
これはAIの記憶をブラックボックスにしないための設計です。
5. Computer and browser use：Codexを仕事が発生する場所につなぐ
Codexが長期作業を進めるには、実際に仕事が発生する場所へアクセスできる必要があります。
ホワイトペーパーでは、以下のような接続先が挙げられています。
- browser
- Chrome
- computer use
- Slack
- Gmail
- Calendar
- GitHub
- Skills
CodexにSlack、Gmail、Calendar、GitHubなどの作業面を接続すると、仕事が最初に発生する場所から情報を拾えるようになります。OpenAIの資料でも、connectorsはSlack threads、inboxes、calendars、docs、issue trackersといった場所にCodexを拡張するものとして説明されています。
ただし、ここは便利さとリスクがセットです。
特に注意すべきなのは、Codexに何を「見せるか」だけでなく、何を「実行させるか」です。
初期導入では、Codexに任せる操作を次の3段階に分けるのが安全です。
| 区分 | 操作例 | 方針 |
|---|---|---|
| 任せやすい | 調査、要約、差分作成、テスト実行、返信案作成 | Codexが実行してよい |
| 人間承認が必要 | PR作成、Slack返信、メール送信、デプロイ | Codexは下書き・準備まで。実行は人間の承認後に行う |
| 初期は避ける | 本番DB操作、データ削除、支払い、契約、権限変更 | Codex単独では実行しない |
Codexに広い権限を渡すほど、レビュー可能性と承認境界の設計が必要になります。
6. Remote control：長い作業を止めず、判断点だけ人間が見る
Remote controlは、Codexが作業を続けている間に、人間が別デバイスから状況を確認し、質問に答え、承認し、必要に応じて方向修正する考え方です。
たとえば、デスクで長い作業を開始し、移動中にスマートフォンから次の判断点だけ確認するような使い方です。
作業を開始する
Codexが調査・実装・検証を進める
人間は別デバイスから次の判断点を確認する
承認、差し戻し、方向修正を行う
Codexが次の作業へ進む
重要なのは、Remote controlはレビューを省略する仕組みではないという点です。
長い作業を止めないために、人間が必要な判断点だけに戻れるようにする設計です。
7. Thread automations：同じ文脈に定期的に戻る
Thread automationsは、同じスレッドを定期的に呼び出して作業を再開する仕組みとして説明されています。
たとえば、次のような指示です。
30分ごとにSlackとGmailを確認して、
対応が必要そうな未返信メッセージを探す。
関連文脈を調べて返信案を作る。
ただし、承認なしに送信しない。
ホワイトペーパーでは、thread automationsは現在のスレッドに紐づいた定期的なwake-up callであり、毎回ゼロから始めるのではなく、同じ会話に戻って文脈を保持すると説明されています。
これは、AIエージェントらしい使い方です。
普通の自動化は、決まった条件で決まった処理をします。
cronで毎時実行
APIを叩く
結果を保存する
Thread automationsでは、もう少し柔らかい作業を扱います。
状況が変わったか確認する
対応が必要か判断する
必要なら下書きを作る
人間に承認を求める
特に、Slack、Gmail、PR、デプロイ状況、サポートスレッドなど、待ち時間が長いが、変化があったら対応が必要な作業と相性がよい領域です。
8. Three examples of loops：Codexが準備し、人間が決める
ホワイトペーパーでは、長期作業の例として次の3つのループが示されています。
| 例 | Codexが準備するもの | 人間が決めるもの |
|---|---|---|
| Chief of Staff | 未対応メッセージ、関連文脈、返信案、判断が必要な質問 | 承認、トーン、タイミング、最終判断 |
| Monitor for feedback | フィードバック要約、更新レンダー、修正メモ、次のレビューリンク | クリエイティブ判断、最終承認、公開判断 |
| Get a refund | ステータス確認、返信案、証拠、次ステップ提案 | 同意、承認、不可逆な操作 |
3つに共通しているのは、Codexが「準備・調査・下書き・更新」を担当し、人間が「承認・判断・不可逆操作」を担当する点です。
これは、Codex活用の基本的な境界線として使えます。
Codexが進めること:
- 情報を集める
- 文脈を整理する
- 下書きを作る
- 差分を作る
- レビュー可能な状態にする
人間が決めること:
- 送るかどうか
- 公開するかどうか
- 承認するかどうか
- 不可逆な操作を行うかどうか
9. Goals：Codexが検証できるゴールにする
長期作業では、ゴール設定が重要です。
弱いゴールはこうです。
このMarkdownに書いてある計画を実装して
これだと、Codexは何をもって完了とすべきか判断しづらいです。
強いゴールはこうです。
このライブラリを移植する。
公開APIの互換性を維持する。
元の単体テストを成功条件にする。
同じテストが通り、差分が文書化されたらレビュー可能とする。
OpenAIのホワイトペーパーでも、弱いゴールは単に計画の実装を依頼するだけだが、強いゴールは期待動作、レビュー基準、制約、明確な完了定義を与えると説明されています。
これはCodexに限らず、AIエージェント活用全般で重要です。
AIに「やっておいて」と頼むほど、結果の評価が難しくなります。
逆に、以下を明示すれば、AIの作業はレビューしやすくなります。
- 期待する動作
- 成功条件
- 失敗条件
- 制約
- テスト方法
- レビュー対象
- 人間が判断するポイント
実務では、次のテンプレートが使いやすいです。
## Goal
何を達成したいか
## Context
背景・関連リポジトリ・既存仕様
## Constraints
守るべき制約
## Success criteria
成功条件
## Review criteria
人間が確認する観点
## Human approval required
Codexが勝手に実行してはいけない操作
## Definition of Done
完了条件
10. Side panel：成果物そのものをレビュー対象にする
Side panelは、単なるプレビューではなく、Codexと人間が同じ成果物を見ながら作業するための面として説明されています。
ホワイトペーパーでは、Markdown、スプレッドシート、CSV、PDF、スライドなどを同じ作業面でレビューでき、コメントが次の指示になり、成果物そのものが文脈になると説明されています。
これは地味ですが重要です。
チャットだけで作業すると、どうしてもこうなります。
AIが説明する
人間が読む
人間が別画面で確認する
またチャットで修正を指示する
Side panel的な作業面があると、こうなります。
AIと人間が同じ成果物を見る
人間がコメントする
コメントがそのまま次の指示になる
成果物の変化が文脈になる
コードでいえばdiff、UIでいえばプレビュー、資料でいえばスライド、データでいえばCSVやスプレッドシートがレビュー面になります。
つまり、Codex活用では「プロンプト」だけでなく、レビュー面をどう設計するかが重要になります。
実務導入するなら、どこから始めるべきか
いきなり全業務をCodexに任せるのは危険です。
最初は、次のような領域から始めるのが現実的です。
| 領域 | 理由 | 例 |
|---|---|---|
| 検証可能な開発タスク | テストやdiffで確認しやすい | リファクタ、CI修正、テスト追加 |
| ドキュメント作成 | レビューしやすく、失敗時の影響が小さい | README、設計メモ、議事録 |
| PRレビュー補助 | 人間が最終判断できる | 差分要約、懸念点抽出 |
| 定期確認タスク | automationsと相性がよい | Slack確認、Issue確認、デプロイ待ち |
| 下書き作成 | 承認境界を作りやすい | メール案、返信案、リリースノート案 |
逆に、初期段階では以下は避けるべきです。
- 顧客への最終返信
- メールの自動送信
- 本番環境への自動デプロイ
- データ削除
- 支払い
- 契約
- 権限変更
Codexには「調査・作成・差分化・下書き」までを任せ、人間が「承認・送信・公開・不可逆操作」を担当するのが現実的です。
どのように設計するか
Codexをチームに導入するなら、まず次の5つを決めます。
1. 長期スレッド化する業務を決める
すべてを長期スレッドにしない。
長期スレッド向き:
- 継続的な開発プロジェクト
- 定期レビュー
- ドキュメント整備
- 問い合わせ対応の下書き
短期スレッド向き:
- 一回限りの質問
- 小さなコード片の生成
- 単発の調査
2. vault構造を決める
vault/
├── TODO.md
├── projects/
│ └── codex-adoption.md
├── people/
├── decisions/
├── notes/
└── agent/
3. Codexが触ってよいツールを決める
許可:
- GitHub issueの閲覧
- PR差分の作成
- README編集
- Slackの指定チャンネル閲覧
- テスト実行
要承認:
- PR作成
- Slack返信
- メール下書きの確定・送信
- デプロイ操作
禁止:
- 本番DB操作
- 支払い
- 権限変更
- 顧客への自動返信
- データ削除
4. ゴール定義テンプレートを使う
## Goal
このPRの変更内容をレビューし、リスクと確認観点をまとめる。
## Success criteria
- 変更ファイルごとの要約がある
- 破壊的変更の可能性が指摘されている
- テスト観点が列挙されている
- 不明点は質問として分離されている
## Human approval required
- コメント投稿
- approve / request changes
5. レビュー面を用意する
コード -> diff / PR
ドキュメント -> Markdown
データ -> CSV / spreadsheet
UI -> preview URL
資料 -> slide / PDF
AIが何をしたかを、人間が見て判断できる形にします。
まとめ
「Codex-maxxing for long-running work」は、Codexをコード生成ツールとしてではなく、長期作業を進めるための状態管理付きワークスペースとして捉える記事でした。
重要なのは、Codexに多くを任せること自体ではありません。
むしろ重要なのは、次の設計です。
- 作業ごとに長期スレッドを持つ
- 記憶をレビュー可能なvaultに残す
- Codexが触れるツールを明確にする
- 定期的に戻るタスクをautomation化する
- Codexが検証できるゴールを与える
- 人間が承認すべき境界を決める
- 成果物そのものをレビュー面にする
Codex活用の本質は、「AIに作業を丸投げすること」ではなく、人間が判断しやすい形で、AIに作業を前へ進めてもらうことです。
その意味で、今後のAIエージェント導入では、プロンプトの書き方だけでなく、以下のような運用設計が重要になります。
どの作業を長期化するか
何を記憶として残すか
どのツールに接続するか
どこで人間承認を挟むか
何をもって完了とするか
Codexを使うなら、まずは「コードを書かせる」よりも、作業の文脈をどう維持し、どうレビューするかから考えるのがよいです。