承認ステップを増やしてもレビューは増えません
AIの生成結果が増えれば人間がレビューする時間も必要です。承認件数・レビュー時間・実行リスクをあわせて計算し、監督が機能する条件を整理しました。
ビジネス「人間が最終確認する」という言葉の次に決めるべきこと
AIが作成した結果を人間が承認する仕組みにしておけば、一見安心できるように思えます。しかし、誰に任せるかを決めるだけでレビューが完結するわけではありません。その担当者が1日に何件読む必要があるのか、何を確認すべきなのか、誤った結果の実行を止める権限があるのかまで決める必要があります。
例えば、AIの導入後にレビューすべき生成物が10倍に増えたにもかかわらず、レビュー人員と時間が据え置きのままだとしたらどうなるでしょうか。承認者をもう1人指定したとしても、実際の内容を読む時間は足りないかもしれません。リクエストを早く処理しようとして、確認を省略してしまうリスクも高まります。
私は、エージェントを導入する際には生成速度とレビュー能力をあわせて設計しなければならないと考えています。人間の承認を必要とするアクションを定め、そのアクションがどれほどの頻度で発生するのかを計算することです。
管理職が懸念しているのは決定の責任でもある
OECD(経済協力開発機構)は、フランス・ドイツ・イタリア・日本・スペイン・米国のミドルマネージャー6,000人以上を対象に調査を実施しました。2025年の発表資料で扱われた「アルゴリズム的管理」とは、業務の割り当て、勤務のモニタリング、評価などを支援または自動化するソフトウェアのことです。生成AIのみに限定した調査ではありません。
ツールを利用している管理職は、意思決定に役立っていると評価しつつも懸念を示しました。誤った決定が下されたときの責任の所在が不明確だという回答が28%、決定の論理を追うのが難しいという回答と労働者の心身の健康保護が不十分だという回答がそれぞれ27%でした。責任の所在が最も多く挙げられたものの、他の懸念との差はそれほど大きくありませんでした。
この結果を「管理職は正確性を心配していない」と解釈すべきではありません。誤った決定を予防することと、エラーが発生した際に誰が対応するのかを決めることの双方が必要であるという意味に近いと言えます。この調査自体も、承認ステップを増やした原因やその効果を実証したわけではありません。
私がこの調査で注目したのは、責任に対する不安を単一の承認プロセスだけで解消しようとする際の問題点です。承認者が存在するという事実と、その人物が実質的に管理できるという事実は別物かもしれないからです。
承認記録には何をレビューしたかが抜けることもある
承認プロセスは、エラーを見つけ出すことと、権限を持つ人物が実行を許可したという事実を記録することの双方に用いられます。この2つの機能が同時に働くためには、レビューするための情報と時間がなければなりません。
エラーを見つけるには、何が変更されるのか、どのような根拠で判断されたのか、誰に影響が及ぶのかを読み取る必要があります。必要であれば一次資料も確認しなければなりません。一方でシステム上には、内容を精読したかどうかとは関係なく、承認アカウントとタイムスタンプだけが残る可能性があります。
そのため、承認件数だけをカウントしても、実際に適切なレビューが行われたかどうかを知ることは困難です。担当者が処理件数のノルマをこなすために複数件を一括で承認してしまうこともあれば、逆に十分なレビューを行おうとしてリクエストが長時間滞留することもあります。どちらのケースも、承認画面を見るだけではその理由を判断できません。
ここで、責任が承認者1人に自動的に帰属すると見なすことも困難です。権限を設定した人、システムを運用する組織、一次データを管理する担当者の役割が複雑に絡み合っているからです。承認ログは経緯を確認するための資料にすぎず、責任配分そのものを代替するものではありません。
米国立標準技術研究所(NIST)の2024年の生成AIリスクマネジメントプロファイルでも、人間とAIの役割配置に伴うリスクを取り上げています。監督の役割を明確に区分し、リスクに比例した評価プロセスを設けることを提案しています。これは自主的な参考ガイドラインですが、承認ボタンの数よりも、監督が実際に機能するための条件に着目している点で極めて有用です。
承認対象の比率を下げてもレビュー件数は増えることがある
以下は、関係性を説明するための仮想の試算です。実際の組織における測定値ではありません。
実務担当者5人が1日あたり4件ずつリクエストを出すと、管理者は20件をレビューすることになります。エージェントを導入した結果、1人あたり1日50件のアクションを提案するようになったと仮定すると、全体では250件になります。そのうち20%だけを事前承認の対象にしたとしても、管理者のもとには50件が届きます。
| 項目 | 導入前 | 導入後の想定 |
|---|---|---|
| 1日に生成されるアクション | 20件 | 250件 |
| 事前承認の対象比率 | 100% | 20% |
| 1日のレビューリクエスト | 20件 | 50件 |
| 1件あたり3分レビューした場合 | 60分 | 150分 |
事前承認の対象比率は下がったものの、レビュー件数は2.5倍になりました。1件あたりのレビュー時間まで変わらないとすれば、必要な時間も2.5倍になります。
250件のうち20件だけをレビューしようとすると、比率は8%になります。しかし、8%が適切な承認基準であるとは限りません。リスクの高いアクションが50件あるとすれば、時間に合わせるために30件のレビューを削るわけにはいかないのです。実行量を制限するか、レビュー人員を補強するか、リスクの高いアクションの発生範囲をより狭く設計する必要があります。
私は、最初は次のように計算してみるのが理解しやすいと考えています。
必要なレビュー時間 ≒ アクション数 × 事前承認対象の比率 × 1件あたりのレビュー時間 + 再レビュー・例外リカバリ時間
これは業務量を大まかに見積もるための簡易的な計算式です。実際にはアクションごとにレビュー時間が異なりますし、複数件をまとめて確認したほうが効率的な場合もあります。差し戻した結果を再確認したり、誤って実行された処理をリカバリしたりする時間も測定しなければなりません。
この数値が担当者の稼働可能時間を超えている場合は、処理量を調整する必要があります。「承認率を下げた」という報告だけで導入効果を判断するのではなく、実際に滞留しているリクエストと待ち時間を確認することが不可欠です。
自動承認が増えても人間の監督が消えるわけではない
Anthropicが2026年2月に公開した利用実態に関する研究には、興味深い結果が示されています。Claude Codeの新規ユーザーのセッションにおいて完全な自動承認を利用する比率は約20%でしたが、利用経験が豊富なグループでは40%を超えていました。同時に、経験豊富なユーザーほど作業の途中で介入して処理を中断させる比率も高かったのです。
研究陣はこれを監督手法の変化と解釈しています。すべてのアクションを事前に承認するのではなく、実行プロセスを見守りながら必要なタイミングで介入するという手法です。自動承認が増えたという事実だけをもって、レビューを放棄したとか安全性が立証されたと結論づけることはできません。
同研究では、タスクが複雑になるほどエージェントが確認の質問を行う頻度とユーザーが処理を中断させる頻度の双方が高まることが示されました。エージェントの質問頻度のほうがより急速に増加しています。もっとも、質問や中断の回数だけで、人間が内容をどれほど深く読み込んだかまで測定できているわけではありません。
私はこの結果について、「人間の介入が増えない」という結論というよりも、どのような方法で監督すべきかを見極める必要があるという説明に近いと考えています。レビュー担当者が中間結果を確認でき、おかしな進行に気づき、即座に停止させることができて初めて、事後介入という手法も成り立ちます。
アクション単体よりもまず作業計画をレビューする
Anthropicは4月の別の論考において、繰り返される承認リクエストがユーザーにとっての摩擦となり、リクエストを注意深く見ずに流してしまう原因になり得ると説明しました。その解決策の1つとして紹介されたのがClaude Codeのプランモードです。実行計画をあらかじめ提示し、ユーザーが確認・修正したうえで作業を開始するアプローチです。
これは組織においても応用できる考え方です。例えば、社内資料を読み込んでレポートの草案を作成するタスクであれば、作業の目的、参照する資料、生成物の保存先をまずレビューできます。作業中に計画の範囲から外れるデータアクセスや外部への送信が必要になった段階で、改めて判断を仰ぐようにするのです。
ただし、計画に合意したからといって、その後のすべてのアクションを無条件で許可したことにはなりません。ツールのアクセス権限、決済金額の上限、社外への送信に必要な承認は個別に設定しておく必要があります。最初に許可した範囲を逸脱するアクションを検知し、停止させる手段も不可欠です。
承認の単位を変えるということは、レビューに必要な文脈をまとめて提示するという意味です。 途中でリスクの性質が変わっても、最初に得た承認のまま実行し続けてよいという意味ではありません。
監督と文書保管はそれぞれ個別に確認する必要がある
韓国の人工知能基本法第34条は、高影響AIやこれを利用した製品・サービスを提供する事業者の責務を定めています。第1項第4号は人間の管理・監督、第5号は安全性・信頼性確保措置を確認できる文書の作成と保管です。
承認ログが存在するという事実だけで、いずれかの義務が満たされたと断定することはできません。実際にどのような管理・監督を行ったのか、安全性・信頼性の確保措置が文書に十分盛り込まれているかを個別に精査する必要があります。単にクリックした時刻だけを残したログをもって、第5号を履行したと見なすこともできません。
適用対象についても「社内ツールか外部サービスか」という区分だけで決まるわけではありません。法が列挙する領域で使用されているか、生命・身体の安全・基本権に重大な影響やリスクを及ぼすおそれがあるかどうかをあわせて検討する必要があります。一般的な社内文書の草案と採用評価に用いられる文書が、いずれも「内部文書」であるという理由だけで同じ扱いを受けるわけではありません。
業種ごとに個別に定められた手続きがある場合は、それにも従う必要があります。レビュー時間を短縮するための設計が、必要な法的手続きを省略してよい根拠にはなりません。
リスクとレビュー能力の双方を見て承認基準を決める
実務においては、まず想定されるアクションをリストアップしてみることをお勧めします。何が変更されるのか、誤った場合の被害規模はどれほどか、復旧可能か、誰に影響が及ぶのかを点検します。社内作業であっても、個人情報を外部に送信したり重要データを上書きしたりするのであれば高いリスクを伴います。
以下は、議論のたたき台とするための例です。同じアクションであっても、データと権限の範囲によって適用すべき統制は異なります。
| アクションの例 | 事前に確認すべき条件 | 統制方式の例 |
|---|---|---|
| 社内草案作成、許可された資料の参照 | 機微情報へのアクセスおよび外部送信の有無 | 権限範囲の最小化、生成結果のサンプルレビュー |
| 社内チケットの変更 | 変更範囲と復旧可能性 | 範囲・回数の制限、変更履歴の記録と例外承認 |
| 顧客向け告知、価格変更 | 受信者・金額・外部への影響度 | 実行前の内容と対象の確認、変更限度額の設定 |
| 高額決済、アカウント削除、重要人事判断 | 被害規模と関連手続き | 自動実行権限の制限、必要な専門レビューと承認 |
承認画面には、変更される内容、判断の根拠、影響を受ける対象をあわせて表示しなければなりません。一次データを確認できるリンクや、差し戻し・中断を行うための導線も必要です。レビュー担当者がその都度複数のシステムを行き来しなければならない状態では、いくら承認リクエストの数を減らしても多くの時間を奪われてしまいます。
成果を評価する際には、自動化率に加えて次の指標を取り入れてみる価値があります。
- 1日のレビューリクエスト件数、1件あたりのレビュー時間と待ち時間
- 承認後にエラーが発見された割合、または再修正が発生した比率
- 複数件を一括承認したケースの有無と、その際のレビュー手法
- 差し戻し後の手戻り作業や例外リカバリに費やした時間
- 承認の負担が重すぎるために利用を断念した業務とその理由
最後の項目は、システムのログデータだけでは把握できません。利用しなくなった理由を担当者本人へ直接ヒアリングする必要があります。管理者だけでなく、リクエストを申請する実務担当者の時間と業務負担もあわせて点検しなければなりません。
Oswarldの視点
私は「人間が最終確認します」という言葉を、安全設計の出発点にすぎないと捉えています。そのうえで、どのアクションを許可するのか、レビューに必要な情報をどのように提供するのか、担当者が処理可能なキャパシティはどれくらいなのかを決める必要があります。
すべてのアクションを承認対象にしておけば、一見すると権限の境界線を今すぐ決めなくても済むように思えるかもしれません。しかしその決定は、毎回リクエストを受け取る担当者個人へと先送りされているだけです。リクエストが増えれば増えるほど、個々の承認者が同じ基準を繰り返し解釈し直さなければならなくなります。あらかじめ定義できる基準は組織として定め、真に判断を要する例外のみをレビュー担当者にエスカレーションする体制のほうがはるかに合理的です。
今年3月の本ニュースレターにおいて、エージェント導入における制約要因として「信頼」の重要性を強調したことがあります。今ではその説明に「レビュー能力」を付け加えるべきだと考えています。ツールに習熟したユーザーがより多くの自律性をエージェントに委ねる傾向は見られるものの、その事実だけで組織が許容できる作業量の上限まで引き上がるわけではないからです。
スループットを向上させるには、レビューに充てる時間を確保するか、リスクの高い実行を削減するか、反復的な確認作業の負荷を軽減するしかありません。単に承認ステップを追加するだけで、この判断が不要になると期待することは難しいでしょう。
今週もし組織内で1つ確認を行うなら、現在承認対象となっているアクションの一覧と、実際のレビュー時間を照らし合わせて点検してみることをお勧めします。精読に必要な時間がそもそも確保されているのかを知ることから始めてこそ、どこに人間の承認を残し、どのアクションの実行範囲を狭めるべきかを具体的に議論できるようになります。
💬 自動化ツールを導入したあと、レビューのリクエストは増えましたか? 実際に内容を精読する時間を確保するために、どのような基準を見直しましたか?
