Webhookはなぜ一時的に禁止になったのか
これは私の推測ですが、企業向けサービスとして、外部連携の利便性に見合う管理機能を整備する必要があったのではないかと考えています。Webhookは、業務データを外部サービスへ送信できる機能です。仮に管理者が利用可否や送信先を十分に制御できない状態で自由に使えてしまえば、意図しない情報流出につながる懸念があります。
このようなリスクを踏まえると、一時的な制限は、企業が安心して利用できる管理体制を整えるための措置だった可能性があります。ただし、当時の管理機能の不足やセキュリティ上の問題が、制限の直接的な原因だったと確認できているわけではありません。
Webhookを使うと何ができるのか
Workspace StudioのWebhookは、フローの途中から指定したURLへHTTPリクエストを送り、外部サービスと情報をやり取りするためのステップです。標準のステップでは直接扱えない外部アプリや、社内向けのツールとの接続に利用できます。例えば、Slackのチャンネルへのメッセージ投稿も一つのユースケースです(将来的にはSlack専用のステップを利用できるようになるかもしれません)。

ここで押さえておきたいのは、今回説明する機能が、フローから外部へアクセスするためのものである点です。外部からの通知を受けてフローを開始するカスタムスターターとしての機能は備えていません。
Workspace Studioのフローは、開始条件、処理を実行するステップ、ステップ間で情報を渡す変数から構成されます。メールの受信をきっかけに処理を始め、Geminiで内容を整理し、その結果を後続の処理に渡すことができます。Webhookは、この処理の流れに外部との接続先を追加するものです。
利用のための前提条件と注意点
利用可能なエディション
Webhook機能が利用可能なGoogle Workspaceエディションは、以下の通りです。
- Business Starter
- Business Standard
- Business Plus
- Enterprise Standard
- Enterprise Plus
接続先URLを限定する機能は一部エディションのみ対応
接続先を限定するURL許可リストが利用できるGoogle Workspaceエディションは以下の通りです。
- Business Plus
- Enterprise Standard
- Enterprise Plus
Webhookを使えるとしても、エディションによっては、接続先まで制限できない可能性があります。
Google Workspace管理者による有効化も必要
Webhookを利用するには、Workspace Studioを利用できる環境に加え、管理者によるWebhookの有効化が必要です。初期状態ではオフになっているため、利用者がフローの編集画面を開くだけでは使い始められません。
フローにWebhookを設定する方法(利用者目線)
今回は、「毎朝7時に天気予報を取得し、Geminiで短い文章にして自分宛てに通知するフロー」を作成してみます。フローを図式化すると、以下のようになります。業務として実用的なフローではないですが、今回はWebhookの理解を目的としているため、あえてシンプルなフローにしています。

① フローの作成を開始する
Workspace Studioにアクセスし、左メニューの「+」から「フロー」を選択します。

② フローの開始条件を決める
「開始条件」に「設定スケジュールで実行」を選択し、設定画面で「開始日時」「繰り返し」「終了日時」を指定します。「繰り返し」には頻度を設定しますが、天気情報は毎日欲しいものなので「毎日」を指定し、「終了時間」には「まったくなし」を指定します。

③ Webhookステップに送信先と処理を設定する
開始条件の設定が完了したら、フローのステップ追加から、「Webhookの送信」を選択します。

基本となる設定項目は以下の3つです。
|
設定項目
|
設定する内容
|
|
WebhookまたはAPIのURL
|
接続先の完全なURL
|
|
メソッド
|
接続先に対して実行する処理の種類
|
|
ペイロード
|
リクエストの本文として渡す内容
|
具体的な設定値を入力していきます。
URLは固定値で指定します。これはWebhook機能の意図的な仕様だと思いますが、外部データの漏洩リスクを防ぐために変数は使用できないようになっています。
今回は天気情報の取得のためにOpen-MetroのAPIを利用します。このAPIはURLにクエリを指定して天気情報を取得することができます。指定されたパラメータは何を意味しているかですが、端的に言うと「東京の天気」を取得するためのパラメーターです。
https://api.open-meteo.com/v1/forecast?latitude=35.68&longitude=139.76&daily=temperature_2m_max,temperature_2m_min,precipitation_probability_max&timezone=Asia%2FTokyo&forecast_days=1
メソッドはPOSTが初期値で、ほかにGET、PUT、PATCH、DELETEを選択できます。GETではペイロードが無視されるため、すべてのメソッドで同じ設定が使えるわけではありません。今回はGETを指定します。
前述した通り、今回はGETを指定するため、ペイロードは空欄になります。

④ Geminiステップで天気JSONを文章化
次のステップとして、「Geminiに相談」を選択します。

設定画面を開くと、デフォルトで「Webhookのレスポンス」が変数としてセットされています。追加で、JSONを要約するためのプロンプトを追記します。

⑤ 天気情報をチャットで通知する
次のステップでは「Chatで通知する」を選択します。通知メッセージには、前のステップでGeminiが要約した内容を指定します。

⑥ テスト実行で結果を確認する
フローをオンにする前に、テスト実行で動作を確認します。フローの下部にある「テスト実行」をクリックし、テスト実行画面で「起動」ボタンを押下します。

実行後はアクティビティで送信内容と応答を確認します。

失敗した場合は、表示されるエラーコードと接続先からの応答を基に設定を見直し、準備ができたらフローをオンにします。
管理コンソールでの制御方法(管理者目線)
組織部門ごとに利用を許可する
Google Workspace管理者は、Webhook機能の利用者を組織部門ごとに制御することができます。
Google Workspaceの管理コンソールにログインし、[アプリ] > [Google Workspace] > [Workspace Studio の設定] > [Webhook の設定]から、組織部門ごとにオン・オフを設定します。

管理者は最初から全社員に開放する必要はありません。例えば検証を担当する部門から有効化し、接続先と送信内容を確認したうえで対象を広げる、という進め方も可能です。利用の可否を決める段階で、誰が検証し、誰が運用するのかも整理しておくとよいと思います。
URL許可リストで接続先を限定する
前述した通り、一部のエディションでは、Webhookの接続先を許可リストで制限できます。ここは設定場所に注意が必要です。Workspace Studioの設定ではなく、[アプリ] > [Google Workspace] > [ドライブとドキュメント] > [機能とアプリケーション]から、URLからのインポートと取得に関する設定を開きます。

許可するURLのみからのインポートと取得を認める設定を選び、接続先のURLやドメインを登録して保存します。Webhookでは、ドライブ、ドキュメント、スプレッドシート、Apps Scriptと共通のURL許可リストが使われます。
共通設定である以上、Webhookのためだけに変更したつもりでも、既存のApps Scriptやスプレッドシートの処理に影響する可能性があります。制限を有効にする前に既存の接続先を確認し、業務上必要なURLを登録することが重要です。
また、この許可リストは、登録したURLとその配下のパスに一致する仕組みです。ドメイン全体を登録するか、必要なパスまで限定するかで許可範囲が変わります。必要な接続先が決まっているなら、登録範囲を具体的に検討してください。
実行前のユーザー承認を設定する
管理者は、Webhookステップに対してユーザー承認を設定することも可能です。管理コンソールにログイン後、[アプリ] > [Google Workspace] > [Workspace Studio] > [承認]に遷移し、「カスタムステップ」から、承認を設定できます。

承認が必要なステップでは、確認が済むまでフローは先に進みません。これは管理者がWebhook機能を有効にする操作とは別の仕組みです。利用を許可していても、実行時の確認が必要になる場合があります。
そのため、承認を必要とする運用では、フローの処理だけでなく、利用者が確認するタイミングまで含めて設計する必要があります。完全自動で進めたい処理なのか、人が内容を確認してから送る処理なのかを、先に決めておきましょう。
管理者は利便性だけではなくリスクも考える必要がある
Webhookは非常に便利な機能である一方、管理者は注意が必要です。Webhookに変数を渡すと、メール本文やチャットの内容など、Google Workspace上の情報が外部サービスに共有される可能性があるからです。便利になったからこそ、接続先だけでなく、送る情報にも目を向ける必要があります。
私は、Webhookを導入する際には、利用する部門、許可する接続先、送信するデータ、承認の要否を先に整理するのがよいと考えています。そのうえで小さなフローから検証し、ログを確認できる状態で運用を始める。Workspace Studioの外部連携を企業の業務として定着させるには、こうした管理面の設計も含めて進めることが重要です。