このシリーズでは、まず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の問題を挙げています。

公式資料:

https://www.anthropic.com/engineering/how-we-contain-claude

つまり、

危険かもしれないので毎回聞く

では、人間側の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を学習させています。

https://www.microsoft.com/en-us/research/publication/learning-when-to-act-or-refuse-guarding-agentic-reasoning-models-for-safe-multi-step-tool-use/

これは重要です。

ただし、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を置きます。

https://www.microsoft.com/en-us/research/publication/optimizing-agent-planning-for-security-and-autonomy/

Google DeepMindもmodel alignmentだけを信用せず、別AIによるsupervisionやsystem-level controlを組み合わせています。

https://deepmind.google/blog/securing-the-future-of-ai-agents/

したがって、狙う構造はこれです。

┌──────────────────────┐
│ 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を切らずに扱います。

既存の実装記事はこちらです。

AIエージェントに「責任経路」を実装する――Capability・Authority・Evidence・Resumeを分離する設計

最小イメージは次のようになります。

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の委任範囲を越えたら、責任経路を人間へ戻す。

これが「関係責任」を実装へ落とすときの、まず最小の形だと考えています。