【第3ページ】データストア（保管庫）の選び方と高度な抽出テクニック
フロントエンドの動的な仕組み（DOM）を理解し、サーバーとの通信（REST API/JSON）をマスターした私たちが次に直面する壁。それは、「データをどこに、どうやって保存し、どうやって効率よく取り出すか」という、データストア（保管庫）の設計問題です。
個人開発や社内ツール開発において、手軽さから「Googleスプレッドシート」を暫定的なデータベース（DB）として使うケースは非常に多いでしょう。しかし、システムの規模が大きくなるにつれ、必ず「処理速度の低下」や「システムの限界」にぶつかります。
今回は、データの特性に合わせた保管庫の選び方と、Googleの技術スタック（GAS/スプレッドシート）を極限までチューニングして爆速化するプロのテクニックを解説します。
3.1 スプレッドシート（2次元表） vs JSON（多次元ファイル）の切り分け基準
データを管理する方法として、誰もが直感的に扱える「スプレッドシート（2次元の行・列）」と、プログラムと相性抜群の「JSON（多次元の入れ子構造）」。この2つを実務で選定する際、どのような基準で切り分けるべきでしょうか？
4つの明確なトレードオフ（妥協点）から、その境界線を浮き彫りにします。 比較項目 Googleスプレッドシート（2次元表） JSON / NoSQL / RDB（多次元） 実用行数の限界数万行が限界（動作が極端に重くなる） 数十万〜数千万行でも高速処理可能 データ構造フラット（行と列の単純な2次元マトリクス） 無限の入れ子（ネスト）や配列構造が可能 アクセス頻度数秒に1回（同時書き込みでロック・競合が発生） ミリ秒単位（毎秒数千回の超高頻度アクセス可） 最大の価値非エンジニア（人間）が直接編集・閲覧できるプログラムがミリ秒単位で高速処理できる
境界線を決める「最大にして唯一の基準」
技術的な仕様よりも重要な選定の決定打は、「誰がそのデータを触るか（更新するか）」です。
- スプレッドシートを選ぶべきケース：
現場の営業スタッフや事務員など、プログラミングができないメンバーが「直接画面を開いて、データを手入力したり修正したりしたい」という要件がある場合。この場合、最高に使いやすいUI（ユーザーインターフェース）が最初から無料で手に入ることになるため、スプレッドシート一択になります。 - JSON / 本格DBを選ぶべきケース：
システム間でデータを自動連携し、1秒間に何度もデータが書き換わったり、ユーザーのプロフィールの中に「過去の購買履歴（配列）」や「住所（ネスト）」といった複雑なデータが紐づいたりする場合。
2次元の表に無理やり複雑なデータを詰め込もうとすると、データの一貫性が崩れる原因になります。用途に合わせた「適材適所」の選定が第一歩です。
3.2 GoogleサイトにおけるGAS（Google Apps Script）の連携制限
社内ポータルなどを構築する際、「Googleサイト」に自作のHTML/JavaScriptを埋め込み、裏側で「GAS（Google Apps Script）」を動かしてスプレッドシートのデータを表示させる、という構成は定番です。しかし、ここには初心者開発者が必ず絶望する「2つの大きな壁（制限）」が存在します。
壁①：iFrame（埋め込み枠）内での動作制限
Googleサイトに自作のHTMLコードを貼り付けると、ブラウザのセキュリティ上、それは「iFrame」という隔離された砂箱（サンドボックス）の中で実行されます。
このため、親画面（Googleサイト全体）のURLを取得したり、ページ全体のデザインをハッキングして書き換えたりすることが厳格に禁止されます。
壁②：デザイン（CSS）が効かない壁と、クロスドメインの制限
GASを「Webアプリ（DoGet）」として公開し、そこに対してフロントエンドから fetch() で通信しようとすると、セキュリティエラー（CORSエラー）に阻まれることが多々あります。
また、GASが自動生成するHTMLにBootstrapやTailwind CSSなどのモダンなCSSフレームワークを適用しようとしても、Google側のセキュリティフィルターによってスタイルの一部が剥ぎ取られたり、意図しない崩れ方をしたりします。
🛠️ 壁の乗り越え方
この制限を乗り越える最もスマートな方法は、「GASにはデザインを一切させない（HTMLを返させない）」ことです。
GASは純粋な「APIサーバー（JSONを返すだけの機械）」に徹しさせ、Googleサイト側の埋め込みコード（HTML/JS）からそのAPIを叩き、届いたJSONデータをフロントエンド側でDOM操作して綺麗にレンダリングする。これが、本連載で一貫して推奨している「密結合から疎結合（APIベース）へのシフト」です。
3.3 スプレッドシートのSQL化（Google Visualization API）
前述の通り、「GASをAPIサーバーにして、スプレッドシートのデータをJSONで返す」という設計は美しいですが、1つ致命的な弱点があります。それが「GASの実行速度」と「6分間の実行時間制限（タイムアウト）」です。
スプレッドシートのデータが数千件、数万行に増えてくると、GASの SpreadsheetApp.getActiveSpreadsheet() などの標準関数は、データをメモリに読み込むだけで数秒〜数十秒の時間を消費するようになります。ユーザーが画面を開いてから、データが表示されるまで10秒も待たされるようでは、アプリとして実用に耐えません。
そこで登場する最強の裏技が、Google Visualization API（gviz）を使った「スプレッドシートの完全SQL化」です。
gviz/tq エンドポイントとは？
Googleスプレッドシートには、公式ドキュメントにはあまり大々的に書かれていない、隠された超強力なエンドポイント（通信窓口）が存在します。それが以下の構造を持つURLです。https://docs.google.com/spreadsheets/d/【スプレッドシートのID】/gviz/tq?tq=【SQLクエリ】
なんと、このURLに対して適切なリクエストを送ると、GASのプログラムを1行も仲介することなく、Googleの超高速なサーバー群がスプレッドシートのデータをデータベースと見なして、直接SQLクエリを実行し、結果を爆速で返してくれるのです。
3.4 【実装実例】GASを通さず、スプレッドシートにSQLを投げる爆速化テクニック
それでは、実際にフロントエンド（JavaScript）から、スプレッドシートに対して直接「SQL（Query言語）」を投げつけ、一瞬でフィルタリングされたデータを取得する実用コードを見てみましょう。
前提条件
- スプレッドシートの共有設定が「リンクを知っている全員が閲覧可能」になっていること。
- A列に「商品名」、B列に「カテゴリ」、C列に「価格」、D列に「ステータス」が入っていると仮定します。
JavaScript（フロントエンド実装）
// 7. 純粋なJSONオブジェクトに変換
const resData = JSON.parse(jsonString);
const rows = resData.table.rows;
console.log(‘— 爆速でSQL抽出されたデータ一覧 —‘);
// 配列のマッピングと安全な値の取り出し（オプショナルチェーニングを使用）
const products = rows.map(row => ({
name: row.c?.[0]?.v ?? ‘なし’,
price: row.c?.[1]?.v ?? 0
}));
// テーブル形式でコンソールに綺麗に表示
console.table(products);
この裏技が「神」である理由
- GASの実行時間（6分制限）を完全に無視できる：
サーバー側（Googleのインフラ内部）で一瞬でフィルタリングが行われるため、クライアント（ブラウザ）に届くデータ量は最小限になります。 - 圧倒的なスピード：
GASを起動して、スプレッドシートを開いて、全行をループで回して……という処理をブラウザ側で待つ必要がありません。ミリ秒単位で結果が返ってきます。 - サーバーレス＆無料：
自分でデータベースサーバーを契約して管理するコストを1円もかけることなく、数万行クラスの簡易的な「リレーショナル風データベース」を構築・運用できます。
🧭 次回予告：第4ページ
スプレッドシートをハックして高速化する術を身につけました。しかし、データの量や種類がさらに増え、画像のアップロードや、より高度な管理画面（入力画面）をノンコードでノンストレスに運用したいとなったとき、スプレッドシートは本当の限界を迎えます。
そこで次回第4ページでは、世界最大のシェアを誇るCMSである「WordPress」を、最強の外部データベースとしてフル活用する「ヘッドレスCMS構成」に挑戦します。
「ACF（Advanced Custom Fields）」というプラグインを駆使し、管理画面をノーコードで爆速構築しながら、裏側では複雑な多次元JSONを出荷するモダン開発の極意を、ディープに解説します。次回のイノベーションをお楽しみに！
この記事が「スプレッドシートの限界突破に役立った！」「gviz/tqの裏技が凄すぎる」と思った方は、ぜひ「いいね」や「フォロー」で応援をお願いします！