OpenAI Codex Masterclass
結論
OpenAIのCodexが「コード生成ツール」ではなく「ソフトウェアエンジニアリングエージェント」として進化していることが紹介されています。
GPT-5.3 Codex、Cerebras上で動くGPT-5.3 Codex Spark、最新のGPT-5.4、軽量版のGPT-5.4 miniやGPT-5.4 Nanoなど複数モデルを用途で使い分けつつ、アプリ・IDE拡張・CLI・Slack・GitHubといった複数のサーフェスから同一エージェントを呼べる設計に。
さらに、プラグイン(スキル+アプリ+MCPを束ねた再利用可能なワークフロー)、オートメーション(定期バックグラウンド実行)、コードレビュー(OpenAI社内では全リポジトリの全PRがデフォルトでレビュー対象)、サブエージェント(タスクを並列分解して統合)、そしてGuardian Approvals・Hooks・Codex Securityといった実験的な安全機構まで、「任せる範囲を広げながら安全を保つ」ための仕組みが学べます。
本記事は概要と要点を示していますので、興味のある方は元動画を拝見してみてください。
💡ポイント
1. Codexは「コーディング支援」ではなく「ソフトウェアエンジニアリングエージェント」である
OpenAIはCodexを単なるコード生成ツールではなく、コマンド実行・テスト実行・コードベース探索まで担う「ソフトウェアエンジニアリングエージェント」として位置づけている。
基盤となるのはGPT-5.3 Codex、Cerebrasと連携した高速版のGPT-5.3 Codex Spark、最新のGPT-5.4、そして短時間タスクやサブエージェント向けの軽量版GPT-5.4 mini、GPT-5.4 Nanoまで複数のモデルで、その上に「Unified Agent Harness」と呼ばれる共通の実行レイヤーが乗る構造になっている。
なぜ重要かというと、モデル単体の賢さだけでなく、ツール実行・環境構築・安全制御まで含めた「現場で動くための器」を分離して進化させているからで、モデルが更新されるたびにCodex全体が自動で底上げされる仕組みになっている。
📖 用語メモ
・Unified Agent Harness: モデルの上に乗り、ツール呼び出し・環境セットアップ・安全制御を統合的に管理する実行基盤。エージェントの振る舞いを評価する役割も担う。
・GPT-5.4 / mini / Nano: 長時間タスク・複雑タスク向けの大型モデルGPT-5.4と、短時間タスクやサブエージェント向けの軽量版GPT-5.4 mini・GPT-5.4 Nano。用途で使い分ける前提で提供されている。
・GPT-5.3 Codex Spark: Cerebrasと連携した高速版モデル。テキスト中心のリサーチプレビュー版として提供されている。
2. プラグインは「スキル+アプリ+MCP」を1つの再利用可能なワークフローに束ねる
プラグインは、「スキル(繰り返し作業の手順書とスクリプト)」「アプリ連携(Notion、Linear、Google Driveなど)」「MCPサーバー(外部ツール接続)」をひとまとめにして配布できる仕組みになっている。
デモでは「Game Studio」プラグインを使い、Imagenでスプライトなどの視覚アセットを生成し、Playwright Interactiveでブラウザ上のゲームをデバッグして動作を確認しながら、簡単なプロンプトでプラットフォーマーゲームを生成していた。
なぜ重要かというと、これまで個別に設定していた「スキルを書き、MCPをつなぎ、アプリを認証する」という三層の手間が、プラグインを入れるだけに圧縮されるからだ。
実務では「自分が毎週繰り返している作業」をまずスキル化し、関連するMCPやアプリと合わせて1つのプラグインとして社内配布すれば、チーム全員の手元で同じ品質の自動化が走り始める。
📖 用語メモ
・スキル(Skill): 定型プロセスをパッケージ化した再利用可能な指示書。手順、スクリプト、参照リソースなどを含み、Codexに「やり方」を一度だけ教えればよくなる。
・MCP(Model Context Protocol)サーバー: 外部システムのツールをエージェントに公開するための仕組み。SentryやLinearなど任意のサービスをCodexから操作可能にする。
・Playwright Interactive: ヘッドレスブラウザPlaywrightをCodexから対話的に操作するスキル。クリックや遷移などのナビゲーションとスクリーンショット取得・分析を通じて、アプリの動作確認やデバッグを可能にする。
・Imagen: 画像生成モデル。Codexからスプライトや視覚アセットを直接生成する用途で使われている。
3. オートメーション:Codexを「常駐する同僚」に変える定期実行
オートメーションはCodexに自然言語で指示した処理を、決まった時刻に裏側で繰り返し実行させる機能で、cronジョブのGPT版と捉えるとわかりやすい。
登壇者は実例として「毎朝9時にSlackをチェックし、返信すべきメッセージとタイムセンシティブな投稿を抽出、重要チャネルの要約までトピックごとにまとめる」自動化と、「Gmailをスキャンして本当に返信すべきメールだけを抽出する」自動化を紹介し、「1日あたり数時間を節約できている」と述べていた。
対話型AIの弱点は「自分から呼ばないと動かない」点にあり、それを「向こうから出力が届く」非同期型に転換できるからだ。明日の最初のアクションとしては、自分が毎朝必ずやっている「情報収集→トリアージ」のうち判断ルールが言語化できるものを1つだけ選び、Codexアプリ内で日次オートメーションとして登録するところから始めるとよい。
4. コードレビュー:OpenAI社内では全PRがデフォルトでCodexにレビューされる
Codex Code ReviewはGitHubに接続することでプルリクエストに自動レビューを走らせられ、CodexアプリやCLIでは`/review`コマンドから明示的に起動できる。Claude Code向けプラグインを使えば、Claude Codeのセッション内からCodexのレビューだけを呼び出すこともできる。
OpenAI社内ではGregを含めた全社員のPRが、全リポジトリでデフォルトでCodexのレビューを通っていると明かされていた。なぜ重要かというと、レビュー対象が「差分そのもの」ではなく「リポジトリ全体の文脈」に拡張されており、変更していないモジュールへの二次的な影響まで指摘してくれるからだ。並行作業が増えるほど人間が全行を読むのは不可能になるため、「ファーストパスはエージェントに任せ、人間はP0/P1の判断と最終承認に集中する」という分業に移行することが、レビュー疲弊を防ぐ現実解になる。
📖 用語メモ
・Codex Code Review: 差分だけでなくリポジトリ全体を文脈化してレビューするCodexの機能。P0〜P2の優先度で指摘を返す。
・Claude Code向けプラグイン: 他社のコーディングエージェントClaude Codeのセッション内からCodexレビューを呼び出すための連携プラグイン。
5. サブエージェント:1つのタスクを分解し、並列に走らせて統合する
サブエージェントは、親タスクを分解可能で独立した子タスクに分け、複数のCodexプロセスを並列に走らせ、最後に結果を統合する仕組みになっている。デモでは40〜50個ほどのペルソナ定義ファイルを「20体のサブエージェントに分担させてレビューさせる」という指示を出すと、Codexが自動でPlanモードを起動し、ファイルをスライスし、各サブエージェントに担当ファイルとレビュー観点を渡してから並列実行していた。
長く逐次的に動かしていた1本の思考プロセスを、独立した視点を持つ複数のエージェントに分解できるからで、セキュリティ脆弱性分析や設計の選択肢出しに特に効く。デフォルトで提供されるペルソナは汎用フォールバックのdefault、実行に特化したworker、調査向けのexplorerの3種類で、それぞれに使用モデル、推論努力(reasoning effort)、サンドボックスモードを設定でき、レビュー系は必ずread-onlyにする、といった安全設計を行える。
📖 用語メモ
・サブエージェント(Sub-agents): 親Codexから分岐して並列実行される子エージェント。役割ごとにモデル・サンドボックス・MCPアクセスを個別設定できる。
・Planモード: タスクが複雑だとCodexが自動で起動する計画立案モード。複数ステップへ分解してから実行に移る。
・サンドボックスモード: read-only / write可など、エージェントがファイルや環境に対して持てる権限の制御。レビュー用途ではread-onlyを推奨。
・ペルソナ(.tomlファイル): 個々のサブエージェントの名前・説明・使用モデル・権限・指示を定義した設定ファイル。
6. ブリーディングエッジ:Guardian Approvals、Hooks、Codex Securityで「任せる安全」を作る
登壇の終盤では、まだ実験的な「ブリーディングエッジ」機能群が紹介された。Guardian Approvalsは、危険度の高いコマンド(ディレクトリ削除、サーバー起動、ファイルの外部公開など)が発生したときに、別のサブエージェントが「これは人間の判断が要るか」を判定し、不要なら自動承認、必要なら人間にだけ介入を求める仕組みだ。
Hooksはセッション開始時・各ツール使用後・セッション停止時の3つのイベントにフックして任意のスクリプトを実行でき、たとえば「stopフックで`keep going`を投げ続けて長時間タスクを継続させる」「startフックで最新コードをpullする」といった使い方ができる。
Codex Securityはコミット単位で脆弱性を発見してパッチを生成し、その変更の適用までCodex自身に行わせる。エージェントを本格的に常駐させると人間側の承認疲労が必ずボトルネックになるからで、「全承認(yolo mode)」でも「全確認」でもなく、判定を別エージェントに委ねる第三の道が現実的な落としどころになる。
📖 用語メモ
・Guardian Approvals: 特権的なツール実行が発生したとき、別のサブエージェントが人間介入の要否を判定する実験的な承認機構。
・YOLOモード: エージェントに事前承認なしで何でも実行させる運用モード。便利だが安全上のリスクが大きいと動画でも警告されている。
・Hooks: セッション開始/ツール使用後/セッション停止という3つのイベントでスクリプトを差し込める拡張機構。`hooks.json`で定義する。
・Codex Security: コミット単位で脆弱性を検出し、Codexが修正パッチまで生成する専用モデル/機能。
まとめ
OpenAI社内のようにSlackから日常的にCodexを呼べる環境を整えれば、IDEを開かなくてもエージェントを使えるようになる。次に、毎日繰り返している情報収集・トリアージ・データ更新といった作業を1つ選んでオートメーション化し、「呼ばなくても動く非同期型」の体験を手に入れると、エージェントへの委任感覚が一気に変わる。プラグインを使えばスキル・MCP・アプリ連携を束ねてチームに配布でき、個人の自動化をチーム標準に昇格させることも現実的な範囲に入ってくる。
並行作業が増えてきたら、サブエージェントとコードレビューの組み合わせが効いてくる。レビュー系サブエージェントはread-onlyで設定し、差分だけでなくリポジトリ全体を文脈にしたファーストパスをエージェントに任せ、人間はP0/P1の判断と最終承認に集中するという分業が、レビュー疲弊を防ぐ現実解になる。さらに本格的に常駐させる段階では、Guardian ApprovalsやHooksを活用して「全承認でも全確認でもない第三の運用」を設計することが、安全と効率を両立させる鍵になる。まずは週次で自分の過去セッションをCodexにスキャンさせ、「自動化できそうなパターン」を推薦してもらうところから始めると、次の改善点が自然と見えてくる。
この紹介に加え、テスト、自己改善、最適化を構築すると、トークンさえあれば、時間経過と共にアプリがブラシュアップされ続けるのだろうが、その指針や方向修正さえもエージェントが担う方が良いのだろうか？様々な案件を経験したメモリーを積んだエージェントが出来れば可能だろう。
本記事について
本記事はAIを基盤に、著者が学習・経験した知見を交えて構成しています。
