Codex 使い方｜長時間動くAIエージェント環境の作り方と注意点

Codexの使い方でつまずきやすいのは、プロンプトより先に「どこで動かすか」「何を触らせるか」を決めないまま走らせてしまう点です。長時間動くAIエージェント（途中で止めずに継続実行するAI）を想定するなら、環境・権限・停止点の3つを先に固定すると事故が減ります。

Codexとは（結論：コードを書くAIではなく「作業を進めるAI」）

Codexは「この関数を書いて」で終わるコーディングAIというより、リポジトリを読み、タスクを分解し、変更を積み上げていく作業者寄りの使い方が合います。最近のニュースでは、OpenAIがOnaを買収して、Codexを安全で持続的なクラウド実行環境（長時間動く前提の環境）へ寄せる方針を示しました。ここでユーザー側が得するのは、モデルが賢くなることより「放っておいても破綻しにくい段取り」を作れる点です。

個人的には、Codexは「一発で完成」を狙うほど失敗しやすいツールだと思っています。代わりに、小さな差分を積み上げる前提でプロンプトと確認点を固定すると、仕事で使える確率が上がります。

Codexでできること（長時間タスクと相性がいい3パターン）

1) リファクタや置換を「方針込み」で進める

単純置換だけでなく、影響範囲の洗い出し、テスト追加、段階的なPR分割まで含めて進める指示が向いています。

2) バグ修正を「再現→原因仮説→修正→検証」までつなげる

エラーログや再現手順を渡し、まず再現を優先させるとブレにくいです。逆に「直して」で投げると、原因に当たっていない修正が増えます。

3) 依存関係の更新と互換対応を段取り化する

ライブラリ更新は地味に時間がかかります。更新方針、破壊的変更の確認、段階的コミット、検証観点までをテンプレにすると、長時間タスクの価値が出ます。

Codex 使い方：長時間動く前提で「最初に整える」手順

ここはプロンプトより重要です。Codexを回す前に、作業場とルールを作ってください。やることは多く見えますが、1回テンプレ化すると次から速いです。

手順1：作業ディレクトリを分ける（触っていい場所を固定）

リポジトリ直下で雑に動かすと、関係ないファイルまで触り始めます。作業は「この範囲だけ」と明示できる構造にします。

• /work（Codexが触ってよい作業領域）
• /docs/agent-notes（調査メモ、判断理由の置き場）
• /scripts（実行してよい補助スクリプト。勝手に増やさせない）

手順2：秘密情報を「渡さない」前提にする（.envの扱いが肝）

長時間タスクでいちばん怖いのは、うっかり秘密情報をコミットする事故です。APIキーやトークンは、AIに貼らない。貼らないで回る手順にします。

• .envや資格情報ファイルは、最初からAIの対象外にする（読み取りも原則NG）
• 必要ならダミーの.env.exampleを用意し、AIは例だけ参照する
• ログやエラーメッセージにトークンが混ざる設定は避ける

料金や実行環境の仕様は変わるので、チーム運用するなら必ず公式ページで確認してください。

手順3：「停止点（人間の確認）」を先に置く

長時間動くAIエージェントは、速い代わりに「間違った方向に速い」です。確認ポイントを決めて、そこまでは自動、そこから先は承認制にすると現実的です。

• 依存関係更新（package.jsonやロックファイル変更）はPRを分けて確認
• 認証・課金・権限周りのコードは自動修正させない（提案だけ）
• ファイル削除は必ず事前確認（削除候補リストを出させる）

手順4：ログの置き場を決める（あとで戻れる形にする）

「何を根拠にそう判断したのか」が追えないと、直すのに倍かかります。Codexには、作業メモを固定フォーマットで残させるのがコツです。

• /docs/agent-notes/yyyymmdd-task.mdに、調査結果と判断を記録
• 変更点は「差分」「理由」「影響範囲」「未解決」をセットで書かせる

コピペで使える：Codex長時間タスク用プロンプト（計画→実行→確認）

以下は「勝手に全部やり切らない」ための型です。重要なのは、実行前に計画を出させ、危ない箇所で止める指示が入っていることです。

プロンプト1：依存関係更新（安全寄り）

あなたはこのリポジトリの保守担当です。
目的：依存関係を更新しつつ、互換性の破壊を最小化する。

制約：
- .env、鍵、トークン、認証情報に触れない。ログに出力しない。
- 認証・課金・権限まわりのコードは変更しない（変更が必要なら提案だけ）。
- ファイル削除はしない（削除候補リストを出して人の承認を待つ）。
- 変更は小さく分け、コミット（またはPR）を段階化する。

手順：
1) まず現状調査（主要依存、テスト有無、CI、実行方法）をまとめて。
2) 更新方針を3案出し、リスクが低い案を1つ選び、理由を書いて。
3) 実行計画をチェックリスト化し、人の「OK」を待ってから作業を開始。
4) 作業後は、差分の要約、影響範囲、追加したテスト、残課題を /docs/agent-notes/ に記録。

出力フォーマット：
- 調査結果
- 更新方針（3案）
- 推奨案
- 実行計画（確認点つき）

プロンプト2：バグ修正（再現優先で迷子になりにくい）

あなたはデバッグ担当です。
目的：バグを「再現できる状態」にしてから原因を特定し、最小の修正で直す。

入力：
- エラーログ：{ここに貼る}
- 再現手順（分かる範囲で）：{ここに貼る}

制約：
- まず再現に集中。推測で修正しない。
- 変更は1コミットで小さく。リファクタは混ぜない。
- 直したら、失敗していたケースを検証するテスト（または確認手順）を追加。

進め方：
1) 再現のために必要な追加情報を質問（最大5つ）。
2) 再現できた前提で「原因仮説」を2つ出し、切り分け手順を書く。
3) 切り分け後に修正案を提示し、人のOK後に実装。
4) 変更点を3行で要約し、影響しそうな箇所を列挙。

注意点：長時間動くCodex運用で起きがちな失敗と直し方

失敗1：差分がでかくなりすぎてレビュー不能

AIは勢いで広げがちです。対策は、作業単位を「PR3つまで」「1コミット100行まで」など、数で縛ること。プロンプトに入れると効きます。

失敗2：テストがないのに“直った気”になる

テストがなければ、せめて再現スクリプトか手動確認手順を成果物に含めます。「直した」ではなく「どう確認したか」を必須出力にします。

失敗3：秘密情報や個人情報がログ・差分に混ざる

これは一発アウトになりやすいので、最初から「触らない領域」を決めます。加えて、Codexの最終報告に「秘密情報が混ざっていないか自己チェック」項目を入れると、ヒヤリが減ります。

失敗4：外部コマンド実行が増えて、何をしたか追えない

エージェント系は、コマンド履歴が散らばると後で詰みます。実行したコマンドを、作業メモに貼るルールにしてください。地味ですが、ここで救われます。

Codexの使い方が向いている人

• コードは読めるが、保守タスク（更新、互換対応、地味バグ）に時間を取られがちな人
• 「自動化したい」より「確認しやすい下準備を作ってほしい」チーム
• 変更の影響範囲や手順をドキュメントに残す運用を作りたい人

逆に、レビューする人がいない環境で「全部任せたい」目的だと、Codexの良さが裏目に出ます。長時間タスクほど、承認者がいる前提のほうがうまく回ります。

まとめ

Codexの使い方は、うまい指示文を探すより「環境・権限・停止点」を先に決めるほうが成果が安定します。Ona買収のニュースが示す方向性も、長時間動くAIエージェントを前提にした環境整備です。今日からできる範囲では、作業ディレクトリの分離、秘密情報の遮断、確認ポイントの固定をセットで整えるのが近道です。

参考リンク

• OpenAI to acquire Ona（OpenAI Blog）
• Meet the OpenAI Engineer Leading ChatGPT’s Biggest Transformation Yet（Wired AI）