OpenAI の自社データエージェントの内部

データは、システムの学習、製品の進化、企業の選択に影響を与えます。しかし、迅速かつ正確に、適切な文脈で回答を得ることは、思ったよりも難しいことがよくあります。OpenAI の拡張に合わせてこれを簡単にするために、私たちは独自のプラットフォーム上で探索と推論を行う当社独自の特注 AI データエージェントを社内に構築しました。

当社のエージェントは、OpenAI のデータ、権限、ワークフローを中心に特別に構築された、外部提供ではない、社内専用のカスタムツールです。ここでは、当社が AI をどのように構築し、使用しているかを紹介することで、AI がチーム全体の日常業務を効果的にサポートできる実際の例を明らかにします。エージェントを構築して実行するために使用した OpenAI ツール（Codex、GPT‑5 フラッグシップモデル、Evals API⁠（新しいウィンドウで開く）、およびEmbeddings API⁠（新しいウィンドウで開く））は、世界中の開発者に提供しているツールと同じものです。

当社のデータエージェントは、従業員が質問からインサイトを得るまでの時間が数日かかっていたのを数分に短縮します。これにより、データチームだけでなく、すべての部門にわたってデータの取得と詳細な分析を行うハードルが下がります。現在、OpenAI のエンジニアリング、データサイエンス、GTM 戦略、財務、研究の各チームは、影響の大きいデータに関する質問に答えるためにこのエージェントを活用しています。たとえば、自然言語の直感的な形式を通じて、リリースを評価したり、ビジネスの健全性を把握したりする方法の答えを見つけるのに役立ちます。このエージェントは、Codex を活用したテーブルレベルのナレッジを製品および組織のコンテキストと統合します。また、継続的に学習するメモリシステムは、使用するたびに改善されます。

この記事では、特注の AI データエージェントが必要だった理由、コードが強化されたデータコンテキストと自己学習が便利である理由、そしてその過程で学んだ教訓について詳しく説明します。

OpenAI のデータプラットフォームは、エンジニアリング、製品、研究の各部門で働く3,500人を超える社内ユーザーにサービスを提供しており、70,000件のデータセットにわたる600ペタバイトを超えるデータを扱っています。それだけの規模になると、適切なテーブルを見つけること自体が、分析を行う際に最も時間のかかる作業の一つとなることがあります。

ある社内ユーザーは次のように述べています。

「似たようなテーブルが多数あり、それらの違いやどれを使用するかを把握するのに膨大な時間を費やしてしまいます。ログアウトしたユーザーを含む場合もあれば、含まない場合もあります。それに、一部のフィールドは重複しており、どれがどれか判別するのが大変です。」

仮に正しいテーブルを選択したとしても、正しい結果を出すのは難しい場合があります。アナリストは、変換とフィルターが正しく適用されていることを確認するために、テーブルデータとテーブルの関係について推論する必要があります。一般的な失敗パターン（多対多の結合、フィルタープッシュダウンエラー、処理されない null）により、結果が暗黙的に無効になる可能性もあります。OpenAI の規模なら、アナリストは SQL セマンティクスやクエリパフォーマンスのデバッグに時間を費やすことなく、メトリックの定義、仮定の検証、データ主導型の意思決定に注力することができます。

当社のエージェントが何であるか、どのようにコンテキストをキュレーションし、どのように自己改善を続けるのかを順を追って見ていきましょう。

当社のエージェントは GPT‑5.2 を搭載しており、OpenAI のデータプラットフォーム上で推論するように設計されています。これは、従業員が作業する場所であればどこでも利用できます。Slack エージェントとして、Web インターフェース経由、IDE 内、MCP 経由の Codex CLI⁠（新しいウィンドウで開く） 内で利用できるほか、MCP コネクター経由の OpenAI の内部 ChatGPT アプリ⁠（新しいウィンドウで開く）内で直接利用することもできます。

ユーザーは、通常は自分で複数回の調査を行う必要がある複雑なオープンエンドの質問をすることができます。テストデータセットを使用する次のプロンプト例を見てみましょう：「ニューヨーク市のタクシー移動の場合、乗車から降車までの ZIP ペアのうち、最も信頼性が低く、標準的な移動時間と最悪の移動時間の差が最も大きいのはどれですか。また、その変動はいつ発生しますか。」

エージェントは分析をエンドツーエンドで処理し、質問を理解し、データを探索し、クエリを実行し、結果を統合します。

エージェントの強みのひとつは、問題を推論しながら考える能力です。固定されたスクリプトに従うのではなく、エージェントは自らの進捗状況を評価します。中間結果が間違っているように見える場合（誤った結合やフィルターのために行数がゼロになる場合など）、エージェントは何が間違っていたかを調査し、アプローチを調整して再試行します。このプロセス全体を通じて、完全なコンテキストが保持され、ステップ間で学習内容が引き継がれます。このクローズドループの自己学習プロセスにより、ユーザーの代わりにエージェント自体が反復作業を行うので、手動のワークフローよりも迅速で一貫した高品質の分析が可能になります。

エージェントは、データの検出、SQL の実行、ノートブックとレポートの公開など、分析ワークフロー全体をカバーします。さらに、社内のナレッジを理解し、外部情報をウェブ検索で取得し、時間とともに学習とメモリを通じて改善していきます。

高品質な回答は豊かで正確なコンテキストに依存します。コンテキストがないと、たとえ強力なモデルであっても、ユーザー数を大幅に誤って推定したり、社内用語を誤って解釈したりするなど、間違った結果が生成される可能性があります。

こうした失敗パターンを回避するために、エージェントは OpenAI のデータとインスティテューショナルナレッジに基づいた複数のコンテキストレイヤーを中心に構築されています。

• メタデータの基盤：エージェントはスキーマメタデータ（列名とデータ型）に応じて SQL の書き込みを通知し、テーブル系統（上流と下流のテーブルの関係など）を使用して、さまざまなテーブルの関係に関するコンテキストを提供します。
• クエリ推論：過去のクエリを取り込むことで、エージェントは独自のクエリの記述方法や、通常どのテーブルが結合されるかを理解できるようになります。

• ドメインの専門家によって提供されるテーブルと列の厳選された説明。スキーマや過去のクエリからは簡単に推測できない意図、セマンティクス、ビジネス上の意味、既知の注意事項が含まれます。

メタデータだけでは不十分です。テーブルを本当に区別するには、テーブルがどのように作成され、どこに由来するのかを理解する必要があります。

• テーブルのコードレベルの定義を導き出すことにより、エージェントはデータに実際に何が含まれているかをより深く理解します。
  • テーブルに保存される内容とそれが分析イベントからどのように派生されるかについての微妙な差異からは、さらなる情報が引き出されます。たとえば、値の一意性、テーブルデータの更新頻度、データの範囲（例：テーブルが特定のフィールドを除外している場合、その粒度のレベル）などのコンテキストが得られます。
• これにより、Spark、Python、その他のデータシステムで SQL 以外にテーブルがどのように使用されるかが示され、強化された使用状況コンテキストが得られます。
• つまり、エージェントは、見た目は似ているものの重要な点で異なるテーブルを区別できるということです。たとえば、テーブルにファーストパーティの ChatGPT のトラフィックのみが含まれているかどうかを判断できます。このコンテキストも自動的に更新されるため、手動でメンテナンスしなくても常に最新の状態に保たれます。

• エージェントは Slack、Google ドキュメント、Notion にアクセスして、リリース、信頼性インシデント、社内コード名とツール、主要メトリックの標準定義と計算ロジックなどの重要な会社のコンテキストをキャプチャできます。
• これらのドキュメントは、メタデータおよび権限とともに取り込まれ、埋め込まれ、保存されます。取得サービスは実行時にアクセス制御とキャッシュを処理し、エージェントがこの情報を効率的かつ安全に取得できるようにします。

• エージェントに修正が加えられたり、特定のデータに関する質問について微妙な差異が発見されたりすると、その学習内容を次回まで保存できるため、ユーザーとともに継続的に改善することができます。
  • その結果、何度も同じ問題でつまずくことがなくなり、将来の回答はより正確なベースラインに基づくようになります。
  • メモリの目的は、データの正確性にとって重要であるものの、他のレイヤーだけから推測するのが難しい、わかりにくい修正、フィルター、制約を保持して再利用することです。
  • たとえば、ある事例では、エージェントは特定の分析実験をフィルタリングする方法を知りませんでした（実験ゲートで定義された特定の文字列との照合に依存していました）。この場合、あいまいに文字列を一致させるのではなく、正しくフィルタリングできるようにするには、メモリが非常に重要でした。
• ユーザーは、エージェントに修正を加えたり、会話から何かを学習したりすると、次回のためにそのメモリを保存するように求められます。
  • ユーザーはメモリを手動で作成したり編集したりすることもできます。
  • メモリはグローバルレベルと個人レベルで範囲指定されており、エージェントのツールを使用して簡単に編集できます。

• テーブルに事前のコンテキストが存在しない場合、または既存の情報が古い場合、エージェントはデータウェアハウスにライブクエリを発行して、テーブルを直接調べたりクエリしたりすることができます。これにより、スキーマを検証したり、データをリアルタイムで理解したり、状況に応じて回答したりできるようになります。
• エージェントは、必要に応じて他のデータプラットフォームシステム（メタデータサービス、Airflow、Spark）と通信して、ウェアハウス外に存在するより広範なデータコンテキストを取得することもできます。

We run a daily offline pipeline that aggregates table usage, human annotations, and Codex-derived enrichment into a single, normalized representation. This enriched context is then converted into embeddings using the OpenAI embeddings API⁠（新しいウィンドウで開く） and stored for retrieval. At query time, the agent pulls only the most relevant embedded context via retrieval-augmented generation⁠（新しいウィンドウで開く） (RAG) instead of scanning raw metadata or logs. This makes table understanding fast and scalable, even across tens of thousands of tables, while keeping runtime latency predictable and low. Runtime queries are issued to our data warehouse live as needed.

Together, these layers ensure the agent’s reasoning is grounded in OpenAI’s data, code, and institutional knowledge, dramatically reducing errors and improving answer quality.

One-shot answers work when the problem is clear, but most questions aren’t. More often, arriving at the correct result requires back-and-forth refinement and some course correction.

The agent is built to behave like a teammate you can reason with. It’s a conversational, always-on and handles both quick answers and iterative exploration.

It carries over complete context across turns, so users can ask follow-up questions, adjust their intent, or change direction without restating everything. If the agent starts heading down the wrong path, users can interrupt mid-analysis and redirect it, just like working with a human collaborator who listens instead of plowing ahead.

When instructions are unclear or incomplete, the agent proactively asks clarifying questions. If no response is provided, it applies sensible defaults to make progress. For example, if a user asks about business growth with no date range specified, it may assume the last seven or 30 days. These priors allow it to stay responsive and non-blocking while still converging on the right outcome.

The result is an agent that works well both when you know exactly what you want (e.g., “Tell me about this table”) and just as strong when you’re exploring (e.g., “I’m seeing a dip here, can we break this down by customer type and timeframe?”). 

After rollout, we observed that users frequently ran the same analyses for routine repetitive work. To expedite this, the agent's workflows package recurring analyses into reusable instruction sets. Examples include workflows for weekly business reports and table validations. By encoding context and best practices once, workflows streamline repeat analyses and ensure consistent results across users.

Building an always-on, evolving agent means quality can drift just as easily as it can improve. Without a tight feedback loop, regressions are inevitable and invisible. The only way to scale capability without breaking trust is through systematic evaluation.

In this section, we’ll discuss how we leverage OpenAI’s Evals API⁠（新しいウィンドウで開く） to measure and protect the agent’s response quality.

Its Evals are built on curated sets of question-answer pairs. Each question targets an important metric or analytical pattern we care deeply about getting right, paired with a manually authored “golden” SQL query that produces the expected result. For each eval, we send the natural language question to its query-generation endpoint, execute the generated SQL, and compare the output against the result of the expected SQL.

Evaluation doesn’t rely on naive string matching. Generated SQL can differ syntactically while still being correct, and result sets may include extra columns that don’t materially affect the answer. To account for this, we compare both the SQL and the resulting data, and feed these signals into OpenAI’s Evals grader. The grader produces a final score along with an explanation, capturing both correctness and acceptable variation.

These evals are like unit tests that run continuously during development to identify regressions as canaries in production; this allows us to catch issues early and confidently iterate as the agent's capabilities expand.

Our agent plugs directly into OpenAI’s existing security and access-control model. It operates purely as an interface layer, inheriting and enforcing the same permissions and guardrails that govern OpenAI’s data. 

All of the agent’s access is strictly pass-through, meaning users can only query tables they already have permission to access. When access is missing, it flags this or falls back to alternative datasets the user is authorized to use.

Finally, it's built for transparency. Like any system, it can make mistakes. It exposes its reasoning process by summarizing assumptions and execution steps alongside each answer. When queries are executed, it links directly to the underlying results, allowing users to inspect raw data and verify every step of the analysis.

Building our agent from scratch surfaced practical lessons about how agents behave, where they struggle, and what actually makes them reliable at scale.

Early on, we exposed our full tool set to the agent, and quickly ran into problems with overlapping functionality. While this redundancy can be helpful for specific custom cases and is more obvious to a human when manually invoking, it’s confusing to agents. To reduce ambiguity and improve reliability, we restricted and consolidated certain tool calls.

We also discovered that highly prescriptive prompting degraded results. While many questions share a general analytical shape, the details vary enough that rigid instructions often pushed the agent down incorrect paths. By shifting to higher-level guidance and relying on GPT‑5’s reasoning to choose the appropriate execution path, the agent became more robust and produced better results.

Schemas and query history describe a table’s shape and usage, but its true meaning lives in the code that produces it. Pipeline logic captures assumptions, freshness guarantees, and business intent that never surface in SQL or metadata. By crawling the codebase with Codex, our agent understands how datasets are actually constructed and is able to better reason about what each table actually contains. It can answer “what’s in here” and “when can I use it” far more accurately than from warehouse signals alone. 

We’re constantly working to improve our agent by increasing its ability to handle ambiguous questions, improving its reliability and accuracy with stronger validations, and integrating it more deeply into workflows. We believe it should blend naturally into how people already work, instead of functioning like a separate tool.

While our tooling will keep benefiting from underlying improvements in agent reasoning, validation, and self-correction, our team’s mission remains the same: seamlessly deliver fast, trustworthy data analysis across OpenAI’s data ecosystem.