JetBrains Airの使い方：Alphaプラグイン導入・設定・レビュー手順

JetBrains Airを使うと、JetBrains IDE内でコーディングエージェントを起動し、必要なプロジェクト情報だけを渡して、普段コードをたどったりテストしたりしている画面で変更を確認できます。最初から大規模なリファクタリングを任せる必要はありません。まずAir Alphaをインストールし、エージェントを1つ接続して、ファイル1つと失敗するテスト1つを渡します。差分とテスト結果に納得できるまでは、変更を採用しないことが大切です。

まず押さえておきたい使い方

Airは入力補完ボタンではなく、エージェントを指揮するコントロールルームとして使います。実際の作業はエージェントが行い、Airはセッションをまとめ、IDEのコンテキストを渡し、結果をIDEネイティブのレビュー画面に戻します。

初回のセッションは、次の流れで十分です。

1. IDE MarketplaceからAir Alphaをインストールします。
2. テストを実行できる、破棄可能なプロジェクトまたはブランチを開きます。
3. New Sessionのプリセットを選び、アクセスレベルはStandard Accessのままにします。
4. 最初のメッセージを送り、Airに求められた場合はサインインを完了します。
5. @file:で関連ファイルを添付します。
6. 小さな修正1件と、そのテストを依頼します。
7. Agent Sessionsで変更されたすべてのファイルを確認します。
8. 自分でテストを実行し、変更を採用するか、編集するか、コミットするか、元に戻すかを決めます。

まず信頼できる状態にすべきなのは、この一連の流れです。並列セッション、エージェントの追加、組織向けの管理機能、クラウドへの引き継ぎは、その後で構いません。

JetBrains Airとは何か

Airは、JetBrainsプロジェクトと1つ以上のコーディングエージェントをつなぐレイヤーです。模型店の検品台を思い浮かべると分かりやすいでしょう。エージェントが部品案を作業台に持ってきますが、寸法や適合性を確認し、最終判断を下す道具はIDE側に残ります。

9月22日のリリースで、Airは3つの構成要素を持つ、より広いシステムになりました。個人作業向けのAir in JetBrains IDEs、連携と自動化を担うAir Teams、ポリシー・可視性・コストを管理するAir Governanceです。本ガイドでは、ローカルで実際に動かせるAir Alpha IDE pluginに焦点を絞ります。

このIDEプラグイン自体が、新しい基盤モデルというわけではありません。標準でCodex、Gemini、GitHub Copilot、Claude、Junieを実行でき、JetBrainsによると、ほかのエージェントもACP経由で接続できます。ACP（Agent Client Protocol）は、IDEとエージェントの実行環境全体をつなぐ共通の接続口です。ツールやモデルのルーティングも、その対象に含まれます。

現在のAir IDEページでも、ローカルからクラウドへの引き継ぎは近日提供予定と記載されています。初回を確実に進めるなら、タスクはローカルかつ小さな範囲に留めます。

インストール前に確認すること

Air Alphaは公開アルファ版であり、安定運用を前提とした完成済みのユーティリティではありません。JetBrainsはUIや動作が変わる可能性を明記しており、更新はおおむね毎週行われるとしています。問題の切り分けを始める前に、まず互換性を確認してください。

2026年9月23日時点で、2026.2系向けの現行MarketplaceパッケージはAir 262.8665.463でした。IntelliJ IDEA 2026.2から2026.2.3までと、一覧に掲載された各JetBrains IDEの2026.2系に対応しています。Marketplaceには2026.3系向けのビルドもあるため、使用中のIDE系列によって正確なプラグインビルドは異なります。

今回の検証環境と互換性

IntelliJ IDEA 2026.2.3（ビルドIU-262.10968.63）では、分離したプロファイルにAir 262.8665.463を読み込み、使い捨てのNodeプロジェクトをプラグインエラーなしでインデックスできました。検出されたエージェントはcodex-cli 0.153.4でしたが、サインアウト状態で、ホストにグラフィカルセッションもありませんでした。そのため、Air上での対話的なタスク実行、生成された差分、エージェントが作成したテストの成功については確認できたとはしていません。以下のUI手順は、JetBrainsの現行クイックスタートと、このプラグインビルドに収録されたラベルに基づきます。

JetBrains Airの使い方：初回セッションの手順

1. Air Alphaをインストールする

IDEの設定を開いてPluginsを選び、Marketplaceタブに切り替えます。Air Alphaを検索し、Installをクリックしてください。IDEから求められた場合は再起動します。

Air自体は無料です。ただし、背後で動かすエージェントには、アカウント、サブスクリプション、API利用料のいずれかが必要になることがあります。料金が導入判断のネックになっているなら、Is JetBrains Air Freeで、プラグイン費用とエージェント費用の違いを確認できます。

2. 低コストで失敗を確認できるプロジェクトを開く

最初は、破棄またはリセットできる既存プロジェクトを使います。初回タスクに向いているのは、関連ファイルが1つ、目に見える不具合が1つ、変更が成功したかを判定できるコマンドが1つあるケースです。

たとえば、連続する空白を正しく処理できないslugヘルパー、エッジケースが1つ抜けたフォーマッター、単体テストが失敗している小さなバリデーション関数などが適しています。初回からマイグレーション、認証、デプロイ用コード、広範な依存関係の更新を任せるのは避けてください。

セッションを開く前に、次の基準点を記録します。

• 現在のブランチ、または使い捨てのworktree
• 正確なテストコマンド
• そのテストが現時点で成功するか失敗するか
• タスクによって変更されると予想するファイル

こうしておけば、レビューは感覚ではなく比較に基づいて行えます。

3. New Sessionのプリセットを選ぶ

メインツールバーのNew Sessionボタンを押すと、現在選択されているプリセットでセッションが始まります。別のプリセットを使う場合は、ボタンの山形アイコンを開きます。

プリセットとは、保存済みの起動設定です。使用するエージェントを決めるほか、モデル、reasoning effort、アクセスレベル、セッション画面を事前に選択できます。Airには、組み込みプリセットと並んで、マシン上で検出されたエージェントが表示されます。選択したエージェントが見つからない場合、プラグインからインストールを促されることがあります。

初回タスクではStandard Accessを選びます。現行プラグインのStandard Accessでは、エージェントはプロジェクト内のファイルを読み書きし、コマンドを実行できます。プロジェクト外のファイルやネットワークへのアクセスには承認が必要です。Full Accessでは、ネットワーク利用とマシン上の任意の場所への編集について、この承認確認がなくなります。初回セッションの既定値としては適しません。

4. 最初のメッセージを送り、エージェントを認証する

認証は、エージェントが実際に必要とした時点で始まります。短いメッセージを入力してEnterを押してください。そのエージェントがマシン上ですでに使っている認証情報をAirが見つければ、そのままセッションが続きます。見つからない場合は、Choose a sign-in method to continueと表示されます。

利用できる認証経路はエージェントによって異なります。

• エージェントへのログインは、ブラウザまたはターミナルで続行できます。
• 対象となるJetBrains AIライセンスまたは組織のワークスペースから、クレジットを供給できます。
• Add an AI providerを選ぶと、サードパーティのサブスクリプションまたはAPIキーを設定するTools | Air | Accountsが開きます。

AccountsでMore Providersを選び、必要な認証情報を追加します。Test Connectionで接続を確認し、OKで保存してからセッションに戻り、そのプロバイダーを選択してください。

タスクのプロンプトにシークレットを貼り付けてはいけません。認証情報は、プロバイダーの接続フローで設定します。

5. タスクに必要なコンテキストだけを追加する

Airでは、コンテキスト追加のコントロールから、ファイル、コミット、スキルを添付できます。@file:でファイルを、@folder:でフォルダーを指定することも可能です。この違いは重要です。関連ファイル1つだけを添付するのは、整備士に故障部品を渡すようなものです。一方、リポジトリ全体を添付するのは、ガレージの中身を作業台へすべて広げるようなものです。

初回は、実装ファイルを添付してテストコマンドを明記します。既存の書き方を理解するために必要な場合に限り、テストファイルも追加してください。

6. 範囲を限定し、確認方法まで含めて依頼する

よいプロンプトには、不具合の内容、変更してよい範囲、検証コマンドが明記されています。たとえば、次のように依頼します。

@file:src/slug.jsで、連続する空白の処理を修正してください。必要最小限の関連テストを追加または更新し、node --testを実行してください。依存関係は変更せず、無関係なファイルにも触れないでください。テストコマンドを実行できない場合は、そこで止めて理由を説明してください。

このプロンプトには、エージェントが作業を終える条件があります。「このヘルパーを改善してください」だけでは、その条件がありません。

7. セッションを追いながら、進捗説明だけで評価しない

エージェントは進捗を報告し、必要に応じて質問します。不足している要件には回答し、自分が理解できる操作だけを承認してください。予期しないネットワークアクセスや、プロジェクト外のファイルへのアクセスには特に注意します。

進捗メッセージは状況の把握に役立ちますが、完了の証拠ではありません。証拠になるのは、生成された差分と、自分でも再実行できるテストです。

8. Agent Sessionsで変更をレビューする

Agent Sessionsを開き、完了したセッションを展開します。変更されたすべてのファイルについて差分を開いてください。現行パッケージには、Show Diff、Generate summary...、Revertの各操作があります。JetBrainsのクイックスタートでは、変更されたファイルをそのまま採用する、編集する、コミットする、元に戻すという選択肢が案内されています。

レビューは次の順番で進めます。

1. 範囲： 変更されたのは想定どおりのファイルだけか。
2. 動作： 実装は対象の不具合を正確に解消しているか。
3. テスト品質： 新しいテストは、修正がなければ失敗する内容か。
4. 副作用： 設定、依存関係、公開インターフェースに変更はないか。
5. 検証： エージェントの説明とは別に自分で実行しても、テストは成功するか。

差分がほぼ正しければ、自分で編集するか、次のイテレーションに向けて具体的なフィードバックを残します。変更範囲が予想外なら、元に戻して、さらに対象を絞ったプロンプトからやり直してください。もっともらしい説明だけを理由にコミットしてはいけません。

導入コストをどう計算するか

Airが変えるのはオーケストレーションの費用であり、その下で使う知能の費用ではありません。プラグインのソフトウェア費用は$0ですが、接続したエージェントは、既存のサブスクリプション、API残高、JetBrains AIクレジットのいずれかを消費する可能性があります。

すでにエージェントへ費用を払っているチームにとって、ここは重要です。レビューが改善するか分からない段階で、コントロール画面を増やした結果、さらに1席必要になることもあります。公開されている比較材料として、GitHubは現在、Copilot Businessをユーザー1人あたり月額$19、Enterpriseを月額$39としています。Businessを10席契約すれば、追加利用分を除いても月額$190です。Airは、Airプラグイン自体の料金を追加せずに対応エージェントを接続できますが、IDEライセンス、プロバイダーのサブスクリプション、API利用料、人によるレビュー時間までなくなるわけではありません。

したがって、予算上の問いは明快です。無料のローカルレビュー画面1つで、既存のエージェント支出をより指示しやすく、検証しやすくできるかどうかです。追加購入や全社標準化の前に、1チーム・1種類のタスクで試してください。

効果を得やすい順に見る6つの活用例

1. 複数のエージェントをすでに契約しているJetBrains利用チーム

ある業務にはCodex、別の業務にはClaudeを使っている開発チームなら、どちらも同じIDE環境から起動し、同じプロジェクトコンテキストを添付して、変更ファイルを1か所でレビューできます。既定でトークン代が安くなるわけではありません。効果は、ツール間の移動を減らし、すでに契約しているサービスを一貫した手順でレビューできる点にあります。

2. 小さくテスト可能な不具合を処理するメンテナー

メンテナーは、失敗しているヘルパーを添付し、リグレッションを1件説明し、対象を絞ったテストを必須にしたうえで、ブランチへ反映する前に差分を確認できます。原因は明確でも、機械的な修正を書く時間がより重要な作業を圧迫している場面で効果を発揮します。

3. 慣れていない顧客コードベースへ入るコンサルタント

コンサルタントは、IDEのコードナビゲーションでシンボルを確認し、関連ファイルだけを添付して、範囲を限定した変更をエージェントに依頼できます。Standard Accessを使い、破棄可能なブランチ内に作業を留めれば、見慣れないリポジトリ規約が原因で編集範囲が広がるリスクを抑えられます。暗黙の顧客ルールをエージェントが理解しているかのように扱わずに、立ち上がりを速められる方法です。

4. 再現可能なバグをリグレッションテストへ変えるQAエンジニア

バグを再現できるQAエンジニアは、関係するファイルとテスト領域を添付し、必要最小限のリグレッションテストを依頼できます。そのうえで、テストが本当に不具合を捉えているかを確認します。再現手順から、エンジニアがレビューできる成果物までの引き継ぎを短くできる点が価値です。

5. 実際の差分を使ってレビューを教えるシニア開発者

シニア開発者は、エージェントに小さな実装を提案させた後、使い慣れたIDE内で、範囲、前提、テスト設計、元に戻す判断を若手メンバーと一緒に確認できます。成果物はコードだけではありません。実際の変更セットを使った、目に見えるレビュー演習になります。

6. 同じタスクでエージェントを比較するプラットフォームチーム

プラットフォームチームは、同じ限定タスクを異なるプリセットで実行し、変更されたファイル、テストの動作、承認、レビュー工数を比較できます。評価単位が同じリポジトリ内で検証済みの変更になるため、チャット回答を比べるより有用な評価結果が得られます。

JetBrains Airを軸に作れる2つのプロダクト

1. エージェント変更向けのレビュー証跡サイドカー

こちらの方が有望です。エージェントのセッションから、タスク、添付コンテキスト、変更ファイル、テストコマンド、テスト結果、人による判断、最終コミットへの参照をまとめたレビューパケットを作る、小さなコンパニオンツールを構築します。どのエージェントがコードを生成した場合でも、その上位に置ける明瞭な記録なら、エンジニアリングマネージャーや規制対象のチームに購入価値があります。

需要には注目すべき具体性があります。ai powered code review platformは、米国で月間約1,900回検索されており、商用意図もあります。また、GitHubのBusinessが$19、Enterpriseが$39という席単価からも、チームがコーディング支援とガバナンスにすでに予算を割いていることが分かります。

最小構成で販売する段階なら、エージェント自体を制御する必要はありません。差分とテスト出力を取り込み、レビューチェックリストへの入力を必須にして、署名済みのMarkdownまたはJSON記録をエクスポートできれば成立します。ただし、プラットフォームリスクはあります。Airはアルファ版で、インターフェースが毎週変わる可能性があり、JetBrains自身がより充実した証跡機能や監査機能を追加するかもしれません。競争力の源泉にすべきなのは、単一IDE内の薄いボタンではなく、複数エージェントを横断するポリシーと長期保存できるレポートです。

2. リポジトリ専用のエージェント設定アドバイザー

リポジトリの言語、テストコマンド、機密性の高いパス、コントリビューションルールを調べ、安全な初回タスクのテンプレートとプリセット設定を提案するオンボーディングツールです。リポジトリごとに各開発者が同じ設定作業を繰り返している、複数種のリポジトリへエージェントを展開するチームが購入対象になります。

広い需要があります。ai coding assistantは米国で月間約18,100回、ai powered coding agentは約8,100回検索されています。MVPは、リポジトリに関する質問票、生成済みの設定メモ、範囲を限定したスタータープロンプト、スモークテストのチェックリストで構成できます。初期段階では、IDEとの深い統合は必要ありません。

課題は差別化です。一般的な設定アドバイスは、JetBrains、エージェントベンダー、リポジトリテンプレートに取り込まれる可能性があります。成立するプロダクトには、組織固有のポリシーチェックと、推奨設定によって失敗や過剰な変更が減ったことを示す証拠が必要です。

現時点の制約と率直な評価

Airが最も役立つのは、すでにJetBrains IDEを好んで使っており、IDEネイティブのレビューを手放さずにエージェントを選びたい場合です。自分で検証できない危険な変更を委任する理由にはなりません。

現時点では、3つの制約が重要です。

• アルファ版であること。 ラベルや動作は、おおむね毎週のリリース周期で変わる可能性があります。
• プラグインは無料でも、作業全体が無料ではないこと。 エージェントの認証、サブスクリプション、API利用、IDEライセンス、人によるレビューには、それぞれ費用がかかります。
• 確実な出発点はローカルであること。 IDEページではクラウドへの引き継ぎを近日提供予定としているため、タスクの継続中にノートPCを閉じる運用を最初から前提にしてはいけません。

また、Standard Accessは読み取り専用ではありません。プロジェクト内では、編集とコマンド実行が許可されます。破棄可能なブランチまたはworktreeを使い、差分を確認して、自分でもテストを再実行してください。

結論はシンプルです。JetBrainsが日々の作業環境なら、Airは小さな変更1件で試す価値があります。一方、ロールバック計画、プロバイダーポリシー、レビュー証跡を整えずに、機密性の高いリポジトリで必須の作業経路にするには時期尚早です。

次の月曜日に試すこと

コマンド1つでテストできるバグを1件選びます。破棄可能なブランチに置き、開発者のマシン1台に対応するAir Alphaビルドをインストールし、Standard Accessを選んで、関連ファイル1つを添付してください。そして、必要最小限の修正とリグレッションテストを依頼します。差分が狭い範囲に収まり、自分で実行したテストも成功した場合に限り、変更を採用します。この一連の流れを1度試すだけで、エージェントのデモを1週間見るより多くのことが分かります。

JetBrains Airでは何ができますか？

JetBrains Airは、JetBrains IDEの内外で、コーディングエージェント、そのコンテキスト、セッション、レビューを連携させます。ローカルのIDEプラグインでは、エージェントを選び、プロジェクト情報を添えてタスクを送り、Agent Sessionsで変更結果を確認します。

JetBrains AirとClaude Codeの主な違いは何ですか？

Claude Codeは、1つのコーディングエージェントです。Airは複数エージェントに対応する操作・レビュー画面であり、利用可能な連携と認証に応じて、Claudeと並んでCodex、Junie、GitHub Copilot、Gemini、OpenCode、ACP対応エージェントを実行できます。

エージェント型コーディングに最適なIDEはどれですか？

あらゆる環境に当てはまる唯一の正解はありません。チームがJetBrainsのナビゲーション、インスペクション、差分ツールを日常的に使っているなら、Airは有力です。最適なのは、エージェントの作業範囲を制限し、確認・テストし、確実に元へ戻せる環境です。

JetBrainsは無料で使えますか？

Air Alphaプラグインは無料です。JetBrains IDEと、Airの背後で動くエージェントには、別途ライセンス、サブスクリプション、API利用料がかかる場合があります。

自社のリポジトリとレビュールールに合った安全なエージェント運用を設計したい場合は、AI agent developmentをご覧ください。