開発チーム:AIエージェントがプルリクエストをレビューし、GitHubのissueを振り分け

開発チームにとって、コードレビューとissueの振り分けは、誰もが有用だと考えながら、丁寧に行う時間を誰も確保できない2つの作業です。プルリクエストは手の空いた人が読むまで2日待たされ、最初のコメントは、ざっと目を通せば気づく内容であることが少なくありません。テストの不足、広すぎるブランチ、消し忘れた秘密情報などです。issueは種類も優先度もなく、ときには再現に必要な情報もないまま届き、人が見極めるのを待っています。これらはチームが言葉にできる基準を持つ手順型の作業であり、権限に境界を設ければAIエージェントに向いています。

着想:人より先に最初の一読を

出発点は、Hermes Agentのユーザーが報告している使い方で、開発チームに関するカードにまとめられています。開いているプルリクエストをレビューし、新しいissueを振り分けるというものです。人間のレビュアーに取って代わるのではなく、確認点を一覧の上位に並べた読み込み済みのプルリクエストと、見極め済みのissueを手渡すことが狙いです。

役割は2つに分け、慎重さを原則とします。エージェントはコメントとラベル付けを行い、何も決定しません。Atakoは、GitHubへのアクセスを読み取り、コメント、ラベル付けに意図的に絞った2つのエージェントでこの考え方を実現します。

2つのエージェントの仕事

このシナリオは、どちらもGitHubリポジトリに接続した2つのエージェントをデプロイします。

PRレビュー担当は、開いているプルリクエストを読みます。1件ごとにタイトル、説明、変更されたファイル、コミットを確認し、重要なファイルを開いて、入力された規約と照らし合わせます。対象はテスト、命名、サイズ、コミットメッセージ、慎重に扱うべき領域です。エラーのリスク、不足しているテスト、認証・決済・秘密情報に触れる変更、説明のつかない変更を探します。コメントはプルリクエストにつき1つだけです。変更を要約する1行、良い点、そして重要度順の確認点を並べ、各点はファイルと、可能なら行に紐づけ、ブロッカーか提案かを明記します。最後に、テストの実行など、確認できなかった事項を記します。最後に読んだコミットを記憶しており、新しいコミットが届いたときだけ、短いフォローアップとして再度コメントします。

issue振り分け担当は、新しいissueを担当します。種類のラベル(バグ、機能、質問、ドキュメント)と優先度のラベル(高、中、低)が存在することを確認し、不足分を作成します。ラベルのないissueごとに、本文とコメントを読み、類似のissueを探し、ルールに従って種類と優先度を決め、ラベルを付けてコメントを追加します。コメントには、理解した内容、優先度の理由、重複の可能性、行動に必要な不足情報(再現手順や対象バージョンなど)を書きます。種類や深刻度が不明確なときは、その旨を伝え、最も低い優先度を選んで質問します。

各回の終わりには、早めに人の対応が必要な事項から始まる要約がチャットに届きます。

エージェントが行わないこと

制限は設計の一部です。どちらのエージェントも、マージ、承認、正式な変更依頼、プルリクエストのクローズ、コードのプッシュ、ブランチの作成を行いません。これらのツールは付与されていません。指示の中で約束しているのではなく、できる機能そのものがないのです。振り分け担当は、issueのクローズ、再オープン、ロック、削除を行わず、タイトル、担当者、マイルストーンも変更しません。

エージェントは推測しません。レビュー担当はファイルと行を示し、確認できなかった点を明示し、存在しない関数やテスト結果を作り出しません。コミットされた秘密情報やトークンを見つけた場合は、コピーせずに、その所在らしき場所だけを伝えます。振り分け担当が重複として挙げるのは、検索で実際に見つけたissueだけです。そして判断はすべての段階で人が行います。これが人による確認を組み込んだ設計の原則です。

Atakoでの設定方法

このユースケースのページから、デプロイは4つのステップで完了します。

1. GitHubを接続します。 リポジトリに限定したきめ細かい権限のトークンを作成し、コードの読み取り、issueとプルリクエストの読み取りと書き込みの権限を付けます。接続は、何かが作成される前に確認されます。
2. コンテキストを入力します。 リポジトリを「オーナー/名前」の形式で指定し、あればレビューの規約と、どんなissueを緊急と見なすかを伝えます。入力がない場合、エージェントは一般的なベストプラクティスとバグの深刻度に基づいて動きます。
3. デプロイします。 1回の操作で2つのエージェントとプロジェクト「開発チーム」が作成されます。エージェントはプロビジョニングされ、最初の指示を自分で受け取ります。
4. 最初の結果、その後は定期的に。 レビュー担当が直近5件のプルリクエストにコメントし、振り分け担当がラベルのない直近10件のissueにラベルを付け、それぞれの回をチャットで要約します。その後、レビュー担当は平日の9:00と14:00の実行を、振り分け担当は9:30の実行を自分でスケジュールします。

アカウントをまだお持ちでない場合は、作成するとトライアルが始まり、その直後にシナリオが設定されます。管理者がエージェントの作成を許可していない場合は、デプロイでその旨が通知され、そこで終了します。

結果の確認場所

レビューコメントはGitHubの各プルリクエストで、振り分けのラベルとコメントは各issueで確認できます。各回の要約は、それぞれのエージェントのチャットで読めます。Atakoのプロジェクト「開発チーム」には、仕組みを説明するページと作業の進捗があり、Atakoのフロアでは2つのエージェントが現在の動きとともに表示されます。

挙動を調整するには、エージェントのチャットで伝えます。たとえば「データベースのマイグレーションには必ずロールバック計画を記載するよう、規約に追加してください」と書くと、その指示は記憶に保持され、以降の実行に反映されます。

安全策

アクセスは意図的に狭くしています。GitHubの接続は、プルリクエスト、ファイル、コミットの読み取り、issueの読み取りと更新、ラベルの管理、コメントの追加という12個のツールの限定リストでエージェントに付与されます。ツールの一覧が短いエージェントは、数百のカタログの中で迷うエージェントより確実にツールを使えます。さらに重要なのは、付与されていないことは、文面で強要されても起こり得ないという点です。エージェントはタイトル、説明、コメント、コードを分析対象のデータとして扱い、指示としては扱いません。

作成するトークンが最初の安全策です。1つのリポジトリと明確な権限に限定されているため、何が起きても被害の範囲が抑えられます。トークンは暗号化して保存され、GitHub側での失効や、エージェントのアクセス削除はいつでも可能です。

人による確認は、意思決定の場面に置かれています。レビューコメントを読み、何を修正するかを決め、承認とマージを自分で行い、issueのクローズ、担当者の割り当て、スケジュール調整も行います。

期待できること

有用なコメントが得られるのは、主に妥当な大きさのプルリクエストです。非常に大きな変更では、レビュー担当はすべて読んだふりをせず、その旨を伝えたうえで最も慎重を要するファイルに集中します。テストは実行できず、そのことを毎回のコメントに明記します。振り分け担当の精度は優先度ルールの明確さに比例し、ルールがなければ慎重な判断を選んで質問します。価値は継続性から生まれます。すべてのプルリクエストが半日以内に最初のレビューを受け、すべてのissueが見極められた状態で届き、人のレビュアーは見つけ出す作業ではなく判断に時間を使えるようになります。