Anyquery レビュー: SQLite を土台に 60 以上の外部ツールを SQL で横断する

Anyquery が埋めるのは「API ごとにクライアントを書く」手間の穴

GitHub の issue、Notion のデータベース、Airtable のレコード、ローカルの Parquet や CSV。これらを 1 つの問いで横断したいとき、素直にやれば各サービスの SDK を呼ぶスクリプトを書き、結果を手元で結合することになる。認証方式もページネーションの作法もサービスごとに違い、使い捨ての調査のたびに同じコードを書き直すことになる。Anyquery はこの部分を SQL に寄せる。README は「SQL query engine that allows you to run SQL queries on pretty much anything」と述べており、対象としてファイル、データベース、アプリの 3 種を挙げている。読み手として想定されているのは、データ分析基盤を持たないが複数ツールのデータを突き合わせたい開発者、あるいは LLM に自前のデータを読ませたいが専用のコネクタを書きたくない人だ。BI ツール向けの MySQL 互換エンドポイントも用意されているので、Metabase や TablePlus から接続する使い方も README には示されている。

SQLite を土台にし、外部接続はプラグインに追い出す

アーキテクチャの核は SQLite だ。README は「It's built on top of SQLite and uses plugins to extend its functionality」と明記している。つまりクエリのパース、実行計画、関数、JOIN は SQLite 側が担い、外部サービスへのアクセスはプラグインという別レイヤに切り出されている。プラグインは公式レジストリからインストールする形で、README のバッジはレジストリの JSON エンドポイントからプラグイン数とクエリ数を取得して表示している。自前のプラグインを書く道も用意されている。加えて「Anyquery can also load any SQLite extension」とあり、既存の SQLite 拡張をそのまま読み込める。この設計の帰結として、外部 API の呼び出しは SQL の実行中に同期的に発生する。JOIN の相手がリモートサービスであれば、その分のレイテンシはクエリ全体に乗る。SQLite の拡張機構を土台にしている以上、リモート側のテーブル統計を持たない状態でプランナが動く場面も出てくるはずで、大きなテーブル同士の JOIN を外部サービス越しに投げるのは得策ではない。

インストールは配布チャネルが広く、Go ビルドだけ条件が厳しい

導入経路は多い。macOS と Linux 向けの最短手順は次の 1 行で、README によればプラットフォームに合ったバイナリを取得しチェックサムを検証したうえで PATH に追加する。sudo は不要とされている。

curl -fsSL https://anyquery.dev/install.sh | sh

バージョンを固定したい場合は ANYQUERY_VERSION、導入先を変えたい場合は ANYQUERY_INSTALL_DIR を設定する。更新は同じコマンドの再実行だ。Windows は Scoop、Winget、Chocolatey が案内されている。パッケージマネージャ経由なら brew install anyquery、AUR では yay -S anyquery-git や paru -S anyquery-git、APT と YUM/DNF はリポジトリ定義を追加してからインストールする手順が README に記載されている。注意点として、APT と YUM の手順は trusted=yes や gpgcheck=0 を含む。リポジトリの署名検証を無効化する設定なので、その意味を理解したうえで使うべきだ。ソースから入れる場合は Go 1.26 以上と C コンパイラが要る。CGO_ENABLED=1 go install -tags "vtable fts5 sqlite_json sqlite_math_functions" github.com/julien040/anyquery@main という形で、go-sqlite3 経由の cgo に依存するため gcc、clang、Windows では mingw ツールチェインが PATH に必要になる。

LLM に読ませる経路は MCP と関数呼び出しの 2 本

LLM 連携は Model Context Protocol 経由が主線だ。README が示す起動方法は 2 つある。LLM クライアントに起動させる場合は anyquery mcp --stdio、HTTP と SSE のトンネルでつなぐ場合は anyquery mcp --host 127.0.0.1 --port 8070 を使う。MCP に対応しないが関数呼び出しには対応するクライアント向けに、anyquery gpt というコマンドも用意されている。このコマンドが返す ID を ChatGPT や TypingMind の画面に貼り付ける、というのが README の説明だ。ここで押さえておきたいのは、LLM に渡るのは SQL を組み立てる能力であって、データそのもののコピーではないという点だ。MCP サーバーが動いている間、モデルはスキーマを見てクエリを発行できる。したがって接続したプラグインが持つ権限の範囲が、そのままモデルから触れる範囲になる。読み取り専用のプラグインだけを入れておくのか、書き込み系も入れるのかは、MCP サーバーをどのクライアントに登録するかと同じ重さで決める必要がある。

MySQL サーバーとして立てる使い方と、その素朴な限界

anyquery server & でサーバーを起動し、mysql -u root -h 127.0.0.1 -P 8070 のように MySQL 互換クライアントから接続する。README は TablePlus や Metabase の接続ガイドを案内している。BI ツールから見れば Anyquery は 1 台の MySQL サーバーにすぎないので、ダッシュボードのデータソースとして登録できる。ただし、この構成を本番の集計基盤として使うのは筋が悪い。土台が SQLite である以上、同時実行の書き込みや大規模な並列集計を想定した作りではないし、接続先の実体は外部 API だ。ダッシュボードを開くたびにリモートサービスへクエリが飛ぶ構成になり、レート制限や一時的な障害がそのまま画面のエラーになる。向いているのは、手元の調査用に立てて自分のクライアントから覗く使い方だ。チームに配る常設のクエリ層として設計するなら、キャッシュ層やスナップショットの設計を別途考える必要がある。

セキュリティ修正が続いている事実をどう読むか

リリース履歴を見ると、0.4.5 が「Security fixes」、0.4.6 が「Security fix again」、0.5.0 が「Sandbox strengthening」と、直近 3 版のうち 3 版すべてがセキュリティ関連の見出しになっている。これは開発が活発である証拠であると同時に、外部サービスの認証情報を扱い、LLM にクエリを発行させるソフトウェアとしては、攻撃面が現実に存在することを示している。プラグインは外部 API のトークンを保持し、MCP サーバーはモデルからの入力を SQL に変換する。サンドボックスの強化が版を重ねて行われているということは、初期の設計では想定していなかった経路が後から見つかっているという読み方もできる。導入を検討するなら、固定したバージョンを 1 つ選び、そのバージョンより後のセキュリティ修正の内容を追うほうがよい。常に最新を追う運用は、この種のツールでは修正のたびに挙動が変わることを意味する。

Steampipe との違いは、問いの立て方にある

同じ「SQL で外部サービスを引く」領域には Steampipe がある。どちらも PostgreSQL ないし SQLite の上に外部 API を仮想テーブルとして載せる発想だが、重心が違う。Steampipe はクラウドや SaaS の設定を横断的に検査し、コンプライアンスや構成の棚卸しに使う方向に寄っている。クエリは「この設定が全アカウントで揃っているか」といった監査の問いになり、結果を継続的に評価する運用が前提になる。Anyquery の README が前面に出しているのは、どちらかといえば個人の作業台だ。ローカルのファイル、Apple Notes や Chrome のような手元のアプリ、そして LLM クライアント。ファイル形式として Parquet や JSON がトピックに並んでいることも、分析用のデータセットを直接 SQL で覗く使い方を示唆している。監査ではなく探索、常設の評価ではなくその場の問い。同じ技術基盤でも、どちらを選ぶかは自分がどちらの問いを立てるかで決まる。

ライセンス表記と保守コストの見積もり

リポジトリのライセンスは NOASSERTION と表示されており、これは GitHub が既知のライセンスとして認識できなかったことを意味する。MIT や Apache-2.0 のような標準的な識別子が付いていない以上、社内で配布する、あるいは商用製品に組み込むといった判断は、リポジトリ内のライセンスファイルを自分で読んだうえで行う必要がある。ここで法的な助言はできない。保守の面では、直近のリリースが 0.5.0 で 2026 年 8 月、その前が 0.4.6 で 7 月、0.4.5 で 6 月と、およそ 1 か月間隔で版が進んでいる。0.x 系であること、そしてセキュリティ修正が続いていることを踏まえると、バージョンを固定して四半期ごとに見直す程度の運用が現実的だ。プラグイン側は本体と別に更新されるため、本体を上げたときにプラグインの互換性を確認する作業が発生する。プラグインを自前で書く場合、その保守は自分の負担になる。レジストリのプラグインは誰がどの程度メンテナンスしているかを個別に見る必要があり、一覧の数は判断材料にならない。

編集部の結論

Anyquery が向くのは、複数の SaaS やローカルファイルをまたいだ調査を、使い捨てのスクリプトではなく SQL で書きたいエンジニアだ。特に LLM クライアントから自前データを読ませたい場合、MCP サーバーを 1 プロセス立てるだけで接続経路が確保できる点は試す価値がある。逆に、本番の ETL パイプラインや厳密なスキーマ管理が要る用途には向かない。プラグインの認証情報がどのように保存され、どの権限で外部 API を叩くのかを、導入前に自分の環境で確認してほしい。ライセンス表記が NOASSERTION である以上、社内配布の可否は自組織の法務判断なしに決められない。

公式情報源

1. Issues
2. julien040/anyquery on GitHub
3. Project website
4. README
5. Releases