JetBrains AI
Supercharge your tools with AI-powered features inside many JetBrains products
2026 年の方針: JetBrains IDE における AI と従来のワークフロー
有効なコードの作成方法は 2 つありますが、 コードを管理する場所は 1 つしかありません。
AI 関連のニュースを読み飽きた方のための簡易版:
現在、開発者がコードを作成する方法には以下の 2 つがあります。
- 従来の方法: 入力、リファクタリング、デバッグを行いながら 1 行ずつ意図を形成することによって作成する。
- 新しい方法: AI との協働作業を通して作成する。自動補完を使用したり、まとまった量の成果物を下書きできるエージェントを使用したりする。
当社はどちらか一方が優れているとは考えていません。
両方のワークフローが妨げ合うことなく JetBrains IDE 内で共存できるようにすることを目標としています。 実際の開発では、以下を目指しています。
- ユーザーが自分でコードを書く場合、IDE はコードの作成のみに注力し、AI によって基本的なコーディングエクスペリエンスが損なわれないようにする。
- ユーザーが AI でコードを生成する場合（またはタスクをエージェントに委任する場合）、IDE は UX と機能の両面で自然で強力に感じられるコードを作成するようにする。
いずれにしても、リリースされるコードの責任は人間が負う ということは変わりありません。また、そのコードを読み取り、理解し、管理する場所が IDE であることにも変わりありません。
誇張やまやかしを排した、「IDE における AI」とは
当社は 1 つの「正式な」ワークフローに制限しようとしているわけではありません。 1 つに絞るには市場の変化が速すぎますし、開発者の多様性の幅が広すぎるため、万能な対応を取ることはできません。
そのため、当社が言うところの「JetBrains IDE における AI」とは、エージェントによる付加価値、つまり必要に応じて以下の場所で使用可能になる UX と機能を指します。
- AI Chat（AI チャット）ツールウィンドウ。チャット主導のワークフローとして提供されます。
- IDE ターミナル。すでに多数の開発者がターミナルで CLI ツールを使用しています。
- エージェント型システム用に作成された新しいオプトインモード。このモードではエージェントを実行し、数時間動作させることができます。
1 つの IDE の中に AI を使用して作業を完了する手段が複数存在すると考えてください。ユーザーが手段を選択し、チームで調整を行い、実際の開発要件に従って制約をかけるのです。
AI 戦略: ベンダーロックインを回避しワークフローの互換性を維持
1 つだけ確かなのは、現時点で「最良」のモデル、プロバイダー、またはエージェントがいつまでも最良であり続けることはなく、来月ですら最良かどうかは分からないということです。
そのため、当社はある特定のベンダーのロードマップに依存しない IDE エクスペリエンスを意図的に目指して開発を行っています。
実際には、JetBrains の AI チャットで以下のようなプロバイダーの利用規約で許可されている内容やユーザーの実際の要望に応じて複数の接続方法をサポートすることを意図しています。
- JetBrains AI が管理する構成（JetBrains AI サブスクリプションを使用）
- BYOK: Bring Your Own Key 方式の API キー
- OAuth サインイン: サポート対象プロバイダーのアカウント（プロバイダーがサポートしている場合）
- ACP エージェント: 標準プロトコルを通じて外部のコーディングエージェントを接続します。
実情の補足: OAuth は必ずしも使用できるわけではありません。 エージェントプロバイダーが OAuth を提供していない（または IDE が使用できる方法で提供していない）場合、当社が接続を作成することはできません。
エージェントクライアントプロトコル（ACP）:「独自エージェントの使用」
ACP を使用すると、標準的なインターフェースを通じて外部コーディングエージェントを JetBrains IDE に接続できます。そのため、IDE で個々のエージェントを個別に統合する必要はありません。 精選されたレジストリからエージェントをインストール（または手動で構成）すると、インストールされたエージェントを AI チャット内で使用できるようになります。
ユーザーが要望していたエージェントの実例には、Cursor エージェントがあります。 Cursor はすでに ACP を通じて JetBrains IDE 内で AI エージェントとして使用できるようになっています。エージェント選択メニューでこのエージェントを選択すると、JetBrains IDE 内でこのエージェントのエージェント型ワークフローを使用できるようになります。
当社が以下のような方針をとっています。
- ユーザーがワークフローまたはチームに最適なエージェントを選択する。
- ユーザーはすでに使用している IDE 内で作業を継続する。
- 「エージェントモード」によって従来の IDE のワークフローが排除されない。
より強い責任が求められる「AI による業務コーディング」
JetBrains が対抗しているのは AI ではなく、 混乱です。
ある種のコーディングは成果物を使い捨てるように最適化されており、これは適切な状況下では非常に有効です。 しかし、JetBrains IDE は使い捨てのコードではなく、長期的な使用を意図したコードを想定して構築されています。
当社は生成されたコードが実際のコードと同じように扱われるべきだ という設計原則に従っています。つまり、以下のことが可能でなければなりません。
- コードの読み取り
- コードのレビュー
- コードの変更
- 誤っている場合に元に戻す
- コードのコードベースに対する影響を理解する
実際には、JetBrains が求める最低条件は以下のように（良い意味で）平凡なものです。
- 変更が可視化されていること
- 変更を元に戻せること
- プロジェクトが破綻したまま放置されないこと（まずは「赤文字のコードをなくす」ことを良しとする）
そして当然ながら、エージェントは多数のファイルを編集できます。 エージェントは非常に役に立ちますが、それはユーザーが生成されたコードを十分に検査し、理解し、訂正できる場合に限ります。 ここで重要となるのが IDE です。IDE は人間または AI が生成したコードを可視化し、制御可能にします。
ユーザーの観点で動作する AI: 当社の製品への取り組み
1. AI と従来のモードを共存させる
入力主導のワークフローも AI 主導のワークフローも有効な手法です。 当社は開発者を置き換えるというナラティブに沿って開発しておらず、ユーザーに唯一の「承認された」作業方法を促す IDE も開発していません。 当社は両方の手法を尊重しています。
2. AI エージェントに IDE の基礎を尊重させる
エージェントに移行するにあたり、高度なコードインテリジェンス、安全なリファクタリング、デバッグ、移動操作、インスペクション、レビューなど、業務開発を構成する IDE の基礎を損なわないようにする必要があります。
3. ベンダーロックインをなくす
複数の有効化方法（サブスクリプション、BYOK、可能な場合の OAuth、ACP エージェント）は「あると良い」であってはいけません。 当社はワークフローが 1 つのベンダーに縛られないようにしています。
4. 流行よりも長期的な実用性を重視する
前述のワークフローが数週間後も継続的に使用されている場合（実際の定着率、実際のプロジェクト数）、その有効性が実証されているということになります。 今日の AI 駆動型の多くのワークフローは流行りものに過ぎません（ralph-loop のことです）。
5. コミュニティからの率直なフィードバックを優先する
JetBrains は Reddit ユーザー、Marketplace のレビュー投稿者、コミュニティメンバーの率直で正直な意見を大切にしており、 まさにそのようなユーザーに当社の取り組みを評価していただきたいと考えています。
AI は大量のコードを作成します。 これはもはや予測ではなく、2026 年 4 月時点の現実です。
とは言え、そのコードに対する責任を誰かが取らなければならないということに変わりはありません。 従来通り、コードをマージする前に査読する人が必要なのです。 エージェントの力を借りて作業を素早く進められるようになったものの、エージェントがユーザーの代わりにリスクを負うことはできません。
そのため、当社は以下のように単純明快な取り組みを行っています。
今後も開発を加速する AI ワークフローを構築し続け、IDE を出荷されるコードのレビュー、理解、管理に最適な場所として強化し続けます。
どの程度の AI 機能を使用するかは、ユーザーの決断に委ねられています。 AI 支援型の手法と従来の手法の両方がうまく連携し合えるようにしつつ、ユーザーが好みの方法を選択できるようにする予定です。
オリジナル（英語）ブログ投稿記事の作者：
