Skyscanner は OpenAI の Codex CLI と JetBrains IDE を連携させ、人間の開発者と同じデバッグツールやテストツールを AI アシスタントでも使えるようにしました。Codex CLI の能力を大きく引き上げた、この取り組みを紹介します。
Skyscanner では、品質を損なわずに開発を加速する方法を常に模索しています。ここ数か月、私は日々のワークフローに OpenAI の Codex を取り入れ、ペアプログラミングの相手として試してきました。
今回の工夫は、JetBrains の Model Context Protocol（MCP）サーバーを使い、Codex CLI を同社の IDE に接続したことです。つまり、AI が IDE の機能を把握し、使えるようにしました。この連携によって、開発の進め方が大きく変わりました。本記事では、Codex が JetBrains のツールを使えるようになったことで、問題解決能力がどう向上し、開発がどのように速くなったかを紹介します。
IDE のコンテキストを Codex に共有
JetBrains MCP サーバーを介して Codex を使うと、通常は「見えない」開発環境の豊富なコンテキストを AI が活用できるようになります。
JetBrains MCP を使うと、Codex は IDE に追加のコンテキストを問い合わせることができます。たとえば、次のようなことが可能です。
- ファイル内の問題の検出：IntelliJ のインスペクションでファイルのエラーや警告を分析し、エラーメッセージと発生箇所を含む具体的な問題を返します。
- 実行構成の実行：事前に定義した実行構成（単体テスト、リンター、フォーマッターなど）を実行し、終了コードと出力を取得します。
これは非常に効果的でした。人間の開発者がコードの記述、コンパイル、テストで頼りにしているのと同じフィードバックループを利用できるからです。Codex は IDE のコンテキストを使って、自らの出力をより効果的に確認・検証できるようになり、修正を繰り返す時間が短くなりました。
エラーの早期発見：実際の事例
Databricks の Java SDK を使うコードで、エラー処理の単体テストを書いていたときのことです。例外が発生する状況をスタブで再現するため、Codex に手伝ってもらいました。すると、自信たっぷりに次のような Java コードを 1 行生成しました。
var stubError = new NotFound("dummy error");NotFound エラーを再現したいので、一見すると妥当に思えます。しかし、その直後、IntelliJ がその行に目立つ赤い下線を表示しました。
問題は、Databricks SDK の NotFound 例外クラスに、文字列を 1 つだけ引数に取るコンストラクターがないことでした（Databricks SDK のソースコード、NotFound.java で確認できます）。つまり、Codex が提案したコードは、そもそもコンパイルできないものでした。
通常の状態では、Codex はこの間違いに気づかないでしょう。後でテストを実行しようとして、初めて何かがおかしいと気づくかもしれません。しかし、JetBrains MCP と連携していたため、Codex はすぐにエラーを認識しました。内部では、Codex が IDE の get_file_problems ツールを呼び出してファイルを検査し、コンパイルの問題（一致するコンストラクターがないこと）が即座に返されていました。
MCP がなければ、おそらく次のような流れになっていたでしょう。
- コードを生成
- 単体テストの実行方法を確認
- 単体テストを実行（コマンド実行についてユーザーに承認を求める必要が生じる場合もあります）
- 失敗メッセージを読み取り、解析
- エラーの修正を試行
JetBrains MCP を使うと、このループは大幅に短くなります。
- コードを生成
- ファイル内の問題を JetBrains に問い合わせ
- IntelliJ が報告した具体的なエラーを修正
これにより、時間とコンテキストの消費を抑えられました。まるで、「ああ、そのクラスにはそのようなコンストラクターはありません。実際には別の引数が必要です。すぐに直しますね」と即座に言ってくれるエンジニアとペアプログラミングをしているようでした。
事前に定義したテストとフォーマット
もう 1 つ便利だと感じているのは、Codex が既存のビルドツールやテストツールを IDE から直接操作できることです。ほとんどのプロジェクトでは、テスト、フォーマット、リントなど、ローカルで使う実行構成を IDE に定義済みです。JetBrains MCP を使うと、Codex はこれらの構成を見つけ、必要に応じて実行できます。
実際に、これらの機能の実行方法を Codex が調べるための時間とコンテキストが減り、本来の問題に集中しやすくなりました。この変更以降、私が見ている限り、Codex はテスト、フォーマット、リントの実行でつまずかなくなりました。
そのため、私のエージェント向けカスタム指示では、変更のたびにテスト、リント、フォーマットを実行するよう Codex に指示しています。
## Code edit instructions
After you've finished editing
- Use the jetbrains mcp (if available) to find any problems
- Run format command if available
- Run lint command if available今では、私が介入しなくても Codex が自力で問題を解決することが増えました。開発者として、次のような点に大きなメリットを感じています。
- Codex が何かを変更するたびに、テスト、リント、フォーマットを手動で実行する必要がありません。
- エラーメッセージをチャットにコピーして貼り付ける必要がありません。
- Codex は、自らの変更が実際に機能するかどうかについて、迅速かつ正確なフィードバックを得られるため、フィードバックのやり取りの回数が減ります。
その分、本来の仕事である、正しく動く高品質なソフトウェアの提供に集中できる時間が増えました。
開発の進め方にもたらした変化
Codex と JetBrains MCP を連携させたことで、開発プロセスにおける AI アシスタントの能力と信頼性が大幅に向上しました。実際に得られたメリットには、次のようなものがあります。
- フィードバックループの高速化：Codex は、コンパイルエラーやテストの失敗について、IDE から即座にフィードバックを得られます。
- プロンプトのやり取りの削減：Codex は IDE に直接問い合わせられるため、私が何かを実行してエラーメッセージを貼り付けるのを毎回待つ必要がありません。
- 提案の品質向上：Codex は IDE と同じ情報を確認できるため、提案した修正が最初の試行でコンパイルとテストに通る可能性が高くなります。
- 既存のワークフローとの親和性向上：Codex は独自のツールを作るのではなく、私たちがすでに使っているツールと連携します。
全体として、Codex は単独で使うツールから、私たちの開発環境により深く組み込まれた存在へと変わりました。
まとめ
Skyscanner の私たちが得た重要な気づきは、シンプルです。コンテキストがすべてを左右します。Codex は単体でも強力ですが、IDE の情報を把握できると、はるかに効果的に働きます。このコンテキストによって Codex の理解がさらに深まり、正確な修正をより速く行えるようになりました。その出力に対する私の信頼も、さらに高まっています。
私たちの事例が、こうした連携を試すきっかけになれば幸いです。実際に使ってみると、単にツールを操作しているというよりも、自分たちと同じ情報を見られる AI を相手にペアプログラミングをしている感覚に近くなります。