技術要約：データフロー制御 (Data Flow Control: DFC)

1. 問題提起

本論文は、データベースシステムと相互作用するAIエージェントおよびデータアナリストの安全性における決定的な欠落（ギャップ）に対処している。近年の研究は、AIが生成したSQLの正確性（すなわち、クエリがユーザーの意図を反映しているか？）の向上に焦点を当てているが、安全性については軽視されがちである。クエリは意味論的に正しくても、データの組み合わせ方、変換方法、およびリリースに関する規制、プライバシー、またはビジネス上の制約に違反する場合がある。

現在の安全メカニズムは、主に以下の3つの理由から不十分である：

1. アクセス制御 vs データフロー： 従来のアクセス制御は「誰が」データにアクセスできるかを制御するものであり、クエリ実行中にデータが「どのように」流れ、結合されるかを制御するものではない。
2. 整合性制約： これらはデータベースの静的な状態を管理するものであり、中間的なクエリの状態や派生（デリベーション）を管理するものではない。
3. プロベナンス（由来）のオーバーヘッド： プロベナンス・システムは遡及的に派生を監査できるが、完全なプロベナンス多項式を実体化するには、20%から10,000倍という極めて高いパフォーマンスコストが発生するため、リアルタイムの強制適用には適していない。
4. 確率的アプローチ： プロンプトや事後検証を通じてLLMに安全性をチェックさせる手法は、本質的に確率的であり、形式的な保証を欠き、ポリシーの複雑さやデータの規模が増大するにつれて精度が低下する。

著者らは、データの安全性は根本的にインフラストラクチャの問題であり、DBMS内部において宣言的なポリシーをタプルレベルのデータフローに対して強制する決定論的なメカニズムを必要としていると主張している。

2. 手法

本論文では、データフローに対するポリシー強制を宣言的に指定し、保証するためのフレームワークであるデータフロー制御 (DFC) を導入する。その手法は、以下の3つのコアコンポーネントで構成される。

2.1 データ安全性の定式化

著者らは、データ安全性をプロベナンス単項式（monomials）に対する集計述語として定式化している。

• オプティマイザ不変性： 物理的なクエリプランがプロベナンス多項式の構造に影響を与えることが主要な課題である。ポリシーをオプティマイザ不変にするため、DFCはポリシーを多項式構造そのものではなく、各出力タプル $o$ に対するプロベナンス単項式のバッグ（bag of provenance monomials） $M(o)$ という正規化された表現に対して定義する。
• 半環（Semiring）による集計： 本システムは、これらの単項式に対して完全な多項式を実体化することなく、効率的に集計を行うために、半環の性質（例：自然数、集合）を活用する。

2.2 PGN ポリシー言語

著者らは、DFCポリシーを表現するための宣言的言語であるPGN (Provenance Guard Notation) を提案している。PGNを使用することで、ユーザーは以下を定義できる：

• ソース ($S$)： ポリシーが適用されるリレーション。
• 制約 ($B$)： ソースリレーションの属性およびプロベナンス単項式に対するブール式（例：「最大コスト < 100」または「ユニークユーザー数 > 1」）。
• 解決策 ($F$)： 違反時のアクション。例えば、REMOVE（タプルを削除）、KILL（クエリを中断）、またはデータの変換やセマンティックな判断のためのLLM呼び出しを行うカスタムユーザー定義関数（UDF）など。
• 拡張機能： システムカタログや他のテーブルを参照する外部次元、シンク（挿入/更新のターゲットテーブル）、必須ソース（グラウンディング）、およびリレーションレベルの解決策をサポートする。

2.3 パサント (Passant) エンジン

Passant は、完全なプロベナンスを実体化することなくPGNポリシーを強制する、ポータブルなクエリ書き換えレイヤーである。これは主に2つの書き換え戦略を採用している。

1. 部分プッシュ (Partial-Push)： ポリシーの集計計算を結合（Join）の下方へプッシュするが、入力属性にアクセスするために依然としてプロベナンス多項式を計算する必要がある。
2. フルプッシュ (Full-Push)： 主要な貢献。ベースとなるクエリを、半環の注釈（annotation）を用いて、ベースクエリの実行に直接ポリシー集計計算を「相乗り（piggyback）」させる形に書き換える。
   • リーフ注釈 (Leaf Annotation)： 入力リレーションに半環の要素（例：カウントのための1、合計のための属性値）を注釈として付与する。
   • 演算ルール： 結合は注釈を乗算し、集計はそれらを加算する。
   • 結果： ポリシー制約は、テーブルの再スキャンやリネージデータとの結合といった「プロベナンス税」を回避しながら、通常のクエリ実行中にインラインで評価される。

本システムは、外部結合（集合注釈による）、ユニオン、および自己結合（対称性最適化による）を含むSQL-92構文を処理する。

3. 主な貢献

1. 定式化： プロベナンスを、監査ツールから、クエリオプティマイザに対して不変なレコードレベルのプロベナンスに対する制約として定義することで、能動的なポリシー強制メカニズムへと昇華させた。
2. PGN 言語： システムのコンテキスト、ユーザー権限、およびリレーショナルメタデータを参照できる、複雑な制約（プライバシー、グラウンディング、変換制限）を表現可能な宣言的言語を設計した。
3. Passant エンジンとアルゴリズム：
   • 既存のプロベナンスシステムを用いたナイーブな事後処理ベースライン。
   • 中間状態を大幅に削減するPartial-PushおよびFull-Push書き換えアルゴリズム。
   • テンプレート化されたポリシー（複数の閾値を単一の支配的な制約に集約する）および対称的な自己結合（階乗的な複雑さを線形に削減する）のための最適化。
4. 実証的評価： 多様なデータベースエンジンにおいて、DFCの強制がほぼゼロのオーバーヘッドで達成可能であることを示した。

4. 結果

著者らは、DuckDB, Umbra, PostgreSQL, DataFusion, SQLServer の5つのDBMSエンジンを用いてPassantを評価した。

• パフォーマンス： TPC-Hクエリにおいて、Full-Pushはほとんどのケースで**≈0%のオーバーヘッド**を達成し、驚くべきことに、Umbraエンジンではベースクエリ（ポリシーなし）よりも優れた性能を示した。
• ベースラインとの比較：
  • 論理的/物理的プロベナンス： これらの手法は、プロベナンスデータの実体化と結合のコストにより、膨大な減速（Logicalは2,000%〜75,000%、Physicalは300%〜700%）を招いた。
  • LLMチェック： 13個のTPC-Hクエリと1〜32個のポリシーを用いた比較において、DFCはLLMベースのチェックよりも数桁高速であり、かつLLMは形式的な保証を欠いている。
• スケーラビリティ：
  • ポリシー数： テンプレート最適化（制約の集約）により、システムはポリシー数に対して劣線形にスケールする。
  • 自己結合： 対称的なポリシー最適化により、多くの自己結合を含むクエリにおいて、強制の複雑さが階乗（$O(n!)$）から線形（$O(n)$）へと削減された。
• 応用： ビジネスプロセス・ステートマシンの強制タスクにおいて、Full-PushはLLMベースのアプローチよりも2桁高速であり、かつ決定論的な正当性を提供した。

5. 意義と主張

本論文は、データフロー制御が、データの安全性を「プロンプトや事後チェック」からデータインフラストラクチャへと移行させるための第一歩であると主張している。

• デフォルトでの安全性： ほぼゼロのオーバーヘッドを実現することで、DFCはすべてのクエリに対して安全ポリシーを適用することを可能にし、安全性を「オプションの、高価なアドオン」ではなく「自然な選択」としている。
• 決定論的な保証： 確率的なLLMガードとは異なり、DFCは、データフローが規制やビジネス上の制約を遵守していることを示す、形式的で決定論的な保証を提供する。
• インフラへのシフト： 本研究は、安全性をアプリケーションやエージェントに委ねるのではなく、データベースエンジン自体によって強制すべきであり、単に「誰がアクセスするか」だけでなく、「データがどのように変換され、組み合わされるか」を管理すべきであると論じている。

著者らは、現在のプロトタイプは単調（monotonic）なSQL-92クエリに焦点を当てているが、より幅広い適用可能性のために、非単調な構成（否定、再帰）へのDFCの拡張が、次のステップとして必要であると述べている。本システムはオープンソースで公開されている。