AI時代のデータガバナンスを再考

夏休み自由研究連載 2026 の4本目です。

はじめに

TIG DX所属の真野です。

2026年7月に公開した、データガバナンス設計ガイドライン の派生物です。

大AIエージェント導入ブームがやってきました。その地ならしとして、データマネジメントもセットで整備しようという流れがあります。ここでどこまで本質的にデータを整えられるかが、企業にとって今後の勝負の分かれ目になるでしょう。

ところで、データガバナンスを定石に従って検討していくと、大半が構造化データの扱いに目が向きがちです。データマネジメントの標準体系であるDMBOKでも、非構造データをメインに扱うのは、11の知識領域のうち「ドキュメントとコンテンツ管理」の1領域だけです。

一方で、AIエージェントに業務をさせるには、業務フロー、判断基準、社内用語の意味といった暗黙知が要ります。こうした情報はデータベースではなく、PowerPointやExcelなどの社内文書やチャット・メールに含まれていたり、そもそも言語化されていない場合も多いです。

構造化データと、社内文書などの非構造データに、改めてどういう力点・順番で取り組むべきでしょうか？ 他にもいくつか論点があります。ここでは論点を3つに絞り再考します。

【問い1】構造化データからか？ 非構造データからか？

単純にどっちから進めるべきか話す前に、少し問題を整理します。

• 構造化データを整備するとは？
  • 販売計画、売上実績、生産計画、製造原価といったSystem of Record由来のファクトデータを、AIが使いやすい形で保管するということ
• 非構造データを整理するとは？
  • AIにコンテキストを上手く与え、業務内容を理解してもらうこと

事業目的や業務内容を理解したAIでも、正しい受注実績が取得できなければ、業務利用に耐えられる判断はできません。逆に、ファクトデータだけが揃っていても、業務の文脈を知らないAIには「どのデータを、どんなルールで見ればよいか」が分かりません。片方だけやれば成果が出る関係では当然ながら無いため、限られた体制でどういう濃淡で力点を置いていくかという話になります。

問い自体もアップデートすると、AIに良い判断をさせるために必要な要素は何か？ から分解して、必要な要素を順序立てて揃えていく話になります。おそらく、必要なファクトデータやそのメタデータを揃え、AIが必要十分にアクセスできる権限設計あたりからが手堅いでしょう。業務ルール？プロンプトに書き殴って動かすところから検証すれば良いのです。

非構造データの難しさとは

まず前提として、非構造ファイルの管理はAI以前から存在します。情報資産管理のルールや部署ルール(このフォルダにこの種のファイルを置く、作成中のものは「_作成中」を付ける、など)といった形で、非構造データにもすでに規約はあるわけです。ないのは、それを機械が読める形に格上げする仕組みです。

では非構造データを一括りに「難しい」と言ってよいかというと、一概にそうではありません。データが 誰に帰属するか で並べてみると、レベル感がまちまちだと分かります。

表の通り、非構造データの難易度はどこに帰属するかでも決まります。

• トランザクション帰属の非構造データ
  実は構造化データの親戚です。工場ラインの検査画像は「検査」というトランザクションの産物なので、検査IDや日時、ライン、判定結果というメタデータが自然に付きます。DBにはポインタとメタデータを置き、実体はオブジェクトストレージに置けば、構造化データのガバナンスにほぼ相乗りできます。
• 組織帰属の非構造データ
  提案書やマニュアルはチームの成果物であり、おそらく作成した個人ではなく部門に紐づきます。ここから企業独自の考え方・ルール・業務フローを抽出できるかが、AI活用の勝負どころだと思っています。ただし現実のフォルダは「_最終_v2_修正済」が乱立し、同じ規程のコピーが部署ごとに散らばり、3年前のマニュアルが最新版として参照されたりします。RAGの前処理として、正本の置き場、ステータスの命名、オーナーの明示といった最低限のドキュメントガバナンスが要ります。つまり、先ほどの「すでにある規約」を機械可読に格上げする仕事がここに来ます。
• 個人帰属の非構造データ
  チャットやメールは、個人への紐づきが強すぎます。プライベートの雑談や、その場だからこそ言えた発言が混ざるためです。利用規約や労務の論点以前に、心理的に受け入れにくいはずです。さらに言うと、監視されていると感じた瞬間に人は書かなくなるので、チャットをAIに読ませて暗黙知を得ようとすると、その源泉が枯れて本末転倒になりそうです。ここは「原則やらない」から始めるのが良いと考えていますが、第三の道は後述します。

同じ組織帰属でも扱いやすさに差があります。設計書や仕様書はシステム側に揃っていて、従来からデータカタログのテクニカルメタデータやビジネスメタデータのインプットでした。そのため、設計書からメタデータへの変換をAIに行わせて基盤へ振り下ろす、という関係になるでしょう。「売上」という言葉に社内で複数の定義がある、といった意味の揺れも、この素材からセマンティックレイヤーを整備するという流れが考えられそうです。

難しいのは、業務の判断基準やドメイン知識(オントロジーやナレッジグラフに落とし込みたいもの)で、こちらは事業部門のドキュメントやベテランの頭の中に眠っています。同じ「非構造の社内文書」でも、基盤側で閉じて取り組めるものと、事業部門に散らばっていて手が届きにくいものがあるので、本来はこの2つも区別したほうが良いでしょう。

構造化データからか？ 非構造データからか？ の答え

ここまで踏まえた上で、構造化データ・非構造データのどちらから整備すべきか？の見解です。

• 着手は表の帰属順の浅い方から。構造化データ → トランザクション帰属の非構造データ → 組織帰属の非構造データ。個人帰属は後回し。難易度もそうですし、費用対効果も出やすいと思うためです
• ただし、組織帰属の非構造データのRAG・ナレッジDB化はそこまで実験コストが大きくないので、基盤整備と並行して試すのもありかと思います。とはいえ、出力品質などの課題が出てからの方がゴールが明確になるとは思います

【問い2】AIに使わせる側の統制は何からやるべき？

AIに使わせる側の論点は、たとえばこういうものです。RAGを全社中央にひとつ構えるか、部門ごとに持たせるか。中央に置くと統制しやすい反面、業務の文脈が薄まります。部門ごとに置くと文脈は濃くなりますが、管理されないRAGが乱立しがちです。SaaS組み込みエージェントを使ってもよいか？棲み分けは、データがそのSaaSの中で完結する業務はSaaS側、部門横断が必要な業務はデータ基盤側、という整理が出発点になりそうです。

こうした論点は色々ありますが、何からやるべきかと問われれば、まずは「AIを試して学ぶを推奨すべきか、統制を取るべきか」の方針を決めることだと考えています。以降で深掘りします。

AIを試して学ぶを推奨すべきか、統制を取るべきか

AIに使わせる側の統制をどうするか、苦慮している組織は多いです。試して学ぶを推奨することで、PoCの乱立を心配する方もいるはずです。試させれば「本番データを早くつなぎたい」という要望だけが強くなり、統制する側が対応に四苦八苦します。チームごとにエージェントもモデルもオーケストレーションツールもばらばらで、監査ログが揃っているかも分かりません。アクセスが急に増えて、基幹システムに想定外の負荷がかかる心配もあります。

かといって、個別案件をひとつずつ審査する許可制は、詰まりやすく、遅く、そして申請する側に不満が溜まります。だれも好き好んで恨まれたくないです。あるべき道は、あらかじめ承認済みのゴールデンパスを敷いておき、道の上は申請不要、道を外れるときだけ審査する形だと思っています。

• サンドボックス: マスキング済みデータと、承認済みのモデルとエージェント実行環境。申請不要で誰でも試せるなど
• 読み取り専用: レプリカ経由で本番データを参照できる。軽い届出で可。基幹システムへの負荷はレプリカとゲートウェイのレート制御で吸収するなど
• チェックゲート: 本番接続、書き込み、自動実行。ログ、権限、オーナーを付けた上で昇格を審査する場も検討する

見落とされがちなのは、サンドボックスに置くデータの整備です。古い断片データしかない環境では、試しても有効な学びになりません。しかし、サンドボックスに本番に近い鮮度と整合性を持つデータを置くなら、万が一の流出を考えて、サンドボックスの利用にも制限を設けたくなります。適切なマスキング済みデータセットをどう用意するかが鍵です。もし、最新データが無いダミーデータばかりですと、そのサンドボックス環境はおそらくほぼ使われません。ジレンマです。

テストデータの整備がプロダクト開発の土台であるのと同じ意味で、これはAI時代のデータ利活用戦略の重要な作業になると考えています。考えるだけでめちゃくちゃ大変そうで辛い感じです。ゴールデンパスを準備すれば解決です、といった簡単な話ではなく、推進力が試されます。

【問い3】権限設定は依然として関門であり、どうすれば広げられるのか

AIにアクセス権限を付与しないと何も動きませんが、すべてを見せて良いわけではないのは普遍的ですので、ここは引き続き大きな論点です。

セキュリティの鉄則は最小権限の原則です。必要な人に、必要なものだけ、必要な期間だけ。一方でデータ民主化やAI活用の要求は逆です。部署を横断して広く読めなければ、横断的な業務改革も、組織の全体像を踏まえたAIの回答も生まれません。この綱引きが、権限設計のジレンマです。

現実の大企業では、ほぼ確実に細かく制御しているのではないでしょうか。長年の運用でアクセス制御には、退職者の残骸、兼務のための例外付与、プロジェクト単位の場当たり設定が積もっています。だから「既存の権限設定を流用するか、再設計するか」が論点に上がるわけですが、流用でよいのは既存の権限設計が信頼できる場合だけで、この論点が上がる時点でたいてい信頼できません。

では再設計して広げましょう、と言っても進まない理由があります。各事業部がデータオーナーとして権限申請の可否を判断する構図では、広げて得をするのは利用者側で、事故のときに詰められるのはオーナー側だからです。データ流出が起きれば「なぜ全社員向けの緩い設定にしたのか。重要ならもっと閉じておけばよかったのに」と後から言われかねません。また、事故は目立ちますが、広げたおかげで生まれた価値は誰にも見えません。この非対称性の下では、合理的なオーナーは今まで通りの縄張りで権限を設定する方向に倒れます。その結果、データ基盤はできたのに今まで通りのことしかできず、「何のためにやっているんだ」という状態に落ちます。

つまりこれは、オーナー側のやる気とか勇気の問題ではありません。仕組みの問題です。

公開範囲を広げるための3つの仕組み

非対称性を潰すには、3点をセットで入れるのが良いと思っています。従来から言われている一般論に近しいポイントです。

• お墨付き
  リスクを取ってよいという基準を明文化し、経営名義で出します。具体的には、データ分類(公開、社内、機微、極秘など)を再定義した上で、「機微・極秘に該当しないものは社内公開がデフォルト」という原則を掲げる形です。ポイントは「開けてよい」ではなく「閉じる側に理由を書かせる」への反転で、挙証責任を移動させます。事故が起きたときに個人を詰めない、と先に宣言しておくことまで含めてお墨付きです。リスクをデータマネジメント側が引き取るとも言え、中々スパイシーです。
• 監査ログ
  誰が、いつ、何を、何の目的でアクセスしたかを残します。利用申請と利用ログのセットがあるから開けられる、という順序です。ここでひとつ指摘したいのは、AIエージェント経由のアクセスは、人間の閲覧よりも構造的に監査しやすいことです。人が画面で見て記憶する行為はログに残せませんが、エージェントのツール呼び出しは全件記録できます。「AIに読ませるのは怖い」という直感とは逆に、監査可能性の面ではAI経由のほうが統制しやすい面があります。ログは、事故時の説明可能性を担保して個人の責任を薄める仕組みです。
• 可視化
  データカタログで、部署ごとの公開状況を客観的に見せます。ある部署はデータ種別の8〜9割を公開していて、別の部署は1割しか公開していない、という事実が並べば、「なぜ少ないのか」は自然に問われます。オーナーシップへの健全な刺激になりますが、公開率を評価指標にした瞬間、中身のないメタデータや形だけの公開が量産されるので、あくまで事実の可視化に留めるのが良いと思います。可視化は、「広げても得しない」問題に評判というリターンを作る仕組みです。

まとめると、お墨付きがリスクを経営に引き取らせ、ログが個人の責任を薄め、可視化がリターンを作るという感じです。

ガバナンスの仕事をAIにやらせる

ところが、前節の処方箋には抜け道があります。閉じる側に理由を書かせても、分類する権限がオーナーにある限り、詰められたくないオーナーの合理的な逃げ道は すべてを機微に分類すること です。組織的なデータリテラシが成熟しないと、どうしても慎重になります。本当に機微じゃないデータなんて存在するの？と考えるとうーんとなりますしね。

しかも分類やメタデータ付与は、データガバナンスの中で誰もやりたがらない最大のボトルネックです。ビジネスメタデータをカタログに手入力してもらう運用は、私の知る限りなかなか成り立ちません。

そのため、将来的にはガバナンスの仕事をAIにやらせる方向に進むでしょう。

• 分類: 公開区分のルールを定義して、AIに一次判定させます。たとえば、個人情報を含むもの、ユーザーの同意範囲を外れる使い方になるもの、購入データでライセンス上二次利用できないもの、未公開の財務情報に該当するものは狭く。個人情報がなく、ライセンス上使えて、自社に知財があるものは広く、という要領です
• メタデータ: 設計書、仕様書、ダッシュボードといった既存の資料からAIがメタデータの下書きをかき集め、人間は最後の承認だけを行います。問い1で書いた「ロングテールは人手ではやり切れない」問題の答えがこれです

人がやるべき仕事は、個々の分類ではなく「AIが区別しやすい分類ルールとは何か」を考えることに変わります。そして責任の所在も変わります。分類の責任は個々のオーナーから、分類ロジックを担保するデータ基盤側へ移り、そのロジックを経営が承認する形になります。お墨付きの対象が、個別の判断からロジックそのものに変わるわけです。人は個別判断で詰められますが、経営承認されたロジックに従った結果では詰められません。

データの帰属は可変的である

問い1で整理した帰属レイヤーは、データを静的に分類する枠のように見えます。しかし知識は帰属を移転します。個人のチャットでの気づきが議事録になり、部門のマニュアルになり、全社の規程になっていく。この流れを見ると、ガバナンスの仕事は帰属の判定ではなく、個人の知を組織の正本へ昇格させるプロセスの設計 なのではないかと思えてきます。

これは問い1で「原則やらない」としたチャットの問題に、第三の道を開きます。チャットをAIに読ませて暗黙知を吸い上げるのではなく、AIが昇格候補を見つけて「この議論、ナレッジ化しませんか」と提案し、本人が承認したものだけが組織帰属へ昇格する形です。監視ではなく提案なので、萎縮効果を避けながら暗黙知を回収できます。運用に慣れて精度が上がれば、承認を省略できる範囲も広がっていくはずです。

正直に書くと、ここは私もまだ実装しきれていません。まとめるボットを作ること、昇格先とプロセスを設計すること、現場に「ここに知識を集める」と浸透させること。どれも地道な壁です。ただ、これを早く取り入れた企業とそうでない企業では、組織の知識がAIに使える形で貯まる速度に差がついていくと考えています。

Governance as Code 来るか？

ルールの管理そのものにも同じ流れが来ると考えています。データガバナンスを三権分立になぞらえると、ルールを定める立法と、運用を監査する司法がガバナンスで、実装して運用する行政がデータマネジメントです。

立法の中身は今はたいてい自然言語の文書で管理されていて、変更の経緯がクローズドなため、従う側から見ると「なんでこんな面倒くさいことをやるのか」が分からないままルールだけが提示されます。できれば無視できないかと常に考えます。

ソフトウェア開発がソースコードでやっているように、ガバナンスのルールもコードとして差分管理できれば(governance-as-code)、v1.0からv1.1への差分と議論の経緯、それに伴う基盤設定の変更までがつながって見え、従う側の納得感が上がります。ガバナンス自体の透明化や可視化が求められる時代です。背景が分かるとAIの追随もしやすそうです。新時代の幕開けかもしれません。

まとめ

主張のまとめです。

1. ファクトデータ、非構造は帰属の浅い、扱いやすいものから整えよう
2. AI利用は個別審査ではなく、サンドボックスと本番利用のための条件を準備しよう
3. 権限は精神論ではなく仕組みで広げよう

AIが素案を提案し、人が承認し、経営がロジックを引き取る。

…という話をしましたが、AI駆動開発と同様に人間の役割が、作業者から承認者へ、さらに承認基準の設計者へと一段ずつ上にあがっていきます。AI時代のデータガバナンスも抽象度が上がり、仕事は一時的にはむしろ増えてきそうです。がんばりましょう。

最後まで読んでいただき、ありがとうございました！