Skyscanner は、OpenAI の Codex CLI と JetBrains の IDE を連携させ、開発者が使うデバッグやテストのツールを AI アシスタントからも使えるようにしました。この連携で Codex の能力をどう引き出したのかをご紹介します。
Skyscanner では、品質を保ちながら開発をスピードアップする方法を常に模索しています。ここ数か月、私は日々の開発で OpenAI の Codex をペアプログラミングの相手として使い、いろいろと試してきました。
そこで一工夫しました。JetBrains の Model Context Protocol（MCP）サーバーを使って、Codex CLI を同社の IDE に接続したのです。これで AI は、IDE にどんな機能があるかを把握し、実際に使えるようになりました。この連携で開発の進め方が大きく変わりました。この記事では、JetBrains のツールを使えるようになったことで、Codex の問題解決力がどう高まり、私たちの開発がどう速くなったのかを紹介します。
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 の IDE に問い合わせる
- IntelliJ が指摘したエラーを修正
これで時間を節約でき、必要なコンテキストも減りました。まるでペアプログラミングの相手が、その場で「あ、このクラスにそういうコンストラクターはありませんね。別の引数が必要です。すぐ直します」と言ってくれるような感覚でした。
設定済みの実行構成を使ったテストとフォーマット
もう一つ便利なのは、普段使っているビルドやテストのツールを Codex が IDE から直接実行できることです。ほとんどのプロジェクトでは、テストの実行、フォーマット、リントなどのローカル実行構成を、あらかじめ私の IDE に設定しています。JetBrains MCP を介せば、Codex は必要に応じてこれらの構成を見つけて実行できます。
実際に使ってみると、Codex が各ツールの実行方法を調べるのにかかる時間も、必要なコンテキストも減り、本来の問題に集中できるようになりました。連携してからは、テストやフォーマット、リントの実行で Codex がつまずくこともなくなりました。
そこで、私のエージェント向けのカスタム指示では、変更のたびにテスト、リント、フォーマットを実行するよう Codex に指示しています。
## コード編集時の指示
編集が終わったら、次の手順に従ってください。
- JetBrains MCP が利用できる場合は、それを使ってファイルに問題がないか確認する
- フォーマット用のコマンドが利用できる場合は、そのコマンドを実行する
- リント用のコマンドが利用できる場合は、そのコマンドを実行する今では、私が手を貸さなくても Codex が自分で問題を解決することが増えました。開発者として、次のような点でとても助かっています。
- Codex が何かを変更するたびに、私が手動でテスト、リント、フォーマットを実行する必要がなくなりました。
- エラーメッセージをコピーしてチャットに貼り付ける手間がなくなりました。
- 変更が実際に機能するかどうか、Codex がすぐに正確なフィードバックを得られるので、修正と確認を繰り返す回数が減りました。
その分、きちんと動く質の高いソフトウェアを届けるという本来の仕事に、より多くの時間を使えます。
私たちの開発の進め方に生まれた変化
Codex と JetBrains MCP を連携させたことで、開発中に AI アシスタントに任せられることが大きく増え、その結果も以前より信頼できるようになりました。実際の開発では、次のような効果が出ています。
- フィードバックの高速化：コンパイルエラーやテストの失敗を、Codex が IDE からすぐに把握できます。
- プロンプトのやり取りの削減：Codex が IDE に直接問い合わせられるので、私がコマンドを実行してエラーメッセージを貼り付けるのを毎回待つ必要がありません。
- 提案の品質向上：IDE が把握している情報を Codex も参照できるため、最初の修正でコンパイルとテストが通る可能性が高くなります。
- 既存のワークフローとの連携：Codex が独自にツールを考案する必要はなく、私たちが普段使っているツールをそのまま利用できます。
こうして Codex は、単独で使うツールから、私たちの開発環境に組み込まれたツールへと変わりました。
まとめ
Skyscanner での経験から学んだのは、Codex の力を引き出すには、どんなコンテキストを得られるかが決め手になるということです。Codex は単独でも強力ですが、IDE から情報を得られると、はるかに力を発揮します。コンテキストがあれば、Codex は問題をより深く理解し、的確な修正をより早く提示できます。私自身、その結果を以前にも増して信頼できるようになりました。
私たちの経験が、皆さんにとってこうした連携を試すきっかけになれば幸いです。実際に使ってみると、単にツールを操作しているというより、自分と同じ情報を見ている AI とペアを組んで開発している感覚にずっと近くなりました。