Air logo

Air

An agentic development environment

Agentic AI AI JetBrains JetBrains AI New Products News Releases

Air Teams: 最高峰のエージェント型ワークフローをチーム全体で活用して繰り返し作業を自動化

Read this post in other languages:

本日はエージェント型開発のためのチームレイヤーとなる JetBrains Air Teams をご紹介します。このプラットフォームは、人間とエージェントが開発ライフサイクル全体を通じて効果的に連携するために必要な共有コンテキスト、環境、ツール、指示を提供します。

Air Teams はすでに JetBrains の法人顧客向けに提供されており、今後は個人のお客様にも提供範囲が拡大される予定です。

今すぐ Air Teams を試す

新たな章の幕開け: 個人開発者からチームへ

JetBrains は数か月前にエージェント型開発への第一歩となる Air アプリをご紹介しました。それ以来、当社は多くを学び、エージェントと連携する開発者の生産性が実際に向上する様子を目にしてきました。

Air の開発を進める中で、2 つのことが次第に明らかになってきました。そのうちの 1 つは、開発者には別のスタンドアロンアプリは必要なく、ツールやエージェントは既存の作業環境に統合されるべきだということです。もう 1 つは、エージェントによって個人開発者の生産性が高まるにつれ、実質的なボトルネックがチームレベルに移り始めたということです。

そのため、Air をスタンドアロンデスクトップアプリの枠を超え、より広範なシステムへと拡張しているところです。Air は現在、個人開発者、チーム、組織という 3 つのレベルでエージェント型開発をサポートしています。Air Teams がエンジニアリングチームに提供するものを詳しく見ていきましょう。

Air Teams とは?

Air Teams はエンジニアリングチームがコーディングエージェントを実行し、うまくいく方法を共有するためのクラウドプラットフォームです。現在、エージェントによる作業のほとんどは個人のノートパソコン上で行われています。各開発者が独自の構成とプロンプトを使用しており、ある人にはうまくいく方法がチームの他のメンバーには簡単には広がりません。Air Teams は、エージェント型ワークフローを 1 か所にまとめます。ある開発者が見つけ出した方法を、誰もが使えるようになります。

Air Teams は以下の 4 つの要素から構成されています。

自動化: コードレビュー、課題の修正、依存関係の更新といった繰り返し発生する作業を自動的に処理します。各々の処理の実行は、イベントまたはスケジュールをトリガーとして開始されます。

共有クラウド環境: コードのビルドとテストに必要なツール、依存関係、資格情報をエージェントに提供します。チームが一度セットアップすれば、全員がその環境を再利用できます。

クラウドタスク: 人のノートパソコンを占有することなく、共有クラウド環境内で並列実行されます。IDE やブラウザーから開始し、進捗確認を行うことができます(間もなくスマートフォンからも可能になります)。

プロジェクト: 共有クレジット、明確なロール、そして特定の個人に依存しない自動化により、上記のすべてを 1 箇所に集約します。

それぞれの要素を詳しく見ていきましょう。

自動化: エージェントの子守りはもう不要

エージェントは高速に作業できますが、タスクの開始、指示の提供、次のステップへの移行は依然として人間を待つ必要があります。いつかは個々の実行を手動調整することがボトルネックになります。

Air Automations は人ではなく、イベントやスケジュールによってトリガーされ、クラウド上で自律的に実行されるエージェント型ワークフローです。このワークフローはチームの共有資産です。ある開発者が自動化を構築すれば、チーム全体がそれを実行、再利用、改善できます。ある人にうまくいった方法をチーム全体の業務に組み込むことができます。たとえば、自動化は新しいプルリクエストが作成された瞬間にレビューしたり、依存関係を週に 2 回更新したりできます。

Air Teams には、コードレビュー、バグ修正、依存関係のアップグレード、ドキュメントメンテナンスなど、10 個の自動化テンプレートが付属しています。そのまま使用することも、チームの作業方法に合わせて調整することもできます。

自動化の仕組み

自動化は、プルリクエストのレビュー、ラベル付けされた課題の調査、毎週の依存関係のチェックなどが必要なパターン化された繰り返し作業に適しています。

以下の 4 項目を一度設定すれば、自動化を実行するたびに再利用されます。

指示: エージェントが実行すべき内容。

環境: エージェントが実行される場所。

ツール: Jira、Figma、Linear など、エージェントが コネクタを通じて使用できるもの。

トリガー: GitHub や Jira のイベント、Webhook、スケジュールなど、エージェントが起動するタイミング。今後、さらに多くのトリガーの種類が追加される予定です。

一例として、ラベルをトリガーとする自動化を紹介します。誰かがバグのラベルを追加すると、自動化によってエージェントが起動されます。エージェントは課題とリンク先の Jira チケットを読み取り、コード内の原因を特定し、エンジニアがレビューできる修正案を含むプルリクエストを作成します。

自動化はチームプロジェクトに属します。そのため、各メンバーが個別に自動化を構築するのではなく、チーム全体が同じ自動化を使用します。自動化の効果が実証されれば、そのプロジェクトの枠を超えて活用できます。チームは別のリポジトリでそれを再利用したり、組織内の誰もがそのまま使用または調整できるテンプレートとして保存したりできます。

自動化は、指示、エージェント、トリガーで構成されます。一度設定すれば、実行のたびに再利用されます。

自動化の例

以下は私たち自身のチームで実行している 3 つの自動化です。

コードレビュー。プルリクエストが作成されると、エージェントが関連するコードと議論を読み取り、インラインコメントと要約を投稿します。プルリクエストを承認したり、変更を要求したりすることもできます。新しいコミットのたびに再度実行されます。この場合、エージェントは以前のレビューとその返信を読み取り、修正済みの問題と残っている問題を確認し、古いレビューを折りたたんで最新のものだけが表示されるようにします。AI エージェントはワークフローを妨げるのではなく、支援すべきです。ユーザーが別のプルリクエストで問題に対応することにした場合、エージェントはその判断を尊重し、自身のチェックを完了させます。

課題の修正。チームメンバーが YouTrack で小規模かつ対象範囲が明確な課題にタグを付けると、エージェントがコンテキストを収集し、修正を試み、レビュー用のプルリクエストを作成します。同じ自動化により、レビューのフィードバック対応も行われます。自動化によって作成されたプルリクエストに対してチームメンバーかコードレビューの自動化からレビューコメントが付くと、エージェントがそのコメントを拾って修正を行います。

依存関係の更新。エージェントはプロジェクトの依存関係を週に 2 回アップグレードします。なお、指示でそのままにするように指定されているものはスキップされます。プロジェクトをビルドし、テストを実行します。アップグレードによって不具合が発生した場合、エージェントは動作を変えずに影響を受けたコードを修正するか、それが不可能な場合はアップグレードを取り消します。その後、適用・スキップ・取り消しされたアップグレードを含むプルリクエストを作成します。前回のプルリクエストがまだマージされていない場合、エージェントはそれをクローズすることで、チームが常に最新の状態のプルリクエストを 1 つだけ持ち、準備ができ次第マージできるようにします。

今後の投稿では、設定方法や使い方も含め、さらに多くの自動化を紹介していく予定です。

主導権を維持

AI エージェントに関して、誰も読まないコメントや誰も求めていないプルリクエストのようなノイズに懸念を持つのは妥当なことです。自動化では、チームの手に意思決定が委ねられます。エンジニアはエージェントが取り組む対象を選択でき、その指示により、上記の例のように出力を小さく保つことができます。つまり、依存関係を更新するための未処理のプルリクエストは 1 つ、プルリクエストごとの最新のレビューも 1 つにできます。各実行ではエージェントのすべての対話とツールの呼び出しも保持されます。そのため、チームは結果が誤っていると感じた場合でも理由を確認できます。コードの変更はすべてプルリクエストとして提出され、マージするかどうかはエンジニアが判断します。

最初の自動化を作成

共有クラウド環境: チームとエージェントが再利用できる構成

個々の自動化は個々のクラウドタスクと同様に 1 つの環境内で実行され、エージェントはその環境が許す範囲の作業しか行えません。エージェントがビルドやテストを行うには、新しく入社したエンジニアが初日に必要とするものと同じもの、つまり適切なツール、依存関係、認証情報、ネットワークアクセスが必要です。小規模なプロジェクトであればデフォルトの構成で運用できることもありますが、ほとんどのコードベースでは、非公開パッケージレジストリ、固定されたツールチェーンのバージョン、エージェントがアクセスする必要のある社内課題トラッカーなど、それ以上のものが必要です。誰かがそれを構成する必要があり、一度で十分なはずです。

環境を手動でセットアップすることも、エージェントに最初の作業を任せてユーザーがレビューできるテスト済みの起動スクリプトをコミットさせることもできます。どちらの方法でも、一度セットアップすればチーム全体がそれを再利用できます。

Air Teams では、その構成が共有可能なクラウド環境に保存されます。ユーザーはチームのプロジェクト内のリポジトリごとに構成を作成します。VM のサイズを選び、マシンがアクセスできるドメインを決定し、ビルドに必要な変数とシークレットを追加します。構成自体はリポジトリ内の .air/cloud/startup.sh に置かれ、チームが他のコードと同様にバージョンを管理し、レビューできるようになっています。

最初の構成をエージェントに任せることもできます。エージェントはリポジトリを検査し、実際のインストールとビルドを実行し、不足しているシークレットがあれば確認を求め、テスト済みの起動スクリプトを別のブランチにコミットします。あとは他の変更と同じようにレビューするだけです。

環境の準備が整うと、Air によってその環境がスナップショットとして保存され、チームと共有できるようになります。構成を共有することは、資格情報を共有するということではありません。共有シークレットはチームメンバーや自動化処理が値を確認することなく使用できるようにするものであり、個人のシークレットやリポジトリへのアクセス権は各個人の手元に残ります。

その後、チームメンバーがクラウドタスク用の環境を選択し、プロジェクトの自動化がその環境上で実行されます。リポジトリのビルド方法を調べ直すのに時間とトークンを費やすエージェントがいなくなります。すべてのタスクで最初から実作業に取りかかれます。

環境の構成方法を確認してください

クラウドタスク: IDE や任意のデバイスからの作業

環境の構成が完了したら、エージェントに作業を割り当てられるようになります。環境とエージェントを選択し、タスクの内容を記述します。リポジトリにカスタム構成が不要な場合は、デフォルトの環境を使用します。

タスクはローカルまたはクラウド内で実行できます。どちらを選択するのが最適なのかは、タスクの内容、必要な構成、そしてエージェントとどれだけ緊密に連携したいかによって決まります。

  ローカルエージェント クラウドエージェント
使用開始 既存のワークスペースはすぐに使用できます。新しいワークツリーやコンテナーは、事前の構成が必要な場合があります。 環境を起動し、リポジトリをコピーする必要があります。事前に構成を行い、キャッシュされた状態の共有可能な環境として保存しておくことで、待ち時間を短縮できます。
マシンリソース ビルドとテストでマシンの CPU とメモリが他の作業と共有されます。 ビルドとテストがクラウドマシン上で実行されるため、ローカルのリソースを節約できます。
ファイルとツール エージェントはコミットされていない変更も含め、ローカルのツールと作業コピーを使用します。 エージェントはリモートブランチ上で動作し、その環境用に構成されたツール、依存関係、資格情報を使用します。
エージェントとアカウント 自分がインストールした任意のサポート対象または ACP 互換のエージェントを、そのエージェントがサポートするアカウントで使用できます。 組織が有効にしたサポート対象のクラウドエージェントを使用できます。
構成の再利用 チームメンバーは構成スクリプトを共有できますが、各自が自分のマシンを準備する必要があります。 チームメンバーは 1 つの環境を共有し、各タスクはその環境のコピー内で実行されます。
進捗確認 マシンを起動したままにしておく必要があります。リモートアクセスの利用可否は、自分が所有するツールに依存します。 マシンの電源を切ってもタスクが実行され続けます。JetBrains IDE やウェブ上の Air を通じて進捗を確認できます(間もなくスマートフォンでも可能になります)。

主な違いは、クラウドタスクがそれを開始したデバイスに縛られていない点です。IDE でタスクを開始し、後からウェブ上でそのタスクを再開できます。エージェントはユーザーがノートパソコンを閉じた後も動作し続けます。

クラウドタスクのワークフローを見る

チームプロジェクト: チームに属する作業

チームプロジェクトは、チームのエージェント型作業のための共有拠点です。チームメンバー、共有環境、MCP コネクタ、自動化を 1 箇所に集約します。

誰が何をできるかは、2 つのロールによって決まります。プロジェクト管理者は、メンバーシップ、環境、コネクタ、自動化を管理します。また、特定のメンバーに環境の編集を許可することもできます。メンバーは共有環境を使用し、独自の自動化を作成して、すべての実行結果を確認できます。

自動化は、作成者に依存する必要はありません。各プロジェクトには専用のサービスアカウントと AI クレジットがあり、プロジェクトの自動化がそのクレジットを使用するか、作成者自身のクレジットを使用するかは、プロジェクト管理者が決定します。プロジェクトのクレジットを使用する場合、自動化はプロジェクトのアカウントで実行され、作成者が離れた後も動作し続けます。

プロジェクトの役割とクレジットの詳細をご覧ください

Air Teams をお試しください

Air Teams を使用すると、エージェント型の作業がチーム全体で共有するものに変わります。自動化によって繰り返し発生する作業が処理され、共有環境によってすべてのタスクに同じ構成が提供され、ノートパソコンを閉じた後もクラウドタスクの実行が継続されるようになります。また、チームプロジェクトを使用することで、これらが特定の個人に依存するのを防げるようになります。

air.jetbrains.cloud で Air Teams をお試しください。上記の機能はすべて共有することを前提にした作りになっていますので、最初からチームメンバーを招待できます。

Air 製品ファミリーの全体像については、jetbrains.com/air をご覧ください。

快適を提供する Air

オリジナル(英語)ブログ投稿記事の作者:

Vladimir Gromozdin

Vladimir Gromozdin