JetBrains Central — IntelliJの会社が「エージェントの管制塔」を作った理由
90%。
2026年1月にJetBrainsが実施したAI Pulse調査(11,000人の開発者)で、業務でAIを使っていると答えた人の比率だ。コーディングエージェントを既に使っていると答えた人だけでも22%いる。1年前はほぼ誰も「エージェント」という言葉を業務の文脈で口にしていなかったことを考えると、この数字は急傾斜だ。
この数字を見たJetBrainsが何をしたかというと、IntelliJもPyCharmも新バージョンを出さずに、まったく別のレイヤーのプロダクトを発表した。それが3月24日に発表された「JetBrains Central」だ。
一言でいうと、エージェントの管制塔。
JetBrains Central は何か
Central は IDE ではない。コーディングエージェントが複数走っている現場で、それらを横断的に統治・管理・最適化するためのプラットフォームだ。JetBrains 自身は「agentic software development のための open system」と呼んでいる。
構成要素は3つある。
Governance レイヤー. ポリシー適用、アイデンティティ/アクセス制御、オブザーバビリティ、監査ログ、コスト配賦。AIエージェントが勝手にリポジトリを触り、誰も何を見ていない—— という状態を企業が許容できない現実に、正面から答えようとしている部分だ。
実行インフラ. クラウド側のランタイム、計算リソースのプロビジョニング、エージェントがチーム共通の環境で動くための土台。ローカルIDEから切り離されたエージェント実行を前提にしているあたりが現代的だ。
Context & 最適化. リポジトリ横断、プロジェクト横断の意味的コンテキストを共有して、タスクごとに「どのモデルをどのツールで使うか」をルーティングする層。Claude Agent、Codex、Gemini CLI、独自構築のエージェント——どこからでも接続できる開放設計になっている。
つまり、JetBrains Central は「誰の IDE か」を問わない。あなたが Cursor を使っていても、Claude Code を使っていても、Codex CLI を使っていても、Centralはその下で「誰が・どのタスクに・どのモデルを・どれだけ使ったか」を束ねる層として動く、という位置づけだ。
ローンチパートナーが物語ること
個人的にいちばん面白いと思ったのは、ローンチパートナー一覧だ。Google Cloud、Anthropic、OpenAI、が同じ図に並んでいる。
AIコーディング領域の3巨人が、同じ一枚の JetBrains スライドの上に揃っている構図はめずらしい。ここから読み取れるのは、**「単体モデルの勝負はもう決着がつかない、オーケストレーションの勝負に移っている」**という業界の共通認識だと思う。
Anthropic は Claude Managed Agents を出し、OpenAI は Codex を周辺ツール群ごと押し出し、Google は Antigravity を投入した。それぞれが自社のエージェント宇宙を構築している最中だが、エンタープライズの現場には複数ベンダーが共存することを誰もが分かっている。だから「中立なオーケストレーション層」にそれぞれが接続しに行く価値がある。JetBrains は長年のIDEベンダーとして、その「中立」を演じるのに向いているポジションにいる。
「Code With Me を終了してまで」が示すもの
The Register が皮肉交じりに書いていた見出しがいちばんインパクトがあった。「JetBrains、Centralを投入、Code With Me を終了」。
Code With Me は JetBrains IDE のリアルタイム共同編集機能で、いわば JetBrains 版の Live Share だった。それを引っ込めてまで Central にリソースを振り向けるというのは、**「人間どうしのペアプログラミングという比喩は賞味期限切れ、これからは人間と複数エージェントの協調だ」**というメッセージに見える。
正直、Code With Me を使っていた開発者には気の毒な判断だ。ただ、方向性としてはわかる。Live Share 的な機能は VS Code が強く、競争優位を作れないまま消耗戦になっていた。そこで戦うより、誰もまだ本気で手をつけていない「エージェント統治」の領域を取りにいく方が、JetBrains というブランドの強みと噛み合う。
Cursor、Zed、Antigravity との住み分け
Central と競合する可能性があるのは、このあたりだ。
Cursor 3 の Agents Window. 複数エージェントを並列に動かす UI という意味では似ている。ただし Cursor は「エディタ側のインタフェース」に寄った設計で、統治・監査といった管理側の機能は Central ほど厚くない。個人開発者・小規模チームに Cursor、複数チーム横断の大企業に Central、という棲み分けになりそうに見える。
Google Antigravity. Google が出している「エージェント前提の新しい IDE」。モデルが Gemini に寄っているので、マルチベンダー前提の Central とは前提が違う。Google エコシステム内で完結するチームには Antigravity、複数ベンダーを混在させたいチームには Central が向く。
Zed の agentic editing. Zed はエディタ自体のパフォーマンスと UX を武器にしていて、エージェント機能は「エディタの中で軽快に動く補助」という立ち位置だ。Central のように統治レイヤーを構築するのではなく、エディタ中心の思想で、役割が違う。
面白いのは、この 4 つが必ずしも「同じ椅子を取り合っている」わけではないこと。現場によっては、Cursor や Zed を個人が使い、Central が会社レベルで全体を監視しているという重ね方になる可能性がある。
ユーザー視点で考えると何が変わるか
開発者個人の視点で、Central が本当に効いてくるのは次のような場面だ。
1日の中で、あなたは Claude Code で新機能を書き、Codex でテストを直し、Gemini でドキュメントを作り、Cursor の Agents Window で別のチームが出したバグを調査する——というふうに、複数のエージェントを渡り歩く日常が、もう一部では現実になっている。そうなると、「今月はどのエージェントがどのタスクに何トークン使ったか」「このリポジトリにどのエージェントがアクセスしたか」「社外秘の該当ディレクトリを触ったエージェントがいないか」といった問いが、急に現実味を帯びる。
Central が提示しているのは、まさにそこへの答えだ。個人にとっての具体的な恩恵は次の3つにまとまると思う。
- コストの可視化. AIコーディングは便利だが、クラウドエージェントが裏で走り続けて月末に予算を食い尽くす問題は、すでに多くのチームで起きている。これを部門・プロジェクト・個人の粒度で把握できるのは、経理的にも心理的にも大きい。
- エージェントの証跡. 「誰が何をコミットしたか」ではなく「どのエージェントがどこを触ったか」が残る。AI起因の不具合やセキュリティ事故が起きた時、どこを調べればよいかが明確になる。
- ベンダーロックインの回避. ひとつのエージェントベンダーに縛られずに済む。Codex が値上げしたら Claude に、Claude が使いづらくなったら Gemini に、と柔軟にルーティングを変えられる状態を維持できる。
これらが本当に EAP で使えるレベルで揃ってくるなら、エンタープライズの AI コーディング活用は段階がひとつ進む。
率直にひっかかる点
良いことばかり書いていないか、と聞かれそうなので、正直にひっかかる点も書いておく。
まず、EAP が Q2 2026 開始で、一般公開のスケジュールはまだ明示されていない。 デザインパートナー主導で進むとアナウンスされているので、普通の開発者が触れるまでにはもう少し時間がかかる。エージェント統治というテーマは急を要するので、出遅れれば独自プロダクトや OSS のオーケストレータに出し抜かれるリスクがある。
次に、JetBrains の IDE を使っていない組織に Central が刺さるかは読めない. 思想的には IDE 中立を謳っているが、営業導線は IntelliJ / PyCharm / Rider を大企業で導入している顧客からになるはずだ。VS Code / Cursor / Zed に完全移行した組織が、Central だけをわざわざ契約するインセンティブは弱い。ここはプロダクトの完成度というより、JetBrains の営業力の問題になりそうだ。
最後に、「エージェント統治」が本当に必要になるのはこれから. 多くの企業はまだエージェントを個人単位でポチポチ使っている段階で、ガバナンスの痛みはまだ顕在化していない。Central は少し先のニーズを先取りしている。だから成否は、JetBrains がどれだけ早く「痛みが顕在化した組織」に導入できるか次第だ。
眺めておくべきタイミング
個人的には、Central のニュース自体より、Q2 の EAP で先行して入る企業が誰かを見るのが一番面白いと思っている。金融、製薬、官公庁のような規制が厳しい業界で先に導入が進むなら、「AIエージェント時代の監査基盤」として定着する可能性が高い。
一方で、テック企業が自前のオーケストレータを書き始めるほうが早いなら、Central は「IDEの老舗が遅れて出してきたもの」で終わる。どちらに転ぶかが 3 ヶ月後、6 ヶ月後に見えてくる。
いまのところ、現場の開発者ができることは少ない。EAP の案内が出たら乗るかどうか検討する、くらいだ。ただ、「複数エージェントがチームで走り回る未来」を信じるなら、誰がその統治レイヤーを握るかの話は、Cursor v○ や Claude v○ の話と同じかそれ以上の重みを持つ——と私は見ている。
関連記事
Qodo — 「AIが書いたコードをAIが検証する」時代の本命は、コード生成ツールではなかった
Qodo(旧CodiumAI)はAI生成コードの検証に特化したマルチエージェントシステム。ベンチマーク最高F1スコア60.1%、$70M調達の背景、CodeRabbitとの違いを整理する。
Cursor 3 vs Claude Code — 同じタスクでトークン消費5.5倍差。それでも「両方使う」が正解な理由
Cursor 3とClaude Codeを料金・トークン効率・エージェント性能・コンテキスト窓で比較。独立ベンチマークの数字と実務での使い分けパターンを解説する。
GLM-5.1 — SWE-Bench Proで首位を奪った中国発OSSモデル、8時間自律コーディングの実力と死角
Z.ai(智譜AI)のGLM-5.1はSWE-Bench ProでGPT-5.4やClaude Opus 4.6を上回った744Bオープンモデル。8時間連続自律コーディングの仕組み、料金、ベンチマークの裏側を解説する。