パスワード強度は桁数と文字種の2つで左右される
強度を左右する2つの要素
総務省は安全なパスワードを「他人に推測されにくく、ツールなどの機械的な処理で割り出しにくいもの」としています。パスワード強度とはこのうち後半の「機械的な処理で割り出しにくい」という性質を数量で表したものです。
パスワードの割り出しにくさは、長さと使っている文字の種類という2つだけで定まります。数字だけで作ったパスワードは1文字あたり10通りの選択肢しかなく、小文字と大文字と数字と記号を混ぜられるなら1文字あたり70通りになるので、文字数が同じでも組み合わせの総数は10と70をそれぞれ文字数の回数だけ掛け合わせた差になります。
パスワードを強くするなら記号より文字数を増やすほうが効果的
文字数を1つ増やすと、組み合わせの数はそのパスワードで使っている文字種の数だけ倍になります。 小文字だけで作っているなら26倍、記号まで混ぜられるなら70倍ですが、記号を加えて文字種を増やしても倍率の上昇は1回だけで、文字数を伸ばしたときのように掛け算が積み重なることはありません。
Hive Systemsも文字を1つ追加することで必要な時間が何倍にもなるため、長さが最も有効な防御手段だと結論づけています。実際にHive Systems 2026年版の一覧表でも、小文字だけの10文字（32年）は記号まで混ぜた7文字（2年）より長く持ちこたえ、表中どの行で比較してもこの関係は変わりません。
安全なパスワードとは、他人に推測されにくく、ツールなどの機械的な処理で割り出しにくいものを言います。／理想的には、ある程度長いランダムな英数字の並びが好ましい（いずれも「安全なパスワードの設定」節）— 総務省 国民のためのサイバーセキュリティサイトより公式情報を見る →
桁数と文字種別のパスワード解読時間は一覧表で比較可能
以下はHive Systemsが2026年に公開した一覧表で、ハッカー集団がRTX 5090を16枚使って総当たりするという条件で計算した値です。bcryptはパスワードを保存用の文字列へ変換するハッシュ関数で、ここではワークファクター10に設定されています。
パスワード解読時間の桁数・文字種別一覧表
| 文字数 | 数字のみ | 小文字のみ | 大文字＋小文字 | 数字＋大文字＋小文字 | 数字＋大文字＋小文字＋記号 |
|---|---|---|---|---|---|
| 4文字 | 即座 | 即座 | 即座 | 即座 | 即座 |
| 5文字 | 即座 | 即座 | 46分 | 2時間 | 3時間 |
| 6文字 | 即座 | 37分 | 2日 | 5日 | 1週間 |
| 7文字 | 即座 | 16時間 | 3か月 | 10か月 | 2年 |
| 8文字 | 即座 | 2週間 | 12年 | 50年 | 132年 |
| 9文字 | 2時間 | 1年 | 636年 | 3千年 | 9千年 |
| 10文字 | 20時間 | 32年 | 3万3千年 | 19万1千年 | 64万5千年 |
| 11文字 | 1週間 | 839年 | 100万年 | 1,100万年 | 4,500万年 |
| 12文字 | 3か月 | 2万1千年 | 8,900万年 | 7億3,700万年 | 30億年 |
13文字以上なら数字だけで作った場合を除きいずれも数十万年を超えます。数字だけの場合はもっとゆるやかで13文字で2年・18文字でも22万8千年ですが、現実の攻撃で差が意味を持つ範囲ではないため上の一覧表は12文字までとしています。
数字だけのパスワードは文字数を増やしても解読時間が伸びにくい
暗証番号のように数字だけで作ったパスワードは、8文字でも即座に破られます。 使う文字が10種類しかないため文字数を増やしても他の列に追いつかず、数字だけで小文字8文字（2週間）と同等になるには12文字が必要で、記号まで混ぜた8文字（132年）と同等になる数字だけのパスワードは、12文字までの範囲にはありません。
右端列に含まれる記号は^*%$!&@#の8種類だけ
Hive Systemsが集計に使っている記号は8種類です。記号の中身は^*%$!&@#で、多くのサイトが受け付ける記号に範囲を限定したとのこと。Hive Systemsは記号の選び方が影響を及ぼす範囲を表の右端列だけと説明しており、右端列の文字種は小文字26・大文字26・数字10・記号8を合わせた70種類になります。
記号の範囲を広く取った別の計算では、同じ「全文字種」という列名でも文字種の数が変わり、結果も変わります。他サイトの表と数値が異なるときは、まず相手の表が記号を何種類として計算しているかを確認することが大切です。
2026 hardware : 16 x RTX 5090 | 2026 password hash: bcrypt set to a work order of 10 (i.e. 1024 iterations of hashing)（"How It Started vs. How It's Going" 節）／We don't include every QWERTY symbol. The symbols most commonly accepted across sites, and generated by most password generators, are limited to ^*%$!&@#, so that's what we include. That choice only affects the right-most column of our tables.（"Limitations of our work" 節）— Hive Systems より公式情報を見る →
解読時間の数値が成り立つ4つの条件
一覧表の数値は条件を定めて初めて計算できます。つまり、Hive Systemsが置いている4つの前提はどれか1つでも実際と異なれば、一覧表の数字がそのまま通用しなくなります。
- ハッカー集団がすでにパスワードのハッシュを持っている: サービスから流出したデータを入手済みという想定
- ハッシュ関数がbcryptのワークファクター10: 1回の照合に1024回のハッシュ計算を挟む設定
- パスワードがランダムに生成されている: 人が考えた規則性のあるものはもっと速く破られる
- 過去の漏えいに含まれていない: すでに漏えいしたパスワードは総当たり以前に試される
ログインの試行回数制限が効かない攻撃を想定している
ハッシュとはパスワードを元に戻せない値へ変換した文字列で、サービス側はこの文字列を保存しています。 一覧表が想定しているのは、このハッシュが流出したあとにハッカー集団が保有する機材で文字列を1つずつ照合していく攻撃です。
ハッカー集団が保有する機材で行う作業なので、ログイン画面の試行回数制限やアカウントロックは機能しません。Hive Systemsは、多要素認証もハッシュを手に入れたあとの照合には関わらないとしています。
逆に、ログイン画面から直接試す攻撃であれば、回数制限のあるサービスでは一覧表の数字よりずっと手前で止まります。一覧表の数字は「サービスから流出したあと、どれだけ持ちこたえるか」を表すものです。
ハッシュ関数をユーザー側から選ぶことはできない
bcryptのワークファクターとは1回の照合にかける計算量の設定で、値を1つ上げると計算量が倍になり攻撃側の試行速度が半分になります。Hive Systemsがワークファクター10を選んでいるのは、実際のサービスでよく使われている設定に合わせたためです。
ユーザーには、利用中のサービスがどのハッシュ関数をどの設定で採用しているかを知る手段がありません。 より弱いハッシュ関数で保存しているサービスなら、同じパスワードでも表より短い時間で破られます。
したがって表の絶対値は、そのままご自身の環境でも同じになる数字としては受け取れません。文字数と文字種の優劣を比較する目安として読んでください。
Cracking passwords this way assumes the attacker has already acquired a hash of one or more passwords, like those found in breaches on HaveIBeenPwned.／The implied attack assumes MFA isn't used or has been bypassed.／These metrics assume passwords are randomly generated. Non-random passwords are much easier and faster to crack, because humans are predictable, so the times in these tables are a best-case reference point.（いずれも "Limitations of our work" 節）— Hive Systems より公式情報を見る →
8文字の解読目安は2年間で225年から132年へ短縮
記号まで混ぜた8文字のパスワードについて、Hive Systemsは年ごとの値を並べて公開しています。数値はいずれも、年をまたいで比較できるようHive Systemsがハッシュ関数の設定をそろえて出し直したものです。
| 一覧表 | 8文字（全文字種）の解読時間 | 想定ハードウェア | 比較に使ったハッシュ関数 |
|---|---|---|---|
| 2024年版（比較用に再計算した値） | 225年 | 12 x RTX 4090 | bcrypt（ワークファクター10） |
| 2025年版 | 164年 | 12 x RTX 5090 | bcrypt（ワークファクター10） |
| 2026年版 | 132年 | 16 x RTX 5090 | bcrypt（ワークファクター10） |
225年・164年・132年はワークファクター10にそろえ直した値
3つの値で異なる前提は、想定するハードウェアに限られます。 Hive Systemsが2024年に公開した表はワークファクター5でしたが、2025年版・2026年版と条件をそろえるため、Hive Systemsは2024年の表をワークファクター10で再計算しており、上の225年はその値です。
Hive Systemsは毎年の数字が短くなる理由を、パスワードが変わったからではなく、計算する側の機材が速く・借りやすくなり続けているためだとしています。2026年版の構成は前年比で約24%速く、解読時間はここ数年毎年およそ20〜25%ずつ短くなってきたというのがHive Systemsの観測です。
そろえ直しが成り立つ範囲は表に並べた3つの値だけです。Hive Systemsは2020年版から2023年版までMD5というハッシュ関数を前提にしており、2024年版でbcryptへ切り替えました。
同じ「8文字」について解読時間が秒や時間の単位になっている古いチャートを見かけるのは、前提に置いたハッシュ関数が異なるためです。各年に公開された一覧表の数字をそのまま並べて比較しても、比較しているのは前提であってパスワードの強さではありません。
毎年20〜25%という値は観測してきた実績であって予測ではない
毎年およそ20〜25%という値は、Hive Systemsがこれまで観測してきた実績であって、この先も同じ割合で短くなるという予測ではありません。つまり、何年後にどこまで短くなるかは表からは分からず、同じパスワードの持ちこたえる時間が短くなる方向にあるというところまでが言える範囲です。
なおHive SystemsはAIがGPU 1枚あたりのbcrypt処理を速くしたわけではなく、AIの効果は機材を借りて束ねる手間が少なくなったことだとしています。量子コンピュータについても、ハッシュに対する影響は実効強度が概ね半分になる程度で、鍵やハッシュを強くすれば対処できる範囲だというのがHive Systemsの見解です。
2024: 225 years／2025: 164 years／2026: 132 years／our official 2024 table ran at bcrypt work order of 5, so we reran the 2024 table at a work order of 10 to line it up with 2025 and 2026. That leaves the hardware as the only thing changing from frame to frame／This year's fleet clocks about 24% faster than last year's／crack times have been falling by roughly a fifth to a quarter, year over year（いずれも "Wait - is my password getting weaker every year?" 節）／Grover's algorithm is the mild one. Against symmetric encryption (like AES) and hash functions (like bcrypt), the best quantum trick only gives a square-root speedup - it roughly halves the effective strength.（"Ok but what about quantum computers?" 節）— Hive Systems より公式情報を見る →
NISTは単要素認証のパスワードに15文字以上を求めている
米国国立標準技術研究所（NIST）が公開しているSP 800-63Bは、パスワードポリシーの世界的な基準として参照されている文書です。そのうち2026年9月時点の最新版である第4版（SP 800-63B-4）は、パスワードの要件を次のように定めています。
| 要件 | 定め | 強さ |
|---|---|---|
| 最低文字数（単要素認証） | 15文字以上 | 要求（SHALL） |
| 最低文字数（多要素認証の一部） | 8文字以上 | 要求（SHALL） |
| 最大文字数 | 64文字以上を許容 | 推奨（SHOULD） |
| 文字種の構成ルール | 課してはならない | 禁止（SHALL NOT） |
| 定期的な変更の強制 | 要求してはならない | 禁止（SHALL NOT） |
| 漏えいパスワードとの照合 | ブロックリストと比較する | 推奨（SHOULD） |
15文字以上はサービス側への要件でユーザーへの推奨ではない
SP 800-63Bの名宛人は、認証を実装する側（Verifier / CSP）です。 15文字以上という数字もサービスが受け付けるパスワードの最低長として定められたもので、ユーザーに15文字以上を勧める推奨ではないため、この区別をしないと「NISTが15文字を推奨」という言い方になり要件の強さも名宛人も実際とずれます。
そのうえで、ユーザーがご自身で文字数を定める目安としては、15文字が現時点で最も根拠のはっきりした数字です。最低文字数が単要素認証で15文字、多要素認証の併用で8文字と異なるのは、パスワード1つが破られたときの結果に差があるからです。
文字数を数字で書いている出典はこの記事で使った3つのうちNISTだけです。総務省は危険なパスワードの5番目を「短すぎる文字列」とするだけで具体的な文字数を出しておらず、Hive Systemsも「最低限の8文字をはっきり超えるところを狙う」とだけ書いています。
つまり15文字はNIST由来の数字であって、3つの出典が一致して支持しているものではありません。他の2つも長さが重要だという向きはNISTと同じですが、何文字を最低とするかは書いていません。
NISTは文字種ルールよりパスワード長を優先
NISTは文字種の混在を求める構成ルールをサービス側が課すことを禁じています。同文書の附録Aでは構成ルールの効果が当初考えられていたほど大きくないことが漏えいパスワードの分析から分かっており、ユーザーは規則に合わせて似た作り方をするとも書かれていて、実際に大文字と記号を1つずつ追加しなさいという規則は末尾にA1!を追加するような似通った作り方を生みます。
定期的な変更の強制も同じ理由で禁じられています。変更を求められたユーザーは末尾の数字を1つずらす程度の変更にとどめがちで、かえって予測しやすくなるためです。ただし認証情報が流出した証拠がある場合は、逆にサービス側が変更を強制しなければなりません。
Verifiers and CSPs SHALL require passwords that are used as a single-factor authentication mechanism to be a minimum of 15 characters in length.／Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.／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.（いずれも "Password Verifiers" 節）— NIST SP 800-63B より公式情報を見る →
推測されやすいパスワードや再利用に一覧表の数値は通用しない
一覧表はランダムに生成されたパスワードを前提にしていますが、人が考えたパスワードには偏りがあり、攻撃側はその偏りを先に試します。したがって、推測できるパスワードは文字数がいくつであっても表の数字よりはるかに速く破られます。
総務省が危険なパスワードに分類する5つの型
総務省は避けるべきパスワードを次の5つに分類しています。どれも総当たりより先に試される種類のものです。
- IDと同じ文字列
- 本人や家族の名前・電話番号・生年月日（住所や車のナンバーも含む）
- 辞書に掲載されているような一般的な英単語ひとつだけ（password、baseballなど）
- 同じ文字の繰り返しや、わかりやすい順番（aaaa・123456・qwertyなど）
- 短すぎる文字列
上の5つと同じ特徴を持つパスワードは、総当たりより先に試される文字列に含まれるため、一覧表より早く破られます。16文字あっても辞書にある単語を連ねただけなら、一覧表の右下にある数字は通用しません。一覧表の数字が意味を持つのは規則性のない文字列を使っている場合だけです。
パスワードの再利用は文字数では埋め合わせられない
どれだけ長いパスワードでも同じものを複数のサービスで使い回していれば、その中でいちばん対策の弱いサービスが全体の強度を左右します。 総務省はあるサービスから流出したアカウント情報を使って他のサービスへの不正ログインを試す手口を書いたうえで、使い回しを避けるよう呼びかけています。
一方で流出した事実がないなら定期的な変更は不要で、総務省は定期変更を課すとパスワードの作り方がパターン化し、使い回しを招くほうが問題になるとしています。内閣サイバーセキュリティセンター（NISC）も定期変更は不要で流出時に速やかに変更する立場だと同ページは説明しており、NISTの定めとも方向は同じです。
サービスごとに異なる長いパスワードを覚えておくのは現実的ではないため、パスワード管理ツールの利用が有効な方法です。スマートフォンやWebブラウザの標準機能にある保存機能も選択肢になります。
パスワードはできる限り、複数のサービスで使い回さないようにしましょう。サービスから流出したアカウント情報を使って、他のサービスへの不正ログインを試す攻撃の手口が知られています。／各サービスごとに異なる充分に安全なパスワードを覚えておくのは大変なので、パスワードを覚える必要のない、パスワード管理ツールを使うことも推奨されます。（いずれも「パスワードを複数のサービスで使い回さない」「パスワードの保管方法」節）— 総務省 国民のためのサイバーセキュリティサイトより公式情報を見る →
文字数と文字種をカウントすれば一覧表と照合可能
ここまでの内容をご自身が利用しているパスワードと照らし合わせます。そこで、照合時にチェックするポイントは文字数と文字種の2つだけです。
- 文字数をカウントする: 今いちばん重要なアカウントで使っているパスワードの文字数をカウントします
- 文字種の列を選ぶ: 数字だけか小文字だけか大文字を混ぜているか記号まで入れているかで列が定まります
- 一覧表の行と列が交わるところを見る: 交わったセルの値がランダムに作られていた場合の目安です
一覧表を見る前に推測されやすさと再利用の2点をチェック
手順の前に、そのパスワードが表の前提を満たしているかをチェックします。 推測できる要素（名前・誕生日・辞書にある単語そのまま）が含まれていないかと他のサービスと同じものを使っていないかの2点で、どちらかに該当するなら一覧表のどこに該当するかを調べるより先にそのパスワードを作成し直すほうが確実です。
前提を満たしていてなお15文字に届いていないなら、文字数を伸ばすのが最も効果的です。15文字はNISTが単要素認証のパスワードに求めている文字数です。
パスワードは人が考えるより生成ツールで作ったほうが前提に近い
人が考えたパスワードは本人が意識していなくても規則性を持ちます。一方、一覧表の数字はランダム生成を前提として計算されているため、生成ツールで作った文字列のほうが前提に近くなります。
覚える必要がある場合の作り方については、出典同士で力点が異なります。総務省は理想は「ある程度長いランダムな英数字の並び」としたうえで、無関係な複数の単語を連ねたり数字列を挟んだりする作り方を紹介しています。
Hive Systemsは、単語を連ねた長いパスワードのほうが短くて凝ったパスワードより持ちこたえるとしています。ただし表の値はランダム生成を前提にした最良ケースの目安で、ランダムでないパスワードははるかに速く破られるとも認めているため、単語を連ねる作り方にするなら一覧表の数字はご自身のパスワードには通用しません。
sakuttoAIのパスワード生成ツールでは、文字数と文字種を指定してランダムな文字列を作ることができます。作ったパスワードは管理ツールに預け、サービスごとに異なるものを使えばこの記事で書いたことがひととおり実行できます。
パスワード強度の数字は前提とセットで読む
- 解読時間の数字は前提とセット。2026年版は、16 x RTX 5090・bcrypt（ワークファクター10）・オフライン総当たり・ランダム生成を条件として計算されている
- 数字だけの8文字なら即座に破られ、記号まで混ぜた8文字は132年。文字種を増やすより文字数を伸ばすほうが効果が大きい
- NISTが単要素認証に求めるのは15文字以上。ただし15文字以上はサービス提供側への要件で、ユーザーへの推奨ではない
- 推測できないかと使い回していないかを表より先にチェック。この2つのどちらかに該当するパスワードには表の数字が通用しない
最初に、いちばん重要なアカウントで使っているパスワードの文字数をカウントします。NISTが単要素認証に求める15文字に届いていなければ、文字種を増やすより先に文字数を伸ばすほうが効果があります。
FAQ
- パスワードは何文字あれば安全ですか？
- NIST（米国国立標準技術研究所）は、パスワードだけでログインする単要素認証なら15文字以上をサービス側の要件として定めており、多要素認証と組み合わせる場合は8文字以上としています。15文字以上という数字はサービスを提供する側が満たすべき要件ですが、ユーザーがご自身で文字数を定めるときの目安としても、15文字が現時点で最も根拠のはっきりした数字です。
- 8文字のパスワードは危険ですか？
- 文字種によって大きく変わります。Hive Systemsの2026年版では、数字だけの8文字は一瞬で破られ、小文字だけの8文字も2週間しかもたず、記号まで混ぜた8文字は132年です。ただし132年は漏えいしたハッシュをハッカー集団が保有する機材で総当たりし、パスワードがランダムに作られていた場合の値で、推測できるパスワードなら文字数に関係なくもっと速く破られます。
- 記号や大文字は必ず混ぜるべきですか？
- 混ぜれば試す組み合わせは増加しますが、NISTはサービス側に対して文字種の混在を求める構成ルールを課してはならないと定めています。混在を強制するとユーザーの作り方が予測しやすい構成に偏るためです。同じ手間をかけるなら、記号を1つ追加するより文字数を1つ増やすほうが効果があります。
- パスワードは定期的に変更すべきですか？
- 流出した事実がないなら変更は不要です。総務省は定期的な変更によってパスワードの作り方がパターン化し、使い回しを招くほうが問題だとしています。NISTもサービス側に定期変更を要求してはならないと定めており、変更の強制は認証情報が流出した証拠がある場合に限られます。
- 解読時間の一覧表はどこまで信用してよいですか？
- 前提が合っている範囲だけです。この種の表は、想定するハッシュ関数・GPUの構成・攻撃の種類を定めて初めて数字が出ます。Hive Systemsも2023年版まではMD5、2024年版からはbcryptを前提にしています。利用中のサービスがどのハッシュ関数を採用しているかはユーザーには分からないため、順位の目安として読んでください。
関連する記事
リバースエンジニアリングとは？意味と手法、違法になるケースを解説リバースエンジニアリングとは、すでにある製品やソフトウェアを調べて、構造や作り方を明らかにすることです。互換性のある製品の開発や脆弱性発見に使われます。著作権法上、プログラムの解析は原則として侵害になりませんが、利用規約や営業秘密、コピー防止の回避には別のルールがあります。
Tencent Cloud上のAIエージェント群を研究者が追跡して対話Tencent Cloud上のAIエージェント群が9月28日から10月8日にかけ、Alibabaの地図サービス高徳地図のデータを取ろうと2,600回以上試みました。研究者は報告書に人間には見えない案内文を入れ、エージェントと対話しています。Tencentに近い関係者は第三者モデルの評価だったと説明しました。
Macのフルディスクアクセスの許可を厳格化【AIエージェント対策】AppleはMacのフルディスクアクセスについて、付与にきわめて明示的な操作を求める仕組みを追加すると2026年10月2日に発表しました。AIエージェントが自律的になるほど、この権限のリスクが高まるためです。開始時期と対象のmacOSは未発表で、許可しているアプリは「プライバシーとセキュリティ」で確認できます。
Ox Alphaの開発元はZ.aiと判明、入出力の保存を規約が明記100万トークンの文脈を無料で利用することができるOx Alpha。提供元を伏せたまま公開されましたが、開発元はZ.aiだとBloombergが報じ、Z.aiもGLMシリーズの最新版だと認めました。OpenRouterに出した提供元は名乗っておらず、入力と出力の保存先は分からないままです。