【Codex】② VS Code版Codex IDE Extension実践入門：コード理解・最小修正・テスト・Diffレビュー

Codex主要コンポーネント習得プログラムの第2回として、VS Code版のCodex IDE Extensionを実際に使い、コードの理解、局所的な修正、テスト実行、Gitによる差分確認までを一通り検証した。

今回の目的は、Codexを単なるチャット画面として使うのではなく、現在開いているファイルや選択範囲を文脈として渡し、変更内容をDiffで確認しながら安全に開発する流れを身につけることである。

今回できたこと
・OpenAI公式Codex Extensionの確認
・Codexサイドバーの起動と認証確認
・開いているPythonコードの説明
・例外メッセージの最小修正
・テストコードの更新とunittest実行
・Git Diffによる変更確認
・Windowsで発生したCRLF/LF混在の修正

1. Codex IDE Extensionとは

Codex IDE Extensionは、VS Codeなどの対応IDE内でCodexを利用するための拡張機能である。エディタで開いているファイルや選択したコードをそのまま文脈として利用できるため、コードを別のチャット画面へコピーする手間を減らせる。

また、Codexが変更した箇所をIDE内で確認し、同じスレッドから追加修正を依頼できる。短い修正や、ファイルを見ながら繰り返し調整する作業に向いている。

2. 今回の検証環境

項目	内容
OS	Windows
IDE	Visual Studio Code
拡張機能	Codex – OpenAI’s coding agent
言語	Python
テスト	標準ライブラリ unittest
バージョン管理	Git
練習フォルダ	02_codex-extension-tutorial

3. OpenAI公式Extensionを確認する

VS CodeのExtensions画面で「Codex」と検索すると、類似名称の拡張機能が複数表示された。今回選んだのは最上段の「Codex – OpenAI’s coding agent」で、発行元がOpenAI、認証マーク付きのものだった。

似た名前の非公式拡張も表示されるため、名称だけでなく発行元と認証マークまで確認することが重要である。

4. Codexサイドバーを起動する

インストール後、Codexアイコンを選択してサイドバーを開いた。アイコンが見つからない場合は、コマンドパレットを開いて次を実行できる。

Codex: Open Codex Sidebar

今回の画面では、過去のTasksが表示されており、すでに認証済みであることを確認できた。また、モデル選択の案内として「GPT-5.6 Sol」を試すポップアップが表示された。

5. 安全な練習用Gitリポジトリを作成する

最初から重要な開発プロジェクトで試すのではなく、今回は専用フォルダを作成した。

mkdir 02_codex-extension-tutorial
cd 02_codex-extension-tutorial
git init

作成したファイルは次の2つである。

app.py

def divide(a: float, b: float) -> float:
    if b == 0:
        raise ValueError("error")
    return a / b


if __name__ == "__main__":
    print(divide(10, 2))

test_app.py

import unittest

from app import divide


class TestDivide(unittest.TestCase):
    def test_normal_division(self):
        self.assertEqual(divide(10, 2), 5)

    def test_division_by_zero(self):
        with self.assertRaises(ValueError):
            divide(10, 0)


if __name__ == "__main__":
    unittest.main()

Codexへ編集を依頼する前に、Gitへ初期状態を保存した。

git add .
git commit -m "Checkpoint before Codex edit"

AIエージェントへ変更を任せる場合、作業前にGitのチェックポイントを作ると、問題が起きても簡単に元へ戻せる。

6. 開いているファイルについて質問する

最初の演習では、コードを変更させず、開いているapp.pyの説明だけを依頼した。

使用したプロンプト

現在開いている app.py の役割を説明してください。

divide関数について、次の点を整理してください。
入力
出力
例外が発生する条件
test_app.pyで確認すべき項目

まだファイルは変更しないでください。

Codexの回答概要

• app.pyは2つの値を割り算するdivide関数を定義している
• b == 0の場合はValueError("error")を発生させる
• 型ヒントはfloatだが、実行時の型チェックではない
• 通常の割り算、負数、ゼロ、ゼロ除算などをテストすべき
• 「ファイルは変更していない」と明示した

ここで分かった注意点

当初、実際のテストファイル名はtest.pyだったが、プロンプトではtest_app.pyと指定していた。そのためCodexは「test_app.pyは存在しない」と回答した。

これはCodexの誤りではなく、ユーザー側のファイル名指定が不正確だったことが原因である。AIへ依頼するときも、対象ファイル名、関数名、変更範囲を正確に指定する必要がある。

その後、ファイル名をtest_app.pyへ変更した。

7. 最小変更とテスト実行を依頼する

次に、app.pyの次の行を選択した。

raise ValueError("error")

その状態で、Codexへ次の変更を依頼した。

使用したプロンプト

選択した例外処理を、分かりやすい内容に改善してください。

条件：
- 例外を ValueError("b must not be zero") に変更する
- test_app.py に例外メッセージを確認するテストを追加する
- それ以外の仕様やコードは変更しない
- 変更後に python -m unittest -v を実行する
- 変更したファイル、差分、テスト結果を報告する

このプロンプトでは、対象、変更内容、変更禁止範囲、検証コマンド、報告項目を明記した。Codexのようなエージェントへ作業を任せる場合、単に「直して」と依頼するよりも、完了条件まで明示する方が安全である。

8. 実際に発生した長時間処理

今回の変更は2行程度だったが、Codexは約7分間動作し続けた。

処理ログを見ると、Codexは次の順で作業していた。

1. Gitの状態とファイル構成を確認
2. app.pyとtest_app.pyを編集
3. 組み込み編集の応答が遅いため、ファイル状態を再確認
4. apply_patchを試行
5. Codex実行ファイル経由のパッチ適用を試行
6. 最終的にPowerShellの文字列置換で変更
7. python -m unittest -vを実行
8. 改行コード混在を検出し、後処理を開始

つまり、モデルが単に考え続けていたのではなく、編集手段がうまく応答せず、複数の方法へフォールバックしていたため長時間化した。

判断基準
数行の単純修正で数分以上かかり、すでに編集とテストが終わっている場合は、処理ログを確認したうえでStopしてよい。停止後はGit Diffとテストを人間が確認する。

9. 変更結果をGit Diffで確認する

Codex停止後、PowerShellで次を実行した。

git diff -- app.py test_app.py
python -m unittest -v

コード上の目的どおり、差分は次の2点だった。

-        raise ValueError("error")
+        raise ValueError("b must not be zero")

-        with self.assertRaises(ValueError):
+        with self.assertRaisesRegex(ValueError, "^b must not be zero$"):

assertRaisesRegexを使用することで、例外の種類だけでなく、メッセージが期待どおりであることも検証できる。

10. unittestの実行結果

test_division_by_zero (test_app.TestDivide.test_division_by_zero) ... ok
test_normal_division (test_app.TestDivide.test_normal_division) ... ok

----------------------------------------------------------------------
Ran 2 tests in 0.001s

OK

2件のテストがすべて成功し、機能変更は正常に完了した。

11. Windowsで発生した「^M」問題

Git Diffを見ると、変更した行末に^Mが表示された。

+        raise ValueError("b must not be zero")^M

^Mは、Windowsで一般的なCRLF改行のCR部分を表している。今回、元のファイルはLFだったが、Codexが変更した一部の行だけCRLFとなり、1つのファイル内で改行コードが混在した。

Pythonの実行結果には問題がなかったが、この状態のままコミットすると、不要な差分や将来の編集トラブルにつながる可能性がある。

LFへ統一する修正

@'
from pathlib import Path

for name in ("app.py", "test_app.py"):
    path = Path(name)
    text = path.read_text(encoding="utf-8")
    text = text.replace("\r\n", "\n").replace("\r", "\n")
    path.write_text(text, encoding="utf-8", newline="\n")
'@ | python -

修正後、次のコマンドで再確認した。

git diff --check
git diff -- app.py test_app.py
python -m unittest -v

^Mが消え、テストも引き続き成功することを確認して作業を終了した。

テストキャッシュの削除

Remove-Item -Recurse -Force __pycache__ -ErrorAction SilentlyContinue

__pycache__をGit管理しない場合は、通常は.gitignoreへ追加しておく。

__pycache__/
*.pyc

12. 今回の最終コード

app.py

def divide(a: float, b: float) -> float:
    if b == 0:
        raise ValueError("b must not be zero")
    return a / b


if __name__ == "__main__":
    print(divide(10, 2))

test_app.py

import unittest

from app import divide


class TestDivide(unittest.TestCase):
    def test_normal_division(self):
        self.assertEqual(divide(10, 2), 5)

    def test_division_by_zero(self):
        with self.assertRaisesRegex(ValueError, "^b must not be zero$"):
            divide(10, 0)


if __name__ == "__main__":
    unittest.main()

13. Codex Extensionを安全に使う実務フロー

1. 対象プロジェクトをGit管理する
2. 作業前にコミットまたはチェックポイントを作る
3. 対象ファイルを開き、必要なら修正範囲を選択する
4. 変更内容と変更禁止範囲をプロンプトへ明記する
5. 実行すべきテストコマンドも指定する
6. Codexの完了報告だけを信用せず、Git Diffを読む
7. テストを自分のターミナルでも再実行する
8. 改行コード、文字コード、不要ファイルも確認する
9. 問題がなければコミットする

最終コミット例は次のとおりである。

git add app.py test_app.py
git commit -m "Improve zero division error and test message"

14. Codex CLIとIDE Extensionの使い分け

作業	向いている方法	理由
リポジトリ全体の調査	Codex CLI	フォルダ起点で広く探索しやすい
現在開いているファイルの質問	IDE Extension	エディタ文脈をそのまま利用できる
数行の局所修正	IDE Extension	変更箇所とDiffを近い画面で確認できる
コマンド中心の調査や自動化	Codex CLI	ターミナル操作との相性がよい
長時間・並列作業	Codex Cloud	ローカルIDEから切り離して委任しやすい

今回の実習から、日常運用としては「フォルダ起点の対話はCLI、ファイル起点の反復はIDE Extension」という使い分けが分かりやすいと感じた。

15. 今回の成果と失敗から得た知見

確認項目	結果
公式Extensionの導入	成功
Codexサイドバー起動	成功
開いているコードの理解	成功
ファイルを変更しない指示	守られた
最小コード変更	成功
テストコード更新	成功
unittest実行	2件成功
処理時間	単純変更としては長すぎた
編集処理	組み込み編集が遅く、複数手段へフォールバック
改行コード	LFとCRLFが混在し、手動修正が必要

16. まとめ

Codex IDE Extensionは、現在見ているコードについて質問し、そのまま小さな変更とテストまで進められる点が非常に便利だった。

一方で、AIエージェントが「変更しました」「テストに成功しました」と報告しても、それだけで作業完了とは判断できない。今回のように、コードの内容は正しくても、Windowsの改行コードが混在する場合がある。

したがって、Codexを実務で安全に使うためには、次の3点が特に重要である。

• 変更前にGitへ保存する
• 変更後にDiffを自分で読む
• テストとファイル状態を自分のターミナルで再確認する

Codex Extensionの価値は、人間のレビューを不要にすることではない。コードの理解、編集、テストまでの反復を高速化し、人間が最終判断しやすい状態を作ることにある。

次回は、Codex AppとCodex Cloudを使い、ローカル作業、Worktree、長時間タスク、並列作業の使い分けを検証する。

参考資料

• OpenAI公式：Codex IDE extension
• OpenAI公式：Codex Authentication
• OpenAI公式：Codex Config basics
• Codex主要コンポーネントの習得プログラム