なぜ QAL なのか?
すでに SQL に慣れている人の最初の反応は、だいたい 「SQL があるのに、なぜわざわざ新しいクエリ言語を覚えさせるのか?」 です。妥当な疑問です。このページはそれに答えます。
短く言うと: SQL は、クラウドデータウェアハウス上で人間が作業するための優れた言語です。QAL は、AI アシスタントが小さな現実のサーバーに対して作業するための言語です。 これは本当に違う2つの問題であり、クエリ層の正しい形は両者で違います。
QAL が解きたかった2つの本命問題
1. AI アシスタントはほぼ一度もリトライしなくていいべきだ
私たちが目指した初期体験はこうです: ユーザーが自然言語で質問し、AI がクエリを組み立て、クエリが走り、答えが返る。一発。リトライなし。
SQL でこれを成立させるのは、いくつかの理由で難しいです。
- スキーマの進化でカラム名やテーブル名が動きます。プロンプトや few-shot サンプルは数週間で陳腐化します。
- 有効なクエリの空間が広すぎます。小さな誤字は、構造エラーではなく、静かに間違った答えを生みます。
- JOIN の挙動は組み立て時点では予測しづらいです。条件を1つ落としただけで、行数が爆発したり DB が刺さったりします。
- SQL は AI が絶対に出してはいけない形 (クロス結合、再帰 CTE、
DELETE) を表現できてしまいます。
QAL は意図的に狭いです。有効なクエリはすべて同じ5つのトップレベルキー (tracking_id, materials, time, make, result) を持ちます。マテリアル名、カラム名、機能名はすべて機械可読仕様書に列挙されていて、AI は実行時にそれを読めます。構造的な間違いは 構造的に不可能 になり、残るのは意味的な間違いだけ。意味的な間違いは、AI に目に見える形で出してほしい種類の間違いなので、それでいいのです。
2. クラウドウェアハウスではなく、安価なホスティングで動くべきだ
もうひとつの選択肢は 「全部 BigQuery / Redshift / Snowflake に入れて SQL を書けばいい」 というもので、私たちは繰り返しその方向に押されました。しかしこれは QA ZERO の中核的な約束と真っ向から矛盾します。
データのパワーを、ウェブサイトを持つすべての人に。クラウドデータウェアハウス契約を払える人だけでなく。
AI アシスタントに自分のサイトについて尋ねる前に BigQuery を契約してもらわないといけないなら、この API が対象にしている人の大多数を最初から除外してしまいます。シェアードホスティング、小さい VPS、安い Lightsail — これが狙いです。クエリ層は、そこで速く動く必要があります。特殊なインフラに頼らずに。
QAL はファイルベースのカラム型ストア (ColumnDB) と、別のバックエンドに差し替え可能な Storage レイヤを標準装備しています。素の MySQL テーブルに対して10秒かかるクエリが、QAL 経由なら1秒未満で返る — これを、誰にも追加料金を払わずに実現することが前提になっています。
この2つが QAL の存在理由です。以下は同じ設計から副次的に得られるメリットですが、2つだけ覚えるならこの2つを覚えてください。
副次的なメリット
3. AI が見るスキーマは安定している
SQL では、テーブル名やカラム名は実装に紐付いています。実装が変わる — カラムがリネームされる、テーブルが分割される — と、名前をハードコードしていたプロンプトや few-shot サンプルは静かに壊れます。
QAL が公開しているのは マテリアル で、これは意味論的な言葉で定義されています(「1行 = 1ページビュー」「1行 = 1クリックイベント」)。内部ストレージが変わってもマテリアルの形は変わらないので、2年前に QAL を学習した AI が今日のサーバーでもそのまま動きます。
4. 生のスキーマはサーバーの中に留まる
AI に直接 SQL アクセスを渡すということは、生のテーブル構造 — 全カラム、全インデックス、全 FK — を渡すということです。これはセキュリティとプライバシーの姿勢を同時にまとめて悪化させますし、運用も厳しくなります。
QAL は裏のストアを意図的に抽象化しています。AI クライアントはマテリアルとカラムを知っているだけで、それが ColumnDB なのか MySQL なのか、ただのファイルなのか、まだリリースしていないものなのかは知りません。これは意図的です。
5. クエリコストは実行前に見積もれる
すべての QAL クエリは result.limit と keep の集合を明示します。これは AI — またはサーバー側のスロットル — がクエリのコストを 実行前 に見積もって、予算を超えるものを弾いたり削ったりできることを意味します。
SQL では一般にこれができません。ミスった JOIN や大きなテーブルに対する SELECT * ひとつで、アシスタントが DoS の発生源に変わります。QAL はその種の問題が存在しないように設計されています。
6. ドメイン語彙が言語に埋め込まれている
SQL はスキーマ設計者が選んだ語彙をそのまま採用します。QAL は — session, pv, goal, click_event, page_version — というドメイン語が言語自体に組み込まれています。このサイトについて事前知識がゼロの AI でも、妥当な選択ができる。言語自体がドメインモデルを運んでくれるからです。
7. 表面積が小さいから安全だ
これは見落とされがちな点です。QAL は SQL に比べて機能セットを意図的に絞っています。これを「未完成」と読む誘惑がありますが、そうではありません。
表面積が小さいこと自体が目的です。 QAL が 持っていない 機能それぞれが、AI ができない種類のミスに対応しています。機能が少ないということは、クエリを壊す方法が少ない、サーバーを傷つける方法が少ない、間違った答えを静かに返す方法が少ない、ということです。欠けている機能は安全資産であって、恥じるべき穴ではありません。
本当に必要な機能があれば、since タグを付けて慎重に追加します(クライアントが可用性を検出できるように)。必要がなければ、外しておくこと自体が積極的な選択です。
QAL がやろうとしていないこと
境界を明示しておきます。
- QAL は 汎用の分析言語ではありません。 QA ZERO が見える範囲のサイトのウェブ行動データに形を合わせてあります。
- QAL は BI ツールの代替ではありません。 ドラッグ&ドロップのダッシュボードビルダーが欲しければ、BI ツールを使ってください。
- QAL は 表現力を目指していません。 目指しているのは AI が組み立てたときに構造的に正しくなる ことです。この2つの目標は時に緊張関係にあり、そのときは正しさを取ります。
次に読むページ
- QAL とは何か? — クエリ言語の実際の形を1ページで。
- Materials, Views, Result — 3つの動く部品。
- AI Instructions — AI クライアントが従うことを期待されるルール集。