なぜOpenAIの社員はSQLを書かないのか？ 「データの迷子」をなくす6つのメタデータ戦略：コンテキストレイヤーの整備が鍵に
OpenAIは、自社プラットフォーム上で探索とリーズニングを実行する社内用のAIデータエージェントを構築し、運用している。その内容は。
OpenAIは2026年1月、同社の独自プラットフォーム上で「リーズニング」（人間のような論理的思考プロセスで問題を解決する人工知能＜AI＞の能力）を実行する社内用のカスタムAIデータエージェントを構築し、運用していることを明らかにした。その詳細は。
カスタムAIデータエージェントの中身は？
編集部のお薦め記事
OpenAIのカスタムAIデータエージェントは、大規模言語モデル（LLM）「GPT-5.2」を中核モデルとして搭載し、Codex（CLI を含む）などのツール群と組み合わせて構築されている。
このカスタムAIデータエージェントの構築、運用には、OpenAIが提供している以下のツールが使われている。
- OpenAI Codex CLI
- 自然言語からソースコードを生成するAIモデル「OpenAI Codex」のコマンドラインインタフェース（CLI）
- OpenAI Evals API
- AIモデルの性能を評価するためのフレームワーク「OpenAI Evals」のAPI
- Embeddings API
- テキストを数値ベクトルに変換する「Embeddings」のAPI
本カスタムAIデータエージェントは、エンジニアリング、データサイエンス、GTM（市場進出戦略）、財務、研究の各部門が、データに関する問題を解決するために活用している。本カスタムAIデータエージェントを使うことで、質問からインサイトを得るまでの時間は数日から数分に短縮されたという。
カスタムAIデータエージェントが必要になった理由
OpenAIのデータプラットフォームは、エンジニアリング、製品、研究の各部門に属する3500人以上の社内ユーザーにサービスを提供しており、7万以上のデータセットと600ペタバイト（PB）を超えるデータを扱っている。
これだけの規模になると、適切なテーブルを見つけるだけでも大変な労力を要する。似たようなテーブルが多数存在するため、ユーザーはどのテーブルを使用すべきか、どのフィールドが重複しているかを見極めるのに多大な時間を費やしていた。さらに、正しいテーブルを選択できても、正しい結果を導き出すことは容易ではない。そこで、従業員がSQLのデバッグに時間を費やすのではなく、指標の定義や過程の検証、データ主導の意思決定に集中できる環境が必要となったのだ。
カスタムAIデータエージェントの仕組みと特徴は
GPT-5.2を基盤とするカスタムAIデータエージェントは、Slack、Webインタフェース、IDE（統合開発環境）、OpenAI Codex CLIなどを使って、OpenAIの従業員が普段作業している場所から利用可能だ。
カスタムAIデータエージェントに対しては、複数回の試行錯誤が必要な質問や自由回答を求める質問を投げかけることができる。
特筆すべきは、カスタムAIデータエージェントがリーズニングを実行しながら問題を処理する能力だ。固定されたスクリプトに従うのではなく、自らの進捗状況を評価しながら処理を進める。中間結果が間違っているように見える場合、カスタムAIデータエージェントは何が間違っていたかを調査し、アプローチを調整して再試行する。
このプロセス全体を通じてカスタムAIデータエージェントはコンテキスト（社内データ、メタデータ、注釈、コード由来情報、組織知識などに基づく背景情報）を保持し、ステップ間で学習内容を引き継ぐ。この自己学習プロセスにより、ユーザーは手動で反復作業を行う必要がなくなり、手動のワークフローよりも迅速で一貫した高品質の分析が可能になる。
コンテキストが鍵
高品質な回答を生成する鍵は、豊かで正確なコンテキストだ。コンテキストがない場合、モデルに高い性能があっても、誤った結果を生成する可能性がある。こうした問題を防ぐため、カスタムAIデータエージェントは同社のデータと複数のコンテキストレイヤーに基づいて構築されている。
レイヤー1：テーブルの使用状況
スキーマのメタデータ（列名とデータ型）に応じてSQLの書き込みを通知し、テーブル系統（上流と下流のテーブルの関係）を使用して、テーブル間の関係に関するコンテキストを提供する。過去のクエリを取り込み、独自のクエリ記述方法や、通常どのテーブルが結合されるかを理解できるようになる。
レイヤー2：人間による注釈
データウェアハウスにおける人間の業務知識をAIに注入するメタデータのレイヤー。スキーマや過去のクエリからは推測しにくい意図、ビジネス上の意味、既知の注意事項などが含まれる。
レイヤー3：Codexエンリッチメント
テーブルのコードレベルでの定義を導き出すことで、データに何が含まれているかをより深く理解できる。これにより、Spark、PythonなどのデータシステムでSQL以外にテーブルがどのように使用されるかが示され、強化された使用状況コンテキストが得られる。
レイヤー4：インスティテューショナルナレッジ
Slack、Googleドキュメント、Notionにアクセスし、リリース、信頼性インシデント、社内コード名およびツール、主要指標の定義と計算ロジックといった社内の重要なコンテキストを、メタデータおよび権限とともに安全に取得する。
レイヤー5：メモリ
修正を加えられたり、データに関する微妙な差異を発見したりすると、それらの学習内容を次回まで保存できるようになっている。これにより、次回以降はより正確な前提から回答することが可能になる。こうした学習内容の保存は、ユーザーの確認を経て実施される。
レイヤー6：ランタイムコンテキスト
テーブルに事前のコンテキストが存在しない場合や、既存の情報が古い場合、データウェアハウスにライブクエリを発行し、テーブルを直接調べたりクエリしたりできるようになっている。これにより、スキーマを検証する、データをリアルタイムで理解する、状況に応じて回答するといったことが可能になる。必要に応じて他のデータプラットフォームシステムと通信し、より広範なデータコンテキストを取得することも可能だ。
カスタムAIデータエージェントの開発で得た教訓は？
OpenAIは、カスタムAIデータエージェントの構築、運用を通じて、以下の教訓を得たという。
ツールは絞る
OpenAIは当初、同社で利用している全てのツールをカスタムAIデータエージェントに公開していた。その結果、ツールが保有する機能が重複していることでカスタムAIデータエージェントが混乱し、問題が生じたという。そこで、曖昧さを減らし、信頼性を高めるため、特定のツールは利用しないことにしたという。
詳細過ぎる指示は逆効果
過度に具体的な指示を含むプロンプトからはよい結果を得られないことが分かった。分析の細部はケースごとに異なるため、より高レベルのガイダンスを提供し、実行経路の選択はGPT-5のリーズニングに委ねることで、カスタムAIデータエージェントはより良い結果を生み出すようになったとOpenAIは分析している。
意味はコードに宿る
スキーマやクエリ履歴を見ると、「どんな形のテーブルなのか」「どう使われてきたのか」は分かる。しかし、そのデータが本当に何を意味しているのかは、実はそれを作っているコードの中にある。データパイプラインのコードには、「どんな前提条件で作られているか」「データの鮮度をどう保っているか」「どんなビジネス目的で変換しているか」といった、SQL やメタデータだけでは見えない情報が含まれている。OpenAI Codexがコードベースを横断的に読み取ることで、カスタムAIデータエージェントは「このテーブルはどのように作られ、どんな意図で使われるものなのか」を理解できるようになる。これにより、「この数字は何を意味するのか」「このデータは今すぐ使えるのか」といった問いにも、より現実に即した答えを返せるようになる。
Copyright © ITmedia, Inc. All Rights Reserved.