SaaSの「勝手に連携」を止めずに管理する手順：設定を締めたとき既存の連携が止まるかは3社で違う(2026)

「うちはSaaSの導入は情シスが管理しています」。そう聞いたあとに管理画面を開くと、名前も知らないアプリが会社のカレンダーやドライブにつながっている。その多くは、規則違反ではなく初期設定の結果です(編集部)。

この記事は、すでに増えてしまった外部アプリの連携を、業務を止めずに管理下へ戻す手順をまとめたものです。対象は、中小〜中堅企業の情シス・総務と、専任の担当者がいない会社で管理者権限を持っている方です。いま契約しているサービスの管理画面だけで進められる範囲を扱います。

最終更新: 2026年9月21日／各社の公式ドキュメントは同日に原文で確認しています。本文の「(編集部)」は、出典の記述ではなくjisalab編集部の解釈・推奨であることを示します。

前提の確認：既定値は3社とも緩い

Google Workspaceの公式ヘルプは、「未設定のサードパーティ製アプリ」の設定の既定を次のように書いています。

「サードパーティ製アプリへのアクセスをユーザーに許可する（デフォルト） – ユーザーは任意のサードパーティ製アプリに Google でログインできます。アクセスされたアプリは、そのユーザーの Google データへの制限なしのアクセスを要求できます。」

Microsoft Entra IDは、既定の時点で権限の強さによる線があります。

「既定では、すべてのユーザーが、管理者の同意を必要としないアクセス許可のアプリケーションに同意することが許可されています。 たとえば、既定では、ユーザーはアプリが自分のメールボックスにアクセスすることを許可することができますが、組織内のすべてのファイルを自由に読み取りと書き込みできるアクセスをアプリに許可することに同意することはできません。」

Slackのヘルプセンターは「デフォルトの設定ではワークスペースのオーナーによる承認がなくても、メンバーはアプリをインストールできます。」としています。

手順1 自分の権限を確かめ、いま何がつながっているかを一覧にする

最初に自分の権限を確かめます。公式ドキュメントの要件は次のとおりです。

• Google Workspace：「API の制御」画面は「アクセスするにはサービス設定の管理者権限が必要です。」
• Microsoft 365：アプリの一覧とアクセス許可の確認は「クラウド アプリケーション管理者」以上。ユーザーの同意設定は「特権ロール管理者」ですが「グローバル管理者ロールは、Microsoft Entra 管理センターを使用する場合にのみ必要です。」とされ、管理者の同意ワークフローの有効化は「グローバル管理者である必要があります。」
• Slack：アプリの承認機能は「ワークスペースのオーナー」が使え、すべてのプランで利用できます。

Google Workspaceは、管理コンソールの「セキュリティ」→「アクセスとデータ管理」→「API の制御」に、設定済みアプリ・アクセスしたアプリ・審査待ちのアプリの3つの一覧があります。実務で見るのは「アクセスしたアプリ」で、各アプリの「ユーザー – アプリにアクセスするユーザーの数。」と、使われているGoogleサービスのAPIを確認できます。

落とし穴が1つあります。公式ヘルプは「表示されていないデータも含め、表内のすべてのデータがダウンロードされます。」としたうえで、CSVで追加される列を、設定済みアプリでは「確認ステータス、ユーザー数、組織部門、リクエストされたサービス、各サービスに関連付けられた API スコープ」、アクセスしたアプリでは「確認ステータス、組織部門、各サービスに関連付けられた API スコープ」と書いています。アクセスしたアプリの追加列の説明に、ユーザー数は含まれていません。落としたCSVにユーザー列があるかを確かめ、無ければ画面から転記してください。

Microsoft 365は、Microsoft Entra 管理センターの「Entra ID>エンタープライズ アプリケーション>すべてのアプリケーション」が一覧です。アプリケーションの種類のフィルターについて、公式ドキュメントは「[エンタープライズ アプリケーション] には、Microsoft 以外のアプリケーションが表示されます。」としています。アプリを選んで「アクセス許可」を開くと、組織全体への付与は「管理者の同意」タブ、特定のユーザーやグループへの付与は「ユーザーの同意」タブに出ます。利用者数は「ユーザーの同意」タブから数えます(編集部)。組織全体に付与されたアプリは、この方法では数えられません(編集部)。

Slackは、公式ヘルプの手順に「Slack Marketplace に移動します。右上の「管理」をクリックします。「インストールされたアプリ」ページで、アプリを検索して選択します。」とあり、この「インストールされたアプリ」ページが一覧になります。Slackのアプリはワークスペース単位で入り、「アプリをインストールすると、ワークスペースのメンバー全員が自分のアカウントを連携してそのアプリを使用できます。」とされています。利用者数は部署に聞いて埋めます(編集部)。

ゴールは、サービス・アプリ名・利用者数・要求している権限が並んだ表を1枚作ることです。この表を手順4でも使います。

手順2 通す・通さないの線を引く

1. 要求している権限の範囲で分ける。自分のカレンダーを読むだけのものと、組織全体のファイルを読み書きできるものを、同じ列で判断しないでください。Microsoftの既定も、自分のメールボックスと組織内のすべてのファイルを分けて扱っています。
2. 利用者数で分ける。1人のアプリと40人のアプリでは、止めたときの影響が違います。多い側は、止める前に代替を用意する対象です(編集部)。
3. 業務上の要否を部門長に決めてもらう。一覧を部門ごとに切り分けて渡し、「要る／要らない」を書き込んでもらいます(編集部)。

Google Workspaceの確認済みステータスを、そのまま合否の基準にしないでください。公式ヘルプは「確認済みアプリは、Google の審査によって特定のポリシーに準拠していることが確認されています。」と説明する一方で、「よく使われている多くのアプリがここでは確認済みにならない場合があります。」と注記しています。

Google Workspaceでは、未設定のアプリを「「Google でログイン」に必要な基本情報のみを要求するサードパーティ製アプリへのアクセスを許可する」に寄せる方法もあります。全部止めるよりは業務が残ります(編集部)。ただし、この設定でリクエスト機能が働くかは、公式ヘルプの記述からは判断できません。生成AIツールを業務で使うときの社内ルールは生成AIの社内利用ルールを作る手順で扱っています。

手順3 締め方と申請の受け方を、サービスごとに設計する

Google Workspaceで使う設定は3つあり、役割が違います。

• 個別のアプリを止める：[ブロック中]。公式ヘルプは「ブロック – アプリは Google データに一切アクセスできません。」とし、「全ユーザーのデータについて、アプリによるアクセスをブロックするには、最上位の組織部門を選択し、[ブロック中] を選択します。」としています。
• 利用中のアプリをサービスごとに一括で止める：[制限付き]。「Google サービスを管理」でカレンダーやドライブなどを[制限付き]にすると、「アクセス権限を [制限付き] に変更すると、インストール済みアプリのうち信頼していないアプリが動作しなくなり、トークンが取り消されます。」。残るのは「[信頼できる] または [特定の Google データ] のデータアクセスが設定されている社内用アプリとサードパーティ製アプリのみ」なので、残すアプリには先にどちらかを設定します。
• 新しい連携を絞り、申請の窓口を開く：「未設定のサードパーティ製アプリ」。「ユーザーが Google アカウントで未設定のアプリにログインしようとした場合の動作を管理します。」とされる設定です。締めたときに既存の連携がどうなるかは、このヘルプには書かれていません。

窓口を開くのに必須なのは、リクエスト機能の前提になっている3つ目です(下の引用)。既存の連携まで一括で止めたいときに限り2つ目を足します。3つ目だけで既存が止まるとは書かれておらず、2つ目だけでは窓口が開かないので、両方が要る場面があります(編集部)。

「管理者または別の管理者が未設定のアプリへのアクセスを制限している場合、ユーザーはこれらのアプリへのアクセスをリクエストできます。」
「注: このリクエスト フローは、管理者がアクセス設定を割り当てていないアプリでのみトリガーされます。設定済みのアプリが、権限のない Google サービスにアクセスしようとすると、ユーザーはブロックされ、このフローでアクセスをリクエストできなくなります。」

条件は二段です。未設定のアプリへのアクセスを制限していなければ、リクエストは発生しません。制限していても、個別にアクセス設定を割り当てたアプリはこのフローに乗りません。そこで「ユーザーに未設定のサードパーティ製アプリへのアクセスのリクエストを許可する」をオンにし、カスタム ユーザー メッセージに申請方法を書き、未設定のアプリへのアクセスを制限する、までを同じ日に行います(編集部)。反映には「変更が反映されるまでに最長で 24 時間ほどかかることがありますが、通常はこれより短い時間で完了します。」とされているので、告知では翌日以降の運用開始としておくと混乱が少なくなります(編集部)。

Microsoft 365は、ユーザーの同意設定を締めても既存の連携は残ります。

「ユーザーの同意設定の更新は、アプリケーションの今後の同意操作にのみ影響します。 既存の同意付与は変更されず、ユーザーは以前に付与されたアクセス許可に基づいて引き続きアクセス権を持ちます。」

締める設定は「エンタープライズ アプリケーション>同意とアクセス許可>ユーザーの同意設定」にあります。同ドキュメントの組み込みポリシーの説明では、選択肢は「選択したアクセス許可に対して、検証済みの発行元からのアプリに対するユーザーの同意を許可する」と「アプリのユーザーの同意を許可する」で、ユーザーの同意を無効にすることもできます。前者を選ぶ場合、同ドキュメントは「(ユーザーが同意できる アクセス許可 を選択するには、必ずアクセス許可を分類してください)」としています。同ドキュメントは「検証済みの発行元によって発行されたアプリケーションに対してのみユーザーの同意を許可することをお勧めします。」としています。

既存の連携で止めたいアプリは、手順1の「アクセス許可」画面で個別に取り消します。ただし「ポータルを使用して、[ ユーザーの同意 ] タブでアクセス許可を取り消すことはできません。」とされ、利用者が自分で同意した分は Microsoft Graph API または PowerShell で取り消します。

窓口は「管理者の同意ワークフロー」です。「ユーザーがアプリケーションにアクセスしようとしているものの同意ができない場合には、ユーザーは管理者の承認の要求を送信できます。 要求は、レビュー担当者として指定された管理者にメールで送信されます。」。設定場所は「[Entra ID]>[Enterprise アプリ]>[同意とアクセス許可]>[管理者の同意設定]」で、有効になるまで「最大で 1 時間かかることがあります。」。

Slackは、制限しても既存のアプリは動き続けます。

「制限されたアプリがワークスペースにすでにインストールされている場合、メンバーはそのアプリを引き続き使用できます。メンバーに使わせたくないアプリは、 すべてアンインストール できます。」

承認機能は、「アプリの管理設定」をクリックし、「承認済みアプリを必須とする」の横にある「編集」から「事前承認済みアプリのみを許可する」にチェックを入れて有効にします。申請は「アプリの承認が有効になっている場合は、事前承認されていないアプリをメンバーがリクエストできます（そのアプリが制限されている場合を除く）。」とされ、「メンバーによる、アプリの承認リクエスト機能の利用を許可する」にチェックを入れると「アプリのリクエスト送信時に、コメントの入力を必須にすることも可能です。」。ただし「Slack ワークスペースにアプリを追加する」のヘルプはリクエストを既定で可能と書いており、扱いが読み取りにくいため、有効化したらこのチェックの状態を確認してください。

有効化すると「ワークスペースのオーナーとアプリ管理権限を持つメンバーだけがサードパーティ製アプリを再インストールできます。」。開発者がスコープを変えたアプリは「アプリの Slack への接続を再承認して新しいスコープの権限を許可する必要があるかもしれません。」とされています。承認機能を有効にしたら、同じ作業の中で使い続けるアプリをすぐ事前承認します(有効化の前に事前承認できるかはヘルプに記載がない)。現場を止めないための手順です(編集部)。

運用で決めておくことは3つです。誰がレビューするか、何日以内に返すか、断るときは何と言うか(編集部)。Slackは既定でリクエストがワークスペースのオーナーに届き、「アプリ管理者を選択する」で特定のメンバーやグループにも任せられます。Microsoftでは、指名しただけでは承認できません。公式ドキュメントは「レビュー担当者が要求を承認するには、要求されたアプリケーションに管理者の同意を付与するためのアクセス許可を持っている必要があります。 レビュー担当者として指定するだけでは、特権は昇格されません。」とし、「Microsoft Graph アプリ ロール (アプリケーションのアクセス許可) を要求するアプリについて管理者の同意要求を承認できるのはグローバル管理者だけです。」としています。期限は「同意要求の有効期限 (日数)」で設定でき、期限が近づくとレビュー担当者にリマインダーが届きます。

Microsoftでレビュー担当者を交代するときは注意が要ります。公式ドキュメントは「新しいレビュー担当者は、既存または期限切れの管理者の同意要求に対して操作を行うことはできません。」とし、「また、レビュー担当者として指定される前に作成された要求には、新しいレビュー担当者が割り当てられません。」と書いています。交代前に出ていた申請は、新任者には引き継がれません。前任者は「自身がレビュー担当者として指定されていた間に行われた要求をレビューする能力を保持し」とされているので、交代前の申請は前任者に片づけてもらうのが安全です(編集部)。

手順4 四半期に一度、同じ一覧をもう一度出す

一度整理しても、新しい連携は増えます。手順1で使った3社の一覧画面から同じ列で表を作り直し、前回になくて今回ある行だけを見ます。Googleの「アクセスしたアプリ」の一覧は「トークンが付与または取り消されてから 48 時間後に更新されます。」とされているので、手順3の設定変更の直後ではなく、2日以上あけて出します。件数が多ければ、手順3の窓口が使われずに入れられている可能性があります。逆にゼロが続く場合は、落ち着いただけなのか、申請をあきらめて別の手段に移ったのかを、現場に一度聞いてください(編集部)。

この棚卸しは、費用の棚卸しと同じ日にやると効率的です。契約と支払いの側からの点検はSaaSの棚卸しでムダな出費を減らす手順にまとめています。

よくある質問