自律性レベル¶
このダイヤルは何か¶
自律性レベルは、エージェントがどこまでの操作を人間の介在なしに自動実行できるかを制御するダイヤルです。L0(提案のみ)からL6(完全自律)までの7段階があり、エージェントの信頼性と操作のリスクに応じて段階的に権限を広げたり狭めたりします。
AIエージェントシステムにおいて、自律性は「有か無か」の二値で設計するものではありません。ツール呼び出しが副作用を持つ(F8)以上、完全自動と完全手動の間に広大なグラデーションがあります。読取操作は自動で行わせつつ、本番データベースへの書込は承認を求め、決済操作は完全に禁止する、というように操作カテゴリごとに異なるレベルを設定するのが現実的です。
さらに重要なのは、自律性レベルは固定ではなく、実績に基づいて昇格・降格する動的な値であるということです。運転免許のように、信頼を獲得すればより高い自律性を与え、違反があれば降格させます。この動的な調整を行わないと、初期に保守的すぎるレベルを設定した場合はいつまでも人間が承認ボトルネックになり、逆に最初から高い自律性を与えた場合は障害時のダメージが大きくなります。
効かなすぎる害 ⇔ 効きすぎる害¶
効かなすぎる害(自律性レベルが低すぎる)¶
自律性を過度に制限すると、エージェント導入の価値が失われます。
- すべての操作に人間の承認を求めると、エージェントは「自動で動く」のではなく「提案書を作る」だけのツールに成り下がります。人間が1件ずつ承認する時間は手作業と変わらず、自動化の効果がゼロになります
- 読取操作(データベースのSELECT、検索API呼び出し)にまで承認を求めると、エージェントが情報を集めるだけで数十分かかります
- 開発者がエージェントに頼らず手動で作業する方が速いと判断し、エージェントが使われなくなります
- 承認が形骸化します。低リスクの操作に対して繰り返し承認を求められると、承認者はいちいち内容を確認せず機械的に承認するようになり(承認疲れ)、本当に重要な承認が見落とされます
効きすぎる害(自律性レベルが高すぎる)¶
自律性を過度に開放すると、被害半径が拡大します。
- ハルシネーション(F4)により、エージェントが存在しない顧客に請求書を送信したり、誤ったデータでデータベースを更新したりします
- 本番環境のデータを破壊する操作が自動実行され、発覚したときには手遅れです
- セキュリティ上の攻撃面が拡大します。プロンプトインジェクション(F14)で操作を注入された場合、高い自律性レベルのエージェントほど大きな被害を出します
- エラーが連鎖します。誤った操作の結果を基に次の操作が行われ、被害が雪だるま式に拡大します
決め方¶
このダイヤルは [reversibility](可逆性)と [failure_cost](失敗コスト)の2つの駆動変数を軸に決めます。
自律性レベルの定義(L0〜L6)¶
| Lv | 名前 | できること |
|---|---|---|
| L0 | Suggest only | 提案のみ、一切の実行なし |
| L1 | Read-only | 読み取りツールのみ実行可能 |
| L2 | Draft | 下書き作成(保存・送信は人間が行う) |
| L3 | Dry-run | 実行計画と差分を提示(実行はしない) |
| L4 | Approval required | 人間承認後に実行 |
| L5 | Bounded auto-execute | 低リスク範囲で自動実行(金額上限等の制約付き) |
| L6 | Full autonomous | 広範な自動実行(限定環境のみ推奨) |
操作カテゴリごとに分ける¶
1つのエージェントに一律のレベルを設定するのではなく、操作カテゴリごとに異なるレベルを設定します。
- 読取操作(検索、参照、分類)→ 自動(L1以上)
- 可逆な書込操作(下書き保存、ステージング環境への変更)→
[failure_cost]に応じて L4 または L5 - 不可逆な書込操作(本番データ変更、メール送信、決済)→ 常に承認(L4)、またはドライランのみ(L3)
実績に基づく動的調整¶
初期レベルは保守的に設定し、実績に応じて昇格・降格させます。
昇格条件の目安:
- 直近50〜200回の操作で95〜99%以上の成功率
- 直近7〜30日間にポリシー違反ゼロ
- 前回の昇格から7〜14日以上の冷却期間
降格トリガー:
- ポリシー違反の検出 → 即時1段階降格
- モデル変更 → 初期レベルにリセットまたは1段階降格
- エラー率の異常上昇(概ね10%超過)→ 猶予期間(24〜72時間)後に降格判定
目安値(出発点)¶
| 操作カテゴリ | 初期レベル | 昇格先 | 条件 |
|---|---|---|---|
| 読取(検索・参照) | L1 (Read-only) | L5 (自動) | 読取は原則自動でよい |
| 可逆な書込(下書き・ステージング) | L4 (承認必要) | L5 (自動) | 成功実績50回以上 |
| 不可逆な書込(本番変更・送信) | L3 (Dry-run) | L4 (承認必要) | 成功実績200回以上、ポリシー違反ゼロ |
| 決済・金銭移動 | L3 (Dry-run) | L4 (承認必要) | [failure_cost] が極めて高いためL5以上への昇格は慎重に |
| 開発環境・サンドボックス | L5 (自動) | L6 (完全自律) | 影響範囲が限定されているため |
L6(完全自律)は、影響範囲が完全に限定された環境(サンドボックス、個人の開発環境、テスト環境)でのみ許容するのが安全です。本番環境でのL6は、極めて高い信頼性が検証され、かつ影響範囲がfailure_costで制限されている場合に限ります。
具体的なシナリオ¶
シナリオ1:社内ナレッジ検索アシスタント¶
社内文書を検索し、質問に回答するエージェントです。
- 検索操作(Confluence、Slack、Drive): L5(自動実行)
- 回答生成: L5(自動実行、ただし出力ガードレールで機密情報漏洩をチェック)
- 文書の編集・更新: L4(承認必要)
- 文書の削除: L3(ドライランのみ)
読取操作が中心のため、高い自律性レベルで運用できます。ただし機密文書へのアクセス制御は別途必要です。
シナリオ2:ECサイトの受注処理エージェント¶
注文の確認、在庫チェック、発送手配を行うエージェントです。
- 注文情報の参照: L5(自動実行)
- 在庫の確認: L5(自動実行)
- 発送手配(可逆): L4(承認必要、ただし信頼獲得後にL5に昇格可能)
- 返品処理: L4(承認必要)
- 返金処理(不可逆): L4(常に承認必要、L5への昇格は慎重に)
- 大口注文の処理(高額): L3(ドライランのみ、金額閾値を超える場合)
[failure_cost] がカテゴリごとに大きく異なるため、きめ細かいレベル設定が重要です。
シナリオ3:開発支援エージェント(CI/CD連携)¶
コードレビュー、テスト実行、デプロイメントを支援するエージェントです。
- コード読み取り・分析: L6(完全自律、開発環境限定)
- テスト実行(サンドボックス): L6(完全自律)
- PR作成・コメント: L5(自動実行、レビュアーがいるため二重チェックあり)
- ステージングへのデプロイ: L4(承認必要)
- 本番へのデプロイ: L3(ドライラン → 人間が手動でデプロイ)
サンドボックス環境ではL6まで許容できますが、本番環境への影響がある操作は制限が必要です。
実践的なアドバイス¶
-
自律性レベルの判定は決定論的なルールエンジンで行ってください。LLMに「危険だと思ったら聞いて」と指示するのは機能しません。どの操作がどのレベルかの判定自体が確率的では、ガバナンスとして成立しません。ツール名×アクション名の静的テーブルか、E2 ポリシーのコード化で管理します。
-
「全件承認」は「承認なし」と同じくらい危険です。低リスク操作に承認を求め続けると承認疲れが発生し、承認者は内容を確認せずにOKを押すようになります。結果として、高リスク操作の承認も形骸化します。リスクに応じたメリハリが重要です。
-
モデルを変更したら自律性レベルをリセットしてください。新しいモデルは旧モデルと異なる失敗パターンを持つ可能性があります。旧モデルでの実績は新モデルの信頼性を保証しません。モデル変更時は初期レベルに戻すか、少なくとも1段階降格させます。
-
カテゴリごとに独立して管理してください。「メール送信でL5を獲得した」からといって「決済でもL5にする」のは危険です。各カテゴリの
[failure_cost]と[reversibility]は異なるため、昇格実績は操作カテゴリに紐づきます。 -
昇格・降格のログを必ず残してください。「いつ、なぜ、どのカテゴリで」レベルが変わったかの履歴は、監査(
[accountability])とデバッグの両方で役立ちます。
関連パターン¶
- E1 リスクベース人間承認 — 自律性レベルの実装パターンです。操作のリスクスコアに基づいてauto/approval/forbiddenを振り分け、段階的自律性(Autonomy Ladder)で動的に調整する仕組みを詳述しています。
- C2 Read-Free / Write-Gated — 読取と書込の権限分離の基盤パターンです。自律性レベルの「L1 Read-only」の実装に直接対応します。
- C3 ドライラン/コミット — 自律性レベル「L3 Dry-run」の実装パターンです。実行計画を提示して人間の確認を得る仕組みです。
- E2 ポリシーのコード化 — 自律性レベルの判定ルールをポリシーエンジンで管理し、デプロイなしにルール変更を反映する仕組みです。
- B1 決定論的な殻 — 自律性レベルの判定を殻(決定論的な制御層)の責務として配置します。