データ基盤を作ったのに、依頼が減らない。
BigQuery にデータを集約し、集計クエリも整備した。それでも営業企画から「先月分を、この3店舗だけで出してほしい」「今度は別の2店舗で」という連絡が週に何度も来る。やっていることはWHERE句の値を差し替えるだけなのに、依頼が来るたびに手が止まる。
この構造が続く理由ははっきりしていて、条件を変える手段がクエリの編集しかないからです。クエリを触れるのは限られた人間なので、その人が窓口になり続けます。2026年8月のConnected Sheetsの更新は、ここに効きます。
セル範囲を、そのまま複数値の条件にできる
Connected Sheets には以前からパラメータの仕組みがありましたが、扱えるのは基本的に単一の値でした。「3店舗」のような複数値を渡したい場合、パラメータを3つ用意する、カンマ区切りの文字列を渡して分解する、といった回避策が必要で、条件の数が変わるたびに作り直しになっていました。
新しいリストパラメータでは、シート上のセル範囲を選択すると、その範囲の各セルがリストの1要素として扱われます。店舗コードを縦に並べたセル範囲を指定すれば、それがそのまま検索条件になります。行を増やせば条件が増え、消せば減る。クエリ側の書き換えは発生しません。
クエリ側では UNNEST() でリストを展開して使います。
SELECT
store_code,
SUM(sales_amount) AS total_sales
FROM `project.dataset.daily_sales`
WHERE
store_code IN UNNEST(@target_stores)
AND sales_date BETWEEN @date_from AND @date_to
GROUP BY store_code
ORDER BY total_sales DESC@target_stores にセル範囲を割り当てておけば、あとは利用者がそのセルを編集するだけです。ここが重要な点で、利用者はSQLを一切見ません。見るのは入力用のシートだけです。
展開は Rapid Release と Scheduled Release の両方に対して進んでおり、2026年8月15日までに完了する見込みです。対象は Google Workspace の全エディションと、個人の Google アカウントです。
入力シートは「触ってよい場所」を先に決める
この仕組みの肝は、機能そのものよりもシートの設計にあります。自由に触れるシートをそのまま渡すと、条件セル以外を壊されて「動かなくなった」という問い合わせが返ってきます。
実務で機能する形にするなら、最低限この3つを分けます。
- 入力シート — 条件セルだけを置く。プルダウン（データの入力規則）で選択肢を固定し、手打ちの表記ゆれを防ぐ
- 抽出結果シート — Connected Sheets の結果が入る。利用者は参照するだけで編集しない
- マスタシート — 店舗コードや部門コードの一覧。プルダウンの参照元。ここは管理側が更新する
そのうえで、シート保護で入力シートの条件セル以外を編集不可にします。ここまでやって初めて「依頼者に渡せる状態」になります。保護をかけずに配ると、数週間後には元の依頼フローに戻っています。壊れるのが怖くて誰も触らなくなるからです。
見落とされやすい2つの落とし穴
1つめは、権限がスプレッドシート側とBigQuery側で別だという点です。シートを共有しても、相手にBigQuery側の参照権限がなければデータは更新されません。逆に、更新を管理者だけが行う運用にするなら、利用者は最後に更新された結果を見ていることになります。この2つは見え方が似ていて、「数字が古い」というトラブルの典型的な原因です。どちらの運用にするかを決めて、シート上に最終更新時刻を出しておくと事故が減ります。
2つめは、クエリ課金です。利用者が条件を変えるたびにクエリが走ります。セルフサービス化は依頼を減らしますが、実行回数は増える方向に働きます。対象テーブルにパーティションを切って日付で絞る、頻繁に見る集計は事前集計テーブルに落としておく、といった前処理がないまま生ログに直接当てると、想定外の請求になります。
ダッシュボードにするか、シートにするか
同じ「自分で見られるようにする」でも、Looker Studio のようなBIツールで作る選択肢があります。使い分けの目安はこうです。
| Connected Sheets | BIダッシュボード | |
|---|---|---|
| 向く用途 | 抽出した数字を加工・編集して次の作業に使う | 決まった指標を定点観測する |
| 利用者の慣れ | 表計算の操作がそのまま使える | ツールの操作を覚える必要がある |
| 出力の自由度 | セルなので後工程に流しやすい | 画面の設計に縛られる |
「見て終わり」ならダッシュボード、「見た数字を使って何か作る」ならスプレッドシートが素直です。営業企画や経理のように、抽出したあとに別の資料へ組み込む工程がある部署は後者に寄せたほうが定着します。ダッシュボード側の設計はLooker StudioでBIダッシュボードを作るにまとめています。
なお、Excelで運用していた集計をこちらに寄せる場合は、変換時の取り込み精度が2026年8月に改善しています。Excelのテーブルとピボットの移行を先に確認しておくと、作り直しの範囲が読めます。シート単体での自動化の範囲はGoogleスプレッドシートで業務を自動化する、基盤側のテーブル設計はBigQueryのオープンレイクハウス構成が参考になります。
次にやること
自分のところに来ている抽出依頼を、直近1ヶ月分だけ見返してください。そのうち「条件の値が違うだけ」のものが何割あるか。半分を超えているなら、この仕組みで消せる依頼です。
逆に、依頼のたびに集計軸そのものが変わっているなら、原因はパラメータではなくテーブル設計側にあります。その場合はシートを整える前に、どの粒度で持つべきかを決め直すほうが先です。
BigQuery側のテーブル設計から入力シートの権限設計まで含めて相談したい場合は、グリームハブのIT・Google Workspace 無料相談で承っています。データ量や利用部署の広がり方によって適切な構成は変わるため、個別にご相談ください。お問い合わせからどうぞ。
