Unified Accessの5つの製品は、守る対象と働く場所がそれぞれ違います。名前だけを見ると重なって見える製品もありますが、実際には前提条件でつながっていて、どれかを入れると別の製品の設計が決まる関係にあります。役割を取り違えたまま契約すると、必要な機能が別の製品にあったり、前提の製品が足りなかったりします。このページでは、製品ごとの役割、土台としてのEnterprise Password Manager、守る対象と製品の対応、製品どうしの前提条件、管理画面とアカウントの分かれ方、2026年9月時点の提供状況を説明します。
製品ごとの役割
| 製品 | 守る対象 | 主な働き |
|---|---|---|
| Enterprise Password Manager | パスワード、パスキー、SSHキー、APIのトークンなどのクレデンシャル | 保管庫で守り、パーミッションとポリシーで使える人を決め、使われた記録を残す |
| SaaS Manager | SaaSとAIのツールの契約とアカウント | 利用の発見、入社と退職に合わせたアクセスの自動化、アクセスの見直し、ライセンスとAIの利用料の管理 |
| Device Trust | 社員の端末 | 端末にエージェントを入れて状態を確かめ、条件を満たさない端末を止める。社員が自分で直せるよう手順を示す |
| Privileged Access | クラウド基盤、データベース、Kubernetesの特権 | 申請の時点で権限を作り、作業の範囲に絞り、終われば自動で消す |
| Credential Broker | 自動で動く処理とAIエージェントに渡すクレデンシャル | 処理の身元を実行時に確かめ、その処理に許されたクレデンシャルだけを渡す |
土台としてのEnterprise Password Manager
5つのうち、Enterprise Password Managerだけはほかの製品の土台になります。クレデンシャルを保管する場所がここにあり、ほかの製品はこの保管庫が守る範囲を外へ広げる形で働くからです。
SaaS Managerは、保管庫のアイテムとブラウザー拡張機能を情報源の1つにして、社員が使っているSaaSを見つけます。Credential Brokerは、保管庫の中のクレデンシャルを実行時に処理へ渡します。Device Trustには、1Passwordのブラウザー拡張機能を入口にして端末を判定する使い方があります。どの製品も、Enterprise Password Managerが社員の端末と保管庫に行き渡っているほど効果が出ます。
守る対象と製品の対応
人、AIエージェント、マシンの3つのアイデンティティーで分けると、製品の受け持ちは次のようになります。
| 製品 | 人 | AIエージェント | マシン |
|---|---|---|---|
| Enterprise Password Manager | 中心 | 自動入力で使わせる範囲を決める | サービスアカウント、環境変数のまとまり |
| SaaS Manager | SaaSのアカウントと利用 | 社員が使うAIのツールと利用料 | 対象外 |
| Device Trust | 社員の端末 | 端末に入ったAIのツールの把握 | 対象外 |
| Privileged Access | 管理者やエンジニアの特権 | エージェントに与える特権 | サービスアカウントの権限の見直し |
| Credential Broker | 対象外 | 実行時のクレデンシャル | 実行時のクレデンシャル |
AIエージェントには3つの製品が関わります。SaaS Managerが社員のAIのツールの利用を見つけ、Credential Brokerがエージェントに渡すクレデンシャルを決め、Privileged Accessがエージェントが入った後に何をしてもいいかを決めます。どれか1つでAIエージェントの管理が完結するわけではありません。
製品どうしの前提条件
製品の中には、別の製品やIDプロバイダーを前提にするものがあります。契約の前に確かめてください。
Device Trust
Device Trustには2つの版があります。Device Trust Coreは1Passwordのブラウザー拡張機能で端末を判定するため、Enterprise Password Managerが前提です。Device Trust ConnectはIDプロバイダーのサインインの流れの中で端末を判定するため、Okta、Microsoft Entra ID、Google Workspaceのいずれかが要ります。Entra IDの場合はP1以上のライセンスが条件です。版ごとに守れる範囲はDevice Trustと組み合わせると何ができるかで扱います。
SaaS Manager
SaaS ManagerとEnterprise Password Managerは別々に契約でき、別々のアカウントとして始まります。両方を使うなら、アカウントのリンク、アプリ検出、SCIM Bridge経由の接続の3つの方法でつなぎます。リンクすると、Enterprise Password Managerの管理者と所有者のメンバーがSaaS Managerでも管理者になります。詳しくはSaaS Managerとの統合で扱います。
Credential Broker
Credential Brokerは、Enterprise Password Managerの保管庫からクレデンシャルを渡す仕組みです。2026年9月時点では、Enterprise Password Managerの契約者に向けて公開プレビューとして提供されています。
管理画面とアカウントの分かれ方
5つの製品は、1つの管理画面にまとまっているわけではありません。Enterprise Password ManagerはPassword Managerと表示される管理コンソールで操作します。SaaS ManagerとDevice Trustは、それぞれ別の管理コンソールを持ちます。管理者のロールもそれぞれの側で決まるため、誰がどの製品を管理するかは製品ごとに決めることになります。
【注意】 「Unified Accessを入れれば管理画面が1つになる」と社内に説明すると、運用の体制を作る段階で食い違いが出ます。製品ごとに管理者を置き、管理者のロールを棚卸しする前提で体制を組んでください。体制の作り方は検討から稼働までの流れと体制で扱います。
2026年9月時点の提供状況
| 製品 | 状況 |
|---|---|
| Enterprise Password Manager | 提供中 |
| SaaS Manager | 提供中 |
| Device Trust | 提供中 |
| Privileged Access | 2026年7月に発表された新しい製品 |
| Credential Broker | 公開プレビュー。GitHub Actionsと、OIDCのトークンを発行できる仕組みに対応 |
Privileged AccessとCredential Brokerは変化の速い段階にあります。検討の時点で、正規販売代理店（デジタルアクセルズ）を通じて最新の状況を確かめてください。位置付けはPrivileged Accessの概要とCredential Brokerの概要で扱います。