ChatGPT WorkのData agent、SQL不要で売上鈍化を探る仕組み
画像出典: 写真: Kristoferb at English Wikipedia（CC BY-SA 4.0 / Wikimedia Commons）
OpenAIは2026年9月10日、ChatGPT Work向けのプラグイン「Data agent」を発表しました。SQLを書かずにチャットで質問するだけで社内データベースを集計・可視化でき、企業ごとの指標定義を読み込んで解釈する点が特徴です。一方で外部顧客向けの精度ベンチマークは公開されておらず、回答に添えられる前提と実行クエリを自分で確かめる使い方が前提になります。
社内のデータベースには答えがあるはずなのに、SQLが書けないから手が出せない。依頼しても順番待ちで、返ってきた頃には次の会議が終わっている。正直なところ、この滞留はどの会社でも起きています。
OpenAIが2026年9月10日に発表した「Data agent」は、まさにこの部分を狙った機能です。ChatGPT Work（法人向けのChatGPT）に追加するプラグインで、チャットで質問するだけで社内データを分析し、ダッシュボードまで作ります。ただし「SQLを書かなくていい」ことと「結果を確かめなくていい」ことは別の話です。仕組みと、どこを自分で見るべきかを順に見ていきます。
Data agentとは？ 何が発表されたのか
Data agentは、2026年9月10日にOpenAIが発表した、ChatGPT Work向けの新しいプラグインです。プラグインとは、ChatGPTに追加して機能を足す部品のことで、これを入れると社内のデータベースに接続できるようになります。日本語メディアでも同日から翌日にかけて、ITmedia・GIGAZINE・gihyo.jpなどが報じました。
できることは大きく3つです。自然言語で質問して集計・分析をさせること、その結果をインタラクティブなダッシュボード（数字を切り替えながら見られる画面）にすること、そしてそのダッシュボードを社内で既に使っているBIツールの中に作ること。BIツールというのは、Tableau や Power BI のような、業務データをグラフで見るための画面です。連携先として Omni、Oracle BI、Power BI、Sigma、Tableau、ThoughtSpot が挙げられています。
質問の例としてOpenAI側が想定しているのは、「なぜ売上が落ちたか」「どのコスト費目が増えているか」「どの大口顧客に解約リスクがあるか」といったものです。どれも、知りたいのにSQLが書けず、社内のデータ担当者に頼んで待っていた類の質問です。
どうやって社内データベースを読み解いているのか
SQL生成だけの仕組みとData agentの違いは、「言葉の意味をどこから調達しているか」にあります。ここが今回いちばん技術的におもしろい部分です。
たとえばあなたが「今期の売上」と言ったとき、それは受注ベースか、請求ベースか、返品を引いた後か。会社によって定義が違います。「大口顧客」の線引きも、「解約」と見なすタイミングも同じです。人間の担当者は、社内にいるうちにこれを覚えます。外から来たAIは知りません。
Data agentは、この企業ごとの意味をセマンティックレイヤー（意味定義層）から読み込みます。セマンティックレイヤーとは、生のテーブルと人間の言葉の間に置かれた、指標の定義や計算式をまとめておく層のことです。具体的には dbt、Snowflake Horizon、Databricks Genie Ontology、それに既に社内で使われているBIダッシュボードが参照先として挙げられています。ビジネス用語、指標の定義、独自の計算式、テーブル同士の関係性といった文脈を、そこから拾ってくる設計です。
接続できるデータの置き場所も幅があります。
- データベース・分析基盤: Amazon Redshift、Google BigQuery、Snowflake、Databricks、MongoDB、Datadog、ClickHouse など
- ファイル・文書: Google Drive、SharePoint 上のもの
また、gihyo.jpの記事によれば、Data agentには「データ品質の分析（Analyze Data Quality）」「データの検証（Validate Data）」を含む約20の組み込みスキルが用意されています。スキルというのは、エージェントがあらかじめ持っている定型の作業手順のことです。品質確認と検証がその中に入っていること自体が、作り手側も「まず数字を疑う工程が要る」と考えている証拠だと読めます。
なお導入の可否や、どのデータソース用プラグインを有効にするかは、IT・データ部門の管理者がコントロールする権限設計になっています。個人の判断で勝手に社内DBへ繋がるわけではありません。
なぜ鵜呑みにできないのか？ 精度ベンチマークが公開されていない
ここが、この記事でいちばんお伝えしたい部分です。
まず前提として、OpenAI自身が「他のシステムと同様、間違いを犯すことがある（Like any system, it can make mistakes）」と明言しています。売り込みの場でこう書くということは、それだけ起こりうるということです。
そのうえで問題なのは、外部の顧客向けに、Data agentの精度（accuracy）ベンチマークが公開されていないことです。ベンチマークとは、決まった問題集を解かせて正答率を測る共通のものさしのことで、これがあると「どのくらい間違えるのか」を数字で把握できます。VentureBeatなど複数のメディアが、競合の Databricks が同時期に自社エージェントのベンチマークを公開したのと対照的だとして、この非公開を指摘しました。
「この回答はどのくらい信じてよいか」を示す客観的な指標を持たないまま、企業ユーザーは業務判断にこの数字を使うことになります。社内で誰かが検証しない限り、正答率は誰にも分からないままです。
OpenAI社内では3,500人以上が600PB規模のデータに対して社内版のエージェントを使っているとされています（一次ソースの本文は直接確認できておらず、二次情報に基づく値です）。ただしこれは利用規模の話であって、あなたの会社のデータで正しく答える保証ではありません。規模の数字を精度の数字と読み替えないことが、最初の防波堤になります。
では、実際の誤読はどこで起きるのでしょうか。大きく3つの場所があります。
1. 意味定義が整っていない会社ほどズレる
仕組みの裏返しです。Data agentの理解は、セマンティックレイヤーから読み込んだ定義の質に乗っています。dbt などで指標定義を整備している会社なら文脈は正しく届きますが、定義が未整備だったり、部署ごとに「売上」の意味がばらついていたりすると、AIはどれかを選ぶしかありません。整備されていない会社ほど、もっともらしく違う数字が出ます。
2. ツールが多すぎると混乱する
OpenAIの開発過程には、示唆的な話があります。当初エージェントに全ツールセットを持たせたところ、機能が重複していることが原因で混乱・誤動作が発生し、ツール呼び出しを制限・統合することで信頼性が改善したというものです。プラグインを有効にする範囲を管理者が絞るのは、単なるセキュリティ上の制限ではなく、精度のための設計だと理解できます。
3. 指摘するまでは同じ誤読を繰り返す
ユーザーが誤りを指摘・修正すると、その内容を保存して次回以降の精度改善に使う「自己修正」の仕組みがあるとされています。前向きな機能ですが、裏を返せば誰かが気づいて直すまでは、同じ誤読が何度でも出てくるということです。最初に使い始めた人が確かめずに流すと、その誤りが社内に定着します。
回答をどう確かめる？ 前提と実行クエリを見る手順
全部を検算する必要はありません。Data agentは、誤りうることを前提にした確認の足場を用意しています。回答と一緒に「前提（assumptions）」と「実行ステップ」の要約が提示され、実行したクエリ結果への直リンクが張られるため、生データまで遡って確認できる作りです。この足場を使う前提で、次の順に見ます。
- まず「前提」を読む期間、対象範囲、どの指標定義を使ったかを確認します。「今期」がいつからいつまでか、返品を含むのか。ここが自分の意図とずれていたら、以降の数字は見る必要がありません。
- 実行ステップで筋道を追うどのテーブルを見て、何で絞り込み、何で集計したか。専門家でなくても、対象から除かれてはいけないものが除かれていないかは判断できます。
- クエリ結果の直リンクで生データに当たる特に、意思決定に使う数字1つだけでよいので、元データまで降ります。合計が合うか、件数が極端に少なくないかを見ます。
- 既知の数字と突き合わせる月次報告など、答えを知っている期間で同じ質問を投げ、一致するか確かめます。これが自分の会社での「簡易ベンチマーク」になります。
- ずれていたら、その場で指摘して直す自己修正の仕組みに乗せます。放置すると、そのまま社内で使われ続けます。
- 傾向をつかむ・仮説の当たりをつける → そのまま使ってよい
- 社内会議で共有する数字 → 前提と実行ステップは必ず読む
- 対外発信・契約・予算の根拠 → 生データまで降りて裏取りする
- 誤情報がそのまま業務判断や対外発信に使われる領域（契約・法務・顧客対応）は、生成AI全般でリスクが指摘されています
導入前に確認しておくべきことは？
使えるかどうかを判断する材料として、現時点で分かっていることと、分かっていないことを分けておきます。
| 発表日 | 2026年9月10日（ChatGPT Work向けプラグインとして発表） |
|---|---|
| 提供形態 | ChatGPT Work のプラグイン。管理者が導入可否とデータソース別プラグインの有効化を管理 |
| 料金 | 追加課金の有無を含め、収集時点の公開情報では未確認 |
| 外部向け精度ベンチマーク | 公開されていない（2026年9月時点・複数メディアが指摘） |
OpenAIの発表を報じた各メディア（ITmediaほか）の公表情報をもとに作成
料金と日本語対応の詳細は、公開されている記事の範囲では明記がありませんでした。導入を検討する段階では、この2点を自社の窓口で確認することになります。
社内の指標定義が部署ごとにばらついていて、セマンティックレイヤーの整備がこれからという会社では、Data agentは「早く出るが確かめにくい数字」を量産する側に回りかねません。その場合は、先に指標定義を1つずつ揃えるほうが効きます。逆に言えば、定義を整える作業そのものが、この種のツールを活かす準備になります。
この機能が示しているものは何か
Data agentの新しさは、SQLを書かずに済むことだけではありません。企業ごとの「言葉の意味」を外部の定義層から読み込んで解釈する、という設計そのものが要点です。AIに社内の文脈をどう渡すかという問題に対して、プロンプトに書き足すのでも学習させ直すのでもなく、既に会社が持っている定義の仕組みに繋ぐ、という答えを出しています。
そしてその設計は、限界の在りかも同時に示しています。読み込む定義が曖昧なら、出てくる答えも曖昧になる。精度の指標が外に出ていない以上、その良し悪しを測るのは、いまのところ使う側の手元にある既知の数字だけです。まずは答えを知っている質問から投げてみる。そこから始めれば十分です。
よくある質問
ChatGPT WorkのData agentはいつ発表された機能ですか？
OpenAIが2026年9月10日に発表した、ChatGPT Work向けの新しいプラグインです。自然言語のチャットだけで社内データを分析し、インタラクティブなダッシュボードまで作成できます。日本語メディアでも同日から翌日にかけて報じられました。
Data agentはどんなデータソースに接続できますか？
Amazon Redshift、Google BigQuery、Snowflake、Databricks、MongoDB、Datadog、ClickHouse などのデータベース・分析基盤に加え、Google Drive や SharePoint 上のファイル・文書も分析対象にできます。どのデータソース用プラグインを有効化するかは、IT・データ部門の管理者が管理します。
Data agentは企業ごとの指標の違いをどう扱っていますか？
dbt、Snowflake Horizon、Databricks Genie Ontology、既存のBIダッシュボードといったセマンティックレイヤー（意味定義層）から、その企業のビジネス用語・指標定義・独自の計算式・データ間の関係性を読み込んで解釈します。裏を返せば、これらの意味定義が整備されていない企業では誤読が起きやすくなります。
Data agentの回答はそのまま信じてよいのでしょうか？
OpenAI自身が「他のシステムと同様、間違いを犯すことがある」と明言しており、外部顧客向けの精度ベンチマークも公開されていません。回答には前提（assumptions）と実行ステップの要約、実行クエリ結果への直リンクが付くため、意思決定に使う数字は前提を読み、生データまで遡って確認する使い方が前提になります。
※記事で使用した内容・数値は変更される場合があります。最新情報は公式サイトをご確認ください。