AIガバナンスとは？経営者が導入可否を決める比較基準・7ステップ・チェックリスト
AI脆弱性診断
そのAIシステム、従来の診断だけで十分ですか？
外部・内部の弱点に加え、プロンプトインジェクションや過剰な権限などAI固有の攻撃面も診断します。
AIガバナンスとは、AIを「導入するか」だけで終わらせず、誰が何を任せ、どの失敗を許容せず、どの結果なら継続・拡大・停止するかを決めて運用する仕組みです。
経営者・事業責任者が最初に作るべきものは、抽象的な倫理宣言や大規模な委員会ではありません。用途ごとに、①業務目的、②入力データ、③AIの権限、④人の確認、⑤評価指標、⑥停止・変更時の責任者を対応付けた、判断可能な運用設計です。
内閣府が整理する現行の政府資料では、総務省・経済産業省の「AI事業者ガイドライン」は、AIの開発・提供・利用を担う事業者に必要な取組の基本的な考え方を示す資料として位置付けられています。個別の業種・サービス・契約により必要な対策は変わるため、自社の用途に当てはめることが必要です。内閣府：人工知能関連技術の研究開発及び活用の適正性確保に関する指針
AIガバナンスで決めるべきこと
AIガバナンスは、モデルの性能評価だけではありません。モデル、データ、外部ツール、利用者、承認者、運用ログを含めて、業務上の責任を設計します。
論点 | 経営・事業の判断 | 現場で決める内容 |
|---|---|---|
目的 | AIで改善したい業務成果は何か | 対象工程、利用者、KPI、対象外の仕事 |
責任 | 導入・継続・停止を誰が決めるか | 業務責任者、システム責任者、承認者、問い合わせ先 |
データ | 何を外部サービスや社内AIへ渡してよいか | 個人情報、営業秘密、契約情報、公開情報の区分 |
品質 | どの誤りなら受容不能か | 評価データ、合格基準、人による確認方法、許容誤差 |
権限 | AIが提案だけするか、操作まで行うか | 閲覧、下書き、送信、更新、決済などの権限と承認 |
継続管理 | いつ再評価・停止するか | ログ、苦情、障害、モデル変更、データ更新時の再審査 |
NISTのAI RMF 1.0は、AIリスク管理をGOVERN、MAP、MEASURE、MANAGEの4機能で整理し、GOVERNを他の機能に横断的に組み込むものと説明しています。これは「評価チームだけが品質を見る」構造ではなく、経営・業務・開発・セキュリティが共通の判断材料を持つ必要があることを示す参考になります。NIST AI RMF 1.0
AIガバナンスと、AIリスク管理・社内ルールの違い
- AIガバナンス：責任、意思決定、承認、評価、監視をどう回すかという全体設計
- AIリスク管理：誤情報、漏えい、偏り、セキュリティなどのリスクを特定・評価・対処する活動
- 生成AIの社内ルール：現場が入力・出力・承認について日々判断できる具体的な利用基準
つまり、社内ルールはガバナンスを現場の行動に落とす部品であり、リスク管理はガバナンスの判断プロセスで扱う活動です。リスクの洗い出し自体はAIのリスク管理・マネジメント、利用条件の文書化は生成AIの社内ルール設計も参照してください。
最初に使う比較基準：リスクを「影響・可逆性・自律性・データ」で分ける
AIを使う業務を一律に「高リスク」「低リスク」と決めることはできません。同じ要約AIでも、社内会議メモの下書きと、顧客への契約条件の回答では失敗の影響が異なります。以下は、Mojiによる一般的な設計上の目安です。法令上の分類や認証要件を示すものではありません。
判定軸 | 確認する質問 | 高く評価する条件 |
|---|---|---|
影響 | 誤った出力・操作で、誰にどの程度の損害が出るか | 顧客、雇用、金銭、健康、安全、権利に影響する |
可逆性 | 誤りを容易に取り消し、元の状態へ戻せるか | 外部送信、公開、決済、権限変更、削除を伴う |
自律性 | AIが提案だけでなく外部システムを操作するか | メール送信、DB更新、発注、返金、設定変更を行う |
データ | 入力・検索・ログに何が含まれるか | 個人情報、機密情報、契約情報、認証情報を含む |
個人情報を含む入力については、サービスの利用条件や設定を確認せずに「匿名化すれば常に問題ない」とは扱えません。個人情報保護委員会は、生成AIサービスの利用に関する注意喚起を公表しています。個人情報保護法、委託・共同利用、国外移転、業界規制や契約上の義務に関わる判断は、法務・個人情報保護・情報セキュリティの担当者と確認してください。個人情報保護委員会：生成AIサービスの利用に関する注意喚起等
リスク別の委任レベル：どこまでAIに任せるか
区分 | 典型例 | AIに許容する役割 | 最低限の統制 |
|---|---|---|---|
レベル1：補助 | 公開情報の要約、社内文書の下書き | 提案・下書きのみ | 入力ルール、利用者による最終確認 |
レベル2：業務支援 | 社内RAG、問い合わせの分類、CRM更新案 | 検索、分類、更新案の作成 | 権限別検索、評価データ、差分確認、ログ |
レベル3：条件付き実行 | 定型メール送信、チケット起票、在庫照会 | 定義済み条件下の操作 | 操作範囲の制限、承認、取消手段、例外時の停止 |
レベル4：高影響の判断・実行 | 採否、与信、価格確定、決済、対外的な法的回答 | 原則として人の最終判断を支援 | 専門部門審査、厳格な検証、説明・異議申立ての設計、継続監査 |
レベルはAIの名称ではなく、業務への影響で決めます。たとえばAIエージェントが外部ツールを操作する場合は、回答品質に加え、付与する権限、承認、停止、監査ログを設計してください。具体的な設計方法はAIエージェントのガードレール設計で解説しています。
AIガバナンスを作る7ステップ
- 対象業務を一つに絞る
全社方針から始めず、「問い合わせの一次分類」「提案書の初稿」「社内規程の検索」のように、入力・出力・利用者を説明できる単位にします。 - 業務成果と利用禁止範囲を決める
時間短縮だけでなく、処理件数、誤り、差し戻し、顧客満足度など、目的に沿う指標を選びます。同時に、対象外の意思決定や入力禁止情報を明記します。 - 責任者と意思決定権を割り当てる
「AI担当」だけで完結させず、業務責任者を導入可否のオーナーにします。開発・運用・セキュリティ・法務は、それぞれの承認条件を持ちます。 - リスクを業務フロー上で洗い出す
入力、検索、モデル処理、ツール実行、出力利用、ログ保存の順に、誤り・漏えい・不正操作・偏り・説明不能を確認します。 - 評価データと合否基準を先に作る
本番データの一部または再現可能なテストケースで、正しい出力だけでなく「出してはいけない回答」「人へ引き継ぐべきケース」を用意します。 - 権限・承認・停止条件を実装する
AIが使えるデータ、実行できる操作、承認が必要な操作、失敗時の停止手順を分けます。権限は必要最小限から始めます。 - 運用後に再評価する
モデル、プロンプト、検索対象、接続先、業務手順を変えたときは、変更前と同じ評価ケースで比較します。苦情・事故・ヒヤリハットも評価セットへ戻します。
評価では、正答率だけを共通指標にしないことが重要です。モデル、入力品質、検索対象、評価データ、許容誤差、業務で許容できない失敗の種類によって結論は変わります。RAGやエージェントを含む評価の分解方法はAIの評価とは？評価指標や評価方法、RAGを対象にする場合はRAG評価データセットの作り方も確認してください。
導入可否を決める1枚の台帳テンプレート
以下はMojiによる提案です。各AIユースケースを1行ずつ登録し、導入審査・変更審査・定期見直しで同じ台帳を使います。
項目 | 記入内容 |
|---|---|
ユースケース名 | 業務名ではなく、AIが担う工程まで記載する |
業務目的・成果指標 | 改善対象、基準値、判定時期、継続・中止の条件 |
利用者・影響を受ける人 | 操作する人、出力を受ける人、不利益を受け得る人 |
入力・検索対象・保存ログ | データ分類、保管場所、外部送信の有無、保持期間 |
AIの役割・接続先 | 要約、分類、検索、提案、送信、更新など。モデル名だけでは書かない |
人の確認・承認 | 誰が、何を、いつ確認し、否決時にどう戻すか |
評価方法・合格基準 | テスト件数、失敗の定義、許容誤差、再評価トリガー |
停止・連絡手順 | 即時停止できる人、復旧条件、利用者・影響先への連絡方法 |
架空の例：「営業提案書の初稿作成」であれば、AIの役割を「過去の承認済み提案書から構成案と下書きを作る」に限定し、価格・契約条件・実績値は人が原典で確認してから提出する、と定義します。ここでは「文章が自然か」だけでなく、必須項目の欠落、根拠のない数値、顧客情報の混入を評価対象にします。
経営会議で使う導入判断チェックリスト
- 対象業務は、AIを使わない場合の現状と課題を説明できるか
- 業務責任者は、導入・拡大・停止の意思決定者として明確か
- AIが参照・入力・保存するデータを一覧化したか
- 顧客、従業員、取引先に影響する誤りを具体的に列挙したか
- AIが外部へ送信・更新・購入・公開できる範囲を制限したか
- 人が確認する工程と、確認者が見るべき根拠を決めたか
- 通常ケースだけでなく、失敗・例外・悪意ある入力を含む評価をしたか
- 品質、コスト、待ち時間、安全性を分けて測っているか
- モデル、接続先、データ、プロンプトを変えた際の再評価条件があるか
- 停止権限、事故時の連絡先、ログの確認担当が決まっているか
よくある失敗：ルールと現場運用を分けてしまう
「機密情報を入力しない」「必ず人が確認する」といった方針だけでは、担当者が実際の業務で判断できないことがあります。何が機密情報に当たるのか、どの契約済み環境を使えるのか、誰がどの画面で確認するのか、確認できなかったときにどこへ戻すのかまで決めて初めて運用できます。
また、AIの出力に根拠が付いていても、その根拠が最新か、閲覧権限に合うか、質問への答えを本当に裏付けるかは別問題です。社内文書を扱う場合は、回答を隠す後処理ではなく、検索時点で権限を反映する設計が必要です。社内RAGの権限管理もあわせて確認してください。
まとめ：AIガバナンスは「慎重になる仕組み」ではなく「任せ方を決める仕組み」
AIガバナンスの目的は、AI利用を一律に制限することではありません。低リスクで可逆的な仕事は速く試し、高影響・不可逆・自律的な仕事ほど、データ、評価、承認、権限、停止を厚くすることです。
OECDのAI原則は、透明性、堅牢性・安全性、説明責任などをAIライフサイクル全体で扱う考え方を示しています。自社のAIガバナンスでも、「誰が責任を負うか」だけでなく、後から根拠・変更・判断経路を追える状態を作ることが重要です。OECD AI Principles
最初の一歩としては、全社横断の制度を完成させようとせず、1つのユースケースを選び、本記事の台帳を埋め、限定運用と評価を始めてください。その結果をもとに、許可範囲と統制を更新する方法が、実務上は再現しやすい進め方です。