Unified Accessの製品は、全てを一度に入れる必要はありません。1つの製品から始めて、次に大きな穴がある領域へ広げていく形が基本です。ただし、どの順で入れても同じ結果になるわけではありません。最初の製品で決めた設計が、後から入れる製品の前提になるからです。後で足す製品を考えずに最初の設計を固めると、2つ目の製品を入れる段階で、管理者の構成やプロビジョニングの方式をやり直すことになります。このページでは、Enterprise Password Managerから始める理由、2番目の製品の選び方、最初に決めておく設計、広げるときの段取り、避けたい順序を説明します。
Enterprise Password Managerから始める理由
最初の製品は、ほとんどの組織でEnterprise Password Managerになります。理由は3つあります。
1つ目は、ほかの製品の前提になることです。SaaS Managerは保管庫と拡張機能を検出の情報源にし、Device Trust Coreは拡張機能を入口にし、Credential Brokerは保管庫からクレデンシャルを渡します。保管庫と拡張機能が社員に行き渡っていないと、後の製品が十分に働きません。
2つ目は、効果がすぐに見えることです。共有のパスワードの台帳がなくなり、退職時に変えるべきパスワードが分かるようになります。経営層や監査の担当者に成果を示しやすく、次の製品の予算を取る材料になります。
3つ目は、社員が毎日触る製品であることです。社員のブラウザーに拡張機能が入り、保管庫を使う習慣ができてから次の製品を入れると、社員への説明が「いつもの1Passwordに機能が加わる」で済みます。
2番目の製品の選び方
2番目は、Enterprise Password Managerを入れた後に残っている課題の中で、最も大きいものから選びます。
SaaSの把握と費用が課題なら
SaaS Managerを選びます。Enterprise Password Managerの運用で、保管庫に業務のSaaSのログインが集まってきた段階が入れどきです。集まった分だけ、アプリ検出で見つかるSaaSが増えます。入社と退職のたびにSaaSのアカウントを手で追加と削除している組織ほど、効果が大きくなります。
端末の状態が課題なら
Device Trustを選びます。私物の端末、委託先の端末、テレワークの端末から業務のシステムに入っている組織に向きます。Device Trust Coreは拡張機能を入口にするため、拡張機能の配布を終えてから入れてください。SSOのサインインの流れで判定したい場合はDevice Trust Connectを選び、IDプロバイダーの条件を先に確かめます。
開発と基盤が課題なら
Credential BrokerかPrivileged Accessを選びます。CI/CDのパイプラインに埋め込まれたトークンが課題ならCredential Broker、クラウド基盤やデータベースの常設の特権が課題ならPrivileged Accessです。どちらも2026年9月時点で新しい製品で、Credential Brokerは公開プレビューの段階です。本番の処理を移す前に、検証用の環境で動作を確かめる期間を取ってください。
最初に決めておく設計
Enterprise Password Managerの設計のうち、後から入れる製品に影響するものがあります。Enterprise Password Managerを入れる段階で、次の5つを決めておきます。
| 設計 | 後の製品への影響 | 本ガイドのページ |
|---|---|---|
| リージョン | 拡張機能で端末を判定する機能は米国のリージョンでだけ使える。SaaS Managerにカナダの環境はない | リージョンの選択とデータの保管場所 |
| 管理者の人数 | SaaS Managerとリンクすると、管理者と所有者のメンバーがそのままSaaS Managerの管理者になる | 所有者と管理者の設計 |
| プロビジョニングの方式 | 自動プロビジョニングを使うとSecurity Automationを使えない | 手動、自動プロビジョニング、SCIM Bridgeの比較 |
| 拡張機能の配布 | 全員に配っておくと、Device Trust CoreとSaaS Managerの検出がそのまま使える | ブラウザー拡張機能のデプロイ |
| 端末の走査の周知 | 端末を見る仕組みへの社員の理解が、後のDevice Trustの導入でも土台になる | 開発者のシークレットを見つけて是正する |
リージョンは作り直さないと変えられません。米国以外のリージョンを選ぶ場合は、後から入れるかもしれない製品の制約を確かめたうえで決めてください。
【運用のポイント】 管理者の人数は、SaaS Managerを入れる前に絞っておくのが安全です。リンクした後でSaaS Manager側だけ管理者のロールを外すことはできず、外すにはEnterprise Password Manager側のグループから外すことになります。最初から必要な人数で始めておけば、リンクの前に棚卸しをやり直す手間がなくなります。
広げるときの段取り
2番目以降の製品も、Enterprise Password Managerと同じ段取りで広げます。少人数で試し、問題を洗い出してから全社へ広げます。試す期間と人数の目安はロールアウト計画とパイロットの考え方がそのまま使えます。
契約の面では、既存の契約の更新の時期に合わせて追加を検討すると、期間をそろえやすくなります。製品ごとの契約とプラットフォームとしての契約のどちらがいいかは、組織の規模と使う製品で変わります。正規販売代理店（デジタルアクセルズ）にご相談ください。
社内の体制では、製品ごとに管理者を決めます。SaaS Managerは情報システム部門と経理や購買、Device Trustは情報システム部門とセキュリティーの担当者、Privileged Accessは基盤の担当者、というように、製品によって関わる部署が変わります。
避けたい順序
次の進め方は、手戻りが起きやすい順序です。
| 避けたい進め方 | 起きること |
|---|---|
| 拡張機能を配り終える前にDevice Trust Coreで止める設定にする | 拡張機能のない端末は判定の対象から漏れる。拡張機能を必須にするチェックで止めると、1Password自体を使えない端末が出る |
| 管理者を整理する前にSaaS Managerとリンクする | 管理者の多い状態がSaaS Managerにも写り、外すにはEnterprise Password Manager側からやり直す |
| 保管庫が育つ前にSaaS Managerのアプリ検出に頼る | 保管庫にログインが少なく、検出の結果が実態より少なく見える |
| 公開プレビューの製品に本番の処理を一斉に移す | 仕様の変更があったときに、全ての処理を同時に直すことになる |
Device Trustで端末を止める設定は、通知だけの段階から始め、社員が自分で直せることを確かめてから強めます。進め方はDevice Trustと組み合わせると何ができるかで扱います。