Privileged Accessは、クラウド基盤、データベース、Kubernetesなどの特権を、必要になった時点で作り、作業が終われば自動で消す製品です。2026年7月に発表された新しい製品で、2026年9月時点では管理画面の操作手順を確かめられる段階にありません。このページでは、製品ページと発表で確認できる範囲で、常設の特権が残る問題、仕組み、申請と承認、AIエージェントの扱い、監査の記録、検討のときに確かめることを説明します。設定の手順は、確かめられた時点で本ガイドに追加します。
常設の特権が残る問題
特権は、作業のたびに付けられ、作業が終わっても外されないまま残りがちです。障害対応で一時的に付けた管理者のロール、プロジェクトのために作ったデータベースのアカウント、退職した担当者が作ったサービスアカウントの権限などが積み重なり、誰が何をできるのかを説明できない状態になります。
AIエージェントは、この問題を大きくします。エージェントは動かした人の権限を引き継いだり、受け取ったクレデンシャルを持ち続けたりするため、特権を持つ主体が人の数を超えて増えていきます。
Privileged Accessは、この状態を常設の特権をなくすこと（いわゆるゼロスタンディング特権）で解決しようとする製品です。普段は誰も特権を持たず、申請が認められたときだけ、その作業に必要な範囲の権限が現れます。
仕組み
申請が承認されると、対象のシステムが本来持っている権限の仕組みの中に、その作業に絞ったアカウントや権限を作ります。AWSであればIAM、KubernetesであればRBAC、データベースであればその作業専用のアカウント、という形です。作業の時間が終わると、作った権限を自動で消します。
接続を中継する仕組みではありません。踏み台のサーバーやプロキシーを通さず、対象のサーバーごとにエージェントを入れることもありません。利用者は普段通りの方法で対象のシステムにつなぎ、つないだ先で使える権限だけがその時間だけ変わります。
| 観点 | 従来型の特権アクセス管理に多い方式 | Privileged Access |
|---|---|---|
| 特権の持ち方 | 特権のアカウントを保管し、使うときに貸し出す | 普段は存在せず、申請のたびに作る |
| 通信の経路 | 中継のサーバーを通す | 対象のシステムに直接つなぐ |
| 作業の記録 | 中継のサーバーで操作を録画する | 申請、承認、アクセスの記録 |
申請と承認
申請は、SlackやMicrosoft Teams、コマンドラインのツール、MCPを通じたAIのツールから出せます。リスクの低い申請はポリシーで自動的に承認し、リスクの高い申請はPagerDuty、Slack、Microsoft Teams、Jiraなどを通じて承認者に回します。誰が、何に、どれだけの権限を求めているかを判断の材料にします。
導入の前に決めるのは、どの申請を自動で通し、どの申請を人が判断するかの線引きです。開発環境の読み取りは自動、本番のデータベースの書き込みは承認者を通す、といった形で、対象と操作の組み合わせで表にしておくと、ポリシーに落としやすくなります。
AIエージェントの扱い
AIエージェントには、作業ごとに専用の身元を割り当て、その作業に必要な権限だけを持たせます。作業が終われば身元ごと消えます。
加えて、エージェントが申告した作業の意図と、実際に行おうとしている操作を突き合わせる仕組み（IBAC）があります。申告と異なる操作をしようとした場合は、実行の前にアクセスを制限するか取り消します。エージェントは対象のシステムのクレデンシャルを直接受け取らないため、エージェントからクレデンシャルが漏れる経路も小さくなります。
監査の記録
申請、承認、アクセスの各イベントが、誰の操作かとともに記録されます。作業ごとの要約をAIで作る機能と、普段と異なる使い方を検知する機能もあります。
特権の利用は、内部統制の監査で必ず問われる領域です。現在の運用で手作業で集めている「誰がいつ特権を使ったか」の資料を、この記録で置き換えられるかを検討の段階で確かめてください。
検討のときに確かめること
製品が新しいため、契約の前に次の4点を正規販売代理店（デジタルアクセルズ）を通じて確かめてください。
対応する対象のシステム
自社が使うクラウド、データベース、Kubernetesの種類と版が対象になっているかを確かめます。オンプレミスのサーバーの特権も対象にしたい場合は、特に早めに確認が要ります。
削除が失敗したとき
作業の終わりに権限を消す処理が失敗した場合に、どう検知され、誰に知らされるかを確かめます。消えなかった権限は、常設の特権と同じ危険を持ちます。
緊急時のアクセス
Privileged Accessや承認者に連絡がつかない間も、障害対応のための特権を得る手段が要ります。緊急用の管理者のアカウントをEnterprise Password Managerの共有保管庫で管理し、使った後にパスワードを変える、といった従来の手順を残すかどうかを決めておきます。
既存の特権アクセス管理との関係
操作の録画を監査の証跡にしている組織は、その要件をどう満たすかを確かめます。すぐに全てを移す必要はなく、新しく作るクラウドの環境から適用し、既存の仕組みと並べて運用する進め方もあります。