「危険な操作は、最後に人間が承認する」——AIエージェントの設計記事では、この一文が安全策の締めくくりとしてよく登場します。本サイトでも、人間承認ワークフローの設計パターンや、人間承認レイヤーへの攻撃を取り上げてきました。
ただし、本番運用に入ると別の問題が出てきます。承認する人は容量に限りがある運用資源だということです。承認依頼が処理能力を超えて積み上がると、エージェントは承認待ちで止まり、業務も止まります。待たされた担当者は急かされ、やがて中身を見ずに承認ボタンを押すようになります。攻撃者がいなくても、量と人員の不足だけで承認ゲートは形だけのものになります。
これは、TAC（テクニカルサポート）のケースキュー管理で何度も見てきた光景です。バックログが積み上がり、SLAが破られ、エンジニアは目の前のケースをとにかく閉じることを優先する。L1で止まるはずのケースがL2に流れ込み、L2のエキスパートは本来の難しいケースに手が回らなくなる。エージェントの承認キューも、まったく同じ構図をたどります。
本稿の位置づけ
AgentOps連載では、PromptOps（指示資産）、ナレッジ運用（参照資産）、ツール運用（能力資産）、モデル運用、キャパシティ運用、ガードレール運用と、エージェントを支える資産を順に「運用対象」にしてきました。本稿では、最後に残った資産である人間を扱います。
| 既存記事 | 扱ったこと | 本稿との違い |
|---|---|---|
| 人間承認ワークフロー設計パターン（3/27） | HITL・HOTL・HOVLの使い分けと承認UIの設計 | 本稿は、設計した承認フローを本番で運用し、計測する話です |
| 人間承認レイヤー攻撃対策（8/25） | 攻撃者が承認疲れを意図的に突く手口 | 本稿は、攻撃がなくても量と人員の不足で自然に劣化する問題を扱います |
| キャパシティ運用編（9/27） | TPM/RPM、クォータ、同時実行など機械側の容量 | 本稿は人間側の容量です |
| ガードレール運用編（10/3） | 誤検知を人のレビューで吸収する、という方針 | 本稿は、その「人のレビュー」を受け止める側の運用です |
設計記事が「承認フローの設計書」だとすれば、本稿は「承認デスクの運用手順書」です。
なぜ人間の承認は”放っておくと”劣化するのか
エージェントは疲れないが、人間は疲れる
エージェントは、夜間でも休日でも、同じ速度で承認依頼を生み出します。導入当初は1日数件だった承認依頼が、対象業務の拡大やエージェント数の増加に伴って、数十件、数百件へと増えていきます。一方で、承認する人の数と集中力は増えません。到着率（依頼の発生ペース）が処理率（人が捌けるペース）を上回った瞬間から、キューは伸び続けます。これは待ち行列の基本的な性質で、気合いでは解決しません。
承認は”増やす理由”しかない
インシデントが起きるたびに「この操作も人間の承認を挟もう」という対策が足されます。承認ポイントを外す判断は、誰もしたがりません。結果として、承認ポイントは単調に増え、低リスクの操作まで承認待ちに並ぶことになります。ガードレール運用編で扱った「例外は足す理由しかない」と、ちょうど裏返しの構造です。
2つの失敗モードは連動している
- 失敗モードA：人が詰まって業務が止まる——承認待ちが滞留し、エージェントのタスクがタイムアウトする。利用部門から「AIを入れたのに遅くなった」と言われる。
- 失敗モードB：人が形だけ押す（ラバースタンプ化）——承認率がほぼ100%に張り付き、1件あたりの判断時間が数秒になる。承認ゲートが存在するのに、何も止めていない。
重要なのは、AはBを生むということです。キューが詰まると、担当者は滞留を減らすために判断を浅くします。つまり、承認キューの滞留を放置することは、そのまま安全性の劣化につながります。HumanOpsは、この2つを同時に監視する運用です。
まず棚卸し——承認ポイントという”人的資源の消費先”を一覧にする
最初にやるべきことは、「どこで、誰が、どれだけ承認しているか」の一覧化です。多くの組織では、承認ポイントがエージェントごと・ワークフローごとにばらばらに作られていて、全体像を誰も把握していません。
| 項目 | 記録する内容 |
|---|---|
| 承認ポイント名 | 例：「外部へのメール送信」「100万円以上の発注」「本番DBへの書き込み」 |
| 発生元 | どのエージェント・ワークフローが依頼を出すか |
| リスク区分 | 高・中・低（誤って承認したときの影響の大きさ） |
| 承認者グループ | 誰が承認できるか（個人名ではなくロールで） |
| 依頼件数 | 1日あたり・ピーク時間帯あたりの件数 |
| 待ち時間SLO | 何分以内に判断すべきか（後述） |
| タイムアウト時の動作 | 保留・却下・エスカレーションのどれか |
| 過去の差し戻し率 | 実際に止めた実績があるか |
この表を作るだけで、「低リスクなのに承認件数の大半を占めている承認ポイント」や「タイムアウト時の動作が誰にもわからない承認ポイント」が見つかることがよくあります。
規律1：承認待ち時間のSLOを決める
「早く承認してほしい」を数字にする
承認キューの運用は、まず待ち時間の目標（SLO）を決めるところから始まります。TACでいえば、優先度ごとの初動SLAにあたります。測る指標は、次の2つに分けておくと原因を切り分けやすくなります。
- 初動時間（Time to Pickup）：依頼が届いてから、誰かが手に取るまでの時間。人員配置やシフトの問題が表れます。
- 判断時間（Time to Decision）：手に取ってから、承認・却下が決まるまでの時間。依頼の情報不足や判断の難しさが表れます。
平均値ではなく、p50とp95で見ることが大切です。平均は「ほとんどすぐ終わるが、一部が何時間も放置されている」状態を隠してしまいます。
SLOはリスク区分ごとに変える
| リスク区分 | 例 | 待ち時間SLOの考え方 | SLO超過時の動作 |
|---|---|---|---|
| 高 | 送金、本番データ削除、権限変更 | 業務時間内に短時間で判断。夜間は待たせる前提で設計 | 上位へエスカレーション。自動承認は絶対にしない |
| 中 | 社外へのメール送信、発注 | 数時間以内 | 担当グループ内で再割り当て、その後エスカレーション |
| 低 | 社内向け文書の更新、定型処理 | そもそも事前承認が必要か見直す | 事後レビュー（サンプリング）への移行を検討 |
タイムアウトを”自動承認”にしない
よくある危険な設計が、「一定時間内に応答がなければ承認とみなす」というものです。業務を止めたくない気持ちはわかりますが、これは承認ゲートを無効化するのと同じです。タイムアウト時の動作は、保留（エージェントは安全な状態で待機）・却下・エスカレーションのいずれかにします。業務を止めたくないなら、タイムアウトを緩めるのではなく、後述の規律4と5で処理能力そのものを上げます。
規律2：キュー滞留とバックログを監視する
見るべき4つの指標
| 指標 | 意味 | 何がわかるか |
|---|---|---|
| キュー深さ（Queue Depth） | 今、未処理の承認依頼が何件あるか | 現在の負荷 |
| 最古の依頼の経過時間（Oldest Item Age） | いちばん古い未処理依頼が何分待っているか | 放置されている依頼の有無。最も重要 |
| 流入率と処理率 | 1時間あたりの新規依頼数と処理完了数 | キューが伸びているか縮んでいるか |
| バックログの消化見込み | 現在の処理率で、今の滞留が何時間で解消するか | 増員や応援が必要かどうか |
キュー深さだけを見ていると、「件数は少ないが、1件が3日放置されている」状態を見逃します。TACの現場でも、件数よりエイジング（ケースの経過日数）のほうが重視されていました。古いケースほど、顧客の不満も、解決の難しさも増していくからです。
リトルの法則で”必要な人数”を見積もる
待ち行列には「平均滞留件数 ＝ 到着率 × 平均滞在時間」という関係（リトルの法則）があります。たとえば、1時間に30件の承認依頼が届き、1件の判断に平均4分かかるなら、1人で捌ける上限は1時間に15件です。つまり常時2人以上が承認に張り付いていないと、キューは伸び続けます。会議や他業務の時間を考えれば、実際にはさらに余裕が必要です。この計算を一度やるだけで、「承認は手の空いた人がやる」という運用が成り立たない理由が見えてきます。
アラートの例
- 高リスクの依頼で、最古の依頼の経過時間がSLOの50%を超えた → 担当グループへ通知
- 流入率が処理率を一定時間上回り続けている → 承認デスクの責任者へ通知
- 特定のエージェントからの依頼が急増した → エージェント側の異常（ループ、誤設定）を疑う
最後の項目は見落とされがちです。承認依頼の急増は、人間側ではなくエージェント側の暴走の兆候であることも多く、承認キューはエージェントの異常検知センサーとしても機能します。
規律3：承認率・差し戻し率で”ラバースタンプ化”を検知する
承認率100%は”健全”ではない
承認キューが空で、SLOも守られている。一見すると理想的ですが、承認率がほぼ100%なら疑ってかかる必要があります。承認ゲートは止めるために存在します。何も止めていないなら、それは「判断が要らない承認ポイント」か「判断していない承認者」のどちらかです。
ラバースタンプ化のシグナル
| シグナル | 見方 |
|---|---|
| 承認率の高止まり | 差し戻し・却下が長期間ゼロ |
| 判断時間の極端な短さ | 依頼内容を読み切れない秒数で承認している |
| 詳細を開かない承認 | 差分・根拠・影響範囲の表示を開かずに承認ボタンを押している |
| 連続一括承認 | 短時間に大量の依頼を立て続けに承認している |
| 時間帯による変化 | 終業前や長時間シフトの後半で判断時間が急に縮む |
| 担当者間のばらつき | 同じ種類の依頼で、特定の担当者だけ差し戻し率が極端に低い |
これらは個人を責めるための指標ではありません。ラバースタンプ化は、ほとんどの場合量が多すぎる・情報が足りない・判断基準が曖昧という仕組みの問題の結果です。指標は「どの承認ポイントの設計を直すべきか」を見つけるために使います。
事後サンプリング監査で”承認の質”を測る
承認率や判断時間は、あくまで間接的な指標です。承認の質そのものを測るには、承認済みの依頼から一定割合を抜き出し、別の担当者（またはL2）が改めて判断し直す事後監査が有効です。「本来は差し戻すべきだったのに承認されていたもの」の割合が、承認ゲートの実質的な見逃し率になります。
さらに踏み込んだ方法として、内容に問題を含むテスト用の承認依頼をあらかじめ決めた頻度で混ぜ、正しく差し戻されるかを確認するやり方もあります。導入する場合は、担当者に「テスト依頼が混ざることがある」と事前に周知し、結果を個人評価に使わないことを明確にしておきます。目的は、承認者を試すことではなく、承認ゲートが機能しているかを確かめることです。
規律4：L1/L2/L3の段階エスカレーションを設計する
すべての依頼を同じ人に送らない
承認依頼の多くは定型的で、判断基準も明確です。一方、ごく一部は文脈の理解や専門知識が必要です。これらを同じキューに並べると、難しい依頼が簡単な依頼の山に埋もれ、簡単な依頼は専門家の時間を浪費します。TACのティア構造と同じ発想で、承認者を段階に分けます。
| 段階 | 担当 | 扱う依頼 | 上位へ上げる条件 |
|---|---|---|---|
| L1 | 業務担当者・承認デスク | 判断基準が明文化された定型依頼 | 基準に当てはまらない、情報が不足している、SLO超過 |
| L2 | 業務の責任者・領域の専門家 | 例外的な依頼、影響範囲の大きい依頼 | 組織横断の影響、法務・セキュリティ判断が必要 |
| L3 | セキュリティ・法務・経営層 | 重大な影響を伴う依頼、インシデントの疑い | （最終判断） |
エスカレーションは”時間”と”内容”の2系統で
- 時間ベース：SLOに対して一定時間を過ぎたら自動で上位に通知する。放置を防ぐ仕組みです。
- 内容ベース：金額・対象システム・データ区分などの条件で、最初から上位に振り分ける。L1が判断できない依頼をL1に並ばせない仕組みです。
エスカレーションの”戻り”を作る
L2・L3が判断した結果は、L1の判断基準にフィードバックします。「この種の依頼はこう判断する」という前例が蓄積されれば、次回からL1で処理できるようになり、上位の負荷が下がります。TACでいえば、エスカレーションされたケースからナレッジベース記事を作る流れです。逆に、同じ種類の依頼が繰り返しL2に上がってくるなら、それはL1の判断基準が足りていないというシグナルです。
規律5：担当者の負荷を平準化し、シフトを設計する
1人あたりの”同時に抱える件数”に上限を設ける
承認依頼を特定の人に割り当てる場合、1人が同時に抱える未処理件数に上限（WIP制限）を設けます。上限に達した担当者には新しい依頼を割り当てず、他の担当者に回します。これにより、「仕事が速い人に依頼が集中し、その人から燃え尽きる」という状況を防げます。
割り当て方式を選ぶ
- プッシュ型（自動割り当て）：システムが順番に依頼を割り当てる。偏りが出にくい反面、担当者の状況（会議中など）を考慮しにくい。
- プル型（各自が取る）：担当者がキューから自分で依頼を取る。柔軟だが、簡単な依頼だけが取られ、難しい依頼が残る「つまみ食い」が起きやすい。
プル型を採る場合は、古い依頼から順にしか取れないようにするか、一定時間取られなかった依頼を自動で割り当てる仕組みを併用します。
シフトと”承認時間帯”を設計する
- 承認担当を「手が空いたらやる仕事」にせず、承認デスクの当番として時間を確保する
- 長時間の連続担当を避ける（判断時間が縮み始める時間帯を指標で確認する）
- 休日・夜間・連休の承認体制を決めておく。決められないなら、その時間帯には高リスク操作を依頼させない（エージェント側のスケジュールで制御する）
- 担当者の不在（休暇・異動）で承認者が空白にならないよう、ロール単位で複数人を割り当てる
需要側を調整する——承認件数そのものを減らす
人を増やすより効果が大きいのが、承認依頼の量を減らすことです。
- 低リスク操作の事後レビュー化：差し戻し率が長期間ゼロで、影響も小さい承認ポイントは、事前承認から事後のサンプリング監査に切り替える
- 類似依頼のまとめ承認：同種の依頼を1件ずつ出させず、条件を揃えてまとめて判断できるようにする（ただし一括承認がラバースタンプ化しないよう、まとめる条件は厳密にする）
- 依頼の質を上げる：エージェントに「何を・なぜ・影響範囲は・取り消せるか」を構造化して添えさせる。判断時間が短くなり、差し戻しの往復も減る
- バッチ処理の時間をずらす：夜間バッチで大量の承認依頼が朝一番に積み上がる構造なら、実行タイミングを分散させる
承認ポイントを外す判断は、必ず棚卸し表の実績（差し戻し率、事後監査の結果）に基づいて行い、外した理由を記録します。
運用サイクル——いつ、何を見るか
| 頻度 | 見るもの | 担当 |
|---|---|---|
| リアルタイム | キュー深さ、最古の依頼の経過時間、SLO超過アラート | 承認デスク当番 |
| 日次 | 流入率と処理率、未処理のまま日をまたいだ依頼、エスカレーション件数 | 承認デスクの責任者 |
| 週次 | 承認率・差し戻し率・判断時間の推移、担当者間の負荷の偏り | 業務責任者 |
| 月次 | 事後サンプリング監査の結果、L2/L3からL1へのフィードバック反映 | 業務責任者＋L2 |
| 四半期 | 承認ポイントの棚卸し（追加・削除・事後レビュー化の判断）、人員計画の見直し | 業務責任者＋セキュリティ |
よくある落とし穴
- 「人間の承認があるから安全」で設計を終える——承認者の処理能力を見積もらないまま、承認ポイントだけが増えていく。
- タイムアウトを自動承認にする——業務を止めないための設定が、承認ゲートを無効化する。
- キュー深さだけを見る——件数が少なくても、1件が何日も放置されている状態を見逃す。
- 承認率の高さを「順調」と読む——止めていない承認ゲートは、存在しないのと同じ。
- ラバースタンプ化を個人の怠慢として扱う——量・情報・基準という仕組みの問題が放置され、担当者が入れ替わっても同じことが起きる。
- 承認依頼の急増を人手の問題とだけ考える——実はエージェント側のループや誤設定だった、というケースを見逃す。
- 承認者が特定の1人に依存している——その人の休暇で業務全体が止まる。
HumanOps チェックリスト
| 領域 | 確認項目 |
|---|---|
| 棚卸し | すべての承認ポイントについて、リスク区分・承認者ロール・件数・タイムアウト時動作が一覧になっている |
| SLO | リスク区分ごとに待ち時間SLOがあり、p50/p95で計測している |
| SLO | タイムアウト時の動作が「自動承認」になっている承認ポイントがない |
| キュー監視 | 最古の依頼の経過時間と、流入率／処理率を監視している |
| キュー監視 | 承認依頼の急増を、エージェント側の異常としても調査する手順がある |
| ラバースタンプ化 | 承認率・差し戻し率・判断時間を承認ポイント別に追っている |
| ラバースタンプ化 | 事後サンプリング監査で、承認の見逃し率を定期的に測っている |
| エスカレーション | L1/L2/L3の役割と、時間ベース・内容ベースの上げ条件が決まっている |
| エスカレーション | 上位の判断結果がL1の判断基準にフィードバックされている |
| 負荷平準化 | 1人あたりのWIP上限があり、担当者間の負荷の偏りを確認している |
| シフト | 承認デスクの当番時間が確保され、休日・夜間・不在時の体制が決まっている |
| 需要調整 | 差し戻し実績のない低リスク承認を、事後レビューへ移行する判断を定期的に行っている |
よくある質問（Q&A）
Q1. 小さなチームでも、ここまでの運用が必要ですか？
すべてを最初から揃える必要はありません。まずは「承認ポイントの一覧」と「最古の依頼の経過時間」の2つから始めてください。少人数のチームほど、1人の不在で承認が止まりやすいため、承認者を複数人にしておくことは早めに対応する価値があります。
Q2. 承認率はどのくらいが適切ですか？
適切な数値は業務によって異なります。重要なのは絶対値より、差し戻しが一定期間まったくないかどうかと、事後監査で見逃しが見つかっていないかです。差し戻しゼロが続き、事後監査でも問題がないなら、その承認ポイントは事後レビューに移行できる候補です。差し戻しゼロなのに事後監査で見逃しが見つかるなら、ラバースタンプ化しています。
Q3. 承認待ちで業務が止まると苦情が来ます。タイムアウトで自動承認にしてはいけませんか？
おすすめしません。自動承認にすると、承認者が忙しいときほどチェックが外れることになり、最もリスクが高い状況で守りがなくなります。業務を止めたくない場合は、低リスク操作の事後レビュー化、依頼の質の改善、承認デスクの当番制など、処理能力を上げる方向で対応してください。
Q4. 承認をAI（別のLLM）に任せれば、人の負荷はなくなりますか？
一次スクリーニングとしてAIを使い、明らかに問題のない依頼と、人が見るべき依頼を振り分けるのは有効です。ただし、AIによる判断は人間の承認の代わりではなく、L1の前段に置く「L0」と考えるのが安全です。AIが通した依頼も事後サンプリング監査の対象に含め、AI側の見逃し率も計測してください。
Q5. 人間承認レイヤーへの攻撃対策とは、どう役割分担すればよいですか？
攻撃対策は、承認疲れを意図的に突く攻撃者から承認ゲートを守る設計です。本稿のHumanOpsは、攻撃がなくても承認ゲートが劣化しないようにする日常運用です。両者は補い合う関係で、HumanOpsでキューと承認の質を平常時から計測していれば、攻撃による異常な依頼の急増や承認パターンの変化にも気づきやすくなります。
まとめ——人間も、運用されて初めて安全装置になる
「最後は人間が承認する」は、それだけでは安全策になりません。承認する人には処理能力の上限があり、疲れ、休み、入れ替わります。承認キューが詰まれば業務が止まり、詰まりが続けば判断が浅くなり、承認ゲートは形だけのものになります。
HumanOpsの規律は、TACのケースキュー管理と同じです。待ち時間のSLOを決め、滞留とエイジングを監視し、承認率と差し戻し率で質を測り、段階エスカレーションで適切な人に適切な依頼を届け、担当者の負荷を平準化する。そして何より、承認依頼の量そのものを、実績に基づいて減らしていくことです。
エージェントの守りは、機械側の資産だけでは完成しません。人間という資産を運用対象として扱ったとき、承認ゲートは初めて「止めるべきものを止める」装置として機能します。
コメント