Post
JA EN

「AIがやるんだから確認は軽くていい」は本当か——AIに任せるほど、確認はむしろ重くなる

Posted
By
38 min read
「AIがやるんだから確認は軽くていい」は本当か——AIに任せるほど、確認はむしろ重くなる
  • 想定読者： AIの出力をどこまで確認すべきか迷うエンジニア、AI前提でレビュー・QAの体制を設計するテックリード・EM・QAリード
  • 前提知識： 生成AIによるコード生成・レビュー支援に触れたことがあること
  • 所要時間： 約18分

概要

「AIがやってくれるんだから、人はざっと確認すればいい」——AI時代、この空気はあちこちで広がっている。そして、まったくの的外れではない。AIが出すものを毎回すべて細かく精査していたら、AIで速くした意味が消えてしまう。確認を軽くすること自体は、合理的な要請ですらある。

だが、結論はこうだ。AIに任せられる範囲が広がるほど、確認はむしろ重く、そして難しくなる。 なぜなら、AIが安くしたのは「実装（コードを書く）」という一工程にすぎず、それを世に出してよいかを見極める確認の仕事は、まるごと人間の側に残るからだ。しかも、その確認の”中身”が変わる。本記事はそれを4つの問いで捉える——何を確認するか（対象）／どこまで（深さ）／どう（問い）／誰が（責任）。そして、その4つすべてに、軸（専門知）が要る。

とりわけ見落とされがちなのが「何を」だ。AIが出すのはコードだけではない。要件・仕様・計画も出す。コードの検証は誰もが気にするが、AIが出した「何を作るか」の検証は素通りされやすく、しかもそこを誤ると被害がいちばん大きい。

この記事は3部作の一本だ。「そもそも軸を作らずに浅く広くで成功できるのか」は本体記事、「AIがあるんだから軸は要らない論」全般は姉妹記事で扱っている。

確認は省けない——手を抜けば事故り、全部見れば回らない

まず、確認が二つの罠に挟まれていることを押さえたい。

手を抜けば、事故る。 これは意志の弱さの問題ではない。自動化を前にすると確認が甘くなるのは、人間の注意の性質そのものに根ざしている。自動化研究ではこれを「automation bias（自動化バイアス）」「complacency（過信）」と呼ぶ。統合レビューによれば、この傾向は熟練者でも生じ、訓練や注意喚起では完全には防げない1。フライトシミュレータの古典的実験では、「ほぼ信頼できるが完璧ではない」自動補助があると、補助なしより監視成績がかえって落ちた2。医療の臨床判断支援でも、誤った助言につられて正解だった判断の5.2%が不正解に変わった3。ソフトウェアでも、AIアシスタントを使った被験者は脆弱性の多いコードを書き、しかも「安全に書けた」と誤認しやすかった4。ベインブリッジが40年前に「自動化の皮肉」で述べたとおり、人が監視役に回るほど、稀な異常を捕まえる力は落ちていく5。

かといって、全部を深く確認はできない。 熟練開発者のRCTでは、AIを使うとむしろ完了が19%遅くなった。AI出力を自分の基準で検証し直す手間が、生成の速さを食い潰したからだ6。開発者調査でも最大の不満は「ほぼ正しいが微妙に違う」出力の修正7、別の調査では「AIコードのレビューは人間のコードより手間」と4割が答え、常に検証する人は半数に満たない8。「全部丁寧に見ろ」は理想論で、守れないルールは現場で省略され、結局は手抜きに逆戻りする。

二つの罠は向かい合っている。手を抜けば見落とす。全部見ようとすれば回らない。 だから確認は「するかしないか」ではなく、何を・どこまで・どう・誰がを設計する問題になる。以下、順に見る。

① 何を確認するか——コードだけではない、AIが出す「要件・仕様」こそ

最初の問いがいちばん見落とされている。確認の対象は、コードだけではない。

AIはいまや、コードを書く前の工程——要件の整理、仕様の起草、実装計画の提案——も担う。「この機能を作りましょう」「この設計でいきましょう」とAIが出してくる。問題は、そこを検証せずに受け入れると、間違った要件で正しく作る——つまり”正しく間違える”ことになる点だ。

前工程の誤りが怖いのは、二つの理由による。第一に、上流の誤りは下流で増幅する。コードのバグは多くの場合ひとつの機能の不具合で済むが、要件・仕様の誤りはプロダクト全体を誤った方向へ走らせる。これはソフトウェア工学の古い常識だ。第二に、前工程は検証が圧倒的に難しい。コードは「動くか」「テストが通るか」で部分的に検証できる。だが要件・仕様の「正しさ」を測る基準は、テストにもCIにも存在しない——レビューする人の中（軸）にしかない。曖昧な指示を投げれば、AIは勝手な仮定で隙間を埋め、もっともらしいが的外れな成果を返す9。「この要件は本当にユーザーが欲しいものか」「このエッジケースは仕様に入っているか」を問えるのは、ドメインとプロダクトを理解している人だけだ。

ここで効いてくるのが、姉妹記事で論じた「両端に軸」という構図だ。AI生成のコードの検証には技術の軸、AI生成の要件・仕様・計画の検証にはプロダクト／ドメインの軸が要る。AIが両端を出すようになったなら、両端ともに確認が要り、それぞれ別の軸が要る。コードのレビューは皆が気にする。だが、AIが出した「何を作るか」のレビューこそ、最も見落とされ、最も大きく外す。

② どこまで確認するか——深さをリスクで差配する

対象が決まっても、すべてを同じ深さで見ることはできない（前述のとおり、それは回らない）。だから深さをリスクに応じて差配する。これは目新しい発想ではなく、規制の世界では標準だ。EUのAI規制はシステムを4段階のリスクに分け、高リスクほど厳しく評価する10。医療機器ソフトでも、一律の検証からリスクベースの方式へ移行している11。

ただし、ソフトウェアの現場で効かせようとすると厄介な事実にぶつかる。「確認の深さ」と「リスクの大きさ」は、きれいには対応しない。 認証や決済——いかにも高リスク——の変更でも、「型で守られた一行」なら確認は浅くて足りる。逆にただのドキュメント更新でも、コピペされる前提のサンプルコードが間違っていれば本番を事故らせる。ラベルと、実際に孕む危うさは、しばしばずれる。

取っかかりとして、確認の深さを上げるべきシグナルを挙げておく。完全な正解表は——後で述べる理由から——あえて作らない。

  • 元に戻せない：削除・送金・送信・本番データの書き換え
  • お金・認証・認可・個人情報に触れる
  • 外部からの入力を、検証せず処理に流している
  • AIが提案した、自分の見慣れないライブラリやAPI（実在しない依存が紛れていないか）
  • 既存の広い範囲の挙動を変える（共有モジュール・設定）

逆に、型とテストで守られ、副作用がなく、局所的で、すぐ戻せる変更なら軽く流してよい。AIが出した百行のうち、深く読むべきはこの数行だ——そう絞り込めること自体が、速さと安全を両立させる。

ただし強く断っておく。これはチェックリストではなく、思考のサンプルだ。 同じ状況でも、プロダクトの規模・リスク許容度・既存のテストの厚さによって、深く見るべき場所は動く。たとえば「AIにユーザー登録機能を書かせた」なら、深く見るのはパスワードの保存・入力検証・エラー時の挙動・「誰がこのデータを読めるか」で、変数名やログ文言は流す。「見慣れないライブラリを勧められた」なら、実在するか・保守されているか・ライセンスを見る。だが、目の前の変更が「外部入力を信頼している」のかどうかは、コードを読み解けなければ気づけない。シグナルは出発点であって、終点ではない。

③ どう確認するか——要所で問いを立てる

では、確認するとは具体的に何をすることか。要所で問いを立てることだ。 「この認可チェックは、別のロールを偽装されてもすり抜けないか」「この処理は、件数が増えてもN+1にならないか」——AIの出力にこうした問いをぶつけ直す、その一つひとつが確認の実体だ。

そして良い問いは、どこに地雷が埋まっているかを知っているからこそ立てられる。コードレビューを大規模に分析した古典的研究は、レビューの核心が「欠陥の発見」そのものより「変更を理解すること」にあると示した12。理解の伴わないレビューは、形だけ承認印を押す作業に堕する。軸のない人は、同じコードを見ても問いが湧かず、「動くからいい」で通してしまう。軸のある人は、危ういところに自然と問いが湧く。

軸の有無が結果を分けることは、別の文脈でも観察されている。AIを与えられた起業家のフィールド実験では、優秀な層は成果を伸ばし、苦戦する層はかえって落とした。違いは「受け取った助言」ではなく、何をAIに任せ、どこに自分の判断を残すかの見極めにあった13。これを確認に置き換えると——軸のある人は「ここは流す／ここは深く見る」を正しく引き、軸のない人はその線を引けず、いちばん危ない箇所を「この程度でいい」と誤判定して素通りさせる。「AIがやるんだから軽くていい」は、軸のある人が言えば適切な省力化、軸のない人が言えば事故への近道。同じ言葉が、軸の有無で正反対の意味になる。だから確認の深さとは、結局立てられる問いの鋭さと数のことだ。

「レビューそのものが要らない」のか——対象で答えが正反対

ここで、もっと振り切れた声に触れておく。「コードレビューや技術的な検証など、そもそも要らない」。これは何に対するレビューかを区別しないと、答えを誤る。

  • 人間が書いたコードへの、重量級の外部承認（変更諮問委員会のような開発の外側の承認ゲート）は、変更失敗を減らす効果が確認されておらず、むしろデリバリを遅らせる。ペアプロのように二人で書いていれば、すでにもう一人の目を通っている。この範囲なら「省ける」は妥当14。
  • だが、AIが生成したコードや要件・仕様への検証は、省けない。むしろAIが出す量が増えるほど激増する。「AIがレビューするから人間は要らない」も成り立たない——AIのコードレビューは人間が見つける品質問題の約1割しか捕まえられず、代替ではなく補完にとどまる15。決済のような規制領域では、自分の変更を自分で承認できない職務分掌が制度として要求される16。

厄介なのは、「レビュー不要」を唱える人の多くが、前者の正しさ（重い承認は無駄）を根拠に、後者（AI生成物の検証）まで一緒に省こうとすることだ。人間が書く量が減ったぶん省けるのは前者、AIが書く量が増えたぶん増えるのは後者。省くべきものと省いてはいけないものが、すり替わっている。

④ 誰が決め、誰が責任を負うか

最後の問いは、個人から組織へ移る。「どこまで確認するか」を誰が決め、誰が責任を持つのかを曖昧にしたまま「軽くていい」を導入すると、別の問題が起きる。

政府アルゴリズムへの「人間による監視」を義務づけた政策を41件調べた研究は、皮肉な結論に達している。人間は期待された監視を遂行しきれず、その結果、監視要件はむしろ欠陥のあるシステムの採用を正当化し、責任の所在をぼかす道具になりうる17。さらに踏み込んだ概念が「モラル・クランプル・ゾーン」だ。自動システムが誤ったとき、実際にはほとんど制御できなかった末端の人間に、道徳的・法的な責任が押し付けられる18。

この構造がいちばん剝き出しになるのが、AI時代によく聞く「検証は要らない、でも責任は持て」という言い方だ。一見もっともらしいが、成り立たない。責任を持つとは、世に出す前に問題を捕まえられること、そして出した後に「なぜこれで良いと判断したのか」を説明できることだ。そのどちらも、検証する手段と、検証できる軸を前提とする。検証を取り上げられたまま責任だけ負わされるのは、責任ではなく——事故が起きたときに差し出される生贄だ。だから「責任を持て」と言うなら、検証する手段と、それを使いこなせる軸を、必ずセットで渡さねばならない。

組織で「確認は軽くていい」を言うなら、セットで決めることがある。深さの基準を誰が引くのか。その判定の責任は誰が負うのか。 ここを曖昧にしたまま掛け声だけが広まると、現場には「形だけの確認」と「いざというときの責任の押し付け」だけが残る。

まとめ

  • 「AIがやるから確認は軽くていい」は逆。AIに任せられる範囲が広がるほど、確認はむしろ重く・難しくなる。AIが安くしたのは実装だけで、確認の判断は人間に残るからだ。
  • 確認は二つの罠に挟まれている。手を抜けば事故り（automation bias）14、全部見れば回らない（検証コスト）6。だから「何を・どこまで・どう・誰が」を設計する。
  • ① 何を：対象はコードだけでない。AIが出す要件・仕様・計画こそ見落とされ致命的。前工程の検証にはプロダクト／ドメインの軸、後工程には技術の軸（両端に軸）9。
  • ② どこまで：深さをリスクで差配する。ただし深さ＝リスクの大きさではない1011。シグナルは出発点で、当てはめるには判断が要る。
  • ③ どう：確認とは要所で問いを立てること。良い問いは「どこに地雷があるか」を知る軸からしか生まれない1213。
  • 「レビュー不要」は対象で正反対：重量級の外部承認は省ける14が、AI生成のコード・要件の検証は省けない（AIレビューは補完どまり15、規制は職務分掌16）。すり替えに注意。
  • ④ 誰が：検証を奪って責任だけ負わせるのは生贄化（モラル・クランプル・ゾーン）1718。深さの基準と責任の所在をセットで決める。
  • 結局、確認の4つすべて——何を・どこまで・どう・誰が——を正しく差配できるのは、軸を持つ人だけだ。

この記事は3部作の一本です。

関連記事

このテーマに関連する他の記事もご覧ください：

参考資料

本文中の引用番号に対応する参考資料を番号順に記載しています。

  1. Complacency and Bias in Human Use of Automation: An Attentional Integration - Parasuraman & Manzey, Human Factors 52(3) (2010). DOI: 10.1177/0018720810376055. automation complacency / bias は熟練者でも生じ、訓練で完全には防げず、マルチタスク負荷下で顕著という実証統合レビュー。【信頼性: 高】 ↩︎ ↩︎2

  2. Does automation bias decision-making? - Skitka, Mosier, Burdick, International Journal of Human-Computer Studies 51(5) (1999). DOI: 10.1006/ijhc.1999.0252. 「ほぼ信頼できるが完璧ではない」自動補助があると監視成績が劣化。omission/commissionの両エラーを実証。【信頼性: 高】 ↩︎

  3. Automation bias: a systematic review of frequency, effect mediators, and mitigators - Goddard, Roudsari, Wyatt, JAMIA 19(1) (2012). DOI: 10.1136/amiajnl-2011-000089. 臨床判断支援のレビュー。誤った助言につられ、正解だった処方判断の5.2%が不正解に変わった。【信頼性: 高】 ↩︎

  4. Do Users Write More Insecure Code with AI Assistants? - Perry, Srivastava, Kumar, Boneh, ACM CCS (2023). AIアシスタント利用群は有意に脆弱性の多いコードを書き、安全だと誤認しやすい。【信頼性: 高】 ↩︎ ↩︎2

  5. Ironies of Automation - Lisanne Bainbridge, Automatica 19(6), 775–779 (1983). DOI: 10.1016/0005-1098(83)90046-8. 自動化が進むほど人間の監視・例外対応・判断が重要かつ困難になるという古典。【信頼性: 高】 ↩︎

  6. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity - METR (2025). 熟練OSS開発者16名・246課題のRCT。AI使用時に完了が19%遅延。小規模・特定文脈につき一般化に留意。【信頼性: 中〜高】 ↩︎ ↩︎2

  7. Stack Overflow Developer Survey 2025: AI - Stack Overflow (2025). 約49,000人。66%が「ほぼ正しいが微妙に違う」AI出力の修正に時間を費やす。【信頼性: 中〜高】 ↩︎

  8. Sonar data reveals critical verification gap in AI coding - Sonar State of Code Survey (2026). 約4割がAIコードのレビューは人間のコードより手間と回答、常に検証する人は半数未満。ベンダー調査である点に留保。【信頼性: 中】 ↩︎

  9. Spec-driven development with AI: Get started with a new open-source toolkit - GitHub Blog (2025). 曖昧な指示はAIが勝手な仮定で埋め成果が崩れる。仕様＝意思決定を先に名指しする装置という整理。前工程（要件・仕様）の検証の重要性を示す。【信頼性: 中（ベンダー開発ブログ）】 ↩︎ ↩︎2

  10. EU AI Act: High-level summary - 欧州連合. AIシステムを4段階のリスク（許容不可／高／限定／最小）に分け、リスクに応じて義務を段階化するリスクベース・アプローチ。【信頼性: 高（公的一次資料）】 ↩︎ ↩︎2

  11. Computer Software Assurance for Production and Quality System Software - U.S. FDA, Federal Register（2022年ドラフト／2025年9月最終化）. 一律の検証から、プロセスリスクの高低で保証の厳しさを変えるリスクベースの方式へ。【信頼性: 高（公的ガイダンス）】 ↩︎ ↩︎2

  12. Expectations, Outcomes, and Challenges of Modern Code Review - Bacchelli & Bird, ICSE (2013). Microsoftでの実証。レビューの核心は欠陥発見そのものより「変更の理解」にあり、理解が伴わなければ効かない。【信頼性: 高】 ↩︎ ↩︎2

  13. The Uneven Impact of Generative AI on Entrepreneurial Performance - Otis, Clarke, Delecourt, Holtz, Koning, Harvard Business School Working Paper 24-042. 高パフォーマーは改善、低パフォーマーは悪化。差は「何をAIに任せ何を自分で判断するかの見極め」にあった。【信頼性: 中〜高】 ↩︎ ↩︎2

  14. Streamlining Change Approval - Google DORA. 外部の重量級変更承認（CAB等）は変更失敗率の低下と関連せず、むしろデリバリ性能に負の影響。ピアレビュー＋自動化を推奨し、ペアプロ済みなら二重レビューは不要とする。【信頼性: 中〜高】 ↩︎ ↩︎2

  15. Studying Quality Improvements Recommended via Manual and Automated Code Review - Crupi, Tufano, Bavota, ICPC (2026). 240 PR・739コメントの分析。AI（GPT-4）は人間が見つける品質問題の約1割しか捕捉できず、人間レビューの代替ではなく補完にとどまる。【信頼性: 中〜高】 ↩︎ ↩︎2

  16. PCI DSS Requirement 6 - PCI DSS 4.0.1（解説）. カード会員データに触れるカスタムコードのセキュアコードレビューと、職務分掌（開発者は自分の変更を承認できない）を要求。規制領域では検証の省略が許されない例。【信頼性: 中〜高】 ↩︎ ↩︎2

  17. The Flaws of Policies Requiring Human Oversight of Government Algorithms - Ben Green, Computer Law & Security Review 45 (2022). 人間監視を求める41件の政策を分析。監視は機能せず、欠陥システムを正当化し責任回避を許す道具になりうると指摘。【信頼性: 中〜高】 ↩︎ ↩︎2

  18. Moral Crumple Zones: Cautionary Tales in Human-Robot Interaction - Madeleine Clare Elish, Engaging Science, Technology, and Society 5 (2019). 自動システムの誤動作時、ほとんど制御できなかった末端の人間に責任が押し付けられる構造（moral crumple zone）。概念提起。【信頼性: 中】 ↩︎ ↩︎2

キャリア・学習
AI AIコーディング コードレビュー 自動化バイアス 検証 品質保証
This post is licensed under CC BY 4.0 by the author.