有界自律性：コンシューマー側の型付きアクションコントラクトがエンタープライズソフトウェアにおける大規模言語モデルのエラーを防ぐ

問題は何か？

エンタープライズソフトウェアにおいて——CRM、ERP、内部ツール、カスタマーサポートプラットフォーム——AI エージェントはますます結果を伴うアクションを実行しています：レコードの更新、メールの送信、ワークフローのトリガー、異なるクライアントワークスペースへのアクセス。大規模言語モデル (LLM) がセキュリティ境界を突破するような方法でエラーを起こすと問題が生じます：

• 未承認のアクション — エージェントがユーザーにパーミッションのない機能を実行する
• 不正な形式のリクエスト — ツール呼び出しの構造が期待されるフォーマットに違反し、API が壊れる
• クロスワークスペース実行 — マルチテナント環境で、エージェントが別のクライアントのデータに触れる
• 未承認のエスカレーション — エージェントがユーザーが承認したよりも高い特権レベルを必要とするツールを使用する

古典的な解決策は「モデルをより良く訓練する」か「プロンプトにガードレールを追加する」です。どちらも確率論的です——モデルはまだエラーを起こす可能性があり、ただその頻度が低いだけです。エラーが GDPR 違反やクライアントの信頼喪失を意味しうるエンタープライズ環境では、それでは不十分です。

論文が提案する解決策

2026 年 4 月 17 日に arXiv で発表されたこの論文は、モデルの外に決定論的レイヤーを提案します：

• 型付きアクションコントラクトは、エージェントがどのアクションを実行できるか、どの引数で、どのコンテキストで、どの前提条件の下でを明示的に定義します
• コンシューマー側実行とは、大規模言語モデル (LLM) がアクションを直接実行しないことを意味します——モデルは構造化されたアクションリクエストを生成し、コンシューマーアプリケーションが実行前に型コントラクトに対して検証します
• リクエストが型チェックを通過しない場合（型の誤り、パーミッションの欠如、ワークスペースの誤り）、アクションは発生しません——大規模言語モデル (LLM) が何を「考えた」かに関わらず

アーキテクチャ的に、これはセキュリティの負担を確率論的なモデルから決定論的な型システムに移します——ランタイムの祈りではなく静的チェック。

実際にはどのように見えるか？

著者はエンタープライズ環境からの具体的な例を示します：

例 1 — ワークスペース分離：

UpdateCustomerRecord(customerId: CustomerId, fields: CustomerFields)
  requires: caller.workspace == customer.workspace

大規模言語モデル (LLM) が別のワークスペースの顧客を更新しようとすると、型システムが実行前に拒否します。

例 2 — 特権：

SendExternalEmail(to: EmailAddress, body: String)
  requires: caller.permissions.includes(SEND_EXTERNAL)

モデルは完璧なメールを作成できます——ユーザーに SEND_EXTERNAL パーミッションがなければ、アクションは静的に失敗します。

例 3 — セマンティック制約：

DeleteRecord(id: RecordId)
  requires: record.createdBy == caller || caller.isAdmin

モデルは合理的に思えても、他人のレコードを削除できません。

なぜこれはプロンプトエンジニアリングより良いのか？

• プロンプトエンジニアリングはモデルが指示を読んで遵守することに依存しています。モデルが境界ケースを解釈したり、誤って制約を違反したりする可能性は常にあります。
• 型コントラクトはコンパイラレベルのチェックです。モデルの動作に依存しません。正しく定義されていれば、カバーするエラーのクラスは不可能です。

トレードオフは実装の複雑さです。型システムは実際のシナリオをカバーしながら過度に硬直しないよう慎重に設計される必要があります。論文はいくつかのエンタープライズドメイン（セールス、サポート、HR）からの例を含み、実際に実行可能であることを示しています。

AI ツール構築への影響

エンタープライズ AI 統合を構築する開発者にとって、論文は具体的な設計パターンを提供します：

1. エージェントが実行できるすべてのアクションを明示的に定義する
2. 各アクションに前提条件を持つ型コントラクトを書く
3. モデルが直接実行するのではなく、構造化されたアクションリクエストを生成させる
4. 検証は副作用の前に決定論的な型チェッカーを通過させる

このアプローチは、構造化されたツール呼び出しを自由な実行よりも推進する MCP（モデルコンテキストプロトコル）のトレンドと一致しています。MCP と組み合わせることで、MCP と型コントラクトの両方が異なるクラスのエラーをブロックする多層防御が実現します。

本論文はプレプリントですが、アイデアは十分に具体的で、現在エンタープライズ AI を構築しているチームは正式な査読付き出版を待たずに今すぐ原則を適用できます。