IDEにおけるJetBrains AirがEAPを開始、ただし本命はオーケストレーション
JetBrainsは、並列タスク向けに設計されたワークスペースへ5つの対応コーディングエージェントを導入するJetBrains Air in IDEsの早期アクセスを開始した。この動きは、もう1つのチャットボットを追加することよりも、AI生成コードを開発者がどこで監督するのかを決めることに重点がある。
Airは、Codex、Gemini、GitHub Copilot、Claude Agent、そしてJetBrains独自のJunieを標準でサポートする。また、コーディングエージェントと開発環境の共通インターフェースであるAgent Client Protocol、すなわちACPを通じて、ほかの互換ツールにも接続できる。
これはJetBrainsを、ソフトウェア開発をモデル中心で捉える考え方と対峙させる。そのモデルでは、開発者は現時点で最も優れた成果を出すエージェントに従う。JetBrainsは、コンテキストを提供し、並行作業を追跡し、人間があらゆる変更をレビューできる環境こそが持続的な製品になると見込んでいる。
当初の見出しでは、5つのIDEにEAPが提供されると伝えられた。JetBrainsの現行ドキュメントでは現在、Android Studioを除く同社IDEラインアップでプラグインをサポートするとされており、最初の説明より最終的な対象範囲は広い。より重要なのは引き続き5エージェントという数字であり、Airはそれらを1つの操作画面内で交換可能な作業者として扱う。
JetBrainsは、開発者にCodex、Claude、Gemini、Copilot、またはCursorを手放すよう求めているわけではない。これらのシステムをJetBrains製品内で動作させたいと考えている。この違いにより、JetBrains Air EAPは、エージェントが実装のより多くを担う時代においても、IDEがソフトウェア開発の中心であり続けられるかを試すものとなる。
IDEにおけるJetBrains Airはワークスペースとモデルを分離する
JetBrains Air in IDEsはオーケストレーション層であり、新しいモデルでもAI Assistantの名称変更でもない。
JetBrainsは10月上旬、MarketplaceおよびIDEの2026.3 EAPビルドを通じてEAPを開始した。同社のAir EAP発表によると、このプラグインはエージェントを同梱せず、AIプロバイダーとしても機能しない。
この設計が重要なのは、利用者がしばしば1つの統合体験として受け取る3つの製品を分けるためだ。モデルはテキストを生成または解釈する。コーディングエージェントはタスクを計画し、ツールを操作し、ファイルを編集し、コマンドを実行する。Airはこれらのエージェントと作業をIDE内で整理する。
開発者は、各プロバイダーの認証規則に従い、すでに使っているエージェントを接続できる。互換性のあるサードパーティ製エージェントを実行するだけなら、JetBrains AIサブスクリプションは不要だ。Airはローカルのエージェントインストールを検出し、レジストリを通じてエージェントを提示し、対応する認証方法を再利用できる。
明示的なファーストクラスサポートを受けるのは、Codex、Gemini、GitHub Copilot、Claude Agent、Junieの5エージェントだ。CursorやほかのツールもACP互換性を通じて利用できるが、正確なインターフェースや認証経路はエージェントによって異なる場合がある。
この製品は、単一の継続的なチャットではなく、セッションを中心に作業を整理する。各セッションは、タスク、そのエージェント、コンテキスト、進行状況、そして生成した変更を表す。開発者はプロジェクト横断で進行中の作業を確認し、入力待ちのセッションを特定し、完了した変更をレビューのために開ける。
Airはプリセットにも対応する。プリセットには、エージェント、モデル選択、推論の強さ、アクセスレベル、その他の起動設定が保存される。これによりチームは、定型的な修正、大規模なリファクタリング、レビュー、実験向けに異なる構成を作成できる。
この構造により、IDEはディスパッチャーとなる。開発者は、失敗したテストをCodexに送り、ドキュメント変更をGeminiに割り当て、パフォーマンス問題の調査をJunieに依頼できる。Airは、これらのエージェントが1つの集合知として協調すると主張しているわけではない。各タスクに見える場所を与え、その出力をレビューのワークフロー内に保つ。
この区別により、「5つのAIエージェントを実行する」という表現に関する重要な誤解を防げる。Airは標準で5つの指定エージェントをサポートするが、5つすべてを同時に実行する必要はない。また、同時に動くエージェントが互換性のあるコードを生成する保証もない。
JetBrainsの現行Airドキュメントでは、ローカルエージェントは開発者のマシン上で実行される。AirはACP互換エージェントとはプロトコルを通じて通信し、コマンドラインエージェントはIDE内でターミナルインターフェースを維持できる。
このプラグインは2026.2バージョン向けにインストール可能で、2026.3 EAPビルドには同梱される。JetBrainsは現在、Android Studioを除く同社IDE全体でのサポートを文書化している。利用可能性、エージェント認証、クラウド実行は、引き続きユーザーの製品バージョンや組織設定に左右される可能性がある。
こうした詳細により、これは単なる配布アップデート以上のものになる。JetBrainsは、既存のエディター、デバッガー、インスペクション、ナビゲーション、バージョン管理ツールを成果物の近くに置いたまま、委任された作業を中心にAIインターフェースを再編している。
JetBrainsがAIチャットパネルを超えようとしている理由
JetBrainsへの圧力は、単に言語モデルが強力になったことではなく、開発者の行動変化から生じている。
IDEベースのAI機能の第一世代は、オートコンプリートとチャットを中心としていた。開発者はコードを選択し、質問を投げ、回答を受け取り、何を貼り付けるか、あるいは適用するかを判断した。このやり取りはサイドパネルに無理なく収まった。
コーディングエージェントは異なる管理上の問題を生む。複数のファイルを読み、計画を立て、コマンドを実行し、リポジトリを変更し、テストを実行してから制御を返せる。開発者は、最初のエージェントが動作中のまま別のタスクを開始することもできる。
JetBrainsによれば、同社は既存のAI Assistantチャット内により多くのエージェントを配置することを試みた。しかし、並行タスクの監督には、会話履歴ではなく作業状態を中心に構成された製品が必要だという結論に至った。
この結論は、EAP期間中にAirとAI Assistantが分離されたままである理由を説明する。AI Assistantは、既存のIDE体験の中で、チャット、補完、コードインサイト、次編集候補、エージェントアクセスを引き続き提供する。Airはエージェントとセッションを作業の主要単位として扱う。
JetBrainsは、将来的にAirが主たるエージェント型インターフェースになると見込んでいるが、AI Assistantの廃止は発表していない。利用者はAI Assistantをインストールしたままにできるが、AI Assistantの通知からAirをインストールすると、両インターフェースの同時実行を防ぐため旧プラグインは無効化される。プラグイン設定から再び有効化できる。
より深い競争上の論点は、開発者の注意を誰が握るかにある。エージェントファーストのエディターやコマンドラインツールは、従来のIDEから作業を引き離し得る。開発者が大半の時間を別の場所でプロンプトの発行とパッチのレビューに費やすなら、IDEは難しいデバッグのときだけ使う二次的な場所になりかねない。
Airはこの流れを逆転させようとしている。JetBrainsと外部エージェントのどちらかを選ぶよう開発者に強いるのではなく、外部エージェントをJetBrains環境へ招き入れる。エージェントが計画と生成を担い、IDEがリポジトリのコンテキストと検証ツールを提供する。
このアプローチは、モデルの移り変わりにも対応する。先進的なコーディングモデルは、組織が開発環境を切り替えるより速く変化し得る。企業は、Java移行にはあるエージェント、インターフェース作業には別のエージェント、制限付きコードを含むリポジトリには社内エージェントを選ぶかもしれない。
Airがこれらのシステムを管理する場所であり続けるなら、JetBrainsはJunieがすべての比較で勝つ必要はない。強力なサードパーティ製エージェントは共有ワークスペースをより有用にするため、同社はその恩恵を受けられる。
これがACPが中心的な役割を担う理由である。ACP contractは、IDEのようなクライアントとエージェントの間の共通接続を定義する。エージェントは、自身のモデル選択、ツール、認証、計画行動を保持する。
JetBrainsはこの境界を、Language Server Protocolの役割になぞらえている。エディターは、互換性のある言語サーバーごとに別個の非公開統合を必要としない。ACPは、各エージェントと各開発環境の間で専用プラグインを作る必要を減らすことを目指す。
この類推には限界がある。コーディングエージェントはコマンドを実行し、リポジトリの広範な部分を変更できるため、その権限と副作用にはより大きなリスクが伴う。それでも、共通の接続層は統合作業を減らし、エージェントの切り替えによる混乱を抑える。
JetBrainsにとって、これは戦略的な機会を生む。Cursor、Codex、Claude、Copilot、Geminiをモデル層で打ち負かす必要はない。それらはJetBrainsのマルチエージェントIDE内の選択肢になり得る。
IDEはエージェント作業のコントロールプレーンになる
Airの中心的な賭けは、コード生成が容易になるほど検証の価値が高まるというものだ。
パッチの生成はソフトウェア開発の一部にすぎない。誰かが、そのパッチが要件に合うか、アーキテクチャを維持するか、テストに合格するか、セキュリティ境界を尊重するか、実環境で正しく動作するかを判断しなければならない。
JetBrainsはすでに、その作業に使われる多くのツールを保有している。同社のIDEは、シンボル、型、参照、プロジェクト構造、テストランナー、バージョン管理、データベース、デバッガー、パフォーマンスプロファイルを理解する。Airはエージェント活動を、これら既存の画面や機能と結び付ける。
エージェントは、ファイル、コミット、スクリーンショット、再利用可能な指示をコンテキストとして受け取れる。開発者は、変更されたファイルを調べ、差分を比較し、関連コードをたどり、結果を別のアプリケーションへ移すことなくプロジェクトを実行できる。
この接続により、重複した探索を減らせる可能性がある。コーディングエージェントはしばしば、ディレクトリの一覧表示、設定ファイルの確認、関連シンボルの特定にトークンを費やす。IDEが提供するコンテキストは、適切なコードへ早い段階で誘導できるが、削減効果はエージェントやタスクによって異なる。
Airはまた、対応エージェントに、デバッグ、プロファイリング、データベース探索、セマンティックコード検索などの活動向けIDEスキルへのアクセスを提供する。JetBrainsによれば、これらのツールはいくつかのタスクで成果を改善できるが、この主張はリポジトリや言語をまたいだ広範な検証がなお必要だ。
エージェントセッションは、このワークフローのコンテナになる。選択したエージェント、会話、アクティビティ、変更ファイル、コミット、報告されたコストを記録する。セッションは複数のプロジェクトにまたがって表示されたままにできるため、完了した作業や介入を必要とする作業を開発者が把握しやすくなる。
このモデルは、5つのチャットタブを開くこととは異なる。チャットタブが主に保持するのは会話である。Airセッションは会話をリポジトリの状態やレビューアクションに結び付ける。
たとえば、失敗している統合テストを抱えるサービスを担当する開発者を考えてみよう。1つのセッションで障害を調査できる。2つ目では、隔離されたブランチで関連依存関係を更新できる。3つ目では、その変更の影響を受けるドキュメントを確認できる。
これらのセッションが進む間、開発者はメインのチェックアウトで作業を続けられる。1つが完了すると、IDEは差分のレビュー、インスペクションの実行、テストの確認、そして成果を対象ブランチに取り込むべきかを判断する場所になる。
このプロセスは、エンジニアリング作業におけるより広い変化に合致する。開発者は、あらゆる実装を直接入力するのではなく、生成された変更を調整する機会が増えている。責任が消えるわけではない。タスクの指定、コンテキストの提供、証拠の確認、競合の解消へと移る。
JetBrainsは、IDEをこうした責任のためのコントロールプレーンとして位置付けている。この用語は、作業者そのものではなく、作業者と状態を調整する画面や基盤を意味する。Airは、複数のエージェントを監督しやすくするなら、最良のパッチを生成しなくても価値を持ち得る。
モデルはユーザーの選択肢も維持する。プロバイダーが許可する場合、開発者は既存のサブスクリプションを接続でき、JetBrains AIを選択することも、ローカルで設定したACPエージェントを使うこともできる。Air自体は独自のモデルを提供しない。
この柔軟性は戦略的に重要だ。単一モデルに紐づく閉鎖的なワークスペースは、そのモデルの弱点や商業的な変更も引き継ぐ。マルチエージェントのワークスペースなら、プロジェクトの慣行やレビュー用ツールを維持したまま、開発者がエージェントを入れ替えられる。
すでに検索可能なエンジニアリングコンテキストを構築しているチームには、同じパターンが見覚えあるものかもしれない。永続的な資産は単一の回答ではなく、コード、意思決定、文書、レビューを結び付ける構造だ。技術ナレッジベースは、1つのコーディングタスクを超えて残すべき情報を保持することで、エージェントセッションを補完できる。
Airだけで、このより広範なナレッジの問題を解決することはできない。セッションには有用な作業コンテキストが含まれるが、チームにはアーキテクチャ上の決定、インシデント、要件のための永続的な記録も必要だ。IDEは実装を調整できる一方、共有ナレッジシステムはその実装が存在する理由を保存する。
並列エージェントはマージと注意力の問題を生む
複数のエージェントを動かしても、開発者がその出力をレビューし、整合させ、信頼できる場合にのみスループットは高まる。
Airでは、開発者はブランチからセッションを開始し、作業を一時的なGit worktreeに配置できる。worktreeは、同じリポジトリ履歴に紐づく別個の作業コピーだ。エージェントによる編集を、開発者が現在チェックアウトしている環境から分離する。
この分離は並列作業に不可欠だ。1つのワークスペースで同じファイルを編集する2つのエージェントは、前提を上書きしたり、それぞれ単独では通過するものの組み合わせると失敗する変更を作ったりする可能性がある。別々のworktreeは直接的な干渉を減らす。
Airは結果を表示し、選択したコミットをアクティブなプロジェクトへ戻せる。ドキュメント化されたセッションワークフローは、変更を対象ブランチへcherry-pickする前にレビューすることをサポートしている。
分離しても統合作業はなくならない。5つのエージェントが関連する領域を変更すれば、開発者は5つのブランチ、重複した編集、一貫しない抽象化、マージコンフリクトに直面するかもしれない。各エージェントはもっともらしいローカル結果を生み出せても、統合されたシステムの一貫性は低下しうる。
するとボトルネックは、コード生成から人間の注意力へ移る。開発者は各エージェントが何を、なぜ変更したのかを理解しなければならない。また、コードを書いた同じシステムが生成した成功サマリーを受け入れるのではなく、どのテストが意味のある証拠を提供するかも判断する必要がある。
Airのセッション一覧は、その作業負荷を可視化するのに役立つ。アクティブなセッション、未読の更新、変更されたファイル、送信済みコミット、入力待ちのタスクを表示できる。この可視性は有用だが、根底にある意思決定が正しいかどうかを判断することはできない。
これがJetBrains Air EAPの中核的なトレードオフだ。並列性は待ち時間を短縮できる一方で、レビューの責務も増幅させうる。検証できる速度を超えてエージェントを起動するチームは、不確実なパッチのキューを大きくしているにすぎない。
プリセットは別のガバナンス上の懸念ももたらす。設定を再現可能にする一方で、チームはどのモデル、権限、作業レベルを各タスク分類に割り当てるべきかを決めなければならない。使い捨てのテスト用リポジトリには適した高権限のエージェントが、本番インフラでは受け入れられない場合がある。
認証も依然として一様ではない。JetBrainsは、プロバイダー管理のログイン、サードパーティーの認証情報、JetBrains AIなど、複数の経路をサポートしている。ただし、あるインターフェースで利用できるサブスクリプションが、別の画面内で同じエージェントを認可するとは限らない。
Claudeはその複雑さを示す例だ。JetBrainsによれば、Claudeのサブスクリプションはターミナル画面を通じて利用できる一方、構造化チャット内のClaude AgentにはJetBrains AI、またはAPI課金付きのAnthropic APIキーが必要となる。Airを万能のサブスクリプションハブと見なす前に、開発者は現在の認可ルールを確認すべきだ。
クラウド実行では、さらに境界が加わる。ローカルセッションは開発者のマシン上で実行されるが、対象となる組織は特定のタスクをJetBrainsのインフラへ送信できる。クラウド実行はIDEを閉じた後も継続できるが、利用可否は組織設定、リポジトリのホスティング、JetBrains AIサブスクリプションに左右される。
したがって、データの取り扱いは選択した経路に依存する。JetBrainsによると、サードパーティーのサブスクリプションを利用する場合、サードパーティーエージェントのデータはユーザーの既存契約に基づいて直接そのプロバイダーへ送られる。JetBrains AIとクラウド機能は、それぞれに適用される規約の下で運用される。
EAP契約も、成熟度を明確に示している。早期アクセスソフトウェアにはエラーが含まれる可能性があり、予期せぬ挙動を示したり、開発中に変更されたりすることがある。エージェントがファイルを編集しコマンドを実行できる場合、チームはEAPというラベルを形式的なバッジとして扱うべきではない。
慎重な導入は、重要度の低いリポジトリと限定的な権限から始めるべきだ。チームは人間によるレビューを必須とし、復旧可能なブランチを保持し、マージ前に独立したテストを実行すべきである。機密性の高いコードでは、エージェントにコンテキストを渡す前に、プロバイダーとデータルーティングについて明確な判断が必要だ。
これらの制御は、IDEにおけるJetBrains Airへの反対論ではない。その並列モデルを有用にするための条件である。オーケストレーションがレバレッジを生むのは、活動ダッシュボードの背後に責任を隠すのではなく、責任をより可視化する場合に限られる。
JetBrainsは競合を置き換え可能なコンポーネントに変えようとしている
Airは、JetBrainsの開発環境を維持しながら競合のエージェントを取り込むことで、エージェントファーストのエディターに挑戦する。
最も重要な対抗相手は、1社ではない。コーディングエージェントが開発者のワークスペース全体を所有すべきだという考え方そのものだ。
エージェントファーストのエディターは、あらゆる操作を1つの統合システム中心に最適化できる。これは集中的な体験を生むが、開発者のワークフローがその製品のモデルルーティング、インターフェース上の意思決定、リリーススケジュールに依存する可能性もある。
JetBrainsは反対の立場を取る。IDEは安定したまま、エージェントがその中でタスクを競う。開発者は、コードを生成するシステムを変更しつつ、使い慣れたナビゲーション、リファクタリング、デバッグ、インスペクションツールを維持できる。
ACPはこの提案に信頼性を与える。共有プロトコルがなければ、多数のエージェントをサポートするには、増え続ける独自統合の集合が必要になる。プロバイダーの更新ごとにコネクターが壊れたり、製品間で機能に不整合が生じたりしかねない。
ACPでは、置き換え可能な単位はモデルだけではない。エージェントは、計画ロジック、ツール、権限、モデルルーティング、インターフェースの挙動を備えている。Airは共通のクライアント境界を通じて、その完全なパッケージに接続する。
これによりJetBrainsは外部イノベーションの恩恵を受けられる。Codexがリポジトリ規模の変更において向上すれば、Airユーザーはそれを選べる。Geminiが別のワークロードでより優れれば、ワークスペースを変更する必要はない。社内ACPエージェントは、制限されたタスクに利用できる。
したがって、名前が挙がる5つのエージェントは固定された上限ではなく、最初のラインナップだ。Codex、Gemini、GitHub Copilot、Claude Agent、Junieは、EAPに認識しやすい選択肢を与える。レジストリとカスタム設定は、可能な選択肢をさらに広げる。
Cursorは示唆的な例だ。AI志向のコーディング環境として開発者の注目を競う一方、そのエージェントはACP経由でJetBrains製品にも接続できる。JetBrainsは、エディターを乗り換えることと結び付けられている製品を、自社IDE内で利用可能なワーカーに変えられる。
それでも、ユーザーが留まる保証はない。ネイティブなエージェントファースト製品は、より一貫したインターフェース、より速い機能提供、または好みのモデルとのより密接な統合を実現できる。プロトコル互換性によって、すべてのクライアント体験が同一になることはめったにない。
Airは選択の複雑さも正当化しなければならない。権限、サブスクリプション、モード、強みが異なる5つのエージェントは、使い慣れた1つのツールより管理しにくくなる可能性がある。ワークスペースには明確なステータス、予測可能な設定、信頼できるレビュー情報が必要だ。
JetBrains自身の製品ラインナップも別のリスクを加える。ユーザーはすでにAI Assistant、Junie、Air、ACPエージェント、プロバイダーアカウント、JetBrains AIに接している。Airはより明確な概念的分離を作るが、移行期間は依然として断片的に感じられるかもしれない。
同社は、エージェント型ワークフローの専用環境をAirとしつつ、チャットやインライン支援にはAI Assistantを残すことで、この問題を解決しようとしている。ユーザーがこの役割分担を理解し、好むかどうかは、EAPの重要な成果となるだろう。
JetBrainsはまず、独立したAir環境を、AIが付加されたエディターではなく、エージェントを中心に構築された場所として提示した。3月のパブリックプレビューは、同時委任を製品の中心的な考え方として確立した。
この体験を既存IDEに持ち込むことで、提案は変わる。開発者はワークフローを試すために別のアプリケーションを導入する必要がなくなる。JetBrainsは、すでにエンジニアリングチームに定着している製品を通じてAirを配布できる。
この配布上の優位性は重要だが、導入は日常的な有用性に左右される。複数のエージェントを認識できるというだけで、開発者が別のツールウィンドウを使い続けることはない。Airは、並行作業を別々のターミナルやプロバイダーアプリケーションよりも理解、レビュー、マージしやすくしなければならない。
JetBrains Air EAP後に注目すべきこと
次の試金石はAirが何個のエージェントを一覧表示するかではなく、チームがコンテキストスイッチを減らし、管理可能なレビューコストで実際の作業を完了できるかどうかだ。
最初の指標は、通常のリポジトリ全体での導入だ。JetBrainsには、並列セッションを起動する目新しさが薄れた後も、開発者がAirを使い続けるという証拠が必要になる。デバッグ、保守、テスト、リファクタリングをまたぐ反復的な利用は、オーケストレーションの論拠を裏付けるだろう。
有用な指標はプロンプト数ではない。チームは、完了したタスク、受け入れられた変更、レビュー時間、再発した不具合、エージェント完了後に必要となった手作業の修正量を検証すべきだ。セッション数が多くても、低品質な出力を隠している可能性がある。
2つ目の指標は、worktreeベースの統合の信頼性だ。Airはブランチの状態、未コミットの変更、コンフリクト、転送先を明確にすべきである。並列エージェント向けに設計されたシステムは、開発者が作業を失ったり、正しいパッチを誤ったブランチに適用したりすることを防がなければならない。
JetBrainsは保護措置とレビュー制御を文書化しているが、EAPではそれらが日常的な負荷の下でどう機能するかが明らかになる。大規模リポジトリ、生成ファイル、モノレポ、重複するリファクタリングは、孤立したデモンストレーションより厳しいテストとなる。
3つ目の指標は、エージェントプロバイダーと競合エディターからの競争上の反応だ。より広範なACP採用は、開発者が対応クライアント間でエージェントを移動できるため、JetBrainsのオープンワークスペース戦略を強化する。プロバイダーは代わりに、自社アプリケーション内で最もよく機能する独自機能を優先するかもしれない。
共通機能のサポートは、エージェント数と同じくらい重要になる。権限、ツール呼び出し、コンテキスト添付、コスト報告、セッション再開、差分の帰属には、一貫した挙動が必要だ。多数のエージェントを接続しても、その最低限の共通機能しか公開しないプロトコルでは、Airの優位性は限定される。
組織は管理機能にも注目すべきだ。JetBrainsによると、企業は管理されたAIアクセスを通じてAirを無効化できるが、ドキュメントではIDE Services管理がまだ完全ではないとされている。エンタープライズ導入には、プロバイダー、認証情報、クラウド実行、データルーティング、監査可能性に関する明確なポリシーが必要だ。
AirとAI Assistantの関係も、もう一つの具体的なシグナルだ。JetBrainsによれば、Airが優先されるエージェント型体験へと移行する一方、AI Assistantのサポートは継続される。今後のリリースでは、この役割分担がよりシンプルになるのか、それともインターフェースの重複を生むのかが明らかになるはずだ。
移行が成功すれば、開発者には委任タスクのための明確な場所と、軽量なインライン支援のための別の場所が提供される。移行が混乱を招けば、各エージェント、サブスクリプション、チャットモードをどのプラグインが担うのかをユーザーが理解しなければならなくなる。
サポートされる5つのエージェントは、専門性が実用的な価値をもたらすかどうかも示すだろう。開発者には、あるタスクではCodexを、別のタスクではJunieやGeminiを選ぶべきだと判断できる、観察可能な理由が必要だ。そうでなければ、セレクターは生産性向上の機能ではなく、管理上の選択肢になってしまう。
IDEにおけるJetBrains Airは、生成コードがコンテキストとレビューの価値を高めるという、十分に説得力のある前提に立っている。未解決の問いは、開発者を常勤のキュー管理者に変えることなく、1つのIDEで十分な数のエージェントを整理できるかどうかだ。
復元可能なブランチでEAPを試し、複数のファイル、テスト、レビュー手順にまたがるタスクを任せてみてほしい。そのうえで、完全なワークフローを現在のエージェント環境と比較する。Airはコンテキスト切り替えを減らし、変更を確認しやすくし、リポジトリに対する制御を維持できただろうか。それとも、単に5つのインターフェースを1つのウィンドウに集めただけだったのだろうか。この答えが実際のチームで繰り返し示されることで、JetBrains Airがエージェント型開発の運用レイヤーになるのか、それとも興味深い実験にとどまるのかが決まる。
