現場の担当者から、Workspace Studioでカスタムの手順を使いたいので管理者設定をオンにしてほしい、と頼まれた。情報システムの担当者に、そういう依頼が届き始める時期です。Google Workspaceのノーコード自動化であるWorkspace Studioに、2026年9月17日、4つの機能が発表されました。カスタムの開始条件、カスタムの手順、第三者サービスとの連携、そしてWebhookです。

言い換えると、Workspace Studioのフローが、Apps Scriptで書いた独自の処理を呼び、SalesforceやSlackと行き来し、任意のURLにHTTPリクエストを送れるようになりました。4つともデフォルトでオフです。管理者がオンにしない限り、誰も使えません。だから依頼が来ます。

この記事は、オンにする前に管理者が知っておくことを書きます。4つの機能の中身、設定が3つに分かれていること、WebhookのURL許可リストの実体、承認の3つの選択肢の今の挙動、ログの見方、そして自社で決める順番です。読者は、Google Workspaceの管理者と、現場から依頼を受けて判断を求められる情報システムの担当者です。確認日は2026年10月13日で、公式の案内とヘルプセンターの記述をもとにしています。管理コンソールの実際の画面は当社の環境では撮影できなかったので、設定の名前はヘルプの英語表記を日本語に当てています。

結論を先に書きます。

  1. コントロールする場所は3つあります。 機能ごとのオン・オフ、機能の種類ごとの承認の要否、WebhookのURL許可リストです。3つは管理コンソールの別々の場所にあります。機能をオンにするなら、誰が使えるかに加えて、承認と送り先の制限をそれぞれ決めます
  2. URL許可リストは、Studio専用の設定ではありません。 「Drive and Docs」の「URLからのインポートと取得」の許可リストを、Drive、Docs、Sheets、Apps Scriptと共用します。使えるのはBusiness Plus、Enterprise StandardとPlus、Education StandardとPlusの5つのエディションで、それ以外のエディションでは、この設定による送り先の制限はできません
  3. 承認の「ユーザーに任せる」は、今は「常に」と同じ動きです。 ヘルプには、将来の変更でユーザーが手動承認と自動承認を選べるようになる、と書かれています。今は3つの選択肢のうち、実質2つしかありません

9月17日に何が増えたか

Workspace Studioは、Google Workspaceのアプリの間で、決めた条件で自動的に動くフローを、文章の指示から作る機能です。9月に公開した記事では、Geminiの開放を4段階に分けた中で、Studioをレベル3の「エージェント解禁」に置きました。10月6日の記事では、同じ9月に出たGeminiの外部ツール接続と並べて、Studioの連携がデフォルトでオフであることを書きました。この記事は、その続きで、Studio側の管理者設定だけを扱います。

9月17日のWorkspace Updatesで加わったのは、次の4つです。

機能 何ができるか 誰が作るか
カスタムの開始条件（custom starters） 他のアプリで起きた出来事を、フローの開始の合図にする。リアルタイムの起動条件を自分で作って公開できる Apps Scriptを書ける人
カスタムの手順（custom steps） Apps Scriptの関数などの独自の処理を、フローの1手順として実行する Apps Scriptを書ける人
第三者サービスとの連携（ベータ） Asana、Confluence、HubSpot、Jira、Mailchimp、QuickBooks、Salesforce、Slackとデータをやり取りする フローを作る人が接続する
Webhook 外部のエンドポイントにHTTPリクエストを送り、相手側の処理を起こす フローを作る人がURLを書く

発表には、4つともGoogle Workspaceのエンタープライズ向けのセキュリティ管理の対象で、管理者が組織全体のエージェント機能を管理できる、と書かれています。届く時期は、管理コンソールの設定が9月17日から、利用者の機能が迅速リリースのドメインで9月21日から、計画的リリースのドメインで9月30日から最大15日かけてです。対象はBusiness Starter、Standard、Plus、Enterprise StandardとPlus、Education Fundamentals、Standard、Plus、教育向けの2つのアドオン、AI Expanded Accessです。

4つを管理者の目で見ると、2つに分かれます。前の2つは、誰かがApps Scriptで書いた処理を、フローの部品として配る仕組みです。後ろの2つは、フローの中からデータを外部のサービスやURLに出す仕組みです。作り方が違うので、分けて考えます。ただし、カスタム手順も、中身によっては外部へデータを送ります。部品の提供元、求められるアクセス権限、通信先は、カスタム手順でも確かめます。

カスタムの開始条件と手順は、どう作られてどう届くか

カスタムの開始条件と手順は、Apps Scriptで作ります。Googleの開発者向けの演習資料には、作り方が一通り書かれています。読んだ範囲で、管理者が知っておくべき流れだけを抜き出します。

カスタムの開始条件がApps Scriptで作られ、テスト用のデプロイで試され、公開されてフローの部品になり、利用者のフローで動くまでの流れ。作る人、管理者、利用者の3つのレーンで示す

作る人の作業。 Apps Scriptのプロジェクトを作り、マニフェストであるappsscript.jsonに、開始条件か手順の定義を書きます。開始条件は、出力する項目と、設定時と管理時に呼ばれる関数を持ちます。手順は、入力と出力の項目と、設定時と実行時に呼ばれる関数を持ちます。開始条件を作るには、Workspace Studio APIを呼ぶ権限が要り、Apps Scriptのプロジェクトをデフォルトの隠れたCloudプロジェクトから標準のCloudプロジェクトに切り替えて、APIを有効にする必要があります。演習資料には、切り替えないとPERMISSION_DENIEDになる、と書かれています。

試す段階。 作った開始条件と手順は、公開する前にテスト用のデプロイから試します。管理者ヘルプには、Apps Scriptを共有された人なら誰でもテスト版を入れられる、と書かれています。ここが1つ目の管理点です。管理者の設定に「未公開（テスト）のカスタム手順を許可する」というチェックがあり、これを外しておくと、テスト版は使えません。演習資料のほうには、この設定が管理者側でオンになっている前提で手順が書かれています。

公開する段階。 公開した開始条件と手順は、Google Workspace Marketplaceを通して配られ、他の公開済みアドオンと同じように管理します。管理者ヘルプは、Marketplaceアプリを組織に入れる手順と、ユーザーがMarketplaceアプリを入れられるかを決める設定のページを参照先に挙げています。つまり、公開済みの部品は、Marketplaceの許可リストの考え方で制限できます。ただし、それが有効なのは、Marketplaceの設定で、ユーザーが入れられるアプリを許可リストのものに限定している場合です。任意のアプリを許す設定のままなら、公開済みの部品はどれでも入ります。管理者が入れるアプリや、社内向けのアプリの例外も、同じ設定で確かめます。

利用者の作業。 公開された開始条件と手順は、フローを作る画面で部品として選べます。利用者はApps Scriptを読みません。誰かが書いた処理が、名前のついた部品として並ぶだけです。

この流れで管理者が決めるのは2点です。テスト版を社内で回してよいか。公開済みの部品のうち、どれを許すか。前者は「未公開のカスタム手順を許可する」のチェック、後者はMarketplaceの許可リストと、その許可リストを効かせる設定で決めます。

3つの設定は、別々の場所にある

ここからが本題です。コントロールする設定は3つあり、管理コンソールの別々の場所にあります。

Workspace Studioをコントロールする3つの設定。機能のオン・オフ、承認の要否、URL許可リストについて、管理コンソールの場所、デフォルト、対応エディションを並べた表

設定 場所 デフォルト 何をコントロールするか
機能のオン・オフ アプリ、Google Workspace、Workspace Studio。「カスタム手順の設定」「連携の設定」「Webhookの設定」 4機能ともオフ その機能をフローで使えるか。組織部門ごとに変えられる（カスタム手順は構成グループも）
承認の要否 アプリ、Google Workspace、Workspace Studio、承認 機密性の高い手順は「ユーザーに任せる」。カスタム手順と連携は「しない」 手順が動く前に、人が確認するか。機能の種類ごとに別の設定
WebhookのURL許可リスト アプリ、Google Workspace、Drive and Docs、機能とアプリケーション、URLからのインポートと取得 制限なし Webhookの送り先。Drive、Docs、Sheets、Apps Scriptと共用。5つのエディションのみ

機能のオン・オフ。 Service Settingsの管理者権限が要ります。Workspace Studioの設定の中に、カスタム手順、連携、Webhookの3つの設定が並びます。組織部門を選んで、オンかオフを選び、保存します。組織部門ごとに上書きし、継承に戻すこともできます。適用の単位は機能ごとにヘルプを確かめてください。カスタム手順のヘルプには組織部門と構成グループの両方が書かれていますが、Webhookのヘルプの手順に書かれているのは組織部門です。カスタム手順の設定には、ヘルプによると選択肢は2つで、オフ（デフォルト）と、オンです。オンのときに「未公開（テスト）のカスタム手順を許可する」のチェックが加わります。オフに戻すと、カスタム手順を使っていた既存のフローは動かなくなります。この点は、オンにしてからオフに戻すときに現場へ知らせる必要があります。

なお、カスタム手順の設定ページの題名は「カスタムの開始条件と手順」で、ページの中では開始条件と手順が一緒に説明されています。開始条件だけの別の設定があるとは、ヘルプには書かれていません。開始条件も同じ設定で縛られると読めますが、ヘルプが明示していないので、オンにする前に自社の管理コンソールで設定の名前を確かめてください。

承認の要否。 同じWorkspace Studioの設定の中の「承認」です。設定は3つに分かれます。社外にデータを出す手順（機密性の高い手順）、カスタム手順、第三者サービスとの連携の手順です。それぞれに「常に」「ユーザーに任せる」「しない」の3つの選択肢があります。Webhookはこの中の機密性の高い手順の設定に従います。9月17日の発表にそう書かれています。

WebhookのURL許可リスト。 Workspace Studioの設定の中にはありません。「Drive and Docs」の「機能とアプリケーション」の「URLからのインポートと取得」にあります。ここで、指定したURLからだけインポートと取得を許可する選択肢を選び、URLかドメインを入れて保存します。次の節で詳しく書きます。

3つの場所が離れているので、機能をオンにするときは、3か所をまとめて見ます。オフのままなら、その機能は使えず、他の2つは関係ありません。オンにするなら、誰が使えるかに加えて、承認と送り先の制限を決めます。Webhookをオンにして、許可リストを制限なしのままにし、承認を「しない」にすると、フローは有効なURLならどこへでもデータを送り、人の確認は入りません。逆に、Webhookをオンにして、許可リストに自社のサーバーだけを入れ、承認を「常に」にすると、送り先は限定され、送るたびに人が確認します。どちらにするかは、管理者が3か所を見て決めることです。

URL許可リストの実体は、Driveの設定

Webhookをコントロールする本命の設定が、URL許可リストです。管理者ヘルプ「Send a webhookを許可またはブロックする」には、次のことが書かれています。

共用である。 許可リストは、Google Drive、Docs、Sheets、Apps Scriptと共有されます。Sheetsで外部のURLからデータを取り込む機能や、Apps ScriptのUrlFetchで外部に出る先を制限しているのと同じ一覧に、Webhookの送り先も従います。既にこの設定を使っている会社では、そこに入っているURLがそのままWebhookの送り先として許可されます。使っていない会社では、Webhookのために設定すると、SheetsやApps Scriptの外部取得も同じ一覧で制限されます。片方だけを制限する設定ではありません。

既存の業務を先に確かめる。 共用なので、Webhookの送り先だけを登録して制限を有効にすると、SheetsやApps Scriptが既に使っている外部のURLが止まります。共有設定のヘルプの手順は、現在の利用先を調べ、必要なURLを登録してから、制限を有効にする順です。Driveのログで既存の接続先を確認し、必要なURLを含めてから、許可リスト方式に切り替えます。

状態は3つある。 制限なし、許可リスト方式でURLの登録あり、許可リスト方式で登録なし、の3つです。制限なしの状態でWebhookをオンにすると、有効なURLならどこへでも送れます。許可リスト方式で登録ありなら、登録したURLとドメインにだけ送れます。許可リスト方式で登録なしのとき、Webhookがどう動くかは、ヘルプに明記がありません。当社は読み取りで断定しません。オンにする前に、テスト用の送り先で実際に確かめてください。

エディションで有無が分かれる。 許可リストが使えるのは、Business Plus、Enterprise StandardとPlus、Education StandardとPlusの5つです。Business StarterとStandardでは使えません。ヘルプには、許可リストに対応しないエディションでは、Webhookをオンにすると有効なURLならどこへでも接続できる、と書かれています。Business StarterやStandardの会社がWebhookをオンにするなら、この設定による送り先の制限はできません。できるのは、利用者の都度の確認と、ログによる事後の確認です。承認するのはフローを実行する利用者本人なので、会社側で送り先を技術的に禁止する機能の代わりにはなりません。その運用で足りるかを、オンにする前に判断します。

HTTPSを使う。 ヘルプは、暗号化されていないHTTPは安全でない、HTTPSで送る、と書いています。フローの送信先にはHTTPSのURLを指定します。ただし、共有設定の仕様では、同じURLのHTTPとHTTPSは同じものとして扱われるので、許可リストにHTTPSの表記で登録しても、HTTPでの送信を禁止できるわけではありません。

ここまでを、自社がどのエディションかと、Webhookを使うかで整理すると、次の段階になります。

Workspace Studioの外部連携を開放する4段階。全部オフ、公開済みのカスタム手順だけ、Webhookを許可リストと承認つきで、テスト版と連携まで、の順に広がる

  • 段階0。全部オフ。 発表上のデフォルトのままです。4つの機能は使えず、承認と許可リストの設定は関係ありません。管理者が何もしなければこの状態です
  • 段階1。公開済みのカスタム手順だけオン。 カスタム手順の設定をオンにし、「未公開（テスト）のカスタム手順を許可する」は外したまま。使える部品は、Marketplaceで許可した公開済みのものだけです。社内で誰かがApps Scriptを書いて配りたいなら、公開の手順を踏んでもらいます
  • 段階2。Webhookを、許可リストと承認つきでオン。 許可リストが使えるエディションなら、既存の接続先を確かめたうえで、自社のサーバーや、契約している外部サービスの受け口だけを入れます。承認は「常に」にします。使えないエディションなら、送り先の技術的な制限はできないので、利用者の都度の確認とログによる事後の確認で運用できるかを判断してからオンにします
  • 段階3。テスト版と第三者サービスとの連携まで。 「未公開のカスタム手順を許可する」を入れ、連携の設定をオンにします。社内でApps Scriptを書いて試す人がいて、SalesforceやSlackとの行き来が業務で決まっていて、承認の運用が回っている会社の段階です

段階2と3の順番は、会社によって入れ替わります。Apps Scriptを書く人が社内にいて、外部へ送る用事がない会社は、段階1から3のテスト版だけを足す形になります。

承認の3つの選択肢と、今の挙動

承認の設定は、オンにした機能に人の確認を挟むための道具です。選択肢は3つです。

  • 常に。 利用者は、その手順が動くたびに手動で承認します
  • ユーザーに任せる。 利用者が、1回だけ承認する、ずっと承認する、拒否する、のどれかを選べます
  • しない。 承認は要らず、自動で承認されます

デフォルトは、機密性の高い手順が「ユーザーに任せる」、カスタム手順と連携の手順が「しない」です。後ろの2つが「しない」なのは、機能そのものがデフォルトでオフだからで、オンにした瞬間に承認なしで動き始めます。機能をオンにするときは、承認の設定を同じ日に見直します。

注意が要るのは、「ユーザーに任せる」の今の挙動です。ヘルプには、現在は「常に」と同じ動きをし、利用者は社外にデータを出す手順をすべて手動で承認する、と書かれています。将来の変更で、利用者が手動承認と自動承認を選べるようになる、とも書かれています。つまり、今「ユーザーに任せる」を選んでも「常に」と同じで、将来、Googleが変更した時点で、利用者が自動承認を選べるようになります。その変更がいつかは書かれていません。

ここから言えることは1つです。「常に」でよいなら「常に」を選ぶ。 「ユーザーに任せる」のままにしておくと、将来の変更のあとに、利用者がずっと承認する、を選んだフローは人の確認なしで動きます。それでよいと決めているなら構いませんが、決めていないなら、挙動が変わらない「常に」を選んでおくほうが、管理者の意図と設定が一致します。

承認を「常に」にすると、Webhookを使うフローは、送るたびに利用者の確認で止まります。自動化なのに手動で確認するのか、と現場は言うでしょう。当社の考えは、最初はそれでよい、です。確認のたびに、送り先と送る内容が利用者の画面に出ます。数週間それを見て、送り先が固定で、内容に顧客の情報が混ざらないと分かってから、承認の設定を見直します。承認の設定は機能の種類ごとなので、変えるときは、同じ設定が適用される他のフローへの影響も確かめます。見直す材料は、次の節のログです。

ログで、送り先と実行の状況を見る

Webhookの実行は、Workspace Studioのログイベントとして記録されます。場所は、管理コンソールの「レポート」「監査と調査」「Workspace Studioのログイベント」です。監査と調査のツールの権限が要ります。手順名でフィルタでき、「含む」で webhook、または「一致」で Send a webhook を指定すると、Webhookの手順だけが並びます。

送り先のURLは、「Webhookリクエストの URL」というパラメータに入ります。この項目は機密性の高い内容として扱われ、見るには特権管理者であるか、「機密性の高いコンテンツを表示」の設定が要ります。つまり、ログを見られる人と、送り先のURLまで見られる人は別に設定できます。

このログで管理者が見られるのは、Webhookの実行の要求と、その送り先です。送った内容そのものは、このログには出ません。送った内容と相手の応答は、フローの利用者側の実行履歴で確かめます。管理者が月に1回見ることは2つです。Webhookの手順を含むフローが、許可リストに入れた送り先だけに送っているか。実行の回数が、業務の想定と合っているか。回数を数えるときは、どのイベントを1回と数えるかを先に決めます。1回の実行で複数のイベントが記録されることがあるからです。

誰が作るか、どこへ送るかで決める

ここまでの設定を、自社の状況に当てはめます。2つの軸で考えます。横軸は、カスタムの開始条件と手順を作る人、つまりApps Scriptを書く人が社内にいるか。縦軸は、フローからデータを外部のサービスやURLに送る用事があるか。送り先は社外のサービスに限りません。自社で運用している内部のツールへの接続も、Webhookの用事に入ります。

Workspace Studioの4機能をどこまで開くかを決める2軸の図。横軸はApps Scriptを書く人が社内にいるか、縦軸はデータを社外に送る用事があるか

  • 書く人がいて、社外へ送る用事がある。 4機能を使う候補です。段階1から始めて、段階2、段階3の順に開きます。許可リストが使えるエディションかを先に確かめ、使えないならエディションの変更も検討の対象です
  • 書く人がいて、社外へ送る用事はない。 カスタム手順だけをオンにします。Webhookと連携はオフのまま。テスト版の許可は、書く人が決まっていて、その人が公開の手順を踏めるなら外したままでよく、試行錯誤の段階なら入れます
  • 書く人はいないが、社外へ送る用事がある。 WebhookをオンにしてもURLを書くのはフローを作る人で、Apps Scriptは要りません。許可リストと承認「常に」で制限して、段階2だけを開きます。カスタム手順はオフのまま
  • 書く人もいないし、社外へ送る用事もない。 今は段階0のままです。ただし、カスタム手順は社内で書く人がいなくても、第三者が公開した部品を使えます。現場から公開済みの部品を使いたいという依頼が来たら、段階1の候補として、上の3つのどれに移るかを考えます

この図は、情報システムの担当者が1人で埋められます。Apps Scriptを書ける人の有無は社内で分かり、外部へ送る用事の有無は、現場の依頼の中身を聞けば分かります。埋めてから、該当する段階の設定を入れます。

自社で決める順番

設定を入れる順番を、5つに分けます。

1. 今の状態を確かめる。 Workspace Studioの設定で、カスタム手順、連携、Webhookがオフのままかを見ます。発表上はデフォルトでオフですが、初期値と自社の環境の現在の値は別なので、組織部門ごとの上書きと継承まで見ます。あわせて、「Drive and Docs」の「URLからのインポートと取得」が、今どの選択肢になっているかを見ます。既に許可リスト方式になっている会社は、その一覧が、Webhookの送り先の候補になります。制限なしの会社は、SheetsやApps Scriptが今どこに接続しているかを、Driveのログで先に調べます。

2. エディションを確かめる。 自社のエディションで、Webhookの許可リストが使えるかを確かめます。Business Plus、Enterprise StandardとPlus、Education StandardとPlusなら使えます。それ以外なら、Webhookの送り先を制限する手段は承認だけです。

3. 上の図に自社を置く。 Apps Scriptを書く人の有無と、社外へ送る用事の有無で、開く段階を決めます。決めた段階と、その理由を1行で書いて残します。

4. 承認を先に入れてから、機能をオンにする。 順番が大事です。カスタム手順と第三者サービスとの連携は、承認のデフォルトが「しない」なので、先に承認の設定を「常に」にしてから、機能のオン・オフを変えます。逆の順にすると、機能がオンになってから承認を入れるまでの間、承認なしで動きます。Webhookは、機密性の高い手順のデフォルトが「ユーザーに任せる」で、今は「常に」と同じ動きですが、自社で既に変えていることがあるので、現在の承認の設定を確かめてからオンにします。Webhookの順番は、既存の接続先の確認、許可リストの登録、承認の確認、最後にWebhookの設定をオン、です。

5. 1か月後にログを見る。 「Workspace Studioのログイベント」で、Webhookの送り先と回数、承認の回数を見ます。想定どおりなら、承認の扱いを個別に見直します。想定と違うなら、機能をオフに戻します。カスタム手順をオフに戻すと既存のフローが止まるので、戻す前に現場へ知らせます。

注意点

設定の名前は、自社の管理コンソールで確かめてください。 この記事の設定の名前は、ヘルプの英語表記を当社が日本語に当てたものです。日本語の管理コンソールでの表記は、一致しないことがあります。場所の階層は変わらないので、階層をたどって見つけてください。

カスタムの開始条件と手順は、限定プレビューです。 管理者ヘルプの両方に、限定プレビューであると書かれています。Webhookのヘルプも同じです。提供段階が変わると、設定の選択肢やデフォルトが変わることがあります。この記事の内容は2026年10月13日時点です。

Webhookの送り先に変数は使えません。 10月6日の記事で書いたとおり、Webhookのヘルプには、送信先のURLは固定で、セキュリティ上の理由から変数を使えない、と書かれています。フローの中で送り先を動的に切り替える使い方は、設計の時点で成り立ちません。

連携やアドオンの手順に変数を足すと、Googleアカウントのデータが外に出ます。 GmailやChatのメッセージの内容、カレンダーの予定を変数として手順に渡せば、それが第三者のサービスに送られます。これはWebhookに限らず、連携の手順でも同じです。承認の画面で、送る内容を見る意味はここにあります。

Marketplaceの設定と、Context-Aware Accessが絡みます。 公開済みのカスタム手順はMarketplaceアプリとして管理されるので、ユーザーがMarketplaceアプリを入れられるかの設定が影響します。また、DriveやGmailなどのサービスごとの手順のヘルプには、利用者がそれらの手順を使えないときは、該当するStudio用のアプリへのアクセス設定と、Context-Aware Accessのレベルを確かめる、と書かれています。対象はそのヘルプに書かれた特定のアプリと条件で、カスタム手順全般に一律に当てはまる話ではありません。オンにしたのに現場で使えない、というときは、この2つを見ます。

データ保護のルールで、内容に応じて止められます。 承認のヘルプには、データ保護に対応するエディションでは、選んだデータに応じて承認を求めるか、操作を止めるカスタムルールを作れる、と書かれています。許可リストが送り先を制限し、データ保護のルールが送る内容を制限する、という分担です。対応するエディションなら、2つを組み合わせます。

KOIYALの見解

9月17日の変更で、Workspace Studioは、Googleのアプリの中で閉じた道具ではなくなりました。社内の誰かが書いた処理を部品にして配り、社外のサービスと行き来し、任意のURLにデータを送る。これは、ノーコードの道具が、小さな開発基盤になった、ということです。

当社は、これを歓迎しています。インハウス経営（AIを活用し、自社で業務を改善し、自社で仕組みをつくる経営）の立場から見ると、Apps Scriptを書ける人が1人いれば、その人が作った部品を、書けない人がフローの中で使える。これは、自社で仕組みをつくる会社にとって、使える範囲の広がりです。外注しなくても、社内で部品が増えていきます。

ただし、歓迎するのと、デフォルトのまま開くのは別です。Googleは4つともデフォルトでオフにし、コントロールする設定を3か所に置きました。3か所に分かれている理由は発表に書かれていませんが、当社の読み取りでは、コントロールする対象が違うからです。機能のオン・オフは誰が使えるかを、承認は動く前に人が見るかを、許可リストはどこへ送るかを制限します。オンにするなら、3つを組み合わせて決めます。

管理者がこの3つを自社で決められる状態が、当社の言うインハウス経営の、情報システムの側の姿です。ベンダーに設定を頼むのではなく、Apps Scriptを書く人の有無と、社外へ送る用事の有無から段階を決め、承認を先に入れ、ログで確かめる。この順番は、Workspace Studioに限らず、今後増える同じ種類の機能にも使えます。

次の行動

  1. 管理コンソールで、Workspace Studioの設定にカスタム手順、連携、Webhookの3つがあることと、オフのままであることを確かめる
  2. 「Drive and Docs」の「URLからのインポートと取得」が今どの選択肢かを見て、自社のエディションで許可リストが使えるかを確かめる
  3. Apps Scriptを書く人の有無と、社外へ送る用事の有無で、開く段階を1つ決めて、理由を1行で残す

3つ目で決めた段階と理由を持って相談に来ていただければ、AI・DXコンサルティングの初回の打ち合わせで、承認の設定と許可リストの中身を一緒に決めます。Geminiの開放の4段階と合わせて、Google Workspaceの管理者設定の初期値を自社の方針に合わせるところまでが、当社の関わり方です。お問い合わせの本文に、エディションと、決めた段階を書いていただければ、初回の前に当社で設定の案を用意します。

参考