Google Apps ScriptでBigQueryにデータを送る手順と、フォームの回答を集計する使い方

2026年9月7日

＠SOHO編集部

この記事のポイント

✓GAS（Google Apps Script）からBigQueryにデータを送る手順を
✓スプレッドシートの読み込み
✓フォームの回答の定期集計まで公式ドキュメントに沿って解説します

GAS（Google Apps Script）からBigQueryを使いたい。スプレッドシートにたまったフォームの回答を、行数を気にせずSQLで集計したい。そう考えて調べ始めると、拡張サービス、Google Cloudのプロジェクト、サンドボックス、ストリーミングと聞き慣れない言葉が続き、どこから手を付ければよいか分からなくなります。

この記事では、GASとBigQueryをつなぐ手順を、Googleの公式ドキュメントで確かめた内容だけで説明します。結論を先に書くと、無料で始めるなら「スプレッドシートの内容をCSVにしてBigQueryへ読み込む（バッチ読み込み）」形がいちばん素直です。1行ずつ送るストリーミングは無料枠では使えません。回答を集計するのではなく、1件ずつ担当を決めて返信したい場合は、BigQueryよりもフォームの回答を管理する道具のほうが合います。その選択肢としてHalictにも後半で触れます。

GASとBigQueryをつなぐ前に知っておきたい全体像

最初に、登場する道具の役割を整理します。ここを押さえておくと、後の手順で迷いません。

GAS（Google Apps Script）は、スプレッドシートやGoogleフォーム、Gmailなどを操作できる、Googleが用意したプログラムの実行環境です。ブラウザの中でコードを書き、ボタンや決まった時刻をきっかけに動かせます。サーバーを用意しなくてよいので、事務作業の自動化によく使われています。

BigQueryは、Google Cloudが提供するデータの保管と集計の仕組みです。何百万行あるデータでも、SQL（データを取り出すための問い合わせの言葉）を書けば数秒で集計できます。スプレッドシートでは重くなって開けない量のデータを扱う場面で使われます。

この2つをつなぐ道が、GASの「拡張サービス」です。Googleの公式ドキュメントは、BigQueryの拡張サービスを次のように説明しています。

BigQuery サービスを使用すると、Google Apps Script で Google BigQuery API を使用できます。この API を使用すると、BigQuery プロジェクトの管理、新しいデータのアップロード、クエリの実行を行うことができます。出典: developers.google.com

つまり、GASからできることは大きく3つです。データを送る（読み込む）、SQLを実行して結果を受け取る、テーブルやデータセットを作る・消すといった管理です。この記事では、前の2つを中心に扱います。

もう1つ押さえておきたいのが、データの入れ物の階層です。BigQueryでは、いちばん外側に「プロジェクト」（Google Cloudの契約の単位）、その中に「データセット」（テーブルをまとめるフォルダのようなもの）、さらにその中に「テーブル」（行と列を持つ表）があります。GASのコードでは、この3つのIDを必ず指定します。スプレッドシートに例えると、プロジェクトがGoogleドライブ、データセットがフォルダ、テーブルがシートに近い関係です。

始める前に用意するものと、無料で使える範囲

BigQueryを使うには、Google Cloudのプロジェクトが必要です。クレジットカードを登録しなくても試せる「BigQueryサンドボックス」という入り口があり、公式ドキュメントでは次のように説明されています。

BigQuery サンドボックスでは、クレジットカード情報の登録、請求先アカウントの作成を行うことなく、BigQuery を体験できます。出典: cloud.google.com

サンドボックスには制限があります。公式ドキュメントに書かれている主なものは次のとおりです。

項目	サンドボックスでの扱い
無料で使える量	毎月10GBのアクティブストレージと1TBのクエリデータ処理
テーブルの有効期限	テーブル・ビュー・パーティションは60日後に自動で期限切れ
データのストリーミング	使えない
DML（INSERT・UPDATEなどの書き換えの文）	使えない
BigQuery Data Transfer Service	使えない

この表でいちばん大事なのは、ストリーミングとDMLが使えない点です。ストリーミングとは、データを1行ずつリアルタイムにテーブルへ送る方法のことです。DMLとは、SQLの「INSERT」「UPDATE」「DELETE」のような、テーブルの中身を書き換える命令のことです。GASの記事でよく見かける「フォームが送信されるたびに1行ずつBigQueryへ追加する」形は、このどちらかを使うため、サンドボックスでは動きません。

もう1つ見落とされやすいのが、60日の有効期限です。サンドボックスで作ったテーブルは60日たつと自動で消えます。フォームの回答を長く保管する入れ物にするなら、課金を有効にしてサンドボックスから外し、テーブルの有効期限を設定し直す必要があります。

課金を有効にした場合の料金も、公式の料金ページで確かめておきます。オンデマンド料金（処理したデータの量で払う方式）では、クエリで処理するデータは毎月1TiBまで無料です。料金ページに表示されているリージョンの例では、それを超えた分は1TiBあたり6.25ドルです。料金はリージョン（データを保存する地域）で変わるので、使うリージョンの表示を確かめてください。ストレージも毎月10GiBまで無料です。スプレッドシートから移す程度のデータ量なら、無料枠の中に収まることがほとんどです。

料金ページには、バッチ読み込みについて次の記載もあります。

デフォルトでは、Cloud Storage またはローカルファイルから BigQuery にデータをバッチ読み込みしても料金は発生しません。出典: cloud.google.com

まとめてファイルとして読み込む方法は、それ自体には料金がかかりません。この点も、GASからはバッチ読み込みを選ぶ理由になります。

拡張サービスを有効にする手順

GASからBigQueryを使う最初の手順は、スクリプトの中でBigQueryの拡張サービスを有効にすることです。公式ドキュメントの手順は次のとおりです。

Apps Scriptのプロジェクトを開く（スプレッドシートからなら、メニューの「拡張機能」から「Apps Script」）
左側の「エディタ」を開く
左側の「サービス」の横にある「サービスを追加」（プラスの印）を押す
一覧から「BigQuery API」を選び、「追加」を押す

これで、コードの中で BigQuery.Jobs.query のように書けるようになります。エディタの入力補完にも候補が出るようになるので、有効になったかどうかはそこで確かめられます。

公式ドキュメントには、マニフェスト（appsscript.json という設定ファイル）を直接書き換えて有効にする方法も載っています。複数のスクリプトに同じ設定を入れたいときはこちらが速いですが、初めてなら画面の操作で十分です。

次に、データを入れる側のGoogle Cloudプロジェクトを確かめます。Google Cloudコンソールで BigQuery のページを開き、プロジェクトを作るとサンドボックスが有効になります。画面の上に表示される「プロジェクトID」をメモしておいてください。GASのコードでは、このIDを毎回渡します。

続けて、BigQueryの画面でデータセットを1つ作ります。左側のエクスプローラでプロジェクト名の横のメニューから「データセットを作成」を選び、名前（例えば forms）とロケーションを決めます。ロケーションは東京（asia-northeast1）など、後から変えられないので最初に決めておきます。

最初の実行では、権限の承認を求める画面が出ます。GASが自分のアカウントでBigQueryを操作してよいかを確認する画面なので、内容を読んで許可します。ここで「このアプリはGoogleで確認されていません」と出ることがありますが、自分で書いたスクリプトを自分で動かしている場合に出る表示です。他人から受け取ったスクリプトの場合は、中身を読んでから許可してください。

GASからクエリを実行して結果をスプレッドシートに書き出す

まずは読み出しから試すのがおすすめです。BigQueryには誰でも使える公開データセットがあり、自分のデータを入れなくても動作を確かめられます。公式ドキュメントのサンプルを短くすると、次のようになります。

function runQuery() {
  const projectId = 'your-project-id'; // 自分のプロジェクトID
  const request = {
    query: 'SELECT refresh_date, term, rank ' +
           'FROM `bigquery-public-data.google_trends.top_terms` ' +
           'WHERE rank = 1 AND refresh_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) ' +
           'GROUP BY refresh_date, term, rank ORDER BY refresh_date DESC',
    useLegacySql: false,
  };
  let results = BigQuery.Jobs.query(request, projectId);
  const jobId = results.jobReference.jobId;
  let wait = 500;
  while (!results.jobComplete) {
    Utilities.sleep(wait);
    wait *= 2;
    results = BigQuery.Jobs.getQueryResults(projectId, jobId);
  }
  const rows = results.rows || [];
  const headers = results.schema.fields.map((f) => f.name);
  const data = rows.map((r) => r.f.map((c) => c.v));
  const sheet = SpreadsheetApp.getActiveSpreadsheet().insertSheet('BigQuery結果');
  sheet.getRange(1, 1, 1, headers.length).setValues([headers]);
  if (data.length) sheet.getRange(2, 1, data.length, headers.length).setValues(data);
}

ポイントは3つあります。

1つ目は useLegacySql: false です。BigQueryには古い書き方（レガシーSQL）と標準のSQLがあり、この指定を入れると標準のSQLで動きます。公式のサンプルもこの形で、新しく書くならこの指定を必ず入れます。

2つ目は、結果を待つ処理です。BigQuery.Jobs.query は、集計が時間内に終わらないと、結果を返さずに jobComplete が false の状態で戻ってきます。そこで少しずつ待つ時間を伸ばしながら getQueryResults で問い合わせ直します。公式サンプルもこの書き方で、待つ時間を倍々に伸ばしています。

3つ目は、結果の形です。BigQueryから返る行は、rows[i].f[j].v という入れ子の形になっています。スプレッドシートに書くには、上のコードのように普通の2次元の配列に直してから setValues に渡します。結果が多いときは pageToken を使って続きを取り出す必要があり、公式サンプルにはその処理も入っています。数千行を超える結果を扱うなら、公式サンプルの全文を見て、ページ送りの部分も取り込んでください。

クエリの料金は、取り出す行の数ではなく、読み込んだ列のデータ量で決まります。料金ページには、LIMITを付けても選んだ列のデータ量で課金されると書かれています。必要な列だけをSELECTに書く、日付で絞り込む、という2つの習慣が、無料枠を長持ちさせるいちばんの方法です。

スプレッドシートの内容をBigQueryに読み込む手順

次は、GASからBigQueryへデータを送る方法です。サンドボックスでも使えるのは、CSVなどのファイルをまとめて読み込む「読み込みジョブ」です。公式ドキュメントのサンプルは、GoogleドライブのCSVファイルを読み込む形になっています。これをスプレッドシートから直接読み込む形に書き換えると、次のようになります。

function loadSheetToBigQuery() {
  const projectId = 'your-project-id';
  const datasetId = 'forms';
  const tableId = 'responses';
  const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName('フォームの回答 1');
  const values = sheet.getDataRange().getDisplayValues();
  const csv = values
    .map((row) => row.map((v) => '"' + v.replace(/"/g, '""') + '"').join(','))
    .join('\n');
  const blob = Utilities.newBlob(csv, 'application/octet-stream');
  const job = {
    configuration: {
      load: {
        destinationTable: { projectId, datasetId, tableId },
        skipLeadingRows: 1,
        writeDisposition: 'WRITE_TRUNCATE',
        schema: {
          fields: [
            { name: 'submitted_at', type: 'STRING' },
            { name: 'plan', type: 'STRING' },
            { name: 'score', type: 'INTEGER' },
            { name: 'comment', type: 'STRING' },
          ],
        },
      },
    },
  };
  const result = BigQuery.Jobs.insert(job, projectId, blob);
  console.log('読み込みジョブ: ' + result.jobReference.jobId);
}

書き換えた点と、その理由を説明します。

getValues ではなく getDisplayValues を使っています。getValues は日付を日付の型で返すため、そのまま文字にすると英語の長い日付表記になり、BigQueryで扱いにくくなります。getDisplayValues なら、シートに表示されているとおりの文字で取れます。

各セルをダブルクォートで囲み、セルの中のダブルクォートは2つ重ねています。自由記述の回答にはカンマや改行が入ることがあり、そのままCSVにすると列がずれます。囲んでおけば、カンマや改行を含む回答も1つのセルとして読み込まれます。

skipLeadingRows: 1 は、1行目の見出しを読み飛ばす指定です。schema で列の名前と型を自分で決めているので、見出しの日本語は使いません。BigQueryの列の名前は英字にしておくと、SQLを書くときに引用符で囲む手間が減ります。列の数と順番は、シートの列と必ず合わせます。シートに列が5つあるのにスキーマが4列だと、読み込みジョブは失敗します。

writeDisposition: 'WRITE_TRUNCATE' は、テーブルの中身を毎回すべて入れ替える指定です。スプレッドシート側に全件がたまっている前提なら、毎回まるごと入れ替えるのがいちばん単純で、二重登録の心配もありません。差分だけを追加したいときは WRITE_APPEND にしますが、その場合は前回どこまで送ったかを自分で管理する必要があります。

なお、BigQuery.Jobs.insert は読み込みを「依頼する」だけで、完了を待たずに戻ってきます。読み込みが成功したかどうかは、BigQueryの画面の「ジョブ履歴」で確かめるか、返ってきたジョブIDで BigQuery.Jobs.get を呼んで状態を見ます。失敗の理由（列の数が合わない、型が合わないなど）もそこに出ます。

フォームの回答を定期的に集計する使い方

ここまでの2つを組み合わせると、Googleフォームの回答をBigQueryで集計する仕組みが作れます。考え方は次のとおりです。

Googleフォームの回答は、これまでどおりスプレッドシートにたまるようにしておく
時間主導型のトリガーで、1日1回 loadSheetToBigQuery を動かし、テーブルを入れ替える
集計したいときは、BigQueryの画面か、GASの runQuery でSQLを実行する

時間主導型のトリガーとは、決まった時刻や間隔でスクリプトを自動で動かす仕組みのことです。公式ドキュメントの手順では、Apps Scriptのプロジェクトで左側の「トリガー」を開き、右下の「トリガーを追加」を押して、実行する関数と「時間主導型」を選び、時刻を決めて「保存」します。公式ドキュメントには、時刻は多少ずれることがあり、例えば午前9時に設定すると午前9時から10時の間で実行時刻が決まる、という説明があります。

フォームが送信されるたびに動かしたい場合は、「フォーム送信時」のトリガーも選べます。ただし前の節で書いたとおり、1行ずつBigQueryに入れるストリーミングは無料枠では使えません。公式ドキュメントには、課金を有効にせずに試すと次のエラーが出ると書かれています。

無料枠でストリーミングは利用できません。課金を有効にせずストリーミングの使用を試みると、次のエラーが表示されます。BigQuery: Streaming insert is not allowed in the free tier. 出典: cloud.google.com

このため、無料で始めるなら「スプレッドシートにためて、定期的にまとめて読み込む」形が現実的です。集計の目的が月次の報告や週ごとの傾向を見ることなら、1日1回の更新で困ることはまずありません。

集計のSQLの例も1つ示します。満足度を5段階で聞いたフォームなら、プランごとの平均点と件数は次のように出せます。

SELECT plan, COUNT(*) AS answers, ROUND(AVG(score), 2) AS avg_score
FROM `your-project-id.forms.responses`
GROUP BY plan
ORDER BY answers DESC

日付で絞りたいときは、submitted_at を文字として読み込んでいるので、SQLの中で日付に直してから比べます。フォームのタイムスタンプは「2026/10/14 9:05:12」のような形なので、PARSE_DATETIME('%Y/%m/%d %H:%M:%S', submitted_at) で日時に直せます。シートの表示形式によって書式は変わるので、実際のセルの表示を見て合わせてください。

課金を有効にしたあとに費用を抑える設定

サンドボックスから外して課金を有効にすると、テーブルの60日の期限やストリーミングの制限はなくなります。その代わり、無料枠を超えた分は請求の対象になります。フォームの集計くらいの量なら無料枠に収まることがほとんどですが、SQLの書き方を誤ると、一度に大きなテーブルを読んでしまうことがあります。公式の料金ページで案内されている、費用を抑えるための設定を押さえておきます。

1つ目は、クエリで課金される最大のバイト数を決めておく方法です。料金ページには、クエリ料金に上限を設けるしくみとして、プロジェクト単位やユーザー単位のカスタムのコスト管理と、クエリで課金される最大バイト数の指定が挙げられています。GASから実行するクエリでも、リクエストに上限を指定しておけば、想定より大きなデータを読もうとしたときにクエリが失敗して止まります。料金が発生する前に止まるので、試行錯誤の段階で入れておくと安心です。

2つ目は、読み込むデータそのものを減らすことです。料金ページには、テーブルを日付などで分割するパーティショニングと、よく絞り込む列で並べておくクラスタリングによって、クエリで処理されるデータ量を減らせると書かれています。フォームの回答のように日付で増えていくデータなら、日付で分割しておくと「先月分だけ」の集計で読む量が小さくなります。

3つ目は、Google Cloudの予算のアラートです。課金を有効にしたプロジェクトでは、請求の画面で予算を決め、使用額がその割合に達したらメールで知らせる設定ができます。金額の上限で自動的に止まる仕組みではありませんが、気づかないうちに請求が膨らむことは防げます。

差分だけを追加したいときの考え方

毎回テーブルをまるごと入れ替える方法は単純ですが、回答が何万件にもなると、毎日すべてを送り直すのは無駄が多くなります。その場合は、前回送った行の続きだけを送る形にします。

やり方は、スクリプトのプロパティ（スクリプトごとに小さな値を保存できる仕組み）に「前回どの行まで送ったか」を記録しておく方法が扱いやすいです。PropertiesService.getScriptProperties() で保存と読み出しができます。次の実行では、記録した行の次から最後の行までをCSVにし、writeDisposition を WRITE_APPEND（今あるテーブルの後ろに足す指定）にして読み込みます。読み込みジョブが成功したことを確かめてから、記録する行番号を更新するのが大事な点です。失敗したのに行番号だけ進めると、その分の回答がBigQueryに入らないまま抜け落ちます。

もう1つの注意は、シートの行を途中で削除したり並べ替えたりしないことです。行番号で続きを管理しているので、途中の行が消えると、送っていない行を飛ばしたり、同じ行を2回送ったりします。差分方式にするなら、元のシートは追記だけの記録として扱い、整理や修正は別のシートで行う決まりにしておきます。

つまずきやすい点と確かめ方

GASとBigQueryの組み合わせでよく止まるところを、確かめ方と一緒に並べます。

プロジェクトIDの指定違い。 GASのコードに書くのは、プロジェクトの「名前」ではなく「ID」です。名前は日本語で付けられますが、IDは英小文字と数字とハイフンの組み合わせです。Google Cloudコンソールの上部でプロジェクトを選ぶ画面に、両方が並んで表示されるので見比べてください。

権限の不足。 スクリプトを動かすアカウントに、そのプロジェクトのBigQueryを使う権限が必要です。自分で作ったプロジェクトなら問題ありませんが、会社のプロジェクトを使う場合は、管理者にデータの編集とジョブの実行ができる役割を付けてもらいます。

6分の壁。 GASには、1回の実行は6分までという上限があります。公式の割り当てのページでは、一般のアカウントでもGoogle Workspaceのアカウントでも、スクリプトの実行時間は1回あたり6分です。トリガーで動くスクリプトの合計時間にも、一般のアカウントで1日90分、Google Workspaceで1日6時間という上限があります。何十万行もあるシートを毎回CSVにすると、この上限に近づきます。その場合は、シートを月ごとに分ける、読み込みは差分だけにする、といった工夫が要ります。

型の不一致。 スキーマで INTEGER にした列に「5（とても満足）」のような文字が入っていると、読み込みは失敗します。フォームの選択肢を数字だけにするか、その列は STRING で読み込んでSQLの中で数字に直すかのどちらかにします。

トリガーが失敗しても気づかない。 公式ドキュメントには、インストール可能なトリガーで関数が失敗しても画面にエラーは表示されず、代わりにApps Scriptから失敗のまとめのメールが届くと書かれています。英語の件名（Summary of failures for Apps Script）で届くので、迷惑メールや通知のフォルダに埋もれていないかを確かめてください。トリガーを追加する画面で、失敗の通知をどの頻度で受け取るかも選べます。

サンドボックスの60日。 先に書いたとおり、サンドボックスのテーブルは60日で期限が切れます。毎日 WRITE_TRUNCATE で作り直していれば実害はありませんが、BigQueryにしか残していないデータは消えてしまいます。元のデータは必ずスプレッドシート側に残しておきます。

BigQueryに移す前に考えたい、ほかの選択肢

GASとBigQueryの組み合わせは強力ですが、すべての場面に向いているわけではありません。目的によっては、もっと手軽な方法で済みます。

数千行までの集計なら、スプレッドシートのままで足ります。 ピボットテーブルやQUERY関数を使えば、プランごとの件数や平均点は数分で出せます。BigQueryが力を発揮するのは、スプレッドシートが重くなって開くのに時間がかかる量（数十万行以上）になってからです。最初からBigQueryを用意すると、プロジェクトや権限の管理という手間が増えます。

画面で見るだけなら、コネクテッドシートという機能もあります。 Google Workspaceの一部のプランでは、BigQueryのデータをスプレッドシートから直接扱えます。GASの公式リファレンスにも、この機能を操作するクラスが載っています。使えるプランかどうかは、自分の契約の内容で確かめてください。

回答を集計するのではなく、1件ずつ対応したいなら、別の道具が合います。 問い合わせ、応募、申し込みのように、届いた回答ごとに「誰が対応するか」「返信したか」を管理したい場面では、BigQueryは向いていません。BigQueryは全体の傾向を見る集計の道具で、1件ずつ担当を付けて進める道具ではないからです。

この場面では、スプレッドシートに「担当」「状況」の列を足して手で埋め、返信はメールソフトから送る、という運用になりがちです。回答が増えると、どの行に返信したかが分からなくなります。

その用途で使える選択肢の1つが、フォームの道具のHalictです。公式サイトによると、フォームで届いた回答1件ごとに担当者・ステージ（対応の状況）・タグを付けて管理でき、返信も同じ画面から送れます。回答の一覧はCSVに書き出せるので、集計はこれまでどおりスプレッドシートやBigQueryで行えます。料金ページでは、1人で使うフリープランが0円で、Googleスプレッドシートへの追記（新しい回答が1行ずつ追記される連携）は月額2,980円（税抜）のスタータープランから使えると案内されています。「受け付けと対応はHalict、全体の集計はBigQuery」と役割を分ける使い方もできます。

Halictは、@SOHOを運営する株式会社ライフスケープが開発・提供しています。

GASとBigQueryの組み合わせが仕事で求められる場面

最後に、この技術が仕事の上でどう役立つかを、市場の目線で整理します。

GASとBigQueryの組み合わせは、エンジニアの専門的な開発というより、事業部門のデータ活用の場面で求められることが多い技術です。営業の問い合わせ、イベントの申し込み、社内アンケートなど、スプレッドシートにたまった情報を「もっと速く、もっと細かく集計したい」という相談から始まります。依頼する側は、本格的なデータ基盤を作るほどの予算はないものの、手作業の集計からは抜け出したい、という段階にいることがほとんどです。

こうした仕事は、業務の自動化やAI活用の支援と一緒に頼まれることが増えています。業務の流れを聞き取り、どこをGASで自動化し、どのデータをBigQueryに集めるかを設計する仕事は、AIコンサル・業務活用支援のお仕事の中身とも重なります。業務の流れを整理するところから関わるので、コードを書く力に加えて、相手の仕事を聞き取る力が求められます。

もう一歩進んで、集めたデータを画面で見せる仕組みや、社内向けの小さな道具を作る段階になると、アプリケーション開発のお仕事の領域に入ります。GASで作った仕組みが社内で定着すると、次はもっと大きな仕組みを作りたい、という相談につながりやすいのがこの分野の特徴です。

データの集計や分析そのものを仕事にしている人の相場感は、研究者の年収・単価相場のページで、データを扱う専門職の収入の目安として確かめられます。集計の結果を広告やマーケティングの判断に使う仕事に広げたい場合は、AI・マーケティング・セキュリティのお仕事で、どんな依頼があるかを見ておくと方向を決めやすくなります。

在宅ワークとフリーランスの仲介を2004年から続けてきた運営者として見てきた限りでは、この種の仕事で長く続く人は、作った仕組みを相手が自分で直せる形で渡しています。コードに説明を書き、トリガーの設定と失敗通知の受け取り先を引き継ぎの資料に残す。データの集計の仕組みは、作った後に何年も使われることが多いので、その一手間が次の依頼につながります。仲介の手数料がかからない直接の取引であれば、同じ予算で依頼する側は保守まで頼みやすく、受ける側は手取りが厚くなります。小さな自動化から始めて、相手の業務に長く関わる関係を作れるのが、GASとBigQueryの仕事の良さです。

よくある質問

Q. GASからBigQueryを使うのに料金はかかりますか？

BigQueryサンドボックスを使えば、クレジットカードを登録せずに試せます。無料で使えるのは毎月10GBのストレージと1TBのクエリ処理までです。ファイルをまとめて読み込むバッチ読み込みには料金がかかりません。課金を有効にした場合も無料枠は同じで、超えた分はリージョンごとの料金で計算されます。

Q. フォームが送信されるたびにBigQueryへ1行ずつ追加できますか？

課金を有効にしたプロジェクトなら、ストリーミングで1行ずつ追加できます。ただし無料枠ではストリーミングは使えず、試すと「Streaming insert is not allowed in the free tier」というエラーが出ます。無料で始めるなら、回答をスプレッドシートにためて、1日1回まとめて読み込む形が現実的です。