Risk-based Human Approval｜リスクベース人間承認¶

一言で（TL;DR）¶

エージェントが実行しようとする操作をリスクスコア（不可逆性 × 失敗コスト）で3層に分類し、低リスクは自動実行、中〜高リスクは人間承認を経由、極高リスクは禁止とします。承認の要否を操作ごとに動的に判定することで、安全性とスループットを両立させます。

解決する問題¶

エージェントが外部システムに副作用を持つ操作を実行できる場合（F8）、すべてを自動実行すれば不可逆な損害が発生しえますし、すべてに人間承認を求めれば待ち時間で業務が止まります。LLM はハルシネーションにより誤った操作を選択する可能性があり（F4）、かつエージェントシステムは本質的に人間との協働が前提です（F17）。

このパターンが無いと、以下のいずれかに陥ります：

全件承認：低リスクの読取操作にまで人間を介在させ、エージェントの価値（自動化による時短）が消失します。
全件自動：本番DBの削除やメール送信など取り消せない操作まで自動実行し、障害発生時の影響が甚大になります。
承認判断がプロンプト任せ：LLM に「危険だと思ったら聞いて」と指示しても、どの操作が危険かの判断自体が確率的でありすり抜けます。

選定条件（When to use / When NOT）¶

使う条件
- エージェントが書込・更新・削除・送信など副作用を伴う操作を実行できます。
- [reversibility] が操作によって異なります（読取は可逆だが送信は不可逆、など）。
- [failure_cost] が中〜高の操作が混在しており、一律のポリシーでは過剰か不足になります。
- 人間がレビューに関与できる運用体制があり、[latency_budget] に承認待ち時間を組み込めます。
使わない条件（＝代替に倒す）
- すべての操作が読取専用で副作用がない → C2 Read-Free / Write-Gated の Read-Free 側だけで十分です。
- [failure_cost] が一律に低く、すべての操作が容易にロールバック可能 → 承認なしの自動実行＋事後監査で済みます。
- [latency_budget] が極めて短く（数秒以内）人間介在を許容できない → ドライラン＋自動検証（C3）に倒します。

駆動変数とチューニング（程度）¶

目盛り	効かなすぎ ⇔ 効きすぎ	決め方 `[駆動変数]`	目安（出発点）
リスク層の閾値（auto/approval/forbidden の境界）	危険な操作が自動実行される ⇔ 安全な操作にも承認を要求しスループット低下	`[reversibility]` × `[failure_cost]` のマトリクスで機械的に分類	可逆＋低コスト=auto、不可逆 or 高コスト=approval、不可逆＋高コスト=forbidden
承認タイムアウト	無期限待ちでタスクが滞留 ⇔ 短すぎて承認者が間に合わない	`[latency_budget]` から逆算。SLA の概ね 50-70% を承認待ちに割り当て	対話型: 2-5分、バッチ型: 1-24時間
リスク評価の粒度	操作単位が粗すぎて高リスク操作を見逃す ⇔ 細かすぎて分類の維持コスト過大	`[failure_cost]` が高い領域ほど細かく分類する	ツール名 × パラメータの組み合わせ（例：delete は approval、read は auto）
承認者の多重度（何人に聞くか）	1人承認で見落とし ⇔ 多人数承認で待ち時間膨張	`[failure_cost]` が極めて高い操作ほど多重度を上げる	通常1人、金銭移動・本番変更は2人以上

相反における立ち位置（相反）¶

F-15 読取専用 vs 書込可能 → hybrid（Read自由・Writeはゲート）。本パターンはまさにこのハイブリッド戦略の実装であり、Read 操作は承認なしに自動実行し、Write 操作をリスクスコアで auto/approval/forbidden に仕分けます。[reversibility] が低い操作ほどゲートを厳しくします。

構造¶

flowchart TD
  Req[エージェントの操作要求] --> Classify[リスク分類エンジン]
  Classify -->|低リスク: auto| Exec[自動実行]
  Classify -->|中〜高リスク: approval| Queue[承認キュー]
  Classify -->|極高リスク: forbidden| Deny[拒否・ログ記録]
  Queue --> Human{人間レビュー}
  Human -->|承認| Exec
  Human -->|却下| Deny
  Human -->|条件付承認| Modify[パラメータ修正]
  Modify --> Exec
  Exec --> Log[実行結果 + 承認記録を監査ログ]
  Deny --> Log

実装メモ¶

リスク分類の最小実装（擬似コード）：

from enum import Enum
from dataclasses import dataclass

class RiskTier(Enum):
    AUTO = "auto"
    APPROVAL = "approval"
    FORBIDDEN = "forbidden"

@dataclass
class RiskPolicy:
    tool: str
    action: str
    reversibility: float   # 0.0（不可逆）〜 1.0（完全可逆）
    failure_cost: float     # 0.0（無害）〜 1.0（致命的）

def classify_risk(policy: RiskPolicy) -> RiskTier:
    risk_score = (1 - policy.reversibility) * policy.failure_cost
    if risk_score >= 0.7:
        return RiskTier.FORBIDDEN
    elif risk_score >= 0.3:
        return RiskTier.APPROVAL
    else:
        return RiskTier.AUTO

リスクポリシーの設定例（YAML）：

risk_policies:
  - tool: database
    action: select
    reversibility: 1.0
    failure_cost: 0.0
    tier: auto
  - tool: database
    action: update
    reversibility: 0.6      # WHERE句次第で部分復旧可能
    failure_cost: 0.5
    tier: approval
  - tool: database
    action: drop_table
    reversibility: 0.0
    failure_cost: 1.0
    tier: forbidden
  - tool: email
    action: send
    reversibility: 0.0      # 送信後の取消不能
    failure_cost: 0.4
    tier: approval

落とし穴：

リスク分類自体を LLM に任せないでください。分類は決定論的な殻（B1）の責務です。ツール名×アクション名の静的テーブルか、ポリシーエンジン（E2）で判定します。
承認待ちの状態を永続化してください。承認キューに入った操作は耐久的な非同期セッション（A2）で状態を保持し、プロセス再起動でも消失しないようにします。
承認タイムアウト後のデフォルトを安全側に倒してください。タイムアウトしたら自動承認ではなく自動却下にします。
条件付き承認を設計に含めてください。承認者が「金額を1万円以下に修正して実行」のようにパラメータを変更して承認できると、却下→再提案のラウンドトリップを減らせます。

段階的自律性（Autonomy Ladder）¶

リスクベース承認の閾値を固定ではなく、エージェントの実績に応じて動的に調整する仕組みが段階的自律性です。運転免許のように信頼を獲得し昇格する一方、違反時には降格します。

自律性レベル L0〜L6¶

エージェントの自律性を以下の7段階で定義します。

Lv	名前	できること
L0	Suggest only	提案のみ、実行なし
L1	Read-only	読み取りツールのみ実行可能
L2	Draft	下書き作成（保存は人間が行う）
L3	Dry-run	実行計画と差分を提示
L4	Approval required	人間承認後に実行
L5	Bounded auto-execute	低リスク範囲で自動実行（金額上限等の制約付き）
L6	Full autonomous	広範な自動実行（限定環境のみ推奨）

[failure_cost] が高い操作カテゴリほど低いレベルから開始し、[reversibility] が低い操作ほど上位レベルへの昇格条件を厳しくします。

昇格条件¶

昇格には以下の条件をすべて満たす必要があります。

成功率：直近 N 回の操作（概ね 50〜200 回）で 95〜99% 以上の成功率を達成していること。[failure_cost] が高いほど閾値を上げます。
ポリシー違反ゼロ：直近 M 日間（概ね 7〜30 日）にポリシー違反がないこと。
冷却期間：前回の昇格から概ね 7〜14 日が経過していること。短期間の連続昇格を防ぎ、十分な検証期間を確保します。

降格トリガー¶

以下の条件で即時または猶予期間後に降格します。

ポリシー違反：即時1段階降格します。[reversibility] が低い操作での違反は2段階降格も検討します。
モデル変更：新モデルは挙動が異なる可能性があるため、初期レベルにリセットするか1段階降格します。昇格実績は旧モデルに紐づくものです。
異常検知：エラー率が閾値（概ね 10%）を超過した場合、猶予期間（24〜72 時間）の後に降格を判定します。

カテゴリ別の独立管理¶

自律性レベルは操作カテゴリごとに独立して管理します。たとえば「メール送信=L5、DB更新=L2、決済=L4」のように、ひとつのカテゴリでの高実績が別カテゴリの信頼を保証するわけではありません。カテゴリ分類は [failure_cost] × [reversibility] のマトリクスに基づいて設計します。

本パターンとの連携¶

リスクベース承認の auto/approval/forbidden の境界線を、現在の自律性レベルに応じて動的に調整します。たとえば L4 ではすべての書込操作に承認を要求しますが、L5 に昇格すれば低リスクの書込は自動実行に移行します。昇格/降格の判定は決定論的なルールエンジンで行い、LLM に任せません。

効かせる力学（forces）¶

F4（ハルシネーション）：LLM が誤った操作を選択しても、高リスク操作は必ず人間承認を経由するため、ハルシネーションによる不可逆な損害を防止できます。
F8（ツール副作用）：副作用の危険度をリスクスコアで定量化し、ゲートの厳しさを段階的に制御します。すべての副作用を一律に扱うのではなく、影響度に応じた最小限の摩擦を入れます。
F17（人間協働）：人間の関与を「全件」でも「ゼロ」でもなく、リスクに応じて適切な頻度に調整します。人間は高リスク判断に集中でき、低リスク作業はエージェントに任せられます。

コーディングエージェント向け指示（machine-actionable）¶

このパターンを人間に提案するなら、同時に以下を提案/確認してください：

[ ] [reversibility] と [failure_cost] を操作ごとに評価し、3層（auto/approval/forbidden）のマッピング表を具体化したか
[ ] 承認待ちの状態保持に A2 耐久非同期エージェントを併置したか
[ ] リスク分類を決定論的コード（B1 の殻）で実装し、LLM に分類判断を委ねていないか
[ ] approval 層に C3 ドライランを組み合わせ、承認者に予測結果を提示する設計にしたか
[ ] 承認タイムアウト後のデフォルト動作を安全側（自動却下）に設定したか
[ ] 監査ログを G1 二層観測に流す設計を含めたか
[ ] 目盛り（上表）の値を [駆動変数] から導き、理由を添えて提示したか
[ ] 将来的な閾値の動的調整が必要なら本パターンの段階的自律性（Autonomy Ladder）の採用を検討したか