# 特権 ID(管理者用アカウント)とは

特権 ID とは、コンピューターやサービスを管理するための最上位の権限を持つ ID です。サーバーの管理者だけでなく、クラウドや SaaS の管理者アカウント、ドメインや決済の管理画面の ID も含みます。

更新日: 2026-09-18

特権 ID(管理者用アカウント)とは、コンピューターやサービスを管理するために与えられた最上位の権限を持つ ID です。

## 特権 ID とは何か

IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版は、特権を「コンピュータを管理するために与えられた最上位の権限」と書いています。同じガイドラインの本文では、管理者 ID を「管理者権限を保持する ID」と呼んでいます。「コンピュータを管理するため」はサーバーや OS を念頭に置いた言い方ですが、対象をそれに限るとは書いていません。この記事では、クラウドや SaaS(インターネット経由で使う業務ソフト)の管理者アカウントも含めて、管理者用アカウントを特権 ID と呼びます。

## どこまでが特権 ID か

代表的なものを 4 つ挙げます。できることは、各サービスの公式ドキュメントの記述によります。

- クラウドのアカウント全体を握る ID の例が、AWS のルートユーザーです。すべてのサービスと資源に完全にアクセスできます。支払いの一部の作業と、単独のアカウントの解約は、ルートユーザーだけができます。
- SaaS の管理者の例が、Google Workspace の特権管理者です。管理コンソールのすべての機能を使え、他の管理者の管理と、削除した利用者の復元もできます。
- 同じく SaaS の管理者の例が、Microsoft 365 のグローバル管理者です。設定と、データの大半にアクセスできます。全員のパスワードの再設定、契約の購入、ドメインの追加と管理もできます。
- サーバー・OS の管理者の例が、Linux の root と Windows の Administrator です。そのコンピューターのすべての操作ができます。

ドメイン登録や決済の専用サービスの管理画面の ID は、出典の定義には例として出てきません。しかし、上に挙げた最上位の管理者と同じ操作(ドメインの管理・支払い)ができる ID なので、この記事では含めます。

## なぜ特別に扱うのか

理由は、権限が強い分、盗まれたり誤って使われたりしたときの影響が大きいことです。政府機関向けの「政府機関等の対策基準策定のためのガイドライン」(令和 7 年度版)の 7.1.3「権限の管理」を見ます。管理者権限にはあらゆる操作が許可される特権が付いている、と説明しています。その ID とパスワードを第三者に取られると、情報の漏えいや改ざんだけでなく、情報システムの破壊も起こりうる、としています。そのため、限られた人だけに管理者権限を付けることが重要だ、というのが同ガイドラインの整理です。サービス側も同じで、AWS はルートユーザーを日常の作業に使わないよう勧めています。Google Workspace は特権管理者を 2 人以上、Microsoft 365 はグローバル管理者をできるだけ少なくするよう勧めています。

## 共有アカウントとどう違うか

特権 ID は権限の強さで決まり、共有アカウントは使う人の数で決まります。数人で使う管理者アカウントは、特権 ID であり共有アカウントでもあります。Microsoft Entra ID の公式ドキュメントは、複数人で 1 組のユーザー名とパスワードを使う場面の例を挙げています。その一つが、設定・管理・復旧に使う強い権限を持つ 1 つだけのアカウントです。共有アカウント一般の定義は[共有アカウントとは](/guides/shared-accounts/what-is-shared-account)にまとめています。管理の全体像は[管理者用アカウント(特権 ID)の管理](/guides/privileged-access)にあります。


## よくある質問

**特権 ID はサーバーの root だけを指しますか**

いいえ。IPA の「コンピュータを管理するために与えられた最上位の権限」はサーバーや OS を念頭に置いた言い方ですが、対象をそれに限るとは書いていません。クラウドや SaaS の管理者アカウントも含めます。

**SaaS の管理者アカウントも特権 ID ですか**

含めます。Google Workspace の特権管理者は管理コンソールのすべての機能を使え、Microsoft 365 のグローバル管理者はドメインの管理や契約の購入、全員のパスワードの再設定ができます。

**管理者の権限は何人が持つべきですか**

Google Workspace は特権管理者を 2 人以上置くよう勧め、Microsoft 365 はグローバル管理者をできるだけ少なくするよう勧めています。1 人にしないことと、増やしすぎないことの両方が目安です。

## 参考資料

- [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf)
- [内閣官房 国家サイバー統括室「政府機関等の対策基準策定のためのガイドライン(令和 7 年度版)」](https://www.cyber.go.jp/pdf/policy/general/guider7_9.pdf)
- [AWS Identity and Access Management ユーザーガイド「AWS account root user」](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)
- [Google Workspace 管理者ヘルプ「Pre-built administrator roles」](https://knowledge.workspace.google.com/admin/users/prebuilt-administrator-roles)
- [Microsoft Learn「About administrator roles in the Microsoft 365 admin center」](https://learn.microsoft.com/en-us/microsoft-365/admin/add-users/about-admin-roles)
- [Microsoft Learn「Sharing accounts and credentials - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/users/users-sharing-accounts)

## Junify の場合

**人手で続けると** 管理者用アカウントを誰に持たせるかを申請と承認で回し、共有のまま残るものは使うたびに記録し、その記録を管理者以外が定期的に点検することになります。

**Junify なら** Junify は、クラウドや SaaS の管理コンソールの管理者用アカウントを、パスワードを使う人が誰も知らない状態で使わせる仕組みです。管理者が ID とパスワードを登録し、担当者は自分のスマホで本人確認をしてクリックするだけでログインします。誰が・いつ・どのコンソールに入ったかは一人ひとり残ります。サーバーや OS の管理者 ID は対象外です。

Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。

- [登録不要の体験デモを見る](https://www.junify.jp/bpo/try)
- [30 分デモを予約する](https://www.junify.jp/bpo/demo)

## 同じテーマの記事

- [AWS のルートユーザー・管理者アカウントを複数人で使うときの管理](/guides/privileged-access/aws-root-and-admin-accounts): AWS は、ルートユーザーを日常の作業に使わず、それにしかできない作業に限るよう勧めています。日常の管理は IAM Identity Center の個人の ID で行い、ルートユーザーは二段階認証(MFA)を付けて保管し、記録を残します。
- [SaaS の管理者用アカウントを管理する方法の比較](/guides/privileged-access/comparison-of-privileged-account-methods): 台帳と貸出の記録、ID 管理サービスの代わりの入力、特権 ID 管理(PAM)の製品、アクセス管理ツールの 4 つを、パスワードを知るか、記録の単位、退職時、二段階認証、ログイン後の管理、前提、向く規模の 7 つで比べます。
- [Google Workspace・Microsoft 365 の特権管理者アカウントの管理](/guides/privileged-access/google-workspace-microsoft-365-admins): 最上位の管理者(特権管理者・グローバル管理者)を少なくし、役割に応じた管理者権限に分け、管理者に二段階認証を必須にし、緊急用のアカウントを分けます。Google と Microsoft の公式ドキュメントが勧めることの整理です。