JetBrains、提供するすべてのIDEにエージェントオーケストレーターを組み込む

JetBrainsは10月1日、自社IDEでAirのアーリーアクセスを開始した。AirはJetBrains Marketplaceのプラグインとして、またはIntelliJ、PyCharm、WebStorm、Riderなどファミリーの2026.3 EAPビルドにバンドルして利用でき、2026.2以降のバージョンで動作する。プラグインは無料だ。

興味深いのはその位置づけだ。Airはモデルでもエージェントでもない。エージェントを一切同梱しない。JetBrainsは、開発者がすでに料金を支払っているエージェントやサブスクリプションへの導管だと説明しており、IDEがターミナルを検出するのと同じように、マシン上にすでにあるものを検出する。

チャットではなくセッション

JetBrainsは、複数のタスクを同時並行でオーケストレーションすることはモデルとの会話とは別の行為であり、両方に同じインターフェースを使うのは間違いだったと主張する。従来のIDE AIはチャットが中心だった。Airはセッションが中心だ。

各セッションはタスクに取り組むエージェントであり、インターフェースはそれらをまとめて追跡する。アクティビティ、未読の更新、変更されたファイル、未プッシュのコミット、各セッションのコストを1つのビューで確認できる。セッションはプロジェクトをまたいで実行でき、エディタータブとして表示されたり、タスクに応じてターミナルやグラフィカルチャット内にとどまったりする。IDE内のどこでもCtrlをダブルタップすると、現在のコンテキストが添付されたプロンプトウィンドウが開く。

分離は一時的なGitワークツリーで処理される。セッションは任意のブランチから、新しいブランチ上で、またはデタッチド状態で開始でき、結果はメインプロジェクトにチェリーピックで戻される。JetBrainsによると、エージェントの出力はIDE内でレビュー可能な差分として表示され、開発者がプルリクエストをレビューするのと同じツールを使う。変更は自動適用されない。

戦略の要はプロトコルへの取り組み

Airは、JetBrainsがZedと共同で構築しApacheライセンスで公開したオープン標準、Agent Client Protocol（ACP）をサポートするエージェントに接続する。ACPはstdinとstdout上でJSON-RPC 2.0を使用し、JetBrains、Zed、Google、GitHub、および25を超えるエージェントが採用している。両社は、IDEに組み込まれた互換エージェントの検索可能なディレクトリであるACP Registryも立ち上げた。

最もわかりやすい比較対象はLanguage Server Protocolだ。LSPは、組み合わせごとの特注統合ではなく、1つの共通標準を通じて、あらゆるエディターがあらゆる言語をサポートできるようにした。ACPはエージェントについて同じことを目指している。

JetBrainsはモデルの品質ではなく、エージェントが起動され、監督され、レビューされる層で競おうとしている。エージェントがエディターとどう対話するかを規定するプロトコルを共同執筆することは、機能ではなくインフラになるための方法だ。同社自身の説明はより率直だ。エージェントを遠ざけておくIDEは、エージェント型開発が当たり前になるにつれて苦戦するだろう。

サポートされるエージェントには、Codex、Claude Agent、GitHub Copilot、Gemini、OpenCode、JetBrains製のJunie、その他のACP互換ツールが含まれる。既存のAnthropic、OpenAI、Googleのキーを持つユーザーはJetBrainsに何も支払わない。エージェントのサブスクリプションがない場合、JetBrainsアカウントでサインインすると無料のJunie Lite実行が提供される。JetBrains AIクレジットは、同社がホストするモデルアクセスのために月10ドルから始まる。

Cursorにはない機能

JetBrainsが頼りにする差別化要因は、Airに接続されたエージェントがIDEのツールをスキルとして呼び出せることだ。エージェントは失敗したテストを調査するためにデバッグ実行をトリガーしたり、プロファイラーを実行したり、複数ファイル全体のコンテキストを備えたリファクタリングエンジンを使ったりできる。エージェントはMCP経由でIDEツールに到達し、貼り付けたテキストではなく構造化コンテキストで作業することもできる。

JetBrainsによると、これにより一部のタスクではより良い結果が得られ、場合によっては使用トークンも少なくなる。トークンに関する主張は同社のものであり、独立したテストは公開されていない。

根底にある主張は、エージェントが何を見られるかに関するものだ。ファイルの読み書きしかできないエージェントはテキストから作業する。遅い関数をプロファイリングし、コールスタックを検査できるエージェントは、シニア開発者が同じ問題を診断するときに持つコンテキストを備えている。JetBrainsは26年をかけてそのツール群を構築してきた。Airはエージェントがそれにアクセスできる初めての機会だ。

なぜ今のタイミングが理にかなうのか

JetBrainsは、レビュー工程が認められたボトルネックになったこの時期にこれを投入する。多くのチームにとって、コードを書くことはもはや制約ではない。書かれたものを確認することが制約なのだ。

その判断はツール市場全体で一斉に現れている。Qodoは同じ週にレビューを目玉とするバージョン3.0を出荷し、Cursorはエージェントワークフローにレビューボットを追加した。3社が同じ結論に収束したことは、制約が恒久的に移ったことを示唆している。エージェントが人間の読む速度より速くコードを生成できるなら、価値は読むコストを下げるものへと移る。

Airの設計はそれを反映している。この製品は、並列エージェントセッションを操作すべき会話ではなく、レビューすべき作業のキューとして扱い、セッションごとのコストを変更ファイルと同じビューに表示する。何個のエージェントを走らせるかを決めるエンジニアリングマネージャーにとって、そのコスト表示が実質的な上限となる。

セッションごとのコスト表示は、行動に大きな影響を与える小さな機能だ。長時間実行エージェントが何に使っているか見えないチームは、慎重に1つのエージェントを走らせがちだ。セッションごとの数値が見えるチームは、複数を走らせることにより前向きになる。決定が賭けではなく配分になるからだ。これはクラウド支出ダッシュボードで起きたのと同じ変化であり、人々の仕事の組み方を変える。

Airが解決しようとしている調整問題もある。あるタスクでClaude、別のタスクでCodex、さらに別のタスクでCopilotを実行するチームは、3つの別々のインターフェースに行き着き、それぞれが何に触れたかの共有記録がない。差分、インスペクション、バージョン管理をすでに備えるIDEでそれらを統合することは、新しいツールを採用するより小さな変更であり、Java、Kotlin、PythonでJetBrainsに標準化しているチームにとっては、エージェントを使うためだけに全員を別のエディターに移行させずに済む。

まだ固まっていないこと

Airはアーリーアクセス版だ。JetBrainsは、荒削りな部分、UIと動作の変更、およそ毎週のアップデートを想定するよう求めている。一般提供日は示していない。長時間実行タスク向けのクラウド実行はAIシートを持つ組織に限定されており、JetBrainsはその価格を明示していない。

プライバシーについて同社は、エージェントにサインインしていなければ何もマシンから出ないこと、サードパーティのサブスクリプションを使う場合、データはJetBrains経由ではなく既存の契約に基づいてそのプロバイダーに送られることを述べている。プラグインを無効にしても他に何も変わらず、別個のAI Assistantも引き続きサポートされる。

チーム自身のリポジトリで検証する価値がある主張は、レビューに関するものだ。Airは複数のエージェントを同時に走らせやすくする。それがより多くのマージされる成果を生むのか、誰も読まない差分を増やすのかは実証的な問いであり、ローンチ記事ではなく、使用最初の1か月で答えが出るだろう。