要点から先に言う。WMS・OMS・TMSにSSOを導入する前に、プロトコルのドキュメントから始めないこと。半日かけて3列のスプレッドシートを作ろう——「人」「各システムでの役割」「退職時にアカウントを無効化するのは誰か」。このシートが埋められなければ、SAMLを選ぶかOIDCを選ぶかは関係ない。このパターンの失敗を3回見てきたが、崩壊のポイントはいつも同じだ。IdPはきれいに接続できるのに、ビジネス側のロールマッピングがぐちゃぐちゃになっている。
なぜいつも本番前夜に爆発するのか
2023年9月。南カリフォルニアの60,000平方フィートの3PL。同じ週にWMS・OMS・TMSを一斉導入することになった。単純にするため、クライアントは現場に3システム共通の共有ユーザー名とパスワードを1組渡した。効率的に聞こえるだろう？
3日目に爆発した。OMSで受注を確認できるはずのカスタマーサービス担当が、TMSのキャリア運賃まで編集できてしまったのだ——なぜなら「CSR」というロールはシステムごとにまったく別の意味を持ち、共有ログインは3つの中で最も広い権限を継承したからだ。オーナーは私に聞いた。「これがシングルサインオンじゃないの？なんで余計にぐちゃぐちゃになるの？」私の答えはこうだ。「それはシングルサインオンじゃない。ログイン画面付きの単一障害点だ」
立て直し方は泥臭かったが効いた。共有アカウント約40件を一晩で凍結し、人・システム・役割をひも付けた120件の個別アカウントを再構築し、業務を回し始めてから、ロールマトリックスをすり合わせ、すべてを単一のアイデンティティソースにつなぐのに2週間かけた。このプロジェクトで身に染みた教訓が1つある。SSOが答えるのは「あなたは誰か」。認可が答えるのは「あなたに何ができるか」。これは別の問題であり、後者を前者に押し付けてはならない。
チェックリスト。ゼロからSSO、ステップバイステップ
ステップ1。すべてのアカウントを棚卸しする。3システムの全アカウントを、ユーザー名・システム・現行ロールの3列でスプレッドシートに書き出す。3種類にフラグを立てる——退職者ゾンビアカウント（ほぼどのプロジェクトにも5–10%ある）、共有の「パブリック」ログイン（ピッキング用タブレットに最多）、過剰権限の「神アカウント」。本番前にこれらを掃除しなければ、SSOを入れても何も変わらない。
ステップ2。ロールマッピングマトリックスを作る。行は業務ロール（ピッカー、CSR、ディスパッチャー、倉庫スーパーバイザー、経理、IT管理者）、列は3システム、各セルはそのロールがそのシステムで押せるボタンを正確に書く。要注意。「ディスパッチャー」はTMSとWMSで同じものとは限らない。同名でも権限が違う。ビジネスオーナーにこのシートへサインをもらうこと。サインなしに本番なし。
ステップ3。アイデンティティソースを決める。すでに全社のアイデンティティシステムがあるなら、それをIdPに使う——二重に作らない。何もない場合だけステップ4のプロトコル選定に進む。
ステップ4。プロトコルを選ぶ。新規システムはOIDCを優先。レガシーはSAML 2.0対応の有無を確認する。伝統的なWMS製品の多くはSAMLしか話さない——無理にOIDCを押し付けてコードを書き換えさせない。プロトコル適合のウサギ穴は見た目より深い。
ステップ5。ユーザー属性をマッピングする。IdPが下流に渡すものを決める。従業員ID、メールアドレス、部門、ロール。安定したグローバル一意の識別子を少なくとも1つは渡す——メールではなく従業員ID。メールは名前変更で変わる。各項目には権威あるソースを名指しする。部門は人事、以上。
ステップ6。退職者フローをつなぐ。アカウント無効化は人事の退職処理にフックし、目標は「最終日に無効化」。自動化できないなら、ITが毎週金曜の午後に退職者リストを手作業で突き合わせる。この抜け穴は3回見た。2024年始め、生活雑貨のEC倉庫が、クリーンなSSO導入から6か月後に権限監査をして、3か月前に辞めたディスパッチャーがまだTMSにログインしてキャリア運賃を閲覧できることを発見した——人事の退職者リストがITと一度も同期されていなかったからだ。
ステップ7。段階的に展開する。ITスタッフ5–10名で1週間のパイロット、次に1倉庫、最後に全員。パイロット中はロールバック用に旧ログイン経路を残す——この行は私の本番前夜チェックリストの先頭に永久に置いてある。
先に計算しよう。SAML vs OIDC vs 自前
| SAML 2.0 | OIDC | 自前アカウント | |
|---|---|---|---|
| 向き不向き | レガシーシステム、伝統的WMS/ERP | 新規システム、クラウドネイティブアプリ | 1〜2システムの小さなチーム |
| 導入の手間 | 中（冗長なXML設定） | 低（JSON、成熟したエコシステム） | 初期は低、後から高 |
| 継続的な保守 | 低（成熟した標準） | 低 | 高（パスワードポリシー、監査、MFA——全部自前） |
| モバイル/タブレット対応 | 弱 | 強 | 自社コード次第 |
| 長期的な総コスト | 古いが安定 | 新規プロジェクトの標準選択 | 2システムを超えると赤字——やめとけ |
判断の枠組みはシンプルだ。3システムのうち1つでもSAMLしか対応していなければSAML一択。新規システムばかりならOIDC。2年以内に2システムを超えない確信がある場合だけ自前を検討する。自前アカウントシステムの本当のコストは構築費じゃない——4つ目のシステムをつなぐ日に、最初の3つがバラバラのパスワードポリシーを発明していたと気づく日のことだ。
本番前夜チェックリスト。失敗は全部ここに住んでいる
- テストアカウントを削除する。ほぼどのプロジェクトでも、本番前夜にまだ生き残ったtest01型のアカウントが3–5件見つかる。
- 管理者アカウントをSSO経由にしない。IdPがダウンした日のために、各システムに最低1つはローカルのスーパー管理者アカウントを残す。パスワードは紙に書いて金庫にロックする——原始的だが、これが本番を救ったことがある。
- 3システムのセッションタイムアウトをそろえる。WMSが8時間、TMSが30分ではディスパッチャーは発狂する。4–8時間で標準化し、繁忙期のタブレット（ロックしない）用は別ポリシーにする。
- デッドゾーンシナリオをテストする。倉庫のワイファイが切れると、SSOのリダイレクトページがタブレットに読み込めず、ピッカーはラックの前で呆然と立ち尽くす。デグレードモードのフォールバックは、実際の現場で本物のテストをすること。
- 監査ログが突き合わせ可能であることを確認する。何かが壊れたとき、「昨日午後2時にこのユーザーがTMSで何を変更したか」に答えられなければならない——3システムのログはすべて同じユーザー識別子を持つ必要がある。
最後に異端のメモ。SSO導入後に「安心した」と感じる人は多い。真実は逆だ——SSOは「1つの鍵、1つの扉」を「1つの鍵、3つの扉」に変える。つまり鍵をなくしたときのコストが3倍になる。SSOにおけるMFAはオプションではなく、セットの一部だ。摩擦が大きすぎる？なら少なくとも管理者と経理ロールには強制しよう。
明日にできること。3システムのアカウントを書き出して、ステップ1の3列に並べること。最初に見つかる真実はいつもこれだ——「80件ある」と思っていたアカウントは実は110件ある。
Lin Xiao（WMS導入コンサルタント）著
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
