6月19日、Bonnie Xuが「AI Agents to Make Sense of Data at OpenAI」と題した記事を公開した。OpenAIが社内のデータ分析課題を解決するために構築したAIエージェント「Kepler」の設計・実装・運用ノウハウについて詳しく紹介されている。
「どのテーブルを使えばいい？」という問いに、5スレッドかかる組織
OpenAIのデータプラットフォームは、70,000以上のデータセットから1日600ペタバイト以上のデータを処理する規模だ。社員の80%がこのプラットフォームを直接利用している。
規模が大きくなるほど「テーブルの発見」が難しくなる。似た名前のテーブルが乱立し、あるテーブルは不正率を補正済み、別のテーブルは補正なし、IDが暗号化されているものとそうでないものが混在——こうした微妙な違いを見落とすと、答えが桁違いに間違うことが起きる。
「ChatGPTのイタリアのProユーザー数は？」という単純な質問に、コードの深掘り3回・会議2回・Slackスレッド5本かかる——これがKeplerを作る動機になった。
Kepler：社内AIデータアナリスト
KeplerはOpenAIの社内ツールで、データに関する質問を自然言語で受け付け、SQL生成・クエリ実行・結果の解釈まで一貫して行うAIエージェントだ。アクセス経路は複数用意されている。
- Slack：Slackエージェントに話しかける
- IDE（Cursor等）：MCPサーバーとして接続（MCPについては後述）
- Webエージェント：テーブル情報の検索
- MCPプラットフォーム：ワークロードの連携
発表内では、ニューヨークのタクシーデータを使った例（「最も所要時間のばらつきが大きいルートはどこか？」）と、ChatGPTの週間アクティブユーザーが3月下旬に急増した原因調査という2つのデモが示された。
後者が特に興味深い。Keplerは以下のステップを自律的に実行した。
- スパイク前後の数値を確認する適切なテーブルを特定
- Notionドキュメントやダッシュボードを参照してテーブルの正当性を確認
- プラン別・地域別でクエリをスライスしてスパイクの原因を絞り込む
- 「ログの重複」などの仮説を立て、社内コンテキストで否定
- Web検索でTechCrunchの記事やリリースノートを参照し、「ImageGenのリリースが原因」と結論づけた
人間のデータアナリストが数時間かけてやる作業を、エージェントが自律的にこなす流れだ。
技術の核心：コンテキストをどう与えるか
Keplerで最も工夫されているのが「コンテキストの設計」だ。コンテキストが不適切だと、ChatGPTユーザー数を「5百万人」と答える（元記事の発表時点で実際の数値とは大きくかけ離れた回答例として紹介されているもの）、Sora（動画生成AI）をKingdom Heartsのゲームキャラクターと誤認するといった致命的な誤りが起きる。
70,000テーブルのスキーマ・クエリ履歴をすべてコンテキストウィンドウに詰め込むことは不可能だ。そこでKeplerは以下のアーキテクチャを採っている。
オフライン処理（事前生成）
テーブルメタデータをOpenAI APIでエンベディングし、意味的検索で取得可能にする基盤を構築している。単なるキーワード検索ではなく、質問の意図に近いテーブルを意味空間から引き当てられる点が重要だ。
説明文の陳腐化問題を解決するため、Codexタスクを毎日並列実行してテーブルの説明を自動生成している。ここで言う「Codex」はOpenAIが提供するコード生成・実行エージェント機能を指す（GitHub Copilot黎明期に広く知られた旧来のCodexモデルとは別物）。
生成内容はカタログの情報だけでなく、「そのテーブルがどのコードから作られたか」「下流での利用パターン」「粒度やプライマリキー」「いつ別のテーブルを使うべきか」まで含む。この「コードベースのクロール」が差別化ポイントで、テーブルが「ChatGPT分析用」であることを知るだけでなく、「このテーブルはログのサブセットからフィルタリングされている」という生成の文脈まで把握できる。
オンライン処理（リアルタイム）
リアルタイム処理では、データウェアハウス（Trino/Spark）・Airflowへの直接APIコール、そしてMCP（Model Context Protocol）によるツール呼び出しの連鎖を組み合わせている。MCPとはAnthropicが提唱しLLMコミュニティで普及しつつあるオープン標準で、AIモデルが外部ツールやデータソースを統一的なインターフェースで呼び出せるようにする仕組みだ。
MCPを採用したことで、Keplerは「間違えたら自分で気づいてやり直す」サイクルを回せる。テーブルのJOINキーを誤ってゼロ件になった場合、エラーフィードバックを受けて別のキーを試す——この自律的な試行錯誤がエージェントの精度を支えている。
オフラインで積み上げた豊富なメタデータをベースに、オンラインでリアルタイムのツール呼び出しと自律的な修正ループを組み合わせる構成が、Keplerのアーキテクチャ上の肝だ。
メモリとevals：品質を維持する仕組み
会話の文脈は全スレッドにわたって保持される。前の応答で特定したテーブル情報を次の質問で再利用できるため、同じ初期調査を繰り返さずに済む。56回のスレッド返信でも文脈が維持されている事例が紹介された。
精度の担保にはevalsを活用している。モデルのアップデートや変更によるリグレッションを検知するための仕組みで、発表者の「Keplerが答えを出すたびに、正しいかどうか毎回ドキドキする」というコメントが印象的だ。それだけ評価の自動化が重要になる。
またワークフロー機能も実装されており、「devテーブルとprodテーブルのデータ検証」「特定の機能分析」といった繰り返しの多い処理を、カスタム手順書として保存・再実行できる。定型的な分析作業の自動化という観点でも、エンジニアリング組織への示唆は大きい。
詳細はAI Agents to Make Sense of Data at OpenAIを参照していただきたい。
