0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@akira_papa_AI(あきらパパ)

AIエージェント時代、ボトルネックは実装ではなくレビューになる — Agent Review Queue実践ガイド

0
Posted at

はじめに

AIコーディングエージェントを使っていると、最初は「コードを書いてくれるのすごいな」と感じます。

でも、しばらく使っていると別の問題が出てきます。

AIが実装できるほど、レビュー待ちが増える。

これ、地味なんですがかなり本質的です。

2026年現在、AI開発ツールはかなり「非同期」に寄ってきています。OpenAI の Codex app は複数エージェントを並列に管理する方向へ進み、Codex mobile では外出先から進行中タスクに返答したり、レビューしたり、方向転換したりする流れが示されています。GitHub Copilot coding agent もバックグラウンドで作業してPRを開き、人間にレビューを求めます。Google Jules も安全なCloud VMで作業し、計画や差分を返す非同期エージェントとして説明されています。

つまり、流れとしてはこうです。

人間が1つずつ書く時代から、人間が複数のAI作業を受け取り、選び、止め、通す時代へ。

なんかこれって、エンジニアの仕事がなくなるというより、仕事の詰まりどころが変わっているだけな気がするんですよね。

今までは「実装できる人」が強かった。
これからは、もちろん実装力も大事なんですが、それに加えて AIから返ってきた仕事をどう受け止めるか がかなり大事になります。

この記事では、そのための小さな仕組みとして Agent Review Queue を紹介します。

難しそうに聞こえるかもしれませんが、要するに AIエージェントから返ってきたPRや差分を、どの順番で、どの観点で、人間がレビューするかを決める待ち行列 です。

Agent Review Queueとは

Agent Review Queue は、AIエージェントが作ったPRや差分を、ただ時系列で見るのではなく、危険度・影響範囲・戻しやすさ・証跡 で並べるための仕組みです。

たとえば、朝にAIから5本のPRが返ってきたとします。

  • ドキュメントのtypo修正
  • テスト追加
  • 認証処理のリファクタ
  • DBマイグレーション
  • 課金処理の修正

この5本を、上から順番に見ていいでしょうか。

たぶん、よくないです。

ドキュメント修正はすぐ見られます。テスト追加も比較的安全です。
でも、認証、DB、課金は別です。そこは「AIが通ったと言っているからOK」とは言いにくい。

ここで必要なのは、根性ではなく整理です。

Agent Review Queue では、各PRに次のようなメタデータを持たせます。

項目 意味 例
risk 壊れた時の危険度 low / medium / high
impact 影響範囲 docs / tests / auth / billing / db
reversibility 戻しやすさ easy / moderate / hard
evidence AIが残した証跡 test log / screenshot / migration plan
human_gate 人間承認が必須か true / false
owner 誰が最終判断するか reviewer / tech-lead

ポイントは、AIにレビューを全部任せることではありません。

AIには整理と下準備を任せる。人間は判断をする。

この分担が大事かなと。

人間が設計すること、AIに任せること

AIエージェントが強くなると、つい「全部やって」と言いたくなります。

でも、実務では全部任せるほど逆に怖くなる場面があります。特に以下です。

  • 認証、認可
  • 課金
  • 個人情報
  • DBマイグレーション
  • セキュリティ設定
  • 外部APIへの書き込み
  • 削除処理
  • 本番デプロイ

こういう領域は、AIが作業してもいい。
ただし、AIが最後の承認者になってはいけない。

僕はここを、こんなふうに分けるのが分かりやすいと思っています。

領域 AIに任せる 人間が判断する
調査 関連ファイル探索、仕様候補の整理 どの仕様を正とするか
実装 小さな差分作成、テスト追加 変更方針が妥当か
レビュー準備 変更点要約、危険箇所リスト化 本当に通していいか
テスト コマンド実行、ログ要約 テスト範囲が足りているか
運用 リリースノート案、監視項目案 リリース判断、ロールバック判断

AI時代のエンジニアは、実装者から 設計・評価・文脈設計者 へ寄っていく。
これ、よく言われます。

ただ、言葉だけだとふわっとしますよね。

実務に落とすなら、「AIから戻ってきたPRをレビューキューに入れる」という形がかなり扱いやすいです。

まずYAMLでレビューキューを作る

いきなりツールを作らなくても大丈夫です。

まずはリポジトリに review-queue.yml を置くだけで始められます。

version: 1
items:
  - id: pr-124
    title: "Add password reset tests"
    agent: "coding-agent"
    risk: "low"
    impact:
      - "tests"
    reversibility: "easy"
    human_gate: false
    evidence:
      tests:
        - "npm test -- auth/reset-password.test.ts"
      notes:
        - "No production code changed"
    reviewer: "frontend-reviewer"

  - id: pr-125
    title: "Refactor authorization middleware"
    agent: "coding-agent"
    risk: "high"
    impact:
      - "auth"
      - "api"
    reversibility: "moderate"
    human_gate: true
    evidence:
      tests:
        - "npm test -- auth"
        - "npm run lint"
      notes:
        - "Changes request permission checks"
    reviewer: "tech-lead"

  - id: pr-126
    title: "Add billing webhook retry"
    agent: "coding-agent"
    risk: "high"
    impact:
      - "billing"
      - "database"
    reversibility: "hard"
    human_gate: true
    evidence:
      tests:
        - "npm test -- billing"
      notes:
        - "Includes migration file"
        - "Requires manual staging verification"
    reviewer: "backend-reviewer"

これだけでも、だいぶ違います。

なぜなら、「どれから見るか」が見えるからです。

レビューで疲れる原因の1つは、コード量そのものではなく、どこが危ないのかを毎回ゼロから探すこと なんですよね。

AIに実装させるなら、AIには差分だけではなく、このメタデータも出させる。
それだけで人間のレビューはかなり軽くなります。

TypeScriptで優先順位を計算する

次に、キューの優先順位を雑にコード化します。

ここで大事なのは、スコアを絶対視しないことです。
これは「人間の判断を置き換えるもの」ではなく、人間が見る順番を決めるための補助輪 です。

type Risk = "low" | "medium" | "high";
type Reversibility = "easy" | "moderate" | "hard";

type QueueItem = {
  id: string;
  title: string;
  risk: Risk;
  impact: string[];
  reversibility: Reversibility;
  human_gate: boolean;
  evidence?: {
    tests?: string[];
    notes?: string[];
  };
};

const riskScore: Record<Risk, number> = {
  low: 1,
  medium: 3,
  high: 5,
};

const reversibilityScore: Record<Reversibility, number> = {
  easy: 1,
  moderate: 3,
  hard: 5,
};

const sensitiveImpact = new Set([
  "auth",
  "billing",
  "database",
  "security",
  "permissions",
  "production",
]);

export function reviewPriority(item: QueueItem): number {
  const impactScore = item.impact.reduce((score, area) => {
    return score + (sensitiveImpact.has(area) ? 4 : 1);
  }, 0);

  const evidencePenalty = item.evidence?.tests?.length ? 0 : 3;
  const humanGateBoost = item.human_gate ? 4 : 0;

  return (
    riskScore[item.risk] * 2 +
    reversibilityScore[item.reversibility] +
    impactScore +
    evidencePenalty +
    humanGateBoost
  );
}

export function sortReviewQueue(items: QueueItem[]): QueueItem[] {
  return [...items].sort((a, b) => reviewPriority(b) - reviewPriority(a));
}

この例だと、課金、認証、DB、セキュリティ系は自然に上に来ます。
そして、テスト証跡がないPRも上に来ます。

つまり、危ないかもしれないものから人間の目に入る。

これが大事です。

AIエージェントは速いです。並列に動きます。しかも、見た目としてはそれっぽいPRを返してきます。

だからこそ、人間側には「どれから疑うか」の仕組みが必要です。
疑うというと少し冷たいですが、実務ではこれは優しさです。

未来の自分、チーム、ユーザー、本番環境を守るための優しさ。

GitHub Actionsで入口ゲートを作る

レビューキューは、人間が読むためだけではありません。

CIにも使えます。

たとえば、human_gate: true なのに必要なラベルが付いていないPRは止める。
テスト証跡がない高リスクPRは止める。
こういう入口ゲートを作れます。

name: agent-review-gate

on:
  pull_request:
    types: [opened, synchronize, edited, labeled, unlabeled]

jobs:
  gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Check review metadata
        run: |
          node scripts/check-agent-review.js

中身は最小ならこんな感じです。

import fs from "node:fs";
import yaml from "yaml";

const raw = fs.readFileSync("review-queue.yml", "utf8");
const queue = yaml.parse(raw);

const errors = [];

for (const item of queue.items ?? []) {
  const impacts = new Set(item.impact ?? []);
  const highRiskArea =
    impacts.has("auth") ||
    impacts.has("billing") ||
    impacts.has("database") ||
    impacts.has("security");

  if (highRiskArea && item.human_gate !== true) {
    errors.push(`${item.id}: high-risk impact requires human_gate: true`);
  }

  if (item.risk === "high" && !item.evidence?.tests?.length) {
    errors.push(`${item.id}: high-risk item requires test evidence`);
  }

  if (!item.reviewer) {
    errors.push(`${item.id}: reviewer is required`);
  }
}

if (errors.length > 0) {
  console.error(errors.join("\n"));
  process.exit(1);
}

もちろん、これは簡易版です。

本格運用するなら、PR本文からメタデータを読んだり、GitHub APIでラベルを見たり、CODEOWNERSと連動したりできます。

でも最初はこれで十分です。

最初から完璧なガバナンスを作ろうとすると、だいたい続きません。
まずは「高リスクPRには人間ゲートが必要」だけでも、自動化する価値があります。

プロンプト例1: AIにレビューキュー用メタデータを作らせる

AIエージェントに実装だけ頼むと、レビュー側がつらくなります。

なので、作業依頼の時点で「最後にレビューキュー用メタデータも出して」と伝えます。

あなたは既存リポジトリの小さな修正を担当するAIコーディングエージェントです。

作業後、コード差分だけでなく、レビュー担当者が判断しやすいように以下のメタデータを出してください。

- risk: low / medium / high
- impact: 影響する領域の配列
- reversibility: easy / moderate / hard
- human_gate: 人間承認が必須なら true
- evidence.tests: 実行したテストコマンド
- evidence.notes: レビュー時に注意すべき点

特に auth / billing / database / security / production に触れる場合は、risk を high にし、human_gate を true にしてください。
不明な場合は楽観せず、risk を1段階上げてください。

ここで大事なのは、AIに「不明なら低く見積もるな」と言うことです。

AIは親切なので、いい感じに見せようとすることがあります。
でもレビューでは、いい感じより正直さの方が大事です。

プロンプト例2: 差分の危険箇所を先に洗い出す

以下のPR差分をレビューする前に、危険箇所を洗い出してください。

出力形式:
1. 変更の要約
2. 影響範囲
3. 壊れる可能性があるユーザーフロー
4. 追加で見るべきファイル
5. 実行すべきテスト
6. 人間が必ず判断すべき点

注意:
- 「問題ありません」で終わらせないでください。
- 根拠がない安心表現は禁止です。
- 判断できない点は「不明」と書いてください。

これを使うと、人間はコードを読む前に地図を持てます。

もちろん、AIの地図が間違っていることもあります。
でも、地図がないよりはかなりマシです。

プロンプト例3: レビュー後の人間コメントをAIに整理させる

以下は人間レビューで出たコメントです。
AIエージェントに再作業を依頼するため、実装指示として整理してください。

条件:
- コメントの意図を変えない
- 未決定事項は勝手に決めない
- 破壊的変更やマイグレーションが必要な場合は、事前確認項目として分離する
- 最後に「完了条件」と「実行すべき検証コマンド」を書く

入力:
（レビューコメントを貼る）

レビューコメントは、意外とそのままAIに渡しにくいです。

人間同士だと通じる省略が、AIには通じなかったりします。
なので、AIに渡す前に「実装指示」に変換する。

ここも立派な Context Engineering です。

プロンプト例4: マージ前の最終確認

このPRをマージしてよいか、最終確認の観点を作ってください。

前提:
- あなたはマージを承認しません
- あなたは人間レビュアーの判断材料だけを作ります
- 不明点を推測で埋めないでください

確認してほしいこと:
- 要件を満たしているか
- 既存挙動を壊していないか
- テスト証跡は足りているか
- ロールバック可能か
- リリース後に見るべきログやメトリクスは何か

出力は、マージ判断チェックリストにしてください。

このプロンプトでは、AIに承認者の椅子へ座らせないのがポイントです。

AIは判断材料を作る。
人間が通す。

この線引きがあるだけで、AI活用はだいぶ健全になります。

導入ステップ

Agent Review Queue は、いきなり全社導入しなくていいです。

まずは小さく始めるのがおすすめです。

Step 1: AI PRにメタデータを付ける

最初は risk、impact、human_gate だけで大丈夫です。

risk: "high"
impact: ["billing", "database"]
human_gate: true

これだけでも、危ないPRが見つけやすくなります。

Step 2: 高リスク領域を決める

チームごとに高リスク領域は違います。

ただ、多くのWebサービスではこのあたりは高リスクにしてよいと思います。

  • auth
  • billing
  • database
  • security
  • permissions
  • production
  • external-api-write

Step 3: CIで最低限だけ止める

最初から細かく止めすぎると、運用が嫌になります。

なので最初はこれだけでいいです。

  • high risk なら human_gate 必須
  • high risk なら test evidence 必須
  • reviewer 必須

Step 4: 週1でキューを見直す

1週間運用すると、だいたい見えてきます。

  • risk が低すぎるPRはなかったか
  • human_gate が多すぎて詰まっていないか
  • AIの evidence は信用できる粒度だったか
  • 人間レビューが本当に楽になったか

ここを調整していく。

仕組みは作って終わりではなく、育てるものです。

よくある落とし穴

1. AIの自己申告を信じすぎる

AIが「テストしました」と言っていても、ログがないなら証跡ではありません。

npm test と書いてあるだけでも弱いです。
できれば、どのテストを、どの環境で、どの結果で通したかまで欲しい。

2. スコアを絶対視する

優先度スコアは便利ですが、最後は人間が見ます。

スコアは地図です。現地そのものではありません。

3. 高リスク領域をAIに決めさせる

AIに候補を出させるのはいいです。
でも、最終的な高リスク領域はチームが決めた方がいいです。

なぜなら、何が危ないかはビジネスによって違うからです。

4. キューに秘密情報を入れる

レビューキューには、個人情報、APIキー、顧客名、社内だけの秘密情報を入れない方がいいです。

キューは共有される前提で、抽象化した情報だけにする。
これは地味ですが大事です。

5. AIに承認までさせる

AIにレビュー補助をさせるのは便利です。
でも、マージ承認や本番デプロイ判断までAIに寄せるなら、相応の監査、権限、ロールバック設計が必要です。

少なくとも最初は、人間承認を残す方がいいと思います。

参考リンク

まとめ

AIエージェントが進化すると、コードを書く速度は上がります。

でも、ソフトウェア開発は「コードができたら終わり」ではありません。

レビューして、テストして、影響範囲を見て、危ないものを止めて、通すものを通す。
この部分はむしろ、以前より大事になっていく気がします。

AIに仕事を投げる技術は、もうかなり語られています。

次に必要なのは、AIから返ってきた仕事を受け止める技術 です。

Agent Review Queue は、そのための小さな型です。

最初はYAML1枚でいいです。
risk と impact と human_gate だけでいいです。

それだけでも、AIエージェントの速度を、人間の判断にちゃんと接続できます。

AIを止めるための仕組みではありません。
AIを安心して働かせるための仕組みです。

明日の自分がレビュー画面を開いた時に、「どれから見ればいいか分かる」状態になっている。

それだけで、かなり助かるんですよね。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?