AIが勝手に実行した行為の責任は消えない｜決裁と記録の作り方

「AIがやったことなので、こちらの責任ではないと説明しました」「自動で動く設定にしたのは前任者です」——実行まで任せたエージェントが事故を起こした部署から出てくる説明です。どちらも社外では通りません。エージェント自体に法人格はないため、代理に関する規定をそのまま当てはめることはできず、実務ではエージェントが出した申込みや送信は、それを動かした会社自身の行為として扱うところから議論が始まると整理されています。この記事では、答えを間違えたのではなく行為をしてしまった場合に何が起きるのかを4つの場面で追い、実行の前に人の承認を挟む線引きと、後から示せる記録の作り方を整理します。

「AIが勝手にやった」が説明にならない理由

まず前提を置き換えます。AIエージェントそれ自体に法人格はありません。だから、権限のない者が代理人として振る舞った場合の規定や、権限があるように見えた場合の規定を、エージェントに直接当てはめることはできません。2025年6月に公表された法律事務所の解説では、利用者が自分の管理下でAIを動かしている場合、AIによる意思表示は利用者自身の意思表示と同視され、利用者が責任を負う構成が想定されると整理されています。2026年4月の解説はさらに進んで、エージェントを利用者の行為の延長にある道具として扱えば足りる、と述べています。

これを実務の言葉に置き換えると、こうなります。エージェントが押した申込みも、送った案内も、会社の名前で出た行為として相手に届く。相手からは、担当者が押したのか機械が押したのかは見えません。だから「AIが判断しました」という説明は、責任を軽くするどころか重くすることがあります。判断させる仕組みを組み、権限を渡したのは会社の側だからです。

次に、この記事が扱う範囲をはっきりさせます。AIが誤った内容を答えた場合の責任は、別の問題として整理すべきものです。答えの誤りは、公開の前に人が読めば止まります。ここで扱うのは、止める機会がないまま外に出てしまった行為、つまり送信、申込み、削除、支払いです。誤りの確率をどれだけ下げても、取り消せない操作を任せているかぎり、この問題は残り続けます。

責任の枠組みの側も動いています。経済産業省は2026年4月9日に「AI利活用における民事責任の解釈適用に関する手引き」の第1.0版を公表しました。AIの使い方を、人の判断や行動を介在させることが予定されている補助や支援の型と、人の判断や行動を代替する前提で提供される依拠や代替の型の2つに分ける整理です。後者では、利用者の注意義務が「その場で適切に判断すること」から「システムを適正に用いる体制を作って運用すること」へ移ると説明されています。想定事例には配送の経路を決めるもの、取引を審査するもの、外観を検査するものが並び、補論としてAIエージェントが取り上げられています。

場面設定：展示会の後追いを、実行まで任せた会社

ここから先は、1つの会社を仮に置いて4つの場面を追います。実在の事故ではなく、権限の渡し方を考えるための想定です。この会社は展示会で1,200件の名刺を集め、その後の作業をエージェント1体にまとめて任せました。任せたのは、案内メールの配信、商談枠の確保、顧客台帳の整理、少額の広告出稿の4つです。

渡した権限も4つあります。配信ツールの操作、日程調整の予約、台帳の書き込み、そして少額の支払いに使えるカードです。ここが分かれ目で、任せた仕事の数と、渡した権限の数が同じになっていることに注意してください。仕事の単位で権限を渡すと、1つの仕事が想定より広がったとき、権限もそのまま広がります。

指示は1行でした。「展示会の来場者に、当社の事例を案内して、興味がありそうな相手と商談を組んでほしい」。読むと自然な文ですが、この1行には数字が1つもありません。何件までか、いつまでか、いくらまでか、どこまでを社外に出してよいか。数字のない指示は、範囲のない権限とほぼ同じ意味になります。以下の4つの場面は、すべてこの1行から出てきます。

場面1：送ってしまった。宛先の条件が広すぎた

最初の事故は配信です。エージェントは「展示会の来場者」を、直近の展示会だけでなく、台帳に残っている過去3年分の来場記録として解釈しました。結果として3,000件を超える宛先に案内が届きました。中には、配信停止を申し出た相手と、すでに取引が終わって担当者が変わっている会社が混ざっていました。

この行為の性質を確認します。送信は、外に出た瞬間に完了して、取り消す手段がありません。訂正の連絡を出せますが、それは新しい送信を1回足すだけで、最初の送信を消すものではありません。広告や宣伝を含むメールは、あらかじめ同意した相手に送るのが原則で、配信停止を受け付けた相手に送れば、社内の失敗ではなく相手に対する違反になります。

ここで効いてくるのが指示の抽象さです。「来場者に案内して」という指示から3年分を選んだことについて、会社の側が「そういう意味ではなかった」と言えるかどうかは、指示の文が客観的にどう読めるかで決まります。先ほどの解説は、AI利用者の指示の範囲内かどうかは客観的に確定させるべきだと指摘しています。頭の中にあった範囲ではなく、書いた文が示す範囲が基準になります。

では何を先に決めればよかったのか。宛先については3つです。母集団の条件（どの名簿の、どの期間か）、除外の条件（配信停止と退職者と競合）、そして1回の上限件数。件数の上限は、宛先の条件を間違えたときの被害を止める最後の弁になります。条件を完璧に書くことはできないので、上限で受け止める発想が要ります。

場面2：申し込んでしまった。無料の枠のはずが有料だった

2つ目は申込みです。商談枠の確保を任せたところ、エージェントは相手企業が使っている予約の仕組みに登録し、そのうちの1つで有料の枠を押さえました。金額は1件あたり数万円でしたが、押さえた枠は12件ありました。

申込みは、送信とは性質が違います。相手との間に契約が成立しうる行為なので、取り消せるかどうかは、相手の対応と、こちらの言い分の強さで決まります。解説では、10個と指示したのに100個の申込みが出た場合、錯誤による取消しを主張できるとされています。ただし同じ解説は、指示が抽象的な場合には利用者側の重大な過失が認められる可能性があると付け加えています。

「興味がありそうな相手と商談を組んで」という1行から12件の有料枠を押さえた場合、この重大な過失の議論に入りやすくなります。参考になる例として、ホテルの予約を任せると1泊30,000円の宿でも予約される可能性があると指摘されている整理があります。値段の上限を書いていなければ、上限がないと読むのが自然だからです。

なお、申込みをした側が消費者である場合には、確認の画面を出していない事業者に対して取消しを認めやすくする特例があります。会社が業務として出した申込みには、この消費者向けの特例は働かないと考えるのが基本です。読者の立場では、守ってもらえる側ではなく、説明を求められる側になります。だから金額の上限は、相手の親切に期待せず、自分の側の設定として置きます。

場面3：消してしまった。整理のはずが履歴を落とした

3つ目は削除です。台帳の整理を任せたところ、エージェントは同じ会社の重複した行を1つに統合しました。統合そのものは望んだ動きですが、副作用として、統合されて消えた側の行にあった問い合わせ履歴と配信停止の記録が失われました。

削除の厄介さは、失った情報の中身によって重さが変わることです。消えたのが作業用のメモなら痛くありませんが、本人からの申し出の記録なら、対応した証拠がなくなります。配信停止を受け付けた記録が消えると、次の配信で同じ相手に届き、場面1と同じ事故が再発します。1つの削除が、別の種類の事故の原因になるという連鎖です。

戻せるかどうかは、AIの側ではなく仕組みの側の話です。世代を残す設定があれば戻せますし、上書きなら戻せません。だから設計では順番が逆になります。まず消せる範囲を仕組みで区切り、そのうえで任せます。ここはAIに判断させないことを明示する場所でもあります。重複かどうかの判定はエージェントに任せてよいのですが、確定はさせません。候補の一覧を出させて、人が確定する形にします。

実務では、任せる行為を2段に分けると事故が減ります。提案までの行為と、実行してよい行為を、最初の設計で分けて書くのです。台帳なら、重複の候補を出すのは実行してよい行為、統合して片方を消すのは提案までの行為。この線を引くだけで、削除に関する事故はほぼ止まります。

場面4：支払ってしまった。1件は小さく、合計が大きい

4つ目は支払いです。少額の広告出稿を任せたところ、1回あたりの金額は小さいまま、出稿の回数が想定を超えて積み上がりました。1回3,000円という上限を守っていても、1日に何十回でも実行できるなら、合計は上限とは無関係に伸びます。

エージェントに支払いをさせる話は、いまや仕組みの側にも用意があります。2025年から、既存の決済の基盤の上でエージェント経由の購入を成立させる枠組みが相次いで公表され、2026年春には複数の事業者が基盤を公表しました。注目したいのは前提の置き方で、人が毎回その場で承認する取引だけでなく、目的と予算と条件を先に決めておけば人がいなくても実行される取引が、正面から想定されている点です。つまり、人がいなくても回る前提で作られています。

その代わりに、枠の設計が求められます。解説では、上限金額、有効期限、用途の範囲、人の承認の4つで設計するという整理が共有されています。ここで大事なのは、上限を1回あたりではなく期間の合計で置くことです。1回3,000円ではなく、1週間で30,000円、と書きます。回数を数えるのは機械が得意な仕事なので、合計で止める設定は難しくありません。

支払いには、もう1つの側面があります。金額が小さいと決裁が要らないという社内の慣習と組み合わさると、誰の承認も通っていない支出が、正規の手続きの外側に積み上がることになります。金額基準の決裁だけを持っている会社では、エージェントが動く領域はまるごと決裁の外に置かれます。次の章から、この構造を直していきます。

4つの場面を、取り消せるかで並べ直す

4つの場面を、金額の大小や社内の重要度ではなく、取り消せるかどうかで並べ替えます。この並べ方をすると、承認を挟むべき場所が自動的に浮かびます。

実行された行為	誰に届くか	取り消せる範囲	設計で先に置くもの
案内の送信	社外の個人	取り消せない。訂正の連絡を足すことしかできない	母集団と除外の条件、1回の上限件数
枠の申込み	取引先や仕組みの提供元	相手が応じれば解除できる。錯誤の主張は指示の具体性次第	金額の上限と、申込みを禁止する範囲
台帳の削除	社内、ただし本人の申し出の記録を含む	世代が残っていれば戻せる。上書きなら戻せない	消せる範囲の区切りと、提案までにする行為
少額の支払い	決済の相手と出稿先	相手の運用によるが、原則として戻らない	期間の合計での上限と、有効期限

表の右端を見てください。4つとも、承認そのものではなく「先に置く数字と範囲」が並んでいます。1件ごとの承認を増やすより、範囲を先に決めるほうが効くという意味です。1件ごとの承認は、範囲を決めきれない部分にだけ使います。

もう1つ読めることがあります。取り消せない行為ほど、事後の対応が「相手への説明」になるという点です。取り消せない行為の設計は、法務の仕事ではなく広報と営業の仕事に化けます。だからここは、情報システム部門だけで決めずに、外に向けて説明する部署も入れて決めます。

行為の効力：誰の意思表示として扱われるのか

ここで法律の側の整理をもう一段だけ確認します。要点は3つです。第1に、エージェントに法人格はないので、代理に関する規定は直接は使えません。第2に、そのため実務では、エージェントを利用者の道具として扱い、その行為を利用者自身の行為と同視する構成が想定されています。第3に、この構成では、権限を超えたという主張は相手ではなく身内に向くことになります。

第3点が実務ではいちばん重要です。エージェントが指示に反した動きをした場合、その責任を提供元に問う筋道はあります。解説では、エージェントが自らの指示に反した挙動をしたことを、利用契約における提供者の債務不履行として捉える余地が示されています。ただしこれは、自社と提供元との間の話です。案内を受け取った3,000件の相手や、有料枠を押さえられた取引先に対しては、自社が説明する立場に変わりません。

この構造を最初から見込んでおくと、社内の議論の順番が変わります。まず外に対する責任は自社が引き受ける前提で設計し、そのうえで内部での回収を契約に書くという順番です。逆にすると、事故のあとに「提供元の問題だから」という説明を外に向けて出してしまい、状況を悪くします。

整理が追いついていない部分があることも押さえておきます。2026年4月に公表された論点整理では、設計した側、動かした側、モデルを開発した側の三者の責任の分かれ目が定義されていないと指摘されています。同じ整理は、この状態が続くと誰も責任を取らない状態が固定されるという現象を挙げています。国際的な動きも早く、2026年1月には東南アジアの1国がエージェント向けの管理の枠組みを公開し、同年2月には米国の標準化機関がエージェントの標準づくりの取り組みを立ち上げています。制度が固まるのを待つより、社内の決め方を先に持つほうが実務的です。

取り消せる範囲を決めるのは、指示文の具体性

錯誤による取消しの話をもう少し詰めます。実務で押さえるべきは、取り消せるかどうかが「AIの性能」ではなく「こちらが書いた指示」で決まるという点です。10個の指示が100個になった場合は取消しを主張しやすく、「よい感じに集めておいて」から100個になった場合は主張しにくい。指示文は、事故のあとに読まれる証拠になります。

だから指示文の作り方が変わります。作業を頼む文ではなく、範囲を確定する文として書きます。実務では4つの要素を入れます。対象（どの名簿のどの期間か）、上限（件数と金額と回数）、禁止（やってはいけない行為の列挙）、そして期限。この4つを入れると文が長くなりますが、長い指示文は、事故のときに自社を守る側に働きます。

あわせて入れておきたいのが、根拠を書かせる設定です。実行の前に、なぜその宛先を選んだのか、なぜその金額になったのか、どの条件に当てはめたのかを短い文で残させます。根拠が読める形で残っていれば、承認する人は中身を全部確認しなくても判断できます。ここは、AIの答えを信じるための仕組みではなく、人が短時間で判断できるようにするための仕組みです。

根拠を残す設定には副作用の効き目もあります。根拠を書けないときにエージェントが止まるようになるからです。「該当する条件が見つからないので実行しません」と返って止まるほうが、当てずっぽうで実行されるよりはるかに安いという判断です。

社内で誰が責任を負うのか。権限を渡した人の位置

次は社内の話です。事故のあとに問われるのは、操作した人ではありません。エージェントは自分で動くので、操作した人が存在しない場合があります。実際に問われるのは、権限を渡した人と、承認の設計をした人です。配信ツールのアカウントを作った人、台帳の書き込みを許した人、カードを紐づけた人。この3人が、事故の当日に何もしていなくても関係者になります。

経済産業省の手引きが示した注意義務の転換が、ここで意味を持ちます。人の判断を代替する前提の使い方では、利用者に求められるのは個々の場面での適切な判断ではなく、システムを適正に用いるための体制を作って運用することだと整理されています。つまりその日の判断ではなく、事前の体制が評価の対象になる。事故の直前の10分間に何をしたかではなく、3か月前に何を決めていたかが見られます。

この整理は、現場に責任が落ちる構図を止める根拠にもなります。よくあるのは、権限は上が渡し、事故の説明は担当者がするという形です。権限の付与そのものを決裁の対象にすれば、渡した側の名前が記録に残ります。誰が何を渡したかが残っていない状態で事故が起きると、結果として現場の1人に集まります。

なお、鍵や資格情報をどう渡すかという設定の手順は、それ自体で1つの主題になるので、ここでは触れません。この記事で必要なのは1点だけです。渡した権限の一覧が、決裁の書面の上に載っているかどうか。載っていなければ、社内のどの資料を見ても「誰が何を任せたか」が分かりません。

外注先が動かした場合の分かれ目

エージェントを自社で組まず、外部に構築と運用を任せている場合を考えます。関係者は3つの立場に分かれます。作った側、実際に動かしている側、そして名前で外に出ている側です。多くの場合、3つ目は自社です。外に対する説明の責任は、名前で出ている側から離れません。

そのうえで、内部の分かれ目は2つの問いで決まります。1つ目は、その動きが指示の範囲内だったか。範囲外なら、利用契約や業務委託契約の履行の問題として提供元に責任を問う筋道が出てきます。2つ目は、範囲を決める書面が存在したか。範囲の書面がなければ、範囲外だったという主張の土台がありません。事故のあとに「そこまで頼んでいない」と言うためには、頼んだ範囲が先に書かれている必要があります。

契約に入れる項目を3つに絞ります。第1に、実行してよい行為と提案までにする行為の一覧。第2に、実行の記録を自社が読める形で受け取れること。第3に、止め方と、止められる人の範囲です。3つ目が抜けている契約は多く、事故の当日に止められる人が自社にいないという事態になります。夜間や休日に動く設定なら、なおさら要ります。

あわせて、提供を受けているものがどちらの型として作られているかを確認します。人の判断を介在させる前提の作りなのか、人の判断を代替する前提の作りなのか。手引きの整理では、エージェントはどちらにも当たりうるので、まずどちらに当たるかを検討してから責任の方向性を考えるとされています。精度が十分でない場合は、人が介在する前提の型として扱われるという整理も示されています。「自律で動きます」という説明と、「人の確認を前提にしています」という説明のどちらを受けているかは、契約書に書き残しておくべき事実です。

承認を挟む線引きは、金額と宛先と取り消せるかの3軸で決める

ここから決める側に移ります。人の承認を挟む場所は、担当者の勘や役職の高さではなく、3つの軸で決めます。第1の軸は金額です。1回あたりと、期間の合計の2つで置きます。第2の軸は宛先で、社内で完結するのか、社外に出るのか、社外の個人に届くのか。第3の軸は取り消せるかどうかで、戻せる操作か、戻せない操作かです。

3軸を組み合わせて、こう決めます。3つのうち2つ以上に当たったら、必ず人の承認を通す。たとえば、社外の個人に届いて取り消せない案内の送信は2つに当たるので承認が必要です。社内の台帳で世代が残る書き込みは0か1つなので、承認は不要にできます。少額でも期間の合計で上限に近づいた支払いは、金額と取り消せないの2つに当たります。

この決め方の利点は、判断を人の裁量に残さないことです。承認が必要かどうかを毎回相談する運用は、必ず「忙しいから今回は省く」に流れます。表に落として、機械が判定できる形にします。3軸の閾値は最初は厳しめに置き、1か月ほど運用して、承認が形だけになっている箇所を緩めます。

参考として、総務省と経済産業省がまとめているAI事業者ガイドラインでも、人が関与する流れを組み込むことが推奨されています。同ガイドラインは2026年3月31日に第1.2版へ更新され、エージェントや物理的に動くAIの進展を反映した調整が入りました。推奨されているのは「人を挟むこと」であって「人が全部見ること」ではありません。人が確認する範囲を先に決めておかないと、確認は必ず全件の見直しに膨らみ、やがて誰も見なくなります。

決裁の1枚に、何を書くか

次は決裁です。ここで言う決裁は、1件ごとの承認ではありません。エージェントに権限を渡すこと自体に対して出す決裁です。1枚に収める前提で、6つの手順で埋めます。関係者3人で半日あれば書けます。

この1枚があると、事故のあとの会話が変わります。「誰が決めたのか」ではなく「決めた範囲のどこがずれていたのか」から始まるからです。決裁は責任を押しつける道具ではなく、範囲を書き残す道具として使います。

後から示せる記録：何を、いつ、誰の資格で実行したか

最後の部品が記録です。ここで残すのは、原因を追うための詳細な作業記録ではありません。「この行為は、誰の資格で、どの決裁に基づいて実行されたのか」を後から示せる最小限です。項目は6つで足ります。

• いつ実行したか。実行の時刻を、指示を受けた時刻と分けて残す
• 誰の資格で実行したか。使ったアカウントと、根拠にした決裁の番号をひも付ける
• 何をしたか。呼び出した先と、渡した値。宛先の件数と金額は必ず数字で残す
• なぜそうしたか。実行の前に書かせた根拠の文。後からまとめて書く形にすると、事故になった実行だけ記録が欠ける
• 結果はどうなったか。成功と失敗の別、件数、相手から返ってきた内容の要点
• 止めた場合は、その理由。止まったことは失敗ではないので、理由の種類を固定して数える

この6項目は、事故のときだけに使うものではありません。3か月後の見直しで閾値を動かすときの材料になります。承認が形だけになっている箇所は、承認から実行までの時間が極端に短い記録として現れます。逆に、承認待ちが積み上がっている箇所は、閾値が厳しすぎる箇所です。

もう1つ、渡した値の扱いに注意が必要です。渡した値には、社外に出せない情報や個人に関する情報が混ざります。だから記録の項目を決める段階で、伏せる欄を先に決めておきます。記録を作ってから伏せ方を考えると、記録そのものが新しい漏えいの経路になります。

整理の進んでいない領域として、誰の代わりに動いているかを機械が証明する仕組みが挙げられています。2026年4月の論点整理では、委任の連鎖を証明する方式や、エージェント同士のやり取りの正当性を確かめる方式が検討課題として並んでいます。技術が追いつくまでのあいだは、決裁の番号を記録にひも付けるという地味な方法が、いちばん確実な代わりになります。

社内への配り方：規程ではなく、1枚と窓口

設計ができても、配り方を間違えると使われません。配るものは3つに絞ります。実行してよい行為の一覧、人の承認が必要になる条件、そして止め方です。この3つを1枚に収め、規程の本体は別に置きます。分量の多い規程を配ると、読まれないまま「読んだ」と回答されるだけになります。

窓口は1つにします。迷ったときに止めて相談する先を1つ決め、その番号を1枚に書きます。ここで大事なのは運用の姿勢です。止めた判断を後から責めない、と決めておきます。止めた人が責められる職場では、次からは止めずに実行されます。止めた件数は、事故を防いだ件数として数えます。

そのうえで、やってはいけない配り方があります。エージェントを使う部署が増えるほど、次の6つが起きやすくなります。

• 「常識の範囲で使ってください」と伝えて任せる。範囲の言葉がないので、宛先も金額も各自の解釈になる
• 金額の決裁基準だけを流用する。少額の支払いを何十回も実行できる設定は、決裁の外側に支出を積み上げる
• 承認を全件に付ける。確認が形だけになり、3週間で誰も中身を読まなくなる
• 実行の記録を、事故が起きてから作り始める。止まらなかった実行の記録は、その時点ではもう残っていない
• 止めるかどうかの判定をAIに書かせる。金額や件数の突き合わせで足りる部分に、判断を持ち込む必要はない
• 外注先に任せているから自社の決裁は不要と考える。名前で外に出ているのは自社なので、説明の責任は移らない

6つに共通しているのは、決める前に動かしていることです。1枚と窓口は、動かす前の週に用意できる分量です。動かしたあとに作ると、たいてい事故が起きた翌週になります。

よくある質問

人の承認を挟むと、自動化の意味がなくなりませんか

挟む場所を全部にすれば、そうなります。3軸で絞ると、承認が必要な件は全体の一部に収まります。先の想定でも、案内の送信と有料枠の申込みと台帳の削除に承認を置き、条件の抽出、下書きの作成、候補の並べ替え、社内向けの書き込みは実行のままにできます。止めるのは行為の種類で、作業の量ではありません。作業の大半は、外に出ない部分にあります。

事故が起きたとき、AIの提供元に請求できますか

筋道はあります。指示に反した挙動をしたことを、利用契約における提供元の債務不履行として捉える整理が示されています。ただし2つの条件が要ります。1つは、指示の範囲が書面で確定していること。もう1つは、実行の記録が自社の手元にあることです。範囲の書面と記録がない状態では、範囲外だったという主張の土台がありません。あわせて、社外に対する説明の責任は自社に残る点も押さえておいてください。

記録はどこまで残せばよいですか

6項目です。時刻、資格、呼び出した先と渡した値、根拠、結果、止めた理由。細かい動作の記録を全部残すより、この6項目が全件そろっているほうが役に立ちます。詳細な記録は原因を追うためのもので、6項目は責任の範囲を示すためのものです。目的が違うので、詳しさで代わりにはなりません。保存の期間は、その行為に関する相手からの問い合わせが来る期間に合わせて決めます。

精度が上がれば、承認は外せますか

種類によって答えが変わります。判定の精度で決まる部分、たとえば宛先の抽出や重複の候補出しは、実測して精度が安定してから承認を外せます。一方で、取り消せない行為は精度とは無関係に残します。1,000件のうち999件が正しくても、残る1件は取り消せないからです。精度で外せるのは判断の承認で、取り消せない操作の承認は最後まで残すと考えてください。この線を引いておくと、精度の議論と権限の議論が混ざりません。

まとめ

AIエージェントが実行してしまった行為について、まず押さえるのは効力の側です。エージェントに法人格はないため代理に関する規定を直接は当てはめられず、実務では利用者の道具として扱い、その行為を利用者自身の行為と同視する構成が想定されています。だから「AIが判断しました」は説明になりません。相手には、会社の名前で出た行為として届いています。

そのうえで、答えの誤りと実行された行為を分けて扱います。誤りは公開の前に人が読めば止まりますが、送信は取り消せず、申込みは相手の対応と指示の具体性で決まり、削除は世代が残っているかどうかで決まり、支払いは期間の合計で膨らみます。取り消せるかどうかで並べ替えると、承認を置く場所が自然に浮かびます。経済産業省が2026年4月9日に公表した手引きが示すとおり、人の判断を代替する使い方では、注意義務は「その場の判断」から「体制の構築と運用」へ移ります。事故の直前の10分ではなく、3か月前に何を決めていたかが見られるということです。

決めることは3つに絞れます。承認を挟む線引きを金額と宛先と取り消せるかの3軸で置き、2つ以上に当たったら人を通す。権限の付与そのものに決裁を出し、成果物、権限の一覧、実行してよい行為、閾値、止め方、見直す日を1枚に書く。そして実行の前に根拠を残させ、時刻と資格と呼び出し先と根拠と結果と止めた理由の6項目を全件そろえる。判定はAIに任せず突き合わせで済ませ、人が確認する範囲は先に狭く決めておく。冒頭の4つの場面は、どれも1行の指示から出ていました。範囲を書く作業は、任せない理由を探す作業ではなく、任せられる範囲を先に確定させる作業です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。