OpenAIエンジニアによるCodexを「自律エージェント」として使い倒すための勉強会レポート

こんにちは、DeNA ヘルスケア事業本部ウェルビーイング事業部DXソリューション部の川上知宏です。

現在弊社では「AI オールイン」を掲げ、プロダクト開発のあり方そのもののアップデートに取り組んでいます。今回はその一環として、OpenAI 社から 3 名の講師をお招きし、OpenAI が提供する、複雑なタスクを自律的に実行し、人と協働しながら仕事を前に進める AI エージェント「Codex」に関する勉強会を開催しました。オンラインで開催された 1 時間のセッションには、300 名を超える社員が集まり、大規模な勉強会となりました。

この記事では、その時のレポートとして、Codex を長時間安定して自律的に動かすためのプラクティスや、計画の外部化手法など、OpenAI 社のエンジニアから直接聞いた実践的な知見をまとめています。

イベント概要

日時：2026/04/23 17:00 - 18:00
会場：オンライン
講師：Nakano Takeshige 氏、Ishida Shuhei 氏、Utsunomiya Shoko 氏
参加者：約 310 名
アジェンダ：
- 解説（40 分）
  - ハーネス最適化
  - Codex を長時間走らせる
  - Codex の高度な設定
- Q&A（20 分 ※盛り上がりにより 5 分ほど延長）

長時間安定してタスクを実行するために

今回の勉強会で一貫して扱われたテーマは「どのようにして Codex に自律的にタスクを遂行してもらうか？」でした。今回の勉強会で扱われた内容で公式ドキュメントの関連のあるものは、関連資料のセクションにも記載しています。

Codex の強み

Codex の強みを整理すると、次のような点が挙げられます。

高い指示追従能力
- 与えられた指示に沿いながら、目的を見失わずにタスクを進める。
高い推論能力
- 実行結果や現在のコードベースの状態を踏まえ、次に取るべきアクションを提案・実行しやすい。
コンテキストコンパクション機能
- コンテキストの自動圧縮機能により、コンテキストが埋まってもタスクを中断したり、ドリフトしたりせずにタスクを進める。

長時間タスク遂行のための基礎

長時間に渡ってタスクを遂行してもらうために、まず意識するべきなのは次の 3 点です。

完了条件の明確化
- 「何を達成できたら完了か」という観点を明確にする必要がある。
- アプリケーションのコード自体が書けた状態を目標にするのではなく、「動作の検証（テストなど）がすべてパスしていること」を目標として定義することが大切。
マイルストーンごとのエージェントによる自己検証の徹底
- タスクを細かく分割し、1 つのマイルストーン終了時に lint, build, test などを実行させ、それらの検証がパスした後に次のステップに進むようにすることが大切。
- これらのルールは AGENTS.md レベルで徹底させる。
知識・計画の外部化
- こちらについては、次の章で扱います。

とくに大切な点：知識・計画の外部化

目標や検証内容、アプリケーションの仕様などをすべてプロンプトだけで保持しようとすると、不要な情報でコンテキストが圧迫されるため、挙動が不安定になることがあります。これを防ぐために、知識や計画は外部のファイルに書き出して管理します。

プロダクトの知識に関わるドキュメント作成時のポイント

知識に関わるドキュメントを 1 つのファイルで作成する場合、プロンプトで大量の情報を与えた場合と同様に、不要な情報でコンテキストが圧迫されるという問題が起こり得ます。この問題を回避するために、ドキュメント自体を構造化し、Codex にはドキュメントのツリーの構造を渡すようにします。 AGENTS.md では簡潔な目次を記載し、それぞれのドキュメントへのパスを記載します。ドキュメントの内部にサブディレクトリがある場合は、サブディレクトリ内に index.md のような目次となる md ファイルを準備することも有効です。（下記例の※）このような対応により、Codex が必要な時に必要な情報だけを探索して取得できるようになります。

ディレクトリ構成の例

AGENTS.md                 <- Codex が参照する全体方針とドキュメントの目次
docs/                     <- ドキュメントをまとめたディレクトリ
├── plans.md              <- 計画・進捗に関するドキュメント
└── design/               <- デザインに関する情報をまとめたディレクトリ
    ├── index.md          <- ※ design ディレクトリ内の目次
    ├── color.md          <- 具体的な色の定義
    └── components.md     <- 具体的なコンポーネントの仕様

計画を外部化する手段として紹介された具体例

計画を外部化する手段として、次の 3 つのアプローチが紹介されました。

プランモード（環境によっては /plan コマンド）
- Codex で利用できるコマンドの一つ。
- 実装する前に、コンテキストの収集や、質問を通した方針のすり合わせを行うことができる。
ExecPlans
- 標準的なガイドラインを md ファイルとして作成しておき、タスク実行時にはその md ファイルに従うように指示する。
- 計画したファイルを更新しながら Codex が作業することにより、ドリフトを抑える効果がある。
- 詳細: Using PLANS.md for multi-hour problem solving
複数マークダウンファイルによる知識の外部化
- ExecPlans の方法を拡張し、目的に応じてさらに細かく md ファイルに分割して計画を管理します。
- 詳細: Run long horizon tasks with Codex

長時間タスクに向いているユースケースの例

ここまでの説明にある通り、目標とその検証の設定が明確にできるタスクの場合に、Codex は安定して長時間タスクに取り組むことができます。ユースケースの例としては次のようなものが挙げられます。

向いている例
- リファクタリング・マイグレーション
- SDK・API の移行
- 既存プロダクトへのスペックドリブンな機能実装
条件付きで向いている例
- グリーンフィールドの大きめの開発
  - plan・spec・validation などが明確に定められている場合は可能
- Data・content pipeline の自動化
  - 入力・出力・評価プロセスが明確に定められている場合は可能
あまり向いていない例
- 要件探索
- 受け入れ基準が主観的なタスク

Q&A セッション

解説終了後には質疑応答の時間もありました。さまざまな視点や観点で多くの質問が飛び交い、Codex というツールの活用の幅広さや、社員が持っている関心の高さを実感しました。ここでは、いくつかの質疑応答を抜粋して紹介します。

Q1. 手触り感が必要な UI への対応策はあるか？
- UI の手触り感が重要な場面では、ChatGPT Images 2.0 などの画像生成機能を Codex 上で活用してデザイン案を何度か生成・修正し、その結果を踏まえて実装に進む方法が紹介されました。
Q2. 他の AI エージェントツールと比較したとき、Codex がとくに優れているタスク領域はどこか？
- Codex の強みは「指示に忠実に従う能力」と「高いリーズニング能力」がよく挙げられる。また、長時間タスクにおいても強いとよく言われている。
Q3. ゴールが明確でない「探索型」のタスクにおいて、有効なアプローチやベストプラクティスはあるか？
- 探索型タスクは「長時間走らせる」という観点では相性が良いとは限らないものの、Codex のプランモード（環境によっては /plan コマンド）を活用したアプローチとは相性が良い。また、テクニカルな手法として、複数のサブエージェントを同時に立ち上げ、それぞれ異なる観点でアイデア出しを行わせ、それらを統合しながらイテレーションを回していく手法も有効だ。

印象に残ったこと

① Codex が扱えるのは、Codex が認識できるもの

「何を当たり前のことを言ってるんだ？」と思われた方もいるかもしれません。ここで大切だったポイントは、人によるチェックが必要になった場面で、その問題は、エージェント自身が認識できる情報が不足していたために、タスクを先に進めることができなかったのか？を考えた方が良いということです。

例として挙げられていたのは、画面構成のチェックやログ、メトリクスの確認です。画面構成の確認には、スクリーンショットや DOM スナップショットを用いること、ログやメトリクスの確認には LogQL や PromQL を利用することでエージェント自身が判断に必要な情報を参照しやすくなります。エージェント利用時に自身が確認に入らないといけない場面に遭遇したら、何のために自分が必要だったのかを整理し、それをエージェントが認識し解決する方法がないかを調べようと思いました。

② 人のタスク管理にも通じる長時間タスクの原則

Codex に長時間にわたってタスクを遂行してもらう、というテーマの最初に説明されたのは、目標・完了条件・受け入れ条件を明確に定義すること、タスクを分解させ、それぞれのマイルストーンに応じた検証環境を準備・実施し、パスしない限り次のステップには進ませない仕組みを作ることでした。

このような内容自体は、エージェントを利用した開発を進めるにあたり、よく言及されることだと思います。私の印象に残った理由としては、あまりにも人のタスク管理にも当てはまる内容だと再認識したからです。普段の、コーディングのタスクかどうかにかかわらず、チームメンバーへの依頼や自分自身のタスクを進める際に、もっと正確に計画をたて効率化する余地があるかもしれないと考えさせられました。

③ エージェントの承認・安全性に関する仕組み

こちらは、Codex の承認・安全性に関する機能として紹介されました。これは、エージェントによるリスクの高い操作時に、人が行わなければならない確認を専用のサブエージェントに移譲できる仕組みになります。人が確認する負担を軽減させつつ、リスクを適切に見極めようとする機能が、Codex の機能としてサポートが進められていることは、非常にありがたく感じました。