LLM はハルシネートします。これは誰にとっても新しい話ではありません。しかし、データツールを他のどんなものよりも激しく壊す特定のハルシネーションカテゴリがあります：自信を持って間違った数値を生成すること。
言語モデルは「MRR は $47,200、前月から 12% 増」と、数値が正しいかどうか、モデルが 1 つのカラムを誤読して黙って間違ったフィールドを集約したかどうかに関わらず、まったく同じトーンで伝えます。出力はもっともらしい。出力は間違っている。SQL をチェックしない限り気づけない — そして Data Agent を使う全ポイントは毎回 SQL をチェックしなくて済むことです。
この記事は、難しい質問でエージェントを減速させて自分の作業を検証させるために、Deep Analysis（内部では Rigorous モードと呼ぶ）を Tablize にどう組み込んだかについてです。Verifiable Reasoning と呼ばれる 9 ステッププロトコルで、その背後の設計判断は驚くほど興味深いものです。
1 つの例で見る問題
Data Agent に尋ねるとしましょう：「先四半期のネット収益は、返金とチャージバックを考慮して何だったか？」
naive なエージェントは：
- 質問内の「ネット収益」を見る。
ordersテーブルにrevenueカラムを見つける。- その四半期で合計する。
- 自信を持って数値を返す。
その数値は少なくとも 3 つの方法で間違っています。1 つ目、orders の「revenue」はグロス注文額で、返品ネットではない。2 つ目、チャージバックは別のテーブル（disputes）にある。3 つ目、「先四半期」が曖昧 — 暦四半期？ 会計四半期？ 過去 90 日？
エージェントはこれらに気づきません。モデルは質問に対して最も確率の高い答えを生成しているのであり、データに対して最も正しい答えを生成しているのではありません。両者は絶えず乖離します。
なぜ「思考トークンを追加するだけ」では修正できないか
Extended thinking は助けになりますが、十分ではありません。テストしました：回答前にモデルに 4〜16K トークンのスクラッチスペースを与えると、多段階質問での精度がおそらく 15〜25% 向上します。それは良いことですが、「本番出荷」と「出荷すべきではない」の差ではありません。
問題は、思考がまだモデルの頭の中に閉じ込められていること。実際にデータを見ているわけではありません。データに何が含まれているか推測し、その推測について推論し、推測と自己整合する答えを生成 — しかし必ずしも現実と整合しません。
必要だったのはもっと思考ではなく、もっと チェック でした。
9 ステップ Verifiable Reasoning プロトコル
Tablize の Deep Analysis モードは、すべての複雑な分析質問を 9 ステップで実行します。すべての質問で 9 つ全部が発火するわけではない — エージェントが質問の形に基づいてどれを実行するか選ぶ — が、プロトコルは厳密性の上限です。
1. 質問を明確化（必要に応じて）
質問が答えに実質的に影響する形で曖昧なら、エージェントが尋ねる。「先四半期」は曖昧。「上位 10 顧客」は曖昧（生涯価値？ 過去 30 日？ グロスかネットか？）。エージェントは尋ねるか、賢明なデフォルトを選んで仮定を開示するか決定します。
ヒューリスティック：間違った仮定が答えを 10% 以上変えるなら尋ねる。スタイル的な違い（例：「上位 10」vs「上位 20」）ならデフォルト。
2. データプランを作成
クエリを書く前に、エージェントがプランを書きます：どのテーブルを使うか、各テーブルからどのカラム、どの結合、どのフィルター、どの集約。エージェントのコンテキストに保持され、応答であなたに表示されます。
データプランはコンピュートコストがかかる前に多くのエラーを捕捉します。エージェントのプランが「orders を refunds に order_id で結合」と言い、refunds テーブルが実際は payment_id をリンクとして使うなら、クエリ実行前にこれが見えます。
3. 集約前にサンプリング
大きいやつ。集約を計算する前に、エージェントが関連テーブルからサンプリングします — テーブルサイズに応じて 10〜100 行 — そして実際のデータを見ます。
サンプリングはデータプランが捕捉できないスキーマの誤解を捕捉します。エージェントが order_status の値は paid / refunded / pending だと思っているが、実際は PAID / REFUND / PENDING_PAYMENT なら、フィルター WHERE status = 'paid' は 0 行を返す。サンプルが即座にこれを明らかにします。
データの奇妙さも捕捉します。返金行のために負の数を含む revenue という名前のカラムは一般的なパターンで、「revenue の合計」を非返金行のフィルターなしで取ると、グロスでもネットでもない数値が出ます。
4. 実際のクエリを実行
プランとサンプルの後、実クエリを実行。この時点でエージェントは構造に高い信頼を持っています。クエリは小さくリスクの低いステップです。
5. 結果のサニティチェック
エージェントが結果を期待される桁と比較。あなたの前月収益が約 $50K で、今月の数値が $4.8M で戻ってきたら、エージェントが疑わしいとフラグ — おそらく単位エラー（セント vs ドル）、フィルター忘れ、または結合の倍増。
サニティチェックはシンプル、機械的、大量のエラーを捕捉。経験則：答えが最近のベースラインから 10 倍外なら、報告前に疑い深く掘り下げる。
6. 独立したクエリで相互検証
最高リスク質問では、エージェントが 2 つの異なる方法で答えを計算。「今四半期のネット収益」が SUM(amount) FROM orders WHERE status = 'completed' GROUP BY quarter で計算され、また SELECT SUM(amount) FROM stripe_charges WHERE captured = true AND created BETWEEN ... でも計算されるなら、2 つは丸めを超えて一致すべき。一致しなければ、一方が間違い — エージェントは黙って勝者を選ばず、不一致を浮上させます。
相互検証は高価（1 つではなく 2 つのクエリ）なので、エージェントは質問が値する場合のみ実行。ルール：追加クエリのコスト以上の決定を駆動する答えは相互検証する。
7. インライン算術
答えに何らかの算術（パーセンテージ、デルタ、比率）が含まれるなら、エージェントが算術をインラインで表示。単に「MRR は 12% 成長」ではなく、「MRR は $42K から $47K に成長、デルタ $5K、$5K / $42K = 11.9%。」
これは衒学的に聞こえます。LLM エラーの最悪のクラス — 間違ったベースからパーセンテージを計算 — に対する単一最良の防御です。$42K からの 12% 成長は $5,040。$42K への 12% 下落は $47,727 から始まったことを意味する。異なる数値、しばしば混同される。算術を表示することで、モデルがどの公式を使ったか明示することを強制します。
8. 仮定を宣言
エージェントが行ったすべての仮定 — 曖昧な質問部分について、どのデータセットを使うか、どのタイムゾーン、どの集約関数 — が答えの末尾の「仮定」セクションにリストされます。
これは 2 つの目的を果たします。1 つ目、間違った仮定を見つけられる。2 つ目、エージェントに仮定を 意識 させ、実験的に暗黙の仮定を作る率を減らします。
9. 結論を明確に述べる
最終回答は短く、宣言的、1 文 — 上の層で裏付けられています。「データは示唆する」や「〜のようです」ではない — 最終行は数値が何で何を意味するかを言います。
冗長だが正直なバージョンの答えは上に。クリーンなバージョンは下に。両方読んでも片方だけ読んでもいい。
Deep Analysis モードでエージェントはどう見えるか
Tablize UI では、Deep Analysis が有効なとき、エージェントが進める 9 ステップ全部が見えます。ツール呼び出しは verify でタグ付けされ、金色の左ボーダーがあり、通常の db_query 呼び出しと区別されます。エージェントの推論テキストはプロトコルを表示 — 「ステップ 3：カラムセマンティクスを確認するため orders から 50 行サンプリング中…」 — フォローできます。
これは Standard モードより遅い。トークンコストは 2〜3 倍、レイテンシは 50〜100% 上昇。それがトレードオフ。質問の 80%（「昨日何人がサインアップしたか」）にはコストが見合わず、Standard のままで。重要な 20%（「返金を考慮した先四半期の実ネット収益は」）にはコストが正しい答えを得る価格。
トグルはチャット入力のすぐ上。いつでもひっくり返せる — 会話の途中でも。モードは次のメッセージに適用、セッション全体ではない。
なぜこれが Data Agent カテゴリに重要か
AI 数値への信頼は、LLM が分析作業に使われる最大の障壁です。LLM アプリケーションの他のあらゆるカテゴリ（コード補完、コピーライティング、カスタマーサポート）には、間違った出力を見つけられる人間がループにいます。データ分析では、間違った数値が誰かが気づく前にビジネス決定を駆動できます。
Data Agent の形は答えが正しい場合のみ機能します。「ほぼ正しい」では足りない — 金融数値での 5% エラー率はディールキラー。Verifiable Reasoning は「ほぼ正しい」から「出荷できるほど正しい」へ到達する方法に対する私たちの賭けです。
まだ完了していません。次に取り組んでいるもの：エージェントの数値に信頼区間を浮上させ、どの答えがデータに十分根ざしているか、どれがモデリング仮定を含むかを一目で見られるようにする。一部の質問の率直な答えは「70% 確信している」で、自信を持った間違った数値を与えるよりむしろそう言いたい。
試す方法
Deep Analysis は Plus プラン以上で利用可能。Tablize で任意のチャットを開き、メッセージ入力の上のモードトグルを見つけ、Deep Analysis に切り替え、難しい質問をする。プロトコルが発火するのが見えます。
最大限興味深い出力のために、データを与えた初日のスマートなアナリストに与えるような質問を尋ねる — スキーマを理解し、テーブル横断結合し、エッジケースに注意する必要のあるもの。9 ステップが点灯します。
関連記事：