Workspace Studio に入れ子条件分岐が追加 — Drive 検索ステップ、Gmail の初回受信のみトリガー、Meet の招待者リスト出力も。2026-10-13 からロールアウト
Google が Workspace Studio の2026年10月フィーチャーリリースとして4件を発表した。(1) Nested Conditionals でフロー内に多層の分岐ロジックを持てる。(2) Search for a Doc は Drive 専用の検索ステップで、検索パラメータでドキュメントを探す。(3) Gmail Skip Replies はスレッドトリガーで後続の返信を無視し、最初の受信メールのときだけフローを走らせる。(4) Meet Calendar Outputs は Meet ステップが返す Calendar メタデータを増やし、招待者リストを含むようにする。会議後フォローアップメール下書きのテンプレート対応も入る。対象は Workspace Studio を使える全ての Google Workspace 顧客と Workspace Individual 契約者。ロールアウトは 2026-10-13 開始で Rapid Release と Scheduled Release の両方に段階展開され、可視化まで最大15日。機能は既定で有効、管理者制御は既存のドメイン / OU ポリシーに従う。
ニュース原文を読む ↗要約
Google が Workspace Updates Blog で、Workspace Studio の2026年10月フィーチャーリリースとして4件の追加を発表しました。
1つ目が Nested Conditionals（入れ子条件分岐）です。これが本体です。
なぜ本体かというと、従来は1段の条件分岐しか書けなかったからです。 「このメールが請求書なら」までは判定できる。「請求書で、かつ金額が10万円以上で、かつ取引先が新規なら」は書けない。 結果として、複雑な判定は複数のフローに割るか、そもそも自動化を諦めるかの二択でした。入れ子が入ると、1つのフローの中に多層の決定経路を持てます。
2つ目は Search for a Doc です。 Google Drive 専用の検索ステップで、検索パラメータでドキュメントファイルを探します。 従来、Drive のファイルを扱うステップは「このファイルをコピーする」「移動する」のように対象が特定済みであることが前提でした。探す工程がフローの中に入ります。
3つ目は Gmail Skip Replies です。 Gmail のスレッドトリガーで、後続の返信を無視し、最初の受信メールのときだけフローを走らせます。
これは地味に見えて、実務では効きます。 スレッドトリガーのフローは、返信が来るたびに再発火するのが既定の挙動でした。問い合わせメールをトリガーにチケットを作るフローなら、やり取りが5往復すれば5枚のチケットができます。 回避するには重複判定を自前で書くしかありませんでした。それが設定1つで消えます。
4つ目は Meet Calendar Outputs です。 Google Meet ステップが返す Calendar イベントのメタデータが増え、招待者リストを含むようになりました。 あわせて、会議後のフォローアップメール下書きのテンプレート対応も入ります。
提供条件と日程が明確です。 対象は Workspace Studio を使えるすべての Google Workspace 顧客と Workspace Individual 契約者。個別エディションの列挙はありません。ロールアウトは 2026-10-13 開始で、Rapid Release ドメインと Scheduled Release ドメインの両方に段階展開され、機能が見えるまで最大15日かかります。
機能は既定で有効で、Workspace Studio のフロービルダーに現れます。管理者側の制御は既存のドメイン / OU ポリシーに従い、前提となるプリミティブの管理設定は展開前に先行投入済みとされています。追加のセットアップ手順はありません。
何が変わったか
- Nested Conditionals — フロー内に多層の分岐ロジックを持てる（従来は1段のみ）
- Search for a Doc — Google Drive 専用の検索ステップ。検索パラメータでドキュメントファイルを探す
- Gmail Skip Replies — Gmail のスレッドトリガーで後続の返信を無視し、最初の受信メールのときだけフローを走らせる
- Meet Calendar Outputs — Google Meet ステップが返す Calendar イベントのメタデータを拡充。招待者リストを含む。会議後フォローアップメール下書きのテンプレート対応
- 対象: Workspace Studio を使えるすべての Google Workspace 顧客と Workspace Individual 契約者（個別エディションの列挙なし）
- ロールアウト: 2026-10-13 開始。Rapid Release / Scheduled Release の両方に段階展開。可視化まで最大15日
- 機能は既定で有効。フロービルダーに現れる
- 管理者制御: 既存のドメイン / OU ポリシーに従う。前提プリミティブの管理設定は先行投入済み。追加のセットアップ手順なし
業務インパクト（一般企業向け）
最初にやることは、Gmail スレッドトリガーの既存フローの棚卸しです。
理由は、Skip Replies が「今まで壊れていたものを直せる」設定だからです。 スレッドトリガーのフローは返信ごとに再発火します。気づかないまま重複処理を作っている可能性があります。 チケット起票、Slack 通知、スプレッドシートへの行追加——どれも重複すると気づきにくい種類の処理です。
確認の仕方は、フローの実行履歴を見ることです。 同じスレッドに対する実行が複数回記録されていれば、該当します。重複判定を自前で書いて回避していたフローも対象です。 Skip Replies に寄せれば、その判定ロジックを消せます。 消せるコードは消したほうが、将来の保守が楽になります。
次に、入れ子条件分岐を「使う方針」を先に決めてください。既定で有効なので、使うかどうかは利用者が決めます。
ここが一番注意すべき点です。 入れ子条件分岐は、フローの複雑さに上限を設けていた制約を外します。 制約があるうちは、複雑な判定は複数フローに分かれていました。分かれていたことで、1つあたりは読めました。
入れ子が入ると、1つのフローに全部書けます。書けるからといって、書くべきとは限りません。 3段、4段の入れ子になったフローは、作った本人以外には読めなくなります。 Workspace Studio を使うのは多くの場合エンジニアではなく、業務側の担当者です。その人が異動したあと、誰も触れないフローが業務の中核に残る——これが現実的なリスクです。
方針として決めるべきことは2つです。 (1) 入れ子の深さの上限（2段までにする、など）。(2) 入れ子を使ったフローには説明を残す（フロー名か説明欄に判定の意図を書く）。どちらも機能では強制できないので、運用ルールとして決めるしかありません。 展開が始まる 2026-10-13 より前に決めておくのが有効です。
管理者は、既存のドメイン / OU ポリシーで制御できる点を確認してください。 追加のセットアップ手順はなく、前提となる管理設定は先行投入済みとされています。つまり今の設定がそのまま新ステップにも適用されます。 Workspace Studio 自体を特定の OU で止めているなら、新機能もそこでは出ません。逆に、全体で許可しているなら新機能も全体で有効になります。
Search for a Doc は、フローの前提を変えます。 これまで「対象ファイルが特定済み」を前提にしていたフローが、探す工程を内側に持てます。 一方で検索結果が0件のとき、複数件のときの扱いを決める必要が出てきます。公式の発表はこの点に触れていません。実際に組むときに確認してください。 検索を入れたフローは、対象が1件に決まらない可能性を常に持ちます。
Meet Calendar Outputs の招待者リストは、取り扱いに注意が要ります。 会議の招待者リストは、社外の人の氏名とメールアドレスを含みます。 これをフローで取り回して外部へ送る経路を作ると、意図しない共有になります。 フォローアップメールの下書きテンプレートが入るので、宛先の自動設定を使うときは、社外参加者が含まれる場合の挙動を確認してください。
副業・個人活用視点
Workspace Studio は、業務自動化の受託で提案しやすい道具になってきています。
理由は、顧客側に追加コストがかからないことです。 Workspace を使っている顧客なら、Workspace Studio へのアクセスがあれば追加契約なしで使えます。 n8n や Zapier を提案すると「また新しいツールの契約か」という話になりますが、すでに持っているものの中で完結します。 稟議が通りやすい。
入れ子条件分岐が入ったことで、提案できる範囲が広がります。 これまで「Workspace Studio では1段の分岐しか書けないので、複雑な判定は別の仕組みが必要です」と言うしかなかった案件が、Workspace Studio で完結します。
ただし、ここに受託側のジレンマがあります。 顧客の中で完結する自動化を作ると、保守の継続契約につながりにくい。 だから「作って渡す」で終わらせるのではなく、「読める状態で渡す」ことに価値を置いてください。 入れ子が深いフローは本人以外読めません。判定の意図をドキュメントに残し、入れ子の深さを抑えて設計する——これが納品物の品質になります。
Gmail Skip Replies は、既存フローの点検サービスとして提案できます。 「スレッドトリガーのフローが返信ごとに再発火して、重複処理が起きていないか点検します」——顧客が気づいていない問題を見つける仕事です。実行履歴を見れば分かるので、調査コストが低く、見つかれば価値が明確です。
個人で使うなら、Gmail Skip Replies と Search for a Doc の組み合わせが実用的です。 「問い合わせメールが来たら（初回のみ）、Drive から該当する見積テンプレートを探して、下書きを作る」——この程度の自動化が、設定だけで組めます。 個人事業なら、問い合わせ対応の初動がこれで数分短くなります。
記事にするなら、「入れ子が入ったことの副作用」を書くと価値があります。 公式発表は機能追加として読まれます。「複雑さの上限が外れた」という側面は誰も書きません。 制約があったから保守できていたフローが、制約が外れたことで読めなくなる——これは機能追加のニュースを読んだだけでは気づけない部分です。 実際にフローを運用している人には刺さります。
ロールアウトの「最大15日」という表記も、記事にする価値があります。 2026-10-13 開始で最大15日。つまり 10-28 頃まで、環境によって機能が見える・見えないが分かれます。 「ドキュメントには書いてあるのに自分の環境に出ない」という問い合わせが発生する期間です。この種のタイムラグを先に説明しておくと、読者の無駄な調査を防げます。