データベーススキーマなしで企業データを生成するSTSの仕組み
導入
企業向けAIエージェントの訓練や評価には、単純な質問と回答だけでなく、実際の業務に近いデータ、権限、状態遷移、複数段階のワークフローが必要です。しかし、企業システムや業務記録は、プライバシー、法規制、商業上の理由から研究目的で利用しにくい場合があります。データベースのスキーマさえ共有されないケースもあります。
そこで合成データが注目されますが、従来手法には弱点があります。表形式の合成器は統計的な分布を再現できても、エンティティ間の関係や業務ルールを破るレコードを作る可能性があります。一方、手順ベースの生成器は有効なデータを作りやすいものの、領域ごとの手作業が必要で、現実の分布を再現しにくい傾向があります。
「Synthesis Through Simulation(STS)」は、この問題をデータベースへの直接アクセスではなく、シミュレーションされた企業環境との相互作用として捉え直します。
STSの考え方
STSでは、LLMエージェントが企業オブジェクトの作成、取得、更新などを行うAPIを呼び出します。APIにはポリシーや状態に応じた制約が組み込まれており、許可された操作だけが環境の状態を変更します。つまり、モデルが自由に表を埋めるのではなく、業務システムが認める操作を積み重ねてデータを生成します。
この設計には次の特徴があります。
- 有効性を環境が担保する。 関係性、権限、状態遷移などの検証を、生成後の後処理ではなく操作時に行います。
- 分布の生成をエージェントに任せる。 どのAPIを、どの順番で、どのように組み合わせるかをエージェントが決めます。
- スキーマへの依存を減らす。 Generalist Populatorはデータベース構造を直接参照せず、APIとの相互作用やフィードバックから操作可能な範囲を把握します。
- 領域ごとの再実装を抑える。 業務固有の制約は環境に置き、生成エージェントは複数領域で共通利用できる設計です。
評価結果と読み取れること
論文では、10種類のシミュレーション環境でGeneralist Populatorを評価しています。データベーススキーマにアクセスしない条件で、平均限界保真度0.88、全環境で制約充足率100%を報告しました。前者は個々の項目の分布が目標にどれだけ近いか、後者は環境の有効性ルールを満たしているかを示す指標です。
比較結果も重要です。統計的な合成器は、必要な初期データが得られないため10環境のうち7環境で適用できませんでした。また、スキーマ情報を与えられたエージェントでも、航空業界の環境では軌跡の82%に失敗しました。複数の処理が強く結び付いたワークフローでは、項目やテーブルの構造を知るだけでは不十分で、正しい順序と状態依存のルールを理解する必要があります。
意義と今後の課題
STSは、企業データ合成を静的な表の生成から、業務システムのシミュレーションへと移す提案です。生成されるのはレコードだけでなく、ツール呼び出しに近い相互作用の軌跡でもあるため、企業エージェントの訓練・評価環境として利用できる可能性があります。
ただし、保証されるのはあくまでシミュレーション環境内の有効性です。環境が重要な業務ルールを欠いていたり、実際とは異なる操作分布を持っていたりすれば、内部的には正しくても本番業務の代理としては不十分です。複雑な操作の探索コスト、APIのフィードバック設計、限界分布を超えた関係性の評価は、今後も検証が必要です。
研究チームはフレームワーク、10環境、生成データを公開しています。STSは、企業データを無制限に模倣するのではなく、制御可能な環境との相互作用を通じてエージェントの能力を研究する方向性を示しています。
コメント
ログイン状態を確認中…
コメントを読み込み中…