「人間が最終確認します」は、確認の回数が増えるほど安全策でなくなる

「人間が最終確認します」は、確認の回数が増えるほど安全策でなくなる

AI活用の相談を受けていると、安全策としてこの言葉をよく聞きます。「実行はAIにさせますが、最終確認は人間が入れています」。設計としては素直で、説明もしやすい。反対しにくい安全策です。

しかし、その確認が実際に機能しているかを測っている組織は、まだ多くありません。

この記事では、Anthropicが自社ツールの利用データと統制実験を公開した資料をもとに、「人間の確認」がどの条件で機能し、どの条件で形骸化するのかを整理します。

参照元はAnthropic公式ブログ（2026年8月7日付）およびTechCrunchの報道（2026年8月9日）です。本記事の内容は2026年8月26日時点で確認できた記載にもとづきます。

30秒で要点

• 開発ツールの利用データでは、権限確認プロンプトの97%が承認されている
• ただし拒否率はプロンプトの種類で大きく異なり、まとまった計画の提示には39%が拒否され、個別の権限リクエストには3%しか拒否されていない
• 有償テスター1,053名の統制実験で、危険なコマンドを人間のレビューが検知できたのは13.6%、自動判定は89%だった
• 人間の検知率はセッション初期の17%から50プロンプト以降で約5%へ低下し、自動判定は横ばいだった
• 実運用ログの再評価では、本番相当の重大度で手動承認セッションの6.3%に利用者が求めていない有害な操作が含まれていた

97%という承認率が意味すること

公開されたデータのうち、最初に目を引くのはこの数字です。利用者は権限確認プロンプトの97%を承認しています。

100回聞かれて、97回「はい」と答えている。この状態を「確認している」と呼べるかどうかは、微妙なところです。少なくとも、確認が判断の分岐として働いている頻度は高くありません。

しかし、この数字だけで「人間は確認しない生き物だ」と結論づけるのは早すぎます。同じデータには、もう一つ性質の違う数字が並んでいます。Claudeがまとまった計画を提示したときの拒否率は39%です。一方、個別の権限リクエストに対する拒否率は3%にとどまります。

同じ人間が、片方では4割近くを差し戻し、もう片方ではほぼ素通りさせている。ここが本記事のいちばん重要な分岐点です。

実験が示した、検知率の差

利用データに加えて、統制実験の結果も公開されています。有償テスター1,053名を対象に、意図的に危険なコマンドを紛れ込ませ、それを検知できるかを測ったものです。

結果は、人間のレビューが検知できたのは13.6%、自動判定が検知したのは89%でした。さらに、自動判定は人間が承認した800件のコマンドをブロックした一方、人間が自動判定の許可したもののうちブロックしたのは6件でした。TechCrunchも同じ13.6%と89%という数値を独立に報じています。

そして、時間の効果がはっきり出ています。人間の検知率はセッション初期には17%あったものが、50プロンプトを超えたあたりで約5%まで下がりました。自動判定の検知率は、セッションの長さに関わらず横ばいでした。

実運用のログを再評価したデータもあります。2026年5月から6月にかけて、学習利用にオプトインしたアカウントを対象にした集計で、本番環境相当の重大度において、手動承認セッションの6.3%に、利用者が明示的に求めていない有害な操作が含まれていたとされています。自動モードのセッションでは2.4%でした。

設定ファイル側の実態も公開されています。2026年6月時点で、アクティブなCLI利用者の49.5%が手動でシェルコマンドの許可ルールを作成しており、5%はあらゆるシェルコマンドを無条件に許可、62%が確認の迂回機能を使うか「二度と確認しない」を選択、対話セッションの25%が確認を迂回するモードで開始されています。つまり、確認が煩わしくなった利用者は、確認そのものを外す方向に動いていた、ということです。

なぜ「確認を増やせば安全になる」と考えてしまうのか

ここで一度、なぜこの設計が採られやすいのかを考えたいと思います。

確認の回数は、目に見えて数えられるからです。 「重要な操作の前には必ず承認を挟んでいます」は、監査でも会議でも説明しやすい。一方、「その承認が実際に判断として機能しているか」は、測らない限り見えません。見えるものと見えないものがあるとき、統制の設計は見えるほうに寄っていきます。

もう一つは、確認を増やすことの副作用が、増やした時点では現れないからです。プロンプトを1つ足したときに何かが悪化するわけではありません。悪化は、回数が積み上がって初めて起こります。個々の判断としては常に「増やすほうが安全」に見え、累積の効果だけが見落とされます。

そして最も見落とされやすいのが、確認の回数とレビューの質がトレードオフの関係にあるという点です。多くの設計は、両者を独立だと暗黙に仮定しています。確認を10箇所に増やせば、10箇所ぶんの安全性が積み上がるはずだ、と。しかし実験データが示しているのは、回数が増えるほど1回あたりの質が落ちるという関係です。この場合、確認を増やすことは安全性の合計を必ずしも増やしません。

人間は「判断」には耐えるが、「確認の連続」には耐えにくい

計画への拒否率39%と、個別許可への拒否率3%。この差の読み方が、実務への翻訳の鍵になります。

計画の提示は、まとまった判断を1回求める形式です。何をしようとしているのか、それが妥当かを考える余地があり、考えるだけの情報も提示されています。ここでは人間は機能しています。4割近くを差し戻しているのですから、明らかに吟味しています。

個別の実行許可は、細かい確認を連続して求める形式です。1件あたりの情報は少なく、文脈は前後に分散し、しかも次々に来ます。ここで人間の吟味は保ちません。

つまり問題は「人間を信頼するかAIを信頼するか」という二択ではなく、どの粒度で人間の判断を求めるかという設計問題です。承認プロンプトを増やすことは、しばしば安全性の強化ではなく、外形的な統制の見た目——安全性の演技——にとどまります。

確かなことと、まだ確かではないこと

確かなこと：権限確認プロンプトの承認率が97%であること。計画への拒否率が39%、個別許可への拒否率が3%であること。1,053名の実験で人間の検知率が13.6%、自動判定が89%だったこと。人間の検知率がセッション長とともに17%から約5%へ低下したこと。実運用ログの再評価で手動承認6.3%対自動モード2.4%だったこと。設定ファイル側の迂回の実態。

まだ確かではないこと：これらの数値は、いずれも単一のベンダーが自社製品について公表したものです。TechCrunchが一部の数値を独立に報じてはいますが、それは報道であって追試ではありません。また1,053名は特定経路の有償テスターであり、実運用ユーザー全体の代表とは限りません。実運用ログの再評価も、学習利用にオプトインしたアカウントに限定されています。

そして、この数値が他社のツールや、開発以外の業務にそのまま当てはまる保証はありません。測定されたのは特定の開発ツール上での挙動です。経費承認や稟議のような業務プロセスに同じ比率を持ち込むことはできません。ここで持ち帰れるのは数値そのものではなく、「確認の粒度と回数が、レビューの質に影響しうる」という構造のほうです。

なお、このデータを公開したAnthropic自身も、高リスクな本番環境の変更については引き続き人間がレビューすべきだとしています。「人間の確認は不要だ」という読み方は、資料の主張とも異なります。

判断軸の提示

ここまでの整理から、承認フローを設計・見直しする際の判断軸を1つ提案します。

確認の「数」ではなく、「1回あたりに判断できる情報量」で設計すること。

具体的には、承認を求める箇所を洗い出したうえで、それぞれが「まとまった判断」の形になっているか、「細かい確認の連続」になっているかを分類します。後者が多い場合、それは統制が厚いのではなく、統制が薄まっている可能性があります。

そのうえで、細かい確認を束ねて、まとまった判断1回に置き換えられないかを検討します。10回の実行許可より、1回の計画レビューのほうが、実際に差し戻される確率は高い。

自分でも試せる、最小の検証

自社でAIツールや自動化の承認フローを運用している場合、確かめるべき数字は1つです。承認率。

直近1か月の承認依頼のうち、承認した件数と差し戻した件数を数えてください。分母は依頼の総数、分子は差し戻した件数です。この比率が限りなくゼロに近いなら、その確認は判断の分岐として機能していないと考えたほうが実態に近い。

多くの組織では、この数字がそもそも記録されていません。その場合は、記録を取りはじめること自体が最初の一歩になります。確認が機能しているかどうかを測っていない状態では、確認を増やしても減らしても、その効果は分かりません。

この記事で扱ったような、AIの権限設計と承認フローを自社の状況に照らして整理したい場合は、無料診断ツールで状況を言語化するところから始めることができます。