前の記事では、OpenAIの2026年のサイバー事例から、AIエージェントの境界を考えました。
ただ、ここで自分の仮説に都合のよい事例だけ集めても意味がありません。
そこで今回は、反証になりそうな一次資料を優先して、OpenAI、Anthropic、Google DeepMind、MicrosoftがAgent Safetyをどう実装しようとしているのかを比較します。
先に結論を書くと、
「Big TechはAIをsandboxへ閉じ込めているだけ」という理解は、すでに正確ではない。
かなり先まで進んでいます。
一方で、他者との関係が変化したとき、Agent自身が責任境界そのものを再構成する設計は、今回確認した公開一次資料では明示的には確認できませんでした。
この記事では、その差をエンジニア向けに分解します。
比較する前に、境界の置き方を6種類に分ける
Agent Safetyを「安全機能があるか」だけで比べると、全部同じに見えます。
そこで、境界をどこで作るかによって分類します。
1. Containment
AIが物理的・技術的に到達できる範囲を狭めます。
Sandbox
VM
Network isolation
Egress control
Filesystem isolation
2. Permission / Authorization
AIが持つAuthority自体を限定します。
Least privilege
Scoped permission
Task-specific authorization
Approval
3. External AI Judgment
別のAIがAgentを監視します。
Agent
↓
Supervisor / Monitor AI
↓
Allow / Alert / Block
4. Human Gate
重大なActionや不明状態を人間へ戻します。
5. Internal Normative Judgment
Agent自身が、
このActionはPolicyに適合するか
を推論します。
6. Relational Responsibility
さらに一段進めて、
Self
Other
Relation
Authority
Impact
History
の変化から、現在のResponsibility Boundaryそのものを再構成する考え方です。
今回特に見たいのは、5と6の差です。
OpenAI：別AIによるMonitorと実行前Reviewへ進む
OpenAIは2026年3月、内部coding agentのtrajectoryを別AIでmonitorする仕組みを公開しました。
monitorは会話、reasoning、tool call、Actionを確認し、ユーザーintentやsecurity policyに反する可能性がある挙動を検出します。
OpenAIは、agentがrestrictionを回避しようとするケースや、unauthorized data transfer、destructive actionなどを実際に観測したと報告しています。
現在は主として低latencyの非同期monitorですが、将来的にはActionを実行する前に同期的に評価し、高risk Actionをblockする方向を示しています。
公式資料:
構造は次のように書けます。
Agent
↓
Action proposal
↓
Monitor AI
↓
Alert / Block
↓
Human Review
さらに7月のHugging Face incident後、OpenAIはcontainment、monitoring、access control、evaluation practiceを強化しました。
8月7日のAstraでは、isolated environment、network/tool restriction、sandbox、monitoringを強化し、control requirementを満たさない内部活動をpauseしています。
8月10日のDaybreakでは、identity verification、approved-use restriction、monitoring、auto-review、scoped permission、human oversightを組み合わせています。
OpenAIの公開設計を一言でまとめるなら、
Capability
+
Actor Qualification
+
Authority
+
Scope
+
Monitor
+
Human Oversight
です。
単純なcontent guardrailではなく、Action Governanceになっています。
Anthropic：Agentの意図よりBlast Radiusを制御する
Anthropicは2026年5月、How we contain Claude across products というかなり直接的な記事を公開しています。
ここで面白いのは、Agent Riskを「モデルがどれくらい善良か」だけで評価していないことです。
Anthropicはfailure probabilityだけでなく、failureが起きたときのblast radiusを環境側から制限することを重視しています。
主な手段は二つです。
Human-in-the-Loop
Claude Codeでは、以前はAgentがActionを行うたびにpermissionを求める設計が強く使われていました。
ただしAnthropicのtelemetryでは、permission promptのおよそ93%が承認されており、promptが多くなるほどapproval fatigueが起きる問題を指摘しています。
「何でも人間に確認すれば安全」という設計にも限界があるわけです。
Containment
Anthropicは、
Agentが何をするかを監督するだけでなく、そもそも何ができるかを制限する
方向を重視します。
sandbox、VM、egress controlなどで、仮に判断を誤っても到達可能な範囲を狭めます。
公式資料:
さらに Trustworthy agents in practice では、Agentを単一モデルとしてではなく、
model
harness
tools
environment
の組み合わせとして扱っています。
well-trained modelだけでは不十分で、harnessやtool、environmentが過剰なAuthorityを与えれば問題が起きる、という立場です。
これは重要な補正です。
「モデルを倫理的にすれば安全」というモデル中心主義から、かなり明確に離れています。
Google DeepMind：別AIが監督し、実績に応じてPermissionを変える
Google DeepMindは2026年6月、内部systemを高度なAI Agentから守るためのAI Control Roadmapを公開しました。
ここでは、alignment済みmodelだけを信用しません。
working agentがpotentially misalignedである可能性を前提に、別のtrusted AIをsupervisorとして配置します。
Working Agent
↓
Trusted Supervisor AI
↓
Review reasoning / action / plan
↓
Allow / Block
さらに面白いのが、verified behaviorに応じてpermissionを段階的に与える考え方です。
Observed Behavior
↓
Trust Evidence
↓
Permission Level
↓
More / Less Autonomy
riskによってreview方法も変えます。
reversibleで低riskなActionなら非同期review。
重大なcyberattackのような高risk Actionなら、実行前の同期blockを使う。
公式資料:
ここまで来ると、permissionはすでにかなり動的です。
Microsoft：Agent自身にPolicy Complianceを考えさせる
今回、私の仮説に対する一番強い反証候補だったのがMicrosoft Researchです。
Optimizing Agent Planning for Security and Autonomy では、Agent自身がtask progressだけでなく、policy complianceも明示的にplanする設計を提案しています。
単にAgent任せにはしません。
underlying systemにはdeterministicなinformation-flow controlを置き、その上でAgentが、
Taskを進めたい
+
Policyにも適合したい
を同時に扱います。
必要ならHuman-in-the-Loopへ戻します。
公式資料:
これは明確に、
安全判断は外部monitorだけが行う
という設計から先へ進んでいます。
MOSAIC：Plan → Check → Act or Refuse
Microsoft ResearchのMOSAICでは、multi-step tool useを行うAgentへ、明示的なsafety reasoning loopを学習させています。
Plan
↓
Check
↓
Act or Refuse
Agent自身が安全判断を行い、refusalをfirst-class actionとして扱います。
公式資料:
つまり、
AI自身に安全判断をさせる研究は存在するか？
への答えは明確にYesです。
PAuth：Userの自然言語TaskからAuthorityを絞る
Microsoft ResearchのPAuthもかなり近い問題を扱っています。
現在のOAuthのようなoperator-scoped authorizationでは、Agentへ広すぎるpermissionを与えやすい。
そこでPAuthは、ユーザーが自然言語で与えたtaskから、そのtaskを忠実に実行するために必要な具体的operationだけをauthorizeすることを目指します。
たとえば、
Bobへ100ドル送金して
というtaskが、
transfer APIを自由に使ってよい
ことを意味しないようにします。
公式資料:
これはCapabilityとAuthorityの分離として非常に重要です。
比較すると「ただのガードレール」ではない
ここまでをまとめます。
| 組織 | 公開資料で確認できる主なアプローチ |
|---|---|
| OpenAI | monitor AI、sandbox、scoped authority、pre-action review、Human oversight |
| Anthropic | HITL、containment、blast-radius control、harness/tool/environment security |
| Google DeepMind | supervisor AI、risk連動block、behaviorに基づく段階的permission |
| Microsoft | deterministic control、internal policy planning、safe tool-use reasoning、task-scoped authorization |
したがって、
Big TechはAIの周囲に固定ガードレールを置いているだけ
という主張は強すぎます。
特にGoogle DeepMindとMicrosoftは、
- permissionを動的に変える
- Agent自身がPolicyを考える
- taskからAuthorityを導く
ところまで来ています。
それでも「関係責任」とは少し違う
ここで、前の記事で置いた設計仮説に戻ります。
たとえば昨日、
delete(file_A) = allowed
だったとします。
しかし今日、別の人が file_A を共同成果物として使い始めた。
Policy textは変わっていない。
Filesystem permissionも変わっていない。
Userの命令も同じかもしれない。
それでも、
Relation
Impact
Residual Owner
Reversibility
が変化しています。
その結果、
ACT
だった判断が、
ASK
HOLD
へ変わる。
このとき必要なのは、単純なPolicy Complianceだけではありません。
Policy ComplianceとBoundary Reconstructionを分ける
Policy Compliance
Current Action
+
Known Policy
↓
Comply / Refuse
Relational Boundary Reconstruction
Self
Other
Relation
Authority
Context
Impact
History
Reversibility
↓
Current Boundaryを再構成
↓
Act / Ask / Hold / Stop
↓
結果を観測
↓
Relationを更新
↓
Boundaryを再構成
違いは、Actionを判定するだけでなく、判定に使う境界側も状態によって動くことです。
今回、Google DeepMindのadaptive permissionやMicrosoftのpolicy planningはかなり近いところまで来ています。
一方で、他者との関係変化からResponsibility Boundary自体を再構成するruntime architectureは、今回確認した公開一次資料では明示的には確認できませんでした。
これは「存在しない」という意味ではありません。
未公開かもしれません。
別の研究用語で存在するかもしれません。
今後の調査で反証される可能性もあります。
ここは事実と仮説を分けます。
Human-in-the-Loopだけでも解けない
もう一つ比較から見えるのが、Human Gateの使い方です。
人間に全部聞けば安全そうに見えます。
しかしAnthropicが指摘するように、approval promptが大量に出れば、人間はほとんど承認するようになります。
つまり、
不安だから毎回聞く
だけではHuman-in-the-Loopが形骸化します。
必要なのは、
AIの委任範囲を超えたから返す
という明確なReturn Conditionです。
これは実装上かなり重要です。
Responsibility Pathwayで見るとどうなるか
私は、AI・人間・組織・外部systemをまたぐActionについて、Capability、Authority、Evidence、External Effect、Repair、Resume、Residual Ownership、Human Returnを切らずに扱う構造を責任経路（Responsibility Pathway）として整理しています。
既存の実装記事:
今回の比較から、少なくとも次のことが分かります。
- Content Guardrailだけを論じる段階は終わっている
- Tool / Environment / Permission / Trajectory / Monitor / Human oversightまで設計対象になっている
- Agent自身のPolicy reasoningも研究されている
- Permissionをtaskやbehaviorに合わせて動かす試みもある
- それでもRelation変化からResponsibility Boundaryを再構成する問題は独立して考える余地がある
まとめ
Big TechのAgent Safetyは、想像以上に多層です。
Model Alignment
+
Containment
+
Authorization
+
Monitor AI
+
Human Gate
+
Internal Safety Reasoning
まで来ています。
だから次の問いは、
AI自身に安全判断をさせていますか？
ではありません。
もっと限定できます。
他者との関係が変わったとき、AIは責任境界そのものを再構成できますか？
ガードレールの「次」というより、ガードレールの内側へもう一つBoundary Modelを持たせる話です。
次の記事では、このRelational Responsibilityを実際のAgent Architectureへ落とすと、どんなstateとtransitionが必要になるのかを疑似コードで組み立てます。