GPT o3 + Codex CLI | 大規模コード診断編

本日の「o3 ＋ Codeex CLI」リリースのライブ配信で披露された大規模コード診断デモの全手順を順を追って解説する。読後すぐに自分のリポジトリで再現できることを目標とする。尚、本日午前2時からライブ配信された内容は、下記のNoteに詳しく解説したので併せて参照いただきたい。

従来の GitHub／エディタ／ターミナル連携との決定的な違い

従来の “Work with Apps” 連携は、アクセシビリティ API 経由で 画面に映っているテキストバッファだけ を取得していた。IDE 上で開いているファイル片や直近 200 行のターミナル出力を読み取って推論する仕組みであり、次のような制約があった。

• ファイル全体が読み込まれないため、大規模リポジトリでは文脈が欠落しやすい。

• macOS の TCC 権限やアクセシビリティ API 変更に影響を受け、OS アップデートのたびに動かなくなるケースが多発。

• Windows／Linux で同等 UX を実現するには別実装が必要で、クロスプラットフォーム展開に難があった。

• 実行系を持たないため、pytest や valgrind を直接走らせることができず、バグの再現・修正・検証を人間が補助する必要があった。

これに対し、新登場の Codeex CLI は「ディレクトリ単位でモデルに引き渡し、モデル側が grep, pytest, git apply などを自律実行する」方式を採る。

• 全ファイル／テストにアクセス…解析範囲はワークスペース全体。長い思考鎖と 600 回規模のツール呼び出しが可能。

• OS 非依存…CLI は Node 製で、macOS・Linux・Windows いずれも同一手順。

• 再現性とサンドボックス…パッチとテストログが残るため CI への組み込みが容易。CLI 内部で Docker もしくは Firejail を自動起動し、作業ディレクトリ外への書き込みを遮断。

※「Work with Apps （VS Code ／ Terminal 連携）」が一般提供から姿を消したのは、公式に細かい理由は公表されてはいないが、当時の内部メモやサポート記事から読み取れる背景は次のような複合要因だ。

環境準備

1. Node.js 22 系以上と Git をインストール。 2. OpenAI API キーを取得し、環境変数 OPENAI_API_KEY に設定。 3. （推奨）Docker をインストールし、ビルドツールやテストランタイムを含むベースイメージを用意。

Codeex CLI の導入

npm install -g @openai/codex

CLI が導入できたら codex --help で確認。恒常的に o3‑high を使う場合は ~/.codex/config.yaml に model: o3-high を書いておく。

Docker イメージの雛形

FROM ubuntu:22.04
RUN apt-get update && \
    apt-get install -y git build-essential python3 python3-pip curl valgrind cmake
RUN curl -fsSL https://deb.nodesource.com/setup_22.x | bash - && \
    apt-get install -y nodejs && npm install -g @openai/codex
WORKDIR /workspace

ビルド後、API キーを渡して起動。

docker build -t codeex-env .
docker run --rm -it -e OPENAI_API_KEY=$OPENAI_API_KEY -v $(pwd):/workspace codeex-env bash

実行ステップ

1. リポジトリを clone またはホストからマウントし cd your-repo。
2. suggest モード で起動し、原因調査と修正を依頼。

codex run --approval-mode=suggest \
  "Ubuntu22.04 + Clang17 でだけ発生するメモリリークを再現し、修正パッチと回帰テストを生成して"

3. CLI が提案するコマンドを逐次承認し、パッチが適用されたら git diff で確認。 4. テストが緑になれば完了。CI に組み込む場合は --approval-mode=full-auto に切り替えて自動化。

以上で、o3 ＋ Codeex CLI を用いた大規模コード診断の基本セットアップは完了する。残るのは実際に手持ちのリポジトリで走らせ、600 連鎖の思考プロセスがどのようにバグを削り取っていくかを体感するだけだ。