GoogleスプレッドシートQUERY関数の使い方【実例付き】データ抽出・集計を自動化

Excelを15年以上、経理や営業管理の最前線で使い倒してきた実務家として断言しますが、Googleスプレッドシートへの移行で最も「生産性の差」が出るのがこの機能です。多くの現場では、VLOOKUP関数を何重にも組み合わせたり、複雑なフィルタ表示を繰り返したりして、月次報告書を作成しています。しかし、その作業の8割は自動化できるものです。

筆者が社内研修で真っ先に教えるのは「データの加工に時間をかけるな」ということです。Excelのピボットテーブルに慣れ親しんだ方ほど、関数一つでデータの抽出・集計・並べ替えを完結させるこの手法の合理性に驚かれます。大量の「営業部売上管理表」や「経理部経費精算リスト」を前に、手作業でのコピペや範囲修正を繰り返す日々から脱却するための、データベース的な思考法を身につけましょう。

実務で求められるのは、単なる関数の知識ではなく「止まらない、ミスの起きない仕組み」です。15年の経験から得た、現場で本当に役立つノウハウを凝縮してお伝えします。

Googleスプレッドシート QUERY関数を実務で使いこなすための思考法

Excel歴が長い方ほど、「関数は一つのセルに一つの結果を返すもの」という固定観念があります。しかし、この機能の本質は「一つの数式で一つの表（テーブル）を生成する」というデータベース的な挙動にあります。企業の経理部門で散見される「数百行のデータを手動でフィルタして別シートに貼り付ける」という作業は、この関数の存在によって過去の遺物となりました。

Excelのフィルタ機能やVLOOKUPとの決定的な違い

Excelの標準機能で特定の条件（例：営業1課かつ売上50万円以上）を抽出する場合、オートフィルタで絞り込んだ結果をコピー＆ペーストするか、複雑なINDEX/MATCH関数を配列数式で組む必要がありました。Googleスプレッドシート QUERY関数は、元データには一切手を触れず、別のセルに「条件に合致した最新のリスト」を常に展開し続けます。

筆者の経験では、この「元データを汚さない」という点が実務上極めて重要です。マスターデータが更新されれば、抽出結果もリアルタイムで同期されます。これにより、報告資料を作成するたびに最新の数値を追いかける手間が完全になくなります。

SQLに近い記述が生み出す圧倒的な記述効率

この関数は、SQLというデータベース操作言語をベースにしています。一見すると難解に思えるかもしれませんが、実務で使う構文は限られています。Excelの関数を幾重にもネスト（入れ子）にするよりも、クエリを一文記述する方が可読性が高く、後からのメンテナンスも容易です。

研修で教えていると、「英語の命令文を書くのが不安だ」という声をよく聞きます。しかし、実務で使う命令は「SELECT（選ぶ）」「WHERE（絞り込む）」「ORDER BY（並べる）」といった中学英語レベルの単語が中心です。これらを組み合わせるだけで、VLOOKUPでは不可能だった「左側の列の取得」や「複数条件での抽出」が瞬時に行えます。

実務における「集計の自動化」の完成形

経理の現場では、月次決算のたびに各部署から送られてくる「経費精算書」をマージし、集計表を作成する業務が発生します。QUERY関数をマスターすれば、各部署のシートを統合し、特定の勘定科目だけを抜き出し、部署別に合計金額を算出する、という一連の流れを一つの数式で完結させられます。

関数を安定稼働させるためのマスターデータ設計術

QUERY関数を実務で使う際、最も初心者がつまずきやすいのが「元データの作り方」です。数式が正しくても、データの形式がバラバラであれば、意図しないエラー（特に #N/A や空白）に悩まされることになります。筆者が研修で口を酸っぱくして伝えているのは、「1行1件のレコード原則」です。

クエリが参照する「データ範囲」の正しい指定方法

基本構文の第一引数である「データ範囲」は、将来的なデータの増加を見越して列全体を指定するのが実務の鉄則です。例えば、A:Fのように指定します。

「見出し行」の指定を間違えると集計が狂う理由

第三引数の「見出し」には、データの先頭何行がタイトルであるかを指定します。通常は「1」を指定しますが、ここを省略したり「0」にしたりすると、見出し行がデータとしてカウントされ、集計結果にゴミが混じります。

筆者が実務で見かけた失敗例として、見出し行が2行にわたっている表（例：上段に「2026年度」、下段に「部署名」「氏名」など）をそのまま参照し、クエリが混乱してエラーを吐くケースがありました。実務では、見出しは必ず「1行」に集約し、シンプルに設計するのが安定稼働のコツです。

データベース形式の「4つの禁止事項」

QUERY関数を正常に動かすためには、参照元データで以下の4つを避ける必要があります。
1. セルの結合（致命的なエラーの原因になります）
2. 合計行の挿入（データ行と混在すると二重計上されます）
3. 空白行の放置（抽出結果に空白が混じります）
4. 列内でのデータ型混在（数値と文字列が混ざると、一方が消えます）

特定の列を抽出するSELECT句とアルファベット指定のルール

実務で最も頻出するのが「必要な列だけを取り出す」操作です。例えば、全30項目ある「社員名簿」から「社員番号」「氏名」「部署名」の3項目だけを抜き出して配布用リストを作る場面です。

アルファベットによる列指定とカンマ区切りの作法

クエリ内では、抽出したい列をアルファベットで指定します。"SELECT A, B, D"のように記述します。ここで重要なのは、元データの列の順番を入れ替えて抽出できる点です。

例えば、元データが「A：部署名、B：社員名」であっても、"SELECT B, A"と書けば、「氏名」が左側に来るリストが作成されます。これはExcelのVLOOKUP関数では非常に手間の回る操作でしたが、QUERY関数なら一瞬です。

「SELECT 」で全列を一括取得する場面

すべての項目を抽出したい場合は、アスタリスク（）を使って"SELECT "と記述します。一見便利ですが、実務ではあまり推奨しません。

筆者の経験では、元データの右側にメモ書き用の列を追加した際、SELECT を使っていると、そのメモまで抽出先に表示されてしまうトラブルがよくあります。実務で使う数式には、面倒でもSELECT A, B, Cと具体的に列を指定することを強く勧めます。これが、意図しないデータ流出を防ぐセキュリティ対策にもなります。

算術演算子を組み合わせて「税込金額」を計算する

SELECT句の中では、簡単な四則演算が可能です。
"SELECT A, B, E 1.1"
このように記述すれば、E列の単価データに1.1を掛けた「税込価格」を計算しながら抽出できます。元の表に計算列を追加しなくて済むため、シートがスッキリします。

業務要件を抽出条件に落とし込むWHERE句の記述法

QUERY関数の真骨頂は、WHERE句による高度なフィルタリングにあります。実務で「特定の条件に合致するデータだけを見たい」という要望は無限にありますが、これを数式で表現するスキルが生産性を分けます。

文字列と数値で異なる引用符のルール

初心者が最もつまずくのが、条件指定の際の「囲み記号」です。
– 文字列の場合：シングルクォーテーションで囲む（例：WHERE B = '営業部'）
– 数値の場合：そのまま記述する（例：WHERE E >= 100000）

「経理の現場では、部署名が文字列として扱われるため、この設定を忘れてエラーになるケースをよく見かけます」。特に、数字だけの「社員番号」が、実際には文字列形式で保存されている場合など、データ型の不一致によるエラーは実務上の「あるある」です。

空白行を除外する「IS NOT NULL」の重要性

前述の通り、列全体（A:F）を範囲指定した場合、データの入っていない空白行も抽出対象になります。これを防ぐために、実務では必ず以下の条件をWHERE句に含めます。
WHERE A IS NOT NULL
「A列が空でない行だけを抽出する」という意味です。これを忘れると、抽出結果の下側に大量の空白行ができてしまい、その下に別の数式を置くことができなくなります。

複数条件を繋ぐANDとORの優先順位

「営業部」かつ「5月以降」といった条件はANDで繋ぎます。
WHERE B = '営業部' AND A >= date '2026-05-01'
逆に「営業部または総務部」ならORを使います。
WHERE (B = '営業部' OR B = '総務部') AND E > 0
このように括弧を使って優先順位を明確にすることで、複雑な業務ロジックも正確に反映できます。

経理担当者が最も苦労する「日付データ」のフィルタリング処理

Googleスプレッドシート QUERY関数の中で、最も難易度が高く、かつ避けて通れないのが「日付」の扱いです。Excelの感覚で「2026/05/13」と書いても、クエリ内では認識されません。

「date ‘yyyy-mm-dd’」形式の厳格なルール

クエリ内で日付を指定する場合、必ずdate '2026-05-13'という形式で書く必要があります。スラッシュ（/）ではなくハイフン（-）を使い、先頭に「date」という単語を添えるのがルールです。

注意点: この形式を1文字でも間違えると、クエリは沈黙するか、エラーを返します。特に、シングルクォーテーションの閉じ忘れには注意してください。Microsoft公式ドキュメントでも、日付リテラルの形式は厳密に定められています。

TODAY関数と連携させた「直近データ」の自動抽出

実務では「今日から過去1週間のデータを抽出したい」といった動的な条件が求められます。この場合、数式内でTEXT関数を組み合わせて日付文字列を生成します。
"WHERE A > date '"&TEXT(TODAY()-7,"yyyy-mm-dd")&"'"
この「ダブルクォーテーションとアンパサンド（&）で繋ぐ」記述は、初心者が最も混乱するポイントですが、一度テンプレートとして覚えてしまえば、あらゆる動的レポートに応用可能です。

月次処理で使える「MONTH」と「YEAR」関数

「特定の月だけを集計したい」場合、MONTH関数が便利です。ただし、注意が必要なのは、QUERY関数内のMONTHは「0から11」で月をカウントする点です（1月が0、12月が11）。
WHERE MONTH(A) = 4
これで「5月」のデータが抽出されます。この仕様は非常に紛らわしく、筆者の研修でも「なぜ1ずれるのか」と必ず質問が出るポイントです。混乱を避けるため、実務では前述のdate 'yyyy-mm-dd'形式で、その月の初日から末日までをAND条件で指定する方法を推奨しています。

SUMIF関数やピボットテーブルを不要にするGROUP BYの集計力

データの抽出だけでなく、その場で「集計」まで行えるのがQUERY関数の真の恐ろしさです。これを使えば、Excelで手間をかけて作成していた部署別集計表や担当者別売上表が一瞬で完成します。

集計関数（SUM, COUNT, AVG, MAX, MIN）の活用

クエリ内では、Excelでおなじみの集計関数が使えます。
– SUM(E)：金額の合計
– COUNT(A)：件数のカウント
– AVG(E)：平均値の算出
これらをSELECT句に入れ、GROUP BY句で「どの項目ごとに集計するか」を指定します。

GROUP BYで使用する列の制約とエラー対策

"SELECT B, SUM(E) GROUP BY B"
この一文で、B列（部署名）ごとのE列（金額）合計が算出されます。ここで初心者がやりがちなミスは、SELECT句に「集計に関係のない列」を入れてしまうことです。

「実務でよく見かけるのは、部署別に集計したいのに、SELECT句に個別の氏名（C列）を入れてしまい、エラーになるケースです」。グループ化の対象になっていない列は、SELECT句に含めることができないというルールを徹底しましょう。

集計結果に対する条件指定「HAVING」の代わりにWHEREを使う

SQLにはHAVING句がありますが、QUERY関数には存在しません。集計後の数値でフィルタリングしたい場合（例：売上合計が100万円以上の部署だけ表示したい）、一度QUERY関数で出した結果を、さらに別のQUERY関数で囲む「入れ子構造」にするのがプロのテクニックです。
=QUERY(QUERY(A:E, "SELECT B, SUM(E) GROUP BY B"), "WHERE Col2 >= 1000000")
このように、仮想的なテーブルをさらにクエリにかける発想を持つと、実務の幅が広がります。

月次レポートを自動化するPIVOT句によるクロス集計の手順

「行に商品名、列に月」を配置した、いわゆるクロス集計表。Excelならピボットテーブルで行うこの作業を、QUERY関数はPIVOT句一つでやってのけます。

クロス集計を実現する構文の組み立て方

"SELECT B, SUM(E) GROUP BY B PIVOT MONTH(C)+1"
この記述により、B列（商品名）ごとの売上（E列）が、C列（日付）の月ごとに横に展開されます。ピボットテーブルのように、マウスでドラッグ＆ドロップする必要はありません。元データが増えれば、自動的に列も増えていきます。

LABEL句で見栄えをプロ仕様に整える

デフォルトの集計結果は、見出しに「sum 売上金額」といった無機質な名前がつきます。報告用資料としてそのまま使うには、LABEL句で名称を上書きしましょう。
LABEL SUM(E) '売上合計額'
筆者が研修で教えている際、受講生が最も「資料作りが楽になった」と喜ぶのがこの機能です。見出しを手書きで修正する手間が省け、完全自動化に一歩近づきます。

FORMAT句による数値書式の指定

集計結果の数値にカンマを入れたり、円マークを付けたりすることもクエリ内で可能です。
FORMAT SUM(E) '#,##0'
「経理の現場では、この設定を忘れて桁数が読みづらい資料を作成し、上司から指摘を受けるケースをよく見かけます」。数式側で書式を固定しておけば、データが更新されても常に美しい書式が維持されます。

表示順と件数を制御してダッシュボードの視認性を高める方法

情報を抽出できても、それがバラバラな順番では「使える資料」になりません。ORDER BY句とLIMIT句を使いこなし、情報の重要度に応じた並び替えを行いましょう。

ORDER BYによる昇順・降順のコントロール

データを並べ替えるにはORDER BYを使います。
– 昇順（小さい順）：ASC（デフォルト）
– 降順（大きい順）：DESC
"SELECT A, B, E ORDER BY E DESC"
これで「売上の高い順」のリストが完成します。日付を降順にすれば「最新の対応履歴」が常に一番上に来るダッシュボードが作れます。

LIMIT句で「ワースト5」「トップ10」を抽出する

大量のデータから特定の件数だけを表示したい時に使うのがLIMITです。
"SELECT B, SUM(E) GROUP BY B ORDER BY SUM(E) DESC LIMIT 10"
この数式は「売上上位10部署」だけを表示します。筆者の経験では、在庫管理において「在庫数が少ない順に5件だけ表示する」といったアラート機能を作成する際によく活用しています。

OFFSET句で開始位置を調整する応用技

あまり知られていませんが、OFFSETを使うと「最初の3件を除外して表示する」といった操作が可能です。ページ分割（ページネーション）のような機能をスプレッドシート上で実現したい場合に重宝しますが、実務ではLIMITとの組み合わせで「2番目に高い数値」を取得する際などに限定的に使われます。

検索窓との連動を実現するセル参照とエスケープ処理の技術

QUERY関数の真のパワーを引き出すのは、クエリ文の中に「他のセルの値」を組み込んだ時です。これにより、ユーザーが検索窓に打ち込んだ部署名に合わせて、リストが瞬時に切り替わる「社内検索システム」が構築できます。

「”& A1 &”」という魔法の記述

クエリ内でセルの値を参照する場合、文字列の途中で一度ダブルクォーテーションを閉じ、アンパサンド（&）で繋ぎます。
"SELECT WHERE B = '" & A1 & "'"
（A1セルに部署名が入っている場合）

この記述は、シングルクォーテーション、ダブルクォーテーション、アンパサンドが複雑に入り乱れるため、初心者が最も嫌悪感を抱く箇所です。「筆者の経験では、ここで記号を一つ書き忘れてエラーになり、1時間悩む受講生を何人も見てきました」。

データ型に応じた繋ぎ方の違い（数値 vs 文字列 vs 日付）

参照するセルのデータ型によって、繋ぎ方が変わります。
– 文字列：'"& A1 &"' （シングルで囲む）
– 数値："& A1 &" （そのまま）
– 日付：date '"& TEXT(A1,"yyyy-mm-dd") &"'

この違いを理解していないと、検索結果が常に「該当なし」になるトラブルに見舞われます。

部分一致検索「LIKE」を活用した高度な検索

「A-001」といった型番の一部を入力して検索したい場合は、= ではなく LIKE と %（ワイルドカード）を使います。
"WHERE A LIKE '%" & A1 & "%'"
これで、A1に入力した文字が含まれるすべての行がヒットします。顧客名簿から会社名の一部で検索する際に、これほど便利な機能はありません。

抽出結果が消える「データ型の混在」トラブルへの対処

QUERY関数には、Excelの標準関数にはない独特の「弱点」があります。それが「1つの列には1つのデータ型しか認めない」という厳格なルールです。これを知らずに運用を始めると、ある日突然データが表示されなくなる恐怖を味わうことになります。

Googleスプレッドシート特有の「データ型判定」の罠

QUERY関数は、参照範囲の各列のデータをスキャンし、多数派のデータ型をその列の型と判定します。例えば、ある列に100件の数値と、5件の文字列（メモ書きなど）が混在していた場合、その列は「数値型」と見なされます。

すると、少数派である「文字列」のデータは、抽出結果では強制的に「空白」として扱われます。これが、実務でよく起きる「元データにはあるのに抽出されない」問題の正体です。

混合データを強制的に扱う「TO_TEXT」の活用

「商品型番に数字だけのものとアルファベット混じりのものが混在している」といったケースでは、QUERY関数に渡す前に全データをテキスト形式に変換してしまいます。
=QUERY(ARRAYFORMULA(TO_TEXT(A:E)), "SELECT ...")
このように、元データを一度TO_TEXT関数に通すことで、すべてのデータが文字列として統一され、欠損を防ぐことができます。

Microsoft公式ドキュメントに見るPower Queryとの類似性

実はこの「データ型の厳格さ」は、Excelの上位機能であるPower Query（取得と変換）にも共通する考え方です。

モダンなデータ分析ツールは、データの整合性を保つために型を重視します。スプレッドシートのQUERY関数をマスターすることは、将来的にExcelの高度な機能を使いこなすための基礎体力作りにも繋がります。

Excelのテーブル機能やPower Queryと比較した際の優位性

ここまでGoogleスプレッドシートのQUERY関数の魅力をお伝えしてきましたが、Excel歴の長い方からは「Excelのテーブル機能やPower Queryで十分ではないか」という質問をよく受けます。それぞれの特性を理解し、使い分けることが真のプロです。

リアルタイム性と同時編集における優位性

ExcelのPower Queryは非常に強力ですが、データの更新には「再読み込み」ボタンのクリックが必要です。また、複数人での同時編集には向きません。

一方、Googleスプレッドシート QUERY関数は、誰かが元データを1文字変えた瞬間に、共有されているすべての画面の結果が更新されます。この「ライブ感」は、スピードが重視される営業現場の進捗管理や、在庫の取り合いが起きるECサイトの管理において、決定的なアドバンテージとなります。

関数のネストを解消し、メンテナンスコストを下げる

Excelで複数条件の抽出を行う場合、IF(AND(...))やVLOOKUPの配列数式など、数式が非常に長くなりがちです。これは、作成した本人にしか中身がわからない「属人化」の原因となります。

QUERY関数は、命令文が平易なテキストであるため、他人が見ても「何をしているか」が一目瞭然です。筆者が企業のシステム改善コンサルティングに入る際、まず着手するのは、こうしたスパゲッティ数式をQUERY関数に置き換えて、後任者が困らないように整備することです。

実務要件に応じたプラットフォームの選択基準

– 10万行を超える超大規模データの重厚な分析 → Excel Power Query
– チームで共有し、常に最新の数値を追いかける動的なレポート → Googleスプレッドシート QUERY関数
「筆者の経験では、日常業務の9割はスプレッドシートの処理能力で十分カバー可能です」。プラットフォームの特性を正しく理解し、適材適所でツールを使い分ける視点を持ちましょう。

明日からの実務にQUERY関数を取り入れる3ステップ

Googleスプレッドシート QUERY関数は、一度その利便性を知ってしまうと、二度と手作業の集計には戻れないほどの破壊力を持っています。まずは、以下の3ステップで、ご自身の業務に導入してみてください。

1. データの「型」を整える：セルの結合を解き、1行1件のきれいなマスターデータを作成する。
2. スモールスタートで抽出する：まずは SELECT と WHERE だけを使い、特定の部署のリストを作ることから始める。
3. 動的な検索窓を作る：セルの値と連動させ、チームメンバーが自分で情報を探せる仕組みを提供する。

実務家として最後に強調したいのは、関数を覚えること自体が目的ではないということです。その先にある「浮いた時間」を使って、データの分析や改善提案、あるいは早く帰って家族と過ごす時間を作ることこそが、ツールを使いこなす真の目的です。

この記事で紹介したテクニックは、筆者が15年かけて培ってきた「現場で壊れない」ための知恵です。ぜひ、今日からの実務に役立ててください。