作成日: 2026-08-19
生成AIを導入したのに、要約やメールの下書き以外では、仕事があまり変わらない。これはモデルの能力不足だけが原因ではない。AIが、その会社で使う「売上」「顧客」「利益」「契約」といった言葉の意味、データの正本、業務上の関係、利用者の権限を知らないからである。
Databricksが2026年に発表したGenie One、Genie Agents、Genie Ontologyは、この課題を「データスマートなAI Co-Worker」として扱う。ここでいうCo-Workerは、文章を返すだけのチャットボットではない。企業データに根拠を置き、業務の意味を踏まえ、必要に応じて次の行動につなげるAIを指す。Databricksの発表
ただし、AIにすべてのデータを見せれば解決するわけではない。企業AIの価値は、会社の文脈を使えることと、その文脈を権限と証跡の下で扱えることの両方で決まる。
「売上を教えて」だけでは、業務の答えにならない
営業部長がAIに「今月、売上が落ちている地域はどこか」と尋ねる場面を考える。一見単純だが、企業システムでは、先に定義を確かめなければならない。
- 売上は受注額、出荷額、請求額のどれか
- 返品や値引きを差し引くのか
- 今月は暦月か、会社の会計期間か
- 地域は顧客所在地か、営業組織か、販売チャネルか
- CRM、ERP、表計算、BIのうち、どれを正本とするか
AIがSQLを書けても、この定義が曖昧なら、もっともらしいが業務で使えない結果を出す。必要なのはデータ量ではなく、この会社で数字をどう使うかという文脈である。
Databricks AI/BIは、Unity Catalogのセマンティクスを使い、再利用可能な指標と意味的な文脈をGenie Agentsやダッシュボードのデータ源として定義する仕組みを案内している。AI/BIの公式ドキュメント
「コンテキスト税」は、意思決定の前に発生する
実務では、分析そのものより前段の確認に時間を使う。
この数字はどこから来たのか。
営業部の売上と経理部の売上が違うのはなぜか。
KPI定義は昨年と同じか。
最新のデータはどのファイルか。
こうした確認に費やす時間を、ここでは「コンテキスト税」と呼ぶ。データアナリストは、高度な分析だけでなく、定義を探し、数字を照合し、背景を説明する「人間のミドルウェア」になりやすい。
AIがこの負担を減らせるのは、回答文を速く書けるからではない。正本データ、KPIの定義、テーブル間の関係、更新時刻、利用者のアクセス権を、あらかじめ機械が扱える形にしている場合である。
Genie Ontologyは、企業の「意味と関係」を共有する試み
Genie Ontologyは、ビジネス用語、エンティティ、KPIの関係を継続的に改善するナレッジグラフとして紹介されている。Databricksの発表
たとえば、単に customer_id や arr という列名をAIに見せるのではない。次のような意味を共有する。
顧客A
├─ 契約Xを持つ
├─ 大口顧客に分類される
├─ ARRは正式な算定ルールで計算する
└─ 更新日・問い合わせ・利用状況と関係する
この関係が整理されて初めて、AIは「減収した顧客」を単なる一覧ではなく、契約更新、解約兆候、問い合わせ、売上影響と結び付けて扱える可能性が生まれる。
ただし、オントロジーは導入するだけで正しくならない。所有部門、定義、更新周期、例外、廃止手順を持たせなければ、古い言葉をもっともらしく使う新しい障害源になる。
| 管理対象 | 決めること |
|---|---|
| KPI | 算定式、対象期間、除外条件、所有者 |
| 業務用語 | 定義、同義語、利用部門、誤用しやすい表現 |
| エンティティ関係 | 顧客・契約・案件・製品・担当の接続規則 |
| 正本 | 優先するデータ源、版、鮮度、改訂者 |
| 例外 | 欠損、矛盾、未確定時にAIが回答を控え、誰へ渡すか |
「人に見せない情報は、AI経由でも見せない」
企業AIの利便性は、アクセス制御を飛び越える理由にはならない。DatabricksのGenieは、組織データに根拠を置き、Unity Catalogを通じて統制されるAI体験として位置付けられている。Genieの公式ドキュメント
Unity Catalogは、データとAIのための統合ガバナンス層であり、アクセス制御、リネージ、監査を扱う。Unity Catalogの概要 Genie Agentについても、利用者ごとに見せるデータを絞るには、基礎テーブル側の行レベルセキュリティを適用する、と明記されている。Genie Agentの設定
この原則を実務へ翻訳すると、次のようになる。
| 問い | 実装すること |
|---|---|
| 誰が質問するか | SSOと利用者の役割を識別する |
| 何を見せるか | テーブル、列、行、共有範囲を権限で制御する |
| 何を根拠にしたか | データ資産、定義、変換、更新時刻を追跡する |
| 何を実行できるか | 検索、下書き、更新、外部送信を別権限にする |
| 間違えたらどうするか | 停止、訂正、通知、再実行、調査の手順を定める |
「AIがそう言った」ではなく、「どのデータ、どの定義、どの権限でこの結果になったか」を確かめられる状態が、業務で使うための最低条件になる。
シャドーAI対策は、禁止だけでは完成しない
機密情報を外部AIへ入力しないよう規程を設けても、公式環境が仕事に役立たなければ、利用者は個人契約のツールやコピー&ペーストへ流れる。これはセキュリティ意識の問題だけではなく、公式の業務経路が不足している問題でもある。
だから、シャドーAI対策は「禁止」と「安全で役立つ代替経路」をセットにする。
- 許可するAI環境と、扱えるデータ分類を明示する。
- 正本データと定義を接続し、一般論でない回答を出せるようにする。
- 読み取り、下書き、書き込み、外部送信を段階的に許可する。
- 権限拒否、根拠不足、例外を、使いにくさではなく安全な引き継ぎとして設計する。
- 利用者の失敗・訂正・要望を、知識と業務フローの改善へ戻す。
データ部門は「質問に答える部門」から、意思決定基盤を作る部門へ
AIがデータへの入口を担うようになると、データ部門が不要になるわけではない。むしろ、部門の価値は高まる。
| これまで偏りがちだった仕事 | これから強化すべき仕事 |
|---|---|
| 個別の集計依頼へ答える | KPIとセマンティクスを共通資産にする |
| 分析結果を説明する | データ品質、正本、鮮度、リネージを管理する |
| SQLを代行する | AIが安全に検索・分析できる権限境界を設計する |
| 部門ごとのレポートを作る | 再利用可能な指標、評価、監査の基盤を作る |
AI Co-Workerがビジネス部門の問いに直接応答できるのは、データチームが裏側で、意味・品質・権限・履歴を整えた場合だけである。役割が消えるのではなく、「数字を仲介する人」から「数字を安心して使えるようにする人」へ移る。
最初に作るのは、モデル選定表ではなく「意味の台帳」
AI導入を始めるなら、まず一つの意思決定を選ぶ。たとえば「解約リスクが高い大口顧客を、毎週、根拠付きで営業責任者に提示する」でよい。
次に、以下を一枚の台帳にする。
- 目的：何を改善し、誰が最終判断するか。
- 指標定義：解約リスク、大口、売上影響をどう計算するか。
- 正本と鮮度：顧客、契約、利用、問い合わせの正しいデータ源と更新時刻。
- 関係：顧客、契約、案件、担当、製品のつながり。
- 権限：誰が何を見られ、AIはどこまで操作できるか。
- 例外：根拠不足、データ矛盾、高リスク時にAIが止まり、誰へ引き継ぐか。
- 評価：提案の的確さだけでなく、根拠、権限順守、見逃し、手戻りをどう測るか。
この台帳がなければ、どんな高性能モデルも、企業の曖昧さを高速に再現するだけになる。
結論：企業AIの資産は、会社がAIに説明できることにある
Databricksの「データスマートなAI Co-Worker」という構想の本質は、AIモデルをさらに賢くすることではない。企業側を、AIが仕事を理解できる状態へ変えることにある。
モデルは更新され続ける。一方で、信頼できるデータ、共有されたKPI定義、業務の関係、権限設計、リネージ、評価の仕組みは、企業が蓄積する資産になる。
最初に問うべきは「どのAIモデルを導入するか」だけではない。
私たちの会社は、AIが根拠と権限を守りながら仕事を理解できる状態になっているか。
この問いに答えられることが、AIを便利なアシスタントから、任せられるCo-Workerへ進める条件になる。