Windows 11 pro にJetBrains Airを入れて、Codexで最初のタスクを実行してみる
はじめに
前回は、複数のAIコーディングエージェントをまとめて扱える開発環境として、JetBrains Airの概要を整理しました。
今回はWindows 11 proへAirをインストールし、OpenAI Codexを使って小さなPythonプログラムを修正します。
Airのインストール自体は難しくありません。そこで、導入部分は簡単に済ませ、次の点を中心に確認します。
確認事項
- CodexをAirへ接続する
- Git Worktreeで作業を分離する
- Planモードで実装前の計画を作る
- Codexへ具体的なタスクを渡す
- 変更差分とテスト結果を確認する
- 修正結果を元のプロジェクトへ反映する
いきなり実務の大きなプロジェクトを開くのではなく、動作確認用の小さなPythonプロジェクトを使います。
※この記事は2026年7月28日時点の内容です。Airは更新が続いているため、画面上の名称や配置が変わる可能性があります。
今回の環境
今回想定する環境は次のとおりです。
| 項目 | 内容 |
|---|---|
| OS | Windows 11 |
| AI開発環境 | JetBrains Air |
| AIエージェント | OpenAI Codex |
| 実行環境 | Git Worktree |
| 言語 | Python 3.12以降 |
| テスト | unittest |
| ターミナル | PowerShell |
| バージョン管理 | Git |
Dockerは使いません。
AirでDockerタスクを実行する場合はDocker Desktopが必要ですが、今回使用するGit Worktreeでは不要です。Airでリポジトリやタスクブランチを扱うにはGitが必要です。
1. JetBrains Airをインストールする
Windows版Airは、JetBrains Toolboxからインストールするのが簡単です。
JetBrains Airからもダウンロードできます。
JetBrains Toolboxを起動し、製品一覧から「Air」を探してインストールします。インストールが終わったら、そのままAirを起動します。
JetBrains Toolbox
↓
Airを検索
↓
Install
↓
Airを起動
Windows版AirはJetBrains Toolbox経由でインストールできます。公式ブログではx64版とARM64版の直接ダウンロードも案内されていますが、更新管理を考えるとToolbox経由の方が分かりやすいと思います。
Airを起動する前に、PowerShellでGitが使えることだけ確認しておきます。
git --version
次のようにバージョンが表示されれば問題ありません。
git version 2.x.x.windows.x
2. AirへOpenAI Codexを接続する
Airを初めて起動すると、AIプロバイダーの接続画面が表示されます。
表示されない場合は、設定画面から次の項目を開きます。
Settings
└─ Account
└─ AI Providers
OpenAIの欄にある「Connect」を押し、使用するアカウントを選択します。
AirのOpenAI Codex接続では、JetBrainsの現行ドキュメント上、次の方法が案内されています。
- ChatGPT Plus、Pro、Teamのアカウント
- OpenAI PlatformのAPI課金アカウント
今回は、普段使っているChatGPTアカウントでログインする想定です。ブラウザーが開いたらOpenAIへログインし、Airからの接続を許可します。
接続が終わったら、AirのAI Providers画面でOpenAIが接続済みになっていることを確認します。
なお、OpenAIのCodex自体はChatGPTの各プランへ展開されていますが、Airから接続できるアカウント種別については、Air側の対応状況を確認する必要があります。
3. 動作確認用プロジェクトを作る
今回は、時間雨量を集計する小さなPythonプログラムを用意します。
最初の状態には、次の問題をあえて残しておきます。
- 空のリストを渡すとエラーになる
- 負の雨量を受け入れてしまう
- テストコードがない
- docstringがない
- READMEの説明が少ない
これらをCodexへ修正してもらいます。
フォルダーを作成する
PowerShellを開き、任意の作業場所へ移動します。
ここでは、次の場所に作成します。
C:\work\air-codex-first-task
PowerShellで次のコマンドを実行します。
New-Item -ItemType Directory -Force C:\work\air-codex-first-task
Set-Location C:\work\air-codex-first-task
rainfall.pyを作成する
rainfall.pyを作成し、次のコードを保存します。
from __future__ import annotations
def summarize_rainfall(rainfall_mm: list[float]) -> dict[str, float]:
total_mm = sum(rainfall_mm)
return {
"total_mm": total_mm,
"max_mm": max(rainfall_mm),
"average_mm": total_mm / len(rainfall_mm),
}
if __name__ == "__main__":
sample_rainfall = [0.0, 2.5, 10.0, 5.5]
print(summarize_rainfall(sample_rainfall))
正常なデータであれば動きます。
python rainfall.py
実行結果は次のようになります。
{'total_mm': 18.0, 'max_mm': 10.0, 'average_mm': 4.5}
ただし、空のリストを渡すとmax()や割り算の処理でエラーになります。
また、雨量としては不自然な負の値も、そのまま集計されてしまいます。
README.mdを作成する
同じフォルダーへREADME.mdを作成します。
# Air Codex First Task
JetBrains AirとOpenAI Codexの動作確認用プロジェクトです。
## 実行方法
```powershell
python rainfall.py
現在のフォルダー構成は次のとおりです。
```text
air-codex-first-task/
├─ rainfall.py
└─ README.md
4. Gitリポジトリを作成する
Airでタスクを実行するには、プロジェクトがGitリポジトリになっている必要があります。Git Worktreeを使う場合は、変更前の状態をコミットしておきます。
PowerShellで次のコマンドを実行します。
git init
git add .
git commit -m "Create starter rainfall project"
Gitのユーザー情報が未設定の場合は、コミット時にエラーが出ます。
その場合は、先に次の設定を行います。
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
設定後、もう一度コミットします。
git add .
git commit -m "Create starter rainfall project"
最後に状態を確認します。
git status
次のように表示されれば準備完了です。
nothing to commit, working tree clean
最初のコミットを作っておくことで、Codexが変更した部分だけを差分として確認できます。
5. Airでプロジェクトを開く
Airを起動し、「Open」を押します。
次のフォルダーを選択します。
C:\work\air-codex-first-task
プロジェクトを開くと、フォルダーを信頼するか確認されることがあります。
今回は自分で作成したプロジェクトなので「Trust」を選択します。入手元が分からないプロジェクトでは、内容を確認せずにTrustを押さない方が安全です。Airでは、プロジェクトを開いた際にスクリプトやコードが実行される可能性があるため、信頼確認が行われます。
プロジェクトを開いたら、rainfall.pyとREADME.mdが表示されることを確認します。
6. 最初のタスクを設定する
ここからが今回の中心です。
AirのChat画面を開き、Codexへタスクを渡します。
タスクを送る前に、次の3項目を設定します。
| 設定 | 今回の選択 |
|---|---|
| Agent | OpenAI Codex |
| Permission Mode | Plan |
| Run Environment | Git Worktree |
AgentはOpenAI Codexを選ぶ
タスク入力欄の近くにあるエージェント選択欄から、OpenAI Codexを選びます。
モデルや推論レベルを選べる場合がありますが、最初は初期設定のままで構いません。
今回は、モデル性能の比較ではなく、Air上での一連の作業を確認することが目的です。
Permission ModeはPlanを選ぶ
今回はPlanモードを使います。
Planモードでは、Codexはいきなりコードを書き換えません。最初にプロジェクトを調べ、実装計画をMarkdownとして作成します。
作成された計画は、通常、次のフォルダーへ保存されます。
.air/plans/
計画を確認した後に実装へ進めるため、変更範囲が分からないままコードを書き換えられるのを防げます。
小さな修正であればPlanモードを省略しても構いませんが、最初はAirの流れを確認するために使用します。
Run EnvironmentはGit Worktreeを選ぶ
実行環境にはGit Worktreeを選びます。
Git Worktreeでは、Airがタスク専用の作業フォルダーとブランチを作成します。
元のプロジェクト
└─ mainブランチ
Airの作業場所
└─ タスク専用ブランチ
Codexが修正している間も、元のプロジェクトは変更されません。
作業完了後に差分を確認し、問題がなければ元のプロジェクトへ反映します。Git Worktreeはファイルとブランチを分離しますが、Pythonなどの実行環境はWindows側の環境を利用します。
最初からLocal Workspaceを使うこともできますが、Local Workspaceでは現在のファイルが直接変更されます。
Airの操作に慣れるまでは、Git Worktreeの方が安心です。
7. Codexへ渡すタスクを書く
今回使用するタスクは次のとおりです。
そのままAirのChatへ貼り付けます。
このプロジェクトにある降雨集計処理を、安全に利用できるように修正してください。
対象:
- rainfall.py
- README.md
- 新しく追加するテストコード
目的:
現在のsummarize_rainfall関数は、空のリストを渡すとエラーになり、
負の雨量もそのまま集計してしまいます。
入力値を検証し、標準ライブラリのunittestで動作確認できるようにしてください。
完了条件:
1. summarize_rainfall([])を実行した場合はValueErrorを送出する
2. 負の雨量を1つでも含む場合はValueErrorを送出する
3. エラーメッセージから原因が分かるようにする
4. 正常な入力では、現在と同じ辞書形式を返す
5. 次の入力ではtotal_mmが18.0、max_mmが10.0、
average_mmが4.5になることを確認する
[0.0, 2.5, 10.0, 5.5]
6. testsフォルダーを作り、unittestによるテストを追加する
7. 次のコマンドですべてのテストが成功するようにする
python -m unittest discover -s tests -v
8. README.mdへ実行方法とテスト方法を追記する
変更時の条件:
- summarize_rainfallという関数名は変更しない
- 引数rainfall_mmの名前は変更しない
- 戻り値のtotal_mm、max_mm、average_mmというキー名は変更しない
- 外部ライブラリは追加しない
- Python 3.12以降で動くコードにする
- 公開関数には日本語のdocstringを付ける
- コメントは処理の理由が分かる箇所にだけ追加する
- 今回の目的と関係のないリファクタリングは行わない
- テストを実行し、結果を最後に報告する
まず現在のコードを確認し、変更するファイルと実装手順を整理してください。
Planの承認前にはコードを変更しないでください。
タスクを細かく書く理由
AIへコード修正を依頼するときは、「使いやすく直してください」だけでは条件が不足します。
今回のタスクでは、次の内容を分けて書いています。
現在の問題
↓
修正の目的
↓
完了条件
↓
変更してはいけない部分
↓
実行するテストコマンド
特に重要なのは、完了条件と変更禁止事項です。
完了条件を書く
Codexにとっての「作業完了」が何を意味するのかを明確にします。
今回であれば、次の条件です。
空のリスト
→ ValueError
負の雨量
→ ValueError
正常なリスト
→ 正しい集計結果
テスト
→ すべて成功
期待する数値も書いているため、Codexが自分で結果を確認できます。
変更してはいけない部分を書く
AIへ修正を依頼すると、必要以上に関数名やファイル構成を変えることがあります。
そこで、次の内容を固定しています。
関数名は変更しない
引数名は変更しない
戻り値のキー名は変更しない
外部ライブラリは追加しない
関係のないリファクタリングは行わない
実務では、APIのURL、JSON形式、データベース構造、CSV列名なども同じように明記します。
8. タスクへ対象ファイルを追加する
Airでは、@を入力するとファイルやフォルダーをタスクのコンテキストへ追加できます。
今回は次の2ファイルを追加します。
@rainfall.py
@README.md
ファイルを明示的に追加すると、Codexがプロジェクト全体を探し回らずに済みます。
小さなプロジェクトでは大きな差はありませんが、実務のリポジトリでは、対象ファイルを絞った方が余計な変更を減らせます。
Airでは、ファイル、フォルダー、Git情報、ターミナル出力、クラスや関数などをタスクのコンテキストへ追加できます。
設定が終わったら、タスクを送信します。
9. Codexが作成したPlanを確認する
Planモードでは、最初に実装計画が表示されます。
計画の書き方はモデルによって変わりますが、おおむね次のような内容になります。
1. rainfall.pyの現在の処理を確認する
2. 空リストの検証を追加する
3. 負の雨量を検出する処理を追加する
4. summarize_rainfallへdocstringを追加する
5. tests/test_rainfall.pyを作成する
6. 正常系と異常系のテストを追加する
7. README.mdへテスト方法を追記する
8. unittestを実行する
この段階では、まだコードは変更されていません。
Planを確認するときは、次の点を見ます。
- 指定していない外部ライブラリを追加しようとしていないか
- 関数名や戻り値を変更しようとしていないか
- 正常系と異常系の両方をテストする計画になっているか
- READMEの更新が含まれているか
- 実行するテストコマンドが正しいか
- 関係のないファイルを変更しようとしていないか
問題がある場合は、この段階でコメントを返します。
例えば、pytestを使う計画になっていた場合は、次のように修正を依頼します。
今回は外部ライブラリを追加しないため、
pytestではなく標準ライブラリのunittestを使用してください。
Planに問題がなければ「Implement」を押して実装へ進みます。
実装画面では、もう一度エージェントと実行環境を選択できます。
今回も次の設定にします。
Agent : OpenAI Codex
Run Environment: Git Worktree
10. Codexの作業内容を確認する
実装を開始すると、Codexはタスク専用のGit Worktreeでファイルを変更します。
想定されるフォルダー構成は次のようになります。
air-codex-first-task/
├─ rainfall.py
├─ README.md
└─ tests/
└─ test_rainfall.py
rainfall.pyには、少なくとも次の検証が追加されているはずです。
if not rainfall_mm:
raise ValueError("雨量データが空です。")
if any(value < 0 for value in rainfall_mm):
raise ValueError("雨量には0以上の値を指定してください。")
実装方法はCodexの判断によって多少変わります。
ただし、次の点を満たしていれば問題ありません。
- 集計前に入力値を検証している
- 空リストと負の値を別々に扱っている
- エラー原因がメッセージから分かる
- 正常時の戻り値形式が変わっていない
- 外部ライブラリを追加していない
テストコードには、少なくとも次の3種類が必要です。
正常な雨量データ
空のリスト
負の雨量を含むリスト
Codexがテストを実行すると、タスク画面へ結果が表示されます。
実行するコマンドは次のとおりです。
python -m unittest discover -s tests -v
テスト名は実装によって変わりますが、正常に動けば最後に次のような結果が表示されます。
Ran 3 tests
OK
テストが失敗した場合は、そのまま修正を依頼します。
テストが1件失敗しています。
原因を確認し、完了条件を変更せずに修正してください。
修正後、同じテストコマンドをもう一度実行してください。
11. Changes画面で差分を確認する
Codexの作業が終わると、Chat画面に「Changes」が表示されます。
Changesを押すと、変更前と変更後の差分を確認できます。AirではUnified表示とSide-by-side表示を切り替えたり、変更行へコメントを付けたりできます。
今回の確認ポイントは次のとおりです。
rainfall.py
- 空のリストを事前に検出しているか
- 負の値を検出しているか
- 関数名が変わっていないか
- 戻り値のキー名が変わっていないか
- 日本語docstringが追加されているか
- 不要な処理が増えていないか
tests/test_rainfall.py
- 正常系のテストがあるか
- 空リストのテストがあるか
- 負の雨量のテストがあるか
- エラーの種類がValueErrorになっているか
- 期待値が具体的に確認されているか
README.md
- プログラムの実行方法が書かれているか
- テストの実行方法が書かれているか
- 追加していないライブラリの説明が混ざっていないか
差分に問題があれば、該当行へコメントを付けてCodexへ返します。
例えば、コメントが多すぎる場合は次のように伝えます。
コードから明らかな処理を説明するコメントは削除してください。
入力値を検証する理由が分かるコメントとdocstringだけを残してください。
Airには、変更差分を別のエージェントへ確認させる「Review with Agent」もあります。
ただし、最初のタスクでは人が自分で差分を読む方が、Airの動きを理解しやすいと思います。AIによるレビューを使う場合も、重要な動作は手動で確認する必要があります。
12. 変更を元のプロジェクトへ反映する
Git Worktreeで実行した場合、Codexの変更はまだ元のプロジェクトへ入っていません。
差分に問題がなければ、Changes画面から「Apply Locally」を押します。
これにより、Git Worktree側の変更が元の作業フォルダーへ、未コミットの変更として反映されます。
別の方法として、タスク用ブランチをそのままチェックアウトすることもできます。
今回はApply Locallyを使います。
反映後、PowerShellで元のフォルダーへ移動します。
Set-Location C:\work\air-codex-first-task
変更状態を確認します。
git status
想定どおりであれば、次のようなファイルが表示されます。
modified: README.md
modified: rainfall.py
new file: tests/test_rainfall.py
元のフォルダーでもテストを実行します。
python -m unittest discover -s tests -v
Air上でテストが成功していても、最終的には元の環境でも確認します。
問題がなければコミットします。
git add .
git commit -m "Add rainfall input validation and tests"
これで最初のタスクは完了です。
今回の作業の流れ
今回行った作業をまとめると、次のようになります。
Windows 11へAirをインストール
↓
OpenAI Codexへログイン
↓
小さなPythonプロジェクトを作成
↓
Gitで初期状態をコミット
↓
Airでプロジェクトを開く
↓
Codex + Plan + Git Worktreeを選択
↓
目的と完了条件を含むタスクを送信
↓
Planを確認
↓
Codexがコードとテストを作成
↓
Changes画面で差分を確認
↓
Apply Locally
↓
元の環境でテスト
↓
Gitへコミット
最初のタスクで分かったこと
Airの特徴は、Codexにコードを書かせることだけではありません。
今回の手順では、次の部分がAirの役割になります。
Codex
└─ コードを調査して修正する
Git Worktree
└─ 元のプロジェクトから変更を分離する
Planモード
└─ 実装前に変更内容を確認する
Changes画面
└─ 人が差分を確認する
Apply Locally
└─ 採用した変更だけを元へ戻す
Codex CLIだけでも同じ作業はできます。
ただし、Worktreeの作成、タスクの進捗、差分確認、元のプロジェクトへの反映を1つの画面で扱える点はAirの分かりやすいところです。
実務で使う場合のタスクの書き方
今回のタスクは小さなPythonプログラムでしたが、実務でも基本的な書き方は変わりません。
例えば、FastAPIの修正を依頼する場合は、次のように書けます。
目的:
指定したAPIで発生している500エラーを修正する。
現象:
空の検索結果を受け取った場合にIndexErrorが発生する。
完了条件:
- 検索結果が0件でも500エラーにならない
- 0件の場合は空の配列を返す
- 既存のJSON構造は変更しない
- 正常系と0件の場合のテストを追加する
- pytestを実行して全件成功する
変更禁止:
- APIのURLを変更しない
- DuckDBのテーブル構造を変更しない
- OpenLayers側のコードを変更しない
- 関係のないリファクタリングを行わない
確認方法:
docker compose up --buildを実行し、
対象APIのレスポンスを確認する。
まずPlanを作成し、変更対象ファイルと影響範囲を整理する。
AIへ依頼するときは、長い文章を書くことよりも、目的、完了条件、変更禁止事項を分ける方が重要です。
まとめ
Windows 11へのAirのインストールは、JetBrains Toolboxから行えば難しくありません。
その後は、OpenAI Codexへ接続し、GitリポジトリをAirで開くだけでタスクを開始できます。
最初に試す設定としては、次の組み合わせが扱いやすいと思います。
Agent : OpenAI Codex
Permission Mode: Plan
Run Environment: Git Worktree
Planモードで実装内容を確認し、Git Worktreeで元のプロジェクトを保護しながら作業させます。
タスクを依頼するときは、少なくとも次の4点を書いておきます。
- 何を直すのか
- どの状態になれば完了なのか
- 何を変更してはいけないのか
- どのコマンドで確認するのか
Airを使っても、AIが作成したコードを確認せずに採用してよいわけではありません。
最終的な差分とテスト結果は人が確認し、問題がない変更だけを元のプロジェクトへ反映する流れが基本になります。
参考資料
- JetBrains Air:セットアップ方法
- JetBrains Air:クイックスタート
- JetBrains Air:Windows版の案内
- JetBrains Air:対応しているAIエージェント
- JetBrains Air:タスクの作成と実行
- JetBrains Air:Planモード
- JetBrains Air:権限モード
- JetBrains Air:実行環境
- JetBrains Air:タスクへコンテキストを追加する方法
- JetBrains Air:変更内容のレビューと反映
- JetBrains Air:変更の確認とコミット
- OpenAI:ChatGPTプランでCodexを利用する方法
- OpenAI Codex CLI:公式GitHubリポジトリ