このシリーズでは、まずOpenAIのサイバー事例からAIエージェントの境界を考え、続いてBig Tech 4社のAgent Safety設計を比較しました。
AIエージェントへToolを渡すと、最初はpermission設計でかなり解けるように見えます。
ところが実際の業務を想定すると、同じActionでも「昨日は実行してよかったのに、今日は確認が必要」という状態が普通に出てきます。
理由は単純です。
他者との関係が変わるからです。
この記事では、固定Policyだけでは扱いにくいこの問題を「関係責任（Relational Responsibility）」という設計仮説として、AIエージェントのstate / transition / Human Returnへ落としてみます。
この記事のコードは設計説明用の疑似コードです。現行のResponsibility Pathway Engineering (RPE) / Responsibility Pathway Runtime (RPR) APIそのものではありません。
自分一人なら壊してよいものが、共同作業になると変わる
たとえば、自分だけで使っている試作ファイルがあります。
prototype.json
自分だけなら、削除して作り直しても大きな問題はありません。
ところが、別の人がこのファイルを共同作業の入力に使い始めた。
Filesystem permissionは変わっていないかもしれません。
AgentのCapabilityも同じです。
Capability: delete可能
Permission: write/delete可能
それでも、削除というActionの意味は変わります。
Before:
自分だけの試作
→ ACTしてよい
After:
共同成果物の一部
→ ASK / HOLDが必要
ここで変わったのはTool Capabilityではありません。
Relationです。
固定Policyだけでは表現しにくい
普通のauthorizationなら、こんな実装になります。
def can_delete(user, resource) -> bool:
return "delete" in user.permissions_for(resource)
これは必要です。
ただし、次の状態は拾えません。
- permissionはあるが第三者影響が増えた
- ownerは同じだが共同利用者が増えた
- reversibleだった処理が外部公開によって不可逆になった
- userは操作権限を持つが、組織上の最終承認権は持たない
- 障害対応で一時的にAuthorityが変わった
つまり、
Permission == Responsibility Boundary
とは限りません。
Responsibility Boundaryをstateとして持つ
まず、境界を固定Ruleではなく状態として持ってみます。
from dataclasses import dataclass, field
from enum import Enum
from typing import FrozenSet
class BoundaryDecision(str, Enum):
ACT = "act"
ASK = "ask"
HOLD = "hold"
STOP = "stop"
ESCALATE = "escalate"
@dataclass(frozen=True)
class RelationState:
actor_id: str
affected_parties: FrozenSet[str]
authority_scope: FrozenSet[str]
shared_owners: FrozenSet[str]
external_effect: bool
reversible: bool
evidence_complete: bool
ポイントは、permissionだけでなく、
affected_parties
shared_owners
external_effect
reversible
evidence_complete
を同じ判断材料へ入れることです。
境界は関数として再計算する
概念的には、次のように考えます。
Boundary(t) = f(
Self(t),
Other(t),
Relation(t),
Authority(t),
Context(t),
Impact(t),
Reversibility(t),
Evidence(t),
History(t)
)
最初から完璧な数理モデルを作る必要はありません。
まずは明示的なruleで十分です。
def decide_boundary(
state: RelationState,
required_authority: str,
) -> BoundaryDecision:
if required_authority not in state.authority_scope:
return BoundaryDecision.ESCALATE
if not state.evidence_complete:
return BoundaryDecision.HOLD
if state.external_effect and not state.reversible:
return BoundaryDecision.ASK
if len(state.shared_owners) > 1:
return BoundaryDecision.ASK
return BoundaryDecision.ACT
これだけでも、
できるから実行
から、
現在の関係状態ではどう扱うべきか
へ判定単位が変わります。
ACT / DENY の二値にしない
Agent設計では allow / deny に寄せたくなります。
でも現場では、中間状態がかなり重要です。
ACT 実行可能
ASK 人間判断があれば進める
HOLD 情報不足なので状態を保持
STOP 現在条件では禁止
ESCALATE 自分のAuthority外なので責任経路を返す
特に HOLD と ESCALATE を分けるのが重要です。
HOLD
= 判断材料が足りない
ESCALATE
= 判断するAuthorityを自分が持たない
この二つを両方「失敗」に丸めると、Agentは再試行や別経路探索を始めやすくなります。
「確認できない」をRetry理由にしない
たとえば外部APIへ変更を投げた直後にtimeoutしたとします。
request sent
↓
timeout
この時点では、
失敗
とは限りません。
成功しているかもしれない。
Responsibility Pathway Runtimeでは、このような結果不明状態を EFFECT_UNKNOWN のように独立して扱う発想が重要になります。
概念的には、
class EffectState(str, Enum):
NOT_STARTED = "not_started"
CONFIRMED = "confirmed"
FAILED = "failed"
UNKNOWN = "unknown"
として、UNKNOWN なら単純Retryしません。
関係責任でも同じです。
不明状態で境界を勝手に緩めない。
def next_action(effect: EffectState) -> BoundaryDecision:
if effect == EffectState.UNKNOWN:
return BoundaryDecision.HOLD
return BoundaryDecision.ACT
ActionのあとにRelationを更新する
Boundaryを一度判定して終わりではありません。
Action自身がRelationを変えるからです。
たとえば、Draftを作るところまでは内部作業です。
State 1
Draft only
external_effect = false
→ ACT
次にレビュー依頼を出す。
State 2
Third party involved
external_effect = true
→ Relationを更新
さらに公開候補へ変わる。
State 3
Public impact
reversible = false or low
→ ASK
したがって、runtime loopは次のようになります。
Observe
↓
Interpret
↓
Reconstruct Boundary
↓
Propose
↓
Authority Check
↓
ACT / ASK / HOLD / STOP / ESCALATE
↓
Observe Result
↓
Update Relation
↓
Reconstruct Boundary
Human-in-the-Loopを「毎回確認」にしない
Human-in-the-Loopは重要です。
ただし、何でも人間に聞けばよいわけではありません。
AnthropicはClaude Codeのpermission promptについて、telemetry上およそ93%が承認されていたと説明し、approval fatigueの問題を挙げています。
公式資料:
つまり、
危険かもしれないので毎回聞く
では、人間側のGateが形骸化します。
Human Gateは、
現在のResponsibility BoundaryがAIの委任範囲を越えた
ときに返す方が実装上明確です。
Human Return Conditionを明示する
例として次をHuman Return Conditionにします。
@dataclass(frozen=True)
class HumanReturnPolicy:
external_publication: bool = True
irreversible_delete: bool = True
permission_expansion: bool = True
credential_change: bool = True
third_party_impact: bool = True
unresolved_authority_conflict: bool = True
判定側は単純です。
def requires_human_return(
*,
external_publication: bool,
irreversible: bool,
permission_expansion: bool,
third_party_impact: bool,
authority_conflict: bool,
) -> bool:
return any([
external_publication,
irreversible,
permission_expansion,
third_party_impact,
authority_conflict,
])
実システムではrisk levelやdomain ruleがもっと入ります。
ここで重要なのは、Human GateをUIの確認ボタンではなく、責任を戻すtransitionとして定義することです。
Ethical JudgmentとAuthority Judgmentを分ける
Agent自身に安全判断をさせる研究も進んでいます。
Microsoft ResearchのMOSAICでは、multi-step tool useに対して、
Plan
↓
Check
↓
Act or Refuse
という明示的なsafety reasoning loopを学習させています。
これは重要です。
ただし、Agentが、
このActionは安全・倫理的に許容できる
と判断したとしても、
だから私が実行してよい
とは限りません。
Ethically Acceptable != Authorized
さらに、
Authorized != Responsibility Complete
です。
なので、判定を最低でも分けます。
@dataclass(frozen=True)
class Judgment:
policy_ok: bool
authority_ok: bool
relation_ok: bool
evidence_ok: bool
def decide(j: Judgment) -> BoundaryDecision:
if not j.policy_ok:
return BoundaryDecision.STOP
if not j.authority_ok:
return BoundaryDecision.ESCALATE
if not j.evidence_ok:
return BoundaryDecision.HOLD
if not j.relation_ok:
return BoundaryDecision.ASK
return BoundaryDecision.ACT
Self-Modelだけでも足りない
AI AgentがSelf-Modelを持てるとします。
自分は何者か
何ができるか
何を知らないか
どんなToolがあるか
現在どのstateか
これは非常に役立ちます。
しかし、
Self-Model != Responsibility Model
です。
「私はdelete toolを使える」と分かっていても、
「今の私と相手の関係では、ここでdeleteを実行するAuthorityはない」
まで接続できるとは限りません。
そこで、SelfだけでなくOtherとRelationをruntime stateへ入れます。
最小のRelational Responsibility Model
@dataclass
class RelationalResponsibilityState:
self_id: str
other_ids: set[str] = field(default_factory=set)
relation_labels: set[str] = field(default_factory=set)
authority_scope: set[str] = field(default_factory=set)
affected_parties: set[str] = field(default_factory=set)
external_effect: bool = False
reversible: bool = True
evidence_complete: bool = True
residual_owner: str | None = None
たとえば共同成果物なら、
state = RelationalResponsibilityState(
self_id="agent-a",
other_ids={"user-a", "reviewer-b"},
relation_labels={"delegated-agent", "shared-work"},
authority_scope={"draft.edit"},
affected_parties={"user-a", "reviewer-b"},
external_effect=False,
reversible=True,
evidence_complete=True,
residual_owner="user-a",
)
ここでAgentに repo.delete Capabilityがあっても、authority_scopeにはありません。
したがって実行しません。
さらに、もしAuthorityがあってもshared-workならHuman Returnする、といったruleを足せます。
External Boundaryは絶対に残す
ここは誤解しやすいので強調します。
AI自身に関係責任を扱わせるからといって、sandboxやpermission controlを外す話ではありません。
内部判断は失敗します。
Microsoft Researchの Optimizing Agent Planning for Security and Autonomy でも、Agent自身にpolicy complianceをplanさせる一方で、underlying systemにはdeterministicなinformation-flow controlを置きます。
Google DeepMindもmodel alignmentだけを信用せず、別AIによるsupervisionやsystem-level controlを組み合わせています。
したがって、狙う構造はこれです。
┌──────────────────────┐
│ External Enforcement │
│ Sandbox │
│ Permission │
│ Monitor AI │
│ Human Gate │
└──────────┬───────────┘
│
┌──────────▼───────────┐
│ Internal Boundary │
│ Self │
│ Other │
│ Relation │
│ Authority │
│ Impact │
│ Responsibility │
└──────────────────────┘
自分でも止まる。外側でも止める。
Defense in Depthです。
AuthorityはCapabilityの成長と一緒に増やさない
高性能なAIを見ると、Capabilityが上がったのでより広いAuthorityを与えたくなります。
でも、
Capability != Authority
です。
むしろ、
High Capability
+
Weak Boundary Model
=
Large Risk
になる可能性があります。
Google DeepMindは、verified behaviorに基づいてpermissionを段階的に与える考え方を公開しています。
この発想を関係責任へ広げるなら、Authority拡大の評価項目に次を足せます。
Task success
Safety compliance
Boundary reconstruction accuracy
Human return accuracy
Third-party impact detection
Uncertainty handling
単に「仕事ができる」だけではなく、止まるべき地点で止まれることをAuthority委譲の条件へ入れるわけです。
Responsibility Formationという見方
ここから先は設計仮説です。
AI SafetyではAlignmentが重要な中心概念です。
望ましいPolicyやValueへAIを合わせる。
それに加えて、Agentへ広い自由を委譲する問題では、Responsibility Formationという見方も必要になるのではないかと考えています。
これはAIに法的責任を負わせるという意味ではありません。
AI内部で、
Self
Other
Relation
Authority
Impact
Responsibility Pathway
を継続的に扱える判断構造を形成する、という意味です。
Responsibility Pathwayへどう接続するか
責任経路（Responsibility Pathway）では、AI・人間・組織・外部systemをまたぐ実行で、Capability、Authority、Evidence、External Effect、Repair、Resume、Residual Ownership、Human Returnを切らずに扱います。
既存の実装記事はこちらです。
最小イメージは次のようになります。
Observation
↓
Interpretation
↓
Proposal
↓
Authority
↓
Action
↓
Verification
↓
Adoption
↓
Residual Owner
↓
Human Return Point
ここへRelational Responsibilityを接続するなら、各transitionでBoundaryを再評価します。
Observation
↓
[Boundary Reconstruction]
↓
Interpretation
↓
Proposal
↓
Authority
↓
[Boundary Reconstruction]
↓
Action
↓
Result Observation
↓
[Boundary Reconstruction]
責任経路そのものが、関係状態によって形を変えるイメージです。
保証しないこと
この設計だけで、AI Agentが安全になるとは保証できません。
特に次は別問題です。
- Relation State自体を誤認する
- 悪意ある入力でAuthority情報を汚染される
- Supervisor AIも誤る
- Human Gateが誤判断する
- 実世界の法的責任をAI内部stateだけで決定する
- ContextやMemoryが欠落する
したがって、実用時にはExternal EnforcementとEvidence検証が必須です。
まとめ
AIエージェントへ自由を渡すとき、問うべきなのはCapabilityだけではありません。
何ができるか
に加えて、
今の関係では、どこまで自分が決めてよいか
を扱う必要があります。
その境界は固定ではありません。
他者が現れれば変わる。
共同作業になれば変わる。
外部作用が生まれれば変わる。
不可逆になれば変わる。
Authorityが衝突すれば変わる。
だから、Agent ArchitectureにもBoundaryをstateとして持たせ、Actionのたびに再構成する余地があります。
External Boundary
+
Internal Relational Boundary
外側でも止める。
内側でも止まる。
そしてAIの委任範囲を越えたら、責任経路を人間へ戻す。
これが「関係責任」を実装へ落とすときの、まず最小の形だと考えています。