Google Sheets から Snowflake を参照するアドオンの実行基盤を Snowflake Tasks に移行した
LayerX は、Google Apps Script の実行制限に起因するユーザー体験の低下を解消するため、Snowflake と Google Sheets を連携するアドオンの実行基盤を Snowflake Tasks に移行した。
キーポイント
GAS 実行環境のボトルネック解消
既存の Google Apps Script (GAS) による実装では、タイムアウトや実行枠の制限が壁となり、大規模データ処理や複雑なクエリ実行時にユーザー体験を損なう問題が発生していた。
Snowflake ネイティブ基盤への移行
GAS の制約から脱却し、Snowflake Tasks を活用したネイティブな実行基盤へアーキテクチャを刷新することで、安定性とスケーラビリティを大幅に向上させた。
非技術職向けデータ分析の民主化
SQL を記述できないビジネス職メンバーでも、設定済みのクエリを選択するだけで最新データを取得・自動更新できる仕組みは維持され、業務効率化が継続している。
GAS の実行制限による課題
UI 実行時の30秒タイムアウトにより重いクエリが中断され、スケジュール実行では即時性の低下とユーザーあたりの6時間/日の上限がボトルネックとなる。
Google Sheets の分析価値の損なわれ
重いクエリを待機させる運用は「疑問を持って即座に再実行する」という高速フィードバックループを阻害し、ツール本来の利便性を失わせる。
AWS 構成の検討と脱却
既存インフラを活かすため AWS 基盤（API Gateway, ECS など）を検討したが、GAS の根本的な制限から脱却する新基盤への移行が必要と判断した。
イベントドリブンな非同期処理アーキテクチャの採用
Google Sheets Add-on UI から直接 Snowflake を参照するのではなく、API Gateway と EventBridge を経由して AWS ECS や Step Functions でジョブをキューイング・実行する非同期フローへ移行した。
影響分析・編集コメントを表示
影響分析
この事例は、Google Apps Script のような低コード環境の制限に直面した際に、クラウドネイティブなデータプラットフォーム（Snowflake）の機能を活用してアーキテクチャを再設計する有効なパターンを示しています。特に、非技術職が日常的に利用する業務ツールの基盤を移行することで、スケーラビリティと安定性を確保しつつ、ユーザー体験を損なわないで済む実装例として、データ分析基盤の構築において参考となるケーススタディです。
編集コメント
GAS の制限に直面した際の典型的なアーキテクチャ移行事例であり、データ連携基盤の設計において「プラットフォームの特性」を正しく評価する重要性が浮き彫りになっています。
はじめに
こんにちは、LayerX バクラク事業部 BizOps 部データグループの平田 (@TrsNium) です。
以前、Google Apps Script で Snowflake と Google Sheets を連携するアドオンを開発した話という記事で、Google Apps Script (GAS) を使って Snowflake と Google Sheets を連携するアドオンを開発した話をしました。このアドオンは、BigQuery の Connected Sheets のような体験を Snowflake でも実現するために作られたもので、UI からのオンデマンド実行やスケジュール実行、パラメータ設定など、データ分析に必要な機能を一通り実装していました。
このアドオンは、ビジネス職のメンバーを中心に社内で幅広く使われています。予実管理や KPI (Key Performance Indicator: 重要業績評価指標) のトラッキングはもちろん、SQL を書けないビジネス職のメンバーも、設定済みのクエリを選ぶだけで最新データを取得できます。手軽で共有しやすく、スケジュール機能で自動更新もできるため、データ分析と業務効率化に役立っていました。
しかし利用が広がるにつれ、GAS のタイムアウトや実行枠の制限が壁になり、ユーザー体験を損なう場面が増えました。そこで、GAS から脱却し Snowflake ネイティブな実行基盤に作り直すことにしました。本記事では、その設計・実装・成果を紹介します。
GAS 制限とユーザー体験について
GAS の制限について
GAS には利用形態ごとに異なるタイムアウトと実行枠の制限があります (Quotas for Google Services)。
- UI 実行 (google.script.run を経由): 30 秒でタイムアウト。ユーザーがボタンをクリックして実行するケースがこれに該当し、少しでも重いクエリは完了前に打ち切られる
- スケジュール実行 (時間主導型トリガー): 30 分でタイムアウト。重いクエリでも実行できるが、即時性がない
- 1 日の総実行時間: ユーザーあたり 6 時間/日（Google Workspace アカウントの場合）。ユーザーあたりのスケジュール数にも上限があり、KPI のトラッキングなどで頻繁に利用するユーザーはすぐに上限に達してしまう。その回避策としてマシンアカウント 1 つにスケジュール実行を集約していたが、今度はそのアカウントの 6 時間枠を全ジョブで共有することになり、重いジョブが枠を消費すると他のスケジュールが実行できなくなる
- 同時実行数: スクリプトあたり 30 実行まで。利用者が増えるとピーク時にジョブが詰まる
最大の問題は、UI 実行の 30 秒制限です。ユーザーがクエリ実行ボタンを押すと、裏側では google.script.run を経由で GAS が呼ばれますが、この経路に 30 秒のタイムアウトがあります。少し重いクエリや集計テーブルを使う分析では、Snowflake 側で結果の準備が終わる前に処理が打ち切られ、Google Sheets には何も書き込まれません。利用者から「動かない」「同期できない」という問い合わせが多く寄せられました。
回避策としてスケジュール実行を案内していました。スケジュール経由なら重いクエリも完了しますが、これでは Google Sheets 本来の価値が損なわれます。データを見て疑問を持ち、条件を変えてすぐ再実行する — この高速なフィードバックループこそが、Google Sheets でデータ分析を行う中心的な価値だからです。スケジュール登録して次回実行を待つ運用ではサイクルが遅くなり、「ちょっと見てみよう」の気軽さが失われます。
この問題を解決するために、GAS の制限から脱却した新しい実行基盤の検討を始めました。
アーキテクチャ選定の思考プロセス
Option A: AWS 構成
社内の既存インフラが AWS ベースのため、最初に AWS を使った基盤構築を検討しました。API Gateway、ECS、SQS、Step Functions、DynamoDB など、AWS のマネージドサービスを組み合わせてスケーラブルなジョブ実行基盤を作るというアプローチでした。
外部サービス
AWS Backend (8+ サービス)
クライアント層
POST /jobs
enqueue
state
RunTask
Snowflake
Google Sheets API
API Gateway
ECS: Job API
SQS (ジョブキュー)
Step Functions
ECS Task (Runner + Writer)
DynamoDB (状態管理)
EventBridge (スケジューラ)
Google Sheets Add-on UI
Apps Script (Minimal Shim)
Step Functions でワークフローを可視化でき、SQS で柔軟なキューイングを実現でき、ECS でスケーラブルな実行環境を構築できます。事業が成長し、コネクタの利用が増えても対応できる基盤です。しかし、実装期間、運用コスト、そしてアーキテクチャ上の課題があります。
まず、ユーザーが日常的に GAS の制限に直面している状況で、基盤構築に時間をかける余裕はありませんでした。AWS 構成ではインフラ構築、認証実装、ジョブ管理システムなど、実装に相応の時間がかかる見込みでした。
Option B: Snowflake ネイティブ構成
アーキテクチャの複雑さを減らすため、AWS を使わない構成を検討しました。データはすべて Snowflake 上にあり、処理も同じ基盤で完結できる可能性があります。調査を進めると、Snowflake には Tasks によるジョブ管理、Python Stored Procedure による外部 API 呼び出し、External Access Integration による外部連携といった機能が備わっていることが分かりました。これらを組み合わせれば、AWS を介さず Snowflake 単体で完結する構成を実現できます。
以下の図は、Snowflake ネイティブ構成の全体像を示したものです（実際の Task などの詳細は後述します）。
Snowflake (単一プラットフォーム)
手動実行
参照
ジョブ投入
パラメータ取得
Tasks 層**スケジューリング
Catalog 層
メタデータ管理
Orchestration 層
ジョブ制御
Core 層
実行エンジン
Google Sheets
Google Sheets API
Snowflake ネイティブ構成では、AWS 構成で必要だった 8 つ以上のサービスを Snowflake 内部の機能だけで実現します。レイヤー構成の詳細は後述します。
共通の懸念：Google Sheets API Quota
どちらの構成を選ぶにしても、Google Sheets API の Quota 制限という問題がありました。
GAS 以外の基盤に移行する場合、Google Sheets API の write requests のデフォルト quota がボトルネックになる可能性があります。AWS 構成でも Snowflake 構成でも同じです。この制限が緩和されなければ、GAS のタイムアウト問題を解決しても、結局別の制約に引っかかってしまいます。
そこで事前に Google Cloud へ Quota 増加リクエストを提出したところ、承認されて Quota 制限が大幅に緩和されました。
意思決定のポイント
最終的に、以下の 2 つの観点で Snowflake 構成を選択しました。
1. 実装速度
Snowflake の組み込み機能で要件 (定期実行・パラメータ設定・オンデマンド実行) を満たせるため、AWS 構成のようにインフラやミドルウェアを個別構築する工数が不要になります。基盤構築に時間をかけず、ユーザー課題に集中できる点が決め手でした。
2. 運用・スキルセットとの相性
データチームのコアスキルセットは SQL、dbt、Snowflake です。SQL と Python で完結する Snowflake 構成なら、新メンバーのキャッチアップも容易です。また、QUERY_HISTORY と TASK_HISTORY でログを一元管理でき、デバッグも単一クエリログで完結します。
レイヤー構成
全体は4つのレイヤーで構成されています。
レイヤー
役割
主なコンポーネント
Tasks
スケジューリング
scheduler_tick, ingest_job_requests_task, run_pending_jobs_task, check_failed_schedules_task
Catalog
メタデータ管理
QUERY_CATALOG, QUERY_SCHEDULES, SPREADSHEET_PARAMETERS
Orchestration
ジョブ制御
JOB_REQUESTS, JOB_STATE, JOB_REQUESTS_STREAM
Core
実行エンジン
EXECUTE_JOB, WRITE_QUERY_TO_SHEET
Tasks 層**: scheduler_tick が5分間隔でスケジュール対象を取り込み、check_failed_schedules_task が1日1回連続失敗を検知してスケジュールを自動停止します。オンデマンド実行は専用の Task を持たず、UI から JOB_REQUESTS に直接 INSERT します。
Catalog 層: QUERY_CATALOG にクエリ定義、QUERY_SCHEDULES にスケジュール設定、SPREADSHEET_PARAMETERS にパラメータ設定を格納します。
オーケストレーション層: JOB_REQUESTS にリクエストが投入されると、JOB_REQUESTS_STREAM (CDC) が変更を検知し、ジョブを JOB_STATE へエンキューします。
コア層: EXECUTE_JOB がジョブを受け取り、WRITE_QUERY_TO_SHEET (Python Stored Procedure) を介して Snowflake クエリの実行と Google Sheets への書き込みを行います。
ジョブ実行フロー
実際のジョブ実行フローは以下の通りです。スケジュール実行とオンデマンド実行のどちらも、同じ仕組みで動作します。
📊 Google Sheets⚙️ Python Stored Procedure📥 Job Queue📚 Catalog⏰ Snowflake Tasks👤 ユーザー📊 Google Sheets⚙️ Python Stored Procedure📥 Job Queue📚 Catalog⏰ Snowflake Tasks👤 ユーザー<circle cx=
原文を表示
はじめに
こんにちは、LayerX バクラク事業部 BizOps 部データグループの平田 (@TrsNium) です。
以前、Google Apps ScriptでSnowflakeとGoogle Sheetsを連携するアドオンを開発した話という記事で、Google Apps Scriptを使ってSnowflakeとGoogle Sheetsを連携するアドオンを開発した話をしました。このアドオンは、BigQueryのConnected Sheetsのような体験をSnowflakeでも実現するために作られたもので、UIからのオンデマンド実行やスケジュール実行、パラメータ設定など、データ分析に必要な機能を一通り実装していました。
このアドオンは、ビジネス職のメンバーを中心に社内で幅広く使われています。予実管理やKPIトラッキングはもちろん、SQLを書けないビジネス職のメンバーも、設定済みのクエリを選ぶだけで最新データを取得できます。手軽で共有しやすく、スケジュール機能で自動更新もできるため、データ分析と業務効率化に役立っていました。
しかし利用が広がるにつれ、GAS のタイムアウトや実行枠の制限が壁になり、ユーザー体験を損なう場面が増えました。そこで、GAS から脱却し Snowflake ネイティブな実行基盤に作り直すことにしました。本記事では、その設計・実装・成果を紹介します。
GAS制限とユーザー体験について
GAS の制限について
GASには利用形態ごとに異なるタイムアウトと実行枠の制限があります(Quotas for Google Services)。
- UI実行（google.script.run 経由）: 30秒でタイムアウト。ユーザーがボタンをクリックして実行するケースがこれに該当し、少しでも重いクエリは完了前に打ち切られる
- スケジュール実行（時間主導型トリガー）: 30分でタイムアウト。重いクエリでも実行できるが、即時性がない
- 1日の総実行時間: ユーザーあたり6時間/日（Google Workspaceアカウントの場合）。ユーザーあたりのスケジュール数にも上限があり、KPIトラッキングなどで頻繁に利用するユーザーはすぐに上限に達してしまう。その回避策としてマシンアカウント1つにスケジュール実行を集約していたが、今度はそのアカウントの6時間枠を全ジョブで共有することになり、重いジョブが枠を消費すると他のスケジュールが実行できなくなる
- 同時実行数: スクリプトあたり30実行まで。利用者が増えるとピーク時にジョブが詰まる
最大の問題は、UI 実行の 30 秒制限です。ユーザーがクエリ実行ボタンを押すと、裏側では google.script.run 経由で GAS が呼ばれますが、この経路に 30 秒のタイムアウトがあります。少し重いクエリや集計テーブルを使う分析では、Snowflake 側で結果の準備が終わる前に処理が打ち切られ、Google Sheets には何も書き込まれません。利用者から「動かない」「同期できない」という問い合わせが多く寄せられました。
回避策としてスケジュール実行を案内していました。スケジュール経由なら重いクエリも完了しますが、これでは Google Sheets 本来の価値が損なわれます。データを見て疑問を持ち、条件を変えてすぐ再実行する — この高速なフィードバックループこそが、Google Sheets でデータ分析を行う中心的な価値だからです。スケジュール登録して次回実行を待つ運用ではサイクルが遅くなり、「ちょっと見てみよう」の気軽さが失われます。
この問題を解決するために、GASの制限から脱却した新しい実行基盤の検討を始めました。
アーキテクチャ選定の思考プロセス
Option A: AWS構成
社内の既存インフラが AWS ベースのため、最初に AWS を使った基盤構築を検討しました。API Gateway、ECS、SQS、Step Functions、DynamoDB など、AWS のマネージドサービスを組み合わせてスケーラブルなジョブ実行基盤を作るというアプローチでした。
外部サービスAWS Backend (8+ サービス)クライアント層POST /jobsenqueuestateRunTaskSnowflakeGoogle Sheets APIAPI GatewayECS: Job APISQS (ジョブキュー)Step FunctionsECS Task (Runner + Writer)DynamoDB (状態管理)EventBridge (スケジューラ)Google Sheets Add-on UIApps Script (Minimal Shim)Step Functions でワークフローを可視化でき、SQS で柔軟なキューイングを実現でき、ECS でスケーラブルな実行環境を構築できます。事業が成長し、コネクタの利用が増えても対応できる基盤です。しかし、実装期間、運用コスト、そしてアーキテクチャ上の課題があります。
まず、ユーザーが日常的に GAS の制限に直面している状況で、基盤構築に時間をかける余裕はありませんでした。AWS 構成ではインフラ構築、認証実装、ジョブ管理システムなど、実装に相応の時間がかかる見込みでした。
Option B: Snowflakeネイティブ構成
アーキテクチャの複雑さを減らすため、AWS を使わない構成を検討しました。データはすべて Snowflake 上にあり、処理も同じ基盤で完結できる可能性があります。調査を進めると、Snowflake には Tasks によるジョブ管理、Python Stored Procedure による外部 API 呼び出し、External Access Integration による外部連携といった機能が備わっていることが分かりました。これらを組み合わせれば、AWS を介さず Snowflake 単体で完結する構成を実現できます。
以下の図は、Snowflake ネイティブ構成の全体像を示したものです（実際の Task などの詳細は後述します）。
Snowflake (単一プラットフォーム)手動実行参照ジョブ投入パラメータ取得Tasks 層スケジューリングCatalog 層メタデータ管理Orchestration 層ジョブ制御Core 層実行エンジンGoogle SheetsGoogle Sheets APISnowflake ネイティブ構成では、AWS 構成で必要だった 8 つ以上のサービスを Snowflake 内部の機能だけで実現します。レイヤー構成の詳細は後述します。
共通の懸念: Google Sheets API Quota
どちらの構成を選ぶにしても、Google Sheets API の Quota 制限という問題がありました。
GAS 以外の基盤に移行する場合、Google Sheets API の write requests のデフォルト quota がボトルネックになる可能性があります。AWS 構成でも Snowflake 構成でも同じです。この制限が緩和されなければ、GAS のタイムアウト問題を解決しても、結局別の制約に引っかかってしまいます。
そこで事前に Google Cloud へ Quota 増加リクエストを提出したところ、承認されて Quota 制限が大幅に緩和されました。
意思決定のポイント
最終的に、以下の 2 つの観点で Snowflake 構成を選択しました。
1. 実装速度
Snowflake の組み込み機能で要件 (定期実行・パラメータ設定・オンデマンド実行) を満たせるため、AWS 構成のようにインフラやミドルウェアを個別構築する工数が不要になります。基盤構築に時間をかけず、ユーザー課題に集中できる点が決め手でした。
2. 運用・スキルセットとの相性
データチームのコアスキルセットは SQL、dbt、Snowflake です。SQL と Python で完結する Snowflake 構成なら、新メンバーのキャッチアップも容易です。また、QUERY_HISTORY と TASK_HISTORY でログを一元管理でき、デバッグも単一クエリログで完結します。
レイヤー構成
全体は4つのレイヤーで構成されています。
レイヤー
役割
主なコンポーネント
Tasks
スケジューリング
scheduler_tick, ingest_job_requests_task, run_pending_jobs_task, check_failed_schedules_task
Catalog
メタデータ管理
QUERY_CATALOG, QUERY_SCHEDULES, SPREADSHEET_PARAMETERS
Orchestration
ジョブ制御
JOB_REQUESTS, JOB_STATE, JOB_REQUESTS_STREAM
Core
実行エンジン
EXECUTE_JOB, WRITE_QUERY_TO_SHEET
Tasks層: scheduler_tick が5分間隔でスケジュール対象を取り込み、check_failed_schedules_task が1日1回連続失敗を検知してスケジュールを自動停止します。オンデマンド実行は専用の Task を持たず、UI から JOB_REQUESTS に直接 INSERT します。
Catalog層: QUERY_CATALOG にクエリ定義、QUERY_SCHEDULES にスケジュール設定、SPREADSHEET_PARAMETERS にパラメータ設定を格納します。
Orchestration層: JOB_REQUESTS にリクエストが投入されると JOB_REQUESTS_STREAM (CDC) が変更を検知し、JOB_STATE へジョブをエンキューします。
Core層: EXECUTE_JOB がジョブを受け取り、WRITE_QUERY_TO_SHEET (Python Stored Procedure) を介して Snowflake クエリの実行と Google Sheets への書き込みを行います。
ジョブ実行フロー
実際のジョブ実行フローは以下の通りです。スケジュール実行とオンデマンド実行のどちらも、同じ仕組みで動作します。
📊 Google Sheets⚙️ Python Stored Procedure📥 Job Queue📚 Catalog⏰ Snowflake Tasks👤 ユーザー📊 Google Sheets⚙️ Python Stored Procedure📥 Job Queue📚 Catalog⏰ Snowflake Tasks👤 ユーザー<circle cx=
関連記事
Snowflakeとdbtでモデルの依存関係にガバナンスを効かせる
Amazonにとって朗報、Snowflake が AWS と AI CPU チップ向けに 60 億ドルの契約を締結
データウェアハウス企業 Snowflake は、AWS と AI 処理用 CPU チップに関する 60 億ドル規模の提携契約を正式に締結した。これにより Amazon のクラウド事業が強化される見込みである。
Datasetteからデータを取得するGoogle SheetsのSQL関数
筆者は、Google Sheetsのimportdata関数やApps Scriptを用いてDatasetteからデータを取得する実装パターンを解説している。
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み