AI開発のセキュリティとデータガバナンス｜実務チェックリスト

社内FAQボットとRAG検索をPoCから本番に上げる場面で、精度より先に承認が止まったことがあります。
原因はモデルそのものではなく、どの文書を入れてよいのか、誰がどこまで見えてよいのかというデータ分類とアクセス権の未定義でした。
この手の詰まり方は珍しくなく、AI開発を前に進める近道はAIセキュリティと『データガバナンス』を同じ箱に押し込めることではなく、役割と責任を分けたうえで統合管理することです。
本記事は、セキュリティ、データ、事業、法務の境界を整理し、Evaluate／Direct／Monitorの体制原則を先に置きます。
NIST AI Risk Management Frameworkと2024年7月26日公開の生成AIプロファイル、国内ガイドラインの位置づけを実務目線でつなぎます。
PoCで今すぐ回せる10項目、本番化で抜け漏れを防ぐ15項目のチェックリストまで落とし込み、AI導入が「作れるのに通せない」で止まる状態を抜ける道筋を示します。

AI開発でセキュリティとデータガバナンスが同時に必要な理由

用語の定義とスコープの切り分け

AI開発の議論が噛み合わなくなる典型例は、同じ「ガバナンス」という言葉で別の対象を話していることです。
現場では、セキュリティ部門は「攻撃に耐えられるか」を気にし、データ部門は「どのデータを誰が使ってよいか」を見ています。
法務や経営は、そこに説明責任や規制適合まで重ねて判断します。
この3つを混同すると、レビュー会議で論点が拡散し、承認が止まります。

私自身、部門横断の説明でこの混線に何度もぶつかりました。
特にRAGや社内向けFAQボットの企画では、AIセキュリティの話をしているつもりが、途中からデータ持ち込み基準や利用目的の妥当性の話に切り替わり、誰が何を決める会議なのかが曖昧になったことがあります。
その後は最初に「用語定義スライド1枚」を配る形に変えました。
AIセキュリティ、データガバナンス、AIガバナンスの境界を先に固定すると、情報システム、法務、事業部門の合意形成が目に見えて早まりました。

AIセキュリティは、AIシステムに固有の脅威に対する実装と運用を指します。
従来の認証、暗号化、監視に加えて、プロンプトインジェクション、モデル抽出、敵対的入力、学習データや推論時コンテキストの汚染といった論点を扱います。
MicrosoftやTrend Microが整理するように、これは「AIを使って守る」話ではなく、「AIそのものを守る」話です。

一方のデータガバナンスは、データの品質、所有、利用ルール、責任分担を定める全社的な枠組みです。
どのデータを収集し、どこに保存し、誰が利用し、いつ削除するのかを決める領域で、技術対策だけでは完結しません。
対象は個別のAIモデルより広く、企業のデータ資産全体です。
AI導入で承認が止まりやすいのも、モデル精度そのものより、出所不明データや権限未整理の文書を投入していないかという管理側の懸念が先に立つからです。

そしてAIガバナンスは、その上位概念です。
セキュリティ、法務、倫理、品質、説明責任を統合し、AIをどう設計し、どう使い、どこまで許容するかを組織として決める枠組みです。
NISTのAIリスク管理フレームワークは、まさにこの全体設計の共通言語として使われていますし、2024年7月26日公開の生成AIプロファイルは、生成AI特有の論点を補う位置づけです。
AIセキュリティとデータガバナンスは、AIガバナンスの配下で連携して機能する関係だと捉えると整理しやすくなります。

データ ガバナンスとは ｜ Google Cloud

データ ガバナンスは、データの安全性、正確性、可用性を確保するための取り組みです。このプロセスでデータの品質と管理をどのように改善できるかをご覧ください。

cloud.google.com

AI特有の攻撃面と従来統制のギャップ

従来のIT統制だけでは足りない理由は、AIアプリケーションの攻撃面が入力から推論基盤、外部連携まで連続して広がっているからです。
『LLM』アプリでは、まず入力が攻撃面になります。
ユーザーが打ち込むプロンプトだけでなく、アップロードされたPDF、CSV、画像、音声、Webページ断片も含まれます。
ここで起きるのが、プロンプトインジェクションやコンテキスト汚染です。
通常のWeb入力検証はSQLインジェクションやXSSには有効でも、「前の指示を無視して機密を出力せよ」のような自然言語ベースの誘導には、そのままでは対応しきれません。

なお、OWASP のガイドは公開・更新が頻繁な「living document」です。
攻撃面はそれだけではありません。
APIと依存パッケージも欠かせません。
外部モデルAPI、埋め込みAPI、ベクトルDBクライアント、オーケストレーションフレームワーク、プラグインのどれかが侵害されれば、アプリ全体に影響が及びます。
加えて、推論基盤ではログ出力やキャッシュ、GPUノード上の一時ファイル、監視基盤への転送データが機密の抜け道になります。
サプライチェーンまで含めると、モデル提供元、データセット、コンテナイメージ、CI/CD、評価用ツール群も対象です。
従来のクラウド設定レビューだけで安心できないのは、AIシステムが複数レイヤーの連鎖で成立しているためです。

3概念（AIセキュリティ/データガバナンス/AIガバナンス）の比較

3つの概念は重なり合いますが、目的も責任主体も異なります。
会議でこの違いが1画面で見えるだけで、レビュー観点の混線が減ります。
私が資料の冒頭に比較表を置くようになったのもそのためで、セキュリティレビューの席でデータオーナー不在が発覚したり、逆にデータ会議でモデル脅威が誰の担当でもなくなったりする事態を減らせました。

この表で見えてくるのは、AIセキュリティとデータガバナンスが横並びの別物でありながら、どちらもAIガバナンスの実効性を支える基盤だということです。
たとえばDSPMのような分散データの発見・分類・曝露可視化は、データガバナンスの文脈で語られますが、実際にはRAGやエージェントの情報漏えいリスクを下げるための前提条件にもなります。
逆に、AIレッドチーミングやプロンプト耐性テストはAIセキュリティの施策ですが、どのデータを投入し、どの業務に使うかというAIガバナンス上の判断抜きでは優先順位を付けられません。

フレームワークも役割で見た方が腹落ちします。
NIST AI RMFは共通言語として導入しやすく、全体設計の起点になり、『ISO/IEC 42001』は2023年12月18日に発行されたAIマネジメントシステム規格で監査や説明責任に踏み込みたい組織と相性があり、日本企業の部門調整では、2024年4月19日初版公表、2025年3月28日に第1.1版が出ているAI事業者ガイドラインや、2025年6月20日公開の『データガバナンス・ガイドライン 2025』が実務に落とし込みやすい立ち位置です。

AI Exchange

Comprehensive guidance and alignment on how to protect AI against security threats - by professionals, for professionals

owaspai.org

まず押さえるべきAI開発の主要リスク

このセクションでは、AI開発で何を守るのかを先に固定しておきます。
対象はモデルそのものだけではありません。
入力されたプロンプト、RAGが引く文書、ベクトルDB、推論API、ログ、外部ツール権限、運用基盤まで含めて保護対象です。
ここが曖昧なままPoCを進めると、「社内文書が出た」「API費用が跳ねた」「外部連携が勝手に走った」といった事象を個別事故として処理することになり、全体像が見えなくなります。
実際に設計レビューをしていると、通常のWebアプリで慣れている脅威モデルだけでは足りない場面がよく出ます。
AIアプリでは、自然言語そのものが攻撃経路になり、検索結果の混入やエージェントの自律実行が被害の広がり方を変えるからです。
AIのリスクは設計、開発、利用、評価まで通して扱う前提で整理するほうが運用に乗ります。

リスク一覧と対策のひな型

まず押さえたいのは、リスクを単なる用語集で終わらせず、「どう起きるか」「どう見つけるか」「どう抑えるか」「それでも何が残るか」の4点セットで揃えることです。
会議でもこの形にしておくと、情シス、開発、法務、事業部で話が噛み合いやすくなります。
『OWASP AI Security and Privacy Guide』でも、AI固有の脅威を通常のセキュリティ管理に接続してテストする考え方が重視されています。

下の表は、最低限カバーしたい8項目を実務向けに圧縮したひな型です。

この表を使うときのポイントは、リスクの数を増やすことではなく、優先度付けの軸を揃えることです。
現場では 資産価値 × 露出度 × 悪用容易性 でまず並べ、そのうえで「運用で見つけられるか」を重ねると整理しやすくなります。
たとえば、社外公開のFAQボットは露出度が高く、RAGの権限ミスは悪用しやすいので短期で塞ぐ対象になります。
逆に、モデル蒸留のような問題は深刻でも検知が難しく、中期から長期で継続監視に回す設計が現実的です。

運用計画に落とすなら、短期はプロンプトインジェクション、データ漏えい、API脆弱性、無制限なリソース消費の封じ込めに寄せる形になります。
中期ではデータポイズニング、モデル盗難、シャドーAIの統制を整え、長期では敵対的攻撃やエージェントの複合リスクに対して評価基盤を育てる流れが収まりやすいのが利点です。
実際にチームで回してみると、短期に「見える事故」を抑えたあとでないと、長期の安全性投資に合意が集まりません。

RAG/ベクトルDBで起きる典型的な漏えい

RAGでは、モデル本体よりも「何を検索させるか」「検索結果を誰に返すか」の設計が漏えいの分かれ目になります。
典型例は、索引スコアだけで上位文書を返し、閲覧権限や機密区分を後段で見ていないケースです。
これだと、検索としては正解でも、業務上は見せてはいけない文書がそのまま生成文に混ざります。

筆者が社外向けFAQを試作したときも、この問題は実データで再現しました。
検索精度を優先してベクトル類似度の高い文書をそのまま使っていたところ、社外公開用の質問に対して、社内手順書の断片が回答候補に混ざったんですよね。
原因は単純で、文書メタデータに「公開範囲」「部署」「機密区分」を持たせていても、検索時にその条件を効かせていなかったことでした。
ここをメタデータベースと連携したABACに変え、利用者属性と文書属性の両方でフィルタしたところ、検索精度を保ったまま混入が止まりました。

RAGで起きる漏えいは、主に4つの場所に現れます。
1つ目は入力時で、機密文書をそのまま埋め込み対象にしてしまうケースです。
2つ目は検索時で、ベクトルDBが権限外のチャンクを返すケースです。
3つ目は生成時で、複数文書を要約した結果として非公開情報が表面化するケースです。
4つ目はログ時で、クエリ、ヒット文書、生成結果が監査ログや分析基盤に平文保存されるケースです。
RAGは便利ですが、漏えい箇所が1段ではなく4段に増えると見ると把握しやすくなります。

対策の軸になるのが、メタデータフィルタ、ABAC、出所ラベル付与の3つです。
メタデータフィルタは、文書に付けた属性で検索対象を絞る仕組みです。
ABACは、ユーザ属性、文書属性、操作内容、環境条件を組み合わせてアクセス可否を決める考え方で、部署、雇用区分、案件参加状況、時間帯まで評価に入れられます。
RBACだけでも役割ベースの制御はできますが、RAGでは「営業部の部長なら見られる」より「この案件に参加中で、社外公開用途ではない」まで切りたい場面が多く、ABACのほうが噛み合います。
『データガバナンス・ガイドライン 2025』が強調する出所管理やライフサイクル管理とも相性が良い考え方です（出典：データガバナンス・ガイドライン 2025）。

出所ラベル付与も地味ですが効きます。
回答文のどの部分がどの文書に基づくか、少なくとも文書群レベルで利用者に見せるだけで、誤引用や権限ミスに気づける頻度が上がります。
実際に使ってみると、生成品質の説明にも役立ちますし、事故調査のときに「どのチャンクが混ざったのか」を追えるため、修正範囲を絞れます。
RAGの安全性は、モデルの賢さより、検索前後でどれだけ属性を丁寧に扱えるかで決まる場面が多いです。

デジタル庁

デジタル庁は、デジタル社会形成の司令塔として、未来志向のDX（デジタル・トランスフォーメーション）を大胆に推進し、デジタル時代の官民のインフラを一気呵成に作り上げることを目指します。

www.digital.go.jp

AIエージェント時代の追加リスク

AIエージェントでは、回答生成だけで終わらず、外部ツールを呼び、状態を持ち、連鎖タスクを進めるため、リスクが一段増えます。
単発のチャットなら危険な出力で止まる問題が、エージェントでは「危険な出力がそのまま実行される」問題に変わります。
ここで注目したいのは、外部ツール権限の逸脱、連鎖タスク暴走、サプライチェーン依存です。

外部ツール権限の逸脱は、エージェントが本来不要な権限でSlack投稿、GitHub更新、Jira起票、Notion参照、Google Drive取得などを実行してしまう状態です。
たとえば、読み取りだけで十分な業務フローに書き込み権限付きトークンを渡していると、誤操作でも改変事故になります。
プロンプトインジェクションと組み合わさると、「文書を読んで要約するだけ」のつもりだったエージェントが、外部送信や設定変更まで進むことがあります。
対策は最小権限、ツールごとのスコープ分離、破壊的操作の人手承認、実行前プレビューの4点が基本です。

連鎖タスク暴走は、目標達成のためにエージェントが再計画を繰り返し、API呼び出しやツール実行が膨らみ続けるパターンです。
これが起きると、コストだけでなく、外部更新回数や監査ログ量も跳ね上がります。
単純なDoSというより、業務フローに似た見た目で暴走するのが厄介です。
実運用では、1タスクあたりの最大ステップ数、最大トークン数、ツール呼び出し回数、外部送信回数を個別に止める設計にしておくと、異常系が見えやすくなります。

サプライチェーン依存も見逃せません。
エージェントは外部LLM API、プラグイン、SDK、MCPサーバー、学習済みモデル、評価ツールなど依存先が多く、1つの改ざんや設定ミスが広い範囲に効きます。
典型例は、プラグインの改ざん、環境変数からのAPIキー漏えい、依存ライブラリ更新による権限拡大です。
従来のSaaS連携より影響が大きいのは、エージェントがその依存先を使って次の行動を決めるからです。
1つの漏えいが次の実行判断に連鎖しやすい構造になっています。

エージェント時代の脅威モデルでは、「何を答えるか」だけでなく「何を実行できるか」「どこまで連鎖できるか」「どの依存先が壊れると止まるか」を一緒に見ます。
2025年から2026年にかけて、AI利用攻撃やAI compromiseの報告が増えている背景にも、この連鎖性があります。
単体機能として安全でも、複数の権限と外部接続を束ねた瞬間に別の攻撃面が生まれるわけです。

この段階になると、優先順位の置き方も変わります。
短期では、外部ツールの権限棚卸しと破壊的操作の承認フローを整えることが先です。
中期では、サプライチェーン監視とシークレット管理、実行ログの相関監視を足します。
長期では、エージェントの評価環境を作り、危険な連鎖行動をテストケースとして継続的に回す形になります。
実際にエージェントを組んでみると、モデルの精度改善より先に、権限と停止条件の設計がボトルネックになります。
ここを飛ばすと、便利な自動化がそのまま新しい攻撃面になります。

AI開発ライフサイクル別の実務対策

企画・リスク評価・同意形成

AI案件は、実装に入る前の整理で成否がほぼ決まります。
ここで見るべきなのは「作れるか」より先に、「そのユースケースが法的に適合するか」「どのデータを使うのか」「本人情報や機密情報を含むのか」「利用規約やDPAで許容されるのか」です。
社内FAQボット、営業支援の要約、契約レビュー補助、顧客向けチャットのように見た目が似た案件でも、扱うデータと判断の重さで必要な統制は変わります。
たとえば契約条文の解釈や顧客への提示文を生成する用途は、単なる要約支援より承認設計を厳しく置くべきです。

企画段階では、NIST AI Risk Management Frameworkを共通言語にすると、法務、情報セキュリティ、プロダクト、業務部門の話が噛み合いやすくなります。
NISTの枠組みは、リスクを「ある・ない」で止めず、用途、影響、関係者、管理策、残余リスクまで文書化していく考え方なので、PoCの段階でも十分使えます。
NISTは2024年7月に生成AI向けプロファイルも公開しており、企画書が抽象論のまま進むのを防ぐ土台として扱えます。

実務では、企画審査票を1枚にまとめると止まりにくくなります。項目は多く見えても、最低限は次の粒度で足ります。

この文書が効くのは、承認の論点を前倒しで表に出せるからです。
実際、評価指標を決めないままPoCを走らせた案件では、デモのたびに見る人が違う基準で良し悪しを語り、「成功」と「失敗」の合意が取れずに長引きました。
出力の評価観点と、どの条件で人手レビューに回すかを先に決めてからは、承認会議が感想戦にならず、判断が一気に進みました。
企画段階での同意形成は、技術選定より先にやっておくべき作業です。

AI Risk Management Framework

www.nist.gov

データ分類とアクセス制御

AI開発では、データをひとまとめに「入力データ」と呼ぶと設計が粗くなります。
少なくとも、学習データ、推論時の入力データ、RAGで参照するデータは分けて扱う必要があります。
学習に使ってよいデータと、質問文として一時利用するだけのデータと、検索参照だけ許されるデータでは、保持、再利用、ログ保存、第三者提供の条件が違うからです。

分類の軸は、機密区分と取り扱いレベルです。
たとえば「公開」「社内限定」「部門限定」「顧客限定」「契約限定」のように分け、個人情報、営業秘密、法務文書、医療・人事などの高感度情報は別タグで重ねます。
ここで効いてくるのがRAGメタデータ設計で、文書チャンクごとに部門、顧客、契約、地域、保持期限、情報オーナー、機密区分を持たせると、検索の前後でフィルタを掛けられます。
前のセクションで触れた通り、RAGの安全性はモデル単体ではなく、この属性設計で決まる場面が多くあります。

アクセス制御は、RBACを土台にしつつ、細かい条件はABACで絞る構成が実務的です。
RBACは「法務担当」「営業マネージャー」のような役割管理に向いていますが、RAGでは「この案件に参加中か」「この顧客を担当しているか」「EU関連案件か」「社外端末からのアクセスか」まで見たいことが多く、ABACのほうが表現力があり、検索時点で返さない設計のほうが事故面を減らせます。

RAGでの典型的な属性は、subject側に「所属部門」「職位」「担当顧客」「データアクセスレベル」、resource側に「文書オーナー」「顧客ID」「契約ID」「地域」「機密フラグ」、environment側に「接続元ネットワーク」「時間帯」「利用チャネル」を置く形です。
この組み合わせなら、営業部でも担当外顧客の契約書は返さない、EU案件は指定地域の保管文書だけ参照する、社外接続では機密区分の高い文書を検索対象から外す、といった制御ができます。

監査ログもこの段階で設計しておくと後工程が安定します。
最低限、誰が、いつ、どのモデルに、どのアプリ経由で、どの権限でアクセスし、どの文書群が参照され、出力にどの出所が使われたかは残したいところです。
ログは単なる保管ではなく、後で調査できる粒度が必要で、権限エラー、フィルタ除外、マスキング適用、例外承認の有無まで取れていないと、事故時に「なぜ出たのか」が追えません。
『データガバナンス・ガイドライン 2025』が出所管理やライフサイクル管理を強調しているのも、こうした追跡性がないと統制が機能しないからです。

評価・テスト・HITLの設計

AIアプリの評価は、精度だけを見ても足りません。
業務で問題になるのは、正答率よりも「危険な誤答をどこで止めるか」「漏らしてはいけないものを出していないか」「攻撃にどこまで耐えるか」です。
したがって、モデル評価、プロンプト評価、RAG評価、セーフティ評価、HITL設計を別々に持つ必要があります。

テストで外せないのが、プロンプトインジェクション耐性です。
Web取得文書、PDF添付、メール転記、チケット本文など、外部または半外部のテキストに「前の指示を無視せよ」「秘密情報を出せ」と埋め込んだケースを用意し、参照だけして無害化できるか、ツール実行に進まないか、システムプロンプトや接続情報が漏れないかを見ます。
『OWASP』のLLM向け脅威整理でも、機密情報漏えい、プロンプト漏えい、誤情報、インジェクションは代表的な論点です。
机上のルールより、具体的な悪性入力で回帰テストに組み込んだほうが運用に乗ります。

回帰テストの対象はモデル更新だけではありません。
システムプロンプト、ガードレール、検索クエリ生成、ランキング、ツール接続先が変わるたびに、以前の安全性が崩れていないかを確認する必要があります。
生成AIでは、モデルを替えていないのに出力傾向が変わることが珍しくありません。
なので、正答データセットに加えて、禁止回答、要承認ケース、権限外参照、出所欠落、長文暴走のような失敗系セットを持っておくと、変更の影響が見えます。

HITLは「人がたまに見る」ではなく、閾値で機械的に発火させる設計が必要です。
たとえば、法的判断を含む、顧客への送信文になる、経済的損失につながる、権限のない文書を参照した疑いがある、出所が不足している、セーフティ判定で境界域に入った、といった条件では自動承認にせず人手レビューへ送ります。
ここで大事なのは、レビューに回す条件を事前に合意しておくことです。
PoCの現場では、デモ時点では盛り上がっても、本番承認の場で「この回答は誰が責任を持つのか」が曖昧になって止まりがちです。
出力評価基準とHITL閾値を先に置くと、責任境界が明確になり、承認フローが流れます（運用上の一般的な指針として設計することを推奨します）。

評価指標も、ユースケースに合わせて分解したほうが実務に合います。
たとえば、脱漏は「必要な出所を拾えているか」、幻覚は「出所なし断定がないか」、セーフティは「禁止領域の応答を抑止できているか」、業務適合は「人手修正なしで使えるか」など、別軸で見ます。
ひとつの総合点にすると、危険な欠陥が平均化されて埋もれます。
社内FAQなら引用根拠の一致率、契約レビュー補助なら論点の取りこぼし、顧客対応案なら禁止表現や誤案内の混入率のほうが、現場の意思決定には直結します。

評価セットは「正解を当てる問題」だけでなく、「答えないほうが正しい問題」「人手承認に回すべき問題」を同じくらい入れておくと、実運用での事故面が見えます。

運用監視・鍵管理・インシデント対応

本番運用では、ログと監視がないAIは調査不能なシステムになります。
監査ログの粒度として残したいのは、入力、出力、参照文書ID、ツール実行、外部送信、権限変更、承認操作、モデル変更、プロンプト変更です。
チャット本文をそのまま平文保存するかどうかとは別に、少なくともイベントとしての事実関係は追える必要があります。
出力だけ残って入力や参照元がない、ツール実行は見えるが誰の代理実行か分からない、という状態では原因分析ができません。

鍵管理と接続制御も運用の中心です。
APIキーはアプリ単位、環境単位、接続先単位で分け、読み取り専用と書き込み可能を混在させない構成にします。
キーのスコープ最小化、定期ローテーション、失効手順の明文化は基本ですが、AIではさらにegress制御が効きます。
どのアプリがどのLLM API、ベクトルDB、SaaS、Webhook先へ通信できるかを制限しておくと、侵害時の拡散範囲を狭められます。
レートリミットもコスト管理だけでなく、モデル抽出や連鎖暴走の抑制策として機能します。

モデルとプロンプトの変更管理は、通常のアプリ設定変更より厳格に扱うべき領域です。
モデル名の切替、プロンプトテンプレート修正、ガードレールルール変更、検索対象コーパス追加は、どれも出力の意味を変えます。
変更チケット、レビュー記録、評価結果、ロールバック条件を結びつけておかないと、問題が起きた時に「いつから壊れたか」が分かりません。
監査ログに変更イベントを残す理由はここにあります。

インシデント対応では、封じ込め、報告、再発防止をAI向けに具体化しておく必要があります。
たとえば機密情報漏えいの疑いが出た場合は、該当アプリの外部送信停止、対象キー失効、検索インデックス更新停止、影響範囲のログ調査、利用者通知の要否判断、再発防止としてのルール変更と評価ケース追加までを一連で動かします。
通常のWeb障害対応と違い、AIでは「誤った出力がどこまで二次利用されたか」も追う必要があるため、出力の保存先や転送先の把握まで含めて設計しておく必要があります。

HITLと人手レビューは運用段階でも残ります。
法的判断、顧客影響の大きい回答、金額提示、契約変更、アカウント停止、信用評価のような高リスク判断には承認ゲートを置き、例外的に自動処理したケースは台帳化しておくと、後から基準の妥当性を見直せます。
自動化率を上げること自体が目的になると、ここが削られがちですが、実務では承認ゲートの置き方で事故の質が変わります。
人手レビューはAIを信用していないから挟むのではなく、責任の所在を途切れさせないために挟みます。

データガバナンス実務: 収集・分類・権限・保管・削除の設計

出所管理と機密性分類

データガバナンスを実務に落とすとき、最初に詰めるべきは「そのデータを、そもそも何者として扱うのか」です。
AI開発では、社内文書、顧客提供データ、SaaS上の業務記録、公開Web情報、購入データセット、委託先から受領したファイルが同じパイプラインに流れ込みます。
ここを一括で「学習用データ」「RAG用データ」とだけ呼んで進めると、あとで利用可否の判定ができなくなります。

そのため、出所管理、つまりデータプロベナンスの台帳を先に持つのが実務上の起点になります。
台帳には、取得元、取得日時、取得手段、同意の有無、契約条件、ライセンス、再利用可否、第三者提供可否、AI利用可否、学習利用可否を紐づけます。
たとえばSalesforceから連携した顧客対応履歴と、Google Driveに置かれた社内手順書では、見た目はどちらもテキストですが、利用根拠も再配布条件も違います。
公開資料でも、閲覧は可能でも学習投入や再配布が許されていないケースがあります。
ここを文書単位、テーブル単位、少なくともデータソース単位で記録しておかないと、後段の権限設計や削除対応が宙に浮きます。

機密性分類も、従来の情報区分だけでは足りません。
公開、社外秘、社内限定、特機密、個人データ、機微情報のような分類に加えて、AIに使ってよいか、学習に使ってよいかの軸を分けて持つ必要があります。
実務では二軸のマトリクスにすると運用が安定します。
たとえば「社内限定だがAI参照は可、学習は不可」「個人データでAI参照は条件付き可、学習は不可」「公開情報で参照も学習も可」といった形です。
機密性と利用可否を同じラベルに押し込むと、例外処理が増え、現場で判断不能になります。

私自身、PoCではきれいに動いていた社内FAQボットが、本番承認の会議で止まったことがあります。
技術的な精度より前に、「この文書群は何分類なのか」「誰が利用可否を決めるのか」が未整備だったのが止まった理由でした。
そのとき効いたのは、新しい仕組みを足すことではなく、既存のガバナンスポリシーにAI利用可否フラグを追加し、責任者欄を必須化したことです。
分類と責任者が見えるだけで、法務、情報システム、業務部門の会話が前に進みました。
本番で承認が下りない案件は、モデルの性能不足より、この手の台帳不足で止まることが多いです。

日本語での整理には、デジタル庁の『データガバナンス・ガイドライン 2025』が役立ちます。
経営資源としてのデータをどう統制するかという観点で、AI利用の文脈でも、出所管理、分類、リネージュ、ライフサイクルのつながりを実務レベルで捉えやすい構成です。

アクセス権限とライフサイクル設計

分類しただけでは統制になりません。
次に必要なのは、収集から削除までの各段階に、誰が責任を持ち、どの手続で扱い、どこまでの時間で処理するかを決めることです。
データのライフサイクルは、収集、加工、配布、利用、保存、アーカイブ、削除の流れで捉えると整理しやすく、AI案件ではこの全段階に責任者を置くべきです。

ここで役割を分けると運用が安定します。
データオーナーは利用目的と許容リスクを決め、承認責任を持つ立場です。
データスチュワードは分類ルール、品質、メタデータ整備、変更管理を担い、現場運用の基準を守らせます。
カストディアンはストレージ、バックアップ、アクセス制御、ログ保全など技術的保管責任を担います。
承認、変更、監査のどこを誰が持つかを分けておかないと、申請は通っても監査証跡が残らない、あるいは削除期限が来ても誰も消せない状態になります。

アクセス制御は、共有フォルダの閲覧権限だけを見ていると不十分です。
AIシステムでは、元データ、加工データ、特徴量、ベクトル化後の埋め込み、検索インデックス、生成ログ、評価データが別々に存在します。
元文書は見えなくても、ベクトルDBからの検索結果で内容が再構成されるケースがあるため、元ソースと派生データの両方に権限制御が必要です。
部門単位のRBACで大枠を切り、案件、データ分類、利用目的、勤務場所、時間帯のような属性条件をABACで足す構成は、RAGの実運用と相性がよいです（実務でよく採用される構成です）。
たとえば「人事部所属でも、採用案件担当者だけが候補者データを参照できる」「社内限定でも、特機密は承認済みセッションからしか検索できない」といった制御は、役割だけでは表現しきれません。

ライフサイクル設計では、各段階にSLAを置くと曖昧さが減ります。
収集時は取得根拠の確認期限、加工時は匿名化やマスキングの完了条件、配布時は権限反映の反映時間、保存時は保持期間、アーカイブ時は復元手順、削除時は削除証跡の残し方まで定義します。
AI案件で見落とされやすいのは、削除が元データだけで終わらないことです。
再学習データ、キャッシュ、評価セット、ログ、ベクトルDB、派生サマリにも削除要件が波及します。
本人削除請求や契約終了時に慌てる案件は、この波及先が設計されていません。

データリネージュとDSPMの活用

AIでトラブルが起きたとき、「どのデータから、この出力に至ったのか」を追えない状態がいちばん厄介です。
そこで必要になるのがデータリネージュです。
最低限でも、収集元、変換処理、特徴量化またはベクトル化、学習もしくは参照、出力までの系統を可視化しておくべきです。
RAGなら、どのソースから取り込み、どの前処理で分割し、どの埋め込みモデルでベクトル化し、どのインデックスに入り、どの検索条件で参照され、どの回答に引用されたか、ここまで追えるだけで事故調査の難易度が変わります。

リネージュは、精緻な全自動マッピングから始める必要はありません。
実務ではまず、データソース単位、主要変換単位、配布先単位の粒度で線を引き、どこで機密度が変わるか、どこで責任者が変わるかを見える化するだけでも効果があります。
PoC段階では「動くかどうか」だけに目が向きますが、本番では「何を入れたら、何が出るのか」が説明できなければ承認されません。
リネージュは説明責任のための図であると同時に、削除、訂正、事故対応の作業地図でもあります。

この可視化を継続運用に載せるうえで、DSPMの位置づけも明確です。
DSPMは機密データの発見、分類、曝露監視を自動化するための仕組みで、SaaS、クラウドストレージ、ノートブック環境、データレイク、ベクトルDBを横断して、どこに何のデータがあり、どこが過剰公開されているかを見ます。
AI案件では、ConfluenceやSharePoint上の文書だけでなく、Snowflakeのテーブル、Jupyterノートブックの一時ファイル、ベクトルDBのメタデータまで視野に入れないと、見えているつもりで見えていない領域が残ります。

DSPMは分類の代替ではありません。
分類ルールとデータオーナー、データスチュワードの定義があって、その上で自動発見と曝露監視を回す位置づけです。
たとえば、個人データや特機密に相当する内容を自動検知し、公開設定の誤りや共有範囲の逸脱をアラートに載せる、といった使い方になります。
これがあると、台帳に載っていない新規データ、想定外の保存先、権限ミスで露出した派生データを早い段階で拾えます。
RAGやエージェントの構成が増えるほど、手作業の棚卸しだけでは追い切れません。

実務では、DSPMで見つけた機密データをそのまま是正するのではなく、リネージュと突き合わせて「なぜそこにあるのか」を確認する流れが合います。
正当な中間成果物なのか、削除漏れなのか、権限継承ミスなのかで対応が変わるからです。
監視、分類、責任者、リネージュが一体で回る状態まで持っていけると、AI向けのデータ管理はようやく本番運用の土台になります。
加えて、リスク管理はモデル単体ではなく、データと運用を含む全体で捉える前提になっています。
データリネージュとDSPMは、その前提を現場の台帳と監視に落とし込む役割を担います。

組織体制の作り方: 誰が責任を持つか

経営直下の推進体制とEDM

ルールを作っても回らない組織には、たいてい「決める場」と「責任を持つ人」が抜けています。
AIガバナンスを機能させるには、事業部門の善意や各部の個別判断に任せるのではなく、経営直下に推進組織を置く構成が先です。
名称はAIガバナンス委員会でもAI PMOでも構いませんが、実務ではこの組織が案件の優先順位、許容リスク、例外承認、監査方針を持ち、各部門の判断基準をそろえる役目を担います。
考え方に沿うなら、ここで押さえるべき軸は Evaluate / Direct / Monitor です。
評価する役割、方針を出す役割、運用を監視する役割を分けると、会議体が「相談窓口」ではなく統治の装置として動きます。

この3つを一つの会議で全部やろうとすると、議論が散ります。
そこで、Evaluate は案件のリスク評価とユースケース審査、Direct は利用基準やデータ分類方針の決定、Monitor は監査ログ、例外承認、インシデント、KPIの定点観測という具合に役割を切り分けると運用が締まります。
たとえばAzure OpenAI Serviceを使った社内FAQボットと、GitHub Copilotのような開発支援ツールでは、同じ生成AIでも論点が違います。
前者はRAG対象文書の権限と引用元の説明責任が中心になり、後者はコード流出、ライセンス、開発端末での利用統制が前面に出ます。
これを案件ごとに毎回ゼロから整理すると、承認が止まりやすくなります。

実際、以前の現場では責任者が曖昧なままPoCを立ち上げ、事業部門は「法務判断待ち」、法務は「セキュリティ確認待ち」、情報システムは「事業側の責任範囲が不明」という状態になり、意思決定が止まったことがありました。
その経験から、案件を起こす前にまず RACI表を1枚で合意する 運用へ切り替えました。
誰が責任を持ち、誰が説明し、誰が協力し、誰に報告するかを先に固定すると、承認フローの往復が減り、会議も「誰が持ち帰るか」で止まらなくなります。
AI案件は技術の難しさより、責任の空白で失速することのほうが多いと感じます。

部門横断の役割分担

体制図だけでは運用に落ちません。
実務では、事業部門、法務、情報セキュリティ、品質管理、情シスがそれぞれ何を持つかを、案件単位で明文化しておく必要があります。
最低限のRACIは次の形にしておくと、レビューの抜け漏れが減ります。

ここでのポイントは、事業部門を「利用者」にせず、業務上の責任主体として置くことです。
AIを導入して価値を出すのは事業側であり、法務やセキュリティは承認機関ではあってもオーナーではありません。
法務は利用規約、委託契約、個人情報、越境移転、説明責任の観点を持ち、情報セキュリティはアクセス制御、ログ、外部接続、脅威、インシデント対応を持ちます。
品質管理は評価データ、期待精度、誤答時の影響、HITLの条件を持ち、情シスはID連携、監査ログ保全、ネットワーク、運用基盤を受け持つ、という分担です。

案件を前に進めるには、各プロジェクトで少なくとも3人を明示しておくと止まりにくくなります。
ひとりは責任者で、通常は事業部門の管理職かプロダクトオーナーです。
ひとりは法務確認者で、個人データ、契約条件、対外提供の有無に関わる論点を閉じます。
もうひとりはセキュリティ確認者で、接続方式、ログ、認証、データ保管先、外部API利用の妥当性を見ます。
たとえば社内文書だけを参照するRAGなら、責任者は利用部門、法務確認者は個人情報や著作物を含む文書の扱いを確認し、セキュリティ確認者はSharePointやConfluenceからの取り込み経路、ベクトルDB、権限継承、監査ログを確認する流れです。
顧客向けチャットボットなら、品質管理の関与を一段強くし、誤案内時のエスカレーション条件まで先に決めておく必要があります。

承認フローも、段階を絞ったほうが回ります。
現場では「企画審査」「設計審査」「本番前審査」の三段階程度に分け、企画審査でユースケースとデータ種別、設計審査で接続構成と制御策、本番前審査で評価結果と運用台帳を確認する形が扱いやすいのが利点です。
例外が必要な案件では、委員会またはPMOが期限付きで承認し、例外理由、補完策、見直し日を台帳に残します。
例外承認が口頭運用だと、後から「なぜ通したのか」を説明できません。
期限と条件を明文化した例外管理は、柔軟さを保ちながら統制も崩さないための要所です。

教育・研修とKPIの設計

体制を作っても、利用者と開発者が同じ研修を受けているだけでは運用は定着しません。
利用者向け教育では、何を入力してよいか、どのデータを貼ってはいけないか、生成結果をそのまま使わない場面はどこか、といった日常動作を具体的に扱う必要があります。
ここではデータ取り扱いとプロンプト衛生が中心です。
たとえば、顧客名簿をそのまま外部サービスへ投入しない、会議メモを要約させるときは機密ラベルを確認する、回答に出てきた引用元をたどる、といった行動単位で教えるほうが定着します。

一方、開発者向け教育では観点を変える必要があります。
求められるのは、プロンプトインジェクション、システムプロンプト漏えい、権限外参照、ログへの機密残存、モデル出力の誤用といった攻撃面の理解と、安全設計の実装です。
『OWASP AI Security and Privacy Guide』（ように、生成AIの安全性はモデル単体ではなく、API、ツール実行、データ接続、権限、監視まで含めて設計しないと抜けます。
LangChainやLlamaIndexでRAGを組む開発者なら、取得した文書の命令を無効化する設計、引用元表示、実行可能ツールの制限、監査ログへのイベント記録まで教育対象に入れるべきです）。

教育は一度実施して終わりではなく、年次更新の仕組みを持たせたほうが現実に合います。
利用者向けはポリシー更新、禁止事例、実際に起きたヒヤリハットを反映し、開発者向けは新しい攻撃パターン、設計レビューで見つかった不備、監査指摘を反映する形で運用し、AI事業者ガイドラインや『データガバナンス・ガイドライン 2025』が重視する継続運用と経営関与を実現します。
研修を制度に組み込むとは、更新履歴と受講履歴が監査に耐える形で残ることまで含みます。

運用を回す仕掛けとしては、台帳管理、例外承認、定期監査、KPI設計をセットで置くのが定石です。
台帳には案件名、責任者、利用目的、モデル種別、接続先、データ分類、法務確認者、セキュリティ確認者、例外有無、見直し日を載せます。
定期監査では、台帳未登録案件、権限逸脱、ログ欠落、評価未更新、削除未完了のような項目を見ます。
KPIは「教育を実施したか」のような活動量だけだと実態が見えません。
たとえば 未分類データ比率 は分類ルールが運用に浸透しているかを見られますし、監査ログ欠落率 は統制の実装漏れを直接あぶり出します。
加えて、例外承認の残存件数、是正期限超過件数、台帳未登録案件数を並べると、体制の緩みがどこから出ているかが見えます。

KPIは経営向けと現場向けで粒度を分けると機能します。
経営には、例外承認の増減、監査不備の継続件数、重要案件のレビュー完了状況のような判断材料を出し、PMOや実務担当には、ログ欠落、分類漏れ、受講未更新、是正遅延のような改善対象を出します。
EDMで言えば、Evaluateは案件の入口、Directは方針と基準、MonitorはこうしたKPIと監査で回る構造です。
ルールが回る組織は、文書の厚さではなく、責任の線が引かれ、教育が更新され、例外が記録され、数字で状態が見えているかで決まります。

使えるフレームワークの選び方

主要フレームワークの地図

AIガバナンスの枠組みは、似た言葉が多いわりに役割が違います。
整理すると、まず土台にあるのがOECD AI原則です。
2019年5月に採択され、2024年5月に更新されたこの原則は、透明性、説明責任、安全性・堅牢性、人権や民主的価値の尊重といった考え方を示すもので、各国の制度やガイドラインの共通母体として機能しています。
理念のレベルで「どんなAIが望ましいか」を示す座標軸だと捉えると位置づけがつかみやすくなります。

その上に、実務でよく参照されるのがNIST AI RMFと『ISO/IEC 42001』です。
NIST AI Risk Management Frameworkは2023年1月26日に公開された任意利用のフレームワークで、法令でも認証規格でもありませんが、部門横断でAIリスクを話すための共通言語としてよく機能します。
加えて、生成AIに特有の論点を補うGenerative AI Profile（NIST-AI-600-1）が2024年7月26日に公開され、汎用的なRMFを生成AI案件へ落とし込む導線も整いました。
NISTの整理が有効なのは、法務、セキュリティ、開発、事業部で見ているリスクが違っていても、「何を統治し、どのリスクを、どの場面で、どう扱うか」を同じ言葉で並べられるからです。
実際、私もNIST AI RMFを先に部門間で合意した案件では、要件定義の会話が「安全に使いたい」「説明できるようにしたい」といった抽象論から、データ出所、監査ログ、権限外参照、人的関与の設計といった具体的なリスク対話へ切り替わりました。

一方の『ISO/IEC 42001』は、2023年12月18日に発行されたAIマネジメントシステム規格です。
こちらは「考え方を揃える」だけでなく、方針、役割、運用手順、内部監査、継続改善まで含めて組織の仕組みに落とし込むための枠組みです。
AI案件が増え、審査記録、教育履歴、是正処置、レビュー周期まで制度として残す必要が出てくると、42001の強みが見えてきます。
監査や説明責任が求められる組織では、この違いがそのまま採用理由になります。

さらに、日本企業にとって実務上の参照軸になるのが、経済産業省と総務省のAI事業者ガイドラインです。
第1.0版は2024年4月19日に公表され、その後も更新が続いています。
国際的な原則や標準を日本の事業実務に寄せて読み替える役割があり、開発者、提供者、利用者という立場ごとの留意点を確認できる点が使いどころです。
海外展開や法規制対応まで視野に入るなら、EUのEU AI Actとの関係も外せません。
こちらは理念や任意指針ではなく、リスク分類に応じて義務が課される規制です。
つまり、OECDが価値原則、NISTが対話の枠組み、ISO/IEC 42001が運用制度、AI事業者ガイドラインが国内実務の翻訳、EU AI Actが法的義務のレイヤーだと捉えると全体像が崩れません。

ISO/IEC 42001:2023

Information technology — Artificial intelligence — Management system

www.iso.org

NIST AI RMFとISO/IEC 42001の違い

NIST AI RMFと『ISO/IEC 42001』は、どちらもAIリスクを扱いますが、向いている問いが違います。
NISTは「どのリスクをどう捉え、関係者でどう共有するか」に強く、ISO/IEC 42001は「その管理を組織の仕組みとしてどう回し、どう監査に耐える形にするか」に強みがあります。

短く言えば、RMFはリスク対話の枠組み、42001は運用管理の規格です。
RMFは任意利用で導入の敷居が低く、PoCが増え始めた段階でも使えます。
たとえば、社内FAQボットを本番化する前に、法務は個人情報と説明責任を気にし、セキュリティは権限外参照とログ保全を見て、事業部は回答品質と運用負荷を見ている、という場面でも、RMFなら論点を一枚に集めやすくなります。
まだ体制や監査制度が固まっていない会社でも始めやすいのはこのためです。

対して42001は、方針の文書化、役割の明確化、教育、内部監査、是正処置、継続改善まで含めて要求事項として扱います。
AI活用が個別案件から全社運用へ移ると、「審査したつもり」「教育したはず」「例外を認めたが記録がない」といった運用の穴が問題になります。
42001はそこを埋めるための規格です。
説明責任を求められる取引先対応や、第三者監査を視野に入れた体制整備では、RMF単体より42001のほうが前に出ます。

使い分けを具体化すると、生成AIの利用ルールを新設する段階ではNIST AI RMFから入るほうが進めやすい場面が多いです。
部門ごとに見ているリスクを共通化し、案件レビューの観点を揃え、どこに追加統制が必要かを洗い出せるからです。
逆に、すでにAI案件台帳、審査フロー、教育計画、監査サイクルを組織標準として定着させたいなら、『ISO/IEC 42001』のほうが骨格になります。
RMFで論点整理をし、その後42001で制度化する流れにすると、現場と監査のどちらにもつながります。

日本のAI事業者ガイドラインとEU AI Actの関係

日本企業の現場では、AI事業者ガイドラインがもっとも手に取りやすい実務文書です。
国際標準や抽象的な原則だけでは動きにくい部門でも、このガイドラインは日本語で役割別の整理がされており、社内規程、審査票、教育資料に落とし込みやすい構成です。
とくに、開発者、提供者、利用者の視点を分けているため、「誰が何を持つのか」を具体化しやすい点が効きます。

ただし、国内ガイドラインだけで閉じると、海外規制との接続が見えにくくなります。
そこで参照軸になるのがEU AI Actです。
EU AI Act（Regulation (EU) 2024/1689）は2024年7月12日に公布され、2024年8月1日に発効していますが、条文の適用範囲や段階的適用の詳細は EUR‑Lex の原文を確認してください。
実務では、AI事業者ガイドラインを社内運用の入口にしつつ、EU向けの提供や高リスク用途の可能性がある案件だけEU AI Actの観点を上乗せする整理が現実的です。
たとえば、国内向けの社内業務支援チャットと、EU市場向けに提供する採用支援AIでは、求められる文書と審査の深さが同じにはなりません。
この差を吸収するためにも、国内ガイドラインをベースにしながら、EU向け案件では高リスク判定、技術文書、記録管理の要求に接続できる設計にしておく必要があります。

背景理解としては、OECD AI原則が各国制度の共通土台にあるため、日本のガイドラインとEUの規制はまったく別言語で書かれているわけではありません。
人権、透明性、説明責任、安全性といった中心概念は重なっています。
違いは、どこまでを努力義務や指針で扱い、どこからを法的義務として執行するかです。
この差を見落とさなければ、国内実務と海外規制対応を一続きで設計できます。

（注）EU AI Act の適用範囲や段階的適用の詳細は、EUR‑Lex（Regulation (EU) 2024/1689）の原文で条文を直接確認してください。

起点としてもっとも扱いやすいのは、NIST AI RMFです。
理由は単純で、認証取得や法令対応から入るより先に、社内の会話を揃えられるからです。
AIガバナンスが止まる場面の多くは、対策不足そのものより、法務、情報システム、セキュリティ、事業部、開発の見ている論点が噛み合っていないことにあります。
RMFを共通言語にすると、議論の起点が「AIは危ないか」ではなく、「この案件のどこにどんなリスクがあり、誰がどの統制を持つか」に変わります。

その次に、日本企業ならAI事業者ガイドラインへマッピングする流れが収まりやすいのが利点です。
NISTで整理した論点を、日本の部門責任、社内ルール、審査票、教育資料の形に変換する段階で国内ガイドラインが効きます。
ここまでで、現場運用の骨格は整います。

監査対応、取引先要求、全社制度化まで進む組織では、『ISO/IEC 42001』で運用を制度として固定する流れが次に来ます。
AI利用が数件のPoCではなく、複数部門の本番運用へ広がると、記録、監査、継続改善、経営レビューまで含めた仕組みが必要になります。
42001はその局面で力を発揮します。
社内で案件を回すだけならNIST中心でも足りますが、説明責任を外部に示す必要が強まるほど、42001の比重が上がります。

EU AI Actは起点というより、適用可能性を判定して上乗せする対象として見るほうが運用上は整理しやすくなります。
すべての案件をEU規制前提で設計すると重くなりすぎますし、逆にEU市場向け案件で無視すると後で要件が噴きます。
国内中心の企業でも、製品提供先や顧客基盤によっては早い段階で確認対象に入ります。

実務の順番を一行で書くなら、まずNIST AI RMFで共通言語をつくり、AI事業者ガイドラインに写して国内実務へ落とし込み、監査や認証の要件があるなら『ISO/IEC 42001』で制度化し、EU市場に関わる案件にはEU AI Actを重ねる、という並びです。
フレームワーク選定で迷う組織ほど、全部を同時に読もうとして止まります。
実際には、役割ごとに読む順番を分けたほうが前に進みます。
経営とPMOは42001の運用要求を見て、現場の設計レビューはNISTで揃え、法務と事業部はAI事業者ガイドラインとEU AI Actの接点を見る、という分担のほうが機能します。

すぐ使える導入チェックリスト

導入の現場では、統制の「正しさ」より「回り方」のほうが先に効きます。
私自身、最初の段階から本番レベルの審査票と承認経路をPoCにそのまま載せたことがありますが、開発の足が止まり、検証したい論点に着く前に工数だけが膨らみました。
そこでPoC用の簡易チェックと、本番移行時の詳細審査を分けたところ、抜け漏れは減らさずに総工数のほうが下がりました。
ここでは、そのときに実務で定着した形に近いチェックリストの切り方を示します。

運用体裁は、PoCタブと本番タブを分けたうえで、どちらも「項目 / 目的 / 担当 / 頻度 / 証跡」の5列で管理すると収まりがよくなります。
担当は個人名ではなく、開発、情報システム、法務、セキュリティ、プロダクト責任者のようにロールで置くと、人の入れ替わりに耐えます。
証跡欄には、会議メモ、承認記録、設定画面の保存、ログ保存先、テスト結果、ベンダー確認記録のどれを残すかまで書いておくと、後から監査用に拾い集める作業が減ります。

PoC段階の最小セット

PoCでは「速く試す」と「危ない線を踏まない」を両立させる必要があります。
ここで本番同等の統制を求めると、社内FAQの検索ボットを1本試すだけでも、正式分類、委員会審査、規程改定、監査証跡整備まで先に求められ、検証より前に疲弊します。
逆に、何も決めずに始めると、RAGに顧客文書を入れた時点で止まります。
PoCでは、判断に必要な最小限だけを先に固定するのが現実的です。

以下は、PoC用タブに入れておくと動かしやすい最小セットです。

PoCで見るべきポイントは、統制の網羅性ではなく、本番で問題になる論点がもう見えているかです。
たとえば『OWASP AI Security and Privacy Guide』。

シナリオ別の補助欄も、PoCから別枠で持っておくと判断が速くなります。
社内FAQなら「公開済み規程のみ」「人事・評価・労務文書は除外」、RAGで顧客データを扱うなら「契約上の利用目的に含まれるか」「テナント分離が必要か」、コード生成なら「社外送信禁止のリポジトリを除外するか」、エージェントに外部権限を渡すなら「メール送信・チケット起票・CRM更新のどこまで許すか」を補助欄に書きます。
項目自体は同じでも、危険線はシナリオで変わるからです。

本番段階の必須セット

本番では、PoCで見えていた論点を制度に落とし込みます。
ここで必要なのは、単発の安全確認ではなく、継続運用と監査に耐える形です。
ように、AIの管理は設計時の一度きりではなく、運用、変更、監視、見直しまで含めて回していく必要があります。

本番タブには、少なくとも次の項目を入れておくと、部門間の責任分界が崩れにくくなります。

本番段階で効くのは、アクセス制御を「権限あり・なし」の二択で終わらせないことです。
RAGの文書検索では、役職だけでなく、所属部署、契約テナント、扱える機密区分、利用時間帯といった属性で絞り込む場面が出ます。
ABACを使うと、文書側の属性と利用者側の属性を突き合わせて返却前にフィルタできます。
顧客データを含むRAGで、この設計がないまま検索精度だけを追うと、回答の出来より先に承認で止まります。

シナリオ別の補助欄は本番ではさらに効きます。
社内FAQなら誤回答時の案内文と担当窓口、顧客データRAGなら契約単位の分離と同意記録、コード生成ならOSSライセンス混入と機密コード送信の制御、エージェント型なら外部SaaSへの実行権限と承認フローを個別欄に持たせます。
特にエージェントは「答えるAI」ではなく「動くAI」なので、閲覧権限だけでなく実行権限の証跡が必要になります。

台帳・証跡テンプレートの作り方

テンプレートは立派に作るより、審査と運用で本当に使う列だけに絞ったほうが回ります。
実務では、1枚目をPoCタブ、2枚目を本番タブ、3枚目をシナリオ別補助欄にする構成が扱いやすい形でした。
PoCと本番を同じシートに混ぜると、軽く試したい案件まで重い審査票に巻き込まれますし、本番案件では逆にPoC向けの薄い記録しか残らなくなります。

テンプレートの基本列は次の5つです。

この5列に加えて、補助欄として「対象シナリオ」「扱うデータ」「利用ベンダー」「例外承認番号」を持たせると、あとで絞り込みや監査対応が楽になります。
たとえば、OpenAI系APIを使う案件とAzure OpenAI Serviceを使う案件では、契約とログの持ち方が変わるので、ベンダー列があるだけで整理の精度が上がります。
ベクトルDBもPinecone、Weaviate、OpenSearchのように実装先を書いておくと、メタデータフィルタや監査ログの所在を追いやすくなります。

証跡は、単に「あり」と書くのでは足りません。
「どこにあるか」まで残しておく必要があります。
会議で承認したなら議事録の保存先、権限制御なら設定画面の保存日、テストならケース名と結果ファイル名まで書いておくと、事後監査用の証跡保全につながります。
ここを曖昧にすると、事故が起きたときに「確認したはず」が残りません。

日本語の運用文書として整えるなら、分類、ライフサイクル管理の観点を列設計に反映させると収まりがよくなります。
AI固有の安全対策だけでなく、データの出所、保持、削除、権限制御を同じ台帳の中で追えるようにしておくと、AIセキュリティとデータガバナンスが別々の紙で分断されません。

テンプレートは凝った仕組みより、案件が増えても同じ見方で追えることのほうが効きます。
PoCでは薄く、本番では深く、その代わり列の構造は変えない。
この設計にしておくと、開発速度を落とさずに、承認・監査・運用の会話を一つの台帳へ乗せられます。

よくあるつまずきと改善の進め方

失敗パターンの早期検知サイン

導入が止まる案件には、似た前兆があります。
いちばん多いのは、ルール先行で運用不能になる形です。
申請書や審査項目だけが先に増え、現場はOpenAIやAzure OpenAI ServiceのPoCを進めたいのに、どのデータなら投入できるのか、誰が承認するのか、例外はどこで裁くのかが決まっていません。
この状態では統制が厳しいのではなく、統制の置き場所がずれているだけです。
審査のたびに判断基準が揺れ、結果としてシャドーAIが増えます。

責任者不在も典型的です。
情報システム、セキュリティ、法務、事業部がそれぞれ断片的に関わっていても、最終的に「このユースケースを本番へ上げる」と言える人がいないと、判断は宙に浮きます。
前述の体制設計でRACIを置く理由はここにあります。
責任分界が曖昧な組織では、問題が起きたときだけ全員が集まり、平時は誰も意思決定しません。
ガバナンス不在や統制不足が侵害コスト増と結び付きやすいのも、この「誰も最後の責任を持たない」状態が修復を遅らせるからです。

データ分類未整備も見逃せません。
文書が「公開」「社外秘」「顧客契約情報」「個人情報」といった区分に分かれていないままPineconeやOpenSearchへ取り込みを始めると、RAGの精度以前に検索対象の妥当性が崩れます。
ABACを入れようとしても、文書側の属性が空欄では判定できません。
分類がない組織では、「アクセス制御を強くする」と言いながら、実際には全件許可か全件禁止の二択になりがちです。

監視不十分も、失敗の進行を静かに加速させます。
推論APIの利用ログ、検索ログ、権限判定ログ、例外承認ログが分かれていたり、そもそも残っていなかったりすると、「誰が、いつ、何にアクセスしたか」を後から追えません。
実務では、分類とログの整備だけで現場の空気が変わることがあります。
私が見てきた案件でも、文書分類を揃えたうえで監査ログの保存先を一本化しただけで、問い合わせから初動封じ込めまでの流れが短くなり、インシデント初動にかかる時間は体感では半分近くまで縮みました。
原因調査の議論が「たぶん」ではなく、アクセス履歴を見ながら進むようになったからです。

現場教育不足は、もっと地味に見えて根が深い要因です。
開発者はプロンプトインジェクションやシークレット混入を知っていても、業務部門が「貼ってはいけないデータ」を理解していないと運用は崩れます。
逆に、業務部門だけ教育して技術側がOWASP系の観点を持っていないと、ログや出力制御の穴が残ります。
『Cisco』が2026年版の調査でAIを利用した攻撃キャンペーンの増加傾向を整理しているのは、攻撃が高度になったという話だけではなく、運用側の理解不足が突かれやすくなっているという意味でもあります。
予測や傾向として読むべき内容ですが、投資の優先順位としては、派手な防御製品より先に分類、責任、監視、教育を並べるほうが崩れにくい設計です。

AI Infrastructure, Secure Networking, and Software Solutions

Cisco is a worldwide technology leader powering an inclusive future for all. Learn more about our products, services, so

www.cisco.com

90日で立て直すロードマップ

立て直しは、一気に制度化しようとすると失敗します。
90日を3区間に分けて、台帳と責任の整備から始めるほうが筋が通ります。
最初の0〜30日は、棚卸しと責任分界の確定に集中します。
対象となるAI利用をPoC、本番候補、本番運用中に分け、使っているモデル、連携SaaS、投入データ、保存先、例外運用を洗い出します。
そのうえでRACIを置き、業務責任者、セキュリティ責任者、運用担当、承認者を案件単位で埋めます。
この区間で効くのは、重い新制度ではなくPoC用の軽いチェック導入です。
最低限、「どのデータを入れるか」「出力をどこまで保存するか」「例外は誰が承認したか」が残る形に変えるだけで、止まっていた案件が動き始めます。

31〜60日では、データ分類とアクセス制御を本格化します。
ここでの中心は、未分類データを減らし、RBACだけで回らない箇所にABACを足すことです。
たとえば、営業部門は自部門の提案書だけ参照でき、法務は契約属性付き文書へアクセスでき、夜間の外部委託先アカウントは機密区分付き文書を返さない、といった条件は役割だけでは切れません。
文書属性と利用者属性を整えて初めて、RAGの返却前フィルタが効きます。
同時に監査ログの整備もこの期間で進めます。
推論ログ、検索ログ、承認ログを別々の画面で眺める運用では監査にならないので、最低でも案件IDやユーザIDで突合できる状態まで揃えます。
NIST AI RMFは2023年1月26日に公開され、その後NIST Generative AI Profileが2024年7月26日に追加されましたが、こうした枠組みが実務で役に立つのは、抽象原則を「分類・権限・ログ」の順に落とせるからです。

61〜90日では、運用監視と検証を一段深くします。
ここで候補に上がるのがDSPMの導入です。
どのデータがどこに置かれ、どの機密区分がどのシステムへ複製されているかを追えるようになると、RAG用ストレージやログ保存先の見落としが減ります。
加えて、レッドチーム演習を入れて、プロンプトインジェクション、権限外文書の返却、監査ログ欠落時の調査不能といった場面を実地で確かめます。
攻撃面の優先度が上がっている背景には、前述の通りAI利用型の攻撃キャンペーン増という傾向があります。
だからこそ、この区間では「攻撃を受けるか」より「受けたときに追えるか」を基準に投資順序を決めたほうがぶれません。
仕上げとしてKPIを可視化し、例外承認の滞留、未分類データ、教育未受講者を月次で追える形にします。

改善のKPIと監査のポイント

改善が進んでいるかどうかは、ルールの冊数では測れません。
KPIは、運用の詰まりと事故対応の遅さが数字に出る項目に寄せるべきです。
代表例としては、未分類データ比率、例外承認の滞留日数、監査ログ欠落率、インシデントMTTR、教育受講率が並びます。
未分類データ比率が高いままだとABACの判定対象が育たず、例外承認の滞留日数が伸びると現場は非公式な抜け道を探し始めます。
監査ログ欠落率は、平時には地味でも、事故時には説明責任の成否を左右します。
MTTRはセキュリティ運用の成熟度を端的に示し、教育受講率は制度が現場へ届いているかを映します。

監査では、文書の有無より整合性が問われます。
分類基準が定義されているなら、実際のSharePointやベクトルDB上の文書にそのラベルが付いているか。
例外承認フローがあるなら、承認番号が案件台帳、アクセス権設定、ログ保存先とつながっているか。
ABACを導入しているなら、subject、resource、environmentの属性が空欄なく埋まり、拒否時のログが追えるか。
ここが切れていると、制度上は統制があるのに、監査では「運用証跡なし」と見なされます。

投資の優先順位を考えるときは、脅威の強さと、統制不在による損失の大きさを重ねて見ると判断しやすくなります。
ガバナンス不在を放置した組織ほど後工程の損失が膨らみやすい傾向があります。
一方で攻撃環境の変化としては、AI悪用キャンペーンの増加傾向が確認されています。
前者は「整備しないコスト」、後者は「待ってくれない脅威」の話です。
だから、予算配分は監視製品だけに寄せるのではなく、責任者不在の解消、データ分類未整備の解消、監視不十分の是正、現場教育不足の補強に先に置くほうが、同じ投資でも失敗率を下げられます。

監査の現場で評価されるのは、完璧なゼロリスク宣言ではありません。
未分類データ比率が下がっている、例外承認が滞っていない、ログ欠落が減っている、MTTRが短くなっている、教育受講率が上がっている。
この流れが月次で見えれば、組織は立て直しの途中でも「改善している」と説明できます。
ルール先行で運用不能だった組織を戻すときも、責任者不在で案件が止まっていた組織を動かすときも、効くのは立派な標語ではなく、分類とログと責任の接続が数字に表れている状態です。

まとめと次のアクション

用語を切り分けたうえで、AIセキュリティ、データガバナンス、AIガバナンスを同時並行で整備することが、PoCを本番に進める最短距離です。
対策はライフサイクルに沿って実装し、運用はチェックリストとRACIで止まらない形に落とし込むと、制度が現場の仕事につながります。
実務では、AIツールとユースケースの棚卸から始め、データ分類、責任者アサイン、PoCと本番の審査分離、監査ログ・アクセス制御・出力レビューの最小運用までを先に決めると前へ進みます。
私自身、この「棚卸、分類、最小運用」の3ステップを2週間の1スプリントで回したときが、現場の抵抗が最も小さく、合意形成も進みました。
次に備える論点としては、エージェントの外部権限の細分化、DSPMによる継続監視、『NIST』のプロファイル更新への追従を運用計画に入れておくと、後追いの改修を減らせます。