11月4日、MIT Technology Reviewが「Securing the agentic enterprise with data lineage」と題した記事を公開した。AIエージェントが多段階で自律的に動作するエンタープライズ環境において、データリネージ（data lineage）がセキュリティとガバナンスの核心になるという考え方を詳しく紹介している。

なお、本記事はMIT Technology Reviewのカスタムコンテンツ部門「Insights」が、データセキュリティ企業Cyberhavenとの提携のもとで制作したスポンサードコンテンツである。 内容の読み方としては、技術的な方向性を示すものとして参考にしつつ、ベンダーの立場からの主張である点は意識しておく必要がある。

「誰もチェックしなかった」が生む惨事

記事はまず、現場で起こりうる具体的なシナリオを提示する。

営業担当者がAIエージェントに顧客向け価格情報を問い合わせる。エージェントは複数のソースからデータを収集する——制限付きの価格システム、社内のやり取り、過去の見積もりアーカイブ。エージェントにはその出力が正確に見えるため、第2のエージェントがそのデータをもとに提案書を自動作成する。人間はどちらのハンドオフも確認しない。

後になって、その提案書に未承認の機密情報が含まれていることが発覚する。しかし、問題のあるデータがどこでワークフローに入り込み、どのようにシステム・ファイル・エージェント間を伝播したのかを誰も追跡できない。

このシナリオが示すのは、AIセキュリティが「ツールの問題」ではなく、「データの可視性の問題」であるという点だ。

従来のセキュリティアーキテクチャが通用しない理由

エンタープライズでのAIエージェント活用が進む中で、管理対象のデータの性質が根本的に変わっている。

従来のセキュリティアプローチは、アプリケーション・システム・ネットワーク・エンドポイントを境界として守ることを前提に設計されている。しかし、エージェントが介在するワークフローでは、データは継続的に取り込まれ、コピーされ、要約され、変換され、再利用され、新しい形で再配布される。静的なファイルの管理ではなく、動き続け断片化するデータの管理が求められる。

こうした環境では、境界型のセキュリティモデルは有効に機能しない。問題の本質は「誰がシステムにアクセスしたか」ではなく、「データがどこを経由して、どう変容したか」を問う観点への転換にある。

解決の鍵は「データリネージ」

記事が提唱するのがデータリネージの確立だ。データリネージとは、データがどこで生まれ、どう変換され、どこに流れたかを一貫して追跡・記録する手法を指す。サプライチェーン管理やデータウェアハウスの世界では以前から使われてきた概念だが、AIエージェントの文脈に応用することで、ガバナンスの基盤として機能するという主張だ。

記事によれば、データリネージを確立することで、人間・エージェント・両者が混在するハイブリッドなワークフロー全体にわたって、ガバナンス・説明責任・信頼性を管理できるようになる。NISTのAIリスク管理フレームワーク（AI RMF）が求める説明可能性や監査可能性との親和性も高い。

※編集部の考察：EU AI Actも第13条でハイリスクAIシステムに対する透明性・トレーサビリティの確保を義務付けており、データリネージの確立はEU市場への対応という観点でも実践的な意義を持つ。日本企業においても、2024年に改定されたAI事業者ガイドライン（内閣府）が「AIの判断根拠の説明可能性」を重視する方向へシフトしており、同様の流れは無視できない。

データリネージの実装標準と既存エコシステム

※編集部の考察：記事はCyberhavenのソリューションを前提に議論を展開しているが、データリネージ自体はオープンな標準や既存OSSエコシステムでも対応が進んでいる点は補足しておきたい。

代表的なものとして、OpenLineageはLinux Foundation傘下のオープン標準規格であり、Airflow・Spark・dbtなど主要データパイプラインツールとの統合が進んでいる。メタデータ管理・データカタログ領域ではApache AtlasがHadoopエコシステムを中心に広く使われており、血統（lineage）グラフの可視化機能を持つ。クラウドネイティブな文脈では、各クラウドベンダーもデータリネージ機能を提供している（Google Cloud Dataplex、AWS Glue Data Catalogなど）。

Cyberhavenのアプローチは、これらのデータパイプライン層での追跡にとどまらず、エンドポイント上のファイル操作・アプリケーション間のデータ移動まで含めたリネージを取得する点を差別化軸としている。エージェントワークフロー特有の「誰がどのツールを呼び出し、どのデータを渡したか」という追跡ニーズには、既存のOSSだけでは対応が難しい部分もあり、ここに商用ソリューションの参入余地がある。

技術選定における論点

データリネージをエージェント環境に適用しようとする際、実装上の論点はいくつかある。

まず粒度の問題だ。エージェントが複数のAPIを連鎖的に呼び出す場合、どの単位でリネージを記録するかによって、後の監査・インシデント対応の精度が変わる。ステップ単位か、トークン単位か、あるいはアーティファクト（生成物）単位か、設計判断が問われる。

次にパフォーマンスオーバーヘッドだ。リネージの記録はメタデータの継続的な書き込みを伴うため、低レイテンシが求められるリアルタイムエージェントワークフローでは設計上のトレードオフになりうる。

さらに標準化の欠如という現実もある。現時点でエージェントワークフロー向けのリネージ標準は成熟しておらず、各ベンダーが独自の実装を持っている状態だ。OpenLineageコミュニティでもエージェント対応の議論は始まっているが、仕様の安定には時間を要するとみられる。

詳細はSecuring the agentic enterprise with data lineageを参照していただきたい。