AIガバナンスとは？企業の体制構築・規程・運用を実務で解説
- 原則禁止で始め、承認済みの選択肢がない
- 現場が個人アカウントや私物端末に流れる
- 審査に期限がなく申請そのものが回避される
- 最も見えないところで機密情報が扱われる
- 禁止は要配慮個人情報の入力などの最小限に絞る
- 定型用途は事前承認済みユースケースとして一覧化
- 5営業日などの内部SLAで審査を止めない
- 台帳で利用実態を可視化し高リスク用途に統制を集中
AIガバナンスとは？企業がいま取り組むべき理由は？
AIガバナンスとは、AI活用のリスクを抑えつつ価値創出を止めないための、意思決定と統制の仕組みを指します。
「守り」の規程集をつくることが目的ではありません。どの用途をどの条件で進めてよいかを判断し、その判断を記録・見直しできる状態をつくることが目的です。以下では対象範囲、優先度が上がった背景、情報セキュリティ管理との違いの順に整理します。
AIガバナンスは何を対象にするのか
対象はAIモデルだけでなく、データ・利用者・業務プロセス・委託先まで含む活動の全体です。
議論は「どのモデルを使うか」に寄りがちですが、実務上の統制点はその前後にあります。
- 入力してよいデータの範囲
- 出力を誰が確認し、どう業務に反映するか
- 外部サービスの利用規約と管理者設定
- 委託先が生成AIを使う場合の取り扱い
ここまでを一つの管理単位として扱うのが、AIガバナンスの基本形です。
経済産業省・総務省の「AI事業者ガイドライン第1.0版」（2024年4月公表）も、AIに関わる主体を「開発者」「提供者」「利用者」に分け、それぞれが果たす事項を整理する構成をとっています。自社がどの立場に該当するかはユースケースごとに変わるため、案件単位で確認する必要があります。
なぜ企業でAIガバナンスの優先度が上がったのか
生成AIの業務利用が部門単位で先行し、規程と利用実態の把握が後追いになる状態が広がっているためです。
Microsoft 365 Copilot、Google WorkspaceのGemini、OpenAIのChatGPT、AnthropicのClaudeといったサービスは、IT部門の大規模な開発を経ずに導入できます。その結果、利用実態の把握が追いつかないまま、社外文書の要約や顧客対応の下書き作成に使われ始めます。
さらに、RAG（検索拡張生成）で社内文書を参照させる構成や、AIエージェントによる自動実行が加わると、権限設計の誤りがそのまま情報漏えいや誤った業務処理に直結します。個人情報保護委員会が2023年6月に生成AIサービスの利用について注意喚起を出したのも、この構造を踏まえたものです。
現場で相談を受けていると、規程整備より先に「どの部署が何に使っているか」の棚卸しから着手したほうが、その後の議論が速く進む傾向があるように見えます。
情報セキュリティ管理との違いはどこか
違いは、出力が確率的で誤りを含む前提に立ち、精度と公平性まで管理対象に含める点にあります。
従来の情報セキュリティ管理は、機密性・完全性・可用性を軸に「守る」ことを主眼としてきました。AIガバナンスでは、ここに次の性質が加わります。
| 観点 | 情報セキュリティ管理 | AIガバナンスで加わる論点 |
|---|---|---|
| 出力の正しさ | システムは仕様どおり動く前提 | 生成AIやLLMは確率的に文章を生成し、出力が誤りうる |
| 公平性 | 主な管理対象ではない | 学習データの偏りが結果の偏りとして現れる |
| 説明可能性 | 処理ロジックを追跡できる | なぜその出力になったか説明しにくい |
ISO/IEC 42001:2023（AIマネジメントシステム、2023年12月発行）が、既存のISO/IEC 27001とは別の規格として整備されたのは、この管理対象の違いを反映したものと理解できます。
企業が押さえるべきAIガバナンスの国内外のルールは？
国内は指針中心、EUは罰則付きの規則、国際規格は認証と運用の型という三層で整理すると全体像を把握しやすくなります。
国内の枠組みはどうなっているか
日本は罰則を伴う横断規制ではなく、ガイドラインと理念法によるイノベーション促進型の設計です。
中核は「AI事業者ガイドライン第1.0版」です。人間中心、安全性、公平性、プライバシー保護、セキュリティ確保、透明性、アカウンタビリティ、教育・リテラシー、公正競争確保、イノベーションの10項目を共通の指針として示しています。2025年に成立した「AI関連技術の研究開発及び活用の推進に関する法律」（AI推進法）も、罰則ではなく国の施策と事業者の協力を定める枠組みです。
ただし、既存法は当然に適用されます。個人情報保護法、著作権法（学習利用については文化庁の文化審議会が2024年3月に「AIと著作権に関する考え方について」を取りまとめています）、金融・医療・雇用など業種別の規制がそれぞれ効いてきます。「AI固有の法規制が薄い＝自由」という読み方は、実務上危険です。
EU AI Actなど海外規制はどこまで自社に及ぶか
EU AI Actには域外適用があり、EU域内で出力が利用される場合は日本企業も対象になり得ます。
EU AI Actは2024年8月1日に発効し、段階的に適用される構成です。
| 適用開始 | 対象となる規定 |
|---|---|
| 2025年2月 | 禁止されるAI慣行 |
| 2025年8月 | 汎用AI（GPAI）に関する義務 |
| 2026年8月 | 高リスクAIに関する主要義務 |
禁止行為違反には、最大3,500万ユーロまたは全世界売上高の7%という水準の制裁金が定められています。EU向け製品にAI機能を組み込む、EU拠点の従業員の採用・評価にAIを使う、といったケースは、該当可能性を個別に確認しておくべき領域です。
ISO/IEC 42001とNIST AI RMFはどう使い分けるか
ISO/IEC 42001は体制運用の型、NIST AI RMFはリスク分析の型で、両者は併用が現実的です。
米国NISTの「AI Risk Management Framework 1.0」（2023年1月公表）は、GOVERN／MAP／MEASURE／MANAGEの4機能でリスクを扱う構成です。2024年7月には生成AI向けプロファイル（NIST AI 600-1）が追加されました。一方のISO/IEC 42001は第三者認証が可能なマネジメントシステム規格で、取引先からの説明要求に耐える体制の証明に向きます。
両者は競合しません。NISTの枠組みでリスクを洗い出し、ISOの枠組みでPDCAを回すという併用が現実的です。主要な枠組みを一覧にすると次のとおりです。
| 枠組み | 発行元 | 性格 | 企業への主な要求 | 主な時期 |
|---|---|---|---|---|
| AI事業者ガイドライン第1.0版 | 経済産業省・総務省 | 法的拘束力のない指針 | 10項目の共通指針、開発者・提供者・利用者別の事項 | 2024年4月公表 |
| AI推進法 | 日本（国会） | 理念法・罰則なし | 国の施策への協力、活用推進 | 2025年成立 |
| EU AI Act | EU | 規則（域外適用あり） | リスク4分類、高リスクは適合性評価・技術文書 | 2024年8月発効／2026年8月に高リスク主要義務 |
| ISO/IEC 42001:2023 | ISO／IEC | 認証可能な管理システム規格 | AIマネジメントシステムの構築・運用・改善 | 2023年12月発行 |
| NIST AI RMF 1.0 | 米国NIST | 任意のフレームワーク | GOVERN／MAP／MEASURE／MANAGEの実践 | 2023年1月公表 |
| 個人情報保護法 | 個人情報保護委員会 | 法律 | 利用目的の特定、第三者提供、要配慮個人情報の管理 | 生成AI利用の注意喚起は2023年6月 |
AIガバナンス体制はどう構築する？
体制は意思決定機関・事務局・現場の三層に役割を割り、規程は4階層で整えるのが実装しやすい形です。
誰が意思決定するのか
取締役会などの承認機関、常設の事務局、実行する現場部門の三層に責任を分けて置きます。
| 層 | 担い手 | 主な責任 |
|---|---|---|
| 意思決定 | 取締役会または経営会議 | 基本方針とリスク許容度の承認 |
| 事務局 | CAIO（Chief AI Officer）やCISO配下の組織 | 審査・台帳管理・モニタリング |
| 現場 | 業務部門 | 個別ユースケースの運用責任 |
事務局には、法務・情報セキュリティ・IT・業務部門・人事の担当者を含めます。法務単独の運用は技術的な実現可能性を判断できず、「原則禁止」に流れやすいため避けたいところです。DX推進の文脈で情報システム部門に閉じていた体制のまま移行すると、事業判断が回らなくなる場面もあります。
規程体系はどう作るのか
基本方針・規程・基準・手順の4階層に分け、変更頻度の高い内容ほど下層に置く設計にします。
技術とサービス仕様の変化が速い領域では、上位文書に具体的なツール名やモデル名を書き込むと改訂が追いつきません。「入力してよいデータの区分」「利用可能なサービス一覧」は下層のガイドラインや別紙に置き、事務局決裁で更新できる設計にしておくと運用が持続します。
| 階層 | 文書 | 決める内容 | 承認者 | 見直し頻度 |
|---|---|---|---|---|
| 1 基本方針 | AI利用基本方針 | 目的、原則、適用範囲、リスク許容度 | 取締役会 | 年1回 |
| 2 規程 | AI利用管理規程、AIリスク管理規程 | 役割分担、審査プロセス、禁止事項、報告義務 | 経営会議／CAIO | 年1回 |
| 3 基準・ガイドライン | 利用ガイドライン、開発基準、評価基準 | 入力可否のデータ区分、ログ保存、精度検証、人による確認の要否 | 事務局 | 半期 |
| 4 手順・様式 | 申請書、リスク評価シート、ユースケース台帳 | 申請と審査の具体手順、記録項目 | 所管部門 | 随時 |
リスク評価とユースケース台帳をどう置くか
全ユースケースを台帳に登録し、影響度に応じて審査の重さを変える二段構えが有効です。
リスク評価は次の三軸で分類します。
- 対象者への影響：採用・与信・医療など人の権利に関わるか
- 扱うデータ：個人情報・機密情報の有無
- 自動化の度合い：人の確認を経るか、AIエージェントが自律実行するか
| リスク区分 | 審査の重さ |
|---|---|
| 低リスク | 届出のみ |
| 中リスク | 事務局審査 |
| 高リスク | 経営承認と事後モニタリング必須 |
こうした段階を置くと、審査待ちによる停滞を抑えられます。台帳には、利用サービス、責任者、対象データ、承認日、次回レビュー日を最低限記録します。
AIガバナンスの運用と実効性はどう担保する？
審査期限、継続モニタリング、インシデント対応、監査証跡、教育の5点を回し続ける設計が必要です。
審査を止めない運用はどう作るか
審査に期限を設け、低リスク類型は事前承認テンプレートで通す仕組みが実効性を左右します。
必要なのは次の2つです。
- 「申請から回答まで5営業日」といった内部SLAを明示する
- 社内文書の要約や議事録作成のような定型用途を、事前承認済みユースケースとして一覧化する
この2つがないと、現場は申請そのものを回避し、個人アカウントでの利用に流れます。実務としては、審査の厳格さより回答の速さのほうが規程遵守率に効いている、という感触があります。
運用中のモニタリングは何を見るか
精度・公平性・セキュリティ・権利と法令・コスト・委託先の6観点を定期的に確認します。
生成AIやLLMを組み込んだ業務は、モデルやサービス仕様の更新によって、自社が何も変更していないのに出力の傾向が変わります。導入時の検証結果が有効であり続ける前提は置けません。業務側の差し戻し率のように現場が自然に生む指標を監視項目に入れておくと、負荷をかけずに劣化を検知できます。
| 観点 | 主な監視指標 | 頻度 | 一次責任 |
|---|---|---|---|
| 精度・品質 | 出力の誤り件数、業務側の差し戻し率 | 月次 | 業務所管部門 |
| 公平性 | 属性別の結果差、苦情・異議申立件数 | 半期 | 事務局＋法務 |
| セキュリティ | プロンプトインジェクション検知、権限逸脱アクセス | 常時 | セキュリティ部門 |
| 権利・法令 | 著作権・個人情報に関する申告件数 | 四半期 | 法務 |
| コスト・利用状況 | API利用量、承認済みユースケースの稼働率 | 月次 | IT部門 |
| 外部委託 | 委託先のモデル変更・規約変更の届出 | 変更時 | 調達＋事務局 |
インシデント対応と監査証跡はどう整えるか
AI起因の事象を既存のインシデント報告経路に接続し、入出力ログの保存期間を規程で定めます。
誤情報の社外提示、機密情報の入力、AIエージェントの誤操作といった事象は、既存の情報セキュリティインシデントの定義に収まらないことがあります。報告対象の例示を規程に列挙し、初動の判断者を明記しておくことが必要です。
監査証跡としては、誰が・どのサービスに・どの分類のデータを入力し・出力をどう使ったかを追跡できる状態を目指します。ログ取得の可否は契約形態や管理者設定で変わるため、サービスごとに一次情報で確認するのが前提です。
教育・リテラシーはどこまで求めるか
全社共通の基礎教育と、高リスク用途の担当者向け実務研修を分けて設計するのが現実的です。
AI事業者ガイドラインも「教育・リテラシー」を共通指針の一つに挙げています。対象別に求める水準は次のとおりです。
| 対象 | 研修の範囲 |
|---|---|
| 全社員 | 入力してよい情報の区分、出力の確認義務、報告経路の3点に絞った短時間研修 |
| 高リスク用途の担当者 | 上記に加え、評価データセットの作り方、人による確認の設計 |
AIガバナンスでよくある失敗と回避策は？
失敗は「禁止に偏る」「文書が更新されない」「技術を評価できない」の三系統にほぼ集約されます。
禁止中心の規程が招く問題は何か
過度な禁止はかえって利用の地下化を招き、統制が及ばない「シャドーAI」の温床になります。
原則禁止で始めた組織では、業務効率を求める現場が個人アカウントや私物端末に流れ、最も見えないところで機密情報が扱われることになります。回避策は、禁止事項を必要最小限（要配慮個人情報の入力、未承認サービスへの顧客データ投入など）に絞り、承認済みの選択肢を先に用意することです。「使ってよい道」を提示しない規程は、実質的に統制を放棄している状態に近づきます。
文書が形骸化する原因はどこにあるか
上位文書に具体的なツール名や技術要件を書き込み、改訂手続きが重すぎることが主な原因です。
年1回の取締役会決議しか改訂手段がない規程は、生成AIやAIエージェントの仕様変更に追随できません。階層設計で下層に可変部分を寄せ、事務局決裁で更新できる範囲を明示しておきます。あわせて、ユースケース台帳に「次回レビュー日」を必須項目として持たせ、期限到来をワークフローで通知する運用にしておくと放置を防げます。
体制面で見落とされやすい点は何か
事務局に技術を評価できる人員がいないことと、委託先の利用実態を把握できていないことです。
法務と内部監査だけで構成された事務局は、RAGの参照権限設計やAIエージェントの実行範囲といった論点を評価できません。技術側の担当を常設メンバーに入れることが前提です。
もう一つの盲点が委託先です。業務委託先が自社の判断で生成AIを使い、成果物や預けたデータが外部サービスを経由している可能性があります。契約書にAI利用の届出義務、再委託時の取り扱い、ログ提供の条項を入れておくかどうかで、事故時の説明可能性が大きく変わります。
| よくある失敗 | 起きる事象 | 回避策 |
|---|---|---|
| 原則禁止で運用 | 個人アカウント利用が広がり実態が不可視化 | 承認済みユースケースを先に整備し、禁止は最小限に絞る |
| 審査に期限がない | 現場が申請を回避、導入が停滞 | 内部SLA（例：5営業日）と低リスク類型の事前承認 |
| 上位規程に技術詳細 | 改訂が追いつかず文書が形骸化 | 可変部分を基準・別紙に移し事務局決裁で更新 |
| 事務局が法務のみ | 技術リスクを評価できず判断が保守化 | IT・セキュリティ・業務部門を常設メンバーに |
| 導入時の検証で終了 | サービス更新後の品質劣化を検知できない | 差し戻し率などの業務指標を定期モニタリング |
| 委託先の利用が不明 | 事故時に経路を説明できない | 契約にAI利用の届出・再委託条件・ログ提供を明記 |
| 台帳がない | 全社のAI利用が棚卸しできない | 全ユースケース登録と次回レビュー日の必須化 |
企業はまず何から着手すべきか
規程を書く前に、部門ごとのAI利用の棚卸しとユースケース台帳の作成から始めるべきです。
AIガバナンスの整備は、規程を書く作業から始めると難航しがちです。先に着手すべきは、いま社内でどの部門が何にAIを使っているかの棚卸しと、ユースケース台帳の作成です。実態が見えた段階で、リスクの高い用途にだけ厚い統制をかける。この順序であれば、利活用の速度を落とさずに体制を立ち上げられます。
