AIで事故が起きたら誰の責任？｜責任共有モデルの読み方

「事故が起きたときの責任の所在を稟議の場で問われ、提供元と自社のどちらだと言えばよいのかが決まらないままです」「提供元の規約に免責と書いてあったので、そこは大丈夫だと説明しました」——AIのサービスを業務に入れる場面で、この2つはたいてい同じ会議に並びます。ただ、後者は危うい説明です。外部の計算資源を借りる形で広まった責任共有モデルの原型は、提供元が基盤そのものの安全を持ち、利用者がその基盤の中に自分が置いたものの安全を持つ、という2分割でした。AIでは、この2つでは足りません。本当は、線は1本ではなく、層の数だけ引かれているというのが実態です。この記事では、AIのサービスで問題が起きたときにどこまでが提供元でどこからが自社なのかを層ごとに読む方法と、入れる前に決めておく最小の項目を整理します。

「誰の責任か」を、起きてから探し始めていないか

AIのサービスを業務に入れるとき、稟議の場でほぼ必ず出る質問が「事故が起きたら誰の責任か」です。この問いに、提供元の規約の免責条項を読み上げて答える例をよく見かけます。しかし規約に書かれているのは、提供元が自社に対して何を保証しないかであって、自社が顧客に対して何を負うかではありません。この2つはまったく別の話で、前者をいくら読んでも後者の答えは出てきません。

起きてから探し始めると、答えにたどり着くまでに時間がかかります。障害の連絡先はどこか、記録はどこに残っているか、顧客への説明は誰が書くか。この3つを同じ日に同時に調べ始めると、最初の連絡までに半日が消えます。線引きは、入れる前にしか引けません。起きた後に引いた線は、どうしても自社に都合よく引かれてしまい、相手に受け入れられません。

この記事で扱うのは、事故が起きた後の対応の段取りではなく、その手前にある線の読み方です。契約と設定と運用の3つを見ないと、線は決まらないという点が出発点になります。契約だけを見ても足りず、設定だけを見ても足りません。どこにどの線が引かれているかを層ごとに読み、自社が持つ側に落ちたものを運用で受け止める。この順番だけが、起きた日に動ける状態を作ります。

責任共有という考え方は、どこから来たのか

この整理が広まった出どころは、外部の計算資源を借りる形のサービスです。大手の提供元は、自社が持つ範囲を「基盤そのものの安全」、利用者が持つ範囲を「その基盤の中に自分が置いたものの安全」の2つに切りました。前者には建物、機材、回線、仮想化の土台が入ります。後者には、その上に置いた利用者の設定、権限、そしてデータが入ります。境目そのものを、責任の分かれ目と呼びます。

この整理には、もう1段の細かさがあります。同じ提供元の説明では、統制を3つに分けています。提供元が完全に持つもの（建物の物理的な安全など）、両方が別々の位置で同じ種類の作業を持つもの（修正の適用。提供元は基盤の側、利用者は自分が動かしている側）、そして利用者だけが持つもの（自社が組み立てたものに固有の安全）です。同じ名前の作業でも、持つ位置が違えば別の責任だという点が、実務では効いてきます。

そして重要なのは、この切れ目が固定ではないことです。出来合いのサービスをそのまま使う場合と、土台だけ借りて自社で組む場合とでは、切れ目が上下に動きます。利用者が組み立てる部分が増えるほど、線は提供元の側に寄り、自社の持ち分が増える。借りる範囲が広いほど自社の持ち分は減り、作る範囲が広いほど増えるという、単純な関係で覚えられます。

AIでは、線を引く層が1つ増える

AIを載せると、この2分割では足りなくなります。ある大手クラウド事業者が2026年8月に更新した解説文書では、AIを使うサービスを3つの層に分けています。モデルを動かす基盤の層、その機能を人が使える形にしたアプリケーションの層、そして実際に人が使う場面の層です。従来の設備と中身という2分割に対して、モデルという層が間に挟まった形になっています。

実務で持つべき見取り図は、これを少し崩した4層です。土台の設備。モデルそのもの。その上に自社が組んだ使い方（何を読ませ、何につなぎ、どう答えさせるか）。そして入力した内容と、出した先。前の2つはおおむね提供元、後ろの2つはおおむね自社、というのが出発点です。ただし境目は借り方で動くので、この見取り図は覚える図ではなく、毎回当てて確かめるための枠として使います。

さらに、自分で動いて操作まで行う形のAIを入れると、層はもっと増えます。同じ事業者が2026年8月に公開した別の解説では、段取りを組む層、外部の道具を呼んで実際に操作する層、状態と記憶を持つ層の3つが上に積み上がるとしています。そこには自律性は責任を減らさないという趣旨の記述も添えられています。動かす範囲が広いほど自社が持つ欄が増えるという向きは、どの整理でも一貫しています。

• 層の数だけ分かれ目がある。線は1本ではないので、図を1枚覚えても足りない
• 同じサービスでも、借りる範囲を変えれば線は動く。契約の区分を切り替えた日に読み直す
• 自分で操作まで行う形にすると層が増える。増えた層は、ほぼ自社の持ち分になる
• 分担が書かれていない欄は、実務では自社に落ちると考えて先に手当てする

層ごとの責任の分かれ目を、一覧にして持つ

層ごとの分担を、実務で使える粒度に落とします。次の一覧は、出来合いのサービスをそのまま使う場合を基準にした並びです。自社で組む範囲が広がるほど、右の欄に書いたものが増えていきます。これはそのまま答えではなく、提供元の資料と契約書を当てて埋め直すための枠として使ってください。

層	おおむね提供元が持つもの	おおむね自社が持つもの
土台の設備	建物、機材、回線、仮想化の土台の安全	どこまでを借りるかの選び方
モデルそのもの	モデルの置き場、重み、入出力の安全機構	どのモデルを選ぶか、切り替えの判断
自社が組んだ使い方	設定できる部品と、その説明の提供	何を読ませ、何につなぎ、どう答えさせるか
入力と出した先	預かった内容の保管の方法と場所	何を入れてよいか、出力をどこまで人が確認するか
身元と権限	認証と権限の仕組みの提供	誰に何を使わせるか、道具ごとの権限の絞り込み
記録	基盤の側の記録の提供と保持	自社の側の記録を何に残し、いつまで保つか

この表を作るときの勘どころは、空欄を空欄のまま残さないことです。埋まらない欄が出たら、それは分担が決まっていない欄です。決まっていない欄は、起きた日にほぼ確実に自社へ落ちます。相手が持つと書かれていないものは、自社が持つと考えて先に手当てするほうが、あとで揉めません。

もう1つ、欄ごとに「どこを見ればそう言えるか」を書き添えます。契約書の条番号、規約の見出し、管理画面の設定名。根拠の場所を書いていない表は、半年後に誰も信じません。書き添える手間は1欄あたり数分ですが、この一手間があるかどうかで、更新のときに作り直しになるか、差分の確認だけで済むかが変わります。

分かれ目その1：出力の正しさは、使う側に残る

AIに特有の分かれ目の1つ目が、出力の正しさです。生成の機能を提供する側の規約は、出てきた内容の正確性についても、適法性についても、第三者の権利を侵害しないことについても、保証しない書き方をしているのが通例です。業界団体が2023年に公開した生成AIの責任共有の提案でも、借り方ごとの分担は整理されている一方で、誤った出力による損害を誰が負うかまでは詰め切られていない、という指摘が残されています。

つまり、出力を使うと決めた時点で、その正しさの責任は使う側に移っていると考えるのが実務の出発点です。これは提供元が無責任だという話ではありません。正しさを判定する材料の大半が使う側にあるからです。何を読ませたか、どんな指示を書いたか、どの場面で使ったか。この3つは提供元からは見えず、見えないものに保証は付けられません。

だからこそ、人が確認する範囲を先に決める必要があります。全部を人が読み直すのは現実的ではないので、外に出るもの、金額に関わるもの、人の処遇に関わるものは人が確認するのように、確認する側を条件で決めます。逆に、社内の下書きや要約の一次案は確認を省いてよいと明示します。確認する範囲を後から決めようとすると、量に負けて確認そのものが省かれます。

分かれ目その2：土台が入れ替わって、挙動が変わったとき

2つ目は、土台の側が入れ替わる点です。従来の外部サービスでも機能追加や仕様変更はありましたが、AIでは同じ指示に対する答えそのものが変わることがあります。モデルの版が上がる、安全機構の判定の幅が変わる、既定の設定が変わる。どれも自社は何もしていないのに、出てくるものが変わるという点で、これまでの変更とは性質が違います。

契約と規約の側では、この扱いは通知の義務と予告の期間で決まります。版を上げるときに事前に知らせるか、前の版をいつまで使えるか、使えなくなるときに何日前に告げられるか。ここが書かれていないサービスでは、ある朝から出力が変わっていた、という事態を自社が丸ごと引き受けることになります。入れる前に必ず読んでおきたい欄です。

自社の側の手当ては2つです。1つは、同じ入力を投げて出力を見比べる小さな確認を、定期と版の切り替え時に走らせること。もう1つは、出力の形が崩れたときに気づける記録を残しておくことです。入れ替わったことに気づけないのが、いちばん困る状態なので、正しさを機械で判定するところまでやらなくても、変わったことに人が気づける仕掛けがあれば足ります。20件ほどの決まった入力を用意しておけば、確認は10分で終わります。

分かれ目その3：入力した内容の扱いは、契約と設定の両方で決まる

3つ目は、入力した内容がどう扱われるかです。学習に使われるか、どこにどれだけ保存されるか、第三者に渡ることがあるか。この3つは、契約の区分と、管理画面の設定の両方で決まります。片方だけを見て安心する例が多く、個人向けの契約のまま業務で使っていた、法人向けの契約だが保存期間の設定を既定のままにしていた、というずれがよく起きます。

実務では、確かめる順番を固定しておくと漏れません。まず契約の区分（誰との契約で、どの区分か）。次に規約の該当条項（入力の利用範囲、保存、第三者への提供、再委託）。最後に管理画面の設定（学習に使わせるかどうか、保存の期間、記録の出力）。この3つの答えを1行ずつ書き留めておけば、監査や顧客の質問にそのまま出せます。

そのうえで、入れてよい内容の線を業務の側で引きます。線は「機密かどうか」ではなく「外に出たときに誰が困るか」で引くほうが運用に乗ります。顧客の氏名や取引条件、未公表の数字、他社から預かった資料。入れてよいものの一覧ではなく、入れてはいけないものの一覧を作るほうが、現場で判断できます。一覧に無いものは相談に上げる、と決めておけば例外も回ります。

自分で組み立てるほど、自社の持ち分は増える

ここまでの3つの分かれ目は、どの借り方でも共通です。そのうえで、借りる範囲によって線が上下に動きます。出来合いのサービスをそのまま使う形では、モデルも安全機構も土台も提供元の側です。土台だけ借りて自社で組む形では、つなぎ方、道具の選定、権限の設計が自社に移ります。計算資源だけ借りて全部を自分で作る形では、モデルの置き方と入出力の安全機構まで自社です。

借りる範囲	自社に増える持ち分	先に決めておくこと
出来合いをそのまま使う	設定、権限、入力の範囲、出力の確認	設定を持つ人と、確認が要る条件
土台を借りて自社で組む	つなぎ方、読ませる資料、道具の選定と権限	つないだ先ごとの権限と記録
計算資源だけ借りて自社で作る	モデルの選定と更新、入出力の安全機構	版の管理と、前の版への戻し方

選ぶときの基準は、機能の多さではありません。自社が持つことになる範囲を、自社が本当に運用できるかです。設計はできても、当番を置いて記録を毎週見る体制が無いなら、持ち分を増やす選択は事故のもとになります。運用にどれだけ人手を割けるか読めないうちは、借りる範囲を広く取るほうが安全です。

自分で動いて操作まで行う形を入れると、この判断はさらに重くなります。道具ごとの権限、操作ごとの確認、人が入る関門、操作の記録。先に触れた2026年8月の解説では、これらはどの借り方でも自社が持ち続ける欄として整理されています。任せる範囲を広げるほど、書いて決めておくことが増えるという向きは変わりません。

起きた日その1：誤った内容を顧客に送ってしまった

ここからは、起きた日に何が問われるかを3つの場面で見ます。1つ目は、AIが作った文面をそのまま顧客に送り、そこに事実と違う記述が含まれていた場合です。この場面で提供元に持ち込める余地は、実務上ほとんどありません。出力の正しさは使う側に残っているうえに、送るという操作をしたのは自社だからです。

問われるのは3つです。誰が確認する決まりだったか。その決まりは書かれていたか。実際にその手順を通ったか。決まりが無かった場合と、決まりはあったが守られなかった場合とでは、その後の直し方が違います。前者は仕組みの不備で、置く決まりを増やします。後者は運用の不備で、手順を短くするか、確認する人を変えます。記録が無いと、このどちらかすら判別できません。

必要な記録は多くありません。いつ、誰の指示で、どの入力から、どの出力が出て、誰が確認して外に出したか。この5つが1行に並んでいれば足ります。記録は原因を突き止めるためではなく、どこで線を越えたかを示すために残すものだと考えると、項目は自然に絞れます。窓口は自社の担当部門で、この場面では提供元への連絡は原則として不要です。

起きた日その2：外部の指示に乗っ取られた

2つ目は、読み込ませた資料や外部の頁の中に指示文が仕込まれていて、AIがそれに従って動いてしまう場合です。取り込んだ文書、道具から返ってきた値、他のAIから受け渡された文字列は、どれも信頼できる指示ではなく、確かめるべき入力として扱うのが基本とされています。人が読む文章と、AIが指示として読む文章の区別が付かないことが原因です。

この場面の線引きは、少し込み入っています。基盤の側の安全機構は提供元が持ちますが、何を読ませるか、どの道具をつなぐか、どの操作まで許すかは自社です。したがって、被害が外に出る操作まで届いたなら、その操作を許す設定をした側の問題として扱われます。読ませる先とつなぐ先を絞ることが、最も効く手当てになります。読み取りだけを許し、書き込みと送信は人を挟む形にしておけば、被害はその手前で止まります。

起きた日の動きは3つです。まず操作を止めること。次に、どの道具でどこまで動いたかを記録から追うこと。そして、読み込ませた元を特定することです。問い合わせ先は、基盤の側の不具合が疑われるなら提供元、自社が組んだつなぎ方の問題なら社内。この振り分けを先に決めておかないと、最初の連絡先を探すところで時間を使います。

起きた日その3：提供元の障害で止まった

3つ目は、提供元の側の障害でサービスが使えなくなる場合です。ここは責任の所在が比較的はっきりしていますが、はっきりしていることと、自社が困らないことは別です。規約に書かれた責任の上限は、多くの場合その期間に支払った料金の範囲にとどまります。止まったことで自社の業務が回らなかった分は、そこには含まれません。

だから確かめるのは、賠償の金額ではなく、止まったときに何ができるかです。復旧の見込みはどこで告知されるか、その告知を誰が見る決まりか、止まっている間に業務を回す代わりの手順はあるか。代わりの手順は高度である必要はなく、その業務を人が手で回す段取りが書いてあれば十分な場合がほとんどです。書いていないと、その日に考えることになります。

顧客に納品や連絡の約束をしている業務でAIを使っている場合は、もう1段の備えが要ります。約束の期日に間に合わない可能性が出た時点で、誰がいつ顧客に伝えるかを決めておくことです。止まった事実より、伝えるのが遅れたことのほうが後で問題になるので、伝えるかどうかの判断を現場に渡しておくほうが、実務は回ります。上に上げてから伝える形にすると、必ず半日遅れます。

契約書と規約で確かめる条項の一覧

ここまでの分かれ目を確かめるために、契約書と利用規約で見る場所をまとめます。全文を読む必要はありません。見出しを追って、次の6つが書かれている場所を特定するだけで、ほとんどの判断は付きます。書かれていない項目があれば、それは交渉するか、自社の側で受け止めると決める対象になります。

この6つのうち、見落とされやすいのは4番目と5番目です。責任の上限と免責は法務が必ず見ますが、記録をどこまで出してもらえるかと、いつまで使えるかは、契約の段階では話題になりにくい。しかし、起きた日と乗り換えの日に効くのはこの2つのほうです。

あわせて、補償の条項があるかどうかも確かめます。出力が第三者の権利を侵害したと言われたときに、提供元が対応を引き受ける仕組みが用意されている場合があります。ただし条件が付くのが通例で、指定の設定を有効にしていること、こちらの指示の内容に問題がないことなどが求められます。条件を外れた使い方をしていると、あるはずの補償が働きません。設定と補償が結び付いている点は、契約書だけを読んでいると見落とします。

規約の免責は、顧客への言い訳にはならない

ここが、この記事でいちばん伝えたい点です。提供元の規約に免責が書かれているのは、提供元と自社の間の取り決めです。自社と顧客の間の契約には、その文言は一度も登場しません。顧客から見れば、契約している相手は自社であって、自社がどこの道具を使っているかは関係のない話です。

実務でこの混同が表に出るのは、説明の場面です。「使っているサービスの規約で保証されていないので」という説明は、社内では通っても、顧客の前ではまず通りません。顧客が知りたいのは、なぜそれが外に出たのか、次に同じことが起きないために何を変えるのか、の2つだけです。道具の話をしている限り、説明は前に進まないと考えて構いません。

したがって、線引きの読み方には2段あります。1段目は提供元との間の線。2段目は顧客との間の線です。1段目で自社に落ちたものは、2段目でも当然に自社が持ちます。そして1段目で提供元に落ちたものも、顧客に対しては自社が前に立ちます。提供元に費用を求められるかどうかは、顧客への説明が済んだ後の、自社と提供元の間の話です。この順番を逆にすると、対応が必ず遅れます。

入れる前に決めておく、最小の3つ

全部を決めてから入れるのは現実的ではありません。最小限、次の3つだけ決めておけば、起きた日に動ける状態になります。逆に言えば、この3つが決まっていないまま入れると、起きた日の最初の30分が探し物で消えます。

3つとも、決めること自体に時間はかかりません。難しいのは決めた内容を、使う人が知っている状態にすることです。文書を共有した、では足りません。使い始めの説明で口頭でも伝え、確認が要る場面の例を2つか3つ挙げておくと、現場の判断がそろいます。例が無いと、条件の解釈が人によってばらけます。

そのうえで、この3つは半年ごとに見直します。使い方が広がると、確認が要る場面の線がずれるからです。最初に決めた線を、そのまま使い続けないこと。線は、使い方が変われば動きます。動いたことに気づく仕掛けとして、見直しの日付をあらかじめ予定表に入れておくのがいちばん確実です。

やりがちな失敗と、その手当て

線引きが機能しない現場には、共通する型が4つあります。どれも悪意や怠慢ではなく、順番の取り違えから起きています。

• 提供元が守ってくれると思い込む：基盤の安全は提供元が持つが、出力の正しさと入力の中身は自社に残る。守られる範囲を条文で確かめないまま入れると、落ちた欄に気づかない
• 規約を読まずに設定だけ見る：管理画面の設定は規約の範囲の中でしか効かない。学習に使わせるかどうかも保存の期間も、契約の区分によって選べる幅が違う
• 起きてから責任の所在を探し始める：探している間に、顧客への最初の連絡が遅れる。遅れたという事実のほうが、後々まで問題として残る
• 図を1枚覚えて終わりにする：借りる範囲を変えた日、機能を足した日、契約の区分を切り替えた日に線は動く。覚えるべきは図ではなく、確かめる手順のほう

4つのうち、実際にいちばん多いのは2つ目です。管理画面に学習に使わせない設定があれば安心だと考えてしまう。しかしその設定が効く範囲は、契約している区分によって違います。設定は規約の中でしか動きません。順番としては、契約の区分を先に確かめ、そのうえで設定を見ます。逆にすると、効いていない設定を効いていると思い込みます。

3つ目への手当ては、前の節の3つ、つまり窓口と確認の範囲と記録です。これがあれば、起きた日に探すのは「どの記録を見るか」だけになります。手当てを先に置いておくと、事故そのものは防げなくても、対応の速さは確実に変わります。防げない事故を、遅れない対応に変えるのが、線引きの実利です。

引いた線を、誰がいつ見直すか

線は一度引いて終わりではありません。見直しの引き金は4つあります。契約の区分を変えたとき。新しい機能を使い始めたとき。提供元から仕様変更の通知が来たとき。そして自社の使い方が広がったときです。このうち3つは提供元からの連絡では届きません。通知を待つ運用にしていると、線がずれたまま半年が過ぎます。

見直しの当番は、法務でも情報システム部門でもなく、その業務を実際に回している側に置くほうが機能します。使い方が広がったことに最初に気づくのは、現場だからです。ただし、契約書の条文を読む部分は法務に回します。気づく人と、読む人を分けるのが、現実的な分担になります。

見直しの中身は、層ごとの表を更新するだけで足ります。埋まっていた欄が空になっていないか、根拠の場所として書いた条番号や設定名が変わっていないか。30分あれば終わります。作り直しになるのは、根拠の場所を書いていなかった表だけです。ここでも、最初に書き添えた一手間が効いてきます。

まとめ

AIのサービスで問題が起きたとき、どこまでが提供元でどこからが自社かは、1本の線では決まりません。土台の設備、モデルそのもの、その上に自社が組んだ使い方、入力した内容と出した先。層ごとに切れ目があり、借りる範囲を変えれば切れ目も動きます。AIに特有の分かれ目は3つで、出力の正しさは基本的に使う側に残ること、土台が入れ替わって挙動が変わる場面があること、入力の扱いは契約の区分と管理画面の設定の両方で決まることです。

起きた日に動けるかどうかは、入れる前に決めた3つで決まります。窓口を名前で決めること、人が確認する範囲を条件の形で書くこと、記録に残す項目を5つに絞ること。そして最後に、提供元の規約に書かれた免責は自社と提供元の間の取り決めであって、顧客に対しては自社が前に立ちます。線を読む目的は、責任を逃れる先を探すことではなく、自社が持つ側に落ちたものを先に手当てしておくことです。

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