前回は、AIエージェントの責任境界を固定permissionだけで決めず、Authority、第三者影響、Evidence、可逆性、Relationの変化から再計算する設計を書きました。

その続きを実装すると、かなり地味だけど重要な問題にぶつかります。

Agentが止まったあと、何をしてよいのか。

一時障害なら再試行してよい。
でも外部APIが成功したか分からないなら再試行は危ない。
保存地点があっても承認が古ければ再開できない。
経路だけ変える再計画と、Scopeを広げる再計画も同じではありません。

責任経路OS（Responsibility Pathway Operating System / RPOS）では、まずこの小さな違いをコードへ落としています。

ここでいう「人への責任返却」は、Agentが自律的に判断を続ける条件を失ったとき、次の判断主体を明示して人間へ戻すことです。

「失敗した」と「何も起きなかった」は別

外部APIへ更新要求を送る最小例です。

def update_remote(payload):
    return api.post("/records", json=payload)

通信timeoutしたら、普通はretryしたくなります。

でも最初のrequestがserverへ到達済みだったら、二回目はduplicate effectになるかもしれません。

request failed != external effect did not happen

ここを一つに丸めると、retry policyが事故を増幅します。

error typeではなく観測事実を分ける

現在の実装では、回復判断に使う事実を RecoveryObservation として分けています。

@dataclass(frozen=True)
class RecoveryObservation:
    transient_failure: bool = False
    retry_budget_available: bool = False
    operation_idempotent: bool = False

    effect_status_known: bool = True
    effect_observed_absent: bool = False
    effect_mismatch: bool = False

    checkpoint_verified: bool = False
    external_state_fresh: bool = False
    authority_current: bool = False

    cause_known: bool = True
    invariant_violation: bool = False
    unauthorized_effect: bool = False
    owner_mismatch: bool = False

例外名だけではなく、

一時障害か
冪等か
retry budget内か
外部効果は本当に発生していないか
保存地点は検証済みか
外部状態は現在もfreshか
Authorityは現在も有効か
原因は分かっているか
責任境界違反がないか

を見るわけです。

停止後を六つに分ける

class RecoveryDisposition(StrEnum):
    LOCAL_RETRY = "local_retry"
    CHECKPOINT_RESUME = "checkpoint_resume"
    EFFECT_RECONCILIATION = "effect_reconciliation"
    CONTRACT_PRESERVING_REPLAN = "contract_preserving_replan"
    REAUTHORIZATION_REQUIRED = "reauthorization_required"
    HUMAN_RETURN = "human_return"

日本語にすると、

局所再試行
保存地点からの再開
外部効果の照合
契約を変えない再計画
再承認
人への責任返却

です。

全部を「再実行」で済ませないのがポイントです。

外部効果が分からないなら、先に照合する

if not observation.effect_status_known:
    return RecoveryDecision(
        disposition=RecoveryDisposition.EFFECT_RECONCILIATION,
        reasons=("effect_status_unknown",),
        prior_authority_remains_usable=False,
    )

必要なのは、まず外部状態の照合です。

write_status_unknown
  ↓
readback / ledger / idempotency record
  ↓
actual effect ?

RPRはattemptやeffectのcontinuityをruntime側で保持し、責任経路OSはその上で次に進む責任経路を選びます。

保存地点があるだけでは再開しない

if (
    observation.checkpoint_verified
    and observation.external_state_fresh
    and observation.authority_current
):
    return RecoveryDecision(
        RecoveryDisposition.CHECKPOINT_RESUME,
        ("verified_checkpoint_and_current_context",),
        True,
    )

保存地点が正しくても、外部状態やAuthorityが古いなら再開しません。

LangGraphの公式ドキュメントでも、interrupt後のresumeではnodeが途中行からではなく先頭から再実行されるため、interrupt前のside effectをidempotentにするか分離する必要があると説明されています。

https://docs.langchain.com/oss/python/langgraph/interrupts

checkpoint continuity != external effect continuity

です。

再計画にも二種類ある

たとえば、

parser A failed
  ↓
approved parser B

のように同じ契約の中でrouteだけを変えるなら、契約を変えない再計画として扱えるかもしれません。

一方で、

read-only failed
  ↓
write APIへ切替

なら話が変わります。

責任経路OSではGoal、Scope、Invariant、対象所有者、Effect class、評価条件、Authority、Delegation、Budgetなどの差分を見ます。

@dataclass(frozen=True)
class ContractDelta:
    goal_changed: bool = False
    scope_changed: bool = False
    invariant_changed: bool = False
    subject_or_owner_changed: bool = False
    effect_class_changed: bool = False
    evaluation_contract_changed: bool = False
    authority_changed: bool = False
    delegation_changed: bool = False
    budget_changed: bool = False

    @property
    def requires_new_authorization(self) -> bool:
        return any((
            self.goal_changed,
            self.scope_changed,
            self.invariant_changed,
            self.subject_or_owner_changed,
            self.effect_class_changed,
            self.evaluation_contract_changed,
            self.authority_changed,
            self.delegation_changed,
            self.budget_changed,
        ))

差分が責任条件へ触れたら、回復のついでに以前のAuthorityを引き延ばしません。

if observation.contract_delta.requires_new_authorization:
    return RecoveryDecision(
        disposition=RecoveryDisposition.REAUTHORIZATION_REQUIRED,
        reasons=("responsibility_contract_changed",),
        prior_authority_remains_usable=False,
    )

つまり、

同じGoal / Scope / Effect / Authorityの中でrouteだけ変更
  -> 再計画

Scope、対象、Effect、Authority、Delegationなどが変化
  -> 再承認

です。

回復処理はAuthorityを生成しない。

ここをデータ構造へ固定します。

retryしてよい条件を狭くする

このclassifierの目的はretryを増やすことではありません。

むしろ逆で、retryしてよい条件を狭くすることです。

失敗した
  ↓
とりあえずretry

ではなく、

何が観測されたか
  ↓
外部効果は確定しているか
  ↓
Authorityは現在も有効か
  ↓
契約は変わっていないか
  ↓
再試行 / 再開 / 照合 / 再承認 / 人へ返す

へ分けます。

地味ですが、たぶんこういうところが本番では効きます。

ガバナンス文書はruntimeの問いへ落とす

この実装は、日本のAIガバナンス文書とも照らし合わせています。

経済産業省「AI事業者ガイドライン（第1.2版）」や、2026年7月14日閣議決定の「人工知能基本計画」を読むと、信頼できるAI、ガバナンス、リスク管理、人とAIの協働などの要求を、実装側では次の問いへ落とせます。

誰がAuthorityを持つか
必要なEvidenceは何か
どこで止めるか
外部操作の結果をどう確認するか
状態変化後も承認を再利用できるか
誰へ責任を返すか

経済産業省「AI事業者ガイドライン（第1.2版）」
- https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20260331_report.html
内閣府「人工知能基本計画」
- https://www8.cao.go.jp/cstp/ai/ai_plan/ai_plan.html

責任経路OSがこれらに「準拠済み」と言いたいわけではありません。

要求をコードへ落として、実際にどこまで扱えるのかを検証する。その順番です。

海外側も「対応済み」ではなく比較材料として読む

NIST AI RMF、EU AI Act、ISO/IEC 42001、OECD AI Principles、さらにMagentic-One、AgentTether、Cordon、Temporary Authority, Permanent Effectsなどにも、再試行、監督、Authority、外部効果、回復といった隣接する論点があります。

責任経路OSでは、それぞれの名称や造語を輸入するのではなく、一般構造へ分解して比較します。

NIST AI RMF 1.0: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10
EU AI Act: https://eur-lex.europa.eu/eli/reg/2024/1689/oj
ISO/IEC 42001:2023: https://www.iso.org/standard/42001
OECD AI Principles: https://oecd.ai/en/dashboards/ai-principles/P9
Magentic-One: https://arxiv.org/abs/2411.04468
AgentTether: https://arxiv.org/abs/2607.06273
Cordon: https://arxiv.org/abs/2606.17573
Temporary Authority, Permanent Effects: https://arxiv.org/abs/2607.10487

詳しい設計意図や、なぜこの形で公開研究を続けているのかはZenn側にまとめています。

Lean 4は検証器として使う

責任経路OSの開発・検証体系ではLean 4を使っています。

formal proof != real-world truth
mathematical validity != execution authority

形式証明が効くところでは使う。
でも現実のeffectや組織上のAuthorityまで、数理が代わりに決めたことにはしません。

数理は、曖昧にしなくてよい部分を曖昧にしないための検証器として扱います。

実装を公開して、壊れるところを集めたい

責任経路OSの設計には自信があります。

ただし、開発者の自信と第三者評価は別です。

開発者の確信 != 第三者評価
内部テスト成功 != 実利用での有効性
公開した != 検証された

まず作る。テストする。公開する。使ってもらう。壊れるところを教えてもらう。直す。

RPRはすでにPyPIで公開しています。

Responsibility Pathway Runtime
- https://pypi.org/project/responsibility-pathway-runtime/

うまく動かない、分かりにくい、止めすぎる、もっと止めるべき、設計として変だ――そういうダメ出しを歓迎します。

再現可能なダメ出し、具体的な反例、壊れるケース、運用上の違和感はかなりありがたいです。

まとめ

今回の実装は、かなり小さな話です。

失敗
  ↓
全部retry

をやめて、

再試行
再開
外部効果の照合
再計画
再承認
人への責任返却

へ分ける。

特に重要なのは、

failed response != no external effect
checkpoint != safe resume
replan != renewed authority

を混ぜないことです。

この小さな境界を実装して、テストして、公開して、実際にどこで壊れるかを見る。

今の責任経路OSは、その途中です。

関連

Zenn: https://zenn.dev/dantarg/articles/rpos-recovery-governance
Responsibility Pathway Program: https://github.com/YutoriKomeiji/responsibility-pathway-program
Responsibility Pathway Runtime: https://github.com/YutoriKomeiji/responsibility-pathway-runtime

小野昭久

本稿を含むResponsibility Pathway / RPE / RPR / RPOSの研究・実装は、勤務先の公式見解や製品活動ではなく、個人として進めている独立研究・OSS活動です。