Slackプラン移行記　ProからEnterprise+へ（前編）　

technologies

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

社内で使っている Slackのプランを 「Pro」 から 「Enterprise+」（旧 Enterprise Grid）へ移行しました。

やってみて分かったのは、これは「プランのアップグレードボタンを押す」だけの作業ではなく、認証基盤（SSO）の構築を伴う、識別子とアカウントの移行プロジェクトだということです。この記事では、移行の全体像を時系列で残しておきます。これから同じ移行をする方の地図になれば幸いです。

まずは前編として、まずはオーガナイゼーションの作成からSSO（Google Workspace SMAL）の設定まで、まず記載します。

今回の前提（自社の状況）

  • 移行元は Pro プランのワークスペースが1つ（比較的シンプルな構成）をEnterprise+に移行する
  • 全社員が会社の Google アカウント（Google Workspace）を持っている
    →SSOにGoogle Workspace SAMLを採用
  • これまで SSO は使っておらず、メール＋パスワードでログインしていた
  • 社外のパートナー様は Slack Connect を利用、一部にゲストユーザーも存在

事前準備

Slackのワークスペースのプライマリオーナーを把握する

　→オーガナイゼーションの作成、およびワークスペースを作成したオーガナイゼーションに関連づける際に作業や承認をしてもらう必要があります。

Google WorkspaceのSSOを触れる権限

　→この権限がないと今回の作業ができません。ない場合は権限を付与してもらうか、権限のある方と作業をしてください。

SSOのIdpを選定しておく

　→SSOが移行の必須条件なのでIdpをどこにするかの検討が必要です。　

1. はじめに：Enterprise+ って Enterprise Grid とは別物？

まず最初につまずいたのが名前です。契約したのは「Enterprise+」なのに、ドキュメントやネット上の情報は「Enterprise Grid」と書かれていることが多いので戸惑います。結論から言うと、移行という観点においてはこの2つは同じものと考えてよさそうです。以前 Enterprise Grid と呼ばれていたプランが Enterprise+ という名称に切り替えられ、Grid という呼称は段階的に廃止されつつあります。

複数のワークスペースを一つの組織（オーガナイゼーション）の統一管理下に置く、という基盤の考え方は同じです。ドキュメントによっては今も「Enterprise organization」「Enterprise Grid」という表記が残っていますが、指しているものは同じ、と理解しておけば混乱しません。

2. 移行の全体像を掴む

作業に入る前に、全体像を掴んでおくと迷いません。移行は大きく次の流れで進みます。

  1. Enterprise+ を契約し、オーガナイゼーション（Org）という「器」を作る
  2. 移行の必須要件である SSO を設定する（今回は Google Workspace SAML）
  3. 全メンバーのメールアドレスを突合する（ここが一番大事）
  4. 連携アプリ、ワークフロー、業務影響などを棚卸しする
  5. 移行日を予約し、全社周知のうえで移行を実行する。ワークスペースをOrgに移行する

重要なのは、これが「ワークスペースを Org へ引っ越しさせる」作業だという点です。ですが、今回のように単一のワークスペースを空の Org へ移す場合は比較的シンプルに進められます。

3. オーガナイゼーション（Org）を作る ― 移行の「器」づくり

Enterprise+ は Web からセルフサービスで申し込むプランではなく、Slack の営業担当（AE）経由での契約が前提です。契約手続きが完了すると初期セットアップ用の招待メールが届き、Org 作成はこのメールのリンクから始まります。あわせて、Org 全体でただ一人だけが就ける最高権限ロール Org Primary Owner を誰にするか、最初に決めておきます。

手順

  1. 基本情報の設定：招待メールのリンクから、Org用のアカウント作成（氏名とパスワード）、Org設定（オーガナイゼーション名とドメイン）を設定
    ・ここで作成するアカウントは、新しく作成されるOrgのオーナーになります。
    ・オーガナイゼーション名は、任意の名称で構いません。ドメインは、ワークスペースで使用しているドメインとは別のOrg用のドメインです。新しく設定してください。
  2. 1の手順を終えると、Orgの画面にログイン可能です。以下の画像のように、移行に必要な手順を示してくれます。※手順を終えたキャプチャしかなく。。。
  3. 「Orgを設定する」→「詳細を編集する」から、アイコンを設定して保存
    ここで1で設定したOrg名とドメインを変更できます。

    ドメインは運用し出してから変えるとやや問題があるので、変更するならSSOの設定を終えるまでに実施しましょう。

  4. Org Owner の追加（任意）：手伝ってもらう人がいれば追加します。不要ならスキップ可です。後からいつでも追加できます。万が一なんらかの理由で入れなくなってしまった場合等のことを考えると追加を推奨します。
  5. 既存ワークスペースの設定を引き継ぐ：「ワークスペースから設定を適用する（移行が必要です）」から、既存ワークスペースの URL と ID を入力して移行リクエストを送信します。なお、この設定時点では既存のワークスペースには影響を与えることはありません。ここで必要なURLは、ワークスペースのURLであって、オーガナイゼーションのURLでないことを明記しておきます。

    ※キャプチャの赤枠部分のエラーメッセージはキャプチャ取得時に過程で発生したものなので無視してください。

    ワークスペースID、URLの確認方法はこちら
    ここで入力するURLはOrgに設定したURLとは別のもので、既存のワークスペースから取得します。
  6. 移行リクエストの承認：移行元ワークスペースの Primary Owner がサインインして承認（自分が兼ねていれば自分で完結）。Slack上にて承認依頼が来ます。（承認後のキャプチャでスミマセン・・・）

  7. 承認待ちの間に基本設定：この時間で SSO など Org の基本設定を進めておくとリードタイムを短縮できます。

ここで Org のドメインが 〜.enterprise.slack.com という形式で決まります（例：example.enterprise.slack.com）。ワークスペース単体のときの 〜.slack.com とは違い、.enterprise. が挟まる点がポイントです。オーガナイゼーションのドメインと、もともとあったワークスペースのドメインは「別のもの」というところを頭の片隅に置いておきましょう。

なお、Org 作成後の各種管理は、サイドバーの組織名 →「ツールと設定」→「オーガナイゼーションの設定」で開く Admin Dashboard が起点になります。以降の SSO 設定もメンバー管理も、すべてここから行います。

もちろん、すべての作業を1日で終えることができない場合があると思いますので、改めてログインする場合はサイドバーのワークスペースの並びの中の＋ボタンや、Slackのログイン画面（ブラウザ）から上記手順1または4で追加したアカウントでログイン可能です。

4. IdP の選定：Trust Login か Google Workspace か

Enterprise+ への移行では SSO の設定が必須です。おそらくここがSlackのEnterprise+移行の一番の難所かもしれません。

そもそもSSO（シングル サイン オン）とは、簡単に言うと、「とあるアカウントにログインできてたら、他のシステムでもログインできた状態にする」、といった仕組みのことです。

設定が必須な理由は、Enterprise プランでは認証の入口が Org レベルの SSO に一本化される設計だから。移行が完了した瞬間から、ユーザーは SSO 経由でしかログインできなくなります。そのため、SSO が未設定のまま移行すると全員がログインできなくなる ―― だから「移行の前」に SSO を用意しておく必要があるわけです。

SSO を実現するには IdP（Identity Provider＝認証を担う基盤）が必要です。当初は社内で使っていたGMOの Trust Login を IdP にする想定でしたが、確認したところ一部のメンバーに Trust Login アカウントが払い出されていないことが判明しました。SSO は IdP に登録されている人しかログインできないため、このまま移行すると未払い出しの人が締め出されてしまいます。

そこで方針を切り替え、全社員が確実に持っている Google Workspace を IdP にすることにしました。全員が Google アカウントを持っているため払い出し漏れの構造的リスクがなく、Google 側のアカウント変更を Slack に同期する自動プロビジョニングも使えるので、メンテナンスも楽になります。

5. SSO 設定の実践（Google Workspace SAML）

SSO 設定は、Google 側（IdP）と Slack 側（SP＝サービス提供側）の両方を行き来しながら進めます。全体は「Google 側で Slack アプリを登録して値を取得 → Slack 側に入力 → Google 側でアプリを有効化 → テスト → 本番有効化」という流れです。

Google 側の設定

  1. 特権管理者で Google 管理コンソールにログインし、「アプリ > ウェブアプリとモバイルアプリ」からに移動します

    「アプリを追加」から「アプリを検索」をクリックします

    「Slack」で検索して、アプリ名が「Slack」でプラットフォームが「ウェブ（SAML）」のものを選択します
  2. 「Google Identity Provider details」から SSO URL・エンティティ ID・証明書の3点を取得
    コピぺを使ってどこかに控えておきましょう

    対応する以下を入力して続行します
    ・ACSのURL：https://{オーガナイゼーション作成時に設定したドメイン名}.enterprise.slack.com/saml/acs
    ・エンティティID：https://slack.com
    ・署名付き応答：チェック

  3. 属性マッピングを設定（User.Email ← Primary email が必須。任意で first_name / last_name も）
    マッピングを設定します
  4. ユーザーアクセスを有効化（対象ユーザーに対してアプリを「オン」にする）
    ユーザーアクセスの赤枠部分をクリックします

    左ペインから有効化する対象を選びます。弊社の場合は全社適用だったのでルートにあたるドメインを選択しました。クリックすると、サービスのステータスが表示されるので、「オン」を選んで保存を押してください。

    これでGoogle側SSOの準備は完了です。

    ※サービスのステータスをオンにする対象は、もし判断できなければ社内関係各所と相談してください。

Slack 側の設定

Slack 側は Org レベルの SSO 設定画面（組織名 → ツールと設定 → オーガナイゼーション設定 → セキュリティ → SSO 設定）で行います。Google から取得した SSO URL・エンティティ ID・証明書を入力し、署名設定を合わせます。

SAMLレスポンスの署名を「レスポンスに署名する」にチェック、「アサーションに署名する」は環境によって調整。今回は外しています。

「テスト設定」を押して結果を確認します。押すとGoogleのアカウントを選択する画面が出るので、Google Workspaceにログインして、アカウントを選択してください。

「すべて申し分なさそうです！」と表示されればOKです。

ここまでくれば、設定レベルではほとんど終わったようなものです！お疲れ様でした。

6. ユーザー管理と認証の設計思想

SSO が通ったところで、運用設計についても整理しておきます。ここを理解しておくと、移行後の「誰がどうログインするか」で迷いません。

本人照合はメールアドレスだけ

意外と誤解しやすいのですが、Slack と Google の突合はメールアドレスで行われます。属性マッピングで姓名も渡していますが、これはプロフィール表示やアカウント作成時の名前情報に使われるだけで、本人照合には一切関与しません。姓名が違っていてもログインは妨げられず、逆にメールアドレスが違えば別人扱いで紐付きません。だからこそ「メールアドレスの一致」が移行の生命線になります。

SSO は「必須／部分的に必須／任意」を選べる

SSO の適用度は、全メンバーに必須・ゲストを除く全メンバーに必須・任意、の3段階から選べます。加えて、メンバー／ゲスト単位の除外リストも管理できます。今回の設計は次のようにしました。

  • 一般メンバー・Partner：SSO 対象に含める（Google 経由でログイン）
  • ゲスト・Org オーナー：メール＋パスワードで SSO をスキップ可（管理者の安全弁も兼ねる）
  • 退職者：Google アカウントを無効化する運用なので、そもそも Google でログインできず SSO でも入れない。Slack 側で個別対応は不要

アカウントは自動では増えない（現状）

JIT や自動プロビジョニングを設定していない現状では、Google 側にアカウントを作っただけでは Slack の Org にユーザーは自動追加されません。自動で揃えたいなら JIT／自動プロビジョニングを設定する、逆に意図しない追加を防ぎたいならユーザーアクセスの範囲で管理する、という選択になります。

前編のまとめ

さて、前編はここまでとしたいと思いますが、いかがだったでしょうか？

まず、冒頭で述べた通り、SlackやGoogle Workspaceの権限がそれなりに必要です。自分が権限を持っているかどうか、しっかり確認しましょう。

SSOのあたりはやはり日頃から触っているエンジニアの方とかでないとなかなか理解が難しいところですし、ここであらゆるSSOのIdPの手順を記載もすることもできないので、もし行き詰まったら早めにSlackサポートやセールスフォース社にサポートを求めることをオススメします。

あるいは、我々ベンジャミンの方で移行のサポートも可能ですので、（20万円税別〜）もし難しそうだな、と感じたらお気軽に問い合わせフォームからご連絡ください！

後編では、移行の予約、検討しておいた方が良いこと、などをお伝えできればと思います。

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

Related posts