Querioの数字が社内で信用されない原因｜検算と権限の決め方

「Querio を入れれば、分析の担当を待たずに、マーケや営業が自分で数字を出せる」「AIが書いたSQLの数字なんて、怖くて会議資料には使えない」——データの活用を部門に広げようとしている会社では、この二つの声が同じ週に聞こえてきます。前者は期待しすぎで、後者は疑いすぎです。自然な言葉の質問をSQLに変えて答える分析基盤が社内で信用されない原因は、AIの精度ではなく、書かれたSQLと出てきた数字を、誰がどこまで確かめるかが決まっていないことにあります。この記事では、Querio をマーケや営業の部門に開くときに、確かめる役割、つないでよいデータの範囲、MCP 経由で外のAIから触らせる線、会議資料に使う前の検算を、課題・原因・対策の順に整理します。

Querio は、データ倉庫に自然な言葉で質問できるAI分析基盤

Querio は、社内のデータ倉庫やデータベースにつなぎ、利用者が自然な言葉で投げた質問を、AIがSQLやPythonのコードに書き換えて実行し、表やグラフで返す分析基盤です。提供元は Querio Ltd. で、公式サイトでは500万ドルの資金調達を公表しています。つなぐ先として Snowflake、BigQuery、Redshift、ClickHouse など主要なデータ倉庫に対応しており、2026年に入ってからも、公式の変更履歴で接続先の追加が続いています。

特徴は、分析の一つひとつが、ノートブックの形で残ることです。質問、AIが書いたSQL、Pythonの処理、出てきた表やグラフが順に並ぶため、答えの数字がどのコードから出たのかを後から追える作りになっています。指標の定義や業務のルールは「コンテキスト」と呼ぶ場所に一度書き、すべてのエージェントと道具がそれを読む仕組みで、定義は dbt のモデルと並べて Git で版を管理すると説明されています。公式サイトはこれを Git を土台にした分析と呼び、ダッシュボードや定期の配信、自社製品への分析の埋め込みまで同じ基盤で扱うとしています。

指標の定義を誰がどう決めるかという論点は、同じ種類の道具を扱った別の記事で詳しく整理しているため、ここでは繰り返しません。この記事が扱うのは、Querio をマーケや営業の部門の人にも開くとき、出てきた数字を誰がどう確かめ、どこまで社内の判断に使ってよいかという運用の側です。導入の可否を決める立場の人が、契約の前に社内で合意しておくべき点に絞ります。

2026年夏の更新：非公開の既定、データ源の制限、鍵、MCP

公式の変更履歴を見ると、2026年の半ばに、社内に広げるときの統制にかかわる更新がまとまって入っています。6月4日には、探索（質問と分析の会話）が既定で本人だけが見られる非公開になり、閲覧者と編集者の権限を付けて共有する仕組みに変わりました。6月10日には、データ源ごとに使える人を絞れるようになりましたが、変更履歴の説明では、特定の利用者を加えるまではワークスペース全体に開いたままです。

7月には、探索ごとに使うAIのモデルを選び、途中で切り替えられるようになり（9日）、エージェントを止めると、それが始めた処理も取り消されるようになりました（27日）。7月28日には二つの更新があり、一つは手順や参考資料をまとめた「スキル」の取り込み、もう一つはワークスペースの管理者が、範囲を絞った鍵（プログラムから使うためのアクセストークン）を発行できる機能です。鍵は一度だけ表示され、名前の変更、作り直し、失効、最後に使われた日時の確認ができます。

そして8月上旬には、MCP に対応したAIの道具から、その鍵を使って Querio のデータ源の一覧を取り出し、探索を作成し、進み具合を確かめ、続きを実行できるようになりました。Claude などの外のAIから、Querio を通じて社内のデータ倉庫に分析を走らせられるということです。同じ時期には、定期実行する探索の結果を保存し、次の更新まで使い回す仕組みも入っています。

• 日付と内容は Querio の公式の変更履歴による。MCP 対応の項目は8月上旬（変更履歴の表示では8月4日付）
• 公式の変更履歴で確かめられたのは2026年8月上旬の項目まで。それ以降の更新は、本記事の執筆時点で公開情報から確かめられなかった

誤解：「AIの精度が上がれば、数字は信用される」

冒頭の二つの声は正反対に見えますが、どちらもAIの精度を信用の物差しにしている点で同じです。Querio は自社の記事で、自然な言葉からSQLへの変換でおよそ9割の精度をうたっていますが、第三者による検証は見当たりません。仮に9割が正しいとしても、残りの1割がどの質問で起きるかは事前に分かりません。全体の精度の数字は、目の前の一つの答えが正しいことを保証しないのです。

実際に社内で信用を落とすのは、SQLの文法の誤りよりも、質問の解釈のずれです。「先月の新規顧客数」と聞いたとき、AIが「新規」を初回の購入とみなすか、アカウントの作成とみなすか、試用の申し込みを含めるかで、数字は変わります。どの解釈でもSQLは正しく動き、エラーも出ません。正しく動くSQLが、聞いた人の意図と違う数字を出すことが、自然な言葉の分析でいちばん起きやすい誤りです。

逆に、「AIの数字は使えない」という見方も、道具の作りを見ていません。Querio は答えの横にSQLとコードを残すので、読める人がいれば確かめられます。問題は、確かめられる作りになっていても、確かめる人と頻度が決まっていないことです。信用は精度の高さから生まれるのではなく、確かめた記録の積み重ねから生まれます。

課題1：同じ質問に、部門ごとに違う数字が返る

部門に開いて最初に起きるのは、同じことを聞いたはずの二人が、違う数字を会議に持ってくる事態です。マーケの担当は「問い合わせからの商談数」を広告からの流入で絞って数え、営業の担当は商談の登録日で数える。どちらも Querio に自然な言葉で聞いただけで、AIはそれぞれの言い回しに合わせて別の条件を付けています。どちらの数字も、その人の質問に対しては正しい答えです。

6月の更新で探索が既定で非公開になったことも、この課題を見えにくくします。非公開は情報を守るには適切な既定ですが、誰がどんな条件で数えたのかが、共有されるまで他の人から見えないということでもあります。会議の場で初めて数字の食い違いに気づき、どちらの条件が正しいかをその場で決めることになりがちです。そうした場面が二度三度と続くと、道具そのものが信用されなくなります。

定義をコンテキストに書いておけば揺れは減りますが、ゼロにはなりません。定義にない言い回しや、定義どうしを組み合わせる質問では、AIが条件を補います。補った条件を答えに書かせ、それを人が読むことを前提にしない限り、食い違いは繰り返されます。

課題2：AIが書いたSQLを、誰も読んでいない

二つ目の課題は、SQLが画面に残っていても、部門の人はそれを読めないことです。読めない人に「SQLを確認してから使ってください」と求めても、実際には確認されません。一方でデータの担当者は、部門の人が作った探索の一つひとつを見る時間がありません。読める人は見る時間がなく、見る時間がある人は読めないという状態が、自然な言葉の分析を部門に開いたときの典型的な空白です。

定期実行もこの空白を広げます。8月の更新で、定期実行する探索の結果は保存され、次の更新まで使い回されるようになりました。変更履歴によれば、手で個別に実行し直した場合は保存された結果を使いません。つまり、定期配信で届いた数字と、画面で開いて実行し直した数字が、更新の時点の違いでずれることがあるわけです。受け取る側がこの仕組みを知らないと、ずれをAIの誤りと受け取ってしまいます。

さらに、探索ごとにモデルを選べるようになったことで、同じ質問でも、使ったモデルによってSQLの書き方が変わる余地が生まれました。どのモデルで作った答えかが記録されていないと、翌月に同じ手順で数字を出し直しても、同じ結果になるとは限りません。

課題3：外のAIから、知らないうちに分析が作られる

三つ目は、8月の MCP 対応で生まれた新しい課題です。Claude などのAIの道具に Querio の鍵を設定すれば、そのAIは会話の流れの中でデータ源の一覧を見て、探索を作り、結果を受け取れます。利用者は Querio の画面を開かないまま、外のAIの答えの中に、社内のデータ倉庫から取り出した数字が混ざることになります。便利な半面、数字の通り道が一つ増えるということです。

このとき、外のAIは Querio から受け取った結果を自分の言葉で要約し、ほかの情報と組み合わせて回答します。Querio の画面ではSQLが見えていても、外のAIの回答の中では、どの探索のどの数字かが分からなくなることがあります。会議資料の下書きを外のAIに作らせると、数字の出どころをたどれない資料ができあがります。

もう一つは、鍵の持ち主の問題です。鍵を作れるのはワークスペースの管理者ですが、使うのは鍵を渡された人や、その人が設定したAIの道具です。鍵が個人のAIの道具の設定に入ったまま異動や退職があれば、誰も把握していない接続が残ります。

原因1：確かめる役割を決めずに、部門へ開いている

三つの課題の根は共通しています。一つ目の原因は、部門に開く前に、誰の数字を、どの場面で、誰が確かめるかを決めていないことです。データの担当者は「部門の人が自分で使うもの」と考え、部門の人は「出てきた数字は正しいもの」と考える。その間に、確かめる責任を持つ人がいません。

自然な言葉の分析は、従来の定型のダッシュボードと違い、質問のたびに新しいSQLが書かれます。定型のダッシュボードなら作るときに一度確かめれば済みましたが、Querio では答えのたびに、確かめる対象が新しく生まれます。すべてを確かめるのは無理なので、どの答えを確かめるかを場面で決める必要があるのですが、多くの導入でここが抜けています。

公式の説明も、データの担当者が定義と権限を管理し、業務の人がその上で自分で分析するという分担を描いています。この分担は、定義と権限を持つ側が、部門の答えの確かめ方まで決めてはじめて回ります。道具を配る前に、確かめ方を配る必要があるということです。

原因2：データ源が、既定で全員に開いている

二つ目の原因は、つないだデータの見え方です。6月10日の変更履歴によれば、データ源ごとに使える人を絞れるものの、特定の利用者を加えるまでは、ワークスペース全体に開いたままです。つまり、データの担当者が検証のためにつないだ売上や顧客のデータ源は、何もしなければ、部門に開いた時点で全員の質問の対象になります。

公式の記事は、データ倉庫への接続を読み取り専用とし、行単位の制限（誰がどの行を見られるか）をコンテキストで定めて、すべての問い合わせに適用すると説明しています。読み取り専用であれば、AIの書いたSQLがデータを消したり書き換えたりする心配は小さくなります。しかし、読み取り専用は「壊さない」ことの保証であって、「見せない」ことの保証ではありません。

マーケの担当が顧客の個人情報の列を含む表に質問し、その結果を表計算に書き出して共有すれば、そこから先は Querio の外の話になります。見せてよい範囲は、つなぐときに決めておくしかありません。

原因3：鍵と MCP の接続が、承認の外で増える

三つ目の原因は、鍵と接続の管理です。範囲を絞った鍵は統制のための機能ですが、どの範囲で、誰に、何のために発行したかを記録しなければ、鍵は増えるだけです。最後に使われた日時を確かめられる機能は、使われていない鍵を見つけて失効させるためのものですが、誰も一覧を開かなければ役に立ちません。

MCP の接続は、AIの道具の側の設定でもあります。社員が個人で使っているAIの道具に鍵を設定すれば、Querio の管理者からは鍵が使われていることは分かっても、その先でどんな会話に数字が使われたかまでは見えません。接続の承認を、Querio とAIの道具のどちらの管理者が持つのかが決まっていないと、双方が自分の担当ではないと考えます。現場で起きがちな失敗をまとめると、次のようになります。

• 検証のためにつないだ本番の顧客データ源を、使える人を絞らないまま部門に開く
• 管理者が広い範囲の鍵を作り、そのまま部門の担当に渡す
• 外のAIで作った会議資料の数字を、Querio の探索に戻って確かめない
• 定期配信の数字と画面の数字のずれを、AIの誤りだと決めつけて使うのをやめる
• どのモデルで作った答えかを記録せず、翌月に同じ数字を再現できない

対策1：SQLを確かめる役割を、場面と頻度で決める

最初の対策は、確かめる役割を表にしておくことです。すべての答えを確かめるのではなく、答えをどこで使うかによって、確かめる人と深さを変えるのが現実的です。目安は次のとおりです。

答えを使う場面	確かめる人	確かめる中身
自分の仮説づくり・下調べ	質問した本人	AIが補った条件を答えに書かせ、意図と合うかを読む
部門内の週次の共有	部門のSQLが読める担当	期間、対象のデータ源、条件、除いたものの有無
会議資料・役員への報告	データの担当者	SQLの読み合わせと、別の経路での検算
社外に出す数字	データの担当者と責任者	検算に加え、定義の版と取得日時の記録

部門の人に求めるのは、SQLを読むことではなく、AIに前提を書かせて、それを読むことです。「対象の期間、使った表、除いた条件、新規の定義を、答えの前に箇条書きで示して」と毎回頼めば、SQLが読めなくても意図とのずれに気づけます。これは前提を説明させる指示であって、AIに正しさを判断させるものではありません。正しいかどうかを決めるのは、前提を読んだ人です。

部門ごとに一人、SQLが読める担当を置けるとよいでしょう。データの担当者がすべてを見るのではなく、部門の担当が週次の共有の前に読み、迷ったものだけを上げる流れにすると、確かめる量が現実的な範囲に収まります。上がってきた迷いは、コンテキストの定義に足す候補にもなります。

対策2：つないでよいデータを、三段に分けてから開く

二つ目の対策は、データ源を部門に開く前に、性質で三段に分けることです。集計済みで個人を含まないもの、個人を含むが業務で必要なもの、つながないものの三つです。広告の配信実績やサイトの集計値は一段目、商談や顧客の一覧は二段目、人事や給与、健康にかかわる情報は三段目に入ります。

一段目はワークスペース全体に開いてよいでしょう。二段目は、データ源ごとに使える人を明示的に加え、行単位の制限を設定してから開きます。三段目は、そもそも Querio につながない判断をします。読み取り専用の接続であっても、つないだデータ源は、AIへの質問の材料になりうるからです。分析の担当者が試しにつないだまま、という状態を残さないことも大切です。

二段目に入れるデータ源は、つなぐ前に、どの列が個人を特定できる情報かを洗い出しておきます。部門の分析に必要なのは、たいてい件数や金額であって、氏名や連絡先そのものではありません。必要な列だけを持つ見せ方（ビュー）をデータ倉庫の側で作り、それだけをつなぐほうが、Querio の中の設定に頼るより確実です。

対策3：MCP の接続は、鍵ごとに読むところから承認する

三つ目の対策は、外のAIからの接続を、鍵の単位で承認することです。鍵を発行するときは、使う人、使うAIの道具、触れてよいデータ源、目的、見直しの期日を記録します。鍵は一度しか表示されないため、渡し方も決めておきます。チャットに貼り付けて渡す運用は避けます。

最初は、データ源の一覧を見て、既存の探索の結果を読む用途から始めます。外のAIに新しい探索を作らせるのは、その次の段階です。外のAIで作った分析は Querio の側にも探索として残るため、外のAIの回答に出た数字は、Querio の探索に戻って条件を確かめることを約束にします。外のAIの要約だけで数字を使わない、という線です。

月に一度は鍵の一覧を開き、最後に使われた日時を見て、使われていない鍵を失効させます。異動や退職の手続きに、鍵の失効を組み込んでおくことも欠かせません。エージェントを止めれば処理も取り消される作りにはなりましたが、いつ止めるかの判断は人が持つことに変わりはありません。

対策4：会議資料に使う前に、別の経路で検算する

四つ目は、会議資料や役員への報告に数字を出す前の検算です。AIが書いたSQLを読むだけでは、前提そのものの誤りを見逃します。別の経路で数えて、おおむね同じ数字になるかを確かめるのが検算の要点です。次の五つの手順を、資料を作る人の決まりにしておきます。

五つ目の手順は、翌月に同じ数字を出し直すときに効きます。どの探索から、いつ、どのモデルで出した数字かが残っていれば、数字が変わったときに、データが変わったのか、条件が変わったのかを切り分けられます。説明できない差が残った数字は、正しいかもしれなくても会議に出さない、という決まりを先に置いておくと、迷いがなくなります。

数字が動いた理由の説明も、AIに任せきりにしないことです。Querio に原因を尋ねれば、もっともらしい理由が返ってきますが、それは仮説です。理由の候補をAIに出させ、裏付けのデータを人が当たるという分担にします。広告の配信の変更、価格の改定、季節の要因など、データ倉庫の外にある事情は、AIには見えていないことが多いからです。

何が社外に出るか：言語モデルの行き先と、外のAI

Querio に質問すると、その質問と、答えを作るのに必要な情報が言語モデルに送られます。公式サイトの画面の例では Claude のモデルが選択肢として並んでおり、最上位の契約では、AIの処理を Amazon の Bedrock 上で行う選択肢が示されています。中位以上の契約では、使うモデルを利用者や管理者が選べます。

公式サイトは「利用者のデータで学習しない」と明記し、SOC 2 の認証、行単位の制限、監査の記録、役割に応じた権限を挙げています。一方で、問い合わせのたびに表の構造だけが送られるのか、取り出した行の中身まで送られるのか、送られた内容がどれだけ保存されるのかは、公開の説明からは確かめられませんでした。信頼性の資料をまとめたページも用意されていますが、本記事の執筆時点では公開の形で読めませんでした。二段目のデータ源をつなぐ前に、提供元の資料で確認すべき点です。

もう一つの社外は、MCP でつないだ外のAIです。Querio から外のAIに渡った結果は、その外のAIの提供元の規約に従って扱われます。Querio 側の設定だけでなく、外のAIの組織向けの契約で、学習への利用や会話の保存の扱いを確かめる必要があります。個人向けの契約のAIの道具に鍵を設定させない、という線もここで引いておきます。

費用の増え方と、やめるときに残るもの

料金は、公式の料金ページによれば利用者の人数では数えず、AIのモデルの呼び出し1回を1単位とするクレジットで数えます。無料の契約は月500単位、中位の契約は月10,000単位が含まれ、超えた分は1単位あたり0.25ドル（無料の契約は0.50ドル）です。中位の契約の月額は、料金の案内では2,099ドル、比較表では2,499ドルと表記が食い違っているため、見積もりで確かめる必要があります。

人数で課金されないことは部門に広げやすい半面、使う人が増えるほど、呼び出しの回数がそのまま費用になるということです。多段で考えるエージェントは、一つの質問で何度もモデルを呼びます。外のAIから MCP で探索を作らせれば、その分も数えられます。料金ページには利用状況の見える化、通知、上限の設定が挙げられていますが、どの契約で使えるかは明確でないため、上限を誰が持つかと合わせて確認します。

やめるときには、Git で管理する作りであることが効いてきます。定義やノートブックが自社の保管庫に残るなら、乗り換えても分析の資産は手元に残ります。ただし、どこまでが自社の保管庫に出力され、どこからが Querio の中にしか残らないかは、導入の初期に試しておくべき点です。やめるときは、鍵の失効と、外のAIの道具からの接続の削除も忘れずに行います。

入れる前に確かめる項目一覧

ここまでの課題と対策を、契約の前に確かめる項目として並べます。すべてに答えが出てから部門に開くのが理想ですが、少なくとも上の四つは、最初の利用者を招く前に決めておきます。

• 答えを使う場面ごとに、確かめる人と確かめる中身を決めたか
• 部門ごとに、SQLが読める担当を置いたか
• データ源を三段に分け、個人を含むデータ源に使える人を明示的に加えたか
• つながないデータを決め、検証用につないだデータ源を片付けたか
• 鍵の発行の記録（人・道具・データ源・目的・期日）と、月次の見直しを決めたか
• 外のAIの道具は組織向けの契約に限り、学習と保存の扱いを確かめたか
• 言語モデルに送られる情報の範囲と保存の期間を、提供元の資料で確かめたか
• クレジットの上限と通知を、誰が持つかを決めたか

項目のうち、言語モデルに送られる情報の範囲は、提供元に確かめるしかありません。それ以外は、社内で決めれば済むことです。道具の機能が足りないから信用されないのではなく、社内の決めごとが足りないから信用されない、というのがこの記事の結論です。

まとめ

Querio は、自然な言葉の質問をSQLに変えて社内のデータ倉庫に問い合わせ、その過程をノートブックとして残す分析基盤です。2026年の夏には、会話の非公開の既定化、データ源ごとの利用者の制限、範囲を絞った鍵、MCP からの分析の作成が加わり、部門に広げるための部品はそろってきました。それでも社内で数字が信用されないとすれば、原因は精度ではなく、確かめる役割、開くデータの範囲、鍵と外のAIの接続を決めていないことにあります。答えを使う場面ごとに確かめる人を決め、AIには前提を書かせて人が読み、会議資料の前には別の経路で検算する。この順番を守れば、自然な言葉の分析は「速いが怪しい数字」から「速くて確かめられた数字」に変わります。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。