Askhub

ナレッジ

AIエージェントの責任は誰が負う?システムと運用の責任分界

任せても、説明責任は残る

「AIのことは、作ったベンダーに任せておけばいい」
AIに業務を任せようとするとき、そう考える方は多いと思います。

でも、それは違うと私たちは考えています。
作業はベンダーに任せられます。ただ、AIに何を許したかの説明責任は、使う会社に残ります。
営業のAIが商談ステージを書き換えた。経理のAIが入金を消し込んだ。そのとき「なぜそれを許したのか」と問われるのは、ベンダーではなく自社です。

これは、悪い知らせではありません。
何が会社に残るのかがはっきりすれば、それ以外は仕組みに渡せるからです。
では、何が残り、何を渡せるのか。
まずは、先に同じ問いに答えてきたクラウドから考えます。

クラウドでも、利用者の持ち分は消えなかった

手がかりは、クラウドの責任共有モデルです。
AWSの説明はこうです。クラウドそのもののセキュリティはAWSが持つ。クラウドの中に顧客が置くもののセキュリティは、顧客が持つ。

分担は、使い方で変わります。
仮想サーバー(EC2)なら、OSの更新は顧客の仕事です。一方、S3のような抽象化されたサービスでは、OSの運用はAWSが持ちます。
任せる範囲が広がるほど、提供者の持ち分は増えます。
それでも、顧客の持ち分がゼロになる形はありません。

マイクロソフトは、この考え方をAIに広げました(Microsoft Learn「AI shared responsibility model」、2026年8月24日更新)。責任を「AIの基盤」「AIアプリ」「AIの利用」の3つの層に分けています。
SaaSとして使えば、基盤とアプリの多くは提供者が持ちます。
でも、IDとアクセスの管理。データの扱い。利用方針。この利用の層は、どの形でも利用者から離れません。

図1 AIの責任の層 · 使い方ごとの分担
提供者に任せる部分が増えても、一番下の行は動きません。

国内のAI事業者ガイドライン(総務省・経済産業省、第1.2版、2026年3月31日)も、同じ形で整理しています。
立場は、AI開発者・AI提供者・AI利用者の3つ。業務システムにAIを組み込む構築ベンダーは主に提供者で、使う会社は利用者です。
利用者には、提供者が示す利用ルールを守ることと、異常時に速やかに情報を共有することが求められています。AIエージェントについては、重要度に応じて人の判断を挟む仕組みと、操作履歴を確かめて報告する仕組みを重要としています。

ガイドラインに法的な拘束力はありません。
それでも、取引先や監査で使われる物差しです。稟議で「国のガイドラインに沿った分担です」と言えることには、意味があります。

なお、責任共有モデルが決めるのは「どちらがどの統制を受け持つか」までです。事故の損害を誰がどこまで負担するかは、契約と法律で決まります。

利用者の持ち分は残る。
では、その持ち分をどう守るか。

人の注意は、件数ですり減る

一番素朴な守り方は、人が気をつけることです。
利用規程で「顧客データを入れない」と決める。ダブルチェックで誤りを拾う。ログをときどき見る。

ただ、人の注意は件数が増えるほどすり減ります。
承認者は忙しい。確認に時間がかかれば、確認そのものが形だけになっていきます。
AIが1日に何百件も処理するようになると、この弱さがそのまま効いてきます。

だから私たちは、守れることは仕組みで保証すべきだと考えています。
AIに許す操作・送信先・データを、仕組みで事前に絞るということです。
許可していない操作は呼べない。前提条件、つまり実行してよい状態かを毎回確かめる条件を満たさない書き込みは通らない。許可していない送信先に、データは出ていかない。
何件処理しても同じように働き、守られたことを記録で示せます。

このシリーズでは、その中心に「業務の型(オントロジー)」を置いてきました。
AIに許す業務操作と、その前提条件をあらかじめ定めたものです。業務操作は、「入金を消し込む」のような記録を変える操作の単位を指します。統制を置く場所の選び方も含めて、AIエージェントの権限設計で整理しています。

ただし、仕組みが守れるのは「決めたとおり」までです。
前提条件が間違っていれば、間違った基準を全件に当てはめます。
何を許すかを決め、その決め方が今も正しいかを確かめるのは、人です。

では、仕組みに渡したあと、人には何が残るのでしょうか。

右の列は、空にならない

シリーズで扱ってきた主な懸念を、「システムで保証する例」と「それでも運用に残ること」に分けてみました。

懸念

システムで保証する例

それでも運用に残ること

誤った書き込み

書き込み前の条件チェックと承認

承認者の判断

権限が広すぎる

許可した操作しか呼べない

許可する操作の定義とレビュー

承認が形だけになる

機械で確かめられることは前提条件で止める

自動承認ルール(人が決めた、自動で承認してよい条件)の確定と見直し

誰がやったか分からない

人とAIを区別して記録する

権限の棚卸し

データの行き先

許可した送信先にだけ接続する

送信先の定期確認

暴走、コストの膨らみ

上限と、全体を止める手段

止める判断と手順の訓練

シャドーAI

公式の道と、送信の見える化

規程、教育、申請の窓口

どの行も、右の列は空になりません。
仕組みが引き受けるのは「毎回同じように確かめられること」です。
人に残るのは3つ。基準を決めること。基準に当てはまらないものを判断すること。基準が今も正しいかを見直すこと。

真ん中の列を、1つの製品で全部満たす必要はありません。いくつかの仕組みを組み合わせて埋めれば足ります。

では、右の列は誰が持つのか。
束ねると、6つの仕事になります。

残る運用は、6つの仕事に束ねられる

1つ目は、許可する操作、つまり業務の型の定義とレビュー。前提条件・承認・取り消し方を決め、変更を承認します。業務部門、情シス、内部統制が持ちます。
2つ目は、承認と自動承認ルールの責任。ルールを確定し、却下率や修正率を見て撤回を決めます。持つのは業務の責任者です。
3つ目は、例外への対応。型に合わない案件を人が引き取り、繰り返すなら型を直します。業務部門の仕事です。
4つ目は、利用規程と教育。入れてよいデータ、使ってよいAIを伝え、申請窓口を運営します。
5つ目は、定期的な確認。権限の棚卸し、送信先の確認、モデル更新時の確認です。4つ目と5つ目は、情シスと法務が持ちます。
6つ目は、インシデント対応。止める判断、報告、関係者への連絡、再発防止。情シスと法務に、経営が加わります。

人の仕事は、1件ずつ確かめることから、基準を決め、外れたものを判断し、基準を見直すことへ移ります(セキュリティもガバナンスもAIが解決する?人に残る3つの仕事)。

営業で考えてみます。AIにSFAの商談ステージを更新させる場合です。
どの条件ならステージを進めてよいかを決めるのは、営業企画(1つ目)。
自動で進めてよいルールを確定し、差し戻しの多さを見て見直すのは、営業の責任者(2つ目)。
条件に合わない大口案件を引き取るのは、担当の営業(3つ目)。
規程と教育、定期的な確認、止める判断は、情シスや法務と分担します。

こうして担当を書き出すと、AIに任せた後の運用の手間が見えます。
それが、そのまま稟議の材料になります。

分担が決まれば、監査への答え方も決まります。

監査には、2種類の記録で答える

監査に出す記録は、この分担に沿って2種類に分けます。
1つは、仕組みの統制が働いていることの証跡。設定と変更の履歴、承認ログ、拒否された操作の記録です。
もう1つは、運用の統制を実施した記録。棚卸しの記録や、ルール見直しの議事録です。

クラウドやSaaSの監査では、ベンダーが受けた第三者保証の報告書を使うことがあります。
そこには「利用者側で実施する前提の統制」が書かれています。表の右の列にあたる部分です。
導入時に報告書の有無を確かめ、6つの仕事に割り当てておく。それだけで、監査の準備はずっと楽になります。

上場企業なら、内部統制報告制度との関係も聞かれます。
2023年4月に改訂された実施基準は、外部に委託した業務の内部統制を、経営者の評価範囲に含めています(金融庁・企業会計審議会の意見書)。委託業務の例には、情報システムの開発・運用・保守などITに関する業務も挙がっています。
評価の方法は2つ示されています。委託業務の結果の一部を自社で検証するやり方。受託会社から、内部統制の評価結果を記した報告書等を入手するやり方。
AIに任せた業務も、この枠組みで説明できるよう記録を残しておけば安心です。

とはいえ、何でも仕組みに寄せればよいわけではありません。

全部を仕組みに寄せなくていい

仕組みで保証する範囲は、広いほどよいとは限りません。作るにも保つにも、費用がかかるからです。

業務ごとに、4つを見ます。
件数が多いか。誤りが取り消せず、社外に出るか。書き込みか、読み取り中心か。ルールが安定しているか。
当てはまるほど、仕組みに寄せる効果は大きくなります。逆なら、運用で守るほうが安く済みます。

経理の入金消込は、件数が多く、ルールも安定しています。仕組みに寄せる効果が大きい業務です。
営業のSFA更新も、件数が多く、前提条件を決めやすい。
一方、経営企画の会議資料の下書きは、件数が少なく、読み取り中心です。最後に人が目を通すなら、運用で守るほうが安く済むこともあります。

工数は、業務の数と定義の細かさで変わります。
まず1つの業務で、定義と運用の工数を測る。広げるのは、それからで十分だと思います。

ここまでは、会社が把握しているAIの話です。
把握していないAIは、どうでしょうか。

シャドーAIは、禁止では止まらない

シャドーAIとは、会社が把握していない生成AIの利用です。
社員が個人のアカウントで別のAIに資料を貼り付ければ、その経路は仕組みの外です。どれだけ仕組みを整えても、届きません。

米PagerDutyが2026年6月11日に公表した調査があります(PagerDuty)。対象は、オーストラリア・日本・英国・米国の大企業で働く、IT・技術職以外の1,250人です。
会社の方針で認められていないと思いながらAIを使った人が、3分の2(66%)。
公開のAIに業務の情報を共有したことがある人は、88%でした。

国内では、そもそもルールが無い職場も少なくありません。
スマートキャンプが2025年12月に行った調査があります(BOXIL Magazine)。業務で生成AIを使う人の31.9%が、勤務先のルールは「特にルールはなく、個人の判断に任されている」と答えています。会社員・経営者の14.4%は「会社は未導入だが、個人で無料版などを利用している」と答えました。

禁じても使われる。ルールが無ければ、なおさら使われる。
禁止を周知するだけでは止まらない、と私たちは考えています。

社員の目的は、仕事を早く終えることだと思います。
それなら止めるより、同じ目的を満たす公式の道を用意して、そちらを通るほうが楽な状態を作るほうが現実的です。
学習に使わない設定と、社内IDでのログインを付けた法人契約の生成AIを配る。社員が使い慣れたAIから、業務システムの操作を呼べるようにする。その場合、認可と記録は業務システム側に持たせます。
推進者が公式の道を用意することは、シャドーAIを減らす策として、情シスにも歓迎されやすい提案です。

芝生の上に踏み固められた近道に、作業員が石を敷いて正規の歩道にしている。使われなくなったロープの柵が草の上に置かれている
柵で塞ぐより、人が通りたい場所に公式の道を敷く。

そのうえで、社外への送信の見える化、「入れてよいデータ」を伝える教育、新しいAIを試したい人のための申請窓口で補います。
見える化で見つかった使い方を、公式の道に取り込んでいく。この作業は運用に残ります。

最後に残るのが、ベンダーとの契約です。

契約で確かめるのは、4つ

AIを使う業務には、たいてい3者が関わります。
モデルや基盤を提供するAIベンダー。それを業務システムに組み込む構築ベンダー。そして使う会社です。

経済産業省の「AIの利用・開発に関する契約チェックリスト」(2025年2月)は、入力データと出力ごとに確かめる項目を示しています。個人情報保護法・セキュリティ・規約改定などの留意点もあります。
契約は、汎用的なAIサービスを使う利用型、カスタマイズ型、新規開発型の3つに分けて整理されています。自社の契約がどれにあたるかを先に決めると、読みやすくなります。

これも参考に、少なくとも4つを確かめます。
入力データを学習に使うか、その保持期間と削除。処理する国と再委託先(生成AIに渡すデータはどこの国へ?保存先の確かめ方と個人情報保護法28条)。事故が起きたときの通知と、調査への協力。契約終了時の、データの返却と削除。

約款で使うサービスは、交渉できないことが多いです。約款や補足文書で確かめ、足りない部分を自社の運用で埋めます。
内製する場合は、自社がAIの提供者の立場になります。構築ベンダーの役割も、自社で持つことになります。

法律も動いています。
2026年7月17日に公布された改正個人情報保護法で、委託先の規律が見直されます(個人情報保護委員会)。委託先は、委託された業務に必要な範囲を超えて個人データを扱ってはならない義務を、明文で負います。漏えい等が起きたときは、委託先から委託元へ速やかに報告することも想定されています。
2026年10月28日時点で委員会が示しているのは、政令・規則の「基本的な考え方」までです。条文案はまだ公表されておらず、意見公募の開始は2027年1月以降と見込まれています。
条文が示された段階で、法務と契約を見直します。

導入がスムーズに進みやすいAIの選び方

次の基準を満たす基盤や作りなら、責任分界の説明が短く済み、導入がスムーズに進みやすくなります。

  1. AIに許す操作を、仕組みで事前に絞れる:規程頼みではなく、許可していない操作は呼べない
  2. 人とAIを区別した記録が残る:誰の代わりに、何をしたかを後から示せる
  3. 提供側に「何でもできる立場」が残っていない:運営者がデータを見る条件と履歴が明確
  4. データの扱い、再委託、事故の通知、終了時の削除が規約で定められている
  5. 社員が使いやすい公式の道になる:シャドーAIから移る先として選ばれる

情シスに説明するときの要点

  • 作業はベンダーに任せても、AIに何を許したかの説明責任は自社に残る。そのうえで、仕組みで保証する部分と運用で守る部分を分けて設計した
  • 運用に残る6つの仕事に、担当部門と頻度を割り当てた。業務部門が持つのは、許可する操作の定義、自動承認ルール、例外対応
  • 件数が多く取り消しにくい業務から仕組みに寄せ、まず1つの業務で工数を測る
  • 監査には「システムが働いた証跡」と「運用を実施した記録」の2種類を出せる
  • シャドーAIは禁止ではなく、公式の道と申請窓口で減らす

残る仕事が見えれば、任せる範囲は広げられる

AIに業務を任せても、説明責任は会社に残ります。
でも、残るのは「基準を決める」「外れたものを判断する」「見直す」仕事です。
毎回同じように確かめられることは、仕組みに引き受けさせられます。

始めるのは、使っているAIを一覧にするところからで十分です。
件数が多く取り消しにくい業務を1つ選び、6つの仕事に担当を書き込む。そこで測った工数を材料に、仕組みに寄せる範囲を決め、公式の道を1つ用意する。

残る仕事を自社で引き受けると決めれば、責任の所在は説明できます。
説明できれば、AIに任せる業務は広げていけます。
私たちは、そう確信しています。

関連記事

参考資料

Askhubについて

Askhubは、日本の中堅・大企業がAIに業務を任せるための基盤です。業務の型(オントロジー)でAIに許す操作を定め、承認と判断ログで任せる範囲を広げながら、国産の基幹システムまで書き込めるようにします。導入はコンサルタントが伴走します。

責任分界を決めるときに確かめておきたいのは、提供する側に「何でもできる立場」が残っていないかです。Askhubでは、運営会社がお客様の会話やファイルを見られるのは、お客様が承諾したワークスペースに限られ、承諾と取り消しの履歴も残ります。障害対応など規約で定めた場合は承諾なしに参照することがありますが、その場合も記録を残し、お求めに応じて開示します。また、何でも操作できる「システム」という主体を作りません。AIの実行も外部のAIツールからの呼び出しも、誰の代わりに動くかを決めたうえで、その人の権限の範囲で判定します。データの扱い、再委託、漏えい時の通知、契約終了時の削除は、利用規約と別紙で定めています。一方、AIにどの業務操作を許すか、自動承認のルールを確定するか、利用規程をどう定めるかは、本文のとおりお客様の側に残ります。

※Askhubのサービスに関する記載は、2026年11月時点の情報です。

関連する機能:製品の全体像、外部ツール連携

ナレッジの記事をもっと見る