最近ずっと、AIエージェントが外部へ何かを実行したとき、その責任がどこに残るんだろうと考えています。
APIを叩くだけなら簡単です。でも、誰が承認したか、実際に何が起きたか、失敗したあと誰が再開してよいかまで追うと、急に話が難しくなる。
その穴を一つずつ埋めていった結果が、私が今「責任経路（Responsibility Pathway）」と呼んでいるものです。
AIエージェントやMCP、Human-in-the-Loop、AIガバナンスを実装側から追っていくと、結局いつも同じ問いに戻ってきます。
AIが判断や実行の途中に入ったとき、責任はどこを通り、失敗したらどこへ戻るのか。
最初からRPEやRPR、ましてRPOSを作ろうとしていたわけではありません。
出発点はもっと単純でした。
AIは責任を扱えない。
でも、そこで一度止まらず、
本当に？
と考えたところから始まっています。
この記事は、noteやZennに分散してきたその流れを、Qiitaから初めて読むエンジニア向けに一本へまとめる入口です。
先に全体像――発想史と現在のstackは少し違う
まず、考えが育った順です。
AIは責任を扱えない
↓
本当に？
↓
責任を「可逆性の残量」として捉えれば工学化できるのでは
↓
責任経路設計
↓
責任経路工学
↓
Responsibility Pathway Layer
↓
Responsibility Pathway Runtime
↓
Responsibility Pathway Operating System
これは、後から製品名を過去へ当てはめたものではありません。
一つ設計・実装するたびに、次に足りないものが見えてきた開発史です。
一方、現在の知識体系を整理するとこうなります。
Responsibility Pathway Model (RPM)
理論・論文
↓
Responsibility Pathway Framework (RPF)
implementation-neutralな共通参照枠
↓
Responsibility Pathway Design (RPD)
design knowledge / patterns / anti-patterns
↓
Responsibility Pathway Engineering (RPE)
machine-readable requirements / controls
↓
Responsibility Pathway Runtime (RPR)
execution / effect / evidence / repair / resume
↓
Responsibility Pathway Operating System (RPOS)
organization / profiles / operations / adoption
名前が生まれた順と、現在の体系上の上下関係が違うのは、設計と実装を進めたあとで理論層と共通参照枠を切り出したからです。
「責任が霧散する」を、実装の問題として見る
AI、人間、組織、複数のシステムが一つの意思決定や実行に関わると、途中で「結局誰が引き取るのか」が曖昧になることがあります。
私は会話の中で、こういう状態を「責任が霧散する」と表現することがあります。
責任経路を考え始めてから既存研究を追うと、海外では responsibility diffusion や responsibility gap といった近い問題設定がすでに議論されていることも分かりました。
私が実装側で扱いたいのは、その問題を別の言葉で言い直すことではありません。
誰が判断したか
誰が許可したか
何が実行されたか
何が確認できたか
どこで止めるか
誰へ戻すか
誰が未解決の影響を持つか
を、実際のAIエージェントの実行経路で切らさず残せないか。
ここをsoftware engineeringの対象として考えています。
2026年初頭: 「AIは責任を扱えない」で終わらせなかった
AIが責任主体になれるか、という問いは大きすぎます。
法的責任、道徳的責任、説明責任、組織責任まで一度に扱うと、実装へ落とせません。
そこで問いを変えました。
AIは人格的な責任を持てなくても、
- 判断
- authority
- execution
- evidence
- stop condition
- return point
を扱うことはできる。
ならば「責任そのもの」ではなく、責任が成立し続けるための構造を扱えるのではないか。
責任を「可逆性の残量」として捉えた
責任経路へ進む前に、一つの考え方がありました。
責任を、可逆性の残量として捉える。
たとえば、提案だけならかなり戻せます。
提案
↓
承認
↓
実行直前
↓
外部作用
↓
第三者へ波及
下へ行くほど、取り消せる範囲は狭くなります。
ただし「可逆性」は単なるundoではありません。
- まだ止められるか
- 誰が止められるか
- 外部作用は本当に起きたか
- 結果不明なら確認できるか
- 修復できるか
- 再開できるか
- 戻せない影響を誰が持つか
まで含めて見ます。
ここから、責任を一点ではなく経路として見る考え方が強くなりました。
現在のRPE / RPRが単一の「可逆性スコア」を計算するわけではありません。実装する過程で、停止、effect、evidence、repair、resume、Residual Ownerなどへ分解していきました。
責任経路設計: 「誰が責任者か」だけでは足りない
AIを含む業務処理では、RACIのように役割を固定するだけでは足りない場面があります。
AIが判断
↓
人が承認
↓
自動システムが実行
↓
別部署が運用
↓
顧客へ影響
このとき必要なのは、
どこで判断したか
どこで承認したか
どこで停止できるか
何が実際に起きたか
失敗したらどこへ戻すか
です。
これを設計対象として整理したのがResponsibility Pathway Design、責任経路設計です。
歴史的には、この設計側が先に育ちました。
RPM: 「責任経路とは何か」を理論として分ける
設計を進めると、次の問いが残ります。
そもそも責任経路は、何をモデル化しているのか。
そこで理論・論文側を Responsibility Pathway Model（RPM） として分離しています。
RPMは、責任、可逆性、actor、capability、authority、evidence、external effect、uncertainty、repair、resume、residual ownership、return / escalation / closureなどの関係を理論として扱う層です。
RPM manuscriptは現在Privateです。このQiita記事では、体系上の位置づけまでを扱います。
RPF: モデルを設計・実装へ使うための共通参照枠
さらに、理論と設計の間にもう一つ必要なものが見えてきました。
Responsibility Pathway Framework（RPF） です。
RPFは新しい製品ではありません。
RPMで扱う責任構造を、特定の業界、特定software、human / AIなどのactor typeへ固定せず、設計・評価・実装へ適用するためのimplementation-neutralな共通参照枠です。
たとえば、共通して見る対象を次のように揃えます。
Actor / Responsibility Actor
Responsibility Function
Capability
Authority
Evidence
Action / External Effect
Verification
Uncertainty
Repair
Resume
Residual Ownership
Return / Escalation
Closure
整理すると、
RPM = theory / model
RPF = common reference structure
RPD = design guidance
です。
この分離があると、金融、行政、製造、software運用などへ同じ責任構造を適用するとき、「何が共通coreで、何がdomain-specificか」を切り分けやすくなります。
RACI / HITL / Guardrailsとは何が違うのか
RACI
RACIはResponsible / Accountable / Consulted / Informedを整理するのに有効です。
責任経路ではさらに、runtime中の外部effect、結果不明、repair、resumeまで扱います。
Human-in-the-Loop
HITLは重要です。
ただし「人をloopへ置く」と「どの状態で誰へ責任をreturnするか」は別です。
Guardrails
Guardrailsは境界を越えさせないために有効です。
責任経路では、止めたあとに誰が引き取り、何を証拠として修復し、誰が再開を許可するかまで見ます。
既存手法を否定するのではなく、それらを責任の継続という観点でつなぐのが役割です。
責任経路工学 RPE: 設計原則をmachine-readableにする
責任経路設計だけでは、AIエージェントのtool callを止められません。
「重要な操作は人間が承認する」と規程に書いてあっても、実行経路にcontrolがなければ意味がない。
そこでResponsibility Pathway Engineering（RPE）へ進みました。
RPEでは、RPF / RPDで整理される責任条件やResponsible AI上の要求を、machine-readableな制御へ落とします。
Responsible AI requirement
↓
human / institutional review
↓
machine-readable Requirement Pack
↓
allow / hold / human_gate / deny
現在のRPE公開実装は、deterministic Python kernel、Requirement Pack evaluation、REST、OpenAPI 3.1、MCP stdio、pack lifecycle、version / compatibilityなどを扱います。
重要なのは、RPEがactionを直接実行しないことです。
Policy / Requirement Decision
!=
External Execution
判断と実行を分けます。
Responsibility Pathway LayerからRPRへ
初期には、AIエージェントと外部toolの間に責任経路を置く Responsibility Pathway Layer として考えていました。
LLM / AI Agent
↓
Responsibility Pathway Layer
↓
Tool / API / Business System
ところが、実際に外部作用を扱うとlayerだけでは足りません。
- execution attemptを保存する
- crash / restart後も状態を持つ
- readbackする
- 外部effectが分からない状態を保持する
- repairとresumeを分ける
ここまで来ると、必要なのはruntimeです。
そこでResponsibility Pathway Runtime（RPR）になりました。
RPR: APIが成功したか分からない状態を消さない
たとえば、AIエージェントが外部APIへPOSTした直後に通信が切れたとします。
request dispatch
↓
network failure
↓
外部では成功しているかもしれない
これ、かなり嫌な状態です（笑）。
ここで「失敗した」と決めてretryすると、二重登録や二重決済の危険があります。
だから、
Receipt != Verified Effect
を分けます。
RPRの公開alphaでは、曖昧な外部writeを結果不明として保持し、readbackやreconciliationへ進めます。
Repair != Resume
エラーを直せたからといって、そのまま再実行してよいとは限りません。
repair completed
!=
execution authority restored
です。
修復中にapprovalが失効したかもしれない。状況が変わったかもしれない。
そのため、
repair
↓
READY_TO_RESUME
↓
explicit resume authorization
↓
fresh execution attempt
と分けます。
「直った」と「もう一度やっていい」は別です。
Human Return Point: 最初は「必ず人間へ返す」だった
責任経路の初期安全設計では、重要な判断や結果不明をHuman Return Pointへ返すことを重視しました。
これは現在も重要です。
ただ、実装を進めると、さらに問いが出てきます。
本当に必要なのはhumanというactor typeなのか。それとも、その場面で必要な責任機能を遂行できる主体なのか。
ここから、Responsibility Return Pointという一般化を検討しています。
Responsibility Return Point
├─ Human
├─ AI Agent
├─ Organization
└─ Composite Actor
そして重要なのは、
Capability != Authority
です。
AIができることと、AIがやってよいことは別です。
Responsibility Return Pointは現在検討中の一般化で、現行公開APIの確定仕様ではありません。
RPRまで作ったら、組織運用が残った
RPRでruntime stateをかなり保持できるようになりました。
でも、Runtimeが正しく止まっても現実の組織には、
- 担当者不在
- authorityの期限
- AI model更新
- capability評価の失効
- Industry Profile
- incident operation
- expert review
- audit handoff
- adoption procedure
が残ります。
Runtimeが停止したあと、誰が次を引き取るのか。
ここはruntimeだけでは閉じません。
そこでResponsibility Pathway Operating System（RPOS / 責任経路OS）へ進みました。
RPOSでやりたいのは、責任を自動決定することではなく、責任経路を組織・業界・運用へ接続することです。
現在はJapan-firstを基本に、
RPF / RPOS Core
+
Japan-first evidence
+
Industry Profile
+
Adoption / Operations Runbook
+
Expert Review
+
Cost / Value Evidence
という方向を考えています。
ここで初めて、導入する側のメリットを考えた
RPOSまで考えたところで、技術とは別の問いが残りました。
これを実際に導入する側には、何のメリットがあるのだろう。
設計として筋が通っていても、導入する理由がなければ広がりません。
ここはまだ、私の提案と仮説の段階です。
RPEとRPRを作ってきた経験から、少なくとも公共側と企業側では、期待できる価値の見方が違うと考えています。
公共側: ガバナンス要求とsystem behaviorをつなげられるかもしれない
ガイドラインや制度には、説明責任、監督、監査、救済、安全確保といった要求があります。
一方、実際のAIエージェントや業務システムは、もっと細かい単位で動きます。
policy / guideline
↓
Requirement / Authority
↓
Gate
↓
Execution
↓
Evidence
↓
Verification / Return / Escalation
私はRPEを作る過程で、自然言語のガバナンス要求と、system behaviorの間にはかなり距離があると感じるようになりました。
責任経路は、その距離を埋める実装手段の一つになれるのではないか。
たとえば、
- 誰がどのauthorityで承認したか
- どこでHuman Gateを要求するか
- 外部作用をどう確認するか
- 結果不明を誰へ返すか
- 監査時に何のevidenceを再構成するか
- unresolvedな影響を誰が引き取るか
を実装・運用の対象にできます。
責任経路を入れれば法令適合や政策効果が自動的に保証される、という話ではありません。
私が提示したいのは、制度上の要求と実際のAIシステム運用の間に、確認可能な責任構造を置くことには価値があるのではないか、という可能性です。
企業側: Cost / Valueを測れる形にできるかもしれない
企業導入を考えると、安全性やガバナンスが重要であることだけでは、継続的な投資判断には足りません。
導入するなら、どこにコストがかかり、何を減らせたのかを見たい。
RPRを作っていると、責任対応にコストが発生する場所が見えてきます。
- approval待ち時間
- 結果不明時の調査工数
- 誤retry / 二重処理
- incident後のrepair / resume工数
- audit evidenceの収集時間
- expert reviewへ渡す前処理
- Industry ProfileやRequirement Packを作り直す重複
これらを経路として記録できれば、
導入・運用・review・incident対応コスト
vs
回避できた手戻り
短縮できた調査時間
再利用できたcontrol / evidence
減らせた監査・専門家対応負荷
を比較できるようになるかもしれません。
だからRPOSでは Cost / Value Evidence を扱いたいと考えています。
現時点で「RPOSを導入すればROIが何％改善する」と言える実測データはありません。
私が置いているのは、責任対応を測定可能なengineering objectへ変えられれば、企業の投資判断に必要なROIを検証できるようになるのではないかという仮説です。
公共側で考えているのはガバナンス要求と実装の接続。
企業側で考えているのは、そのうえでCost / Valueまで観測できるようにすること。
同じ責任経路でも、この二つを同じ導入理由として扱わない方がよいと考えています。
現在のstack
RPM Responsibility Pathway Model
theory / paper / model
RPF Responsibility Pathway Framework
implementation-neutral common reference structure
RPD Responsibility Pathway Design
patterns / anti-patterns / design knowledge
RPE Responsibility Pathway Engineering
machine-readable requirements / gate controls
RPR Responsibility Pathway Runtime
execution / effect / evidence / repair / resume
RPOS Responsibility Pathway Operating System
organization / profiles / operations / expert review / adoption
重要なのは略称を増やすことではありません。
同じ責任意味論を、理論→共通参照枠→設計→工学→runtime→現実の運用まで切らさずつなぐことです。
検索して来た人向け: 関連語との位置関係
AIガバナンス / Responsible AI
責任経路はAIガバナンス全体を置き換えません。
既存の要求を、authority、execution、evidence、repair、resumeへ落とす実装モデルです。
AIエージェント安全性
安全性だけでなく、authority、accountability、external effect、recoveryまで扱います。
Human-in-the-Loop / Human Oversight
重要な構成要素です。責任経路ではreturn conditionとauthorityまで明示します。
Audit Log / 監査ログ
重要なevidenceです。ただしログ量ではなく、責任経路を再構成できるかを重視します。
MCP
MCP自体が責任を保証するわけではありません。RPRではtool callを外部作用として責任経路へ接続します。
responsibility diffusion / responsibility gap
AI・人間・複数主体の意思決定で責任が分散・空洞化する近接問題として、既存研究文脈と接続して捉えています。
次の記事では実装へ
次の記事では、AIエージェントへ責任経路を実装する最小構成として、
- Actor Contract
- Capability
- Authority
- Evidence
- Responsibility Return Point
- Effect Unknown
- Repair / Resume
- RPE / RPR / RPOS
をPython風の疑似コードで具体化します。
RPFは、その実装で共通して見る対象を定義する参照枠として背景に置きます。
まとめ
発想史はこうです。
AIは責任を扱えない
↓
本当に？
↓
責任を「可逆性の残量」として捉える
↓
責任経路設計
↓
RPE
↓
Responsibility Pathway Layer
↓
RPR
↓
RPOS
現在の体系は、
RPM → RPF → RPD → RPE → RPR → RPOS
です。
最初から完成した体系図があったわけではありません。
作って、足りないものが見えて、また作る。その繰り返しでした。
AIに人格的な責任を押しつけたいわけではありません。
AIが途中に入っても、責任を扱うための構造が途中で消えないようにする。
それを理論から運用までつなげていく過程が、Responsibility Pathwayの現在地です。
現在の公開実装
RPEは要求・gate側、RPRは実行後の状態・evidence・repair / resume側です。コードを読むだけでなく、RPRはPyPIからそのまま試せます。
- Responsibility Pathway Engineering (RPE) — GitHub: https://github.com/YutoriKomeiji/responsibility-pathway-engineering
- Responsibility Pathway Runtime (RPR) — GitHub: https://github.com/YutoriKomeiji/responsibility-pathway-runtime
- RPR — PyPI: https://pypi.org/project/responsibility-pathway-runtime/
- RPR — Documentation: https://yutorikomeiji.github.io/responsibility-pathway-runtime/
- RPR — Demo: https://yutorikomeiji.github.io/responsibility-pathway-runtime/demo.html
pip install responsibility-pathway-runtime
現行の公開alphaは 0.1.0a4 です。production-readyやcustomer-environment verifiedを意味するものではありません。
この記事は2026年8月時点の経緯整理です。RPM manuscriptはPrivateです。RPOS、Responsibility Return Point、Cost / Value Evidenceには現在検討・開発中の内容を含みます。公開済み実装と、提案・仮説・将来設計は分けて読んでください。