パスワードの文字数や変更頻度といった運用ルールを定めるパスワードポリシーは、不正アクセスを防ぐ土台となる取り組みです。一方で「何文字にすべきか」「定期的な変更は必要か」といった推奨値は、近年の考え方の変化によって、かつての常識から大きく見直されています。従来のまま運用を続けると、かえって安全性を下げてしまう項目もあります。
自社のパスワードポリシーを決める、あるいは見直すとき、どの項目を・どの値に設定すればよいのでしょうか。本記事では、パスワードポリシーで決める設定項目の全体像と、各項目の推奨値を整理します。あわせて、NISTや総務省が示す最新の考え方、Active Directory・Microsoft Entra IDでの設定、自社ポリシーを策定する手順までを解説します。
読み終えたときには、長さ・文字種・変更頻度などの各項目について、出所の確かな推奨値をもとに自社のパスワードポリシーの草案を書き起こせる状態を目指します。パスワード単体に頼りすぎないための次の一手もあわせて紹介します。
目次
一括ダウンロードする
パスワードポリシーとは｜何を決めるルールか
パスワードポリシーとは、組織の情報システムやクラウドサービスで使うパスワードについて、満たすべき条件や運用ルールをまとめた規程です。最低何文字以上にするか、どのような文字を含めるか、どのくらいの頻度で変更するかといった項目をあらかじめ定め、利用者が推測されやすい弱いパスワードを使うことを防ぎます。
Active DirectoryやMicrosoft Entra ID、各種クラウドサービスの多くは、パスワードポリシーをシステム側で強制できる設定項目を備えています。そのため、まず「どの項目を・どの値に設定するか」を決め、それをシステムの設定に落とし込むという流れになります。
ポリシーを構成する設定項目の全体像
パスワードポリシーで一般的に定める設定項目は、次のとおりです。自社で決めるべき項目を取りこぼさないよう、まず全体像を押さえておきましょう。
| 内容 | |
|---|---|
| 長さ | 最低何文字以上を必須とするか。桁数の上限を設ける場合もあります。 |
| 文字種（複雑性） | 英大文字・英小文字・数字・記号のうち、どの種類をいくつ含めることを必須とするか。 |
| 有効期限（定期変更） | パスワードを変更するまでの最大日数。期限を設けないという選択もあります。 |
| パスワード履歴 | 過去に使ったパスワードの再利用を何世代ぶん禁止するか。 |
| 禁止パスワード | 辞書に載る単語や漏えい済みのパスワードなど、使用を拒否する文字列。 |
| 連続失敗への対策 | ログインに連続で失敗した場合に、認証を一時的にロック・制限する回数。 |
| 最小使用日数 | 変更後、次に変更できるようになるまでの日数。履歴をすり抜ける連続変更を防ぎます。 |
これらのうち、どの項目をどの値にするかで、パスワードポリシーの強度と使いやすさのバランスが決まります。次章では、各項目の今の推奨値を具体的な数字で見ていきます。
ポリシーを定める目的とリスク
パスワードポリシーを定める目的は、推測やツールによる割り出しに強いパスワードを利用者に使ってもらい、不正アクセスやアカウントの乗っ取りを防ぐことにあります。ルールがないと、利用者はIDと同じ文字列や誕生日など、覚えやすく推測されやすいパスワードを選びがちです。
システムごとにパスワードの基準がばらばらだと、統制が効かず、弱いパスワードが残り続けます。パスワードポリシーで組織としての基準をそろえることが、こうしたリスクを抑える第一歩になります。一方で、ルールを厳しくしすぎると、かえって安全性が下がる場合もあります。その理由は「なぜ『従来の常識』は変わったのか」で詳しく見ていきます。
設定項目ごとの推奨値｜従来の常識と今の推奨
ここからは、各設定項目を具体的にどの値にすればよいかを見ていきます。米国国立標準技術研究所（NIST）が示す最新のガイドラインでは、かつて一般的だったルールの一部が見直されています。従来の常識と今の推奨を並べると、次のように整理できます。
| 従来よく見られたルール | 今の推奨（NIST SP 800-63B-4） | |
|---|---|---|
| 長さ | 8文字程度以上 | 単独利用は15文字以上／多要素認証と併用する場合は8文字以上（上限は64文字以上を許容） |
| 文字種（複雑性） | 英大文字・小文字・数字・記号の混在を必須 | 混在を必須とするルールは課さない（長さを優先） |
| 有効期限（定期変更） | 90日ごとなど定期的に変更させる | 求めない（漏えい・侵害の証拠がある場合のみ変更） |
| パスワード履歴 | 過去数世代の再利用を禁止 | NIST は世代数を規定していない（定期変更をしない運用では重要度が下がる） |
| 禁止パスワード | 任意（設定しないことも多い） | 漏えい済み・脆弱なパスワードをブロックリストと照合して拒否 |
| 連続失敗への対策 | 数回の失敗でアカウントをロック | 連続失敗を100回以下に制限（超過した認証器は無効化し、再設定するまで使えない） |
| 最小使用日数 | 履歴のすり抜けを防ぐために設定することがある | NIST に規定なし（定期変更を前提としないため設ける必要は乏しい） |
※NISTの要件はSP 800-63B-4（2025年最終版）に基づく。従来のルールは一般的に見られた運用例。
長さについては、NISTは単独で使うパスワードを15文字以上とするよう求めています。情報処理推進機構（IPA）も、安全なパスワードの条件として「数字・英大文字・英小文字を組み合わせてできるだけ長い文字数（15桁程度）で構成されている」ことを挙げています。15文字前後という目安は、国内外の公的な見解で共通しています。
多要素認証と組み合わせて使うパスワードであれば、8文字以上まで短くしてもよいとされています。
文字種の複雑性については、大文字・小文字・数字・記号の混在を必須とするルールは、今のNISTの考え方では課さないことになっています。複雑さよりも長さを確保するほうが、推測やツールによる割り出しに強くなるためです。定期変更も、漏えいなどの兆候がない限りは不要とされています。
出典・参考資料（2件）
全体像の表で挙げた「連続失敗への対策」について、NISTは上限値として「100回以下」を示しています。これは上限であり、より少ない回数に厳しくするのは差し支えありません。数回の失敗で即ロックする従来のアカウントロックとは考え方が異なり、総当たり的な推測攻撃を抑えられれば十分という立場です。
一方で、Active DirectoryやMicrosoft Entra IDなど製品側には、より少ない失敗回数でロックする設定が既定・推奨として用意されているものもあります。両者はねらいが異なるため、どちらかが誤りというわけではありません。
自社のポリシーで何回に設定するか迷う場合は、総当たり攻撃を抑えられれば十分という考え方に立ち、正規の利用者が打ち間違いで頻繁にロックされない範囲で回数を定めるとよいでしょう。
避けるべき弱いパスワードの例
どれだけポリシーを整えても、利用者が推測されやすいパスワードを選べば意味がありません。総務省やIPAは、次のようなパスワードを避けるよう示しています。
- IDと同じ文字列、自分や家族の名前・電話番号・生年月日
- 辞書に載っている一般的な英単語ひとつだけ（password、baseball、monkey、dragon など）
- 同じ文字の繰り返しや単純な並び（aaaa、0000、abcd、123456 など）
- キーボードの配列をそのまま使った文字列（asdf、qwerty など）
- 複数のサービスで同じパスワードを使い回す
覚えやすく、かつ推測されにくいパスワードを作るには、意味のつながらない複数の単語を数字でつなげる方法が有効です。総務省も「無関係な（文章にならない）複数の単語をつなげたり、その間に数字列を挟んだりしたもの」であれば、推測されにくく覚えやすいパスワードを作れると説明しています。
なぜ「従来の常識」は変わったのか（NISTの考え方・総務省）
複雑性の強制や90日ごとの定期変更は、長く一般的なルールでした。これらが見直された背景には、「ルールを厳しくするほど安全になるとは限らない」という実態があります。
文字種の混在を必須にすると、利用者は「Password1!」のような、ルールは満たすが推測されやすいパターンを選びがちです。また、定期的な変更を求めると、末尾の数字だけを増やすといった規則的な変え方になったり、覚えきれずに使い回しが起きたりします。NISTはこうした副作用を踏まえ、複雑性の強制を課さず、定期変更も求めない方針に切り替えました。
Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.
出典：NIST SP 800-63B-4 Digital Identity Guidelines §3.1.1.2｜米国国立標準技術研究所（NIST）
Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised.
要点は2つで、文字種の混在などの構成ルールを課してはならないこと、そして定期的な変更を求めてはならず、漏えいの証拠があるときにのみ変更を強制すること、を示しています。
日本でも同じ方向が示されています。総務省は、定期的な変更を求められることがあるものの、サービス側から流出した事実がなければ変更の必要はないと明記しています。
利用するサービスによっては、パスワードを定期的に変更することを求められることもありますが、実際にパスワードを破られアカウントが乗っ取られる等のサービス側から流出した事実がない場合は、パスワードを変更する必要はありません。むしろ定期的な変更をすることで、パスワードの作り方がパターン化し簡単なものになることや、使い回しをするようになることの方が問題となります。
出典：安全なパスワードの設定・管理｜総務省 国民のためのサイバーセキュリティサイト
総務省も、内閣サイバーセキュリティセンター（NISC）が「定期変更する必要はなく、流出時に速やかに変更する」考え方を示していると紹介しています。自社のパスワードポリシーで定期変更を残すかどうかは、これらの公的な見解を踏まえて判断するとよいでしょう。
製品・OSでの設定とNIST新基準とのギャップ（Active Directory / Microsoft Entra ID）
決めたパスワードポリシーは、実際の製品やOSの設定に落とし込むことになります。ここで注意したいのは、代表的な製品の初期設定（既定値）が、必ずしもNISTの最新の推奨値と一致しているわけではない点です。Active DirectoryとMicrosoft Entra IDの既定値を、NISTの推奨値と並べて見てみます。
| NIST SP 800-63B-4 | Active Directory 既定ドメインポリシー | Microsoft Entra ID 既定 | |
|---|---|---|---|
| 長さ（最小） | 15文字（単独で使う場合） | 7文字 | 8文字（最大256文字） |
| 文字種（複雑性） | 混在の強制は課さない | 複雑性要件 有効 | 4カテゴリ中3種を必須 |
| 有効期限（定期変更） | 求めない（侵害時のみ変更） | 最長42日 | 既定90日 |
※各社公式ドキュメント（2026年11月時点）の既定値。
いずれの製品も、既定値は複雑性の強制や定期変更を前提としており、長さを重視して定期変更を求めないNISTの推奨とは方向が異なります。そのため、既定値のまま運用するか、自社のポリシーに合わせて調整するかを判断する必要があります。特に長さの下限を、既定の7〜8文字から推奨の15文字へ引き上げるかどうかが論点になります。
判断の手がかりとして、Microsoft自身も有効期限ポリシーの扱いを見直しています。同社はパスワードの有効期限ポリシーについて、現代の対策と比べて効果が薄いとして、推奨するセキュリティベースラインには含めていないと説明しています。製品の既定値が必ずしも最善とは限らない、という前提で設定を検討するとよいでしょう。
設定する場所は製品ごとに異なります。Active Directoryでは、グループポリシー管理のアカウントポリシーで長さ・複雑性・有効期限などを定めます（コンピューターの構成＞Windowsの設定＞セキュリティの設定＞アカウントポリシー＞パスワードのポリシー）。
Microsoft Entra IDでは、禁止パスワードや連続失敗のロックをMicrosoft Entra管理センターのパスワード保護で設定し、有効期限などアカウント全体の方針はMicrosoft 365管理センター側で扱います。
製品ごとの細かな操作手順は各公式ドキュメントに譲りますが、まずは上記の既定値とのギャップを把握し、どの値に合わせるかを先に決めておくと、設定作業がぶれません。
出典・参考資料（4件）
パスワードポリシーの策定・社内規程化の手順
ここまでの内容を踏まえ、自社のパスワードポリシーを策定する手順を整理します。はじめて定める場合も、既存のポリシーを見直す場合も、次の流れで進めると漏れがありません。
まず、対象範囲を決めます。社内システム・クラウドサービス・Active Directoryなど、どのアカウントにポリシーを適用するかを洗い出します。
次に、設定項目ごとの値を決めます。長さは単独利用で15文字以上、多要素認証と併用する場合は8文字以上を目安とします。文字種の混在強制と定期変更は原則として設けず、漏えい済みパスワードの拒否と連続失敗への制限を取り入れます。これらの値に、NIST・総務省・IPAの考え方を根拠として添えておくと、社内の合意形成がしやすくなります。
続いて、決めた値を規程文書に落とし込み、Active DirectoryやMicrosoft Entra IDなど実際のシステムの設定に反映します。製品の既定値とポリシーがずれている場合は、前章の対応表を参照して調整します。最後に、利用者へ周知し、運用のなかで定期的に見直す体制を整えます。
策定時に最低限そろえておきたい項目は、次のとおりです。自社のポリシー草案を書き起こす際のチェックリストとして活用してください。
- 適用範囲（対象システム・アカウント）
- 長さの下限（単独利用15文字以上／多要素認証併用8文字以上を目安）と上限
- 文字種（複雑性）の扱い（混在を必須にするか）
- 有効期限（定期変更）の有無（漏えい時の変更手順を含む）
- パスワード履歴（再利用を禁止する世代数を設けるか）
- 最小使用日数（設けるか）
- 漏えい済み・脆弱なパスワードの拒否と、連続失敗への制限
- 使い回し禁止の周知と、多要素認証の併用方針
一括ダウンロードする
パスワードに頼りすぎない対策（多要素認証・パスワードレス・ID基盤）
ここまで見てきた推奨値でポリシーを整えても、パスワードだけに頼る限り、漏えいや使い回しのリスクはゼロにはなりません。そこで有効なのが、パスワードに加えて本人確認の要素を増やす多要素認証（MFA）や、パスワード自体を使わないパスワードレス認証です。
さらに、複数のサービスへのログインを一度の認証にまとめるシングルサインオン（SSO）を備えたID基盤（IDaaS）を使うと、利用者が管理するパスワードの数そのものを減らせます。
ID基盤を導入すると、サービスごとに個別のパスワードを覚える必要が減り、管理者のパスワード再発行対応の負担も軽くなります。ここでは、SSOや多要素認証・パスワードレス認証を備えた代表的なID基盤を紹介します。
| サービス名 | CloudGate UNO | HENNGE One | トラスト・ログイン byGMO |
|---|---|---|---|
| SSO（認証の集約） | ● | ● | ● |
| 多要素認証（MFA） | ● | ● | ● |
| パスワードレス（FIDO2/パスキー） | ◎全プランで無制限 | △公式に明記なし | ●有料のSSOプロで対応 |
| 無料プラン・スモールスタート | △30日間の無料体験 | ×無料プランなし・最低200ID | ◎無料プランあり |
| 特徴（一言） | 全プランでパスキー無制限。国産の自社開発で日本語サポート | ID統制とメール・端末対策を統合。上場企業の約2割が利用 | 無料から始められるIDaaS。電子認証局が運営 |
| 詳細情報 | 公式資料を見る | サービス詳細を見る | サービス詳細を見る |
1. CloudGate UNO（株式会社インターナショナルシステムリサーチ）
CloudGate UNOは、株式会社インターナショナルシステムリサーチが自社開発するクラウド型のID基盤です。シングルサインオン・多要素認証・アクセス制限・ID管理を一つの画面で扱え、パスキー（FIDO2）によるパスワードレス認証をすべてのプランで無制限に利用できます。
FIDO2準拠のパスワードレス認証を2019年から提供してきた実績があり、直近1年間で年間1億回以上の認証、稼働率99.99%を公表しています。国産の自社開発で日本語サポートを受けられる点も、国内企業にとって選びやすい材料です。一度の認証で複数のクラウドサービスにアクセスできるため、利用者がサービスごとにパスワードを管理する手間を減らせます。
パスワードレス認証への切り替えが管理者側の負担に与える影響について、提供元のインターナショナルシステムリサーチは、導入現場で見られた変化を次のように説明しています。
導入と同時にパスワードレス認証に切り替えた企業では、IT部門の業務の約20%を占めていたパスワード関連のヘルプデスク業務が「0%」になったという事例があります。
2. HENNGE One（HENNGE株式会社）
HENNGE株式会社が提供するHENNGE Oneは、ID統制にメール・エンドポイントセキュリティを組み合わせた統合基盤です。シングルサインオン・多要素認証・アクセス制御を軸に、多数のクラウドサービスへのログインを集約できます。アクセス管理を担うIdentity Editionでは、多要素認証とアクセス制御を組み合わせて、ログイン時の本人確認を強化できます。
契約ユーザー数は300万を超え、2026年3月末時点で3,731社が利用し、東京証券取引所の上場企業の約2割が導入しています。連携するクラウドサービスの数が増えても、シングルサインオンの利用自体に追加費用がかからない料金設計のため、利用サービスが多い企業でも導入しやすい点が特徴です。
3. トラスト・ログイン byGMO（GMOグローバルサイン株式会社）
電子認証局を運営するGMOグローバルサイン株式会社が手がけるトラスト・ログイン byGMOは、企業向けのクラウド型ID基盤です。シングルサインオン・ID管理・多要素認証・アクセス制限を備え、SSOへ一度パスキー（FIDO2）で認証すれば、登録したクラウドサービス全体にアクセスできます。
アカウント数・連携アプリ数とも無制限の無料プランがあり、初期費用をかけずにシングルサインオンとID管理を始められます。まずは小さく試してから本格導入を検討したい企業に向いています。電子証明書・電子認証を本業とするセキュリティ事業者が提供している点も安心材料です。
ここで挙げた3サービスは一例です。選ぶ際は、パスワードレス（パスキー）への対応範囲・無料やスモールスタートの可否・サポート体制や自社の利用規模との相性を軸に比べると絞り込みやすくなります。SSOや多要素認証・パスワードレス認証に対応するID基盤をより広く比べ、機能・料金・選び方や導入事例まで確認して自社に合うものを見極めたい場合は、以下の比較記事が参考になります。
まとめ
パスワードポリシーでは、長さ・文字種・有効期限・履歴・連続失敗への対策・禁止パスワードといった項目を定めます。近年は、文字種の混在強制や定期変更を見直し、長さを重視して漏えい済みパスワードを拒否する考え方が、NISTや総務省・IPAといった公的な見解で共通しています。
自社のポリシーを定めるときは、Active DirectoryやMicrosoft Entra IDの既定値がこうした最新の推奨値とずれている点に注意し、本記事のチェックリストを手がかりに草案を書き起こしてみてください。あわせて、多要素認証やパスワードレス認証、ID基盤を取り入れることで、パスワードそのものに頼りすぎない運用に近づけられます。
一括ダウンロードする
よくある質問（FAQ）
Q. パスワードポリシーとは何ですか？
A. パスワードポリシーとは、組織で使うパスワードが満たすべき条件や運用ルールをまとめた規程です。長さ・文字種（複雑性）・有効期限（変更頻度）・履歴・連続失敗への対策・禁止パスワードといった項目を定め、利用者が推測されやすい弱いパスワードを使うことを防ぎます。
Active DirectoryやMicrosoft Entra ID、各種クラウドサービスのように、システム側で強制できる設定項目として備わっていることが一般的です。
Q. パスワードポリシーで定期的なパスワード変更は本当に不要ですか？
A. パスワードポリシーでの定期変更は、漏えいや侵害の兆候がない限り不要というのが、現在の公的な見解です。NIST SP 800-63B-4は定期変更を求めないよう明記し、総務省も、サービス側から流出した事実がなければパスワードを変更する必要はないとしています。
むしろ定期変更を求めると、パスワードの作り方がパターン化したり使い回しを招いたりするため、漏えいが判明したときに速やかに変更する運用が推奨されています。
出典・参考資料（2件）
Q. パスワードポリシーの文字数は何文字に設定するのが正解ですか？
A. パスワードポリシーの長さは、単独で使う場合は15文字以上、多要素認証と併用する場合は8文字以上が目安です。NIST SP 800-63B-4が示す基準で、IPA（情報処理推進機構）も安全なパスワードの条件として15桁程度を挙げています。文字種を増やすよりも長さを確保するほうが、推測やツールによる割り出しに強くなるため、まずは下限の文字数を十分に取ることが重要です。
出典・参考資料（2件）
Q. パスワードポリシーで文字種（大文字・数字・記号）の混在は必須にすべきですか？
A. パスワードポリシーで文字種の混在を必須とするルールは、今のNISTの考え方では課さないことが推奨されています。混在を強制すると、利用者は「Password1!」のようにルールは満たすが推測されやすいパターンを選びがちになるためです。
複雑性よりも長さを優先するのが基本方針となります。ただしMicrosoft Entra IDなど製品の既定では4カテゴリ中3種が必須のままの場合があるため、既定値とポリシーのずれには注意が必要です。
出典・参考資料（1件）
Q. 業務でパスワード管理ツール（パスワードマネージャー）を使ってもよいですか？
A. 業務でのパスワード管理ツールの利用は、安全なパスワード運用を助ける手段として問題なく、むしろ推奨されています。長くサービスごとに異なるパスワードを使い分けるには、人が覚えるだけでは限界があるためです。
NIST SP 800-63B-4は、入力欄への貼り付け（ペースト）を許可してパスワード管理ツールの利用を妨げないよう求めています。総務省も、パスワードの適切な保管方法を示しており、ツールの活用はこうした考え方に沿った運用といえます。
法人での選び方や共有・監査ログといった機能の違いは、『法人向けパスワード管理ツールおすすめ11選を徹底比較』でサービスごとに比較しています。
出典・参考資料（2件）
Q. Active DirectoryやMicrosoft Entra IDの既定値のまま使って問題ありませんか？
A. Active DirectoryやMicrosoft Entra IDの既定値は、NISTの最新の推奨値とはずれているため、そのまま使うかどうかは見直しが必要です。Active Directoryの既定ドメインポリシーは最小7文字・複雑性要件あり・最長42日、Entra IDの既定は8文字・4カテゴリ中3種必須・有効期限90日で、いずれも複雑性の強制や定期変更を前提としています。
Microsoft自身も有効期限ポリシーは効果が薄いとして推奨するセキュリティベースラインに含めておらず、自社ポリシーに合わせて調整するのが安全です。
出典・参考資料（2件）
ID管理・認証サービスの料金・資料を一括チェック
MCB FinTechカタログでは、シングルサインオンや多要素認証でパスワード運用の負担を減らせるID基盤の最新資料を無料で一括請求できます。対応する認証方式や料金プランをまとめて比較できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
