人間によるコードレビューを諦めた話 — Requirements as Code × AIレビューの実践

Last updated at 2026-03-08Posted at 2026-03-08

人間によるコードレビューを諦めた話 — Requirements as Code × AIレビューの実践

コードレビューが破綻した

AIがコードを書く速度に、人間のレビュー速度が追いつかなくなった。

Claude CodeやGitHub Copilotで1時間に数百行が生成される現場で、従来の「人間が全行読んで承認する」コードレビューは機能しない。
レビュアーは積まれたPRをさばけず、形骸化したLGTMが増える。

LGTMは"Looks Good To Me"の略で、「私としては良いと思います」「問題ない」という意味の英語のネットスラングです。GitHubなどのコードレビューで修正不要の承認を伝える際や、チャットで相手の提案に同意する際によく使われます。

これは怠慢ではなく、構造的な問題だ。

AWS で長年What's Newを書き続けてきたJeff Barrが2026年3月7日の『JAWS DAYS』に登壇し、こう発言している。

Communication is More Important than Ever.

コードを書く能力よりも、周りとのコミュニケーション能力が重要になる。
プログラム言語を扱うスキルはAIに渡していく。

そういう時代の宣言だ。

ならば、AIが書いたコードはAIにレビューさせる。人間はその結果を判断する。
この方針に切り替えた。

Requirements as Codeとは何か

AIにコードレビューをさせるとき、「何を基準に判断させるか」が問題になる。

コードの文法や型の整合性は静的解析ツールに任せられる。
しかし「このコードはビジネス要件を正しく実装しているか」を判定するには、AIが要件を読める状態にしておく必要がある。

その基盤が Requirements as Code だ。

要件をYAMLで構造化し、AIが解釈できる形式で管理する。

requirements:
  - id: REQ-001
    category: 概要
    title: hoge1
    priority: Must
    status: Approved
    acceptance_criteria:
      - ほげほげほげほげほげほげ
      - ほげほげほげほげほげほげ
      - ほげほげほげほげほげほげ
      - ほげほげほげほげほげほげ
      - ほげほげほげほげほげほげ

  - id: REQ-002
    category: 概要
    title: hoge2
    priority: Must
    status: Approved
    acceptance_criteria:
      - ほげほげほげほげほげほげ

このYAMLをソースとしてMarkdownの要件定義書を自動生成する。
人間が読む文書と、AIが読む構造化データが同じソースから出てくる。

AIレビューの信頼基準をどう作るか

「AIのレビュー結果を信頼していいのか」という問いには、レイヤーを分けて答える必要がある。

レイヤー1：機械的に検証できるもの（CIで自動ブロック）

YAMLに定義された制約と実装の整合性チェック。

要件に定義された入力/出力の型・制約と実装が一致しているか
セキュリティ要件（認証・認可・暗号化）が実装されているか
禁止されている外部依存を使っていないか

Pass/Failで判定できるのでCIに組み込んで自動ブロックする。人間の判断を介在させない。

レイヤー2：文脈が必要なもの（AIがWarning → 人間が承認）

要件の意図まで踏み込んだ判断が必要なもの。

実装がユーザーストーリーの目的に沿っているか
エッジケースが考慮されているか
設計の一貫性が保たれているか

ここはAIがWarningを出し、人間が最終判断する。重要なのは「AIの指摘を全部潰すこと」ではなく、無視した理由を記録することだ。後から「なぜこの指摘を無視したか」が追跡できる状態を作る。

レイヤー3：AIが判断できないもの（人間必須）

ビジネス的な優先度判断（技術的に正しくても要らない機能）
組織・顧客固有の文脈（このお客様はこういう理由でこの実装を嫌がる）
要件定義自体が間違っているケースの発見

AIはコードと要件の乖離を検出できるが、要件自体の妥当性は判断できない。
ここは人間が担う領域として明示的に残す。

要件IDとコードを紐付ける

レビュー精度を上げる最も即効性のある施策は、PRの説明とコードコメントに要件IDを入れる運用の徹底だ。

// req: REQ-001 REQ-002
public void RegisterHogeHoge(string hoge_id, string hoge_number)
{
    ...
}

## このPRの変更内容

対応要件: REQ-001, REQ-002

- ほげほげほげほげほげほげ
- ほげほげほげほげほげほげ

AIレビュー時のプロンプトはシンプルになる。

以下の要件定義YAMLと、対応するコードの差分を比較してください。
対応要件: REQ-001

[要件定義YAML]
...

[コードの差分]
...

acceptance_criteriaの各条件が実装されているか確認し、
未実装・不整合・懸念点を指摘してください。

受け入れ条件をより機械判定しやすくする（将来の改善）

現状のacceptance_criteriaは自然言語のままだ。AIは読めるが、解釈が揺れる可能性がある。

将来的には以下の構造を検討している。

acceptance_criteria:
  - id: AC-001-1
    description: ほげほげほげほげほげほげ
    test_type: unit
    expected_values: [済, 未]
  - id: AC-001-2
    description: ほげほげほげほげほげほげ
    test_type: e2e
    expected_http_status: 403

test_typeとexpected_valuesが入ると、AIが「これはユニットテストで検証すべき条件」「E2Eで確認すべき条件」と分類でき、テストコードの自動生成にも繋がる。

ただし今の形式でも十分AIレビューに使える。構造の完璧化より、要件IDの参照運用を先に徹底させる方がROIは高い。

人間が担う仕事が変わる

AIレビューを導入した結果、チームの仕事の重心が変わった。

コードを一行一行追うレビューは減った。代わりに増えたのは

AIの指摘が妥当かを判断するメタレビュー
要件定義の質を上げる議論
AIが検出できないビジネス文脈の判断

Jeff Barrが言った「コミュニケーションが今まで以上に重要」は、この変化を指している。
コードを書く能力の差分は縮まる。
要件を正しく定義し、チームで合意し、AIに正確に伝える能力の差分が広がる。

Requirements as Code は、AIと人間の役割分担を明確にするための設計だ。

まとめ

AI生成コードを人間が全部レビューするのは構造的に無理
AIにコードレビューさせるには「何を基準に判断させるか」の設計が必要
要件定義をYAMLで構造化し、AIが読める状態にする
レビューの信頼基準は3レイヤーで設計する（自動ブロック / Warning+人間承認 / 人間必須）
今すぐできる最初の一手は要件IDをコードとPRに紐付ける運用の徹底
人間の仕事はコードを読むことから、要件の質を上げることに移行する

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up