CodexをVS Codeで使う方法｜拡張の設定と差分確認

CodexをVS Codeで使うには、公式のCodex拡張を入れ、作業するプロジェクトを開きます。最初は対象のファイルや関数を示して小さな修正を頼み、変更された行とテスト結果を同じエディタで確認するところまでを一組にすると、依頼と結果のずれを見つけやすくなります。

この記事はOpenAIの公式資料に基づく解説です。下のコードと依頼文は、操作の考え方を学ぶために編集部が作った教材です。教材のコード検査と、Codex拡張を動かした実測は区別しています。 本記事では製品操作の実測は行っていません。

CodexをVS Codeで使い始める手順

公式のIDE拡張の案内から、VS Code用のインストールリンクを開きます。拡張の識別子はopenai.chatgptです。名前が似た拡張を選ばないよう、この識別子と発行元を確認してください。すでに導入済みなら、同じ拡張が有効かを確かめます。

1. VS Codeで、今回の対象プロジェクトを開く。
2. 公式リンクからCodex拡張をインストール、または有効化する。
3. Codexアイコンからサイドバーを開き、表示されるサインインの案内を進める。
4. 対象ファイルを開き、まず内容の説明を頼む。

アイコンが見当たらない場合は、コマンドパレットを開き、Codex: Open Codex Sidebarを実行します。コマンドパレットのキーはMacがCmd+Shift+P、Windows/LinuxがCtrl+Shift+Pです。サイドバーが開いたことと、サインインして依頼できることは別なので、入力後の応答まで確認しましょう。

変更を頼む前には、現在の変更一覧を見て、自分がすでに編集している箇所を把握します。公式も作業前後のGitチェックポイントを勧めています。既存の変更とAIの変更が混ざる場合は、対象を分けるか、作業前の差分を残してから進めてください。CLIの導入全体を知りたい場合はCodexのインストール手順へ進めます。

VS Codeで選択したコードをCodexへ渡す

IDE拡張の特徴は、いま開いているコードを依頼の文脈に使えることです。公式のプロンプトガイドでは、開いたファイルが自動で文脈に含まれると説明されています。ただし「選択した関数を説明して」と「このファイル全体を変更して」は異なる依頼です。参照させる内容と、変更を許す範囲をそれぞれ伝えます。

公式のコマンド一覧では、選択範囲の追加はchatgpt.addToThread、ファイル全体はchatgpt.addFileToThreadです。頻繁に使う場合は、キーボードショートカット設定で「Codex」またはコマンドIDを検索し、キーを割り当てられます。

自動で渡る文脈を切り替えるには、公式のIDEコマンド一覧にある/ide-contextをCodexの入力欄で選びます。これは文脈の自動追加の切り替えであり、選択外のファイルを絶対に読まない、編集できないという権限制限ではありません。参照内容が合っているか不安なときは「最初に参照したファイルと関数名を挙げて」と頼むと、別ファイルを前提にしているずれを早く見つけられます。

VS Codeで小さな修正を頼む教材

例として、空白を除いて名前を表示し、空欄なら「ゲスト」を返すJavaScript関数を考えます。以下は編集部の教材で、Codex拡張の実際の応答を再現したものではありません。実務のプロジェクトへそのまま貼らず、練習用フォルダのdisplay-name.mjsで試す想定です。

export function displayName(name) {
  return name.trim();
}

まず関数を選択して文脈へ追加し、変更せずに説明させます。この段階では、期待する結果と現状の違いを揃えることが目的です。

選択したdisplayName関数を説明してください。
この段階ではファイルを変更しないでください。
"  いち  "、"   "、""を渡したときの戻り値を挙げ、
空欄を「ゲスト」にする要件との差を説明してください。

この教材の修正前の結果は、順に「いち」、空文字列、空文字列です。説明が一致したら、変更範囲と確認条件を添えて依頼します。「よしなに直して」だけでは、入力型の変更や別機能の追加まで進むか判断できません。

display-name.mjsのdisplayNameを修正してください。
前後の空白を除いた結果が空なら「ゲスト」を返してください。
入力は文字列のまま、関数名とexportを維持してください。
変更はこの関数と対応する最小限のテストに限定してください。
上の3入力に加え、"たろう"が変わらないことを確認してください。
最後に変更ファイル、実行した確認、未確認の点を報告してください。

条件を満たす実装の一例は次のとおりです。Codexがこの通りのコードを返すという保証ではなく、差分を見る際の比較例として使います。

export function displayName(name) {
  const trimmed = name.trim();
  return trimmed || "ゲスト";
}

この例は文字列だけを入力とする仕様です。nullや数値にも対応するなら、それは別の要件として相談します。今回の修正に無関係な型変換を加えないことで、どの問題を直したかが明確になります。実際の案件では、既存テストの書き方や関数の呼び出し元も確認してから依頼範囲を決めてください。

Codexの差分をVS Codeで確認する順番

公式では、要約と差分をコードのそばで確認し、同じチャットで追加修正できると案内しています。要約を読んだら、実際に変更されたファイルと行へ進みます。「修正しました」という応答だけで、期待した動作まで確認できたとは判断しません。

1. ファイル：依頼した関数とテスト以外に、設定や依存関係が変わっていないか。
2. 変更行：空欄の扱いだけが変わり、関数名・export・通常入力の処理が保たれているか。
3. 確認結果：何を実行し、何件を確認し、失敗や未実行が残ったか。
4. 利用する場所：その関数を使う画面や処理でも、必要な範囲の確認が済んだか。

教材では、修正前後をローカルのNode.jsで照合しました。4入力のうち空欄2件だけが「ゲスト」に変わり、通常入力2件は同じ結果でした。これは教材コードの検査結果であり、拡張の操作や実アプリの画面を検証した結果ではありません。

不要な変更を見つけたら、ファイルと行、戻してほしい理由を指定します。自分の未保存・未コミットの編集もある状態で「全部元に戻して」と頼むと、残したい変更を区別できません。「今回追加したこの処理だけを戻し、作業前からの変更は維持して」と範囲を伝え、戻した後も差分を読みます。レビュー観点を広げたい場合はCodexのコードレビュー手順が参考になります。

VS Code側とCodex側の設定を分ける

公式の設定ページは、設定を二つに分けています。画面や入力操作はVS Codeの設定、エージェントの動作はCodexの設定です。似た名前でも、書き込む場所が違います。

chatgpt.*をconfig.tomlへ貼っても、拡張のエディタ設定にはなりません。共通設定の配置や優先順位はconfig.tomlの設定解説で確認できます。最初から全項目を変えず、困っている操作に対応する項目を一つずつ変更すると、原因を追いやすくなります。

複数行の依頼をEnterで誤送信しやすい場合は、chatgpt.composerEnterBehaviorを確認します。cmdAlwaysは送信にCmd/Ctrl+Enterを要求し、cmdIfMultilineは複数行のときにそのキーを使います。現在の設定を見てから、短い文で送信動作を確かめましょう。

実行中の追加メッセージは、chatgpt.followUpQueueModeで扱いが変わります。queueは次の実行まで待たせ、steerは現在の実行へ追加指示を渡します。たとえば「終わったら説明を短くして」はqueue、「対象ファイルを間違えたので変更を止めて」はsteerを選ぶ判断になります。ただし追加指示を送ることと、すでに行われた変更を取り消すことは別です。実行状況と差分を確認してください。

VS Codeでうまく動かないときの切り分け

不具合は、表示・参照内容・設定・実行環境に分けて調べると、変更する場所を絞れます。次の表は公式の操作・設定をもとにした編集部の確認順です。

WindowsでWSLを使う場合は、chatgpt.runCodexInWindowsSubsystemForLinuxが関連します。公式は、リポジトリや道具がWSL2側にある場合や、Linuxの道具が必要な場合の設定として説明しています。全員がWSLへ切り替える前提ではありません。変更するとVS Codeが再読み込みされるため、作業を保存してから進めます。

また、chatgpt.cliExecutableは開発用です。拡張が動かないときの一般的な対処として手動設定する項目ではなく、上書きにより拡張の一部が動かなくなる可能性も公式が示しています。困ったときは、使っているOS・拡張の版・症状・直前の操作を残し、設定を一度に増やさないようにしましょう。

VS Codeで次の依頼へ進む前の確認

一件の修正が終わったら、「参照したファイル」「残した差分」「実行した確認」「未確認の点」を短く残します。テストが成功していても、画面操作や別の入力条件を試していなければ、その範囲は未確認です。必要な確認を終えてからGitのチェックポイントを作ると、次の作業との境目が分かります。

最初の目標は、関数一つの説明と修正を依頼し、変更を自分で判断できることです。その流れが安定してから対象を広げてください。チームで使うときは、対象リポジトリ、変更を認める範囲、確認する担当を揃えると、同じ依頼手順を共有しやすくなります。