AIエージェントや自動化処理に、外部API、SaaS変更、デプロイ、通知、権限操作を任せるとき、厄介なのは単純な「失敗」だけではありません。

失敗したように見えるのに、外部ではすでに実行済みかもしれない。

たとえば、API requestを送った直後にtimeoutしたとします。

request sent
  -> external system may already have changed
  -> response lost

ここで自動retryすると、二重決済、二重送信、二重変更になるかもしれません。

反対に「失敗した」と閉じると、実際には起きている変更を見失う可能性があります。

この記事では、この状態を「成功 / 失敗」の二択に潰さず扱うPython/SQLite runtime、Responsibility Pathway Operating System（責任経路OS / RPOS）0.1.0a2を実際に動かします。

python -m pip install responsibility-pathway-os==0.1.0a2

RPOSは、AIの責任問題を解決したと主張するものではありません。

狙っているのは、AIや自動化が現実世界へ作用するときに、承認した・実行要求を送った・success responseを受けた・本当に外部状態が変わったを別々に扱えるようにすることです。

分からないとき、責任まで消してはいけない。

この記事では、その考え方を実装として追います。

この記事は特に、次のような人向けです。

AIエージェントに外部APIを呼ばせている
Human-in-the-loopや承認フローを入れている
timeout後のblind retryを避けたい
決済、SaaS、deployment、IAM、通知など外部side effectを扱う
audit logだけでなく、external effectまで追跡したい
障害後のrepair / resume / reauthorizationを設計したい

まず動かして、その後で仕組みを見ます。

GitHub: https://github.com/YutoriKomeiji/responsibility-pathway-os
Product site: https://yutorikomeiji.github.io/responsibility-pathway-os/
PyPI: https://pypi.org/project/responsibility-pathway-os/0.1.0a2/

PyPI 0.1.0a2 では公開済みruntimeを試せます。この記事後半の3本のintegration demoは、そのPyPI公開後に追加した GitHub current main 側の内容です。

1. インストールする

Python 3.11+です。

python -m pip install responsibility-pathway-os==0.1.0a2
rpos --db rpos.db boot

sourceから確認する場合:

git clone https://github.com/YutoriKomeiji/responsibility-pathway-os.git
cd responsibility-pathway-os
python -m pip install -e .

2. まず「普通に完了する」経路を見る

python examples/happy_path_verified.py

概念的には、次の経路です。

PROPOSED
 -> HUMAN_GATE
 -> AUTHORIZED
 -> DISPATCHING
 -> VERIFIED
 -> COMPLETED

ここで重要なのは、COMPLETED が単なるtransport receiptの直後ではなく、外部結果を検証した後に来ることです。

RPOSでは、

人間が承認した
!=
外部へ要求を送った
!=
相手から応答が返った
!=
実際に外部状態が変わった

として扱います。

3. API timeout後の `EFFECT_UNKNOWN` を見る

次に、一番見てほしいexampleです。

python examples/effect_unknown_restart_reconcile.py

外部呼び出し後に結果を確認できないと、RPOSは

DISPATCHING -> EFFECT_UNKNOWN

として保持します。

EFFECT_UNKNOWN は、難しい概念ではありません。

**「外部で何が起きたか、まだ確認できていない」**という状態です。

ここで「例外が起きた = 外部effectは起きていない」と推測してretryしません。

restart後もsilent redispatchせず、まずreconciliation、つまり外部状態を読み直して事実を照合する処理へ責任を戻します。

この区別は、たとえば次の処理で重要です。

payment request
SaaS configuration update
deployment request
email / notification send
IAM / privileged access change
非同期jobの起動

4. Human-in-the-loopだけでは「停止後」は決まらない

実行前にHuman Gateを置くことは重要です。

でも、repairできた後に「さっき承認済みだったから、そのまま再実行していい」とは限りません。

python examples/human_return_reauthorization.py

RPOSでは、

REPAIR_REQUIRED
 -> READY_TO_RESUME
 -> AUTHORIZED
 -> DISPATCHING

のように分けます。

READY_TO_RESUME は「再開準備ができた」状態であって、execution authorityではありません。

再開には明示的なauthority restorationを要求できます。

つまり、Human-in-the-loopを実行前の承認だけで終わらせず、停止後の再開判断まで扱うという設計です。

既存OSSと比べて、RPOSはどこを狙っているのか

ここは機能数の勝負ではありません。

2026年8月30日時点で、Human-in-the-loop / tool approvalは Microsoft Agent Framework や OpenAI Agents SDK にあります。workflowのcheckpoint / resume / fault toleranceは LangGraph が強く、durable execution / retry / idempotencyは Temporal が深く扱っています。authorization / policy enforcementには Amazon Bedrock AgentCore Policy のような仕組みがあります。

PyPIにも、decision replay / rollbackを扱う auditable、Saga patternでcompensationする saga-agent、durabilityに強い python-durable があります。

それぞれの得意分野では、RPOSより成熟しているものがあります。

RPOSが主戦場にしているのは、その間に残る次の境界です。

外部実行後の結果不明を EFFECT_UNKNOWN として保持する
成功応答と現実の作用を分ける
修復完了と再実行権限を分ける
不確実性を次の人間・組織へ返す Human Return を消さない
それらを別機能で終わらせず、一つのresponsibility pathwayとして接続する

Temporalの公式資料自身も、Activityが成功した後、Workerが結果をServiceへ通知する前に落ちるとretryされ得るため、非冪等な処理では二重課金等が起こり得ると説明しています。

RPOSが追加で問うのは、続けてよいか自体が分からないとき、何を事実として保持し、誰のauthorityで次へ進むのかです。

さらに、この責任境界の一部をLean 4のbounded abstract modelでmachine-checkし、Python runtime testとproof ceilingへcrosswalkしています。

今回確認した主要な近縁PyPIパッケージの公開資料では、同じ形のLean 4 responsibility-invariant crosswalkは確認できませんでした。ただし、世界唯一・世界初という主張ではありません。

5. adapter exceptionでも「何も起きていない」と決めつけない

python examples/adapter_exception_containment.py

dispatch開始後にadapterが例外を投げた場合も、外部side effectが発生した可能性を捨てません。

これは、network errorとbusiness effectを同じ「失敗」に潰さないためです。

request failed
!=
external effect did not happen

6. current mainの3本のintegration demoを動かす

current public main には、より実運用に近い3本のscenarioがあります。

python examples/production_grade_demos/run_demo.py --workdir ./demo-state

このsuiteはdemo用にstate machineをコピーせず、shipped RposService、RPOS SQLite persistence、transition rulesを使います。

別processのlocalhost HTTP serviceへrequestを送り、外部effectは別SQLite databaseへ保存します。

Scenario A: supplier payment

相手側では処理済みなのに、呼び出し元がresponseを受け取れないケースです。

proposal
 -> finance Human Gate
 -> approve
 -> HTTP dispatch
 -> external DB commit
 -> connection lost
 -> EFFECT_UNKNOWN
 -> process restart
 -> independent GET readback
 -> COMPLETED

確認点:

EFFECT_UNKNOWN がprocess restartを越えて残る
restart後にsilent redispatchしない
external readbackで完了へ進む
external apply_count == 1

Scenario B: production deployment

初回dispatchを外部controllerがrejectします。

AUTHORIZED
 -> dispatch rejected
 -> REPAIR_REQUIRED
 -> repair preparation
 -> explicit change_manager resume
 -> fresh dispatch identity
 -> receipt
 -> EFFECT_UNKNOWN
 -> independent readback
 -> COMPLETED

確認点:

rejectをsuccess扱いしない
repair後もauthorityを自動復元しない
receiptだけではcompleteしない
fresh dispatch identityを使う

Scenario C: privileged access revocation

PROPOSED
 -> HUMAN_GATE
 -> DENIED

調査不足ならHuman Gateでdenyし、external access side effectを0件のまま止めます。

7. RPOS DBと外部DBを分けて見る

--workdir ./demo-state を付けると、RPOS側DBと外部system側DBが別々に残ります。

これは意図的です。

RPOS内部に「成功」と記録したことは、external effectの証拠にはなりません。

production systemなら、外部SQLiteの部分をprovider-specific readback contractへ置き換えることになります。

8. PyPI 0.1.0a2とcurrent mainは同じではない

production-grade demo suiteは、PyPI 0.1.0a2 の公開後にcurrent mainへ追加されています。

したがって、

pip install responsibility-pathway-os==0.1.0a2

で取得する公開runtime artifactと、current repositoryにあるdemo sourceは区別してください。

この記事では、0.1.0a2として公開済みのRPOS runtime semanticsを、current source checkoutのintegration demoから実行する構成を紹介しています。

9. 一度の承認を永久権限にしない

RPOSにはcommit-time authority revalidationがあります。

commit時点で、actor / operation / action / target / effect / evidence / context / authority epochが現在の条件と一致しなければHOLDできます。

狙いは、

以前の承認を別targetへ流用する
別effectへ承認を横流しする
revocation後に古いauthorityを使う

といったケースをfail-closedにすることです。

10. Lean 4では何を証明しているのか

cd formal/lean
lake build

Lean 4.32.2にpinしています。

現在のnamed assertionは6件です。

RPOS.human_gate_cannot_dispatch_directly
RPOS.only_verified_enters_completed
RPOS.effect_unknown_is_not_completed
RPOS.ready_to_resume_is_not_authorized
RPOS.receipt_is_not_effect_verification
RPOS.model_proposal_is_not_authority

日本語にすると、

Human Gateから直接dispatchできない
VERIFIED 以外から直接 COMPLETED へ入れない
EFFECT_UNKNOWN はcompletionではない
READY_TO_RESUME はauthorityではない
receiptはeffect verificationではない
model proposalはauthorityではない

という境界です。

RPOSでは、

operational risk
 -> Lean theorem
 -> Python runtime test
 -> model scope
 -> proof ceiling

のcrosswalkを公開しています。

ただし、Lean proofはPython runtime全体のformal correctnessを意味しません。

SQLite、任意の外部system、法的authority、組織責任、production deployment全体を証明したものでもありません。

11. ブラウザで状態遷移だけ見ることもできる

Product siteにはinteractive state-path explorerがあります。

こちらは状態遷移を視覚化するsimulationです。

production-grade demosはPython runtime + separate HTTP process + separate external SQLiteを実際に動かすintegration scenarioです。

用途が違うので分けています。

12. これは何を解決していないのか

RPOS 0.1.0a2はPublic Alphaで、engineering evaluation / bounded pilots向けです。

以下はclaimしていません。

production readiness
legal / regulatory compliance
certification
universal AI safety
任意外部systemでのexactly-once
arbitrary credentials / provider correctness
Python implementation全体のformal correctness
arbitrary operationのeventual completion

責任経路OSはAIの責任問題を解決済みにするものではありません。

承認・実行・応答・現実の作用・不確実性・修復・再開を分けて扱えば、今より安全にAIへ外部操作を任せられるのではないか。その仮説を実装として試せるようにしたものです。

13. この考え方の背景を読むなら

このQiita記事は「まず動かす」側に寄せています。

責任経路OSがなぜ必要だと考えたのか、世界課題から概念・Open Source実装までをつないだ記事はZenn側です。

AIエージェントの承認・実行・結果不明をどう扱うか――責任経路OS（RPOS）0.1.0a2を公開

これまでの流れ:

問題設定の原点はnoteにも残しています。

まとめ：まずどこへ行けばいいか

まず動かす

python -m pip install responsibility-pathway-os==0.1.0a2

コード・tests・Lean・CI・demoを見る

GitHub

状態遷移をブラウザで見る

Product site

自分のfailure modeに合うか確かめる

GitHubをforkして、壊してみてください。

RPOSで一番見てほしいのは、派手な「AI安全」の主張ではありません。

分からないことを、分かったことにしない。

外部で何が起きたか分からないなら、その不確実性と次の責任を消さずに残す。

まずはそこからです。