Bubble × Google Drive：手動連携・データ取得実装ガイド

  • 投稿日
  • 著者 宮崎翼
  • カテゴリー コラム

本記事では、ユーザーがGoogleアカウントでログインし、Google Drive上の録画ファイル（MeetingデータURL）を自動的にBubbleデータベースへ取り込むシステムの実装手順を解説です。

定期実行までは、実装してないので要望があれば、またリクエスト下さい。

全体像

  1. Google Cloud Console設定: 認証用キーの取得
  2. Bubble DB設計: データの受け皿を作成
  3. Google認証（OAuth）: API Connectorの設定とログイン実装
  4. ロジック実装: バックエンドワークフローによる定期データ取得

1. Google Cloud Consoleでの事前準備

BubbleとGoogleを接続するために、Google側で「鍵」を作成します。

  1. プロジェクト作成: Google Cloud Consoleにアクセスし、新規プロジェクトを作成します。
  2. APIの有効化:
    • 「APIとサービス」 > 「ライブラリ」へ移動。
    • Google Drive API を検索し、有効化します。
  3. OAuth同意画面の設定:
    • User Typeは「外部（External）」を選択。
    • アプリ名やメールアドレスを入力。
    • スコープ（Scopes）の設定で、以下を追加します：
      • .../auth/drive.readonly （Driveの読み取り権限）
      • .../auth/userinfo.email （ユーザー特定用）
  1. 認証情報（Credentials）の作成:
    • 「認証情報」 > 「認証情報を作成」 > 「OAuth クライアント ID」を選択。
    • アプリケーションの種類：「ウェブ アプリケーション」。
    • 承認済みのリダイレクト URI に以下を追加（BubbleのAPI Connector用）：
      • https://[あなたのアプリ名].bubbleapps.io/api/1.1/oauth_redirect
    • 作成後、Client ID と Client Secret を控えておきます。

2. Bubble データベース設計

データを格納するためのテーブル構造をBubbleの「Data」タブで設定します。

A. User（ユーザー）タイプの改修

既存のUserタイプに、Google連携用の情報を追加します。

  • Email (既存): ユーザー識別用。
  • GoogleID (text): 新規追加。
    Google認証時に取得される一意のID（subフィールドなど）を保存し、確実な紐付けを行います。

B. Meeting（ミーティング）タイプの新規作成

会議録画データを保存するための新しいデータタイプを作成します。

  • CreatedBy (User): どのユーザーの会議データか（Userとリレーション）。
  • DriveFileUrl (text): Google Drive上の録画ファイルのURL（View Link）。
  • MeetingUrl (text): 元の会議URL（※Driveの説明欄などから取得可能な場合）。
  • RecordedAt (date): 会議の実施日（ファイルの作成日時）。

3. Google認証（OAuth）の実装

Bubbleの「API Connector」プラグインを使用して、Googleとの接続を確立します。

A. API Connectorの設定

  1. API Name: Google Drive Integration
  2. Authentication: OAuth2 User-Agent Flow
  3. Client ID / Client Secret: 手順1で取得した値を入力。
  4. Scope: https://www.googleapis.com/auth/drive.readonly https://www.googleapis.com/auth/userinfo.profile
  5. Token endpoint: https://oauth2.googleapis.com/token
  6. User profile endpoint: https://www.googleapis.com/oauth2/v1/userinfo

B. APIコールの作成（ファイル検索用）

データ取得用のAPIコールをこの段階で設定しておきます。

  • Name: Get Files
  • Method: GET
  • URL: https://www.googleapis.com/drive/v3/files
  • Parameters:
    • Key: q
    • Value: mimeType contains 'video/' and trashed = false （動画ファイルかつゴミ箱に入っていないもの）
    • このパラメータは動的に変更できるよう「Client-safe」のチェックを外しておくと便利です。

C. ログインワークフローの実装（フロントエンド）

アプリのログインページに「Googleで連携」ボタンを配置し、Workflowを設定します。

  1. Button Click Event: Account > Signup/login with a social network を選択。
  2. API Provider: 先ほど設定した Google Drive Integration を選択。
  3. データ保存処理:
    • 認証成功後、APIから返ってきたProfile情報（IDなど）を Current User の GoogleID フィールドに保存するアクションを追加します。


以下は、おそらくこれでできると思いますが、ですが未検証部分です。

4. 定期実行Workflowの構築（Backend Workflow）

注: この機能にはBubbleの有料プラン（Backend Workflowsの利用）が必要です。

サーバー側で全ユーザーを巡回し、新しいファイルをチェックするロジックを組みます。

A. ユーザーごとの処理（サブワークフロー）

まず、「1人のユーザーに対して何をするか」という処理を作成します。

  • Workflow Name: Sync_User_Drive
  • Parameter: TargetUser (Type: User)

アクション設定:

  1. API Call (Get Files):
    • 設定した Get Files APIを呼び出します。
    • 認証コンテキスト: (User to run as) に TargetUser を指定します（重要）。これにより、そのユーザーのGoogle Driveにアクセスします。
    • 検索クエリ (q): 「作成日が前回の同期以降」などの条件を追加すると効率的です（例: createdTime > '2023-01-01T00:00:00'）。
  2. Create a new thing (Meeting):
    • APIのレスポンス（Files list）に対して、「Schedule API Workflow on a list」を使用するか、リストの各アイテムに対してデータを保存します。
    • DriveFileUrl: API結果の webViewLink
    • RecordedAt: API結果の createdTime
    • CreatedBy: TargetUser
    • ※重複保存を防ぐため、「Search for Meeting: count > 0」の条件分岐（Only when）を設定し、すでに同じURLが存在する場合は作成しないようにします。

B. メインの定期実行ワークフロー

全ユーザーを対象にループ処理を開始する親ワークフローです。

  • Workflow Name: Schedule_Drive_Sync

アクション設定:

  1. Search for Users:
    • GoogleID が空ではない（連携済みの）ユーザーを検索します。
  2. Schedule API Workflow on a list:
    • Type of things: User
    • List to run on: 手順1の検索結果 (Search for Users)
    • API Workflow: Sync_User_Drive (先ほど作成したサブワークフロー)
    • Interval: サーバー負荷を考慮し、5〜10秒程度の間隔を空けます。

C. スケジューリング（定期実行の設定）

このシステムを自動で動かし続ける設定を行います。

  1. 初期起動:
    • Bubbleのエディタの「App Data」タブ、または管理者用ページにボタンを作成し、一度だけ Schedule_Drive_Sync を実行します。
  2. 再帰的実行（ループ）:
    • Schedule_Drive_Sync ワークフローの最後に、自分自身（Schedule_Drive_Sync）を再度スケジュールするアクションを追加します。
    • Scheduled date: Current date/time +(hours): 1 （1時間ごとに実行する場合）

まとめ：実装のポイント

  • 認証情報の管理: GoogleIDを確実にUserデータに保持させることで、システムが「誰のDriveを見に行くべきか」を判断できます。
  • APIの権限: drive.readonly は読み取り専用のため、誤ってユーザーのファイルを削除するリスクがなく安全です。
  • バックエンド処理: ユーザー数が増えると処理が重くなるため、フロントエンドではなく必ずBackend Workflow（Recursive Workflow）で実装してください。
API Connector Backend Workflow Bubble Google Cloud Platform Google Drive API NoCode OAuth

この記事を書いた人

宮崎翼

愛媛県出身・東京都在住。
国立工業高専（新居浜工業高等専門学校）卒業後、外資系ソフトウェア企業などで法人営業・IT導入支援に従事し、BtoB領域で多様な新規開拓やエンタープライズのDX推進を経験。

現在は「AppTalentHub」の理念、ノーコード／ローコードを活用したアプリ開発の標準化と、エンジニアのスキルの可視化による適正評価を実現するためのプロジェクトやコミュニティ運営に取り組んでいます。
https://tsubasa.tech/about

記事一覧