新智元（シンジーユアン）発
編集：peter 東
【新智元リード】2026 年初頭、多くの企業がまだデータアナリストに手作業で SQL を書かせていた頃、OpenAI 内部で明らかになった、自律的思考・推論、さらには自己進化さえ可能にするデータ分析エージェントが、データ検索にかかる時間を「数日単位」から「数分単位」へと劇的に短縮した。
なぜデータチームはいつも「同じ過ち」を繰り返すのか。
その答えは、計算リソースの不足ではなく、テーブルが多すぎ、定義が多すぎ、経験が散在しすぎていることにある。
同じ「アクティブユーザー」という用語でも、テーブルによって集計基準が全く異なることがある。たとえ正しいテーブルを選べても、結果を出すには 100 行以上の SQL が必要で、結合条件を 1 つでも間違えればすべてが水の泡となる。
これに対し、OpenAI 内部ではより過激な取り組みが行われた。Codex を中核としたデータインテリジェントエージェントに、「テーブル検索→理解→SQL 作成→結果検証」という一連のプロセスを任せるというのだ。6 階層のコンテキストアーキテクチャを採用し、データセマンティクスを補完し、組織知識を接続し、経験的記憶を蓄積させることで、エンジニアが単純作業をする代わりに「質問するだけ」で済むようにしたのである。
データ検索でもはや手作業のテーブル確認は不要に
「類似した構造のテーブルが大量にあり、その違いを理解し、どれを使うべきか特定するのに膨大な時間を費やしている」。ある OpenAI エンジニアの日常的な愚痴は、データワーカー全員の共通の悩みを如実に表している。
OpenAI 内部のデータプラットフォームには600PBものデータが存在し、それは7 万ものデータセットに分散している。想像してみてほしい。OpenAI のエンジニアが ChatGPT のユーザー増加を分析しようとした際、数十もの類似したユーザー用テーブルが目の前に現れる。それぞれが「ユーザーアクティビティ」を記録していると主張しながら、その定義はバラバラなのだ。
間違ったテーブルを選んでしまえば、数日かけて行った努力がすべて無駄になる。さらに深刻なのは、誤ったデータに基づいて重要な意思決定を下してしまう可能性さえあることだ。
さらに厄介なことに、たとえ正しいテーブルを選べたとしても、正しい結果を生成するのは容易ではない。
下の図に示されているのは180 行以上にも及ぶ SQL 文だ。これはまさに乗り越えがたい大山のようであり、複雑なテーブル結合や集計処理において、わずかなエラー一つで分析全体が無効になってしまう。
しかし現在、自律学習能力を備え Codex が駆動するインテリジェントエージェントの登場により、エンジニアはもはや 100 行以上もの SQL クエリ文を書く必要がなくなった。質問するだけで、データの海から必要な情報を見つけ出せるようになったのだ。例えば下の図では、2 つの時点におけるアクティブユーザー数を比較するよう求めている。
6 階層アーキテクチャからなる「データブレイン」
自然言語を SQL 文に変換するツール自体は数多く存在する。しかし、OpenAI 内部で使用されているデータインテリジェントエージェントの核心的な革新性は、その多層的なコンテキストアーキテクチャにある。
最下層の基礎メタデータには、テーブル構造や列の型など基礎的な情報が含まれており、インテリジェントエージェントに対してデータグラフの骨格を提供する。
その一つ上の階層は人手によるアノテーションだ。これはドメインの専門家が丹念に作成したテーブルや列の説明であり、スキーマや過去のクエリからは容易に推測できない意図、セマンティクス、ビジネス上の意味、そして既知の注意点を捉えている。この階層は、インテリジェントエージェントに対する各テーブルの基礎トレーニングに相当する。
さらにその上のCodex による強化レイヤーでは、テーブルのコードレベルでの定義を推論することで、インテリジェントエージェントがデータの実態をより深く理解できるようにする。このレイヤーは、値の一意性、テーブルデータの更新頻度、データ範囲などの重要情報を提供する。このレイヤーの導入により、インテリジェントエージェントは、構築方法や更新プロセスにおける各テーブル間の差異を理解できるようになった。
さらにその上の組織知識レイヤーでは、インテリジェントエージェントが Slack、Google Docs、Notion などにアクセスし、製品のリリース、信頼性に関する事象、内部コードネームやツール、そして主要指標の正式な定義や計算ロジックといった、企業の重要な背景情報を取得できる。
外部テキストを通じて取得した背景情報があるおかげで、インテリジェントエージェントは初歩的なミスを犯さずに済む。
例えば、ユーザーから「なぜ 12 月のコネクタ使用量が急激に減少したのか」と問われた際、インテリジェントエージェントは単に数字の減少を報告するだけでなく、組織知識を通じて、これが測定上およびログ記録上の問題によるものであり、実際の使用量の崩壊ではないことを発見した。これは ChatGPT 5.1 のリリースに伴うデータ収集方法の変更に関連していたのだ。
そして最も重要なのが 5 番目のレイヤー、学習進化だ。これによりインテリジェントエージェントは永続的な記憶を持つことができる。ユーザーからの修正を受けたり、データ問題の微妙なニュアンスを発見したりした際、その経験を保存し、次回以降に活用できる。記憶はユーザーが手動で作成・編集することも可能だ。グローバルに適用されるものもあれば、特定のユーザーにのみ固有のものもある。
最上層のランタイムコンテキストにより、インテリジェントエージェントは、既存のコンテキストがない場合や、既存の情報が古くなっている場合に、データウェアハウスへ直接クエリを実行してテーブルをチェック・照会することができる。さらに、より広範なデータコンテキストを取得するために、他のデータプラットフォームシステム（メタデータサービス、Airflow、Spark など）と通信することも可能だ。
オフライン検索とオンラインクエリの動的切り替え
では、上記の 6 階層システムは、どのように連携して機能しているのだろうか。
具体的には、オフライン処理とオンライン処理の 2 段階に分けられる。
毎日未明、インテリジェントエージェントは、前日の何千何万ものデータテーブルの実際の使用法と呼び出しの軌跡を体系的にスキャンする。データ専門家たちが残した注釈や洞察を汲み取り、Codex を呼び出してコード深層のロジックを解釈し、テーブルの背後にあるより豊かなビジネスセマンティクスを導き出す。こうして散在する「知識の断片」がすべて融合され、統一され標準化された「知識グラフ」へと変貌する。
その後、OpenAI の埋め込みモデルを通じて、これらは一連のベクトル埋め込みへと変換・圧縮され、高速検索用データベースに格納される。これで、AI インテリジェントエージェントのための、すぐに使用可能な「データの記憶宮殿」が完成する。
ユーザーから質問が届くと、インテリジェントエージェントは人間の分析担当者のように、メタデータという名の広大な海に飛び込み、時間のかかる手作業のサルベージを行う必要はもはやない。代わりに検索拡張生成（RAG）技術を通じて、現在の質問と最も関連性の高いデータテーブルを正確に特定・抽出する。このプロセスは高速で拡張性が高く、遅延も極めて小さい。
一方、最新のデータを必要とするリクエストに対しては、インテリジェントエージェントはリアルタイムクエリチャネルを同時に起動し、データウェアハウスへ直接クエリを発行する。これにより、ランタイムコンテキストの即時性を実現しつつ、オフライン知識との深い統合も可能になる。こうして複雑なビジネス上の問いは、オフライン記憶による「稲妻のような高速検索」と、リアルタイムデータによる「精密誘導」との連携により、数秒で得られる明確な洞察へと姿を変える。
静的なツールから動的なチームメイトへのパラダイムシフト
このインテリジェントエージェントが最も驚くべき点は、その技術的な複雑さではなく、いかにして日常のワークフローに溶け込み、真の意味での「チームメイト」となり得るかという点にある。従来の「一問一答」型のツールとは異なり、OpenAI 内部で使用されているデータ分析インテリジェントエージェントは、「共に推論できるチームメイト」として設計されている。対話的であり常にオンラインで、素早い回答の処理から反復的な探索までをこなす。
このようなシナリオを想像してほしい。プロダクトマネージャーからの質問が不明確、あるいは不完全な場合、インテリジェントエージェントは自ら進んで明確化のための質問を投げかける。もし応答がなければ、妥当なデフォルト値を適用して作業を進める。例えば、ユーザーが日付範囲を指定せずにビジネスの成長について尋ねた場合、直近の 7 日間または 30 日間と仮定するかもしれない。これにより、インテリジェントエージェントは返信を続けつつ、ユーザーと協力してより正確な結果を導き出すことができる。
また、絶えず進化を続けるインテリジェントエージェントが学習の過程で道を誤らないよう、OpenAI チームはEvals APIを利用して、厳格な監視役をインテリジェントエージェントに配備した。
Evals APIは、すべての重要な質問に対して手動作成された「ゴールドスタンダード」となるクエリ文を用意し、インテリジェントエージェントの成果を継続的に監視・評価する。
これらの評価は SQL の構文正確性をチェックするだけでなく、結果データの精度も比較する。インテリジェントエージェントが「道を誤った」場合、システムは即座にアラートを発令し、ユーザーに影響が及ぶ前に問題を発見・修正することを保証する。
データセキュリティの面では、このインテリジェントエージェントはユーザーが既にアクセス権限を持つテーブルのみをクエリできるよう規定されている。アクセス権限が欠如している場合は、その旨をマークするか、ユーザーに権限が与えられている代替データセットにフォールバックする。
さらに、データ分析プロセスの透明性を確保するため、インテリジェントエージェントは各回答の隣に、その仮定と実行情報を要約して表示し、推論プロセスを明らかにする。クエリが実行されると、基盤となる結果への直接リンクを提供し、ユーザーが元データを検査し、分析の各ステップを検証できるようにする。
データ分析インテリジェントエージェントをどう構築するか
前述の OpenAI 製データ分析インテリジェントエージェントはオープンソースされていないが、もし同様のものを自作したい場合のために、OpenAI のエンジニアたちが実際に直面した落とし穴についても言及されている。
当初、インテリジェントエージェントは完全なデータセットにアクセス可能だったが、すぐに機能の重複するデータテーブルの海で道に迷うことになった。曖昧さを減らし信頼性を高めるため、開発者はインテリジェントエージェントがアクセスできるデータテーブルを制限せざるを得なかった。これにより曖昧さが減少し、クエリの信頼性が向上した。
もう一つの落とし穴は、開発者によって与えられた過度に規格化されたシステムプロンプトに起因する。多くの質問は類似した分析形状を共有しているものの、詳細の変化は大きく、硬直した指示は逆効果になり得ることがわかった。実際の使用効果に焦点を当てると、どのように実現するかをシステムレベルのプロンプトではなく、インテリジェントエージェント自身に委ねることで、より堅牢で良い結果を生み出すことができた。
そして最も重要だったのは、専門家によるデータテーブルのアノテーションに比べ、データの真の意味はコードの中に存在すると気づいたことだ。クエリの履歴は、SQL やメタデータには現れなかった仮定やビジネス上の意図を捉え、テーブルの形状と使用法をより正確に描写する。Codex を使用してコードベースをクロールすることで、インテリジェントエージェントはデータセットが実際にどのように構築されているかを理解し、各テーブルに実際に何が含まれているかをより良く推論できる。データウェアハウスからの情報のみに頼るのに比べ、データを構築したコードの方が、「このテーブルには何が入っているのか」「いつそれを使えるのか」という問いにより正確に答えることができる。
企業のデータ環境が複雑化するにつれ、OpenAI のデータインテリジェントエージェントに似たツールが、将来の企業データ分析の標準装備となり、業界全体をより効率的で、よりインテリジェントなデータ駆動型意思決定のパラダイムへと押し上げるだろう。
これらのインテリジェントエージェントの目標は、データアナリストを代替することではなく、その能力を拡張することにある。データアナリストを煩雑なクエリの作成やデバッグから解放し、より高次元である指標の定義、仮説の検証、そしてデータ駆動型の意思決定策定に集中させることだ。
参考資料：