データエージェント時代のガバナンス── ルールを誰が決めるのか 

データエージェントが、社内データを動かし始めた

データエージェントという言葉が、業界で急に増えました。自然言語の問いを受け取り、社内データに自律的にアクセスし、必要な分析や処理を複数ステップで実行するAIです。

たとえば経営者が「先月、解約が増えたセグメントは？その顧客の共通点は？」と話しかける。
するとエージェントが、自分で必要なテーブルを探し、結合し、集計し、グラフにして返します。さらに「該当する顧客の担当営業に、まとめてアラートを送って」と言えば、通知の送信まで実行します。
これまで人間のアナリストが数日かけてやっていた一連の作業を、対話の流れの中でエージェントが代行します。

BIが「見るインターフェース」、対話型AIが「問うインターフェース」だとすれば、データエージェントは「触る、動かすインターフェース」です。

ここで効いてくるのが、エージェントが裏側で下している判断です。どのテーブルを使うか。どう結合するか。誰にどこまで見せてよいか。どんなアクションを実行してよいか。これまで人間が経験と常識で判断していたことを、エージェントが肩代わりします。

判断を肩代わりさせるほど、ガバナンスが要る

人間の判断をエージェントが肩代わりするということは、判断を誤ったときの影響も、エージェントの速度で広がるということです。

定義のずれた数字を、そのまま経営会議の資料にしてしまう。見せてはいけない相手に、顧客データを返してしまう。確認のないまま、誤ったアクションを実行してしまう。
人間なら途中で「何かおかしい」と気づけた場面でも、エージェントは、与えられたルールがなければ止まりません。

だからこそ、ガバナンスの議論が一斉に立ち上がっています。
エージェントが自律的に判断する以上、その判断の前提となるルールを、人間が事前に書いて埋め込んでおかなければなりません。
BIの時代に「ダッシュボードを誰が見られるか」を決めれば足りた世界とは、問われる範囲が違います。エージェントは、与えられたルールの範囲でしか安全に動けないからです。

ルールをコード化する

業界が示し始めた答えは、「ルールをコード化せよ」というものです。海外ではPolicy as Codeと呼ばれる動きの、データ領域への適用です。
データ規約をドキュメントや口頭ではなく、Gitで差分管理できるコードとして書き、データ基盤やエージェントが実行時に自動で強制する。事後監査ではなく、事前防御の世界です。

本記事は、データとAIを経営の意思決定や事業活動に本気で組み込もうとしている会社を想定しています。ベンダーのデフォルト設定で運用が回るなら、それで十分です。デフォルトを超えた規約設計が必要になる会社に向けて書きます。

業界の答え「ルールをコード化せよ」は正しい。
ただ、その手前で多くの会社が止まっています。

「ルール」とは具体的に何のことか ：3層で整理する

「ルールのコード化」と言われたとき、コード化される対象は、実はかなり広範囲です。本記事では、これを3層で整理します。

層1：データ定義のコード化

何が「売上」か。何が「アクティブユーザー」か。各カラムの型、制約、許容範囲は何か。
これらの定義を、多くの会社はExcelの指標一覧や社内Wikiで管理してきました。
「売上」の定義が部署ごとに微妙に違ったり、同じ会議で違う数字が並んだりするのは、繰り返し見てきた光景です。

ここをコードに移すのが層1です。
指標定義はdbt Semantic Layerに、データ契約はdbt contractsに、データ品質ルールはGreat ExpectationsやSodaに書きます。Gitで差分が追え、PRでレビューされ、変更履歴が残ります。

エージェントに「先月の売上はどうでしたか」と問いを投げたとき、定義のずれた数字が同じ自信で返ってくる事態を防ぐのが、この層の仕事です。
指標定義のコード化は、エージェントの時代には、あれば便利、ではなく、「ないと壊れる」側に来ます。

層2：動的アクセス制御のコード化

• 関東エリアのマネージャーは関東の顧客データだけ閲覧できる

• 個人情報カラムは、特定ロール以外には自動でマスキングされる

• サンプル数が少ない粒度での生データ閲覧は禁止する

• クエリの結果を国外のリージョンに持ち出してはいけない

• 会員IDと購買履歴の生データ結合は、特定の承認なしには禁止する

これらの取り決めを、データ基盤側のポリシーとしてコードに書きます。
BigQuery Data Policyにせよ、Snowflakeにせよ、Databricks Unity Catalogにせよ、いずれも行レベルセキュリティ、列マスキング、データクラス分類を宣言的に書ける仕組みを持っています。ユーザーの所属属性に応じて、生成されるSQLに条件が自動付与されたり、出力カラムがマスクされたりする世界です。

これまでIAMが担っていたのは「誰がどのテーブルにアクセスできるか」の静的な定義でした。
エージェント時代に必要なのは、その先にある「アクセスしたあと、何をどこまで見られるか」の動的な制御です。
同じテーブルでも、見る人の属性や問いの文脈で、返ってくる内容を変える。これが層2の正体です。

どの属性をどう組み合わせて規約にするかは、人間が決めなければなりません。結局、規約の意思決定の話に戻ります。技術スタックの選択肢が増えても、決めるべきことが減るわけではありません。

層3：エージェントのガードレール

エージェントがどこまでのクエリを実行してよいか。どんなアクション、例えばメール送信、レコード更新、外部API呼び出しを取れるか。スキャン量が一定を超えるクエリは事前承認が要るか。機密度の高いデータに触れる問いは、出力前に人間のレビューを挟むか。エージェントの行動範囲そのものをポリシーで縛る層です。

データエージェントは、読み取りだけでなく実行まで踏み込みます。読み取りの権限と実行の権限を、同じ承認フローで渡してよいかは別の議論です。実行の世界には、取り消しと監査がセットで要ります。

ガードレール機能はこの1〜2年で急速に整備が進んでいます。ただし業界全体としては、層2に比べるとまだ発展途上で、何をどこまでガードすべきかの合意も、これから形成される段階です。

3層に共通するのは、これまでドキュメント、Excel、口頭で運用されていた取り決めを、Gitで差分管理されるコードに移す、ということです。
人間の判断を、システムが実行時に強制できる形に変換する。これがコード化の正体です。

コード化されると、何が変わるか

経営の視点で、コード化される前と後の差を3点に絞ると、こうなります。

1つ目は、変更履歴が追えること。
いつ、誰が、何を、なぜ変えたかが、Gitのコミット履歴に残ります。前は誰かの頭の中か、共有フォルダの古いExcelにしか残っていませんでした。コード化された規約は、コミットメッセージとPRの議論として、判断の理由まで残ります。

2つ目は、レビューと承認が記録に残ること。
ルール変更がPRとして起案され、関係者がレビューして承認する。属人的な「言った、言わない」が消えます。これは内部統制や監査対応の文脈でも、重い意味を持ちます。

3つ目は、実行時に強制されること。
ドキュメントで「禁止」と書いても、人間は破れます。事故が起きてから監査ログで気づくのが、これまでの世界でした。コードに書けば、データ基盤やエージェントが実行時にブロックします。事後監査から、事前防御に変わります。

ルールのコード化は、技術は着実に進んでいますが、問題は技術ではないところにあります。

その「ルール」を、誰が決めているのか

「ルールのコード化」が進まない最大の理由は、技術ではなく、コードに書く「ルール」を決める人が社内にいないことです。

データの取り扱いに関する規約の窓口は、さまざまな部門が担当します。例えば、情報システム部門と法務部門が引き取るなどです。

ところが、情シスはセキュリティ視点で判断するため、迷えば「禁止」と返しがちです。守ることが本来の役割なので、これ自体は責められる話ではありません。法務は法令解釈ができますが、業務上の影響までは判断しません。「個人情報保護法に抵触するか」は答えられても、「業務効率を下げてまで守るべきか」は領域外です。

データ部門は、現場の業務感を持っています。ただし、規約を「決める」権威は持ちません。実装と運用の責任はあっても、最終決定者ではないのです。

事業部はスピード優先で動きます。規約の調整役にはなりません。決まったルールを早く知りたい立場であって、決める立場ではありません。

結果として、規約の最終決定者が空白になる構造ができあがります。さらに踏み込むと、組織内の担当者間でも解釈が揺れたりもします。

同じ法務部の中でも、AさんとBさんで「これは個人情報に当たるか」の判断が違うことがあります。情シス部の中でも、クラウド利用ポリシーの読み方が、世代やバックグラウンドで分かれることがあります。
「前回、この件はどう決まったんでしたっけ」と聞くと、議事録が残っていないか、結論が複数あって混乱します。3年前のドキュメントに方針らしきものが書かれていても、当時の起案者が異動しており、今の現実と整合しているかは誰にも分かりません。担当者が変われば運用が変わる、属人運用の世界です。

最終決定者の不在以前に、中間レイヤーですら解釈が揃わないのが、ルールのコード化を止めている本当の理由です。

ベンダー提案を受けた社内会議で、各部署がそれぞれ違うルールを主張して空中分解する場面もよく見ます。事業部は「これくらい見えないと現場が動かない」と言い、情シスは「その範囲は出せない」と返し、法務は「個別判断が要る」と保留する。
結論は出ないまま、エージェントの導入だけが先に検討に乗ったりもします。コード化を止めているのは、技術選定でも予算でもなく、規約そのものの不在です。

経営がまず手を入れるべきは、規約を決める人と場

提案したいのは、規約を決める人と場を、まず1つ立てることです。

法務、情シス、データ責任者。それぞれから1人ずつ集めて、起案、レビュー、承認、例外申請を回す場を作る。その場で決めるべき最低限の問いは、こうです。

• 集計粒度の閾値はどこに置くか。サンプル数何件未満で生データ閲覧を禁止するか

• 行レベルアクセスのスコープを、誰がどの権威で承認するか

• データ持ち出しの境界はどう線を引くか。リージョン、業務委託先、AI学習用データ

• 例外申請のルートと、応答までの時間。誰が暫定承認できるか

• エージェントが取れるアクションの範囲。読み取りだけか、実行まで含むか

• 規約の更新頻度と、変更履歴の残し方

一度で完璧に決める必要はありません。重要なのは、「決める場が存在する」「次回までに更新される」という運用が回り始めることです。
例外申請のフローも一緒に決めておくと、現場が止まりません。緊急時は担当者単独で暫定承認、次回レビュー会で正式承認するか却下、暫定運用に上限期間を切る、の3点だけ揃えば十分です。これだけが揃えば、ルールのコード化は始まります。dbt Semantic Layerで指標を書くのも、行レベルセキュリティのポリシーを書くのも、決まった規約を写す作業になります。

多くの会社は、ベンダー選定とアーキテクチャ設計を先に走らせて、規約の意思決定で止まっています。これは順番が逆で、重要なのは、ツール選定の手前にある、ルールを決める場の設計です。最初に意思決定の場と人を整えれば、ベンダーとの会話は規約のコード化の議論として成立します。

コードに書けるのは、決まったルールだけ

コードに書けるのは、決まったルールだけです。決めるのは、いまも昔も人間の仕事です。

ルールのコード化は、技術側の進化で着実に進んでいます。ベンダー各社のアーキテクチャは、この1〜2年で目に見えて整いました。ただ、コードに落とされる元の「ルール」が決まっていなければ、どんなツールも動きません。
データエージェントを試験導入する話と、規約の意思決定機関を立ち上げる話は、本来は同時に走らせるべき2つの宿題です。