「AIは責任を負えない」だけでは、説明として足りない
Ownershipの記事で、 責任（アカウンタビリティ）の層だけは人間からAIへ移せない、と書きました。 「AIは責任を負えない」という一文は、直感的には正しいのですが、 実務ではそれだけでは足りません。 なぜ既存のリスク管理の仕組みが、AIエージェントに対して機能しにくいのか を構造的に理解しないと、対策は打てないからです。 「誰が責任者か」を突き詰めていけば、最終的には人間に行き着く—— これ自体は正しい結論です。しかしその手前にある 「なぜ従来のやり方では、その人間にすんなりたどり着けないのか」 という問いこそが、実務上はるかに重要です。
既存のリスクフレームワークが前提にしてきた三つのこと
ソフトウェア工学のリスク管理は、成熟した枠組みを持っています。 機能ごとの所有、深刻度によるエスカレーション、テストカバレッジによる保証——。 しかし、これらの枠組みは暗黙のうちに、次の三つを前提にしています。
- 決定論的な振る舞い：同じ入力には、同じ出力が返る
- 離散的で監査可能な変更イベント：「いつ、何が変わったか」を追跡できる
- 明確なコンポーネントと所有者の対応：この部分の責任者は誰か、が一意に定まる
Agenticシステムは、この三つを同時に破る
2026年の論文 "Risk Architecture for AI-Native Engineering Teams" は、この破綻を正面から論じています。
「Agenticなシステムを構築・運用するチームは、この三つの前提を同時に破る。 出力は確率的であり、システムは自律的に複数ステップの行動を取り、 リスク面はデプロイの間で静かに変異する。」
同じプロンプトを与えても、AIエージェントは毎回同じ判断をするとは限りません。 一つの変更が、人間が把握しきれない複数ステップの行動として実行されます。 そして、モデルやツールの更新によって、 リスクの性質そのものが「気づかないうちに」変わっていきます。 従来のリスク管理の道具立ては、この三つのどれとも噛み合いません。
論文はさらに、既存の枠組みでは名前すらついていなかった 失敗モードのクラスターを一つ提示しています。 「依存境界の決定論ミスマッチ（dependency-boundary determinism mismatch）」 と呼ばれるものです。次のセクションで、これが何を意味するかを見ていきます。
既存の対策は「上から」か「下から」——真ん中が空いている
では対策がないわけではありません。 ただし論文は、既存の対策には空白があると指摘します。
一つは「上から」のアプローチ——NIST AI RMFやISO/IEC 42001のような、 組織全体を対象にしたポリシーフレームワークです。 もう一つは「下から」のアプローチ——OWASPのAgentic AIガイダンスのような、 個別の脅威を分類する技術的なリストです。
この二つは、それぞれの役割を果たしています。 NIST AI RMFやISO/IEC 42001は「組織としてAIリスクにどう向き合うか」という 経営レベルの指針を与え、OWASPのガイダンスは 「プロンプトインジェクション」「権限昇格」のような、 現場のエンジニアが警戒すべき具体的な攻撃パターンを教えてくれます。 どちらも有用ですが、どちらも日々の運用の設計図ではありません。
しかし論文が指摘するのは、 この二つの間、エンジニアリングマネージャーが実際に運用する層—— 役割、意思決定権、エスカレーション構造——がまだ手薄 だという点です。方針は立派でも、脅威リストは詳細でも、 「では今日、誰が何を承認し、何かあれば誰に報告するのか」という 現場の運用設計が抜け落ちているのです。
最も危険な場所は、AIチームの内部ではない
この論文で最も興味深い発見は、危険の所在です。 リスクへの対応力は、純粋なソフトウェア工学からAI-Nativeなチームへ移行するにつれて 低下していきますが、最も深刻で、最もカバーされていない失敗は、 AI-Nativeなチームの内部ではなく、その確率的な出力が 決定論的な前提を持つ他のシステムに消費される「組織の境界」で起きる というのです。
つまり、AIエージェントを使いこなしているチーム自身よりも、 そのアウトプットを無条件に信頼して使う、隣のチームやシステムの方が危険 だということです。AIチームが「これは確率的な提案です」と理解して扱っていても、 それを受け取る決定論的なバッチ処理や、他部署の承認フローが 「常に同じ結果が返る」前提で設計されていれば、そこに歪みが蓄積します。
これが「依存境界の決定論ミスマッチ」の正体です。 具体的な例で考えてみます。 AIエージェントが「この顧客セグメントには値引きを推奨する」という 提案を生成したとします。この提案自体は確率的で、 同じ条件でも次回は違う推奨を出すかもしれません。 ところが、それを受け取る請求システムが 「一度承認された推奨は、常に同じロジックで処理される」 という決定論的な前提で設計されていたらどうなるでしょうか。 AIチームの中では何も間違っていないのに、 境界を越えた瞬間に、想定外の値引きが大量に適用されるという 事故が起こり得ます。
だから「検証の網」は、チームの境界を越える必要がある
Ownershipの記事で、 責任を果たすための投資として「検証の網・観測性・可逆性」の三つを挙げました。 この論文の発見が付け加えるのは、 この投資はチームの内側だけでは完結しないという視点です。
自分たちのAIエージェントの出力がどこに消費されているか、 その受け手が「確率的である」ことを前提に設計されているかどうかまで、 責任の範囲として見なければなりません。 役割、意思決定権、エスカレーション構造—— この論文が「空白」と呼んだ真ん中の層を埋めるのは、 結局のところ、境界をまたいで会話できる人間の仕事です。
これは偶然にも、 Scrum Masterの記事で描いた「Human-AI Systems Coach」の仕事とも重なります。 ポリシーでも脅威リストでもない、現場の役割と意思決定権とエスカレーションという 真ん中の層を日々設計し、更新し続ける人——それはまさに、 進行係から転身したシステムコーチが担うべき仕事の一部です。
自己診断のための問い
- 自分たちのAIエージェントの出力を受け取っているシステムやチームは、その出力が確率的であることを認識しているか
- 「いつ、何が変わったか」を追跡できない領域が、自分たちのシステムのどこかに残っていないか
- ある機能の責任者を尋ねられたとき、一意に答えられる範囲はどこまでか。答えに詰まる境界線はどこか
- ポリシー文書（上から）と脅威リスト（下から）は整備されているが、日々の承認・エスカレーションの運用（真ん中）は誰が設計しているか
おわりに
「AIは責任を負えない」は結論であって、説明ではありません。 本当に理解すべきは、確率的で自律的なシステムを前提に設計されていない 組織の隙間に、リスクが静かに溜まっていく構造です。 人間の判断力が最後まで担うべき仕事は、 コードを読むことでも、承認印を押すことでもなく、 この隙間そのものを見つけ、埋め続けることなのかもしれません。