データ分析AIの精度は、モデルの賢さだけでは決まりません。OpenAIが社内向けデータエージェントを構築した事例では、表のスキーマだけでなく、コード、組織知、記憶、実データまで含む6層の文脈が中核に置かれています。
これは「AIにSQLを書かせる」話ではありません。大量の似たデータから意味を取り違えず、検証可能な答えを出すための設計論です。
600PB・7万データセットで起きる問題
OpenAIの公式記事によると、同社のデータ基盤は3,500人超の社内利用者、600PB超のデータ、7万のデータセットを支えています。この規模では、SQLを書く前に「どの表を使うべきか」を見つけるだけでも大仕事です。
しかも、列名が似ていても意味は同じとは限りません。ログアウト利用者を含むか、更新頻度はどれくらいか、どのフィルターが必須か。こうした差を見落とすと、SQLが正常に動いても結論は間違います。多対多結合、NULLの扱い、フィルター位置など、静かに結果を壊す要因もあります。
つまり本当の課題は、構文生成よりデータの意味を正しく復元することです。
精度を支える6層の文脈
OpenAIの構成は、文脈を大きく次の6層に整理できます。
- 表の利用情報：スキーマ、データ型、リネージュ、過去のクエリから、表同士の関係や典型的な結合を把握します。
- 人の注釈：担当者が、列の意図、業務上の意味、既知の注意点を補います。
- コードによる補強：表を生成するコードを調べ、対象範囲、粒度、更新条件、除外ルールを読み取ります。
- 組織知：Slack、Google Docs、Notionなどから、指標の正式定義、障害、社内用語を取得します。
- 記憶：過去の訂正や、推測しにくいフィルター条件を保存し、同じ失敗の再発を防ぎます。
- 実行時の確認：情報がない、または古い場合は、データウェアハウスへ問い合わせて現状を確かめます。
重要なのは、これらを全部プロンプトへ詰め込まないことです。OpenAIは日次のオフライン処理で情報を正規化し、埋め込みに変換しておきます。実行時はRAG（検索拡張生成）で関連部分だけを取得し、必要ならライブクエリで確認します。
「意味はスキーマではなくコードに宿る」
この事例で特に実務的なのが、公式記事にある「意味はコードに宿る」という教訓です。
スキーマは表の形を示し、過去のSQLは使われ方を示します。しかし、データがどう作られたかは生成コードにあります。たとえば、集計対象の除外条件、更新のタイミング、重複排除の方法は、列名だけでは分かりません。
車載開発にたとえるなら、信号名一覧だけを見てもECUの振る舞いは説明できないのと同じです。仕様、生成ロジック、変更履歴までそろって、初めて意味が固定されます。
権限と評価を文脈の外に置かない
文脈を豊かにすると、同時に漏えいリスクも増えます。OpenAIのエージェントは既存のアクセス制御を引き継ぎ、利用者が元から閲覧できる表だけを問い合わせる「パススルー」方式です。文書の検索でも、メタデータと権限を扱う仕組みが実行時の取得を制御します。
品質評価では、重要な質問と人が作成した正解SQLを組にし、生成SQLの文字列だけでなく、実行結果も比較します。書き方が違っても結果が正しいSQLを落とさないためです。これはデータエージェント版の回帰テストです。
なお、公式ドキュメントでは従来のEvalsプラットフォームは2026年10月31日に読み取り専用化、11月30日に終了予定とされています。新規設計では特定サービス名に固定せず、代表質問・正解結果・継続実行という評価資産を移植可能に保つのが安全です。
導入時に先に作るべき4つ
- 意味の台帳：主要指標、利用禁止の表、必須フィルターを管理します。
- 権限付き検索：検索結果にも元データと同じ認可を適用します。
- 訂正可能な記憶：誰が保存し、誰が編集でき、どの範囲で共有するかを決めます。
- 結果ベースの回帰テスト：SQLの見た目ではなく、期待結果と業務上の意味を検証します。
モデル選定はその後でも遅くありません。先に文脈と評価の配線を作れば、モデルを更新しても知識と品質基準を引き継げます。
まとめ
データエージェントの信頼性は、プロンプトの巧さより意味を何層で支えるかで決まります。
- スキーマだけでなく、コードと人の知識を使う
- 記憶は保存するだけでなく、範囲と編集権限を設計する
- 古い文脈は実データで確かめる
- 生成物ではなく実行結果を継続評価する
AIにデータを渡す前に、データの意味を説明できる仕組みを作る。遠回りに見えますが、これが分析AIをPoCで終わらせない最短ルートです。