AIエージェント導入で誰が責任を持つか｜経営・現場・情シス・ベンダーのRACI設計

結論：AIエージェント導入では「誰が責任を持つか」を先に決める

AIエージェント導入で最も危ない状態は、モデル精度が低いことではない。誰が責任を持つのかが曖昧なまま、AIが業務データやSaaSを操作し始めることである。

AIエージェントは、メールを読み、CRMを更新し、問い合わせを分類し、社内文書を検索し、チケットを起票し、外部APIを呼び出す。つまり、従来は人間、情シス、業務責任者、ベンダーが分担していた判断と操作の境界に入ってくる。

このとき、次の問いに答えられない会社は、本番導入で止まる。

問い	曖昧なまま進めた場合
AIエージェントの利用目的を誰が承認するのか	現場ごとに勝手な使い方が広がる
AIに与えるデータ範囲を誰が決めるのか	過剰権限、機密情報流出が起きる
AIの出力ミスを誰が確認するのか	顧客対応や社内判断に誤りが混ざる
自動実行を止める判断を誰がするのか	事故時に停止が遅れる
ベンダーの責任範囲を誰が契約で定義するのか	障害時に発注側と開発側が揉める

GXO株式会社がAIエージェント導入で推奨するのは、ツール選定の前にRACIを作ることである。

RACIとは、業務や意思決定ごとに、Responsible、Accountable、Consulted、Informedを決める整理方法である。AIエージェント導入では、これを「誰が作業するか」だけでなく、「誰が承認し、誰に相談し、誰へ通知するか」まで含めて設計する。

なぜAIエージェントではRACIが必要なのか

NIST AI Risk Management Frameworkは、AIのリスクを個人、組織、社会に対して管理するための枠組みであり、AIの設計、開発、利用、評価に信頼性の観点を組み込むことを目的としている。生成AI向けのプロファイルも公開されており、AI導入では利用開始後の運用と見直しまで含めた管理が必要になる。

また、NIST Cybersecurity Framework 2.0では、Governが中心的な機能として扱われ、組織のリスク管理方針、期待値、ポリシーを確立・伝達・監視する考え方が示されている。AIエージェントは社内システム、データ、ID、外部連携に触れるため、AIガバナンスとサイバーセキュリティガバナンスを分けて考えられない。

AIエージェントでRACIが必要になる理由は、3つある。

1. AIが複数部署の境界をまたぐ

営業AIエージェントは、営業だけのものではない。CRM、メール、契約書、見積、顧客情報、マーケティングデータ、場合によっては会計データに触る。CSエージェントも、サポート、開発、法務、営業、個人情報管理と関係する。

部署横断の業務で責任者が曖昧だと、事故時に「現場の問題」「情シスの問題」「ベンダーの問題」と押し付け合いになる。

2. AIは判断と実行の境界を曖昧にする

人間が文章を作り、人間が送信するなら責任は比較的分かりやすい。しかし、AIが顧客メールを下書きし、担当者が一部だけ確認し、AIが自動送信する場合、どこからが人間の責任で、どこからがAIシステムの設計責任なのかが曖昧になる。

AIエージェント導入では、作成、確認、承認、実行、監査、改善を分けて責任を置く必要がある。

3. ベンダー任せにできない領域が増える

ベンダーはシステムを作れる。しかし、どの顧客へメールを送ってよいか、どの商談金額をAIが更新してよいか、どの契約条件を人間承認にするかは、発注側の業務判断である。

AI導入を外注する場合でも、発注側がRACIを持たなければ、ベンダーは「作れるもの」を作るだけになる。

AIエージェント導入の基本RACI

最初に、全社共通の基本RACIを作る。以下は、中小・中堅企業向けの初期テンプレートである。

項目	Responsible 実行責任	Accountable 最終責任	Consulted 相談先	Informed 通知先
AI利用目的の定義	業務部門責任者	経営/DX責任者	情シス、法務、現場リーダー	関係部署
対象業務の選定	業務部門責任者	経営/DX責任者	情シス、GXO/ベンダー	利用部門
データ範囲の定義	情シス、業務部門	情報管理責任者	法務、個人情報管理者	経営、利用部門
権限設計	情シス	情報管理責任者	業務部門、ベンダー	監査担当
禁止事項の定義	情シス、業務部門	経営/DX責任者	法務、セキュリティ担当	全利用者
プロンプト・ワークフロー設計	ベンダー/GXO、業務部門	業務部門責任者	情シス、現場担当	利用者
本番リリース判定	情シス、業務部門	経営/DX責任者	法務、セキュリティ担当、ベンダー	関係部署
日次・週次ログ確認	情シス、業務管理者	情報管理責任者	ベンダー、現場リーダー	経営/DX責任者
事故時の停止判断	情シス	経営/DX責任者	法務、業務責任者、ベンダー	全利用者
改善・再学習・ルール変更	業務部門、ベンダー	業務部門責任者	情シス、法務	利用者、経営

この表で重要なのは、Accountableを必ず1人または1部門に絞ることである。Responsibleが複数いてもよいが、最終責任が複数あると意思決定が止まる。

業務別RACI：営業AIエージェント

営業AIエージェントは、商談創出や提案作成に効く一方、顧客接点と売上条件に直結する。自動化範囲を慎重に分ける必要がある。

業務	R	A	C	I
ターゲット企業リスト作成	営業企画	営業責任者	マーケ、情シス	営業チーム
顧客メール下書き	営業担当、AI	営業責任者	法務、CS	関係者
顧客メール送信	営業担当	営業責任者	情シス、法務	顧客担当チーム
CRM入力補助	営業担当、AI	営業責任者	情シス	営業企画
商談確度の自動変更	原則禁止	営業責任者	情シス	経営
値引き・契約条件の判断	原則禁止	営業責任者/経営	法務、経理	営業担当

営業では、AIに「作らせる」ことと「送らせる」ことを分ける。下書きはAIに任せても、送信、値引き、契約条件、CRMの重要項目更新は人間承認を残す。

業務別RACI：CS・問い合わせAIエージェント

CSでは、AIが問い合わせ分類、回答候補、ナレッジ検索を担うと効果が出やすい。一方で、クレーム、返金、契約変更は責任分界を誤ると炎上しやすい。

業務	R	A	C	I
問い合わせ分類	CS担当、AI	CS責任者	情シス	CSチーム
回答案作成	CS担当、AI	CS責任者	法務、開発	CSチーム
返金提案	CS責任者	CS責任者/経営	経理、法務	営業、顧客担当
契約変更案内	CS担当	営業責任者/法務	経理、情シス	顧客担当
クレーム自動返信	原則禁止	CS責任者	法務、広報	経営
ナレッジ更新	CSリーダー	CS責任者	開発、情シス	CSチーム

CSでは、AIが回答を速くするほど、誤った回答も速く広がる。回答案の作成者、承認者、顧客送信者を分けることが重要である。

業務別RACI：情シス・開発AIエージェント

情シスや開発では、AIエージェントがログ調査、コード生成、チケット起票、手順書作成を補助できる。一方で、本番環境や秘密情報に触れるため、責任分界は最も厳しく設計する。

業務	R	A	C	I
障害ログ調査	情シス、AI	情シス責任者	ベンダー、開発	関係部署
チケット起票	AI、情シス	情シス責任者	業務部門	関係者
手順書作成	情シス、AI	情シス責任者	ベンダー、現場	利用者
権限付与	情シス	情報管理責任者	業務責任者	監査担当
本番DB更新	原則人間のみ	情シス責任者	開発、業務責任者	経営
秘密情報の検出・マスキング	情シス、AI	情報管理責任者	セキュリティ担当	監査担当

情シス領域では、AIが「提案する」ことと、AIが「実行する」ことを明確に分ける。特に本番DB更新、権限付与、秘密情報の扱いは、人間承認とログを必須にする。

事故時の責任分界を先に決める

RACIは平常時だけでは足りない。AIエージェントでは、事故時の判断者を先に決めておく必要がある。

事故パターン	初動責任	最終判断	相談先	通知先
顧客への誤送信	業務部門責任者	経営/法務	CS、情シス、ベンダー	顧客担当、経営
機密情報の外部送信	情シス	情報管理責任者/経営	法務、セキュリティ担当	関係部署
CRM/DBの誤更新	情シス、業務部門	業務部門責任者	ベンダー、監査担当	利用部門
AIの大量実行・課金超過	情シス	経営/DX責任者	ベンダー、経理	利用部門
不適切な回答・差別的出力	業務部門責任者	経営/法務	人事、広報、ベンダー	関係部署
外部API・MCP連携の異常	情シス	情報管理責任者	ベンダー、セキュリティ担当	利用部門

事故時に最も避けるべきなのは、「誰かが止めるだろう」という状態である。停止権限を持つ人、顧客説明をする人、ベンダーへ調査依頼する人、経営へ報告する人を先に決める。

RFPに入れるべき責任分界要件

AIエージェント開発を外注する場合、RACIをRFPに入れる。これを入れないと、提案書は機能一覧に偏り、運用責任、ログ、承認、事故対応が抜けやすい。

要件	RFPに書くべき内容
役割定義	発注側、業務部門、情シス、ベンダー、外部SaaSの責任範囲を定義する
承認フロー	高影響操作では承認者、代理承認者、承認ログを設計する
停止権限	異常時に誰がAIエージェントを停止できるかを定義する
ログ確認	ログを見る担当者、頻度、保存期間、異常検知時の通知先を定義する
変更管理	プロンプト、ツール、データ接続、権限、モデル変更時の承認者を定義する
ベンダー責任	障害調査、再発防止、設定変更、運用支援の範囲を定義する
発注側責任	業務判断、データ分類、利用者教育、社内承認の責任を定義する
事故対応	誤送信、情報漏えい、過剰実行、出力不備の初動フローを定義する

RFPで責任分界を明記すると、見積もりも比較しやすくなる。安い提案が、実は運用責任や事故対応を含んでいないだけだった、という失敗を避けられる。

30日で作るAIエージェントRACI

最初から全社完璧なAIガバナンスを作る必要はない。まずは1業務に絞って、30日でRACIを作る。

期間	やること	成果物
1週目	対象業務と関係者を洗い出す	業務フロー、関係部署、利用データ一覧
2週目	作成、確認、承認、実行、監査、停止を分解する	操作一覧、禁止事項、承認条件
3週目	RACI表を作る	業務別RACI、事故時RACI
4週目	RFP、社内規程、運用手順へ反映する	発注要件、運用チェックリスト、ログ確認ルール

この30日で作るべきものは、分厚いガイドラインではない。現場が迷ったときに見られる、1枚の責任分界表である。

GXOが支援できること

GXO株式会社では、AIエージェント導入を、単なるAIツール導入ではなく、業務設計、権限設計、責任分界、RFP設計、運用設計として支援する。

特に、次のような相談は商談化しやすい。

• AIエージェント導入前に、経営・現場・情シス・ベンダーの責任分界を整理したい
• ChatGPT、Copilot、Gemini、Claude、MCP連携を本番利用する前に、承認者と停止権限を決めたい
• AI導入ベンダーへ出すRFPに、RACI、ログ、承認、事故対応を入れたい
• 営業、CS、経理、人事、情シスごとにAI利用責任者を決めたい
• 既存のAI活用が部門任せになっており、経営に説明できる体制にしたい
• AIエージェントの禁止事項、権限、監査ログ、責任分界をまとめて整備したい

AIエージェント導入で重要なのは、誰かを責めるために責任者を決めることではない。事故を防ぎ、事故時に止め、改善し、安心して業務へ広げるために責任分界を決めることである。

→ AIエージェント導入前のRACI設計を相談する

→ FDE+ ReadyでAI導入前の業務・権限・責任分界を相談する

まとめ

AIエージェント導入では、モデル、ツール、プロンプトより先に、責任分界を決める。

最低限、次の6つは本番前に決めておきたい。

• AIの利用目的を承認する人
• AIに渡すデータ範囲を決める人
• AIの権限を承認する人
• AIの出力を確認する人
• AIを止める人
• ベンダーへ改善要求する人

RACIがある会社は、AI導入を止めるのではなく、広げられる。誰が何を決めるかが明確だから、現場は安心して使え、経営は投資判断をしやすくなり、情シスは運用を設計できる。

AIエージェント導入の成否は、AIそのものだけで決まらない。責任分界を設計できるかで決まる。

関連記事

• AIエージェント導入前に決めるべき禁止事項｜送信・削除・決裁を自動化しないルール
• AIエージェント時代のゼロトラスト｜ユーザーではなくエージェントが最弱リンクになる
• AIエージェントの権限管理が新市場に｜Arcade.dev資金調達から見るMCP/A2A時代の発注要件
• AIエージェント導入はPoCから業務実装へ｜最初の1業務を選ぶ7つの基準
• Microsoft 365 CopilotのSearchLeak報道から考える｜社内AI導入前に確認すべき権限棚卸し

参考資料

• NIST, AI Risk Management Framework

https://www.nist.gov/itl/ai-risk-management-framework

• NIST, Cybersecurity Framework

https://www.nist.gov/cyberframework

• OWASP GenAI Security Project, LLM06:2025 Excessive Agency

https://genai.owasp.org/llmrisk/llm062025-excessive-agency/