PromptQLレビュー（2026年）：Hasuraのデータエージェントを検証する

PromptQLの正体（そして誰も発表しなかった方向転換）

私は仕事としてAIエージェントを作っているので、PromptQLは他の多くの新しいエージェント製品と同じように、大きな精度の主張と、あまりにも綺麗すぎるデモとともに私の机の上にやってきました。この製品をレビューする上で有用なのは、製品が実際に何であるかと、現在どのようにマーケティングされているかを切り分けることです。というのも、この一年でこの二つは乖離してしまったからです。

PromptQLは、オープンソースのGraphQLエンジンを出荷し、2年間で1億ダウンロードを突破した企業、Hasuraによるものです。創業者のTanmai Gopal氏とRajoshi Ghosh氏は2500万ドルのシリーズBと1億ドルのシリーズCを調達し、2025年末までにVentureBeatは同社を、時給900ドルのAIエンジニアを販売する10億ドル超規模のビジネスだと評していました。Tanmai氏が使っているフレーミングは、あなたのデータの「顧客」が変わったというものです。

「私たちは、アプリはもはやデータへのアクセスを必要とする最も重要な存在ではないと気づきました。未来は、AIがデータと対話し、ユーザーに代わってデータにアクセスする世界です。」

Tanmai Gopal、VentureBeatインタビュー

つまり2025年の売り文句は明確でした。エンタープライズデータの上に構築された信頼性のある自然言語レイヤーであり、text-to-SQL、tool-calling、RAGと対比されるものでした。しかしその後、ホームページは変わりました。現在のpromptql.ioは、「マルチプレイヤーAIエージェント、ClaudeやChatGPTを思い浮かべてほしいが、共有スレッドと共有のブレインを備えたもの」という打ち出し方をしており、見出しの課題はSlack、ドキュメント、チケット、CRM、ウェアハウステーブルにまたがるコンテキストの劣化です。名指しされているロゴは、Cisco、McDonald's、Instacart、Swiggy、Lightspeedといった大物揃いです。

どちらの説明も真実であり、同じエンジンを指しています。しかし予備知識なしにサイトに辿り着けば、PromptQLはGleanや共有社内ナレッジベースに少し似た、チームのナレッジツールだと思うかもしれません。しかし内部の仕組みは依然としてデータエージェントです。これを覚えておいてください。料金、ドキュメント、ベンチマークはすべて、wikiのラッパーではなくデータエンジンについてのものだからです。

PromptQLの仕組み：まず計画し、それから実行する

ここは私が実際に敬意を払っている部分であり、この製品が肩をすくめられるだけでなくレビューに値する理由です。ほとんどの「あなたのデータに対するAI」ツールは、データを読む、計算する、回答を書くという全作業を一つのコンテキストウィンドウの中でモデルに丸投げしています。PromptQLはこれを二つに分けています。

Playgroundで質問をすると、PromptQLはまずクエリプランを返します。これは、データをどのように取得・フィルタリング・処理するかを、前提としている仮定も含めて平易な言葉でステップごとに分解したものです。これを読むことができ、鉛筆アイコンで編集することもできます。編集すると、PromptQLは「それを記憶し、今後のスレッドのために自己修正」します。この透明性は、流し読みする人でも飛ばすべきではない部分です。データが動く前に計画を目にすることができるのです。

そのプランは、実際のコードとして実行されます。PromptQLはPythonを使ってデータを取得・整理し、どのステップも展開して、実際に自分のデータソースに対して実行されたPythonとSQLを確認できます。これは製品全体がその上に成り立っている一節であり、創業者の言葉で言えばこうです。

「私たちは回答を生成する代わりに、あなたのビジネス固有のドメイン特化言語でプランを生成します。それらのプランは、ランタイムでの検証とポリシーチェックを伴う決定論的なアクションへとコンパイルされます。」

Tanmai Gopal、VentureBeatインタビュー

結果はアーティファクトとして得られます。これは構造化されたテーブル、テキスト、あるいはチャートで、モデルのコンテキストの外側に存在し、後続のステップから参照されます。これがスケールにおける巧妙な点で、つまりPromptQLはコンテキストウィンドウよりもはるかに大きなデータに対して作業できるということであり、モデルが気づかぬうちにそれを見失うことがありません。分類・要約・抽出・可視化といったセマンティックな作業は、それぞれ限定されたコンテキストの中で独立して実行される、狭い範囲に特化したAIプリミティブによって処理されます。そのため、LLMは常に小さく明確に区切られたスライスについてのみ推論すればよいのです。

最後に、すべての回答にはクエリの複雑さ、データの精度、モデルの確信度に基づいた信頼性スコアが付与され、その分析が何を含み何を含まなかったかについての評価メモも添えられます。スコアが低ければそれを修正でき、その修正は次回にも引き継がれます。サポートの世界から来た身としては、このパターンには見覚えがあります。これはハルシネーションを防ぐことの背後にあるのと同じ発想であり、つまりシステムは平然と推測するのではなく、確信が持てないときはそう伝えるべきだということです。

PromptQLが実際に解決しようとしている信頼性の問題

これがなぜ重要なのかを理解するには、素のモデルが実際のデータに関する質問でどれほど酷い成績を出すかを見る必要があります。Tanmai氏はBerkeley Data Agent Benchmarkを引き合いに出しており、そこではフロンティアモデルがデモから想像されるよりもはるかに低いスコアしか出せていません。

現実世界のデータに関する質問では、BerkeleyのベンチマークはOpus 4.6を43%、Gemini 3 Proを38%、GPT-5.2を25%としており、素のデータベースクエリ生成は「ほぼ0%」というスコアです。ベンチマーク自体の解釈は、エージェントは「多くの場合正しいデータを選択できるが、計算の計画や正確な実装に失敗する」というものです。これはまさに、PromptQLのプラン・アンド・実行の分離が狙っているギャップであり、だからこそ創業者はある一つの言葉を繰り返し強調しています。

「最大の問題は、単に質問に正確に答えられないことではありません。大きな問題は、AIが実際には正確でないときでさえ、正確であるかのように振る舞うことです。つまりAIは自信満々に間違えるのです。それが問題なのです。」

Tanmai Gopal、VentureBeatインタビュー

Hasuraはこの失敗を四つのモードに分類しており、この2x2のマトリクスは、PromptQLであれ他のツールであれ、あらゆるAIデータ分析ツールを評価する前に頭に入れておくべき最も有用なものです。

さて、あの「100%の精度」という見出しについてです。Hasuraはそれが釣り文句であることを清々しいほど正直に認めています。同社は「100%の精度という主張は技術的には成立しない」と認め、実際の主張は100%の再現性であるとしています。これは計算がモデルの推論ではなくコードとして実行されるためです。より限定的なCRMArena-Proのデータベース・数値タスクでは、最先端の手法で引用される30〜60%に対し、100%を報告しています。この切りの良い数字は話のきっかけとして扱い、再現性こそが実際の製品の特徴だと捉えてください。

際立つ機能

中核となるループを超えて、PromptQLを一般的なAIナレッジベースチャットボットと区別するいくつかの点があります。

本物のAPIになる自動化。 ワークフローがPlaygroundで機能するようになったら、コーディング不要で、Zapier、Slack、cronジョブ、あるいは独自のアプリから呼び出せるHTTPエンドポイントとしてデプロイできます。これにより、一度限りのスレッドが再現可能なビジネスプロセスへと変わります。もし私がデータチームを率いるなら、最も頼りにするであろう機能です。

メタデータによるシステム横断的な結合。 PromptQLはHasura DDNの上に構築されているため、スーパーグラフが複数のサブグラフを縫い合わせ、リレーションシップは「同一のデータソースに裏付けられている必要はありません」。実際には、これはPostgresとSaaS APIを結合し、両者にまたがって推論できることを意味し、Snowflakeや単一のウェアハウス専用に構築されたツールが苦戦する部分です。

自ら構築されるコンテキストレイヤー。 2026年版のラッパーには、Slack、Google Docs、Snowflake、PostHog、Salesforceから自動的に情報を取り込むwikiが追加されており、リビジョン履歴と監査証跡を保持し、範囲を限定したアクセス（外部・内部・個人・機密）を強制します。これは、SalesforceのAIツールにも見られるようなコンテキスト連携の試みです。あなたが行った修正は共有の「スキル」となり次の担当者に引き継がれますが、これはすべてのチームが戦っているナレッジマネジメントの問題が、エージェントの姿をまとっただけとも言えます。

自分のモデルを持ち込める、そしてそれが請求額に直結する。 PromptQLは、ClaudeやGPTから、Fireworks経由で提供されるDeepSeek、Kimi K2、GLMといったオープンウェイトモデルまで、あらゆるLLMを実行できます。スレッドごとに、あるいはスレッドの途中でもモデルを切り替えられ、MCP経由での相互運用も可能です。これは覚えておいてください。モデル選択こそが、コストに対する最大のレバーだからです。

PromptQLの料金：実際に支払うことになる金額

PromptQLにはシート課金がありません。100%従量課金制で、OLU（Operational Language Unit）と呼ばれる正規化された単位で請求されます。これは、あらゆるモデルにわたる入力・出力・キャッシュ・キャッシュ作成トークンを一つの一貫した数値にまとめるもので、モデルを切り替えても請求額の形が変わらないようになっています。

Hasuraが提示する典型的なタスクコスト（0.14ドルのレートで）は正直で小さなものです。シンプルなデータタスクなら2 OLU未満（0.28ドル未満）、複雑なレポートなら約10 OLU（約1.40ドル）、綿密な調査なら約40 OLU（約5.60ドル）です。

ここに落とし穴があり、それは予算の観点からこのPromptQLレビュー全体の中で最も重要な点です。OLUあたりの価格は固定ですが、選ぶモデルによってタスクが消費するOLU数が変わり、その差は非常に大きいものです。Claude Opus 4.6を基準の1.0倍とすると、GPT-5.2は0.42倍、Kimi K2.7は0.17倍、DeepSeek V4 Flashは低いときには0.018倍にまで下がり、Hasuraはこれを同じ作業に対して最大57倍安いと表現しています。つまり、同じレポートでも、モデルのドロップダウンをどう選ぶかによって、数ドルにも数セントにもなり得るのです。

その計算を頭の中でやってもらうよりも、自分自身の数値を入力してみてください。

ここで重要なのは一つの数字ではなく、習慣です。PromptQLでは、日常的なタスクにオープンウェイトモデルを選ぶかどうかが、丸め誤差程度で済むか、実際に無視できない項目になるかの分かれ目になります。これはAIエージェントのコストに適用しているのと同じトータル・コスト・オブ・オーナーシップの考え方であり、ただそのダイヤルがモデルのドロップダウンになっているだけです。

実際にPromptQLについて人々が語っていること

ここでは率直に言わなければなりません。公正なレビューとは、見つけられたことと同じくらいはっきりと、見つけられなかったことも語るものだからです。PromptQLの公の場での存在感は薄いものです。執筆時点でG2にもCapterraにもレビューは一件もなく、公式の「Show HN」ローンチも二回とも反応はほとんどありませんでした。一方は6ポイント、コメント4件、もう一方は6ポイント、コメント1件です。会話のほとんどはHasura自身のチャンネル内で行われています。

見つかるのは、Hasuraの既存の開発者ベースがこの方向性を気に入っているということです。ローンチに反応した、ある長年のユーザーの声です。

「私はHasuraを使った本番のコードベースを10個以上構築・運用してきました。個人的には、バックエンドを構築するならSupabaseやPayloadなどよりも良い選択肢だと思っています。彼らがこのプラットフォームのためにLLM関連のリソースに時間を投資していることは、当時これを選んで良かったと思わせてくれます。」

purposesystem、Hacker News

最も強力なパフォーマンス数値はベンダー自身によるものなので、それを踏まえて評価する必要があります。Hasuraのチームは従来型のtool-callingと比較して「精度は約2倍、再現性は約4倍」と報告しており、Tanmai氏は「まだベータ版の製品であるにもかかわらず、3〜5か月で7桁の取引が成立している」と主張しています。これらは実際の発言ですが、あくまで企業が自社について語っているものであり、独立したテストではありません。また、それらを突き合わせて検証できるだけの第三者による製品レビューの蓄積もまだありません。CiscoやMcDonald'sのようなロゴを掲げる製品としては、この静かなコミュニティがこのレビューにおける最大の黄色信号です。

PromptQLが優れている点、そうでない点

ドキュメント、Playgroundのスクリーンショット、料金ページに浸りきった上での、私の正直な評価表です。

PromptQLを使うべきなのは、システムをまたいだ雑然としたデータを抱え、本物の信頼性要件があり、セマンティックレイヤーをモデル化するだけのエンジニアリング意欲を持つ、データ・分析チームです。プラン・アンド・実行という設計は、あなたのデータに対する自信満々に間違えるAIに対して私が見た中で最も説得力のある回答であり、オートメーションをAPI化する機能は本物の勝ちポイントです。

避けるべきなのは、すぐに使えるアシスタントが欲しい場合、データエンジニアのいない小規模チームである場合、あるいは実際の仕事がカスタマーサポートである場合です。これはルールベースのチャットボットの代替ではありませんし、そもそもヘルプデスク向けにはまったく作られていません。

このアイデアのサポート版としてのeeselを試す

「作業過程を示し、確信が持てないときはそう伝えてくれる、根拠に基づいたエージェント」というアイデアに納得してここまで読んでくださったものの、あなたのデータがウェアハウスではなくヘルプデスクにあるのなら、それはまさに私がeesel AIで取り組んでいる課題です。PromptQLはプラン・アンド・実行の規律をデータ分析の世界に持ち込みますが、eeselは「推測せず、根拠を持たせ、まず証明する」という同じ発想をサポートの世界に持ち込みます。

具体的には：eeselはあなたのSlack、ヘルプデスク、そしてConfluenceやNotionといったナレッジソースに接続し、その知識をもとに引用付きで回答し、幻覚を起こす代わりにエスカレーションし、そして――これがなければ出荷しないという部分ですが――実際の顧客に返信する前に過去のチケットでシミュレーションを行います。8,000社以上の顧客において、初月からティア1のボリュームのかなりの部分を実際に解決しており、料金は従量課金制でシート課金はありません。PromptQLが信頼できるデータの仲間であるなら、eeselは信頼できるサポートの仲間です。

eeselを無料で試すことができ、数分でソースを接続し、本格的に導入する前にシミュレーションを実行できます。