ベンジャミンのヤマノウチです。

前編でSSOの設定までをお知らせしていきましたが、あとはリリースに向けた流れをお伝えしていきたいと思います。

7. この後の流れ

移行日当日に向けた準備と影響範囲の確認

• 　メールアドレスの突合
• 　アプリやワークフローの棚卸し
• 　ユーザーへのログイン方法の告知の準備
• 　緊急時の連絡先
• 　ダウンタイムについて
• 　ワークスペース移行日の予約

関係各所への連絡

ワークスペース移行日

8. 移行当日に向けた準備と影響範囲の確認

最優先タスク：メールアドレスの突合

繰り返しになりますが、移行前の最重要タスクは全メンバーの Slack アカウントのメールが会社の Google Workspaceメールアドレスと一致しているかの確認です。ここがずれている人は、SSO 必須化の瞬間にロックアウトされます。テストが通っても、それは「自分のアカウントが一致している」ことの確認にすぎない点に注意が必要です。

ワークスペースのメンバーメニューで一覧をエクスポートして、Google側もCSVでダウンロードしてメールアドレスで突合しておきましょう。ここで必要なのは、あくまで企業のドメインでGoogle Workspaceに払い出したユーザーに対してSSOでSlackへのログインを行うようになるユーザーの突合であり、ゲストユーザーやSlack Connectユーザーは突合の必要はありません。

Google Workspaceのアドレス以外でSlackにログインしている人や、サフィックス（例[xxxx+123@benjamin.co.jp]の+123の部分）などを利用してSlackユーザーを作成している場合、ログインができなくなってしまいます。

アプリやワークフローの棚卸し

クラシックアプリはレガシーな権限モデルを使っており、依存したまま移行すると将来的にイベントを受信できなくなります（機能停止の期限が設定されています）。移行前に、使っている連携アプリがクラシックアプリでないかを確認しておきます。

また、他にもGoogleスプレッドシートへのアクセスがあるワークフロー等が使えなくなる、という報告を受けています。おそらくスプレッドシートに限った話ではないのでしょうが、ワークスペース移行後にGoogleへの認証を再度実施すると使えるようなので、事前に数や、誰が触れるのか、優先度等を把握しておくことをお勧めします。

アプリにせよワークフローにせよ、「こうすれば大丈夫」と、この記事で語れるものではありません。環境個別のものであり、サードパーティ製のものもあれば、ワークフローなどは自作のものが多いからです。動かないと業務が止まる、というケースもあれば、後でどうとでもなるケースもあろうかと思います。弊社は確実に後者寄りで、ワークスペース移行後に確認、修正したのでも充分こと足りる状況でした。

よって、ここは業務影響を最小限に留めるよう、冷静に判断をしてください。必要に応じて、各部門と調整も検討してください。

ユーザーへのログイン方法の告知の準備

Google WokspaceのSSOを用いてログインするユーザーには、Slackのワークスペース移行が完了すると以下のようなメールが送信されます。「Slackを起動する」から起動してください。

移行後、メンバーは一度 Google 経由でログインし直し、Slack アカウントを SSO と紐付けることになります。この紐付けリンクは72時間で失効しますが、過ぎても慌てる必要はありません。管理者が再バインドメールを再送すれば復旧できます。

再送手順は「組織名 → ツールと設定 → オーガナイゼーションの設定 → メンバーディレクトリ → メンバー → 対象者のプロフィール → 氏名横の「・・・」 → SSOの再バインドメールを送信する」。この操作は Org / Workspace の Owner・Admin が行えるので、移行直後の問い合わせ対応に備えて、対応できる人を複数用意しておくと安心です。

ゲストユーザー（シングル、マルチ問わず）には、一度ログアウトされてしまう旨を通知して、再度ログインをしてもらうように伝えるか検討しましょう。ゲストユーザーは社外の人が多いと思います。個別に連絡が必要かもしれませんので、それぞれゲストユーザーの関係部署と相談して、必要に応じて連絡してもらいましょう。伝えてもらうことの要約としては、「移行後ログインし直してください」です。

影響を受けないユーザー

• Slack Connect の社外ユーザー：相手企業のSlackワークスペースで認証されるため、こちらの SSO 設定の管轄外。影響なし。

緊急時の連絡先

ログインが出来ないなど、何らかの理由で使えなくなったときの連絡先も用意しました。今回は、メールアドレス、GoogleChatのスペース等を事前に用意しておきました。

ダウンタイム

ワークスペース移行にはハードダウンタイム（一時的にアクセスできない時間帯）が伴います。弊社ではお客様のシステムの監視の通知をSlackで実施しているものがあったりするので、Slackが動いてない時間があったときの影響がないか、他部門へ確認を実施しました。今回は問題なし、との回答だったのでよかったのですが、もし影響が想定される場合だと、より調整が大変だったかもしれません。

ワークスペース移行日の予約

ワークスペースをオーガナイゼーションに引っ越す、Xデー、運命の日の設定です。

移行日時は「日付＋おおよその時刻」で指定する形で、分単位のピンポイント指定はできません。Slack 側の移行カレンダーの枠を予約する形なので、希望の枠が取れるとは限りません。全社アナウンスを先に出してしまうと「その日取れませんでした」となりかねないので、先に枠の予約可否を確認し、確定してから告知するのが安全です。時差の関係で日本時間の早朝が取りにくいこともあるため、第二希望も用意しておくとスムーズです。当社の場合は業務終了している「00:00」を指定しました。

以下の赤枠「管理」のところから設定可能です。一度設定した後も変更できます。

関係各所への連絡

関係各所へ以下の連絡をしましょう。

• ワークスペース移行日時（ダウンタイムあり）
• アプリ、ワークフローへの影響
• 緊急時の連絡先
• 移行後ユーザーのログイン方法（SSOユーザー、ゲストユーザー）
• その他、必要に応じて

こういった連絡や周知、調整があるからこそ、前編の冒頭でお伝えした通り、「移行プロジェクト」と言えるわけです。

これで準備は整いました。あとは移行日を待つだけです！

9.　ワークスペース移行日当日

移行日は張り付きで監視しました。張り付きの必要があるかは多少議論の余地がありそうですが・・・。指定した時間になると、オーガナイゼーションの管理コンソールにワークスペースの移行が開始された旨が表示され、ただただ待つことしかできません。弊社はほぼリモート勤務なので、Slackが止まるとあらゆる業務が滞る可能性が高いです。終わらなかったり、失敗したらどうしよう、という心配がちらつきます。


結果、ワークスペースの移行自体はおおよそ30分程度で終了しました。シンプルな構成だったので早かったのだと思います。こんなメールが来てました。あっさりしてます。

朝の出勤時間まで、ユーザーが入ってくることができるかどうかわからないのがとにかく心配で、「孤独」な状態になります。トラブル時の対応も考えた時間の設定（00:00）だったため、始業時間（10:00）まで長く、落ち着かない時間だったことを覚えています。

Slackデスクトップを起動すると、ちょっとだけ画面が変わっている印象はあったのですが、それほど違いはわかりませんし、意識する必要はなさそうです。

Slackに孤独を訴える独り言ポストをすると、しばらくしてメールでワークスペースの移行完了を知り、ログインできたユーザーがリアクションをくれたのでとても安心しました。どなたか管理者ではない方に依頼して、ログインできたかをリアクションしてもらうよう手配しておくのも良いかもしれませんね。

発生したトラブル

比較的シンプルな構成だったため、トラブルはそれほどありませんでしたが、強いて挙げるとすると、以下がありました。

・Googleスプレッドシートへのアクセスが含まれたワークフローが動かなくなった
　→Googleに認証を再度通せばOKだった、とのことでした。この限りかどうかはわからないですが、ご参考まで

・ゲストユーザーがログインできない、という問い合わせがあった
　→基本的には再度ユーザー名とパスワードでログインしてもらう旨の連絡を改めて実施するとログインできたとのことでした。

ということで、無事移行完了としました。

10. まとめ：これから移行する人へ

Slack Pro → Enterprise+ の移行は、作業というよりプロジェクトでした。最後に、実際にやってみて感じた要点をチェックリストとして残しておきます。

• SSOを実現するIdpはあるか？　ないと進められない
• IdP は「全員が確実に持っているもの」を選ぶ。払い出し漏れがあると移行時に締め出しが起きる
• Slack、IdPの自分の権限は把握しておくこと。なければ付与してもらう、あるいは権限者と一緒に作業する
• メールアドレスの突合はしっかり。メールアドレスが一致しないと締め出しが起きる
• ダウンタイムがある。止まって問題ないか確認が必要。
• Googleスプレッドシートを使ったワークフローが動かなくなる。認証作業が必要。
• 移行日の枠は先に確保してから全ユーザーに告知する
• 周知はサボらず丁寧に。あらゆる可能性を検討して相談、通知。

で、Slack Enterprise+はどう？

結論から。移行して良かったと思います。AIが無制限に使えますし、ワークフローの自動生成でワークフローが新たに生まれ始め、業務省力化が進んでいますし、毎日のダイジェスト（Bussiness+以上の機能）で投稿の見落としや回答漏れが減りました。さらにはAIを組み合わせる窓口とするところに無限の可能性を感じます。Salesforce連携はもちろんのこと、notionやBacklog等とMCPサーバーやAPIで接続し、データの取得や更新の選択肢が広がっています。

Slack Enterprise+は、セールスフォース社がDreamforce 2026で掲げたAIforceの旗印として、ただのチャットツールではなくあらゆるUIを置き換えてしまえる可能性があると感じています。より使い込んで、ブログにて拡散していきたいと思います。

弊社で移行のサポートも可能ですので、（20万円〜）お気軽に問い合わせフォームからご連絡ください！

お問い合わせはこちらから