- OpenAIは、3,500人以上の社内ユーザーと600PB規模のデータを効率的に分析するため、カスタムAIデータエージェントを独自に構築
- 自然言語での質問だけで、テーブル探索、SQL実行、ノートブックおよびレポート公開まで、エンドツーエンドの分析ワークフローを自動処理
- 6層のコンテキスト（テーブル利用、人手による注釈、Codexベースのコード分析、組織知識、メモリ、ランタイムコンテキスト）を組み合わせて精度を確保
- 中間結果が誤っている場合は自ら原因を調査し、アプローチを修正する自己学習型クローズドループ構造で運用
- Evals APIベースの体系的な評価システムにより、品質回帰を早期検知し、既存のセキュリティ・権限モデルをそのまま継承して信頼性を維持
カスタムデータエージェントが必要な理由
- OpenAIのデータプラットフォームは、3,500人以上の社内ユーザー、600ペタバイト規模のデータ、7万件以上のデータセットを抱えており、正しいテーブルを見つけること自体が分析で最も時間のかかる作業
- 類似したテーブルが多く、ログアウトユーザーを含むかどうか、フィールドの重複など、テーブル間の違いを把握しにくい状況
- 正しいテーブルを選んでも、many-to-many結合、フィルタープッシュダウンの誤り、nullの未処理などで結果が無効になる可能性がある
- アナリストはSQLのデバッグではなく、メトリクス定義、仮説検証、データ駆動の意思決定に集中すべき
エージェントの動作方式
- GPT-5.2 を基盤に動作
- Slackエージェント、Webインターフェース、IDE、Codex CLI（MCP連携）、社内ChatGPTアプリなど、社員がすでに使っている環境からアクセス可能
- 複雑でオープンエンドな質問にも対応可能
- 質問の理解
- データ探索
- SQL実行
- 結果の分析と要約までエンドツーエンドで実行
- 例: NYCタクシーデータセットで、ピックアップ-ドロップオフZIPの組み合わせのうち、移動時間の変動性が最も大きい組み合わせを分析
- 固定スクリプトには従わず、自身の進行状況を評価しながら、中間結果が誤っている場合（例: 誤った結合やフィルターで0行になる）には原因を調査し、アプローチを修正して再試行
- 分析ワークフロー全体をカバー: データ発見、SQL実行、ノートブックとレポートの公開、社内知識の参照、Web検索、メモリベース学習
コンテキストの階層構造
-
Layer 1: テーブル利用（Table Usage）
- メタデータによるグラウンディング: スキーマメタデータ（カラム名、データ型）をSQL作成に活用し、テーブルリネージ（上流・下流テーブルの関係）でテーブル間の関係を把握
- クエリ推論: 過去のクエリを収集し、エージェントが自身のクエリ作成方法や一般的に結合されるテーブルの組み合わせを学習
-
Layer 2: 人手による注釈（Human Annotations）
- ドメインエキスパートがテーブルやカラムについてキュレーションされた説明を作成し、意図、セマンティクス、ビジネス文脈、既知の注意点など、スキーマや過去クエリからは推測しづらい情報を捉える
- メタデータだけではテーブルを区別しにくいため、生成方法と出所に関する理解が不可欠
-
Layer 3: Codexベースのコード分析（Codex Enrichment）
- テーブルのコードレベルの定義を導き出し、データの実際の内容を深く理解
- 値の一意性、テーブルデータの更新頻度、データ範囲（特定フィールドの除外有無、粒度）など、分析イベントに基づくニュアンスを提供
- SQLに加えて、Spark、Pythonなど多様なデータシステムでの利用文脈も把握可能
- 似て見えても本質的に異なるテーブルを見分けられる（例: 1st-party ChatGPTトラフィックのみを含むテーブルかどうか）
- このコンテキストは自動更新されるため、手動保守が不要
-
Layer 4: 組織知識（Institutional Knowledge）
- Slack、Google Docs、Notionなどから、ローンチ、障害事例、社内コードネーム、主要メトリクスの正式な定義と計算ロジックなどの社内コンテキストを収集
- 文書を収集・埋め込み・メタデータおよび権限とともに保存し、実行時にアクセス制御とキャッシュを処理する検索サービスを運用
-
Layer 5: メモリ（Memory）
- エージェントが修正を受けたり、データ質問のニュアンスを発見したりすると、それを保存して次の分析時により正確なベースラインから開始
- メモリの目的は、他の層では推論しにくい非自明な修正、フィルター、制約条件を保存・再利用すること
- 例: 特定の分析実験をフィルタリングする際、実験ゲートで定義された特定文字列との一致が必要だったが、メモリがないとあいまい文字列一致を試みてしまう誤りが発生
- 修正や学習内容を発見すると、エージェントがメモリ保存を促し、ユーザーが手動で作成・編集することも可能
- グローバルレベルと個人レベルでメモリ範囲を区別
-
Layer 6: ランタイムコンテキスト（Runtime Context）
- テーブルに関する事前コンテキストがない、または情報が古い場合は、データウェアハウスにライブクエリを発行してスキーマ検証とリアルタイムデータ把握を実施
- メタデータサービス、Airflow、Sparkなど、データプラットフォームの他システムとも通信し、ウェアハウス外のデータコンテキストを取得
-
日次オフラインパイプラインとRAG
- テーブル利用、人手による注釈、Codexベースの強化情報を単一の正規化表現へ集約する日次オフラインパイプラインを運用
- 強化されたコンテキストをOpenAI Embeddings APIで埋め込みに変換して保存し、クエリ時には**RAG（Retrieval-Augmented Generation）**で関連コンテキストのみを検索
- 数万件のテーブルにまたがるテーブル理解を高速かつスケーラブルに保ち、ランタイムレイテンシを予測可能で低く維持
チームメンバーのように考え、協働する設計
- ワンショット回答ではなく対話型の反復探索を支援し、ターン間で完全なコンテキストを維持するため、後続質問や方向転換の際に最初から説明し直す必要がない
- エージェントが誤った方向に進んでいる場合、ユーザーが分析の途中で介入してリダイレクトできる
- 指示が不明確な場合は明確化質問を先回りして提示し、応答がなければ妥当なデフォルト（例: 直近7日または30日）を適用して進行
- 同じ分析が繰り返されるパターンを観察した後、反復分析を再利用可能な**ワークフロー（instruction set）**としてパッケージ化
- 週次ビジネスレポート、テーブル検証などが例
- コンテキストとベストプラクティスを一度エンコードすることで、ユーザー間で一貫した結果を保証
信頼を保ちながら迅速に改善する評価体制
- 常に進化するエージェントであるため品質ドリフトが起こりやすく、体系的な評価がなければ回帰は見えないまま進行しうる
- OpenAI Evals API を基盤に、質問と回答のペアからなるキュレーション済みセットを構築し、各質問に手作業で作成した**「ゴールデン」SQLクエリ**を対応付け
- 自然言語の質問をクエリ生成エンドポイントに送り、生成されたSQLを実行したうえで、期待されるSQL結果と比較
- 単純な文字列一致ではなく、SQLと結果データの両方を比較し、Evalsグレーダーに投入して正確性と許容変動を反映した最終スコアと説明を算出
- この評価は、開発中に継続実行されるユニットテストとして機能し、本番環境のカナリアとして回帰を早期に捕捉
エージェントのセキュリティ
- OpenAIの既存のセキュリティおよびアクセス制御モデルに直接接続し、同一の権限とガードレールをインターフェース層に継承・適用
- すべてのアクセスはパススルー方式で行われ、ユーザーがすでに権限を持つテーブルのみクエリ可能で、権限がなければその旨を知らせるか代替データセットへフォールバック
- 透明性のため、推論過程を公開: 仮定と実行ステップを回答とともに要約し、実行したクエリの元結果へ直接リンクして、ユーザーが分析の全工程を検証できる
構築過程で得た教訓
-
Lesson 1: 少ないほどよい（Less is More）
- 初期にはツール一式をすべてエージェントに公開したが、機能重複による混乱が発生
- 人間が手動で呼び出す場合には有用な重複機能も、エージェントには曖昧さをもたらすため、特定のツール呼び出しを制限・統合して信頼性を向上
-
Lesson 2: 経路ではなく目標を導く（Guide the Goal, Not the Path）
- 非常に指示的なプロンプトは、かえって結果を悪化させた
- 質問ごとに詳細が異なるため、硬直した指示はエージェントを誤った経路へ導きやすく、高レベルのガイダンスを与え、実行経路の選択はGPT-5の推論に委ねるほうが優れていた
-
Lesson 3: 意味はコードの中にある（Meaning Lives in Code）
- スキーマとクエリ履歴はテーブルの形状や使われ方しか説明せず、本当の意味はテーブルを生成するコードに存在する
- パイプラインロジックは前提、鮮度保証、ビジネス上の意図を捉えており、これはSQLやメタデータには現れない
- Codexでコードベースをクロールしてデータセットの実際の構築方法を理解することで、ウェアハウスのシグナルだけでは不可能な**「何が入っているか」と「いつ利用できるか」**への正確な回答が可能になる
今後の方向性
- 曖昧な質問への対応力向上、より強力な検証による信頼性・正確性の改善、ワークフロー統合の深化を継続推進中
- 別個のツールではなく、人々がすでに働いているやり方に自然に溶け込む形を志向
- エージェントの推論、検証、自己修正の基盤技術の向上に伴って継続的に進化しており、
チームのミッションは、OpenAIのデータエコシステム全体に高速で信頼できるデータ分析を円滑に提供すること
1件のコメント
Hacker Newsの意見
信頼性と説明可能性が最大の問題だ
私たちは10年間、Veezooで自然言語分析を開発してきたが、単純なText-to-SQLアプローチはスケーラビリティに欠ける
CFOが売上を尋ねるとき、99%しか合っていない数字には意味がなく、CFOがSQLを直接検証することもできない
そこで私たちはKnowledge Graphという抽象化レイヤーを置き、AIが自然言語を意味ベースのクエリ言語に変換し、それを決定論的にSQLへコンパイルしている
逆にこの意味クエリを再び自然言語の説明へ変換し、ユーザーが結果が意図に合っているかを簡単に検証できるようにしている
ビジネスロジックはKnowledge Graphに存在し、コンパイラがすべてのクエリがこれに100%従うことを保証する
詳しい構造はVeezoo Architectureドキュメントにまとめられている
気になるのは、カーディナリティ爆発をどう管理しているのか、そして前のクエリ結果に依存する複数クエリのリクエストをどう処理しているのかだ
ある日付にどのクエリが使われ、どのように検証されたのかを追跡できるべきだ
（もちろんプロンプトもバージョン管理の対象だ）
最初の例が完全に非論理的で驚いた
これが人間のレビューを通過したのなら、おそらくAIが書いたのだろうし、そうだとするとシステムの信頼性に疑問が生じる
問題の画像リンク
デスクトップは正常なプロンプト、
モバイルは誤ったプロンプトだ
いくつものBIシステムを使ってきた経験からすると、この種のAIエージェントはまさに理想的なユースケースだと思う
BIでは本来、複数のレイヤーでエラーが発生する — クエリ自体が間違っているか、データの解釈の仕方が間違っている
この二つが合わさると、すでに「仮想の世界」に入り込んでいるようなものなので、むしろAIに第1段階を任せたほうがよい
OpenAIが信頼性の問題を解決したのかと期待したが、残念ながらそうではなかった
0段階: データの保存が間違っている
-1段階: モデリング自体の理解が間違っている
-2段階: ビジネスプロセスが最初から間違っている
だから私は「単一の信頼できる情報源」ではなく「単一の虚偽の情報源」と呼んでいる
信頼をスケールさせるのが最も難しい部分だ
私たちも似たようなものを作っているが、どれだけエージェントループが良くても、結局は人がキュレーションした標準指標(canonical metrics) が必要になる
そうでなければ、非技術職のユーザーが検証不能なSQLで危険な意思決定をしてしまう
私たちのアプローチは以下の通りだ
時間が経つと、ほとんどのクエリは標準指標を使うようになり、エージェントは単純なSQL生成器ではなく、意図→検証済み指標へのスマートルーターになる
「信頼を壊さずに素早く動く」セクションのゴールデンSQL評価システムも同じ洞察を含んでいる
関連する話はこのブログ記事にまとめた
答えに至る経路が複数あると、互いに異なる結果が出てしまう
LLMはしばしば
xyz_indexのような意味のない指標を作り出すが、ユーザーはもっともらしいと信じてそのまま使ってしまう私の考えでは、AIが開発者の仕事に与える本当の影響はデータとドキュメントの品質だ
企業のデータがどれほどよく整理されているかが、AI活用の効率を左右する
公開データはすでに枯渇しており、次の資源は社内ドキュメント、コードリポジトリ、データレイクだ
こうした基盤が整っている会社は、AIで新しいサービスを速く安く作り、維持できる
逆にドキュメントやコード管理がひどい会社では、AIはまともに機能しない
結局は競合に市場を奪われることになるだろう
だから今後転職活動をするときは、ドキュメント・データ・リポジトリ管理の水準を必ず尋ねるつもりだ
AmplitudeではModaという似たシステムを作った
数か月前にWadeがClaire Voにデモ動画を見せていたが、本当に素晴らしかった
私は毎日これでいろいろな質問を投げながら使っている
私たちも似た機能をDefinite.appで5分で提供している
SparkやSnowflakeは必要ない
データレイク、パイプライン、セマンティックレイヤー、データエージェントを一つのアプリとして提供している
実際にはエージェント自体よりもデータインフラ構築のほうがはるかに難しい
エージェントが単にSQLしか書けないなら限界が大きいが、私たちはインフラ自体を管理できるようにして大きな転換点を作った
本当に良い内容だ
ただ、結果がどのように計算されたのかを説明する部分が欠けているように思う
OpenAI社内向けなので、ユーザーがSQLを読めるという前提は問題ないが、非技術ユーザーにとっては設計上の大きな課題だ
データシステムを扱っていると、「答え」だけでなく「答えがどう導かれたのか」も同じくらい重要だとすぐに気づく
個人的にはKimiのIn-House Data Agentのほうがもっと興味深い
データ問題は技術問題ではなく組織問題だ
私の経験では、データ問題の原因は「間違った技術選定」ではなくガバナンスとオーナーシップの意思決定にある
結局、すべてはConwayの法則に行き着く