「誰の責任か」を決めた、その後どうする？
AIを業務に組み込むとき、多くの現場がまず考えるのは「責任をどこに置くか」だ。誰が承認するのか、どの条件では止めるのか、証跡はどう残すのか。その整理は確かに必要だし、やらないよりやった方がずっといい。
ただ、ひとつ問いを立てたい。「責任を固定した」その後、その設計は動くことを前提にしているか。
Zennに掲載された「責任固定から責任経路設計へ」という記事は、AIガバナンスのこの盲点を正面から扱っている。著者はSAP/ERPの現場経験を持つ実務家で、「システムが正しく動いた、承認も通っていた、ログも残っていた、それでも後から見ると誰が止められたのかが曖昧になることがある」という体験からこの議論を立てている。
責任固定が必要な理由は明確にある
記事はまず、責任固定の意義を丁寧に認めている。なぜ固定が必要かというと、AIが絡む判断では責任が「外へ押し出されやすい」からだ。
- AIは「判断材料を作っただけ」と言う
- 人間は「AIの提案を確認しただけ」と言う
- ツールは「承認済みの操作を実行しただけ」と言う
- 組織は「運用ルールに従っただけ」と言う
こうして、各主体が少しずつ責任を外へ押し出す。結果として責任が空白化する。だから停止境界・責任境界・承認境界・証拠ログを事前に定義することには意味がある、というのが記事の出発点だ。ここは否定していないし、むしろ「曖昧なままAIを業務へ入れるくらいなら、まず固定すべきものは固定した方がよい」と明言している。
ここまでは、多くのAIガバナンス議論と重なる。問題はここから先だ。
しかし固定は「一断面」にすぎない
記事が核心として提示するのは、「責任固定は責任設計の全体ではない」という主張だ。著者はこれを「責任固定はスナップショットであり、恒久凍結ではない」と表現している。
固定後に残る問いとして、記事は具体的にこれだけ並べている。
- その固定条件は妥当だったのか
- 固定時の前提そのものは正しかったのか
- 承認者は実質的に理解していたのか
- UIや組織圧によって追認になっていなかったか
- 後発事実によってリスク評価が変わらなかったか
- 停止後に誰が修復するのか
- ログは判断文脈や判断圧まで再構成できるのか
特に印象的なのが「前提経路（Premise Pathway）」という概念だ。どれだけ厳密に責任境界を固定しても、判断の前提が誤っていれば固定される責任も誤る、という指摘だ。「誤った前提→正しい形式処理→もっともらしい結論→責任固定→異議申し立て困難」というフローで図示されている。ERPの現場でも同じことは起きる、と著者は言う。仕様書や業務前提が間違っていれば、その後の設計・承認・ログがどれだけ整っていても結果はずれる。
記事中の営業メールの例が、これをよく示している。AIが作った営業メール案を人間が承認して送った。後から、そのメールが契約上の誤解を生む表現だったと分かった。さらに、AIが参照したのは誤った社内資料だった。承認者は時間に追われ本文を十分に読んでいなかった。ツール画面はリスクを分かりやすく表示していなかった。このとき責任は「承認者に固定済み」で終わるのか。記事はそうではないと言う。AI入力の文脈・社内資料の管理・承認UI・業務圧・送信権限・レビュー体制、それぞれに責任比重が分配される、と。
「固定後再評価」をどう実務に引き寄せるか
ここからは、実務での読み方だ。
記事が提示する「Evidence Log」の定義が面白い。単なるイベントログではなく、「後から責任経路を再構成できる証跡」であるべきだ、とある。誰が依頼し、AIにどの文脈が渡され、承認者は何を見て、どの条件で実行され、どこで止められなかったのか、失敗後に誰が修復したのか。これらがつながっていなければ、固定された責任境界も後から検証できない。
ここは、多くの現場で見落とされている点だと思う。「ログは残っている」と言うとき、それはイベントの記録なのか、それとも判断の文脈まで追えるものなのか。その差が、後から責任を再評価できるかどうかを分ける。
もうひとつ、「Stop Authority（停止権限）を実行権限と分離する」という設計の話も実務的に刺さる。AIエージェントでは実行が簡単になるほど停止判断が遅れる。「業務を止めたくない」「自動化の流れを止めたくない」という圧力があるからこそ、停止権限は意識的に別軸で設計しないと機能しない、という指摘だ。
OpenAIが2026年4月に示した5原則のひとつ「適応性」にも触れており、一度決めた責任境界を永続的に正しいものとして扱えないという考え方が、この責任経路設計の考え方と重なると著者は読んでいる。
実務への示唆：「固定で終わり」になっていないか点検する
この議論が示しているのは、AIガバナンス設計における「安心の落とし穴」だ。責任固定を完了した瞬間に、固定後の動きを考えるインセンティブが消える。「ここで責任は確定している」という言い方が、後発事実を受け取る経路を塞ぐ。
実務担当者が今すぐ点検できることとして、三つ挙げてみる。
一つ目は、承認フローに「形式承認」と「実質承認」の区別があるかどうかだ。画面を見て「承認」を押したことと、内容を理解して承認したことは違う。組織圧や時間圧がある状況での承認は、実質的に追認になっていないか。
二つ目は、ログが「責任経路を再構成できるか」という観点で設計されているかどうか。AIに何を渡したか、承認者が見た画面に何が表示されていたかまで残っているか。
三つ目は、失敗後に「誰が修復するか」が決まっているかどうか。これを事前に決めていないと、固定された責任が「責任は確定済みなので対応不要」という方向へ逃げる口実になりうる。
「固定」は起点であって終点ではない
この記事が主張する「責任経路設計（Responsibility Pathway Design）」は、責任固定を否定しているわけではない。固定を「観測点」として位置づけ、その後の再評価・修復・再配分まで設計の対象に含める、というアプローチだ。
「責任を固定したあとに責任を動かせない設計こそが危険である」という文が、この記事の核心だと読んでいる。固定は必要だが、固定は終点ではない。その後に責任がどう移動し、どう修復され、どう人間や組織へ戻るかを経路として設計する。それがAIエージェント時代に求められるガバナンスの姿だ、という議論だ。
同種の議論が今後も増えてくると思う。そのとき見るべきは、「責任をどこに置くか」だけでなく、「固定後の再評価経路があるか」だ。その軸をひとつ持っておくだけで、ガバナンス設計の議論の見え方がかなり変わる。
