JetBrains: «Стратегия 2026 — ИИ и классические рабочие процессы в IDE»

Источник: https://blog.jetbrains.com/ai/2026/05/our-2026-direction-ai-and-classic-workflows-in-jetbrains-ides

Краткое содержание

Программный пост (на японском, оригинал — английский) Дениса Ширяева о позиции JetBrains относительно ИИ в IDE. Главный тезис: «есть два валидных способа писать рабочий код — традиционный (ввод, рефакторинг, отладка по строке) и новый (совместная работа с ИИ через автодополнение и агентов), и JetBrains не выбирает между ними». Цель — чтобы оба варианта работали в одном IDE «не мешая друг другу», и в любом случае «человек отвечает за выпущенный код, а IDE — место, где этот код читается, понимается и сопровождается».

ИИ в JetBrains, по тексту, доступен в трёх точках: AI Chat (как chat-driven workflow), IDE Terminal (CLI-инструменты, которыми и так пользуются разработчики) и новый opt-in режим для агентов, в котором их можно запускать на часы. Стратегия — «не зависеть от дорожной карты конкретного вендора»: подключение к моделям через JetBrains AI subscription, BYOK (API-ключ), OAuth, ACP (Agent Client Protocol) с курируемым реестром агентов. Cursor уже доступен в JetBrains IDE через ACP. Принципы: пользователь выбирает агента, остаётся в своём IDE, «agent mode» не вытесняет классический workflow.

«AI generated code ↔ настоящий код»: сгенерированный код должен быть так же читаем, ревьюируем, изменяем, откатываем и понятен по влиянию. Минимальные требования — изменения видимы, обратимы, проект не оставлен «сломанным» (приоритет «no red code»). Программные направления продукта: сосуществование AI и классических режимов; уважение фундамента IDE (code intelligence, безопасный рефакторинг, отладка, навигация, инспекции, ревью); отсутствие vendor lock-in (через JetBrains AI/BYOK/OAuth/ACP); долговечная полезность вместо моды; приоритет честной обратной связи Reddit/Marketplace/сообществ.

// Иллюстрация: чтение из настроек подключения к разным провайдерам
{
  "ai_chat": {
    "providers": [
      { "type": "jetbrains_ai", "subscription": true },
      { "type": "byok", "api_key_env": "OPENAI_API_KEY" },
      { "type": "oauth",  "provider": "anthropic" },
      { "type": "acp",    "agent": "cursor", "endpoint": "acp://localhost/cursor" }
    ],
    "fallback": "jetbrains_ai"
  }
}

Значимость

Программный стратегический пост, который имеет смысл читать рядом с майскими EAP-релизами ReSharper и Rider того же мая: он формулирует, почему JetBrains строит ACP как открытый протокол, а Junie — как первого «опорного» агента, не как замок-in.

🧾 Транскрипт (формат)

2026 年の方針: JetBrains IDE における AI と従来のワークフロー Source: https://blog.jetbrains.com/ai/2026/05/our-2026-direction-ai-and-classic-workflows-in-jetbrains-ides

有効なコードの作成方法は 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 支援型の手法と従来の手法の両方がうまく連携し合えるようにしつつ、ユーザーが好みの方法を選択できるようにする予定です。

オリジナル（英語）ブログ投稿記事の作者：

Denis Shiryaev