規制業界でAIエージェントを使う前に作る、部署横断の責任分界と監査ログ

先に結論

金融、保険、士業、医療のような規制業界でAIエージェントを本番投入する前に本当に必要なのは、AIツールの比較検討ではありません。「誰が確認し、誰が承認し、事故時に誰が止め、監査や顧客へ誰が説明するか」を、部署をまたいで先に決めておくことです。

AIの出力ミスは、多くの場合アルゴリズムだけの問題ではありません。導入した組織の側に、確認する人・止める権限・説明できる記録が用意されていなかった、という運用設計の問題として表面化します。精度が99パーセントでも、残る1パーセントが顧客の資産や患者の判断、依頼者の権利に触れる業種では、その1件を誰が拾い、誰が責任を持つのかが決まっていないこと自体がリスクになります。

だからこそ、規程を書くより先に、部署横断の責任分界（RACI）と監査ログの要件を、実際に埋められる表として作ることを勧めます。本記事は、その表をどう埋めるかを具体的な手順で示します。技術的な権限マトリクスやキルスイッチの作り込みではなく、組織として誰が何に責任を負うか、という運用の骨格に絞って解説します。

なお、本記事は特定の法令が何を義務づけているかを断定しません。求められる記録の内容や保存期間、報告義務は業種と取り扱う情報によって大きく異なり、金融庁・厚生労働省・各士業の所管当局・個人情報保護委員会など、監督主体もばらばらだからです。自社に適用される具体的な要件は、必ず所管当局の公表資料と顧問弁護士に確認してください。本記事が示すのは、その確認結果を組織の運用に落とし込むための共通フレームです。

この記事を読むべき人

• 金融・保険・士業・医療など、顧客への説明責任や記録保存が重い業種で、AIエージェントや生成AIの本格利用を検討している経営者・役員
• 情シスが一人または兼任で、AI利用が部署ごとにバラバラに広がり始めているのを把握しきれていない管理者
• PoCは通ったが、本番化の稟議で「事故が起きたら誰が責任を取るのか」を問われて止まっている担当者
• 規程やAIポリシーの雛形は用意したものの、現場が実際にどう運用するのか腹落ちしていない法務・コンプライアンス担当
• ベンダーやSaaSにAI処理を任せているが、自社が取り出せるログと契約上の責任範囲を確認できていない担当者

一つでも当てはまるなら、ツール選定より前に、この記事の責任分界の設計から着手する価値があります。

なぜ部署横断でないと決まらないのか

AIエージェントの導入がこじれるのは、技術が難しいからではありません。関わる部署が、それぞれ別の正しさを持っているからです。

現場は、目の前の業務を速く楽にしたい。問い合わせ対応の下書き、書類のチェック、調査の一次整理をAIに任せられれば、人手不足のなかで回るようになります。現場にとっての正しさは「効率」です。

情シス・ITは、誰がどのデータにアクセスでき、その操作が記録として残るかを気にします。AIが顧客データや基幹システムに触れるなら、権限とログの管理が最優先です。ITにとっての正しさは「統制可能性」です。

法務・コンプライアンスは、事後に説明できるかを見ます。顧客や監督当局から「なぜその判断・その回答になったのか」と問われたとき、根拠と経緯を示せなければ、便利さは一瞬で負債に変わります。法務にとっての正しさは「説明責任」です。

経営は、どこまでのリスクなら取ってよいかを決めます。攻めれば競合に先行できるが、事故が起きれば行政処分や信用失墜に直結する業種では、許容できるリスクの線を引くのは経営の仕事です。経営にとっての正しさは「リスク許容度」です。

この四つは、どれも正しく、そして放っておくと噛み合いません。合意しないまま「便利だから」で本番化してしまうと、問題が起きた瞬間に全員が困ります。現場は止めていいのか分からず動かし続け、ITは記録を求められても揃えられず、法務は説明を迫られても根拠を持たず、経営は初めて「そんな使い方をしていたのか」と知る。事故対応で最も高くつくのは、この「誰も決めていなかった」という空白です。部署横断で設計するというのは、事が起きる前に、この四つの正しさを一つの表の上で突き合わせておく、という意味です。AI導入で法務・情シス・現場が具体的にどこで揉めるかは、AIエージェント導入で法務・情シス・現場が揉めるポイントでも整理しています。

RACIを実際に埋める手順

RACIは、業務ごとに Responsible（実行・確認する人）、Accountable（最終責任を負う人）、Consulted（相談する相手）、Informed（報告を受ける相手）を割り当てる表です。言葉だけ知っていても意味はありません。埋められる粒度まで落として初めて機能します。手順は三段階です。

手順1：AI利用業務を影響の重さで分類する

まず、社内でAIを使う（使おうとしている）業務を洗い出し、次の三つに仕分けます。分類の軸は「AIの誤りが誰に、どこまで届くか」です。

• 社内効率化型：出力が社内に閉じる。議事録の要約、社内文書のドラフト、情報整理など。誤っても外部への影響はない。
• 顧客影響型：出力が顧客に届く、または顧客対応の判断材料になる。問い合わせ返信の下書き、提案資料、説明文の生成など。
• 法的・金銭的影響型：出力が契約・審査・診断・申告・権利義務など、法的または金銭的な結果に直結する。与信判断の補助、書類の適法性チェック、金額算定の一次案など。

この分類を先にやる理由は、すべての業務に同じ厳しさの統制をかけると現場が回らず、逆に一律に緩めると重い業務で事故るからです。分類ごとに統制の強さを変える、というのが実務の要です。どの業務をどの区分に入れるかの考え方は、AI法制がリスクベースへ向かう時代、中小企業はAI利用をどう分類すべきかで詳しく扱っています。

手順2：分類ごとに、埋めるべき欄を決める

分類が済んだら、区分ごとに次の欄を埋めます。ここが本題です。

この表の空欄を、実際の役職・部署・人名・日数で埋めていく作業そのものが、部署横断ワークショップの中身になります。埋まらない欄が残ったら、それは「まだ本番化してはいけない業務」だというサインです。

手順3：埋められない欄を本番化の判定に使う

RACI表の価値は、埋まった表よりも「埋まらなかった欄」にあります。Accountableに名前が入らない、ログ保管期間が決められない、顧客説明文が書けない——そのどれかが残る業務は、稟議を通す前に立ち止まるべきものです。本番化の可否をこの表で判定できるようにしておくと、「なんとなく便利だから広げる」を防げます。本番化条件の詰め方は、AIエージェント発注前相談のように、解く業務と範囲、本番化の条件を先に言語化する進め方が有効です。

Accountable（説明責任者）を1人に絞る理由

四つの役割のなかで、最も間違えやすいのがAccountableです。ここを「法務部」「情シス」「AI委員会」のような組織名や複数人で埋めてしまうと、いざというとき誰も責任を持ちません。全員の責任は、誰の責任でもないからです。

Accountableは、その業務でAIが問題を起こしたとき、最終的に説明し、判断し、責任を引き受ける一人を指します。役職の箱ではなく、個人名で埋めてください。「顧客影響型の問い合わせ対応AIのAccountableは、カスタマーサポート部長の◯◯」というところまで具体化して初めて、事故時に迷いなく動けます。

一人に絞ると責任が重すぎるように見えますが、実務ではむしろ逆です。Accountableが一人だからこそ、その人はConsulted（法務・専門家）に堂々と相談でき、Informed（経営・監査）へ迷わず報告できます。責任の所在がはっきりしているほど、相談と報告の線が明確になり、結果として組織全体が守られます。逆に責任者が曖昧な組織ほど、現場は「勝手に判断していいのか」を毎回迷い、かえって統制が効きません。

なお、Responsible（実行・確認する人）は複数いてよく、むしろ重い業務では複数のチェックを重ねるべきです。一人に絞るのはあくまでAccountableです。この違いを曖昧にしないことが、RACIを形骸化させないコツです。

監査ログの粒度――事後に「なぜその出力か」を説明できるか

監査ログを取る目的は、記録を貯めること自体ではありません。事後に、顧客や監督当局へ「なぜAIがその出力を出し、それが最終成果物にどう反映されたか」を再現して説明できることです。この目的から逆算すると、残すべき項目が決まります。

• 入力：AIに何を渡したか（プロンプト、指示内容）
• 参照データ：どの資料・データベースを参照したか（社内文書、顧客データ、外部情報の別）
• 出力：AIが返した内容そのもの
• 修正履歴：人がどこをどう直したか。無修正で採用したのか、手を入れたのか
• 承認者と承認時刻：誰が、いつ、その出力を使ってよいと判断したか
• 外部送信履歴：その出力や入力が、外部（顧客・他社・外部API）へ送られたか

ここで注意したいのは、「出力だけ」を残しても説明にならないことです。同じ質問でも、参照した資料が違えば答えは変わります。人が大きく修正していれば、AIの出力と最終成果物は別物です。入力・参照・出力・修正・承認・送信までを一連の流れとして残して初めて、「この結論に至った経緯」を語れます。

ただし、何をどこまで残す義務があるか、どれだけの期間保存すべきかは、扱う情報の種類と業種の規制によって異なります。ここを自己流で決めず、所管当局の資料と顧問弁護士に確認して要件を確定させてから、ログ設計に落としてください。個人情報を含む場合の取り扱いは、個人情報保護委員会の公表資料も確認の起点になります。生成AIを業務ワークフローに組み込む場合の統制の考え方は、金融・士業の生成AIワークフローはモデルリスク管理外でも統制が必要になるも参考になります。

AI台帳の作り方と、更新が止まる理由

AI台帳とは、「自社のどの部署が、どの業務で、どのAIを、どのデータに対して使っているか」を一覧にしたものです。責任分界を設計する土台であり、監督当局や取引先から「御社はAIをどう使っていますか」と聞かれたときの、唯一の答えられる資料でもあります。

台帳に載せる基本項目は次のとおりです。

台帳づくりで本当に難しいのは、作ることではなく、続けることです。多くの組織で台帳は、作った直後がピークで、三か月もすると実態とずれ始めます。理由は単純で、「誰が、いつ、更新するか」を決めていないからです。現場は日々新しいツールを試し、部署は勝手にSaaSを契約し、AIの使い道は静かに増えていきます。更新の担当と頻度を決めない限り、台帳は現実に追い越されます。

対策は運用の側にあります。月次で更新する担当を個人名で決め、更新を各部署の定例に組み込み、新しいAI利用を始めるときは台帳への登録を着手の条件にする。この三点を仕組みにしないと、台帳は「作った時点の写真」で止まります。台帳と責任分界を一体で設計する具体的な進め方は、AI規制がリスクベースへ向かう時代、企業はAI台帳と責任分界をどう作るべきかでも掘り下げています。

事故が起きたときの手順を、平時に決めておく

AIの出力が原因で顧客に誤った情報を伝えた、機密データが外部に渡った、誤った判断材料で意思決定してしまった——こうした事態は、起きてから考えるのでは遅すぎます。平時に、次の点を紙に落としておきます。

• 止める人：誰の判断で、その業務のAI利用を停止するのか。停止の権限を持つ人を明確にする。
• 顧客へ説明する人：影響を受けた顧客への連絡は誰が、何を、いつ伝えるのか。
• 証跡にするログ：何が起きたかを再現するために、どのログを保全し、いつまでに固めるのか。
• 当局への報告：報告義務がある場合、誰が、どの窓口へ、いつまでに報告するのか。

このうち当局報告のタイミングと要否は、業種・事案の性質によって大きく異なります。報告が必要かどうか、期限がいつかは、自己判断せず所管当局の基準と顧問弁護士に確認して、事故対応手順の中に組み込んでおいてください。技術的な侵害・情報漏えいを伴う場合の初動は、専門チームによるインシデント対応支援のような枠組みと、平時の責任分界を接続しておくと、判断の空白が生まれにくくなります。事故対応で最も避けたいのは、「誰が止めるか」を事故の最中に相談し始めることです。それを平時のRACIで先に決めておくのが、この設計の目的です。

外部委託・SaaS利用時の責任分界

AIエージェントの多くは、自社開発ではなく外部のSaaSやベンダー経由で使います。ここで責任分界が曖昧になりやすいのは、「ログはベンダーが持っている」という状態です。

確認すべきは三点です。第一に、ベンダー側にどんなログが記録されているか。第二に、そのログを自社が必要なときに取り出せるか、取り出せるとしてどの範囲・どの形式・いつまで保持されるのか。第三に、それが契約書のどこに書かれているか。監査や顧客から説明を求められたとき、「ベンダーに問い合わせないと分からない」「契約上その期間のログは残っていない」では、説明責任を果たせません。

外部委託しても、顧客や当局に対する説明責任そのものは委託元に残る、という前提で考えるのが安全です。委託先の管理は、契約の文言だけでなく、実際に取り出せるログと、取り出す手順まで含めて設計してください。組織全体でシャドーAI（部署が勝手に契約したツール）を統制下に置く進め方は、生成AIガバナンスの考え方が土台になります。自社の業務にどのAIエージェントを、どの範囲で入れるかの検討自体は、AI営業支援エージェントのような具体的な業務エージェントの設計と合わせて詰めると、責任分界も現実的になります。

よくある誤解

規制業界のAIガバナンスでは、次の思い込みが事故の入り口になります。

「規程を作れば体制が整う」：規程は前提条件であって、運用ではありません。誰が確認し誰が承認するかが現場で回っていなければ、立派な規程はむしろ「守れていない証拠」になります。規程より先に、埋まったRACI表を用意してください。

「AI台帳を作れば運用できる」：台帳は現状の写真にすぎません。更新の担当と頻度を決めなければ、数か月で実態とずれ、かえって「実態を把握していない」ことの証明になりかねません。

「ログを取っていれば説明できる」：ログは、目的から逆算した粒度で取っていなければ説明の役に立ちません。出力だけ残していても、入力・参照・修正・承認・送信がなければ「なぜその結論か」は語れません。

「うちは規制業界ではないから関係ない」：顧客の個人情報を扱う、金銭に関わる、契約に影響する業務があるなら、明示的な業法がなくても説明責任は発生します。規制業界向けの設計は、規制業界でない企業にとっても、事故時に会社を守る備えになります。

進め方――規程文の前に、埋まる表をつくる

ここまでの要点は一つです。規程やポリシーの文章を先に書くのではなく、部署横断で「実際に埋められる表」を先につくること。AI利用業務マップ、RACI表、監査ログ要件、顧客・監査向けの説明項目——この四つが埋まって初めて、AIエージェントを本番に載せる準備が整います。

相談や着手の前に、社内で次を確認しておくと、議論が具体的に進みます。

• どの部署がAIを使い、どの業務が顧客・金銭・法的結果に影響するか
• 各業務のAI出力を誰が確認し、最終責任者（個人名）は誰か
• 入力・参照データ・出力・修正・承認・外部送信のログを残せるか
• 取引先や監督当局からAI利用を問われたとき、何を答えられるか
• 社員教育と月次台帳更新の担当が、個人名で決まっているか

自社だけで表を埋めきれない、あるいは埋めた表が本当に規制に耐えるか不安、という段階では、AI導入可否アセスメントのように、部署横断で運用できる責任表とログ要件へ落とし込む外部の視点を使うのも一つの手です。GXOでは、規程文の作成ではなく、実際に部署横断で回るRACI・AI台帳・監査ログ要件・教育計画を一体で設計する支援を行っています。全社のセキュリティ体制と接続して考えたい場合は、セキュリティ事業の枠組みと合わせて整理できます。

よくある質問（FAQ）

Q. 規制業種でAIエージェントを入れる場合、最初に着手すべき整備は何ですか。 A. ツール選びではなく、AI利用業務の洗い出しと三区分（社内効率化型／顧客影響型／法的・金銭的影響型）への分類からです。分類ができると、どこに重い統制をかけるべきかが見えます。

Q. RACIのAccountableは部署名で書いてはいけませんか。 A. 避けてください。組織名や複数人にすると、事故時に誰も責任を持ちません。業務ごとに、説明し判断し責任を引き受ける一人を、個人名で割り当ててください。

Q. どんなログを、どのくらいの期間残せばよいですか。 A. 目的（事後に「なぜその出力か」を説明できること）から逆算し、入力・参照データ・出力・修正履歴・承認者・外部送信履歴を残すのが基本です。ただし義務としての保存期間や範囲は業種と扱う情報で異なるため、所管当局の資料と顧問弁護士に確認して確定してください。

Q. 特定の法律で具体的に何が義務づけられているか教えてください。 A. 本記事では断定しません。金融・保険・士業・医療で監督主体も要件も異なり、一般論で述べると誤りになるためです。自社に適用される条文・ガイドラインは、必ず所管当局の公表資料と顧問弁護士に確認してください。

Q. AIをベンダーのSaaS経由で使っています。責任はベンダーにありますか。 A. 顧客や当局への説明責任は、原則として委託元に残ると考えるのが安全です。ベンダーが持つログ、自社が取り出せる範囲、契約書の記載を確認し、取り出す手順まで含めて設計してください。

Q. AI台帳がすぐ古くなってしまいます。どうすれば続きますか。 A. 月次の更新担当を個人名で決め、各部署の定例に更新を組み込み、新しいAI利用の開始条件に「台帳登録」を入れてください。担当と頻度を決めないと、台帳は必ず実態に追い越されます。

Q. 事故が起きたら、まず誰が何をするのですか。 A. 平時に、止める人・顧客へ説明する人・証跡にするログ・当局報告の要否とタイミングを決めておきます。当局報告の要否と期限は自己判断せず、所管当局の基準と顧問弁護士に確認して手順へ組み込んでください。

Q. うちは規制業界ではありません。それでも必要ですか。 A. 顧客の個人情報・金銭・契約に関わる業務があれば、明示的な業法がなくても説明責任は生じます。規制業界向けの責任分界は、規制業界でない企業でも事故時の備えとして有効です。

関連するGXOナレッジ

• AI規制がリスクベースへ向かう時代、企業はAI台帳と責任分界をどう作るべきか
• AI法制がリスクベースへ向かう時代、中小企業はAI利用をどう分類すべきか
• 金融・士業の生成AIワークフローはモデルリスク管理外でも統制が必要になる
• AIエージェント導入で法務・情シス・現場が揉めるポイント

参考・出典

以下は本記事の作成にあたり内容を確認した公的・一次情報です（確認日：2026-07-10）。適用される具体的な要件は業種・取扱情報により異なるため、必ず所管当局の最新版と顧問弁護士に確認してください。

• 経済産業省・総務省「AI事業者ガイドライン」: https://www.meti.go.jp/policy/it_policy/ai_guideline/
• NIST AI Risk Management Framework（Govern／Map／Measure／Manageの4機能でAIリスクの信頼性を管理する枠組み）: https://www.nist.gov/itl/ai-risk-management-framework
• 個人情報保護委員会（個人情報を含むデータの取扱い・漏えい時対応の一次情報）: https://www.ppc.go.jp/
• TechRadar Pro「Agentic AI adoption outpaces governance in regulated industries」（規制業界で運用統制が導入に追いついていない傾向を報じた二次情報）: https://www.techradar.com/pro/agentic-ai-adoption-outpaces-governance-in-regulated-industries