AIガバナンスの体制｜5つの役割分担
目次
はじめに
生成AIの利用ルールを作り、相談窓口も置いた。それでも案件が止まる。
営業部は顧客メールの下書きに使いたい。情シスはデータの扱いを確認したい。法務は契約と著作権が気になる。推進担当は「結局、誰が許可を出すのか」と会議を重ねる。全員が必要な仕事をしているのに、最後の判断者だけが見えない。
AIガバナンスの体制で難しいのは、立派な委員会を作ることではない。案件ごとに、実行する人、最終責任を持つ人、助言する人を分けることだ。
専任のCAIOや大きな組織がなくても始められる。事業、AI推進、IT・データ、リスク、経営という5つの役割を、まず一つの案件へ割り当てればよい。
AIガバナンスの体制が止まる3つの原因
推進担当へ責任が集まりすぎる
よくあるのは、AI推進担当が企画、ツール選定、セキュリティ確認、利用教育、成果測定まで抱える形だ。推進担当は全体をつなげられる。ただし、営業メールの正しさや個人情報の利用可否まで一人で決められるわけではない。
業務の結果に責任を持つのは事業部門である。技術的な安全性はIT・データ担当が 見る。法令や契約は法務などのリスク担当が見る。この境界を曖昧にすると、推進担当は確認待ちの受け皿になる。
助言者と承認者が混ざる
「法務確認済み」という言葉にも幅がある。論点を助言しただけなのか、利用を承認したのか。コメントした人が最終責任者に見えると、誰も決裁を引き取らなくなる。
RACIでは、実行担当をResponsible、最終責任者をAccountable、助言者をConsulted、報告先をInformedとして分ける。案件や成果物ごとにAccountableを一人にするのが肝だ。
止める人が決まっていない
導入時の承認者は決めても、運用中の停止権限が抜けやすい。誤送信、参照データの漏えい、急な品質低下が起きたとき、誰が機能を止められるだろうか。
AISIの「CAIO設置・AIガバナンス実務マニュアル（案）」は、数十名程度のスタートアップを想定し、推進側と別のセーフティオーナーへ停止権限を持たせる案を示す。これは2026年2月時点の案である。以下では、その役割分離を社内利用にも応用する。
AIガバナンスを回す5つの役割
肩 書は会社ごとに違う。そこで、部署名ではなく「何を決める機能か」で置いてみる。
1. 事業オーナー
対象業務の成果と現場運用に責任を持つ。AIを使う目的、許容できる誤り、人が確認する場面を決める役割だ。
営業メールなら営業責任者、採用書類なら人事責任者が担う。AIの精度を技術担当へ丸投げせず、「重要顧客への返信は必ず課長が確認する」のように業務条件へ落とす。
2. AI推進責任者
案件を横断し、共通ルールと現場の間をつなぐ。ユースケース台帳、審査の窓口、評価テンプレート、教育を整える。
推進責任者は何でも承認する役ではない。判断材料を揃え、適切な責任者へ届ける。AISIの同資料も、CAIOがすべてを直接管理せず、CISOや法務、事業部門と分担する考え方を示している。
3. IT・データ責任者
ツール、認証、アクセス権、ログ、データ連携、障害対応を持つ。モデルの性能だけでなく、入力データがどこへ送られ、どれだけ保存されるかを確認する。
AI案件ではプロンプトが注目される。ところが、事故の境界はアカウントや外部連携に現れやすい。シャドーAIの対策で扱ったように、禁止だけでなく、利用できる入口と相談経路を用意する仕事でもある。
4. リスク責任者
法務、情報セキュリティ、プライバシー、人権、品質などの観点から助言し、高リスク案件を監督する。一人の万能担当を置く必要はない。案件に応じて必要な専門家をConsultedにする。
NTT DATAのAIガバナンス活動でも、技術だけでなく法務、知財、情報セキュリティを含む横断体制が紹介されている。AIのリスクは一部門のチェックリストだけでは閉じない。
5. 経営スポンサー
優先順位、予算、受け入れるリスクの水準を決める。日々の審査へ毎回参加する役ではない。部門同士で判断が割れたときの決裁と、重大事故の報告先を引き受ける。
経済産業省のAI事業者ガイドライン第1.2版は、経営層のリーダーシップの下でAIガバナンスを構築し、継続的に見直す枠組みを示している。方針 を掲げるだけでなく、投資と停止の判断まで経営につながっている必要がある。
RACIを1案件で作る
RACIは組織全体を一度に埋めると重い。以下は、社内向け営業メールの下書きという低リスク案件の例である。
| 成果物・判断 | 事業 | AI推進 | IT・データ | リスク | 経営 |
|---|---|---|---|---|---|
| ユースケース台帳 | A/R | R | C | C | I |
| データ・権限表 | C | R | A/R | C | I |
| 評価結果 | A | R | C | C | I |
| 本番リリース判定 | A | R | C | C | I |
| 事故記録 | C | R | A/R | C | I |
| 緊急停止判断 | C | R | R | A | I |
| 再開判定 | R | R | C | A | I |
採用の合否、与信、医療など人への影響が大きい用途では、リリース判定のAを経営へ移し、独立したリスク監督を入れる。RACIは用途の危険度で変える。
会議の参加者ではなく成果物の所有者を決める。誰が台帳を更新し、評価へ署名し、再開を承認するのか。ここまで書けば、担当者が変わっても判断が残る。
ソフトバンクの公開するAIガバナンスの体制では、個々のAI利活用部門が成果の妥当性やリスク評価を管理し、説明する。中央だけでなく、利用部門にも運用責任を置く形だ。
外部のSIerと進める場合も、Aをベンダーへ丸ごと移さない。顧客は業務要件、提供データ、受入基準、リリース可否のAを持つ。SIerは実装、試験記録、障害の一次対応をRとして持つ。モデルやクラウドの仕様変更時は、SIerが影響を報告し、顧客が再評価を承 認する。ここが契約と仕様書の両方にないと、「技術的には動くが、誰も受け入れられない」で止まる。
企業規模別の最小構成
30人規模なら3人で5役を持つ
CEOまたはCTOが経営スポンサーとAI推進責任者を兼ねる。対象業務の責任者を事業オーナーにする。情シスや情報管理担当がIT・データ責任者とセーフティオーナーを担う。専門性が必要な案件だけ、外部の弁護士やセキュリティ専門家へ相談する。
兼務はできる。ただし、推進と停止を一人で完結させない。
数百人規模なら中央と現場を分ける
AI推進の小さなCoEが台帳、共通基準、教育を持つ。各事業部には事業オーナーを置き、案件の成果と運用を持たせる。IT・データ、法務、セキュリティは高リスク案件に重点参加する。
全部の案件を月一回の委員会へ集めると遅い。低リスクは共通基準で現場承認し、高リスクだけ中央審査へ上げる二段階が現実的だ。
規制産業では推進と監督を分ける
規制や人への影響が大きい業務では、推進部門と監督部門の独立性を高める。金融庁のAI官民フォーラム資料には、データ、業務、システム、リスク管理の各部門が横断で体制を強化した事例がある。利用を進めながら、審査プロセス、ルール、教育を同時に整える発想だ。
30日で体制を動かす手順
1週目は対象業務を一つ選び、5役へ実名を入れる。業務量、利用データ、人への影響、外部送信の有無を一枚にまとめる。
2週目はユースケース台帳、権限表、評価ケースを作る。正しい回答例だけでなく、答えてはいけない例、情報不足で人へ戻す例も入れる。AI社員の導入失敗を防ぐ運用設計も、仕事、情報、承認、評価、改善をつなげる観点で使える。
3週目は模擬審査を行う。通常ケース、機密情報を含むケース、品質低下のケースを流し、誰が判断に詰まるかを見る。議論の量より、未決の責任を見つけるのが目的だ。
4週目は限定利用を始める。実行件数、差し戻し、修正理由、停止回数を週次で確認する。問題が起きたら「AIが悪い」で終わらせず、業務条件、データ、権限、評価のどこを直すか決める。
30日後に残すのは、役割表、ユースケース台帳、権限表、評価結果、審査記録、停止・再開手順の6点だ。全社規程より先に、この一式を1案件で動かす。
体制は組織図より成果物で確認する
AIガバナンスの体制が機能しているかは、部署名の数では測れない。
- ユースケースごとに最終責任者が一人いる
- データと権限の所有者が決まっている
- 合格条件と禁止条件を文書で確認できる
- 異常時に止める人と手順がある
- 判断と変更の履歴が残る
この五つが揃っていれば、兼務中心の小さな体制でも案件を進められる。逆に、AI委員会があっても成果物の責任者がいなければ、確認会議は増える。
AIエージェントのガバナンス設計では承認や責任の原則を扱った。ここで一歩進めたのは、原則を案件成果物のRACIへ落とした点だ。誰が何を承認し、どの条件ならAIが止まるのか。仕様書と受入基準へ書けば、顧客とSIerが同じ条件で話せる。
自社のAIガバナンスを一つの案件から設計したい場合は、Atsumellへ相談してほしい。業務フローの整理から、役割分担、承認条件、評価、実装まで一緒に組み立てられる。
