[Codex IDE] VS Code ユーザーが Claude Code から Codex に乗り換えてみる時の手順書

こんにちは。これまで VS Code + Claude Code の組み合わせで開発を回していましたが、2025年9月から Codex IDE に乗り換えてみました。

準備のために集めたドキュメントと、実際に移行してみて気づいたポイントをまとめ直したのがこの記事です。

テーマは「VS Code ユーザーが実務を止めずに Codex IDE に乗り換えるには？」。拡張機能の違いを押さえながら、私が踏んだ手順を振り返ります。

全体の流れをざっくり掴む

やることはシンプルで、以下の5ステップを順番に回すだけです。

今の環境を棚卸し（拡張・設定・キーバインドの洗い出し）
Codex 拡張を入れてサインインし、レイアウトを整える
Chat / Agent / Full Access の運用ルールを決めてしまう
編集・実行・レビュー・Git の日常フローを Codex に置き換える
ショートカットやプロンプトを整えて、自分たち用に最適化する

1. 乗り換え前にサクッと整える（5分）

いきなり入れ替えるより、先に周辺を片付けておくと後が楽でした。

Claude Code の拡張は一旦無効化（競合防止。必要になったらすぐ戻せます）
VS Code 本体は最新版にアップデート
Codex 用にサインインできる OpenAI/ChatGPT アカウントを用意
Windows ユーザーは WSL を準備しておくとパスやシェルのズレで悩まない

2. Codex 拡張を入れて動かす（10分）

ドキュメントの手順通りに進めつつ、VS Code の見た目がどう変わるかを意識すると安心感があります。

サイドバーの拡張機能タブで「Codex」を検索 → OpenAI 公式の拡張をインストール
インストール後、サイドバーに出る Codex アイコンを押してサインイン
チャットペインは右側にドラッグ固定すると、コードと横並びで使いやすい
モデルはデフォルトのままでOK。必要になったら UI から切り替えれば十分

3. モード運用を合意してから触る

Codex IDE は権限レベルで 3 つのモードが切り替わります。ここを決めておかないと、誰かがうっかりフル権限で動かしてヒヤッとします。

Chat（Read-Only）：読み取り専用。設計相談やレビューで使う
Agent：ワークスペースへの編集とコマンド実行を許可（通常ここがデフォルト）
Agent – Full Access：ネットワークや外部領域までフル権限。原則封印

4. Claude Code とどう違う？（操作感の比較）

実際に触ってみると「できること」よりも「どう操作するか」「承認をどう挟むか」の設計が大きく違います。ざっくり比較するとこんな感じでした。

観点	Claude Code（拡張/CLI）	Codex IDE（VS Code 拡張）	乗り換え時のメモ
UI統合度	もともと CLI 中心。拡張はあるが CLI 連携色が強い	VS Code に深く統合（チャット/差分適用/承認が一体）	差分プレビュー→適用が速い
実行モード	Plan/Auto などの運用慣習	Chat / Agent / Full Access の 3 段階	まず Chat→Agent で安全に
変更の提示	提案→適用（承認フローあり）	提案をエディタで diff 表示→承認適用	Git 差分と合わせて安全に戻せる
選択範囲連携	選択範囲/ファイルを会話に添付	選択範囲をそのまま送信可	「この塊だけ」運用がしやすい
モデル切替	スラッシュコマンド等	UI から切替（用途に応じて）	深い推論が必要な時に変更
キーバインド	CLI/拡張混在	コマンドパレット/ショートカットが充実	よく使う操作に割当て推奨
ターミナル実行	CLI からの操作が得意	Agent がターミナル実行（要承認）	テスト/ビルドを任せやすい
クラウド実行	自前運用が中心	（実装有無は環境依存）ローカル/クラウドの住み分けがしやすい設計	重い処理のオフロードに相性良
GitHub 連携	ワークフローに組み込み可	PR レビュー等のワークフロー連携に相性が良い	「設計相談→PRレビュー」導線が短い
拡張/プラグイン	CLI 側に仕組みあり	拡張はIDE統合に集中	「IDE内で完結」が強み

特に気に入っているのは、差分プレビューと承認が VS Code の標準 diff とほぼ同じ感覚で使えるところ。CLI でゴリゴリ進めるより、エディタの延長線で完結するのが Codex の良さだと感じました。

5. まずは 15 分だけ触ってみる

導入直後は、Chat モードで小さなタスクを2〜3個お願いしてみるのがおすすめです。私は以下のような流れで慣らしていきました。

Chat モードで「この関数、引数を増やして呼び出し箇所もまとめて直して」など小粒な修正を頼む
同じく Chat で「このテストケースを Jest で追加し、失敗ログを見せて」と依頼し、出力の癖を確認
提案された diff を目で追いながら手で適用し、安心感を得る
問題なければ Agent モードに切り替え、npm test の実行や ESLint 設定の整備を任せてみる

6. プロンプトと運用テンプレ

狙いを一行で伝えたうえで、前提・制約・ゴールを短く並べると、Codex の理解度が安定します。

狙い: service 層にリトライを追加してタイムアウトを軽減
前提: axios 使用/共通のloggerあり/既存テストは通す
制約: 外部APIのインターフェースは変えない
完了: 変更差分+テスト更新+失敗時のログ例を提示

編集系の定番プロンプト（選択範囲に対して）

「この範囲の副作用をなくす形でリファクタ。I/O は関数外に寄せて」
「この diff を説明→適用。懸念があれば適用前に質問して」

実行系の定番プロンプト

「パッケージを更新せず、現状の lock を維持したままテストだけ実行。落ちた箇所を要約して」
「依存が壊れたら中断し、必要な前提条件を列挙してから続行して」

7. よくあるつまずきと対処

複数の AI 拡張が衝突したら、まずは Codex だけ有効にして挙動を確認
勝手に書き換えられそうで怖いときは、Chat で提案を確認してから Agent へ昇格。Git 管理を徹底
外部アクセスが心配なら Full Access を封印し、ネットワークアクセスは都度承認にする
巨大リポジトリで迷子になったら、ワークスペースを対象ディレクトリに絞り、選択範囲ベースで会話
ログが長いときは「まずは要約でお願いします」と伝え、箇条書き出力をルール化

8. VS Code 向けおすすめ設定

キーバインド例（`keybindings.json`）

[
  {
    "key": "cmd+shift+.",
    "command": "codex.toggleChat",
    "when": "editorTextFocus"
  },
  {
    "key": "cmd+enter",
    "command": "codex.sendSelection",
    "when": "editorHasSelection && editorTextFocus"
  },
  {
    "key": "cmd+shift+enter",
    "command": "codex.applyLastChange",
    "when": "editorTextFocus"
  }
]

設定の指針

diff を必ず経由（自動適用は段階導入）
プロジェクト毎にモード方針を README に明記
保存時フォーマットは人間/AI の両方で同じに設定し、整形差分を減らす

9. 1 時間で雰囲気を掴むスケジュール

移行初日にやったミニスケジュールも置いておきます。約 1 時間で主要機能を一周できます。

インストールとサインイン（10分）
Chat モードで小さな関数リファクタと TODO 実装提案を試す（15分）
Agent モードで単体テスト追加＋ログ要約、Lint 設定の調整を任せてみる（20分）
よく使うショートカットを keybindings.json に登録（5分）
運用ルールを README や Notion に反映（10分）

10. チェックリスト（配布用）

Claude Code 拡張は 無効化（一旦）
Codex 拡張 インストール & サインイン
Chat→Agent の 2 段階運用で開始（Full Access は使用しない）
Git 管理と diff 確認を徹底
キーバインドを 3 つだけ入れる（開閉/送信/適用）
README に モード方針/承認ルール/機密方針を記載
初週は「選択範囲ベースの小粒タスク」だけを任せる

まとめ

Codex IDE は VS Code の操作感に自然と溶け込む。diff → 承認 → 適用の距離が短い
運用は Chat で提案を確認し、慣れたら Agent で実行する二段構え。Full Access は封印
乗り換え初期は選択範囲ベースの小粒タスクから。ショートカットとルールで迷いを減らす

「ツールの違い」は“できる／できない”よりも、操作・承認・可視化の設計の違いです。この記事をチームの README や Notion に貼って、最初の 1 週間だけでもルールを固定してみると移行のストレスがかなり減りました。