# 共有アカウントの管理

共有アカウントは、1 つの ID とパスワードを複数人で使う状態です。個人に分けられるものは分け、残るものは誰が使ったかを残せる方法で管理します。

更新日: 2026-09-17

共有アカウントがある限り、退職のたびにパスワードを変えて配り直す手間と、誰が使ったかを説明できない状態の両方が残ります。

## 共有アカウントとは何か

共有アカウントとは、1 つのサービス上の 1 つのアカウント(ID とパスワードの組)を複数の人が使う状態です。定義と法令上の位置づけは [共有アカウントとは](/guides/shared-accounts/what-is-shared-account) にまとめています。

## なぜ生まれ、なぜなくならないか

生まれる理由はサービス側の設計にあります。Microsoft Entra ID の公式ドキュメントは、1 組のユーザー名とパスワードを複数人で使う場面を 2 つ挙げています。企業の SNS アカウントのようなアプリケーションと、Microsoft 365 の管理者アカウントのような、強い権限を持つ 1 つだけのアカウントです。人数分のアカウントを作れないサービスでは、共有が唯一の使い方になります。

なくならない理由も同じところにあります。サービス側の仕組みは、利用者側では変えられません。そのため、個人アカウントに分けられるのは、サービス側にその仕組みがあるものに限られます。SNS の公式アカウントや、一度のログインで複数のサービスに入れる仕組み(SSO)に載らない部門ツールの管理者アカウントは、分けたくても分けられないまま残ります。

## 何が困るか

困りごとは 5 つに分かれます。

- 退職や異動のあとも、辞めた人がログインできる状態が続きます。パスワードを知っている人は、変えて配り直すまで誰でも入れます。
- 誰が操作したかを説明できません。サービス側の記録には、アカウントの名前しか残らないからです。
- 担当者が不在の日にログインできません。確認コードは、登録した 1 台のスマホに表示されるか、登録した電話番号にしか届きません。
- 私物端末にパスワードや履歴が残ります。ブラウザーの保存機能やメモに、共有パスワードがそのまま入るためです。
- 使っていないアカウントに気づけません。誰が使っているかが、台帳にも記録にも残っていないからです。

このうち退職と記録は、法令やガイドラインの要求と直接ぶつかります。個人情報保護委員会のガイドライン(通則編)は、個人データを扱う情報システムの利用者を「識別した結果に基づいて認証する」ことを求めています。誰かを確かめたうえでログインさせる、という意味です。IPA の「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版は、共有 ID をやむを得ず使う場合に、利用した人を特定できる仕組みを求めています。どちらも共有そのものを禁じてはいません。しかし、誰が使ったかを特定する手段を用意する責任は、利用者側に残ります。

## 管理の選択肢

複数人で使う方法は 4 つに分けられます。ID 管理サービス(Okta、Microsoft Entra ID など。社員のアカウントをまとめて管理し、一度のログインで複数のサービスに入れるようにするサービス)を使っているかどうかで、選べる方法が変わります。

| 方法 | できること | 残る限界 | 向く場面 |
| --- | --- | --- | --- |
| 手作業の台帳と定期変更 | 道具なしで始められ、誰が知っているかを台帳で追える | 全員がパスワードを知り、変更のたびに配り直す | 使う人が数人のとき |
| パスワードマネージャーでの共有 | 保管庫を共有し、入力を自動化できる | 自動入力できる人はパスワードを使える | 配布と保管を整えたいとき |
| ID 管理サービスが代わりに入力(Okta の SWA、Entra ID の password-based SSO) | パスワードを見せずにログインさせる | 対象は ID 管理サービスにアカウントのある人 | 使う人が全員そこにアカウントを持つとき |
| アクセス管理ツール | 担当者に代わってパスワードを入力する | 対象アプリと端末の条件は製品ごとに確認する | ID 管理サービスにアカウントのない人を含むとき |

誰が使ったかの記録は、表の上 2 行と下 2 行で分かれます。手作業とパスワードマネージャーでは、サービス側の記録は共有アカウントの名前のままです。ID 管理サービスとアクセス管理ツールは、その手前で本人単位の記録を残します。パスワードマネージャーには、見られる範囲を絞れる製品もあります。端末の条件も方法ごとに違い、手作業は端末を問わず、パスワードマネージャーは保管庫を開ける端末で使い、ID 管理サービスはそのサービス側の設定で決まります。Entra ID の代わりの入力は、共有アカウントを使う利用者ごとに EMS または Entra ID P1 / P2 の契約プランが前提です。

管理者用アカウント(強い権限を持つ ID)の利用申請・承認と操作の記録を仕組みで行う特権 ID 管理(PAM)は、[管理者用アカウント(特権 ID)の管理](/guides/privileged-access)で扱います。パスワード自体を担当者に配る道具(共有機能つきのパスワードマネージャーなど)は、上のパスワードマネージャーの行に含めます。

Okta の Secure Web Authentication(SWA)は、Okta にログインするだけで、ほかの Web アプリにも入れるようにする Okta の機能です。ID 管理サービスに認証を任せる方式(SAML などの規格でつなぐ方式)に対応していないアプリが対象です。管理者がアプリの ID とパスワードを設定でき、レポートでは誰がいつどのアプリにアクセスしたかを確認できます(公式ヘルプ)。Entra ID の password-based SSO は、Entra ID にパスワードを預けて代わりに入力させる機能です。共有アカウントを使う権限を持つ利用者は、パスワードを見ずに、ログインの手続きの中で使います。管理者はアクセスの付与と取り消しを行い、誰がいつアクセスしたかをサインインの記録(サインインログ)で確認できます(公式ドキュメント)。見られる範囲を絞れるパスワードマネージャーのうち、Bitwarden は、隠したパスワードも自動入力では使えると公式ヘルプに明記しています。詳しくは [パスワードマネージャーとは](/guides/shared-accounts/what-is-password-manager) で扱います。

## 何から始めるか

最初にするのは棚卸しです。サービス名、アカウントの ID、パスワードの保管場所、使っている人、管理者、二段階認証の受け取り先、最後に確認した日を一覧にします(最小の 7 項目。全項目は[棚卸しの記事](/guides/shared-accounts/shared-account-inventory)に)。この一覧がないと、次の 2 つの判断ができません。

次に、個人アカウントに分けられるものを分けます。利用者の枠を追加できるサービス、管理者権限を複数人に与えられるサービス、部門の代表アドレスは共有をやめられます。Microsoft 365 の共有メールボックスは、各自が自分のアカウントでアクセスする前提で作られています。公式ドキュメントには、共有メールボックス自体のアカウントではサインインしないようにと書かれています。代表アドレスをこの形にすれば、メールの共有と個人単位の認証を両立できます。

最後に、残るものの扱いを決めます。上の表から、使う人の範囲(ID 管理サービスにアカウントがあるか)、要る記録の細かさ(アカウント単位で足りるか、本人単位が要るか)、端末の条件(会社支給か私物か)で選びます。定期変更を続けるかどうかは、NIST SP 800-63B Revision 4の考え方が判断材料になります。同文書は、サービスを提供する側は利用者に定期的なパスワード変更を求めてはならず、パスワードが盗まれたなどの証拠がある場合は必ず変更させる、としています。共有アカウントで二段階認証を複数人が使うときの問題は [二段階認証(二要素認証)とは](/guides/shared-accounts/what-is-two-step-verification) で扱います。


## このテーマの記事

- [ブラウザーのパスワード保存を業務で使ってよいか](/guides/shared-accounts/browser-saved-passwords-at-work): 個人アカウントのパスワードを、会社が管理するブラウザーの設定で、1 人が使う端末に限って保存するなら選択肢になります。共有アカウント、私物端末、個人アカウントへの同期が絡む場合は避けます。管理者の設定で保存を止められます。
- [共有アカウントを複数人で安全に使う方法の比較](/guides/shared-accounts/comparison-of-shared-account-methods): 手作業、パスワードマネージャーの共有、ID 管理サービスによる代わりの入力、アクセス管理ツールの 4 つを、パスワードを知るか、記録の単位、退職時、二段階認証、ログイン後の管理、前提、向く規模の 7 つで比べます。
- [退職者が出るたびにパスワードを変える運用の限界](/guides/shared-accounts/password-change-on-every-departure): 一度知られたパスワードは取り消せないため、退職のたびに変える運用には理由があります。限界は、変更後の配り直しと保存先の更新にかかる手間と、誰が知っているかの一覧がないまま起きる抜け漏れです。
- [パスワード管理規程のテンプレートと書き方](/guides/shared-accounts/password-policy-template): 規程に入れる項目は、適用範囲、パスワードの条件、保管、共有の禁止と例外、共有アカウント、二段階認証、変更、退職時の手続き、違反時の扱い、見直しの 10 項目です。各条を IPA と個人情報保護委員会の要求に対応づけ、文例を示します。
- [パスワードの定期変更はもう不要か(NIST SP 800-63B の考え方)](/guides/shared-accounts/periodic-password-change): NIST SP 800-63B は、サービス側が利用者に定期変更を求めないよう定め、変更を必須にするのは盗まれた証拠があるときとしています。複数人で使う共有アカウントは、知っている人が変わるたびに変更が要ります。
- [共有アカウントの棚卸しの手順と台帳の項目](/guides/shared-accounts/shared-account-inventory): 共有アカウントの棚卸しは、サービスごとに誰がパスワードを知っていて誰が使えるかを一覧にする作業です。見つけ方、台帳の項目、分ける・残す・廃止するの判定、更新のきっかけを順に示します。
- [共有アカウントの二段階認証を複数人で使うときの問題と選択肢](/guides/shared-accounts/sharing-two-step-verification): 共有アカウントの二段階認証は、コードが 1 人のスマホにしか出ないか、登録用の QR コードを配って全員が出せるかのどちらかになります。方式ごとに起きる問題と、不在と退職に備える選択肢を整理します。
- [パスワードをスプレッドシートで管理する会社が最初に直すこと](/guides/shared-accounts/spreadsheet-password-management): 最初に直すのは、そのシートを開ける人の範囲です。次に台帳としての項目を整え、最後にパスワードの値だけを別の保管場所へ移します。一覧としてのスプレッドシートは残せます。
- [Slack・メールでパスワードを送るのをやめる方法](/guides/shared-accounts/stop-sending-passwords-in-chat): 送ったパスワードは検索で見つかり、転送や書き出しで広がり、端末と退職者のアカウントに残ります。やめるには、先に別の渡し方を用意し、そのうえで本文に書かないルールを決めます。
- [パスワードマネージャーとは](/guides/shared-accounts/what-is-password-manager): パスワードマネージャーは、ID とパスワードを他人が読めない形で保管し、ログイン画面に自動で入力するソフトです。共有機能で配布は整いますが、共有した相手はパスワードを使える状態になります。
- [共有アカウントとは](/guides/shared-accounts/what-is-shared-account): 共有アカウントとは、1 つのサービスの 1 つの ID とパスワードを複数の人が使う状態です。サービス側の記録には誰が操作したかが残らないため、別の手段で人を特定する必要があります。
- [二段階認証(二要素認証)とは](/guides/shared-accounts/what-is-two-step-verification): 二段階認証とは、パスワードに加えて 2 つ目の確認(認証アプリのコード、SMS、セキュリティキーなど)を求めるログイン方式です。本人が持つものを前提にした仕組みなので、共有アカウントで複数人が使うと本人を特定する意味が失われます。
- [共有アカウントを個人アカウントに分けられないケースの整理](/guides/shared-accounts/when-accounts-cannot-be-split): 原則は 1 人 1 アカウントです。それでも、サービスがアカウントを 1 つしか持てない、公式アカウントそのもの、管理者アカウントが 1 つ、外部の人に発行できない、といった場合は共有が残ります。残すものに何を求めるかを整理します。

## よくある質問

**共有アカウントは全部なくすべきですか**

個人アカウントに分けられるものは分けるのが先です。それでも 1 つしか作れない管理者アカウントや公式 SNS は残るので、残るものの管理方法を決めます。

**パスワードを定期的に変えれば安全ですか**

変えた後のパスワードを全員に配り直す以上、知っている人の範囲は変わりません。NIST SP 800-63B は定期変更を求めず、盗まれた証拠があるときは必ず変更させるとしています。

**台帳はどんな項目から作ればよいですか**

サービス名、アカウントの ID、パスワードの保管場所、使っている人、管理者、二段階認証の受け取り先、最後に確認した日から始めると、次に決めることが見えます。

**Okta や Entra ID があれば共有アカウントは管理できますか**

Okta の SWA や Entra ID の password-based SSO に ID とパスワードを預ければ、直接つなげないアプリでも代わりに入力できます。契約プランと対象アプリの条件は公式ヘルプで確認します。

## 参考資料

- [個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和 8 年 6 月一部改正)](https://www.ppc.go.jp/files/pdf/260614_guidelines01.pdf)
- [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版(2026 年 3 月)](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf)
- [Microsoft Learn「Sharing accounts and credentials - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/users/users-sharing-accounts)
- [Microsoft Learn「About shared mailboxes in Microsoft 365」](https://learn.microsoft.com/en-us/microsoft-365/admin/email/about-shared-mailboxes)
- [Okta Help Center「About Secure Web Authentication」](https://help.okta.com/oie/en-us/content/topics/apps/apps-about-swa.htm)
- [Okta Help Center「Report types」](https://help.okta.com/oie/en-us/content/topics/reports/report-types.htm)
- [Bitwarden Help Center「Collection permissions」](https://bitwarden.com/help/collection-permissions/)
- [1Password Support「Create and share vaults」](https://support.1password.com/create-share-vaults-teams/)
- [NIST Special Publication 800-63B Revision 4「Digital Identity Guidelines: Authentication and Authenticator Management」](https://pages.nist.gov/800-63-4/sp800-63b.html)

## Junify の場合

**人手で続けると** 共有アカウントを安全に使い続けるなら、誰がパスワードを知っているかの一覧を保ち、人が入れ替わるたびに変えて配り直し、同じ ID で誰が操作したかを別に記録することになります。

**Junify なら** Junify は、分けられずに残った共有アカウントを、担当者がスマホで本人確認をしてから使う形にする仕組みです。管理者が ID とパスワードを登録し、担当者はクリックするだけでログインするため、パスワードは担当者に渡らず、共有のままでも誰が・いつ使ったかは一人ひとり残ります。Okta や Entra ID はそのままで、そこに載らないアカウントだけを登録できます。

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

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