【ITニュース解説】Google Sheets to Your Warehouse: the Share Step Is the One That Fails

企業内で多くの部署が、マーケティング予算、財務モデル、顧客管理など、様々な業務データをGoogle Sheetsに整理し、管理している。これらのGoogle Sheetsは、部署ごとの「シャドウデータベース」として機能し、日々の業務に不可欠な存在となっている。しかし、これらの重要なデータが企業全体のデータウェアハウスに統合されていないため、他のシステムデータと組み合わせて分析することが難しいという問題が発生する。結果として、データは手動でコピー＆ペーストされ、常に最新ではない状態でダッシュボードに表示されるという状況が生まれている。

Google Sheetsのデータをデータウェアハウスに取り込むことは、データの鮮度と統合性を保ち、より深い分析を可能にする上で非常に重要だ。Datanikaのようなツールを使えば、この連携は効率的に行える。DatanikaにおけるGoogle Sheetsはソースとしてのみ機能し、Sheetsへのデータの書き戻しはできない。データ連携を始めるには、まずデータを格納する宛先となるデータウェアハウス（PostgreSQLなど）が必要で、さらにGoogle Cloudプロジェクトを用意し、Google Sheets APIを有効にしておく必要がある。すでにBigQueryをDatanikaで使用している場合は、その既存プロジェクトとサービスアカウントを再利用し、Sheets APIを有効にするだけで良い。

次に、Google CloudのIAM & Adminセクションでサービスアカウントを作成する。ここで注意すべきは、このサービスアカウントにIAMロールを一切与えないことだ。多くの人は役割を付与することが適切だと感じるかもしれないが、DatanikaがSheetsにアクセスする際にはGoogle CloudリソースではなくSheets APIを直接利用するため、IAMロールは不要であり、むしろ不必要にアクセス範囲を広げるだけとなる。サービスアカウントを作成したら、JSONキーファイルをダウンロードし、そのサービスアカウントのメールアドレス（例: datanika-sheets-reader@your-project.iam.gserviceaccount.com）を控えておく。このメールアドレスが今回のデータ連携において最も重要な要素となる。

この連携プロセスで多くの人が最初に失敗するポイントが、まさにこのサービスアカウントへのスプレッドシートの「共有」だ。Googleのサービスアカウントは、明示的に共有されたスプレッドシートしか読み取ることができない。サービスアカウントが属するGoogleアカウントが見られるシートや、サービスアカウントがアクセスできるGoogle Driveフォルダ内のシートであっても、個々のスプレッドシートが直接共有されていなければアクセスはできない。そのため、連携したい各スプレッドシートを開き、「共有」ボタンをクリックして、先ほど控えたサービスアカウントのメールアドレスを貼り付ける必要がある。アクセス権限は「閲覧者」に設定し、「ユーザーに通知」のチェックボックスは必ずオフにする。サービスアカウントにはメールボックスがないため、通知を送っても意味がないからだ。この共有作業は、フォルダ単位ではなく、連携したい個々のスプレッドシートに対して繰り返す必要がある。

DatanikaでGoogle Sheetsとの接続を追加する。/connectionsページで「google_sheets」タイプを選択し、以下の情報を入力する。接続名は後で識別しやすいように「gsheets-marketing-budget」のような名前を付けると良い。スプレッドシートURLには、https://docs.google.com/spreadsheets/d/<ID>/editのような完全なURLを入力する。サービスアカウントJSONのフィールドには、ダウンロードしたJSONキーファイルの内容全体を貼り付ける。このデータは暗号化されて保存される。

入力後、「Test Connection」ボタンをクリックすると、「not tested」という結果が表示される。これは意図的な挙動であり、その理由を理解しておくことが重要だ。多くのツールでは、ここで緑色の成功マークが表示されるかもしれない。しかし、Datanikaの場合、サービスアカウントの認証情報が有効であること（JSON形式が正しく、キーが有効で、APIが有効であること）は確認できるものの、実際にスプレッドシートへの共有権限があるかどうかは、データがアップロードされる際に初めてチェックされるためだ。もしここで成功の表示が出たとしても、共有設定の不備による実際のアップロード失敗を予測できないため、誤解を招く可能性がある。逆に、接続自体は問題なくても共有設定がまだ完了していない場合に失敗と表示するのも適切ではない。そのため、Datanikaは「ここではテストされていない」という真実を伝えることを選択している。実際の検証は最初のデータ実行時に行われる。

接続を作成したら、次にデータのアップロードを設定する。/uploadsページに移動し、アップロード名を決定する。ここで入力した名前（例: sheets-daily-sync）は、後のスケジュール設定で正確に参照されるため、スペースを含める場合は注意が必要だ（例: Sheets Daily Syncはそのまま保存される）。ソースコネクションと宛先コネクションを選択し、以下の設定を行う。「Sheet Names」では、連携したい特定のタブ名をコンマ区切りで指定できる。空欄にした場合は、スプレッドシート内のすべてのタブがロードされる。「Batch size」はデフォルトで10000が設定されている。「Schema Contract」は特に重要だ。人間が編集するスプレッドシートの場合、カラムが追加されたり削除されたりする可能性があるため、取り込み時にスキーマの変更をどう扱うか（既存のスキーマを更新するか、エラーとして処理するか）をここで設定する。SQLデータベースをソースとする場合とは異なり、書き込みモードやソーススキーマなどの項目は表示されない。

設定が完了したら、アップロードの行にある「Run」ボタンをクリックして、最初の実行を行う。/runsページで実行状況を確認できる。ここで、もしスプレッドシートの共有ステップに不備があった場合、エラーとして表示される。実行が完了したら、/modelsページを開く。データウェアハウスには、アップロード名から派生したスキーマ（スペースはアンダースコアに変換され、全体が小文字になる）が作成され、その中にスプレッドシートの各タブがテーブルとしてロードされているはずだ。例えば、「sheetsdailysync」というアップロード名からは「sheetsdailysync」スキーマが、「Sheets Daily Sync」という名前からは「sheets_daily_sync」スキーマが生成される。Datanikaは内部管理用のテーブルも作成するが、/modelsには表示されない。

実行が成功（緑色のステータス）したとしても、それだけでデータが期待通りにロードされたとは限らないため、必ずスプレッドシートの元のデータと、データウェアハウスに取り込まれたテーブルの行数を比較し、目視で確認すること。空のタブや、共有設定を忘れたタブがあっても、実行自体は成功と表示されてしまう可能性があるからだ。

最後に、定期的なデータ連携のためにスケジュールを設定する。/schedulesページで「Target type」を「upload」、「Target name」に先ほど設定したアップロード名を正確に入力する。そして、Cron式を使って実行頻度を設定する。例えば、「0 * * * *」は1時間ごと、「0 3 * * *」は毎日午前3時に実行される。タイムゾーンはデフォルトでUTCとなる。スプレッドシートのパイプラインは、誰かがタブ名を変更するなどの理由で突然機能しなくなることがあるため、Settings → Notificationsで失敗時のアラートを設定しておくことが非常に重要だ。

まとめると、Google Sheetsからデータウェアハウスへのデータ連携は、サービスアカウントとスプレッドシートとの間で「共有」という形で「紹介」するステップが最も重要であり、かつ失敗しやすいポイントである。もしデータの取り込みが失敗し、認証情報自体には問題がない場合、この共有ステップに戻って確認することが解決への近道となる。