Insynergy

AIエージェントを止められても、誰が決めるかは決まらない

AIエージェントを登録・監視・停止できても、停止後に誰が何を根拠に判断し、どこへエスカレーションし、誰が結果を引き受けるかは決まらない。返金判断の例から、技術的統制を判断権限、Decision Boundary、Decision Logへ結び直す必要性を示す。

金曜夜の承認待ち画面

架空の場面から始めよう。

ある通販事業者のカスタマーサポートに、AIエージェントが入っている。 問い合わせを読み、注文履歴と配送状況を照合し、回答を返す。

金曜の夜、そのエージェントが一件の申し立てに返金の実行を選んだ。 配送が3度遅れ、同じ顧客からの連絡は4回目。 処置は全額返金と次回クーポンの付与で、金額は自動処理の上限として決めていた1万円を超えていた。

画面には「人間の承認待ち」と表示されている。 承認ボタンは、確かにそこにある。

だが、この画面の前で決まっていないことがある。 この承認を押してよいのは誰か。 何を基準に押すのか。 押さなかったとき、誰へ上げるのか。 押したあとで返金が誤りだったと分かったとき、責任を負うのは担当者か、導入した部門か、上限を1万円と決めた誰かか。

承認ボタンがあれば、人間の判断は設計されたことになるのか。 本稿の答えは、ならない、である。 人間を処理の途中に置くだけでは、判断の主体も、基準も、責任も、停止の条件も、例外の扱いも、記録も定まらない。 Human-in-the-Loopは、判断できる場が用意されて初めて機能する。 それ自体が責任の所在を決めはしない。

統制はプラットフォームへ移る

統制をどこに置くかの問題として、この状況を整理した記事がある。 著者はRichard Fleming、Maria Teresa Tejada、Brendan O'Rourke、David AllenによるAgentic AI Governance, Risk, and Controls for Business Leaders（Bain & Company、2026年7月28日）である。

エージェントは一日に数千回、チケットを起票し、レコードを更新し、ワークフローを起動する。 一件ずつ人間が確認する前提は、もう成り立たない。 だからガバナンスは、文書ではなくプラットフォームに置くべきだ、というのが主張である。 文書の規則は、誰かが思い出して参照したときにしか働かない。 基盤のコントロールプレーン（実行を制御する層）に埋め込まれた統制は、すべての行動に働く。

挙げられた統制の領域は五つある。

本番業務でエージェントを動かすなら、この五つは備えるべき基盤である。

規程はあるのに、意思決定が変わらない

同じ日に、別の角度から同じ空白を指した記事がある。 Stephanie OverbyによるWhy AI governance is failing — and what actually works（CIO、2026年7月28日）だ。

論点は、ポリシーがあるかないかではない。 生きたAIインベントリを持ち、用途をリスクで分類し、統制を業務フローへ埋め込み、書かれた規則ではなく技術的な強制で効かせる。 評価指標で継続的に測り、使わなくなったエージェントを正式に廃止する。 そこまでやって初めて、ガバナンスは実際の意思決定を変える。 入ってきた案件がすべて承認されて出てくるなら、それはガバナンスではなく公証サービスだ、という一言が基準を示している。

数値はCIOの独自調査ではなく、外部の一次調査による。 Cloud Security AllianceがToken Securityとともに2026年4月21日に公表した調査では、過去12か月にAIエージェント関連のインシデントを経験した組織が65%、把握していないエージェントが自社環境で動いていた組織が82%、正式な廃止プロセスを持つ組織は21%だった。 EY Technology Pulse Poll（2026年3月4日公表）では、AI導入が事業リスクを管理する自社の能力を上回っていると答えたリーダーが78%にのぼった。

2つの記事を、どう読むか

Bainの記事はコンサルティング会社による実務提言であり、CIOの記事は複数の専門家と企業事例と外部調査を構成した業界メディアの報道である。 実務の観察として読む価値はあるが、学術的な合意や公的な規範と同じ地位では扱えない。

共通するのは4点だ。 統制は実装に置くこと、運用と停止と廃止まで見ること、可視性と継続的な評価を持つこと、最後は人間が説明責任を負うこと。 違いは、Bainが基盤側の統制領域を設計するのに対し、CIOは組織側、つまり誰が所有し、シャドーAIをどう減らし、放置されたエージェントをどう畳むかを問う点にある。

両方を重ねれば、エージェントは登録され、監視され、必要なら止められる。 それでも問いが残る。 AIエージェントを止められることと、どの判断を、誰の責任で、どこまで任せるかが設計されていることは、同じなのか。

同じではない。 停止できるという性質は、止めるべき瞬間を誰が判断し、止めなかった結果を誰が引き受けるのかを、何も決めないからだ。 冒頭の画面がそれだった。 上限一万円という統制は正しく働き、実行は止まった。 止まった先に誰がいるのかが、決まっていなかった。

日本の事業者に示されていること

この設計課題は、日本でも名指しされている。 総務省と経済産業省が2026年3月31日に公表したAI事業者ガイドライン（第1.2版）は、AIエージェントを「特定の目標を達成するために、環境を感知し自律的に行動するAIシステム」と定義した。 そのうえで、自律的に動作するがゆえに、判断が必要となる事項を重要度に応じて整理し、対象を選定したうえで人間の判断を適切に介在させる仕組みの構築が重要だとしている。 外部システムとの連携が増えることを踏まえ、連携先のツールや権限の制限、操作履歴の定期的な確認もあわせて示された（掲載ページ）。

ただし、これは法律ではない。 法的拘束力を持つ一律の義務ではなく、AI開発者、AI提供者、AI利用者がそれぞれ自主的に取り組むための指針である。 「すべてのAIエージェントの全行動について、事前の人間承認が義務づけられた」わけでもない。 示されたのは、重要度に応じて対象を選び、そこに人間の判断を介在させよ、という設計の要請だ。 どの事項が重要で、誰の判断をどの段階で介在させるかは、各社が決めるほかない。

判断は、どの枠組みの主題でもない

問うべきは、どのAIツールを導入したかではない。 この業務で、どの判断が行われ、誰に影響し、誰が責任を引き受けたのか、である。

この問いは、既存の枠組みのどれか一つには収まらない。 Governanceは、どのルールで監督するかを扱うが、業務の中の判断権限をどこへ置くかまでは決めない。 DXは、業務や価値提供をどう変えるかを扱うが、判断権限がどこへ移るかは計画に書かれないことが多い。 Automationは、どの処理を自動化するかを扱う。自動化できることは、委ねてよいことを意味しない。 AI Ethicsは、どの価値や原則を守るかを扱うが、価値が衝突した瞬間の承認、停止、例外、記録の実装までは含まない。

どれも必要であり、足りないことは不要を意味しない。 判断の配置という対象が、どの枠組みの主題でもないというだけである。

いま欠けているもの

いま組織に欠けているのは、AIを監視する規則ではない。 規程も、審査会も、アクセス制御も、監査ログも、多くの企業はすでに持っている。 欠けているのは、AIの自律性、技術的統制、業務権限、人間の責任を、「誰が何を決めるか」という一つの構造へ結び直す設計である。

ここから先では、この欠けた設計をDecision Design™︎（判断の設計） として定義する。 そのうえで、冒頭の返金判断を例に、AIへ任せる範囲、人間が引き受ける範囲、承認と停止と例外と記録の境界を、実装できる形へ落とす。 承認ボタンを押すのは誰で、何を見て、どれだけの時間で、どんな権限のもとに判断するのか。 押さなかった場合、誰へ何分以内に上がるのか。 押したあとの説明責任は誰が負うのか。

この不足、つまりAIの自律性、技術的統制、業務権限、人間の責任を「誰が何を決めるか」へ結び直す設計を担うのが、Decision Designである。 Decision Designは、判断という行為そのものを設計対象とする思想だ。 その中心にあるのが、Decision Boundary™︎という概念である。 誰が決めるのか。 どこまでを任せ、どこからを引き受けるのか。 その線を無自覚のまま放置せず、意図的に設計すること。 それがDecision Designである。

Decision Designは、何を設計するのか

Decision Designとは、判断という行為そのものを設計対象とし、誰が何をどこまで決めるのかを事前に定める考え方である。

何についての判断で、主体は誰か。 AIへ委ねる範囲はどこまでで、人間または組織が引き受ける範囲はどこからか。 どのデータを根拠に、どの条件で実行し、どの条件が現れたら止めるか。 例外は誰がどう扱い、どこへ上げるか。 何を記録し、誰が説明責任を負い、いつ境界を見直すか。

Decision Designは、何ではないのか

Decision Designは、AI利用規程の別名ではない。 守るべき項目を並べたチェックリストでもない。 すべての判断を人間へ戻す思想でもなければ、AIを信用しないための概念でもない。

Decision Designは、どの問題に対する概念なのか

Decision Designが向き合うのは、AIによって判断の能力が拡張され、代替され、分散される一方で、判断の主体と責任の所在が曖昧になる問題である。 なお、Decision DesignとDecision Boundaryは確立された法律でも公的規格でも学術用語でもなく、本稿が提示する設計概念である。

4つの枠組みを、判断で貫く

Decision Designは、Governance、DX、Automation、AI Ethicsを置き換えない。 判断という共通の対象を通じて、その4つを横断し、実装へつなぐ。 Governanceの規則はどの判断にどの条件として効くのかへ翻訳され、DXが描いた業務の流れは判断権限がどこへ移るのかとして具体化される。 Automationが選んだ対象は自動実行してよい判断の範囲になり、AI Ethicsが掲げた価値は、衝突したときの停止条件と最終判断者の指定になる。

Decision Boundaryとは何か

Decision Boundaryとは、AIに委ねる判断と、人間または組織が引き受ける判断とを分ける境界である。 「このAIを使うか、使わないか」という製品単位の線ではなく、判断の一つひとつに引く線である。

返金判断に、境界を引く

冒頭の場面に、この境界を引いてみる。 以下は設計例であり、金額の水準は各社が損失許容度、取消可能性、顧客への影響に応じて決めるものだ。

何を判断し、誰に影響するのか

出発点は、「返金する」という一つのアクションを判断の単位まで分解することである。 申し立ての事実関係は認められるか。 責任は自社か、配送業者か、顧客側の事情か。 返金、再送、部分返金、クーポンのどれを選び、金額をいくらにするか。 今回限りの処置か、以後の取引条件を変えるのか。

影響の届く先も書き出す。 返金を受ける顧客、返金額を負担する会社の収益、同種の申し立てを受け続ける担当者。

AI、人間、最終判断者の役割

AIが担うのは、事実の照合と選択肢の提示までとする。 注文履歴、配送記録、対応履歴、契約条件を突き合わせ、処置案とその根拠、反対材料、金額の内訳を示す。

そのうえで権限を段階に分ける。 可逆で影響の小さい判断（少額の部分返金、再送の手配、クーポンの付与）は、条件を満たす限りエージェントが実行してよい。 一定額を超える返金、繰り返される申し立て、不正の兆候がある案件は、提示までで止める。 取引条件の変更や契約解除を伴う処置は、事業側の責任者へ渡す。

最終判断者を「担当者」とだけ書かない。 金額は返金権限を持つ役割へ、不正の疑いは不正対応の所管へ、重要顧客との関係は営業側の責任者へ割り当てる。 説明責任を負うのは、ボタンを押した個人ではなく、その権限を割り当てた役割である。

使えるデータ、採用条件、停止条件

参照できる情報は、注文履歴、配送記録、契約条件、対応履歴、返金規程といった、この判断に必要な範囲へ限定する。 他の顧客の情報や目的外の個人データは、判断材料に加えない。 データの最小化は、セキュリティ統制であると同時に判断境界の一部である。

採用条件は金額だけで決めない。 顧客への影響、取消可能性、事実照合の確からしさ、不正の兆候を条件に組み込む。 設計例としては、3千円以下かつ取消可能かつ照合済みなら自動実行、3万円までは権限を持つ人間の承認付き実行、それを超えるか不正の兆候があれば提示のみ、となる。

停止条件も先に決めておく。 根拠データが欠けている、古い、矛盾している。 規程と過去の対応履歴が食い違い、判断が競合している。 規定額を超え、取消や再請求ができず不可逆になる。 同一顧客や同一手口からの申し立てが短期間に集中している。 これらが現れたら、エージェントは自動実行に進まない。

例外とエスカレーション

止めたあと、誰へ、何を、どの時間内に引き継ぐのか。 承認権限を持つ担当者が不在なら、何分待って次に誰へ回すのか。 返金期限や決済の締めが迫る案件では、待たせること自体が損失になる。 重要顧客、複数契約の競合、不正検知は、引き継ぎ先がそれぞれ違う。 宛先と制限時間と引き継ぐ情報を、例外の種類ごとに決めておく必要がある。

記録と説明責任、そして見直し

残すのは、システムの動作ログではない。 参照した情報とその版、提示した選択肢、適用した規程、人間が承認したのか修正したのか拒否したのか、その理由、結果と金額。 後から「誰がどの判断を引き受けたか」を説明できる形にする点が、システムログとの違いである。

境界は一度引いて終わりではない。 誤った返金や不正の通過が起きたとき、モデルや規程が変わったとき、評価で自動実行の精度や差し戻し率が想定と食い違ったとき、引き直す。 承認率が極端に高い、承認までの時間が短すぎるといった兆候も、追認が起きているサインとして扱う。

承認ボタンを、判断にする

承認を判断にするには、承認者に次のものが要る。 何が変わり、誰にいくらの影響が及ぶのか。 使われたデータと、その鮮度や欠損。 推奨の理由と反対材料、処置の可逆性と戻す手順。 判断に使える時間。 そして、承認、差し戻し、条件変更、停止を選べる権限。

このどれかを欠いた承認は、判断ではなく追認である。 結論は「人間を増やす」ではない。 低リスクで可逆な判断は条件付きで自動化し、価値が衝突する判断と不可逆な判断を、人間または組織が引き受ける。

5つの統制領域を、境界へつなぐ

Bainの五領域も、CIOが求めた実効性も、Decision Boundaryの実装要素として読み直せる。 アイデンティティはどの金額までどの処置を実行してよいかという権限の段階になり、行動の制限は自動実行できる判断の外縁、コンテキストの規律は何を参照させ何を参照させないかの指定になる。 可観測性と評価は停止と巻き戻しが実際に効くことの検証であり、説明責任は最終判断者の指定と判断の記録として具体化される。 AIインベントリは判断権限の一覧に、リスク分類は判断ごとの影響と取消可能性の評価になり、廃止プロセスは、権限を持ったまま誰も見ていないエージェントを畳む手続きになる。

小さく始める

全社のAI利用を一度に設計し直す必要はない。 一つの業務から始められる。

押されなかったボタンの意味

冒頭の画面へ戻ろう。 1万円という上限は、統制としては正しく働いていた。 働いていなかったのは、その線の意味である。 なぜ1万円なのか、超えたら誰が引き受け、何を見ていつまでに決めるのか。 どれも決まっていなかったから、承認ボタンは、責任が宙に浮いたまま止まる場所になった。

Decision Boundaryが設計された組織では、同じ画面が違う意味を持つ。 1万円は、可逆性と不正の兆候と照合の確からしさを織り込んだうえで、返金権限を持つ役割が引き受けると決めた線である。 承認画面には、影響、根拠データ、反対材料、戻す手順、残り時間が並び、30分以内に動かなければ案件は上位の役割へ上がる。 押しても、押さなくても、誰が何を決めたかは記録に残る。

AIエージェントを止められることは、必要だが十分ではない。 止まった先に誰がいるのかを決めていなければ、統制は責任の所在を教えない。 誰が決めるのか。 どこまでをAIへ任せ、どこからを人間または組織が引き受けるのか。 その線を引けるのは、ベンダーでもガイドラインでもなく、それぞれの組織だけである。

参考資料

Read the original English analysis (English) →note版を開く →