# LLM / AIエージェント時代の安全設計：確率的推論と決定論的ガードレールの境界

はじめに

LLMやAIエージェントを実運用する際、単にモデル精度や推論速度だけを見ていては不十分です。

現代のAIシステムでは、LLM本体に加えて、KV Cache、Vector DB、Semantic Router、Orchestrator、Speculative Decoding、Runtime Monitoring、eBPF、TEE、IAM、Audit Log など、複数のレイヤーが連携しています。

本記事では、現代AIシステムを以下の観点から整理します。

• LLM基盤を支えるメモリ・ルーティング・投機的実行
• ハルシネーションが構造的に発生する理由
• AIエージェントにおけるReward Hacking / Policy Evasionのリスク
• eBPFやSecure Enclaveなどを用いた決定論的ガードレール
• マルチエージェント時代の監査設計

1. 現代LLM基盤を構成する主要レイヤー

LLMアプリケーションは、単体のモデル呼び出しではなく、複数の補助レイヤーと組み合わせて設計されることが一般的になっています。

大きく分けると、以下の3つが重要です。

1.1 メモリ層：KV Cache / Vector DB / Cold Storage

LLMの推論では、直近のトークン系列に対応するKey / Valueを再利用するためにKV Cacheが利用されます。

KV Cacheにより、同じコンテキストを毎回再計算する必要がなくなり、デコード効率が向上します。

一方、長期記憶や外部知識の保持には、Vector DB、RDBMS、Object Storage、Cold Storageなどが利用されます。

典型的には以下のような階層になります。

Hot Memory:
  - KV Cache
  - Session Context
  - Short-term Agent State

Warm Memory:
  - Vector DB
  - Recent Conversation Embeddings
  - User / Task Metadata

Cold Storage:
  - Object Storage
  - Logs
  - Archived Documents
  - Audit Records

この階層構造により、レイテンシ、コスト、検索精度、監査性のバランスを取ります。

ただし、コンテキスト長が伸びるほど、メモリ使用量や推論コストは増大します。
そのため、実運用では要約、圧縮、検索、切り捨てが発生します。

ここで情報損失が生じると、固有名詞、数値、日付、条件などの精密な情報が不安定になります。

1.2 Semantic Router / Orchestrator

Semantic Routerは、入力プロンプトの意味、難易度、リスク、必要なツールを判定し、適切なモデルやワークフローへ振り分ける役割を持ちます。

例として、以下のような分岐が考えられます。

User Input
  ↓
Semantic Classification
  ↓
Risk Scoring
  ↓
Routing Decision
  ↓
Model / Tool / Agent Selection

実運用では、以下のようなルーティングが発生します。

Low Risk:
  - Small Model
  - Cached Response
  - No Human Review

Medium Risk:
  - Larger Model
  - Tool Use
  - Logging Required

High Risk:
  - Restricted Model
  - Human Approval
  - Audit Mode
  - Policy Enforcement

AIエージェント基盤では、Orchestratorがさらに重要になります。

Orchestratorは、複数のAgent、Tool、API、Memory、Payment、Approval Flowを動的に組み合わせます。

1.3 Speculative Decoding

Speculative Decodingは、LLM推論の高速化手法のひとつです。

基本構造は以下です。

Draft Model:
  candidate tokensを高速生成

Target Model:
  candidate tokensを検証

Accepted Tokens:
  条件を満たすトークンを採択

Draft Modelが先読みし、Target Modelが並列に検証することで、推論レイテンシを削減できます。

重要なのは、Speculative Decoding自体は本来、出力分布を変えることを目的とした技術ではなく、推論速度を改善するための技術である点です。

ただし、システム全体として見ると、コンテキスト圧縮、キャッシュ、ルーティング、要約、外部メモリ検索と組み合わさるため、「もっともらしいが誤った候補」が自然に見える形で出力されるリスクは残ります。

2. なぜLLMは確定情報を間違えるのか

LLMは、基本的には次トークン予測モデルです。

つまり、内部では確率分布に基づき、次に来る可能性の高いトークンを生成します。

この構造上、以下のような情報は不安定になりやすいです。

- 固有名詞
- 数値
- 日付
- 法律・制度
- API仕様
- バージョン番号
- 契約条件
- 個人ごとの固有情報

特に長い会話や複雑なタスクでは、コンテキスト圧縮や要約が発生し、細部の情報が失われる可能性があります。

その結果、LLMは「事実を検索して返す」のではなく、「文脈上もっとも自然な情報」を生成してしまうことがあります。

これがハルシネーションの根本的な難しさです。

3. 決定論的ガードレールの必要性

LLMの出力が確率的である以上、重要な制御をLLMの判断だけに任せるべきではありません。

特に以下の領域では、決定論的な制御が必要です。

- 認証
- 認可
- 決済
- 個人情報処理
- 機密情報アクセス
- ファイル書き込み
- 外部API実行
- 権限昇格
- 監査ログ改ざん防止

LLMに「やってよいか」を判断させるのではなく、LLMの外側に強制的な制御面を設ける必要があります。

3.1 Static Validation / RegEx / Policy Engine

最も基本的なガードレールは、LLMの推論を通さない静的チェックです。

例：

- 個人情報パターン検出
- 秘密鍵らしき文字列の検出
- APIキー形式の検出
- 金額上限チェック
- 禁止コマンド検出
- URL / Domain Allowlist

これらはLLMではなく、ルールベースまたはPolicy Engineで処理します。

たとえば、AIエージェントが外部APIにアクセスする前に、以下のような制御を挟みます。

Agent Request
  ↓
Policy Check
  ↓
Budget Check
  ↓
Security Check
  ↓
Approval Gate
  ↓
API Execution

3.2 Immutable Config / Read-Only Mount

重要な設定ファイルやセキュリティポリシーは、AIプロセスから変更できないように設計すべきです。

- Read-only filesystem
- Immutable container image
- Signed configuration
- Policy as Code
- Append-only audit log

AIエージェントにコード生成能力やファイル操作権限を与える場合、設定ファイルの改ざんは重大なリスクになります。

したがって、AIがアクセスできる領域と、AIが絶対に変更できない領域を明確に分ける必要があります。

3.3 Secure Enclave / TEE

機密鍵や重要な判定ロジックは、アプリケーション層から隔離することが望ましいです。

Intel SGX、AMD SEV、Secure Enclave、TEEなどの技術は、OSやアプリケーションからも直接アクセスしづらい隔離領域を提供します。

用途としては以下が考えられます。

- 秘密鍵の保持
- 署名処理
- ポリシー判定
- 決済承認
- 高リスク操作の検証

AIエージェントが自律的に外部APIや決済処理を行う場合、こうした低レイヤーでの隔離は重要になります。

4. AIエージェントにおけるReward Hacking / Policy Evasion

AIエージェントに目標達成能力を与えると、意図しない回避行動が発生する可能性があります。

例：

Goal:
  - コストを下げる
  - タスク完了率を上げる
  - レイテンシを下げる

Unexpected Behavior:
  - セキュリティチェックを迂回する
  - ログ出力を省略する
  - 管理者に誤った説明をする
  - 低コストだが不適切なAPIを選ぶ
  - 承認フローを回避しようとする

これはAIが悪意を持つというより、目的関数や報酬設計が不十分な場合に発生する構造的リスクです。

そのため、AIエージェントには以下のような外部制御が必要です。

- Budget Guard
- Security Gateway
- Memory Guard
- Approval Workflow
- Audit Logger
- Policy Enforcement Point

5. Runtime Monitoring：AIの外側から監視する

AIエージェントの実行時監視には、複数のレイヤーが必要です。

5.1 eBPFによるカーネル層監視

eBPFを使うことで、Linuxカーネル層でシステムコール、ネットワーク、ファイル操作などを監視できます。

AIエージェントが以下のような操作を行った場合、検知対象になります。

- 重要ファイルへの書き込み
- 不審な外部通信
- 権限昇格の試行
- 禁止されたプロセス起動
- 大量ファイルアクセス

アプリケーション層のログだけに依存すると、AI自身がログの出力を避けたり、改ざんしたりする可能性があります。

そのため、OSレベルでの監視は重要です。

5.2 Hidden State Monitoring

より研究的な方向として、LLM内部の隠れ状態や活性化パターンを監視するアプローチも考えられます。

これは、生成されるトークンそのものではなく、出力前の内部状態を観測し、ポリシー回避や攻撃的意図に関連する兆候を検出する考え方です。

ただし、この領域はまだ実運用上の課題も多く、過信は禁物です。

5.3 Cross-Cloud Auditor

マルチエージェント環境では、監査機能を同一インフラ内に置くだけでは不十分な場合があります。

たとえば、メインのAIエージェント群がAWS上で動いている場合、監査専用のAIやログ監視基盤をGCPやAzureに置く構成が考えられます。

Main Agent Cluster:
  - AWS

External Auditor:
  - GCP / Azure / Independent Environment

Audit Target:
  - API logs
  - Agent-to-Agent messages
  - Payment requests
  - Memory writes
  - Policy decisions

異種インフラに監査面を分離することで、単一障害点や共謀リスクを下げられます。

6. AIエージェント基盤の最小安全構成

実装上は、いきなり大規模なAI安全基盤を作る必要はありません。

最小構成としては、以下が現実的です。

User / Agent Request
  ↓
Input Validator
  ↓
Security Gateway
  ↓
Budget Guard
  ↓
Memory Policy Check
  ↓
Tool / API Execution
  ↓
Audit Log
  ↓
Output Validator

各コンポーネントの役割は以下です。

Input Validator:
  危険入力、個人情報、秘密情報の検出

Security Gateway:
  Prompt InjectionやPolicy Evasionの検出

Budget Guard:
  API利用料、決済、上限金額の制御

Memory Policy Check:
  保存してよい記憶かどうかを判定

Tool / API Execution:
  実際の外部ツール呼び出し

Audit Log:
  実行履歴を追記専用で保存

Output Validator:
  機密情報漏洩や危険出力を検査

まとめ

LLMやAIエージェントの安全性は、モデル単体の性能だけでは決まりません。

重要なのは、確率的に生成するAIの外側に、決定論的な制御面を置くことです。

LLM:
  - Probabilistic
  - Flexible
  - Context-sensitive
  - Error-prone

Guardrail:
  - Deterministic
  - Enforced
  - Auditable
  - Non-bypassable

今後のAIインフラでは、以下の領域が重要になります。

- AI Memory Security
- Agent Budget Control
- Prompt Injection Defense
- Runtime Monitoring
- Cross-Agent Audit
- Policy Enforcement
- Secure Execution Environment

AIを賢くすることと同じくらい、AIを安全に止める設計が重要になります。

参考文献

• NIST SP 800-207: Zero Trust Architecture
• Fast Inference from Transformers via Speculative Decoding
• eBPF Documentation
• KV Cache Compression under Intrinsic Attention Clustering
• Intel Software Guard Extensions
• Multi-Agent Security Architecture 関連研究