QUERY関数が思った結果を返さないときの原因

where句で日付を指定したのに、何も引っかからない。エラーメッセージも出ない。

QUERY関数はエラーを出さずに「期待と違う結果」を返すことが多く、

原因が数式の外側（元データの作り方）にあることも珍しくありません。

起きやすい原因を、実際の症状から順に見ていきます。

■ QUERYは何をしているか

=QUERY(範囲, "select A, B where C > 100", 1)

第2引数は、SQLに似た構文で書く「クエリ言語」です。範囲の中身を

このクエリ言語で読み替えて返しますが、範囲の各列がどんなデータ型と

「推定」されたかによって、同じ書き方でも結果が変わります。

QUERYのつまずきの大半は、この「型の推定」に起因します。

■ 症状1：数値が入っている列なのに、集計や比較が効かない

=QUERY(A1:D100, "select sum(C) where C > 0")

C列に数字が並んでいるはずなのに、合計が0になったり、

where句の条件に何も引っかからなかったりします。

原因は、C列の中に文字列として扱われるセルが混ざっていることです。

QUERYは列全体をスキャンして型を推定しますが、その際、

空白に見えるセルや、数式の結果が空文字("")になっているセルがあると、

列全体が「文字列の列」と判定されることがあります。

見た目には空欄でも、="" のような数式が入っていると、

それは「空白」ではなく「長さ0の文字列」であり、

数値の列としての判定を崩す原因になります。

対処は、集計対象の列に文字列の数式結果が混ざっていないか確認し、

混ざっている場合はIFERRORの戻り値を "" ではなく空欄そのものにするか、

集計前にその列だけ値貼り付けで数値に固定することです。

■ 症状2：Col1やAを書いたのに列がずれる／認識されない

QUERYの列指定には2通りの書き方があります。

・範囲をシート内のセル番地で渡した場合 → A, B, C のように

　元のシート上の列名で指定します。範囲が E2:H100 なら、

　1列目でも "A" ではなく "E" と書きます。

・範囲を他の関数の結果や名前付き範囲として渡した場合 → Col1, Col2 のように

　範囲内の並び順で指定します。

この2つを混同すると、列指定が無視されたり、エラーにすらならず

空の結果が返ったりします。 特に、範囲をA1から始めていない場合

（例えばE列から始まる表）に "select A" と書いてしまうミスが多く、

これは表の外にある別の列を指しているため、無関係な結果か空欄が返ります。

範囲がどこから始まっているかを確認し、セル番地由来ならその番地の列名、

関数の出力由来ならColNのどちらかに統一してください。

■ 症状3：where句の日付条件が何も拾わない

=QUERY(A1:D100, "select A where B = date '2026-08-31'")

日付の比較で最も間違えやすいのがここです。QUERYのクエリ言語内で

日付リテラルを書くときは、date '2026-08-31' のように

date というキーワードを付けたうえで、年-月-日の形式にする必要があります。

これを付けずに "B = 2026-08-31" と書くと、日付としてではなく

引き算の式として解釈され、意図と違う結果になります。

もう1つ、B列のセルが「日付として入力されているように見えて、

実際には文字列として入力されている」場合、date '...' との比較が

成立せず、該当なしになります。セルを選択してホームの表示形式を見るか、

右揃えになっているか（日付・数値は既定で右揃え、文字列は左揃え）で

見分けられます。文字列化している場合は、DATEVALUE関数などで

一度日付型に変換してから範囲に渡してください。

■ 症状4：ヘッダ行が集計に混ざる、または消える

QUERYの第3引数（見出しの行数）を省略、または実際と違う数を指定すると、

2つの症状が出ます。

・ヘッダ行がデータとして集計に混ざる → 文字列であるヘッダが

　数値列の中に紛れ込み、前述の型推定を崩す一因にもなります。

・逆に見出しが消えて、結果の先頭行がいきなりデータになる

第3引数は「範囲の先頭に見出し行が何行あるか」を示す数値です。

見出しが1行なら 1、見出しが無く先頭からデータなら 0 を明示してください。

省略した場合、QUERYは範囲の中身から自動判定しますが、

先頭行の型が2行目以降と近いと誤判定しやすく、これも省略せず

明示した方が安定します。

■ 症状5：label句を使ったら列名が消えた・想定と違う名前になった

=QUERY(A1:D100, "select A, sum(C) group by A label sum(C) '合計'")

label句は返ってきた列の見出しを付け替える機能ですが、

select句に書いた式と、label句に書いた式が文字単位で一致していないと

反映されません。 空白の有無、大文字小文字、関数名の表記ゆれで

簡単にずれます。反映されない場合、既定の "sum C" のような

機械的な見出しに戻ります。

また、集計系の関数（sum、count、avgなど）を使うと、

label句を書かなくても見出しが自動的に "sum C" のような表記になり、

group byを使った場合は元の列名がそのまま引き継がれないことがあります。

見出しをそのまま使う設計にしていると、この自動生成された文字列が

そのまま表に出てしまうため、集計を使うクエリでは基本的に

label句で明示的に付け替えておくのが安全です。

■ 複数の症状が絡む例：集計もwhereも効かないとき

型推定の崩れ、列指定の取り違え、where句の書き方は、

それぞれ独立した原因のように見えて、同じ表の中で同時に起きることが

よくあります。たとえば、E列から始まる売上表に対して、

=QUERY(E1:H200, "select A, sum(C) where B = date '2026-08-31'")

と書いてしまうと、A・B・Cはいずれも表の外を指しており、

select句もwhere句もそもそも成立していません。この状態で

「集計が0になる」「日付条件が効かない」と別々の症状として

捉えてしまうと、原因究明が遠回りになります。

対処は、まず列指定だけを直したうえで（この例ならE、F、Gに直す）、

where句を外した状態で結果件数を確認し、次にwhere句だけを足して

件数の変化を見る、という順番です。一度に直す要素を1つに絞ると、

どの変更が結果を動かしたかが分かります。

■ やってはいけないこと

結果が空になったとき、範囲を広げて様子を見ること。

型推定やColとAの取り違えが原因の場合、範囲を広げても症状は変わらず、

かえって「どこまでが原因の候補か」が分かりにくくなります。

まず小さい範囲・単純な条件（where句なし）で結果を確認し、

条件を1つずつ足していく方が原因を特定しやすいです。

■ それでも解決しないとき

・型推定が崩れている原因のセルが、範囲のどこにあるか特定できない

・where句を単純化しても、期待した行が出てこない

・group byやpivotを組み合わせた複雑なクエリで、どこがずれているか分からない

このあたりまで来たら、クエリを分解しながら1つずつ検証した方が早いです。

私はスプレッドシートの数式・関数まわりの調査と修正を承っています。

どの条件でどうずれていたかを突き合わせてお返ししています。

――

この記事の執筆には生成AIを活用しています。内容は実際の挙動を確認して書いています。