承認疲れとは。確認を増やすほど中身を見ない承認が増える

コラム一覧へ戻る

承認疲れとは何を指すか

承認疲れは、承認や確認の要求が続いたときに、一件ごとの判断が薄くなり、内容を確かめないまま通すようになる状態を指します。医療の現場で処方時に出る警告表示では「アラート疲れ（alert fatigue）」、多要素認証の承認要求では「MFA疲れ（MFA fatigue）」と呼ばれます。呼び名は分野ごとに違いますが、起きていることは同じです。要求の数が増えたこと自体が、一件あたりの確認の質を下げます。

ここが運用設計で扱いにくいところです。承認を増やす対策は、ある件数までは間違いを止めます。その件数を超えると、増やした分だけ読まれない承認が増えます。

実際に何割が中身を見ずに通されているか

数字が取れている分野があります。処方入力システムが出す薬剤安全警告について、JMIR Medical Informatics に載った2020年の系統的レビューは、複数の研究を集計して、警告が上書き（無視して先へ進む操作）された割合の平均が研究ごとに46.2%から96.2%まで分布したと報告しています。

上書きが常に誤りというわけではありません。同じレビューは、上書きのうち適切だったと判定された割合も29.4%から100%まで幅があったとしています。警告の種類によって差が大きく、高齢者向けの警告では適切と判定された上書きが14.3%から57%にとどまりました。残りは、止めるべきものを止められなかった分です。

なぜこうなるのかは、承認者の側に立つと説明がつきます。警告が全件に出るため、そのほとんどは自分の判断と一致します。一致する警告を毎回読むのにかかる時間が積み上がり、読まずに閉じたときの手戻りより大きくなった時点で、読まないことが合理的な作業手順になります。

これは医療特有の話ではありません。同じ構造は、経費申請でも、外注への発注でも、AIが出した下書きの確認でも起きます。承認者が1日に同じ形の依頼を何十件も見て、その大半が問題ないとき、読む手は止まります。

連続する承認要求は「止めるため」に押される

「うちの承認は機械が出す警告ではなく、人が中身を見て押すものだから違う」と考えるかもしれません。人が押す承認でも同じことが起きた例があります。

Uber は2022年9月16日の告知で、社外委託先のアカウントが乗っ取られた経緯を公開しています。攻撃者は委託先の業務用パスワードを闇市場で入手したとみられ、そのアカウントへのログインを繰り返し試みました。試行のたびに委託先には二要素認証の承認要求が届き、当初はそれが侵入を止めていました。しかし最終的に委託先が要求の一つを承認し、攻撃者のログインが通りました。そこから社内の他アカウントへ広がり、業務ツールへの権限が渡っています。

承認要求が連続すると、承認は「内容を判断する操作」から「要求を止める操作」に変わります。押せば通知が止まるからです。そして、押し方が変わったことは記録に出ません。中身を読んで押した承認も、通知を止めるために押した承認も、承認済みという同じ形で残ります。だから質が落ちていることは、事故が起きるまで誰にも見えません。

AIに任せるほど、承認要求の母数が増える

この問題は、AIエージェントに作業を任せる現場で先に表面化しています。Uber が社内で使うAIエージェントの動きを記録する仕組みについて、2026年5月に公開された論文があります。同社で10か月以上運用した結果として、7,200台以上の端末で1日1万件を超えるエージェントのセッションを処理していると報告されています。運用の中で、社外に出ていた認証情報の露出を26分類にわたって数百件見つけたとも書かれています。

件数の桁が変わったことが、そのまま承認の問題になります。エージェントが動くたびに人の確認を求める設計にすれば、承認要求はセッション数に比例して増えます。承認する人の数は増えないので、あふれた分は押されるだけの承認になります。

承認者1人あたりの件数を数える

承認疲れが起きているかどうかは、感覚ではなく件数で判断できます。次の順で測ります。

• 承認者ごとに、1日に届く承認依頼の件数を数える。誰の手元に何件溜まっているかを人単位で出す。
• 1件を確かめるのに実際にかかる時間を出す。過去に差し戻した依頼を例にとり、問題に気づくまでに何分かかったかで測る。
• 件数と1件あたりの時間を掛け、その人が承認に使える時間を超えていないか見る。

超えているなら、承認を求める箇所を足しても、読まれない承認が増えるだけです。打ち手は3つです。承認を求める依頼の種類を減らす、承認者を分けて1人あたりの件数を下げる、承認を通したうえで事後に抜き取りで見る形に変える。

どの依頼に承認を残すかの線引きは、間違えたときの損害と取り返しやすさで決めます。その分け方はHuman-in-the-loop の記事で扱っています。承認を外した依頼については、何をいつ通したかを後から追える記録を残しておく必要があります。記録の残し方は監査ログの記事にまとめています。

PATHWORK での扱い方

PATHWORK は、チャットで来た依頼をタスクに起こし、担当と状態と期限を1画面で追う道具です。承認疲れの文脈では、「確認待ち」の状態を担当者ごとに並べられる点が対応します。誰の手元に承認待ちが何件あるかが表に出るので、上で挙げた1つ目の数え方は道具で済みます。

ただし、道具は件数を見せるだけです。何件までなら読めるのか、どの依頼から承認を外すのかは、運用として人が決めます。状態を用意しただけでは、承認待ちの列が見えるようになり、列そのものは短くなりません。

まとめ

承認疲れは、承認要求の件数が承認者の処理量を超えたときに、確認が中身を読まない押印に変わる状態です。承認済みの記録は同じ形で残るため、質が落ちたことは事故が起きるまで表に出ません。承認を全件に挟む設計は、件数が少ないうちは間違いを止めますが、依頼が増えると止まらなくなります。

次の一手は、承認者1人あたりに1日何件の承認が届いているかを数えることです。1件に取れる時間が、問題に気づくのに必要な時間を下回っていたら、承認の対象を減らす判断に入ります。

参考

• Poly TN, Islam M, Yang HC, Li YJ. Appropriateness of Overridden Alerts in Computerized Physician Order Entry: Systematic Review. JMIR Medical Informatics, 2020
• Uber Newsroom: Security update（2022年9月16日）
• ADR: An Agentic Detection System for Enterprise Agentic AI Security（arXiv, 2026年5月）