AI コーディングツールに機能をまるごと任せ、プルリクエスト（PR）まで作らせる働き方が珍しくなくなりました。
書く手間が減った一方で、そのコードの品質を誰がどう保証するのかという問いは、むしろ重くなっています。
チームの技術判断に責任を持つテックリードにとって、避けて通れない論点です。
AI が書いたコードを、どこまで自分の目で読めば安心できるのか迷ったことはありませんか？
私もテックリードを目指して学んでいる途中なので、DORA の調査と GitHub・Anthropic の公式ドキュメントを手がかりに、変わることと変わらないことを分けて考えてみました。
書く速さより「確かめる量」がボトルネックになる
AI で速くなるのは、主に「書く」工程です。
5,000 人近くの技術者に聞いた調査をまとめた 2025 年 DORA レポートの発表記事では、90% が仕事で AI を使い、80% 超が生産性が上がったと感じていると報告されています。
その一方で、30% は AI が生成したコードをほとんど、あるいはまったく信頼していないと答えている点も見逃せません。
変更を本番へ届ける流れ（デリバリー）への影響も、前年とは様子が変わりました。
AI の導入は届ける速さ（スループット）とは正の関係に転じたものの、安定性とは引き続き負の関係にあるという結果です。
DORA はこれを、自動テストや成熟したバージョン管理、速いフィードバックといった仕組みが弱いまま変更量だけが増えると不安定さにつながる、と説明しています。
AI はチームを直すのではなく、今あるものを増幅する——レポートの中心にあるこの一文が、テックリードにとっての出発点でしょう。
品質保証の論点は「一件ずつ丁寧に読めるか」から、増えた変更量を受け止める仕組みがあるかへ移ってきているのです。
「できたように見える」で止めない仕組みを置く
仕組みの具体像を考える手がかりになるのが、Claude Code の公式ベストプラクティスにある検証の考え方です。
そこには、Claude は作業が「できたように見えた」時点で止まるため、実行できるチェックが無ければ人間自身が検証ループになり、すべての間違いが人に気づかれるのを待つことになる、とあります。
対策として挙げられているのは、テストやビルド、リンターのように合否を返すチェックを AI に渡すことでした。
さらに、成功を宣言させずにテスト結果などの証拠を示させることや、作業した AI とは別の目に採点させることも勧められています。
テックリードの仕事に置き換えると、「完了」の定義を、機械が判定できる形で先に決めておくことにあたります。
PR にテストの実行結果を添えるのをチームの約束にすれば、レビュアーは再実行せずに証拠を読むところから始められます。
一方で、AI のレビュアーは指摘を探すよう頼まれると、問題がなくても何かしら報告しがちだという注意書きもありました。
全部を追いかけると過剰な作り込みにつながるため、AI レビューに何を指摘させるかの基準も人が決める必要があります。
承認の責任は人に残し、その線を明文化する
仕組みを整えても、最後にマージを通す判断は誰かが引き受けなければなりません。
GitHub の Copilot の出力をレビューするためのドキュメントは、Copilot が作った PR にも、ほかの貢献と同じだけ丁寧なレビューが必要だと明記しています。
さらに承認必須のリポジトリでは、Copilot に作業を頼んだ本人の承認は必要数に数えられず、別のレビュアーの承認が要る仕組みです。
AI に指示した人は「書いた側」に含まれ、独立したもう一人の目が必須になるという設計だと読めます。
ただし、線の引き方は固定ではありません。
2026 年 9 月 1 日の GitHub の更新情報で、Copilot のコードレビューが承認を出し、それを必要承認数に数えられる機能がパブリックプレビューとして加わりました。
既定では無効で、管理者が企業・組織・リポジトリの単位で有効にでき、リポジトリ単位では承認してよいファイルパスまで選べるようになっています。
つまり、「AI の承認を何に数えるか」が、チームで決める設定項目になったということです。
たとえば、ドキュメントやテストの変更は AI の承認で通し、認証や課金、データベースの移行は人の承認を必須にする、といった線引きを先に書いておくのがテックリードの役目です。
テックリードが先に決めておく3つのこと
仕組みと承認の線は、チームの土台があってこそ機能します。
DORA AI Capabilities Model は、AI の効果を増幅する組織の能力を 7 つに整理したものです。
これに Claude Code のガイドを重ねると、先に手を打てることは 3 つに絞れます。
AIの使い方の方針を言葉にする
1 つ目は、何を期待するか、試してよい範囲、使ってよいツールを明確にして伝えることです。
DORA は、方針が明確だと AI の良い影響が増幅され、現場の摩擦も減るとしています。
変更を小さく、戻せる形に保つ
2 つ目は、小さなバッチで進めることと、バージョン管理を丁寧に扱うことです。
DORA によれば、こまめなコミットは個人の効果を、ロールバックの頻繁な活用は AI を使うチームのパフォーマンスを押し上げる関係が見られました。
AI なら大きな差分も一度に作れてしまうぶん、分割の目安と戻し方を決めておく意味は増す一方でしょう。
設計の理由は人が書いて渡す
3 つ目の根拠は Claude Code のガイドで、AI に毎回読ませる設定ファイル（CLAUDE.md）に書くべきものとして、プロジェクト固有のアーキテクチャ上の決定が挙がっています。
コードだけからは推測できない文脈を AI に渡すため、という位置づけです。
設計判断は人が持ち、その理由を文章で残すことが、AI に任せる範囲を広げる前提になります。
判断の理由を残す書き方は、ADR の記事でまとめました。
最後に
AI がコードの多くを書くようになっても、マージを通す責任が人に残る点は変わりません。
変わるのは、全部を自分の目で読むやり方から、確かめる仕組みと、人が承認する範囲を設計するやり方へ重心が移ることです。
承認の線を引いたら、次はレビューそのものの運用ルールを見直す番です。
目的や応答時間まで含めたレビューの決めごとは、こちらで整理しています。
まずは手元のプロジェクトで「完了の定義」を機械が判定できる言葉に書き出すところから始めてみるつもりです。
以上です。
コメントを残す