Insynergy

AIエージェントの送信ボタン――人間承認は誰の判断か

AIエージェントが一斉メールを送る直前、人間が押す「承認」ボタンは何を意味するのか。ログや監督だけでは、誰がどの判断を引き受けたかは定まらない。本稿は、配信対象・利用データ・文面・規模・例外を判断単位へ分解し、Decision Boundary、拒否権、エスカレーション、Decision Logによって実質的な承認を設計する方法を示す。

ある日本企業のマーケティング部で、AIエージェントが顧客12,418人への一斉メール配信を実行に移した。CRMから配信対象を抽出し、顧客ごとに文面を生成し、配信時刻を最適化し、配信システムを操作する。担当部長の画面には、すでに「承認済み」と表示されている。

形式のうえでは、人間の承認工程を通っている。だが、部長が承認したのは何だったのか。文面か。配信対象か。個人データの利用範囲か。12,418件という規模か。それとも、通常なら手動で除外するはずの例外顧客を、今回に限って含めるという判断か。画面の「承認済み」の4文字からは、そのどれを引き受けたのかが読み取れない。

これは論点を示すための架空の場面である。しかし、AIエージェントを業務に入れ始めた組織なら、遠からず自社の画面で似たものを見ることになる。そこで本稿が立てる問いは1つだ。

人間承認のボタンは、誰の、どの判断を引き受けたことになるのか。

「仕事を進めるAI」への移行を、IBMは的確に描いた

IBM Thinkが公開する解説記事『What are AI agents?』（著者 Anna Gutowska、媒体 IBM Think、URL: https://www.ibm.com/think/topics/ai-agents ）は、AIエージェントを「利用可能なツールを使ってワークフローを設計し、自律的にタスクを遂行するシステム」と定義する。従来のチャットボットが主に「応答する」のに対し、AIエージェントは目標を分解して計画し、外部ツールや他のエージェントを使って推論し、外部環境へ行動し、フィードバックから改善する。応答するAIから、仕事を進めるAIへ。この移行を、IBMの整理は明快に体系化している。ベンダー発の解説であることは割り引く必要があるが、能力の輪郭を掴む一次情報として有用だ。

同記事は、エージェントの行動を左右する主体として3者を挙げる。設計し訓練する開発チーム、導入して利用者に提供するチーム、そして具体的な目標と使えるツールを与える業務ユーザーである。ここに最初の難しさがある。行動に影響する主体が増えるほど、「最後に責任を引き受ける1人」の輪郭は薄れていく。誰もが少しずつ関与し、誰も全体を引き受けていない、という状態が生まれやすい。

4つの安全策は必要だが、それだけでは「誰が決めるか」は決まらない

IBMは実務的な安全策を4つ挙げる。行動履歴を残すActivity logs、暴走や長時間実行を人間が止めるInterruption、エージェントの開発者・導入者・利用者を追跡可能にするUnique agent identifiers、そして一斉メール送信や金融取引のような影響の大きい行動の前に人間の承認を求めるHuman supervision。マルチエージェント依存、無限フィードバックループ、計算複雑性、データプライバシーといったリスクに対し、これらはいずれも欠かせないコントロールである。否定する理由はない。

問題は、これらが揃っても、なお決まらないものがある点だ。ログがあれば「何が起きたか」は後から辿れる。だが、誰がその判断を引き受けるかは、ログには書かれていない。固有IDがあれば行動の出所は追える。だが、開発者・導入者・業務責任者の間で責任がどう分かれるかは、IDだけでは決まらない。中断ボタンがあれば止められる。だが、いつ止め、いつあえて止めないかを誰が決めるかは、ボタンの存在とは別問題だ。そして人間承認があっても、承認者が何を確認し、何を拒否できるのかが定義されていなければ、承認は判断ではなく追認になる。

言い換えれば、これらは判断を支える道具であって、判断権限の配置そのものではない。

日本でも、論点は「人の介在」から「判断責任」へ進んだ

この空白は、日本の政策文脈でも意識されつつある。総務省・経済産業省が令和8年3月31日に公表した「AI事業者ガイドライン（第1.2版）」は、AIエージェントを「特定の目標を達成するために、環境を感知し自律的に行動するAIシステム」と定義したうえで、その別添のリスク整理において、「AIエージェントの場合、自律的な動作の中で人間の意図しない商品の注文やファイル削除等の動作を行う可能性がある」と明記している（本編、別添（付属資料））。同別添はさらに、AIエージェントの自律性が高まるにつれ、人間による監視のみでは高速なAI間相互作用への対応が困難となる場合が想定される、とも述べている。人を1人挟めば安全、という発想の限界を、指針自身が示しているわけだ。

ただし位置づけには注意がいる。このガイドラインは法律上の一律の義務ではなく、リスクや各主体の資源制約を踏まえた自主的な取組の指針である。ガイドラインが主に公平性の文脈で説く「人間の判断の介在」も、AIの出力結果が公平性を欠くことがないよう、AIに単独で判断させるだけでなく、適切なタイミングで人間の判断を介在させる利用を検討したうえで、潜在的なバイアスに留意する、という趣旨で書かれている（概要）。すべてのAIエージェントに、すべての行動前の人間承認を法的に義務づけたものではない。

より踏み込んだ問題意識は、内閣府科学技術・イノベーション推進事務局が令和8年4月にまとめた「人工知能基本計画の改定に向けて（議論のたたき台）」に見える。これは確定した規制や最終計画ではなく、議論のための資料である。そのうえで同資料は、本稿にとって決定的な懸念に触れている。Human-in-the-loopにおいて、人間が責任を取るためだけに一連の流れの中へ置かれてしまう、という懸念だ。人間を挟むこと自体が目的化すれば、承認は責任の儀式に堕する。

その後、令和8年7月14日、政府は第II期の「人工知能基本計画」を閣議決定した。確定した計画は、人が意思決定に対する責任を持つことを掲げ、その責任のあり方としてHuman-in-the-loop、Human-on-the-loop、Human-in-the-leadという3つの考え方を示している。また、自律行動型AIによって権利侵害や損害が生じた場合の責任分界を継続的に検討し、「人がAIとどう関わり、いかなる判断を担うのか」を継続的に探究するとしている。

ただし、この計画は国の政策であり、個別の企業業務で誰が何を承認すべきかを直接割り当てる法律や一律ルールではない。それでも、政策上の問いは「人間を入れるべきか」から「人間がどの判断を担い、どの責任を引き受けるのか」へ進んだ。ここから引き出せる要旨は、こう1文にできる。人間承認は、判断対象・判断材料・権限・拒否可能性が定義されて初めて、実質的な判断になる。

問いを「どのAIを使ったか」から「誰がどの判断をしたか」へ

だとすれば、経営が問うべきことは変わる。「どのAIエージェント製品を導入したか」ではなく、「その業務で、誰がどの判断を引き受けたか」である。ツールの選定は入口にすぎない。一斉メールの例で本当に問われているのは、配信対象・利用データ・文面・規模・時刻・例外という個々の判断を、誰がどの権限で引き受けたのか、という業務上の事実だ。

この転換は、既存の取り組みを否定するものではない。むしろ、それぞれの守備範囲と、単独では残る空白を冷静に見たほうがよい。Governanceは「どのルールで監督するか」を定めるが、個々の判断権限を誰にどう配置するかまでは自動的には決めない。DXは「業務や価値提供をどう変えるか」を描くが、その過程で判断権限がどこへ移るかまでは自動的には決めない。Automationは「どの処理を自動化するか」を扱うが、どの判断まで機械に委ねてよいかは別の問いだ。AI Ethicsは「どの価値や原則を守るか」を示すが、承認・停止・例外・エスカレーション・記録を具体的な業務手順へ落とし込む作業とは同じではない。

4つはいずれも役割を持ち、どれも不要ではない。それでも、判断権限の配置という1点は、4つのどれかに自動的に含まれてはいない。ここが構造的な空白だ。

足りないのは「判断単位への分解」である

いま多くの企業に欠けているのは、ログ・固有ID・中断・人間承認という個別の安全策を、一斉メールで言えば配信対象・利用データ・文面・規模・時刻・例外という判断単位へ分解し、そのそれぞれについて「どこまでをAIへ委ね、どこからを人間または組織が引き受けるのか」を一貫して管理する設計である。安全策は点として存在するのに、判断の線が引かれていない。「課題がある」でも「ガバナンスが必要だ」でもなく、欠けているのはこの分解と接続の設計だ。

次に問うべきは、この欠けた設計を、冒頭の一斉メール配信AIエージェントへどう具体的に落とし込むか、である。配信対象・文面・利用データ・送信規模・例外処理の境界をどこに引くのか。承認者に何を見せ、どの権限で拒否できるようにするのか。「承認済み」を責任の儀式ではなく、差し戻し可能な実質的判断へ変えるには何がいるのか。ここまでの安全策を、そのまま使いながら一段深める必要がある。

この不足を埋めるのが、Decision Design™︎である。Decision Designは、判断という行為そのものを設計対象とする思想だ。その中心にあるのが、Decision Boundary™︎という概念である。誰が決めるのか。どこまでを任せ、どこからを引き受けるのか。その線を無自覚のまま放置せず、意図的に設計すること。それがDecision Designである。

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

Decision Designは、判断という行為そのものを設計対象とする。具体的には、何を判断するのか（判断対象）、誰が判断するのか（主体）、どこまでをAIへ委ね、どこからを人間が引き受けるのか、どのデータを使ってよいのか、何を基準に採否を決めるのか、どの条件で承認し、どの条件で止めるのか、例外をどう扱い、誰へエスカレーションするのか、何を記録し、誰が説明責任を負い、いつ境界を見直すのか。これらを1つの設計対象として束ねる。

「AIを導入する」でも「人間を入れる」でもない。その中間にある無数の判断を、放置せず設計するということだ。

Decision Designは、何ではないのか

Decision Designは、AI利用規程の別名ではない。守るべき項目を並べたチェックリストでもない。すべての判断を人間へ引き戻す思想でもなければ、AIを信用しないための概念でもない。むしろ逆で、AIへ安心して委ねられる範囲を明確にするために、引き受ける範囲を先に定める発想である。委任と留保の線を意図的に引くからこそ、委任の側を広げられる。

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

Decision Designが向き合うのは、次の問題だ。AIによって判断能力が拡張され、代替され、複数の主体やエージェントへ分散されていく一方で、判断の主体と責任の所在が曖昧になる。能力は増えたのに、誰が引き受けているかが見えない。この非対称を埋めるための概念である。なお、Decision DesignもDecision Boundaryも、確立した法律や公的規格、既存の学術用語ではない。判断を設計するための実務的な枠組みとして本稿が用いる呼び名である。

Decision Boundaryの定義

Decision Boundaryとは、AIに委ねる判断と、人間または組織が引き受ける判断との境界である。この線を引くことが、Decision Designの中核作業になる。冒頭のAIエージェントに、実際に引いてみる。

まず、一斉メールという1つの「承認済み」を、複数の判断へ分解する。誰を配信対象に含めるか。どの顧客データを使ってよいか。どの文面・表現・オファー・価格を採用するか。何件まで、いつ送るか。配信停止希望者、未成年、センシティブ属性を含む顧客、苦情対応中の顧客といった例外をどう扱うか。誤配信や異常を検知したとき、停止・継続・撤回・訂正のどれを選ぶか。これらはすべて別種の判断であり、1つのボタンに潰してはならない。

そのうえで、AIへ委ねられる範囲を定める。承認済みテンプレート、承認済みのデータ項目、既存の同意範囲の内側、通常の配信規模、事前に定めた対象条件、禁止表現チェックを満たす定型配信――ここは自動実行の候補にできる。AIは、候補抽出、文面の個別最適化、重複・配信停止・禁止表現の検査、送信時間の最適化、異常検知を担う。ここを人間が1件ずつ見るのは、むしろ実効性を下げる。

一方、人間または組織が引き受ける範囲も明示する。新しい顧客セグメント、センシティブ属性の利用、当初と異なる目的でのデータ利用、一定件数を超える配信、法的・社会的に誤認を招きうる表現、特別価格、取り消しの難しいオファー、重大な苦情が予測される配信――ここは委ねない。しかもその引き受け手を、漠然と「担当者」で済ませない。文面はマーケティング責任者、データ利用は個人情報保護責任者、表現の適法性は法務、というように、判断内容と権限に応じて最終判断者を定義する。

「承認済み」を、拒否可能な判断に変える

Human-in-the-loopは、人を挟むだけでは実質を持たない。承認者に、判断できる材料を、判断できる時間の中で渡してはじめて意味を持つ。この一斉メールなら、承認者へ提示すべきは、配信対象数、抽出条件と除外条件、利用データ、テンプレートからの変更点、反対材料や異常値、過去の苦情率、配信停止の可逆性、そして「いつまでに判断すべきか」という時間である。そのうえで承認者が、差し戻し・対象縮小・文面変更・停止を選べる状態をつくる。承認しかできない画面は、承認ではなく追認を強制する。加えて、AIの推奨をそのまま通し続ける自動化バイアスを、追認率のモニタリングで監視する。

停止・例外・エスカレーションも設計する。同意情報が確認できない、CRMと配信システムで件数が一致しない、通常を大きく上回る配信数、禁止属性の推定、文面の法的表現チェック不合格、外部ツールの想定外応答――こうした事象を停止条件として定義し、影響に応じてマーケティング・法務・プライバシー・情報セキュリティへエスカレーションする。ただしIBMがInterruptionの項で指摘するとおり、止めることが常に最善とは限らない。送信の途中停止、撤回メールの追送、対象を限定しての継続、手動運用への切替など、状況に応じた安全なフォールバックまで含めて設計しておく。止める権限と、止めない判断の責任を、あらかじめ置く。

IBMの4つの安全策を、判断設計へ接続する

ここでIBMの4つは、否定されるのではなく、一段深く接続される。Activity logsは「何が起きたか」の記録にとどめず、利用データの版、配信対象条件、生成文面、適用ルール、呼び出したツール、関与した各エージェントの固有ID、承認者・承認対象・承認理由・例外・停止・配信結果までを残すDecision Logへ進める。「誰がどの判断を引き受けたか」を後から説明できる記録にする、ということだ。Unique agent identifiersは、エージェントを追跡する用途を超えて、開発者・導入者・業務責任者との責任関係を結び直す鍵として使う。Interruptionは、停止ボタンの実装で終わらせず、停止条件・停止権限・停止後の安全なフォールバックまで設計する。Human supervisionは、承認者を置くだけでなく、承認対象・判断材料・時間・権限・拒否可能性を定義する。IBMの安全策は、組織の判断設計へ載せ替えたとき、はじめて機能する。

境界は、引いて終わりではない

Decision Boundaryは固定物ではない。苦情率や配信停止率の急増、誤配信、プライバシー事故、モデルやツールやCRMの変更、法令やガイドラインの改定、そして承認者による追認率の異常な上昇――これらを、境界を見直す契機として定義しておく。モデルが変われば委ねてよい範囲は変わる。法令が変われば引き受けるべき範囲が変わる。誰が、何をきっかけに、この線を引き直すのか。それ自体が設計対象である。

12,418件と「承認済み」を、もう一度

冒頭に戻る。あの画面で問題だったのは、AIが12,418件を配信したことではない。「承認済み」の4文字が、配信対象なのか、利用データなのか、文面なのか、規模なのか、時刻なのか、例外の扱いなのか――そのどれを引き受けた印なのかを、誰も言えなかったことだ。Decision Boundaryが引かれていれば、あの部長は「12,418件」という規模と、その中に含まれる例外顧客の扱いを、判断材料とともに、拒否できる権限で、期限内に引き受けたはずだった。承認は儀式ではなく判断になり、ログは記録ではなく説明になる。

誰が決めるのか。どこまでをAIへ任せ、どこからを人間または組織が引き受けるのか。その線を意図して引くこと。それが、送信ボタンの手前で本当に問われていることである。

FAQ

Q. AI事業者ガイドライン（第1.2版）は法的義務ですか。 いいえ。総務省・経済産業省が令和8年3月31日に公表した指針であり、リスクや各主体の資源制約を踏まえた自主的な取組のための枠組みです。AIエージェントについて権限設定や人間の判断の介在、操作履歴の確認などの留意点を整理していますが、すべての行動前の承認を法的に一律義務づけるものではありません。

Q. Human-in-the-loopとDecision Boundaryは何が違いますか。 Human-in-the-loopは「人間を工程に挟む」という配置です。Decision Boundaryは「その人間が、何を、どの材料で、どの権限で、どこまで拒否できるのか」という判断の中身と線を定義します。人を挟んでも境界が引かれていなければ、承認は追認になりえます。

Q. まず何から始めればよいですか。 自動化したい1つの業務を選び、その中の「承認済み」を判断単位へ分解することから始めます。何を委ね、何を引き受け、誰が最終判断者で、どの条件で止めるのか。この線を1つ引ききると、他業務へ展開する型ができます。

参考資料

Read the original English analysis (English) →