Codex を IDE に入れると、最初は「エディタ横にチャットが出るだけ」と見えます。けれど実務では、開いているファイル、選択範囲、差分レビュー、ローカル実行、cloud への委譲、MCP 設定、permission profile が同じ導線に乗ります。ここを曖昧にすると、ちょっとした修正を cloud task に投げすぎたり、逆に時間のかかる調査を IDE の短い会話で抱え込んだりします。
この記事では、2026年8月27日時点の OpenAI 公式ドキュメントを前提に、Codex IDE extension を editor context 付きの local 作業レーンとして設計する方法に絞って整理します。Codex 全体の立ち位置は Claude Code vs Codex CLI 比較、権限や profile の切り替えは Codex config profile 設計ガイド、UI 検証は Codex browser use ガイド、既存 Chrome profile を使う作業は Codex Chrome extension ガイド に分けています。
今回扱うのは、IDE に開いている文脈を Codex に渡す作業、エディタ上で差分を確認する作業、長い仕事を cloud へ逃がす判断、CLI / desktop / plugin との境界です。
先に結論: IDE extension は「今見ているコードを短く直す」場所にする
私なら、Codex IDE extension の役割を次のように固定します。
| レーン | 向いている仕事 | 避ける仕事 |
|---|---|---|
| IDE extension | 開いているファイルの説明、小さな修正、選択範囲のリファクタ、差分確認 | 長い調査、複数 PR 並列、定期実行、広い権限が必要な外部操作 |
| Codex CLI | terminal 中心の実装、script / test 実行、profile 切替 | editor context に依存する細かい選択範囲修正 |
| Codex cloud | 長時間の調査、並列 task、GitHub / Linear 起点の作業 | 手元の未保存ファイルや選択範囲だけが重要な修正 |
| Desktop app | project / thread / worktree / review の管理 | IDE の選択範囲だけを使った短い修正 |
OpenAI の IDE extension docs は、open files や selection を prompt に持ち込み、差分をエディタ横で review し、長い仕事は cloud に委譲できる導線として説明しています。つまり IDE extension は、補完ツールではなく editor context を起点にした Codex の入口です。
editor context は便利だが、常時 ON にしない
IDE extension の一番の価値は、今開いているファイルや選択範囲を説明し直さなくてよいことです。たとえば、retry.ts と retry.test.ts を開いた状態で「この retry の flaky test を直して」と頼めば、Codex はその文脈から始められます。
ただし、私は editor context を常時 ON にはしません。
| 状況 | editor context |
|---|---|
| 開いているファイルが今回の対象だけ | ON |
| 関係ない顧客資料や secret を開いている | OFF |
| 依頼内容を明示的に path で指定する | OFF でもよい |
| desktop app から同じ project の chat を続ける | 必要なときだけ ON |
OpenAI の developer settings では、desktop app と IDE extension が同じ project で active chats と editor context を共有でき、app composer から IDE context をオンオフできると整理されています。便利ですが、共有されるのは「見てほしい文脈」だけにします。
悪い頼み方はこうです。
開いているものを見て、よさそうに直して。よい頼み方はこうです。
Open editor context only for src/retry.ts and tests/retry.test.ts.
Fix the off-by-one retry count.
Do not touch backoff.ts unless the test proves it is necessary.
Run the focused retry test and summarize the diff.IDE context は説明を減らすためのものです。対象範囲を曖昧にするためのものではありません。
local と cloud の切り替えを最初に決める
IDE extension では、短い local 作業と長い cloud 委譲の両方に進めます。ここを混ぜると、作業単位が崩れます。
私の基準は単純です。
| 判断軸 | local のまま | cloud へ委譲 |
|---|---|---|
| 所要時間 | 数分から十数分 | 30分以上かかる |
| 文脈 | open files / selection が中心 | repo 全体、issue、複数資料 |
| 検証 | 手元で focused test を回す | isolated environment で広めに回す |
| レビュー | エディタ横の diff で十分 | PR / task result として戻す |
| 並列性 | 今の作業を止めて見る | 裏で走らせて後で確認する |
小さな修正を cloud に逃がしすぎると、戻ってきた結果を review する時間の方が重くなります。逆に、大きな migration を IDE の local chat で抱えると、context が散って中断しにくくなります。
実務では、最初の prompt に次の一文を入れるだけでも安定します。
If this requires repo-wide investigation or more than 20 minutes, stop and propose a cloud task instead of editing broadly.Codex IDE extension は、作業が育ったときに cloud へ逃がせるのが強みです。だからこそ、どこまでを local iteration として扱うかを先に決めます。
config.toml と MCP は CLI と共有される前提で見る
Codex IDE extension は、CLI と同じ config.toml レイヤーを共有します。OpenAI の developer settings でも、agent configuration は app / IDE extension / CLI で同じ設定を継承し、MCP 設定も config.toml にあるため CLI と IDE extension に適用されると説明されています。
これは便利ですが、事故ポイントでもあります。
たとえば CLI 用に強めの profile を作っていた場合、IDE extension でも同じ権限が見えることがあります。
[profiles.deep-fix]
sandbox_mode = "workspace-write"
approval_policy = "on-request"
model_reasoning_effort = "high"この profile を IDE で使うなら、次を確認します。
- writable roots は editor で開いている project に限定されているか
- network policy は必要な domain だけか
- MCP server は read / write の境界が分かれているか
- approval が必要な tool call を見落とさないか
- focused test ではなく broad command を勝手に走らせないか
設定は「CLI で安全だったから IDE でも安全」とは言えません。IDE は open files と selection が強いので、見えている文脈の混入も考えます。profile の設計自体は Codex config profile 設計ガイド 側に寄せ、この記事では「IDE でも同じ設定が効く」前提だけ押さえれば十分です。
plugin 前提の手順を IDE extension に持ち込まない
Codex plugin governance の記事でも触れましたが、plugin は surface 差分を持ちます。OpenAI の glossary でも plugin は web / desktop / CLI での利用が中心として整理され、IDE extension とは同じ扱いではありません。
そのため、IDE extension 用のチーム手順に次のような指示を書くのは危険です。
Google Drive plugin で仕様を読み、Airtable plugin で進捗を更新してから実装して。IDE extension では、まず local repo と editor context を中心にします。外部アプリや plugin が必要なら、desktop / web / CLI の適切な surface に切り替えます。
| 必要なもの | 使う場所 |
|---|---|
| open file / selection / focused diff | IDE extension |
| external app plugin | desktop / web / CLI の対応 surface |
| localhost UI 確認 | built-in browser |
| 既存 Chrome login | Chrome extension |
| 定期実行 | Automations |
これを分けないと、「IDE で動くはずの手順」が現場で止まります。実装チームへ配る runbook では、必ず実行 surface を書きます。
review はエディタ横で終わるものと PR に戻すものを分ける
IDE extension の diff review は、短い修正では非常に便利です。要約、変更行、follow-up を同じ場所で確認できます。ただし、これで全ての review が終わるわけではありません。
私なら、次のように分けます。
| 変更 | IDE 内 review でよいか | 追加 gate |
|---|---|---|
| test 名の修正 | よい | focused test |
| 1関数の off-by-one | よい | focused test + diff確認 |
| auth / permission | 足りない | PR review + security review |
| migration / data repair | 足りない | rollback / dry-run / 人間 gate |
| UI regression | 足りない | browser screenshot / viewport確認 |
IDE extension は、差分を見やすくします。しかし、受け入れ判断そのものは別です。重い差分は Codex レビュー完了ゲート設計ガイド の scope / evidence / verification / risk / reviewability へ戻します。
チーム導入時の最小ルール
Codex IDE extension をチームに配るなら、最初から全員に強い設定を渡さない方がよいです。私は次の 7 項目だけを標準化します。
- open files / selection を使うときは対象 path を prompt に書く
- 関係ない機密ファイルを開いたまま IDE context を ON にしない
- local で 20 分を超えそうなら cloud task へ切り替える
- CLI と IDE extension が
config.toml/ MCP を共有する前提を明記する - write profile は project ごとに分ける
- plugin が必要な workflow は IDE extension 前提にしない
- auth、billing、permission、migration は IDE 内 review だけで merge しない
この程度でも、導入直後の事故はかなり減ります。
よくある失敗
1. IDE extension を補完ツールとしてだけ見る
Codex IDE extension は、ただの inline completion ではありません。editor context、diff review、local / cloud の切り替え、config / MCP まで含む作業入口です。
2. open files を全部信頼する
開いているファイルは便利な context ですが、今回の作業対象とは限りません。対象 path を prompt で固定します。
3. CLI の強い profile を IDE で常用する
CLI で使う deep work profile を IDE でも既定にすると、短い修正に過剰な権限が乗ります。IDE 用の通常 profile は狭くします。
4. plugin が使える前提で runbook を書く
IDE extension で plugin 前提の手順を書くと、実行 surface の差分で止まります。外部 app が必要なら desktop / web / CLI 側の手順へ分けます。
5. 長い仕事を editor chat に抱え込む
IDE extension は今見ているコードに強いです。長い調査、並列 task、review queue は cloud / Automations / worktree へ逃がす方が安全です。
まとめ
Codex IDE extension は、Codex をエディタに閉じ込める機能ではありません。今見ているコード、選択範囲、差分 review を起点に、必要なら CLI、desktop、cloud、browser、Chrome extension へ作業を分岐する入口です。
最初に決めるべきことは、どの IDE を使うかではなく、editor context をいつ渡し、local でどこまで直し、cloud へいつ逃がし、どの config / MCP / permission profile を共有するかです。
短い修正は IDE extension で速く回す。長い仕事は cloud へ委譲する。外部アプリや plugin は対応 surface に分ける。重い差分は review gate に戻す。この線引きを持つだけで、Codex IDE extension は「便利な横チャット」ではなく、実務の AI コーディングレーンとして使いやすくなります。