Google Sheets DuckDB統合：実際にできることを徹底解説

ただ、「DuckDBをSheetsに統合する」とひと口に言っても、実際には考慮すべき点がいくつかあります。導入前にその実態を把握しておきましょう。

QUERY()関数とDuckDBの機能比較

まず、既存のQUERY()関数と何が違うのかを整理します。

機能	QUERY()関数	DuckDB統合
複数シートのJOIN	✗ 不可	✓ 対応
ウィンドウ関数（移動平均・累計など）	✗ 不可	✓ 対応
CTE（共通テーブル式）	✗ 不可	✓ 対応
HAVINGによる集計絞り込み	△ 限定的	✓ 完全対応
データエクスポートの必要性	不要	不要（組み込み型の場合）
ライブデータへのアクセス	✓	✓（組み込み型の場合）
大規模集計の処理速度	遅い	高速
SQLの学習コスト	低（独自方言）	中（標準SQL）

QUERY()はSheetsの数式エンジン内で評価されるため、そのエンジンが公開する機能の範囲に縛られます。一方DuckDBは、シートのデータを表形式の入力として読み込む独立したインプロセスデータベースとして動作します。スプレッドシートは実行環境ではなく、データソースとして機能するわけです。

Google SheetsとDuckDBを統合する仕組み

DuckDBをSheetsデータに対して動作させる方法はいくつかあります（詳しくはDuckDBとGoogle Sheetsの接続方法をご覧ください）。大きく分けると、DuckDBが読み込める形式（CSV、Parquet）にデータをエクスポートするか、データの橋渡しを自動処理するインテグレーション層を使うかのどちらかです。

より注目すべきアプローチは、DuckDBをツールチェーンに直接組み込む方法です。これにより、クエリエンジンが古いエクスポートではなく、シートの範囲にライブアクセスできるようになります。ModelMonkeyが内部で採用しているのがこの方式です。DuckDBのUDFとして登録されたsheet_range()テーブル関数を使うと、A1記法でスプレッドシートの範囲をSQLクエリ内から直接参照できます。

SELECT 
  category,
  SUM(revenue) as total_revenue,
  AVG(margin_pct) as avg_margin
FROM sheet_range('P&L!B2:E500')
GROUP BY category
ORDER BY total_revenue DESC

このクエリはライブのスプレッドシートデータに対して実行されます。エクスポート工程も、陳腐化したCSVも不要です。sheet_range()関数はクエリ実行時に指定した範囲を取得し、DuckDBが処理できる型付きの表形式ソースとして返します。

カラムの型はデータから自動推論されます。数値はDOUBLE、真偽値はBOOLEAN、混在するデータはVARCHARがデフォルトです（DuckDB公式ドキュメント「Docs › SQL › Data Types」参照）。2026年4月時点で、DuckDBの型推論はファイナンス系のデータのほとんどを適切に処理できます。ただし、ヘッダーテキストと数値データが混在するカラムでは、明示的なキャストが必要になることがあります。

財務・経営企画への具体的な活用例

複数シートにまたがる貢献利益分析

製品ライン別・地域別の貢献利益分析が必要な経営企画担当者を例に考えてみましょう。典型的なワークブックでは、売上シート・原価シート・製品マスタが別々に存在し、VLOOKUPチェーンでつないでいるケースが多いはずです。

DuckDBを使えば：

SELECT 
  p.product_line,
  r.region,
  SUM(s.revenue)                                                  AS total_revenue,
  SUM(s.revenue - c.cogs)                                         AS gross_profit,
  ROUND(100.0 * SUM(s.revenue - c.cogs) / SUM(s.revenue), 1)     AS margin_pct
FROM sheet_range('Sales!A2:D1000')    s
JOIN sheet_range('COGS!A2:C1000')     c ON s.product_id   = c.product_id
JOIN sheet_range('Products!A2:B200')  p ON s.product_id   = p.id
JOIN sheet_range('Regions!A2:B50')    r ON s.region_code  = r.code
GROUP BY p.product_line, r.region
ORDER BY gross_profit DESC

VLOOKUPチェーンが複数シートにわたっていたものが、単一のクエリに集約されます。中間計算列も、名前付きセル参照の連鎖も不要です。

移動平均と累計の同時算出

月次売上の3ヶ月移動平均と年度累計を同時に計算するウィンドウ関数も、DuckDBなら一発です。

SELECT
  month,
  revenue,
  AVG(revenue) OVER (
    ORDER BY month ROWS BETWEEN 2 PRECEDING AND CURRENT ROW
  ) AS moving_avg_3m,
  SUM(revenue) OVER (ORDER BY month) AS cumulative_revenue
FROM sheet_range('Monthly!A2:B24')

QUERY()ではこの処理は不可能で、補助列を手動で並べるしかありません。年度（4月始まり）の累計管理や、予実差異の推移分析に直接応用できます。

SQLが書けなくても使えるか

ここで正直に書いておきたい点があります。上記のサンプルは比較的シンプルなSQLですが、チームの全員がJOINやウィンドウ関数をすらすら書けるわけではないはずです。

組み込み型の統合では、「必要な分析を日本語で入力すると、AIがSQLを生成・実行する」という自然言語インターフェースを提供しているものがあります。「製品ライン別・地域別の粗利益率を計算して、上位10件を表示して」と入力すれば、SQLは自動生成されます。実はこのAI生成機能こそが、SQLに不慣れなチームメンバーにとっての最大の恩恵です——記事の最後にさらっと触れるような話ではなく、導入の主目的になりえます。

ただし、AIが生成したSQLは必ずレビューする習慣をつけてください。特に財務データを扱う場合、JOIN条件や集計ロジックに意図しないバグが含まれていることがあります。

実際に考慮すべき制限

データ量の上限

Google Sheetsのセル上限は1,000万セルです（Google Workspace公式ドキュメント「Google Sheetsの上限と制限事項」より）。DuckDBはそれをはるかに上回るデータセットを扱えますが、Sheets統合の中で動作する以上、Sheets自体が保持できる量に縛られます。中堅企業（売上10億〜50億円規模）のファイナンスデータであれば、1,000万セルに達することは稀です。数百万行規模のトランザクションデータを扱う場合は、MotherDuckなどのサーバーサイドDuckDBへの移行を検討してください。

出力サイズと表示品質

5万行の結果セットをスプレッドシートにインラインで返すのは処理が重く、通常は意味もありません。必要なのは集計結果であって、生の行データではないからです。適切なインテグレーションでは、インライン表示を200行程度に制限し、それ以上の出力は別のシートに書き出す設計が望ましいです（output:"sheet"パラメータで指定する方式など）。これによりコンテキストをクリーンに保ちながら、完全な結果セットへのアクセスも確保できます。

もう一点、正直に触れておく必要があります。SQLの集計結果は「正確な数値」であり、「投資家向けのプレゼンテーション品質の財務表」ではありません。ヘッダーのフォーマット、セルの色付け、前提条件の注記——こうした仕上げは、依然としてSheets側で行う必要があります。DuckDBはデータ処理エンジンであり、レポートフォーマッターではないという点を理解した上で使うことが重要です。

クエリのタイムアウト

大きな範囲に対する複雑なJOINは、数秒かかることがあります。DuckDBインスタンスはインメモリで動作するため計算自体は高速ですが、ボトルネックになるのは通常、Sheets APIからの範囲データの取得です。このラウンドトリップのレイテンシは範囲サイズに比例して増加します。

Google Sheets DuckDB統合でネイティブ組み込みが優れている理由

エクスポート＆クエリ方式（CSVに書き出し、ローカルでDuckDBを実行し、結果を再インポート）は機能しますが、根本的な問題があります。エクスポートした瞬間にデータが陳腐化するという点です。スプレッドシートの更新に合わせて分析を最新状態に保ちたい場合、手作業の繰り返しに戻ってしまいます。

DuckDBがクエリ実行時に直接範囲を読み込む組み込み型統合は、この問題を解消します。クエリは常にシートの現在の状態を反映します。これが最も重要になるのは、予実管理ダッシュボード、月次KPIレポート、案件パイプラインの集計など、データが日々変化し手動操作なしに分析が最新状態を保つ必要がある場面です。

もう一つのメリットは、クエリの出典を追跡できる点です。DuckDBがAIエージェントのワークフローの一部として動作する場合、各クエリでアクセスした範囲を記録できます。「P&L!B2:E500とProducts!A2:C200の範囲にクエリを実行し、product_idでJOINしました」というように、分析の根拠を後から確認できます。

ただし、これを「財務モデルの完全な監査証跡」と見なすのは過大評価です。アクセスした範囲とSQLのログは取れますが、財務監査が求める変更履歴・承認フロー・バージョン管理は別途必要です。あくまで分析の出典確認を補助するツールとして捉えてください。

セルの数式と比べたときの優位性は明確です。数式では出力は確認できますが、その導出過程はネストした関数の中に埋もれてしまいます。DuckDBのクエリはそれ自体がドキュメントとして機能します。

まとめ

Google Sheets DuckDB統合により、ライブのスプレッドシートデータに対してJOIN・ウィンドウ関数・集計などの本格的なSQL機能が使えるようになります。GoogleのSheets上限（1,000万セル）により大規模なバッチ処理には向きませんが、CSVのエクスポートと再インポートも不要で、データは常に最新状態を反映します。

実際的な制約は2点——インライン結果のサイズ（目安は200行以内で、大きな出力は別シートへ）と、大きな範囲の取得レイテンシです。

財務・経営企画への適用で最も効果を発揮するのは、複数シートにまたがる集計（製品別・地域別の貢献利益、月次推移の移動平均など）です。SQLの生成はAIに任せられますが、生成されたクエリのレビューと出力の最終的なフォーマットは、人間の判断が必要です。

よくある質問

Q. SQLの知識がなくても使えますか？

組み込み型の統合では、日本語で分析内容を記述するとAIがSQLを自動生成する機能を提供しています。ただし、財務データを扱う場合はJOIN条件と集計ロジックを確認できるレベルの知識があると安心です。生成されたSQLは必ず内容をレビューしてください。

Q. QUERY()関数と併用できますか？

はい。DuckDB統合はQUERY()の置き換えではなく補完として機能します。シンプルなフィルタリングはQUERY()のまま、複数シートのJOINや複雑な集計はDuckDBと使い分けるのが現実的です。

Q. Google Sheets以外のデータソースも使えますか？

組み込み型アプローチはSheetsの範囲を直接読み込む設計です。外部データベースやAPIと組み合わせる場合は、まずSheetsに取り込む手順が必要になります。

Q. 財務レポートの監査証跡として使えますか？

クエリのログ（アクセスした範囲・実行したSQL）は記録できます。ただし、財務監査が求める変更履歴・承認フロー・バージョン管理は別途必要です。DuckDBのクエリログはあくまで分析の出典確認を補助するツールとして捉えてください。

Q. データ量が多い場合はどうすればよいですか？

Google Sheetsの1,000万セル制限（Google公式ドキュメントより）が上限です。数百万行規模のトランザクションデータを扱う場合は、MotherDuckなどのサーバーサイドDuckDBへの移行を検討してください。中堅企業の財務データであれば、通常この制限に達することはありません。