社内データをChatGPTに接続し、自然言語で質問するだけでダッシュボードを作れる機能「Data agent」がChatGPT Work向けに公開されました。ChatGPT Workは企業向けのChatGPT提供形態で、組織のデータソースと連携できる点が個人向けプランとの大きな違いです。
QA（品質保証）やテスト自動化に関わるエンジニアにとって、この機能は「テスト対象」の性質が変わる出来事として捉える必要があります。集計ロジックやSQLクエリを人間が書くのではなく、AIエージェント（自律的にタスクを遂行するAIの仕組み）が都度生成する形になるためです。この記事では、Data agentのような生成型データ分析機能をリリースサイクルに組み込む際、QA視点でどこを見るべきかを整理します。
Data agentが変える「テストすべきもの」の中身
従来のBI（ビジネスインテリジェンス）ダッシュボードは、固定のクエリとロジックに対して回帰テスト（変更が既存機能を壊していないか確認するテスト）を組めば十分でした。クエリが変わらない限り、同じ入力には同じ出力が返ってきます。
Data agentは自然言語の指示を受けて、都度クエリやグラフ構成を自動生成します。つまり同じ質問文でも、モデルのバージョンやプロンプトの解釈次第で生成されるクエリが変わりうるということです。これはLLM（大規模言語モデル）を使ったアプリケーション全般に共通する性質で、決定論的（同じ入力から必ず同じ出力になる性質）なシステムのテスト手法をそのまま持ち込めません。
たとえば「先月の解約率を部門別に出して」という指示に対し、ある回では正しい集計期間でSQLが生成され、別の回では月初日の定義がずれる、といったことが起こり得ます。これはバグというより、生成AIの持つ「毎回微妙に異なる出力を返す」性質そのものです。QAとしては、この揺らぎを許容範囲と欠陥の境界線として明確に定義する作業が新たに必要になります。
生成結果の検証はどう設計するか
生成AIが介在する集計処理をテストする際、有効なアプローチの一つが「正解データセットとの突き合わせ」です。あらかじめ人手で計算した既知の正解値を用意し、Data agentが生成した結果と自動で比較する仕組みを作ります。
この仕組みはevaluation（LLMの出力品質を評価する手法、通称eval）と呼ばれる領域に該当します。単体テストのように「一致/不一致」だけでなく、集計値のずれが許容誤差の範囲かどうかを判定するロジックが必要です。
具体的には次のような観点でテストケースを設計します。
- 既知の正解値を持つクエリセット（売上合計、件数集計など基本パターン）を10〜20件程度用意する
- 同一プロンプトを複数回実行し、出力のばらつき（分散）を継続的に記録する
- 集計期間や地域名など、曖昧さを含む表現に対する解釈の一貫性を確認する
- 生成されたグラフの軸ラベルや単位が入力データの定義と一致しているかをチェックする
これらは一度実施して終わりではなく、モデルの更新やプロンプトテンプレートの変更のたびに再実行する回帰テストとして組み込む必要があります。ChatGPT Workの管理画面や利用しているOpenAIのモデルバージョン情報を定期的に確認し、バージョン変更のタイミングを把握しておくことが前提になります。
既存のCI/CDパイプラインとの接続点
Data agentのような機能は単体では完結せず、社内のデータ基盤やダッシュボード共有フローと接続されて初めて価値を持ちます。ここでCI/CD（継続的インテグレーション/継続的デリバリー）パイプラインとの接続を考える必要があります。
従来のダッシュボードはコード化されたクエリをGitで管理し、プルリクエストのレビューを経てデプロイする、というプロセスが一般的でした。dbt（データ変換をコードで管理するツール）を使っている組織であれば、この流れは馴染み深いはずです。
Data agentが生成するクエリは対話の中で都度作られるため、この「コードレビュー」の工程が抜け落ちます。組織として重要な意思決定にこの機能を使う場合、生成されたクエリやロジックを事後的に確認できるログ機能があるかどうかを確認しておく必要があります。ChatGPT Workの管理コンソールで、監査ログ（audit log）や生成されたクエリの履歴が閲覧できる設定になっているか、導入前に必ずチェックしてください。
今日から確認できること
実際に導入を検討している、あるいはすでに一部チームで使い始めている場合、次の点を今日確認しておくと安心です。
# 確認例: 生成されたクエリのログが取得できるか
# ChatGPT Work管理画面の「監査ログ」または「アクティビティ」セクションを確認
# - どのユーザーがどんな質問をしたか
# - 生成されたSQL/クエリ本体が記録されているか
# - タイムスタンプとモデルバージョンが紐づいているかこれらのログが取得できない設定になっている場合、後からダッシュボードの数値に疑義が出た際に原因追跡ができません。品質保証の観点では、これは重大な設定漏れとして扱うべきです。
また、Data agentを使ったダッシュボードを意思決定に使う前段階として、次のチェックリストを社内のQAプロセスに組み込むことを検討してください。
- 既知の正解値を持つ質問セットで定期的にサンプル検証を行う
- ダッシュボードの元になった質問文とクエリをセットで保存・共有する
- 集計結果に対して「なぜその数値になったか」を人間が説明できる状態を保つ
- モデルやプロンプトテンプレートの更新タイミングをリリースノートで追跡する
まとめ
ChatGPT Workの新機能Data agentは、自然言語だけでダッシュボードを作れる利便性がある一方、QAの視点では「毎回同じ結果を返すとは限らない集計システム」を新たにテスト対象に加えることを意味します。
決定論的なBIツールと違い、生成AIによる集計は正解データセットとの突き合わせやログの監査性を前提にした品質保証設計が欠かせません。導入を検討しているなら、まずは監査ログの有無とサンプル検証の仕組みを確認するところから始めてみてください。