「社員による生成AI利用が増えてきたが、会社として管理できていない」
「生成AIの社内ルールを作ったが、それだけで十分なのか分からない」
「AIシステムを導入するとき、誰が責任を持つべきなのか」
「AIエージェントやRAGまで利用する場合、どこまで統制すればよい？」
このような企業で重要になるのが、生成AIガバナンスです。
生成AIガバナンスとは、単に、
個人情報を入力しない
といった利用ルールを作ることではありません。
例えば、
誰がAI導入を承認するか
どのAIサービスを利用できるか
どのデータへアクセスできるか
どの業務までAIに任せられるか
問題が発生した場合に誰が対応するか
AIモデル変更時に誰が再評価するか
まで含めて、企業としてAI利用を管理する仕組みです。
経済産業省・IPAなどが策定する「AI事業者ガイドライン」は、AIを利用する企業を含む事業者がリスクを適切に認識し、自主的に必要な対策を行うための、日本におけるAIガバナンスの統一的な指針として位置付けられています。最新版は2026年3月31日に公表された第1.2版です。
この記事では、生成AIガバナンスとは何か、企業が整備しておきたい管理体制、リスク評価、アクセス権限、ログ、インシデント対応、継続的な見直しについて解説します。
生成AIガバナンスとは
生成AIガバナンスとは、
生成AIを
安全かつ事業目的に沿って
利用・管理するための企業統制
です。
例えば会社が生成AIを導入すると、次のような問題が発生します。
営業：
顧客メールをAIで要約したい
人事：
応募者情報をAIで整理したい
開発：
ソースコードをAIへ入力したい
総務：
社内規程をRAGで検索したい
経営：
AIエージェントで業務を自動化したい
これらについて、
現場が自由に判断する
だけでは企業全体としてのリスク管理が難しくなります。
そこで、
利用目的
↓
リスク評価
↓
承認
↓
利用
↓
監視
↓
改善
という仕組みを作ります。
これが生成AIガバナンスです。
生成AIガイドラインとの違い
「社内向け生成AIガイドライン」と「生成AIガバナンス」は似ていますが、範囲が異なります。
生成AIガイドラインは主に、
社員がAIを利用するときのルール
です。
例えば、
利用可能なAI
入力禁止情報
個人情報の扱い
AI出力の確認
社外公開時の注意
などです。
一方、生成AIガバナンスは、
企業としてAIをどのように管理するか
まで含みます。
例えば、
AI導入責任者
AIサービスの審査
リスク評価
承認フロー
アクセス権限
利用ログ
インシデント対応
定期レビュー
です。
つまり、
生成AIガイドライン
=
利用者向けルール
生成AIガバナンス
=
会社全体の管理体制
と考えると分かりやすいでしょう。
なぜ生成AIガバナンスが必要なのか
生成AIは一般的なSaaSよりも利用方法が幅広いためです。
例えばメールサービスなら、
メールを送る
という利用目的が比較的明確です。
生成AIの場合、
文章作成
要約
データ分析
コード生成
顧客対応
採用
契約書確認
社内検索
AIエージェント
など、さまざまな用途に利用できます。
さらに、
社員が直接ChatGPT等を利用
するだけでなく、
業務システム
↓
AI API
や、
AI
↓
MCP
↓
社内システム
といった高度な連携も増えています。
AIの利用範囲が広がるほど、
何をAIへ許可してよいか
を企業として管理する必要があります。
生成AIガバナンスで管理する主な対象
企業で管理したい対象を整理すると、主に次のようになります。
| 管理対象 | 具体例 |
|---|---|
| AIサービス | ChatGPT、Gemini、社内AIなど |
| 利用者 | 社員、管理者、外部委託者 |
| データ | 個人情報、顧客情報、機密情報 |
| 利用目的 | 要約、検索、分析、自動化 |
| AIシステム | RAG、AIエージェント |
| 外部連携 | API、MCP、SaaS |
| 権限 | 閲覧、更新、送信、削除 |
| モデル | 利用モデル、バージョン |
| ログ | AI利用・Tool実行履歴 |
| インシデント | 情報漏えい、誤操作など |
生成AIガバナンスでは、これらを個別に管理するのではなく、全体として管理します。
生成AIガバナンスの基本構造
例えば次のような構成です。
経営
↓
AI利用方針
↓
AI責任者・管理部門
↓
利用サービス審査
↓
AIシステム・ユースケース審査
↓
各部署
↓
社員による利用
↓
ログ・KPI・インシデント
↓
定期レビュー
重要なのは、
AI利用を管理部門だけで決める
ことでも、
現場へ完全に任せる
ことでもありません。
実際の業務を知っている現場と、情報システム・セキュリティ・法務・経営などが連携する必要があります。
1．生成AI利用の責任者を決める
まず、
誰がAI利用について責任を持つのか
を決めます。
小規模企業なら、
経営者
+
IT担当
でも構いません。
中規模以上なら、
AI責任者
情報システム
セキュリティ
法務
各事業部門
などで体制を作ります。
重要なのは、
問題が起きたときに
誰へ確認すればよいか分からない
状態をなくすことです。
AI責任者の役割
例えば、
AI利用方針の決定
利用サービス承認
高リスク案件の承認
インシデント対応
ルールの見直し
利用状況の経営報告
などを担当します。
すべてを一人で実施する必要はありません。
2．利用可能な生成AIサービスを管理する
社員が自由に生成AIサービスを選べる状態では、
どこへ会社データが送られているか
を把握できません。
そこで、
承認済みAI一覧
を作ります。
例えば、
○ 会社契約の生成AI
○ 社内AIシステム
○ 承認済みAPI
△ 部署限定AI
× 個人契約の未承認AI
とします。
AIサービス導入時に確認する項目
例えば、
入力データの利用目的
モデル学習への利用
データ保持期間
保存地域
ユーザー管理
SSO・MFA
ログ
削除方法
再委託
外部サービス連携
などです。
「有名なAIだから利用可能」とするのではなく、会社として利用条件を確認します。
3．AI利用をユースケース単位で管理する
同じAIでも、利用方法によってリスクが異なります。
例えば、
公開文章の校正
と、
社員の人事評価支援
ではリスクが異なります。
そのため、
どのAIを使うか
だけでなく、
何に使うか
を管理します。
AIユースケース台帳を作る
例えば次のように整理します。
| ID | 部署 | AI利用 | データ | リスク | 責任者 |
|---|---|---|---|---|---|
| AI-001 | 営業 | メール下書き | 顧客情報 | 中 | 営業部長 |
| AI-002 | 総務 | 社内FAQ | 社内規程 | 低 | 総務部長 |
| AI-003 | 人事 | 応募者整理 | 個人情報 | 高 | 人事責任者 |
| AI-004 | 開発 | コードレビュー | ソースコード | 中 | 開発責任者 |
こうすると、
会社で何のAIが
どこで使われているか
を把握できます。
4．AI利用をリスクレベルで分類する
すべてのAI利用に同じ承認手続きを適用すると、管理コストが大きくなります。
そこで、
低リスク
中リスク
高リスク
などに分類します。
低リスク
例えば、
公開文章の校正
アイデア出し
社内文書の下書き
です。
中リスク
顧客メールの要約
社内データ分析
RAGによる社内検索
などです。
高リスク
個人情報を大量に扱う
採用・人事評価へ利用
契約・与信判断
AIによる自動更新
外部への自動送信
などです。
高リスクになるほど、
事前審査
責任者承認
ログ
人による確認
定期レビュー
を強化します。
NISTのAI RMFでは、AIリスク管理を組織の目的、利用環境、リスク許容度などと結び付け、継続的に管理する考え方が示されています。生成AI向けのGenerative AI Profileも、生成AI特有のリスクを組織が特定・管理するための補助資料として位置付けられています。
5．AIへ入力できるデータを分類する
生成AIガバナンスではデータ管理が重要です。
例えば、
Level 1
公開情報
Level 2
一般社内情報
Level 3
機密情報
Level 4
重要機密・個人情報
と分類します。
AIサービス側も、
一般AI
会社契約AI
社内専用AI
などに分類します。
そして、
データ分類
×
AI環境
で利用可否を決めます。
例えば、
| データ | 一般AI | 法人AI | 社内専用AI |
|---|---|---|---|
| 公開情報 | ○ | ○ | ○ |
| 社内情報 | △ | ○ | ○ |
| 機密情報 | × | △ | ○ |
| 認証情報 | × | × | × |
のようにします。
6．ユーザー権限をAIでも維持する
RAGやAIエージェントでは特に重要です。
例えば、
社員A
↓
通常の社内システム
↓
担当顧客のみ閲覧可能
なのに、
社員A
↓
AI
↓
全顧客を検索可能
となってはいけません。
基本は、
ユーザー
↓
認証
↓
権限確認
↓
許可されたデータだけ取得
↓
AI
です。
AIだから特別な管理者権限を与えるのではなく、既存のアクセス権限を維持します。
7．AIへ許可する操作権限を管理する
生成AIが文章を生成するだけなら、影響範囲は比較的小さくなります。
しかしAIエージェントになると、
メール送信
CRM更新
契約変更
ファイル削除
注文処理
などを実行できます。
そこで、
Read
Write
Send
Delete
などを分けます。
例えば、
顧客情報を見る
→ 自動実行可能
CRMメモを作る
→ AIが提案
CRMを更新
→ 人が承認
顧客を削除
→ AIには許可しない
とします。
最小権限を基本にする
AIへ、
将来使うかもしれないから
全部の権限を与える
のではなく、
現在の業務に必要な権限だけ
を付与します。
通常の情報セキュリティと同じ考え方です。
8．Human in the Loopを設計する
Human in the Loopとは、AI処理の途中に人による確認を入れることです。
例えば、
顧客問い合わせ
↓
AI
↓
返信案
↓
担当者確認
↓
送信
です。
高リスク操作では、
AI
↓
実行内容を提案
↓
承認
↓
実際に処理
とします。
例えば、
支払い
返金
契約変更
人事判断
重要メール送信
データ削除
などです。
9．AI出力の責任者を決める
生成AIガバナンスでは、
AIが作ったからAIの責任
とはできません。
AIを業務で利用した場合、
誰が最終成果物を確認するのか
を決めます。
例えば、
営業メール
→ 営業担当
契約文書
→ 法務・担当者
採用関連
→ 人事担当
社外公開文章
→ 広報責任者
です。
10．AI利用ログを残す
AI利用を監査できるようにします。
例えば、
誰が
いつ
どのAIを
何の目的で
どの機能を使ったか
を記録します。
独自AIシステムなら、
user_id
AI機能
利用モデル
実行日時
Tool実行
処理結果
エラー
などです。
すべてのプロンプトを保存すればよいわけではない
ログ自体に、
個人情報
顧客情報
機密情報
が含まれる可能性があります。
そのため、
ログ保存対象
保存期間
閲覧可能者
利用目的
まで決めます。
11．モデル・プロンプト変更を管理する
通常のシステムでは、
プログラム変更
↓
テスト
↓
本番反映
を行います。
生成AIでも同様に、
モデル変更
プロンプト変更
RAG検索設定変更
Tool追加
によって回答や動作が変わります。
例えば、
モデルA
↓
モデルBへ変更
しただけで、
回答精度
文章の傾向
Tool利用方法
コスト
レスポンス速度
が変わる可能性があります。
そのため、
変更
↓
評価
↓
承認
↓
本番反映
という変更管理を行います。
12．AIの評価方法を決める
生成AIシステムでは、
動いた
だけでは十分ではありません。
例えば問い合わせAIなら、
回答正確性
回答できない場合の動作
情報漏えい
不要なTool実行
処理時間
APIコスト
を評価します。
RAGなら、
必要な文書を検索できるか
回答根拠が正しいか
権限外データが出ないか
を確認します。
定期的に再評価する
生成AIは変化が速いため、
導入時にテストしたから終了
ではありません。
例えば、
3か月ごと
半年ごと
モデル更新時
重大な機能追加時
などに再評価します。
NIST AI RMFもAIリスク管理を一度きりの作業ではなく、AIライフサイクルを通じて継続的に扱う枠組みとして設計されています。
13．生成AIインシデント対応フローを決める
例えば、
社員が機密情報を未承認AIへ入力
AIが顧客へ誤った内容を送信
AIエージェントが誤更新
RAGから権限外文書が表示
といった問題が発生する可能性があります。
事前に、
問題発見
↓
AI利用停止
↓
担当部署へ報告
↓
影響範囲確認
↓
データ・ログ調査
↓
原因分析
↓
再発防止
↓
必要に応じて報告
というフローを決めます。
インシデントの報告先を明確にする
社員が、
AIに誤って顧客情報を入力してしまった
と気付いたとき、
誰にも言わない
状態が最も危険です。
そのため、
AI利用担当
情報セキュリティ担当
上司
など、報告先を明確にします。
NISTの生成AIリスク管理に関する取り組みでも、ガバナンス、導入前テスト、コンテンツの由来、インシデント開示などが重要な検討領域として扱われています。
14．AIベンダー・外部サービスを継続監視する
一度AIサービスを審査しても、その後に、
利用規約変更
新機能追加
データ利用条件変更
モデル変更
外部連携追加
などが発生する可能性があります。
そのため、
契約時だけ確認
ではなく、継続的に利用条件を確認します。
特に、
個人情報
機密情報
外部サービス接続
を扱うAIについては重要です。
15．生成AIの利用状況を経営層へ報告する
生成AIガバナンスは、情報システム部門だけの仕事ではありません。
経営層も、
どの程度AIが利用されているか
どんな効果が出ているか
重大なリスクがないか
どんなAIシステムを導入予定か
を把握する必要があります。
例えば四半期ごとに、
承認済みAI：5サービス
AI利用者：120人
AI関連システム：8件
削減時間：月350時間
インシデント：1件
高リスクAI案件：2件
などを報告します。
ガバナンスは「AIを止める仕組み」ではない
生成AIガバナンスを厳しくしすぎると、
AIを利用するたびに
10ページの申請
といった状態になり、現場で利用されなくなります。
重要なのは、
低リスク
→ 簡単に利用
中リスク
→ 部署責任者確認
高リスク
→ 専門審査
のように、リスクに応じて管理レベルを変えることです。
経済産業省・IPAが示すAIガバナンスも、変化の速いAI環境を前提として継続的に見直す「アジャイル・ガバナンス」の考え方を取り入れています。AI事業者ガイドライン自体もLiving Documentとして更新されています。
中小企業の生成AIガバナンスはどこまで必要？
中小企業が大企業と同じAI委員会を作る必要はありません。
例えば最初は、
経営者
↓
AI責任者1名
↓
IT・セキュリティ担当
↓
各部署
程度でも構いません。
最低限、
利用できるAI
利用できるデータ
高リスク業務
AI導入の承認者
問い合わせ先
インシデント報告先
を決めておくだけでも管理しやすくなります。
IPAの生成AI導入・運用ガイドラインも、導入・運用・利用ルール・リスク管理を分けて整理しており、組織規模や状況に応じて実践できる内容になっています。
中小企業向けの簡易AIガバナンス例
例えば、
【AI責任者】
代表取締役またはIT責任者
【利用可能AI】
会社承認済みサービスのみ
【一般利用】
文章作成・要約・アイデア整理
【要承認】
顧客情報・社内文書を扱うAI
【禁止】
認証情報の入力
AIによる自動契約
重要データの自動削除
【高リスク処理】
必ず人が確認
【問題発生時】
AI責任者へ即時報告
【見直し】
半年ごと
程度から始められます。
AIガバナンスの導入手順
STEP1．現在利用しているAIを把握する
まず、
誰が
何のAIを
何に使っているか
を調査します。
既にシャドーAIが存在している可能性もあります。
STEP2．AI利用方針を決める
例えば、
AIを積極的に活用する
ただし高リスク業務は統制する
などです。
STEP3．管理責任者を決める
AI利用・セキュリティ・インシデントの責任者を決めます。
STEP4．承認済みAIを整理する
会社として利用可能なAIサービス一覧を作ります。
STEP5．AIユースケースを登録する
例えば、
営業メール
社内RAG
AI OCR
AIエージェント
などです。
STEP6．リスク評価する
扱うデータ
影響範囲
自動実行の有無
社外影響
などから評価します。
STEP7．必要な統制を追加する
例えば、
アクセス制御
Human in the Loop
ログ
利用制限
などです。
STEP8．本番運用する
実際に利用します。
STEP9．利用状況を監視する
AI利用量
エラー
インシデント
費用
業務効果
を確認します。
STEP10．定期的に見直す
モデル・サービス・業務が変わればガバナンスも更新します。
生成AIガバナンスのチェックリスト
体制
□ AI責任者が決まっている
□ 高リスクAIの承認者が決まっている
□ インシデント報告先が明確
AIサービス
□ 承認済みAI一覧がある
□ 新しいAI導入時の審査がある
□ 契約・データ利用条件を確認している
データ
□ AIへ入力可能なデータ区分がある
□ 個人情報の扱いが決まっている
□ 機密情報の扱いが決まっている
システム
□ ユーザー権限を維持している
□ RAGにアクセス制御がある
□ AIエージェントに最小権限を適用している
□ 高リスク操作に承認がある
運用
□ AI利用ログを取得している
□ モデル変更時に評価している
□ インシデント対応手順がある
□ 定期的にAI利用状況を見直している
生成AIガバナンスでよくある失敗
ルールを作っただけで終わる
実際のAI利用状況を確認しなければ統制できません。
すべてのAI利用を同じレベルで管理する
低リスク利用まで複雑な承認にすると現場で使われなくなります。
AIサービスだけ管理する
同じAIでも利用目的によってリスクは異なります。
ユースケース単位で管理します。
AIを管理者権限で社内システムへ接続する
必要な権限だけ付与します。
ログを取得しない
問題発生時に何が起きたか確認できません。
モデル変更を軽視する
AIモデルを変更すると動作が変わる可能性があります。
ガバナンス部門と現場が分離する
実際の業務を理解していないと、過剰なルールになりやすくなります。
生成AIガバナンスに関するよくある質問
生成AIガバナンスとAIガイドラインは同じですか？
完全には同じではありません。
ガイドラインは主に社員の利用ルールです。
ガバナンスは、
責任者
承認
リスク評価
アクセス制御
監査
インシデント対応
まで含む企業全体の管理体制です。
小規模企業でもAIガバナンスは必要ですか？
AIを業務利用するのであれば、最低限の責任者・利用サービス・禁止事項・高リスク業務・報告先は決めておくとよいでしょう。
大規模な委員会を設置する必要はありません。
AIの利用履歴はすべて保存すべきですか？
必ずしもすべて保存する必要はありません。
ログ自体に個人情報・機密情報が含まれる可能性があるため、保存対象・期間・閲覧者を決めます。
ChatGPTなどを社員が使うだけでもガバナンスは必要ですか？
利用規模が大きくなれば検討した方がよいでしょう。
特に、
複数部署で利用
顧客情報を扱う
社内文書を扱う
場合は会社として管理しやすい仕組みを整えます。
RAGにもガバナンスが必要ですか？
必要です。
特に、
誰がどの文書を検索できるか
というアクセス制御と、登録する文書の管理が重要です。
AIエージェントは通常の生成AIより厳しい管理が必要ですか？
操作権限を持つAIエージェントでは影響範囲が広くなるため、より慎重な権限管理が必要です。
閲覧・更新・送信・削除を分け、重要な操作には人による承認を入れます。
hiro-dev-labの生成AIガバナンスを考慮したシステム開発
hiro-dev-labでは、単に生成AI APIを接続するだけでなく、企業利用を前提としたAIシステム設計・開発を支援しています。
例えば、
- ユーザー認証を含むAIシステム
- 権限を考慮したRAG
- AI処理ログ
- OpenAI APIなどを利用したAI機能
- Human in the Loop
- AIエージェントのTool権限設計
- MCPによる社内システム連携
- API・データベース連携
- DifyによるAIアプリ
- n8nによる業務自動化
- Python・TypeScriptによるAI機能開発
などを検討できます。
例えば、
社員
↓
ログイン
↓
権限確認
↓
AI
↓
許可された社内データのみ取得
↓
回答
↓
操作が必要なら承認
↓
ログ保存
という構成です。
AIガバナンスは文書上のルールだけではありません。
権限管理
アクセス制御
ログ
Human in the Loop
などをシステム側で実装することも重要です。
生成AIガバナンスは「AIを安全に止める」ではなく「安全に使い続ける」ための仕組み
生成AIガバナンスを導入すると、
AI利用が面倒になる
と考えるかもしれません。
しかし、本来の目的は逆です。
安全性が分からない
↓
会社としてAIを禁止
ではなく、
リスクを把握
↓
許可できる範囲を決める
↓
必要な統制を追加
↓
安全に利用する
ための仕組みです。
企業では最低限、
1．AI利用方針
2．AI責任者
3．承認済みサービス
4．AIユースケース管理
5．リスク分類
6．データ管理
7．アクセス権限
8．AI操作権限
9．Human in the Loop
10．利用ログ
11．変更管理
12．AI評価
13．インシデント対応
14．定期レビュー
を整理します。
そして、
導入
↓
利用
↓
監視
↓
評価
↓
改善
を繰り返します。
NISTのAI RMFや日本のAI事業者ガイドラインも、AIリスクを継続的に管理し、組織の状況や利用目的に応じて改善していく考え方を重視しています。
「社員による生成AI利用が増えて管理が必要になってきた」
「RAGを導入したいが権限管理まで考えたい」
「AIエージェントを社内システムと接続したい」
「企業利用を前提に安全なAIシステムを設計したい」
このような段階からでも、お気軽にお問い合わせください。
生成AI・AIシステム開発について相談する