AIがコードを書き、レビューする時代

Anthropicは最近、AIアシスタントのClaudeが同社のプロダクションコードベースにマージされるコードの80%以上を書いていると発表した。2025年2月にClaude Codeがローンチされた当初は一桁台だったが、その後急速に増加した。さらに、コードレビューの多くもAIエージェントによって行われ、人間が出力を一行ずつ読む機会は大幅に減っている。

しかし、ほとんどのSOC 2やISO 27001認定プログラムには、今でも「変更はデプロイ前に第二の有資格者によってレビューされ承認される」という条項が含まれている。この管理文言は実際の業務を反映しなくなっている。

従来のピアレビューはPR承認によって変更管理の証拠を提供してきた。1人のエンジニアがPRを開き、別のエンジニアがコメントするか承認をクリックし、プラットフォームは2つの名前が付いたきちんとした記録を残す。監査人はタイムスタンプ、承認者、明確な変更前後の比較があるため、これを好む。しかし今では、その記録はレビューではなく儀式を記録していることが多い。エージェントがコードを書き、エージェントの集団がレビューした場合、人間の「承認」は欠けているか形だけのものになる。この管理策は監査を通るかもしれないが、もはや皆が合意した意味を持たない。

これは、芝居か発見かのどちらかにつながる。エンジニアは読んでいないdiffを機械的に承認して証拠を出し続けるか、監査人が「第二レビューア」が何ヶ月も実際には何もレビューしていないことを途中で発見する。芝居はプログラムを内部から腐食させる。発見は通常、慌てたぎこちない是正につながる。どちらが起こる前に管理策を再設計する方が良い。

旧来の管理策を置き換えるには、その実際の機能を正直に評価する必要がある。ピアレビューは5つのタスクを1つのGitHubクリックに束ねていた。すなわち、欠陥検出（本番に到達する前にバグを捕捉）、意図検証（変更が正しい問題を解決していることを確認）、独立性（作者のバイアスがない第二者が作業をレビュー）、知識移転（変更を理解した第二の人間）、説明責任（承認に名前を付ける）。欠陥検出は通常最初に挙げられる正当化理由だが、常に最も弱い要素だった。人間は大きなdiffを流し読みする。2000行のPRを承認したことがある人なら、すべてのブランチを追跡していないことを知っている。レビューの効果はdiffが数百行に達すると急激に低下する。監査人がPR承認を受け入れたのは、それがバグを確実に捕捉したからではなく、他の4つの機能、特に独立性と説明責任の証拠を提供したからだ。

問題は、これら5つの機能が今どこにあるかだ。それらは依然として重要だが、diffはもはやそれらを探す場所ではない。エージェントはコードとテストを書き、他のエージェントがPRをレビューする。専用ツールが論理エラー、セキュリティ脆弱性、リグレッションをスキャンする。それらは重要度で結果を分類し、必要なゲートを通過した変更を自動的にマージする。自動化された正確性チェックはより安価で優れたものになり、一方で人間の注意力は固定されたままである。シニアエンジニアに2000行のエージェント作成のdiffを読ませることは、わずかな保証を追加するだけで、貴重なシニアの判断力を消費する。機械の出力を一行ずつレビューすることは、非常に少ないバグを見つけるための高価な方法だ。

レビューは消えたわけではない。作業成果物の検証は自動化され、人間の注意はdiffの上の意思決定に移った。人々は「エージェントがコードを正しく書いたか」と尋ねる代わりに、「正しいルールの下で正しいものを構築しているか」により多くの時間を費やしている。Anthropicも同様の変化を説明している。

独立性に関する明らかな異論は、同じモデルがコードを書き、レビューすることは、一つの心が自分の仕事をチェックすることに等しいというものだ。そのリスクは現実的だが、モデルは決定論的ではない。異なる指示に対して同じ種類の答えを生成するわけではない。「この機能を出荷せよ」と「ロールバックされる欠陥を見つけよ」では異なる作業が生まれる。重要なのは、書き手とレビューアの失敗がどの程度相関しているかだ。この相関を減らす方法は3つある：役割に異なる目標を与える（書き手は変更を機能させようとし、レビューアはそれを壊そうとする）、レビューアにクリーンなコンテキストから始めさせる（書き手の合理化やバグを生んだ半完成のメンタルモデルを継承しない）、作者に依存しないツール（プロパティテスト、コントラクトテスト、ファザー、静的解析、実行）を書き手エージェントの制御外に置く。

敵対的プロンプティングだけでは独立性の問題を解決できない。書き手とレビューアはモデルのトレーニングに埋め込まれた誤解を共有する可能性がある。プロンプトではモデルの知識のギャップを埋められない。だからこそ、ツールチェーンがレビューパスを追加するよりも重要だ。プロパティテスト、ファザー、静的解析、実行はモデルではないので、モデルのブラインドスポットを共有しない。両方のエージェント役割が信じる誤りでも、どちらも作成していないチェックを生き残らなければならない。もちろん、ツールチェーンはすべてを捕捉できるわけではない。新しいロジックや判断は、依然として敵対的役割とクリーンなコンテキストに依存する。

著者は、AIネイティブ変更管理（ANCM）フレームワークを提案する。これは人間のレビューをdiffから3つの重要な成果物に移す。すなわち、作業とその制約を記述するスペック、変更がクリアしなければならないゲートを定義する検証計画、自動マージの条件を設定する自動化ポリシーである。このモデルでは、人間は具体的なコードdiffではなく、意図と実装を統制する検証体制を承認する。これは必ずしも損失ではない。人々は大きなdiffを流し読みするよりも、スペックとポリシーをより注意深くレビューできる。バージョン履歴付きの承認されたスペックと、それを実施したレビュー実行の記録は、PRの発掘よりも完全な証拠の道筋を残す。

記事は、ピアレビューの各機能について、旧管理策、新管理策、監査人が受け取る証拠を表形式で示している。例えば、欠陥検出の旧管理策はdiffへのレビューアのサインオフ、新管理策は定義された重要度ゲートに対して実行されるエージェントレビューフリート（作者に依存しないテストとファザーを伴う）、証拠はレビュー実行ログ、発見結果、ゲート結果である。意図検証の旧管理策はPRが意図に一致するとの想定、新管理策は実装前に責任者がレビュー・承認したスペック、証拠はバージョン履歴付きの承認済みスペックである。

著者はこの新しい管理策セットをAIネイティブ変更管理（ANCM）と呼ぶ。これは監査人により低い保証を求めるものではなく、新しい証拠を彼らがすでに使用している基準にマッピングする。ANCMの各管理策が生成する証拠を監査人に説明し、各成果物がどの基準を満たすかを示すことは、形式的なクリックがまだレビューとしてカウントされると皆に偽るよう求めるよりも強力な立場である。