この記事の要点
- 外部型のAIは、データを別基盤へ渡すたびに権限や履歴を再構築する負担が生じる
- 計算後の出力を隠しても、権限外データの影響を受けた計算結果は修復できない
- AIの会話履歴や利用者の好みも、守るべき企業データになる
金庫の台帳を、建物の外へ運ぶAI
会社の重要データが、厳重に管理された金庫の台帳だとします。誰がどのページを読めるか、いつ書き換えたか、外へ持ち出してよいかは、社内の規則で決まっています。そこへ優秀なAIエージェントを雇ったものの、働く場所が別の建物だったらどうなるでしょう。仕事のたびに台帳を出張所へ送り、必要なページを複製し、向こう側でも鍵と閲覧記録を用意しなければなりません。
これがDatabricksのいう外部エージェントに近い構図です。AIやLLMを社内データ基盤とは別の環境で動かし、データを外部の検索基盤やモデルへ渡すと、元の金庫にあった権限や来歴がそのまま付いていくとは限りません。Databricksは、外部型ではガバナンス、通信遅延、データ移動費用、監視、システム更新、業務用語の共有に負担が積み上がると説明しています。
黒塗りは、計算が終わった後では遅い
たとえば台帳のうち、ある社員が読めるのは自分の担当部門だけだとします。AIが全部門の数字を読んで売上平均を計算し、その後で閲覧禁止の部門名を黒塗りにしても、平均値には禁止された数字が入っています。完成した回答から文字を消すだけでは、計算そのものに混ざった情報を取り除けません。
Databricksの記事は、行単位のアクセス権が設定された財務データの集計を使って、この問題を説明しています。AIエージェントは文章を取り出すだけでなく、検索結果を組み合わせ、合計や傾向を計算し、次の処理へ渡します。だから権限は最後の回答だけでなく、検索計画や計算の途中にも効いていなければならない。データネイティブ型の核心は、門番を出口だけに立たせないことです。
AIのメモ帳も、新しい台帳になる
AIエージェントは仕事を続けるために、会話の流れ、作業の進捗、利用者の好み、過去に使った道具の結果を覚えます。一見すると便利なメモですが、「この顧客は重要顧客である」「この利用者はこの条件を好む」といった記憶は、それ自体が機密性を持つ情報です。元データを守っていても、AIのメモ帳だけが別の出張所にあれば、管理には穴が残ります。
さらに、複数のAIが協力する場面では、共有するメモが食い違うと仕事が崩れます。Databricksは、AIの作業状態と長期記憶をLakebaseに置く構成を紹介しています。LakebaseはDatabricks基盤内のマネージドPostgreSQLで、複数のエージェントが同じ状態を読み書きする場所として位置づけられています。誰が書き、誰が読み、その結論がどの情報から来たのかをつなげる設計です。
AIを金庫室のそばへ迎える
データネイティブ型は、台帳を出張所へ送り続ける代わりに、AIを金庫室のある建物へ迎えます。Databricksの構成では、Unity Catalogが権限やデータの来歴を扱い、AI Searchがその権限に従って情報を探し、MLflowがモデルや道具の動きを記録します。Unity AI GatewayがAIへの通信を制御し、Lakebaseが状態と記憶を支えます。
開発者向けページでは、Databricks Appsが認証とガバナンスを備えた管理型サーバーレス環境として紹介されています。Agent Bricksは、モデル、検索、道具を一つの環境で組み合わせ、記憶と状態をLakebaseへ保存します。比喩を離れて言えば、AIのためだけに別の建物、別の入館証、別の監視カメラを増やさず、既存の管理境界をAIにも広げる構想です。
便利なAIほど、居場所が大切になる
文章を要約するだけのAIなら、人が入力内容を選び、出力を読んで止められます。承認の振り分け、顧客対応、分析、案件管理まで動かすAIは、途中で何度もデータや道具に触れます。能力が高く、長く働くほど、どこに入り、何を覚え、どの規則に従うかの重みが増します。
Databricksの記事は自社プラットフォームを軸にした提案であり、すべての企業が同じ構成を選ぶと決まったわけではありません。それでも、このたとえが映す変化は明快です。AIエージェントを導入するとは、賢い回答窓口を置くことではなく、新しい働き手へ社内の鍵を渡すことです。鍵を渡すなら、頭の良さと同じくらい、その働き手の居場所が重要になります。