論文要約：Bounded Autonomy for Enterprise AI: Typed Action Contracts and Consumer-Side Execution

この論文は、大規模言語モデル（LLM）を企業ソフトウェアの自然言語インターフェースとして利用する際の安全性と信頼性に関する課題を提起し、**「制約された自律性（Bounded Autonomy）」**というアーキテクチャを提案しています。著者らは、LLM の誤動作を防止する鍵はモデルの品質向上ではなく、実行アーキテクチャの設計にあると主張しています。

以下に、問題定義、手法、主要な貢献、結果、および意義について詳細にまとめます。

1. 問題定義 (Problem)

企業環境において LLM をシステムオペレーターとして直接使用することには重大なリスクが伴います。

• リスク: モデルの誤り（ハルシネーション、エンティティの混同、権限の過大評価など）が、不正な実行、不正なデータ変更、クロスワークスペースの漏洩、あるいは取り返しのつかないビジネス変更といった、運用コストのかかる失敗に直結する可能性があります。
• 現状の課題: 多くの既存の AI ツール利用設計は、プロンプトエンジニアリングや事後の監視に依存しており、モデルが「生の実行（raw execution）」に近すぎる状態を放置しています。
• 核心的な問題: 企業システムは権限に敏感で、状態を持ち、マルチテナントであり、業務結果に直結するため、LLM の不確実性をそのまま実行させることは許容されません。

2. 手法とアーキテクチャ (Methodology & Architecture)

著者は、LLM を「意図の解釈者」としては活用しつつも、「直接の実行者」としては信頼しない**「制約された自律性（Bounded Autonomy）」**アーキテクチャを提案しました。このアーキテクチャの中核は、BAL (Bounded Autonomy Layer) です。

主要な設計原則と構成要素

1. タイプド・アクション・コントラクト (Typed Action Contracts):
   • 企業操作は、生の実行 affordance ではなく、構造化された「アクション契約」として公開されます。
   • 各契約には、入力スキーマ、権限条件、バリデーション論理、実行コールバック、結果のセマンティクスが定義されています。
2. 権限を考慮した機能公開 (Permission-Aware Capability Exposure):
   • BAL のオーケストレーションエンジンが参照するアクション一覧は静的ではなく、現在のユーザーの権限に基づいて動的にフィルタリングされます。
   • ユーザーが実行権限を持たないアクションは、モデルに提示されません。
3. 消費者側の実行境界 (Consumer-Side Execution Boundary):
   • 実行権限は常に企業アプリケーション（消費者側）が保持します。
   • BAL はバックエンドに直接アクセスせず、消費者が定義したサービスや API ルートを通じて実行を仲介します。これにより、既存のビジネスロジック、監査、データ境界が維持されます。
4. 副作用前のバリデーション (Validation Before Side Effects):
   • 実行前に、ドメインスキーマに基づいた厳格なバリデーションが行われます。
   • 不正なペイロードは、副作用が発生する前に構造化されたエラーとして返却され、モデルに修正を促します。
5. 曖昧性の明示的処理 (Explicit Ambiguity Handling):
   • エンティティの解決が曖昧な場合（例：同名の顧客が複数いる）、モデルが推測して実行するのではなく、ユーザーに明確化を要求する状態へ遷移します。
6. 承認ゲート (Confirmation Gates):
   • 高リスクまたは多段階のワークフローについては、実行前に人間の承認を必須とするゲートが設けられます。
7. マニフェスト・ガバナンス (Manifest Governance):
   • 実行可能な機能は、明示的に公開された「アクションマニフェスト」に基づいてのみ決定されます。

防御の多層化 (Defense-in-Depth)

• BAL レイヤー (D1-D3): 権限フィルタリング、バリデーション、承認ゲート。これらは BAL によって実装され、どの企業アプリでもポータブルです。
• 消費者側レイヤー (D4-D6): バックエンドの権限チェック、スコープ強制、ドメインサービスによる検証。これらは企業アプリ固有の防御層です。
• 特徴: BAL は消費者側のレイヤーをバイパスせず、それらを経由して実行するため、既存のセキュリティ保証も維持されます。

3. 主要な貢献 (Key Contributions)

1. 設計原則の定義: 企業 AI における「制約された自律性」の概念を確立し、モデルを「プランナー/解釈者」として、バックエンドの「信頼されたオペレーター」としては扱わない設計指針を示しました。
2. BAL の提案と実装: 任意の企業アプリケーションに統合可能なポータブルな AI 仲介層（BAL）を設計・実装しました。これにより、タイプド契約、権限フィルタリング、バリデーション、承認ゲートが強制されます。
3. 実運用環境での評価: マルチテナントの企業アプリケーション（CRM/クライアント管理）にこのアーキテクチャを実装し、実データ上で評価を行いました。
4. 実証的評価: 手動作業、制約なしの AI（安全層無効化）、完全な制約された自律性の 3 つの条件で比較評価を行いました。

4. 評価結果 (Results)

25 件のシナリオ（7 つの失敗ファミリー）を用いた実験結果は以下の通りです。

• 安全性 (Safety):

  • 制約された自律性 (Condition C): 25 件中 23 件のタスクを完了し、不正な実行（Unsafe Execution）は 0 件でした。完了しなかった 2 件も、エンタープライズへの副作用なしに安全に封じ込められました。
  • 制約なし AI (Condition B): 25 件中 17 件しか完了しませんでした。8 件の失敗のうち、2 件は「誤ったエンティティへの書き換え」という深刻な不正実行として企業データに反映されました。
  • 重要な発見: 消費者側のバックエンド権限チェックは多くの不正を捕捉しましたが、「ユーザーに実行権限があり、ペイロードも構造的に正しいが、ターゲットエンティティが間違っている」というケース（Wrong-entity mutations）は、BAL の曖昧性解消と承認メカニズムがないと捕捉できませんでした。

• 有用性 (Utility):

  • タスク完了率: 制約された自律性 (92%) は、制約なし AI (68%) よりも高いタスク完了率を示しました。
  • 速度: 手動作業と比較して、両方の AI 条件で 13〜18 倍の高速化が達成されました。
  • 逆説的な発見: 安全レイヤーを削除すると、タスク完了率が低下しました。これは、構造化されたバリデーションフィードバックがモデルに正しい結果を導くための修正を促し、試行錯誤を減らしたためです。安全レイヤーは単なる制約ではなく、モデルの自己修正を支援する機能として機能しました。

• 防御の多層化:

  • 制約された環境では、すべての失敗が BAL レイヤー（D1-D3）で捕捉されました。
  • 制約なし環境では、捕捉が消費者側レイヤー（D4-D6）にシフトしましたが、2 件の重大な失敗がすべての層をすり抜けてしまいました。

5. 意義と結論 (Significance & Conclusion)

• パラダイムシフト: 企業 AI の安全性は、モデルの能力向上やプロンプト改善の問題ではなく、実行アーキテクチャの問題であるという視点を確立しました。
• 安全と有用性の両立: 一般的に「安全性と有用性はトレードオフ」と考えられがちですが、この研究では、適切なアーキテクチャ的制約（構造化フィードバックなど）が導入されることで、安全性が向上すると同時に、タスク完了率も向上することを実証しました。
• 実用的なアプローチ: 不完全な LLM を企業システムで安全に運用するための具体的な実装パターン（タイプド契約、消費者側実行、マニフェスト管理）を提供しました。
• 将来性: このアーキテクチャはモデルに依存せず、LLM の能力が向上しても、あるいは異なるモデルに置き換わっても、安全性の保証は維持されます。

結論として:
この論文は、LLM の不確実性を組織的な損害に変えないための、実証済みの実用的なアーキテクチャを提示しています。「制約された自律性」は、モデルの自由度を制限するのではなく、企業システムにおける制御、検証、コンテキストの境界を第一級の関心事として扱うことで、AI を企業環境で信頼性高く運用可能にする道筋を示しています。