この記事は構文の解説ではありません。QUERY数式が財務モデルのどこで真価を発揮するか、どこで破綻するか、そして別の手段を選ぶべきタイミングはいつかを掘り下げます。
SUMIFSにできないこと、QUERY数式にできること
SUMIFSは集計します。QUERY数式は行を返します。これが本質的な違いであり、どちらのツールをどこで使うかを決定します。
たとえば、取締役会向けの資料として事業部別の貢献利益ビューを作成するとします。SUMIFSでは指標ごと・行ごとに数式を1つずつ書かなければなりません。QUERY数式なら、product_line = "Enterprise" の全行を売上高降順でまとめて返し、ヘッダー行もつけて——これを一度の操作で実現できます。結果は自動的にスピルされるため、ソースデータが更新されれば連動して変わります。
Googleの公式ドキュメントによれば、QUERY数式は「Google Visualization API Query Languageを使用してデータにクエリを実行する」関数です。このクエリ言語は SELECT、WHERE、GROUP BY、ORDER BY、LIMIT、LABEL をサポートしており、レポートクエリで必要になる処理の約8割をカバーします。
複数シートを参照するクロスタブ構文
多くの解説記事が省略している部分——別シートの参照についてです。構文上、範囲は関数呼び出しの中に直接記述する必要があります:
=QUERY('損益計算書'!A:H, "SELECT A, B, C, SUM(F) WHERE B = 'エンタープライズ' GROUP BY A, B, C LABEL SUM(F) '売上高'", 1)
第3引数(1)は、ソースデータのヘッダー行数をQUERY数式に伝えるものです。省略すると、ヘッダー行がデータ行として扱われ、集計結果が崩れます。
前提条件シート(Assumptions)が全体を駆動するモデルで、動的な日付フィルターを使う場合は次のようになります:
=QUERY('損益計算書'!A:H, "SELECT A, B, SUM(F) WHERE A >= date '"&TEXT(前提条件!$B$3,"yyyy-mm-dd")&"' GROUP BY A, B", 1)
ここで日付フォーマットは厳密です。QUERY数式の日付リテラルは、SQL文字列内でシングルクォートに囲まれた yyyy-mm-dd 形式が必要です。フォーマットを間違えると、データの問題のように見えるパースエラーが返され、デバッグに時間を取られます。
QUERY数式のWHERE句による動的フィルタリング
WHERE句は AND、OR、NOT をサポートしています。たとえば2026年第1四半期(1〜3月)の特定コストセンターの実績vs予算差異分析では:
=QUERY('仕訳明細'!A:J, "SELECT B, D, SUM(G), SUM(H) WHERE C = 'CC-412' AND A >= date '2026-01-01' AND A <= date '2026-03-31' GROUP BY B, D ORDER BY SUM(G) DESC", 1)
これにより、第1四半期の特定部門の部署名・勘定科目・実績・予算を、実績金額の大きい順に返します。最も差異が大きい項目から順に確認できるため、予実管理の分析作業に直結します。SUMIFSで同じことをしようとすれば、対象の勘定科目ごとに4つの数式を縦横に複製することになります。
見落としやすい制約が一つあります:SQL文字列内で名前付き範囲を参照することはできません。列の参照は文字(A、B、C)または Col1、Col2 形式でなければなりません。名前付き範囲はデータソース引数として使用できますが、クエリ文字列内では機能しません。WHERE account = 名前付き範囲 のように書いても、エラーも出さずに全件返すという形で静かに失敗します。
集計とGROUP BY
QUERY数式のGROUP BYは、プログラム的な出力においてピボットテーブルの代替になります。ルールはシンプルです:SELECT内で集計関数を使っていない列は、すべてGROUP BYに含める必要があります。これを守らないと「Column X cannot both be aggregated and not aggregated」というエラーが発生します。
サポートされている集計関数は SUM、COUNT、AVG、MAX、MIN の5つです。MEDIAN、STDEV、パーセンタイル関数は非対応——これが現時点での上限です。この5つを超える処理が必要な場合は、QUERY数式の出力結果に対して別途数式を重ねるか、より細かい関数を使ったARRAYFORMULAを検討する必要があります。
2026年4月時点で、GoogleはQUERY数式の集計関数セットを2018年以降拡張していません。四半期別EBITDAの中央値が必要であれば、QUERY数式で行を取得・ソートした上で、結果範囲にMEDIAN関数を別途適用するのが現実的なアプローチです。
LABEL・FORMATによる出力制御
解説記事ではほとんど紹介されませんが、取締役会向け資料を作るうえで重要な2つの句があります。
LABEL は結果のカラムヘッダーを任意の名前に変更します。指定しないと、集計列のヘッダーは SUM Revenue や avg(E) のような自動生成名になります。内部用途なら問題ありませんが、PDF出力やプレゼン資料としては不適切です。
=QUERY('売上明細'!A:F, "SELECT A, B, SUM(C) GROUP BY A, B LABEL A '期間', B 'セグメント', SUM(C) '売上高(百万円)'", 1)
FORMAT は出力に表示フォーマットを適用します。TEXT() と同じフォーマット文字列が使えます。取締役会向け資料の金額列であれば:
"... LABEL SUM(C) '売上高' FORMAT SUM(C) '#,##0'"
これにより、セルの値は数値のまま維持され(モデル内の他の数式から参照可能)、表示上はカンマ区切りのきれいな形式になります。
実務でQUERY数式が破綻するパターン
本番モデルで痛い目に遭う前に把握しておくべき、3つの失敗パターンです。
列の型が混在している場合。 QUERY数式は多数決で列型を判定します。列Bが95%テキストで5%に数値が混在していると、QUERY数式はその列をテキスト型として扱い、WHERE条件での数値比較を無警告でスキップします。ソースデータを整形するか、型を強制するヘルパー列を追加してください。
日付列の空白セル。 日付列にブランクセルがあると、日付範囲でフィルタリングした際にエラーが返されます。回避策は WHERE A IS NOT NULL AND A >= date '...' でNULL除外フィルターを追加するか、ソース範囲に末尾の空白行が含まれないようにすることです。
動的なシート参照。 INDIRECTのようにQUERY数式内でシート名を動的に参照することはできません。=QUERY(INDIRECT("'"&A1&"'!A:H"), ...) という形で範囲部分は動的にできますが、クエリ文字列内の列参照は依然としてハードコードが必要です。シート構成が変わるモデルでは、SUMIFSにはない脆弱性がQUERY数式に生じます。
QUERY数式 vs SUMIFS:使い分けの判断基準
| 判断軸 | QUERY数式 | SUMIFS |
|---|---|---|
| 出力形式 | フィルタリングされた複数行・複数列 | 単一の集計値 |
| ソート | ORDER BY で対応 | 不可 |
| ヘッダー出力 | LABEL 句で自動付与 | 別途手動で記述 |
| 日付範囲フィルター | 1つのWHERE句で完結 | 引数ごとに条件を記述 |
| 他の数式からの参照 | スピル範囲への参照が必要 | 単一セル参照で容易 |
| データ型の堅牢性 | 型混在に弱い | 比較的安定 |
| 動的シート参照 | INDIRECT で範囲のみ動的化可 | INDIRECT と完全に互換 |
| 最適な配置場所 | レポート・出力シート | 計算エンジン(中間集計) |
行を返す必要があるとき——フィルタリングされたリスト、動的なレポートスライス、ソートされた出力——はQUERY数式を使います。他の数式が参照する固定セルに単一の集計値が必要なときはSUMIFSを使います。よくある間違いは、実質的にフィルタリングテーブルをSUMIFSで構築しようとすることです。これは行ごと・列ごとに数式を手動で複製する羽目になります。
GL明細(仕訳データ)から参照する専用のレポートシートを持つ3表連動モデルは、QUERY数式の最適な活用場面です。レポートシートは自動で最新状態に保たれ、LABELがカラム名を整え、ORDER BYがCFOに見せたいデータを手動ソートなしで先頭に出します。
すでにGoogle SheetsのワークフローにAIを組み込んでいるなら、QUERY数式との相性は良好です。AIがSQL文字列の生成・修正を担い、数式の構造はそのまま維持できます。
よくある質問
QUERY数式とVLOOKUPはどう使い分けますか? VLOOKUPはキーに対応する単一の値を縦方向に検索する関数です。QUERY数式は複数の条件で複数行・複数列を返せるため、レポート出力には適しています。ただし単一セルの値引き当てにはVLOOKUPやINDEX/MATCHのほうがシンプルです。
QUERY数式はExcelでも使えますか? 使えません。QUERY数式はGoogle Sheets固有の関数です。Excel環境ではPower QueryやLET関数・FILTER関数の組み合わせが代替手段になります。
QUERY数式で処理できるデータ量に上限はありますか? Google Sheetsのスプレッドシート自体の上限(1,000万セル)が事実上の制約です。実務では数万行程度であれば速度上の問題はほぼ生じませんが、数十万行を超える場合はBigQueryへのデータ移行を検討する価値があります。
クエリ文字列内で日本語の列ヘッダーをそのまま使えますか? 使えません。QUERY数式のクエリ文字列内では列をアルファベット(A、B、C)またはCol1、Col2形式で指定する必要があります。日本語ヘッダーを表示したい場合はLABEL句で後から付与してください。
QUERY数式のエラーをデバッグするコツは?
まずクエリ文字列をセルに単独で出力し、目視確認するのが早道です。日付フォーマット(yyyy-mm-dd)とシングルクォートの対応、ヘッダー引数の指定漏れ、列型の混在の3点が原因の大半を占めます。
まとめ
QUERY数式は、フィルタリング・ソート・集計を伴う行出力を単一の式で処理します。クロスシート参照は標準の 'シート名'!範囲 構文とヘッダー引数で機能します。日付フィルターは yyyy-mm-dd 形式の文字列が必須です。集計関数はSUM・COUNT・AVG・MAX・MINの5つのみで、それ以上はサポートされていません。WHERE句はAND/OR/NOTとIS NULLによる空白処理をサポートします。FP&Aモデルにおいては、QUERY数式はレポート・出力シートに、SUMIFSは単一値が下流の数式に流れる計算エンジンに配置するのが適切な役割分担です。
QUERY数式のSQL文字列構築やデバッグを会話形式で行いたい場合は、ModelMonkeyのプランを選ぶ——Google SheetsとExcelの両方に対応しています。