PR レビューをエージェントに任せる、JetBrains Air の Automations

はじめに

溜まった PR を1本ずつ開いてレビューするだけで午前中が終わってしまう、チームでコードレビューを回している人なら、こんな経験はないでしょうか。

JetBrains Air には、この最初の一読をエージェントに任せる Automations という機能があります。
PR が開かれた、CI が落ちた、毎朝9時になった、といったきっかけでエージェントが自動で動きます。
この記事では Automations の仕組みと、どんな作業を任せられるかを紹介します。

Automations は EAP（Early Access Program）の機能です。この記事の内容は 2026年9月24日時点の情報で、画面や仕様は今後変わる可能性があります。

JetBrains Air の Automations

Automations は、トリガーが発火したときに Air が自動で実行する cloud task です。
エージェントは JetBrains 側のクラウド環境で動くので、手元の PC を閉じていても処理が進みます。

• 製品: JetBrains Air（web 版 air.jetbrains.cloud）
• 機能: Automations
• 提供状況: EAP（2026年9月24日時点）

Automations の仕組み

automation は「何をさせるか」と「いつさせるか」の組み合わせで作ります。

項目	内容
Instructions	エージェントへの指示文。template から始めることもできる
Model	使うエージェントとモデル
Repository / Environment	対象のリポジトリと実行環境。環境を選ばなければ既定の cloud 環境
Triggers	起動のきっかけ、対象ブランチ、変更の扱い
Connectors	エージェントが使える外部ツール（Jira、Sentry、Figma など）。GitHub は常に有効
Notifications	実行の完了や状態の変化を知らせる

中心になるのは Triggers です。トリガーは「開始条件 → ブランチ → 変更の扱い」の3つで構成されます。

開始条件の種類

開始条件は大きく4系統あります。GitHub のイベントは Air の GitHub App が受け取るので、webhook を自分で設定する必要はありません。

系統	選べる条件
時刻	At time（決まった曜日と時刻）/ Repeat every（一定間隔）
GitHub	Pull request（Opened / Moved out of draft / Labeled / New changes / Review requested / Review received / Merged）/ Issue（opened / labeled）/ Workflow（failed / job failed）
Jira	Issue created / labeled / assigned / status changed / priority changed / resolved / commented
Webhook	外部システムから HTTP POST を受けて起動。JSON の payload はタスクの文脈として渡る

変更の扱い（change handling）

エージェントにどこまで手を動かさせるかを、トリガーごとに4段階から選びます。

change handling	動き
No code changes	commit も push もしない。結果は run の出力と通知で返す
Push to source branch	チェックアウトしたブランチ（PR なら PR のブランチ）に commit して push
Push to new branch	新しいブランチに push する。PR は作らない
Create a PR	新しいブランチに push して PR まで作る

同じ「CI の失敗」でも、原因の報告だけで止めるか、修正 PR まで作らせるかをここで決めます。任せる範囲を段階的に広げられるのが、この設計のよいところです。

想定する使い方

Air にはテンプレートが10件用意されています。テンプレートを選ぶと指示文が入った状態で作成画面が開くので、あとはトリガーと変更の扱いを決めます。
場面ごとの使用例を表にまとめました。

場面	テンプレート	開始条件	change handling
PR の一次レビュー	Code Review	PR opened / New changes	No code changes
テストが足りない PR の補強	Cover PR with Tests	PR opened	Push to source branch
CI が落ちたときの初動調査	Fix Failed CI	Workflow failed	Create a PR
朝会の準備	Standup Update	At time（平日の朝）	No code changes
リリースノートの作成	Generate Release Notes	PR merged / At time	Create a PR
依存関係の定期更新	Dependency Upgrade	Repeat every（週1）	Create a PR
issue の振り分け	Issue Triage	Issue opened	No code changes
監視アラートからの調査	Fix Bug	Webhook	Push to new branch
ドキュメントの追従	Documentation Maintenance	PR opened	No code changes
merge conflict の解消	Resolve Merge Conflicts	PR labeled	Push to source branch

PR の一次レビュー

Code Review のテンプレートは、PR の説明と関連 issue、変更されたファイルと周辺のコードを読んでから判断するよう指示されています。指摘するのは「merge 前に直すべき」「失敗するシナリオを示せる」「修正案を示せる」の3条件を満たすものだけで、指摘は inline comment として PR に付きます。

CI が落ちたときの初動調査

GitHub Actions の workflow が失敗したら、Fix Failed CI がログを読み、原因を特定して修正 PR を作ります。workflow 名や job 名で絞り込めるので、「main の test job が落ちたときだけ」のような指定もできます。

夜間や休日に落ちた build でも、朝には原因と修正案がそろった状態になります。

朝会の準備

Standup Update を平日の朝に動かすと、前回からの commit、open な PR、放置されている review を集めて、「Done / In progress / Needs attention」の3つに分けて返します。数日レビューされていない PR のように、ラベルが付いていなくても止まっている作業を拾うよう指示されています。

外部システムからの起動

Webhook trigger を使うと、監視ツールのアラートや社内のツールから automation を起動できます。

テンプレート設定方法

1. Settings | VCS Providers で GitHub を接続し、対象のリポジトリへのアクセスを許可する
2. Automations タブで template を選ぶ
3. Select repository でリポジトリを選び、Add Trigger で開始条件と change handling を決める
4. Create で保存し、詳細画面の Run Now で一度手動で動かす

Run Now では、ブランチと change handling を指定し、trigger の payload の代わりになる文脈を渡せます。本番の trigger を待たずに、指示文の出来を確かめられます。

実際に動かしてみた

spring-petclinic で、Code Review と Standup Update の2本を作って動かしてみました。
モデルは Codex / GPT 6 Astra です。

Code Review は、PR を開くと自動で起動しました。
Air 側の結果を見ると、コードを読むだけでなく、変更に関係する OwnerControllerTests の21件を自分で実行して、すべて通ることを確かめていました。指示文にテストを実行しろとは書いていないので、エージェントが自分で判断した検証です。
run の Artifacts に残っていたテストログ（owner-controller-tests.log）も開いてみましたが報告どおりでした。

テストが動いたのはAir の cloud 環境（JetBrains 側のコンテナ）です。PR の Checks は0件のままで、ログには作業ディレクトリ /workspaces/spring-petclinic と、環境の proxy の設定が出ていました。

Standup Update は Run Now で動かし、PR のないまま残っていたブランチを「Needs attention」に挙げていて、放置された作業を拾うという指示どおりの結果でした。

まとめ

PR を1本ずつ読む前に、エージェントの一次レビューが済んでいたらどうでしょうか。
チェックリストで確認していた観点は指示文に書け、linter では拾えない判断もエージェントが先に見てくれます。

まずは Code Review の template を選び、change handling を No code changes にして、自分のリポジトリで PR を1本開いてみてください。

ナットウシステムからのお知らせ

弊社は JetBrains 製品に関するご質問、ご相談等を受け付けております。弊社のXまたはメールでご連絡ください。

参考