無料一括パスワードジェネレーター

強力なパスワードを一度に複数生成します。数、長さ、文字をカスタマイズして、テキストファイルとしてダウンロードします。

デバイス上でローカルに生成されたパスワード
「パスワードを生成」をクリックして開始します

    一括パスワード生成

    このツールは、暗号的に強力なパスワードを1つの操作で複数生成します。チームのオンボーディング、一括アカウント作成、パスワードインベントリの管理のためのリストの準備に最適です。各パスワードは、ブラウザの組み込みランダムジェネレーターを介して生成されます。

    強度レベル

    よくある質問

    これらのパスワードは本当にランダムですか?

    はい。パスワードはwindow.crypto.getRandomValues()で生成され、これはセキュリティ用途に適した暗号的に安全なランダム値を提供します。

    100以上のパスワードを生成できますか?

    ブラウザの速度低下を避けるために、ツールは一度に100に生成を制限します。必要に応じて、複数のバッチを別々に生成します。

    ダウンロードしたファイルを保存するには?

    .txtファイルを安全な場所に、できれば暗号化して保管してください。コードリポジトリにコミットしたり、安全でないチャネルで共有したりしないでください。ユーザーへの配布後は削除してください。

    良い乱数はどこから来るのか

    コンピューターは設計上、決定論的です。同じ入力と同じコードが与えられれば、常に同じ出力を生成します。これはスプレッドシートを処理するCPUには望ましい性質ですが、パスワード生成器には望ましくありません。攻撃者がジェネレーターの出力した値の列を再現できれば、そのジェネレーターが発行したすべてのパスワードを再現できてしまいます。

    そのためジェネレーターは「エントロピー」（プログラム外からの予測不可能な物理的シグナル）を収集し、CSPRNG（暗号論的擬似乱数生成器）と呼ばれるアルゴリズムにシードとして使います。「疑似」という言葉は正直な表現で、ビットは物理法則ではなくアルゴリズムによって生成されます。「暗号論的に安全」とは、過去の出力を大量に見た攻撃者でも次のバイトを偶然以上に予測できないことを意味します。Theodore Ts'oは1994年にLinuxカーネルに/dev/randomを実装し、macOS・BSD系・Solaris・Windows（BCryptGenRandomを使用）もすべて同等のインターフェースを採用しました。内部ではディスクシーク時間・ネットワークパケット到着・キーボードとマウスの入力・ハードウェア割り込み・Intel CPUのRDRANDなど考えられるすべての物理的ジッターを暗号ハッシュで混合し、継続的に再シードします。

    ブラウザでは、W3CのWeb Cryptography APIがwindow.crypto.getRandomValues(typedArray)を通じてこれを公開しています。型付き配列を渡すと、ブラウザが暗号論的に強いランダムバイトで埋めます。1回の呼び出しで最大65,536バイトまで対応しています（このツールはその範囲内に収まります）。このAPIは2015年7月からChrome・Firefox・Safari・Edgeで標準サポートされており、このツールにアクセスするユーザーのブラウザが未対応である可能性は実質的にありません。

    パスワードエントロピー：実際の計算

    パスワードの「強度」（正式な暗号論的な意味での）はエントロピーのビット数で測定されます。ランダムに生成されたパスワードの標準的な計算式は次のとおりです：

    エントロピー = L × log₂(R)

    ここでLは文字数、Rは文字プールのサイズです。文字セット別の1文字あたりのエントロピーは次のとおりです：

    94という数字は明確にしておく価値があります。ASCIIコード32から126が印刷可能文字（95文字）であり、スペースを除くと94の可視非スペースグリフ（小文字26 + 大文字26 + 数字10 + 句読点/記号32）になります。この式に具体的な数字を代入すると：

    暗号コミュニティは3つの閾値で合意しています。80ビットは最低限（2014年までのNISTの推奨下限）で、全94文字セットを使って約13文字で到達します。100ビットは暗号化システムを保護するパスワードにANSSI（フランスのNSA相当機関）が要求する水準で、約16文字で到達します。128ビットはAES-128の対称鍵強度と同等で、Vaultのマスターパスワードに推奨され、約20文字で到達します。

    重要な注意点：この計算はあくまでもランダムなパスワードにのみ適用されます。人間がパスワードを選んだ場合、実効エントロピーははるかに低くなります。攻撃者はR^L個の文字列をアルファベット順に列挙するわけではなく、流出したパスワードリスト・辞書の単語・一般的な置換（a→@、o→0、s→$）・キーボードウォーク・人間が記憶しやすい文字列の構成方法に関する統計モデルを使ったプログラムで推測します。7,000万件のYahooパスワードの匿名コーパスを調査したJoseph Bonneauの2012年の研究（IEEE Symposium on Security and Privacy）によると、ユーザーが選んだパスワードはオンライン大規模攻撃に対して「10ビット未満のセキュリティしか提供せず、最適なオフライン辞書攻撃に対しても約20ビット程度」であることが分かりました。20ビットとは100万回の推測です。現代のGPUならマイクロ秒単位で完了します。

    NIST SP 800-63B：2017年と2025年に変わったこと

    約30年間、北米のパスワードに関するセキュリティポリシーは、定期的な強制変更・文字種の混在・短い最小文字数を推奨した1985年のNIST出版物に端を発していました。「大文字 + 小文字 + 数字 + 記号、90日ごとに変更」というルールを成文化した2003年フォローアップの著者Bill Burrは2017年にそれを公に撤回し、ウォール・ストリート・ジャーナルに「自分がやったことの多くを今は後悔している」と語りました。NISTは同年、この方針転換を正式化しました。

    NIST SP 800-63B Rev 3（2017年6月）は2つの時代的な変更を行いました。セクション5.1.1.2には「検証者は記憶シークレットを（例えば定期的に）任意に変更することを要求すべきでない（SHOULD NOT）」とあります。強制的な変更は、ユーザーが予測しやすい弱いパスワードを選ぶ原因になるためです。同じセクションには「検証者は記憶シークレットに対して他の構成ルール（例：異なる文字種の混在要求）を課すべきでない（SHOULD NOT）」ともあります。数字と記号を強制するとユーザーは長いパスフレーズよりもPassword1!を選んでしまいます。Rev 3では最小文字数を8文字に設定し、最大64文字まで受け入れることを義務付け、新しいパスワードを侵害リストと照合することを義務付け、パスワードマネージャーとクリップボードからの貼り付けを許可することを明示的に義務付けました。

    NIST SP 800-63B Rev 4（2025年7月31日確定）はさらにハードルを上げました。単一要素パスワードには15文字の最小要件が課されます（「単一要素認証メカニズムとして使用されるパスワードは、最低15文字の長さを要求しなければならない（SHALL）」）。多要素の場合は第2要素がセキュリティの重みを担うため8文字のままです。構成ルールの禁止は維持され、Rev 3の「SHOULD NOT」からRev 4の「SHALL NOT」へと、推奨から厳しい要件に変わりました。侵害の証拠がない限り、パスワードのローテーションは依然として推奨されていません。

    Absolutoolのツールはデフォルトで4種類の文字クラスすべてを使った16文字を生成し、約104ビットのエントロピーを提供します。これはRev 4の15文字最低要件と80ビット対称等価閾値の両方を余裕を持ってクリアします。このツールの最大128文字は、NISTが検証者が受け入れなければならないと義務付けている最大文字数のちょうど2倍であり、生成されたパスワードがサーバーで受け入れられないほど長くなる現実的なケースはありません。

    RockYou：2026年も残り続ける惨事

    2009年12月、ソーシャルゲーム会社RockYouが教科書的なSQLインジェクションによって侵害されました。この侵害で3,200万件以上のユーザーアカウントが流出し、パスワードが平文で含まれていました。RockYouはパスワードを暗号化せずに保存していたのです。当時の同社のパスワードポリシーは5文字以上のみを要求し、特殊文字を禁止しており、脆弱性をさらに深刻にしていました。

    流出したファイルはすぐにrockyou.txtと呼ばれるようになり、現在も世界で最も参照されているパスワードワードリストとして流通しています。ペネトレーションテスター向けにKali Linuxにデフォルトで同梱され、世界中のあらゆる辞書攻撃ツールがこれを参照し、商業的なクレデンシャルスタッフィングサービスがベースラインとして保持しています。16年経った今も、攻撃者は2009年の流出に最初に登場したパスワードを使ってアクティブなアカウントを侵害し続けています。ここから広まった教訓：サーバーは絶対に平文パスワードを見てはならない（このツールはクライアントサイドで生成するため、サーバーは一切見ない）。保存するパスワードはMD5や無塩SHA-1のような高速ハッシュではなく、Argon2idやbcryptのような低速・ソルト付き・メモリハード関数でハッシュ化すべきだ。サイトごとに異なるパスワードを使うことが、過去10年間の侵害を席巻してきた盗まれた認証情報を使い回す攻撃への唯一の防御だ。

    Have I Been PwnedとBreachコーパス

    MicrosoftリージョナルディレクターのTroy Huntが運営するHave I Been Pwned（HIBP）は、「このパスワードは侵害で登場したことがあるか？」という問いに対する標準的な権威ある情報源となっています。Huntは2013年に侵害されたメールアドレスの検索可能なインデックスとしてHIBPを立ち上げ、後に公開された侵害で確認されたすべてのパスワードをSHA-1ハッシュでインデックス化したダウンロード可能なリストであるPwned Passwordsコーパスを追加しました。Pwned Passwords V2は2018年2月22日にローンチし、データセットのk-匿名性API（Cloudflareと共同構築）を導入しました。クライアントはSHA-1ハッシュの最初の5文字のみを送信し、サーバーはその5文字で始まるすべてのフルハッシュと観測回数を返し、クライアントがローカルで比較します。パスワード（フルハッシュさえも）はユーザーのデバイスを離れません。

    一括生成ツールにとっての関連性は2つあります。HIBPにすでに存在するパスワードは定義上、新しい有用なパスワードではなく、クレデンシャルスタッフィング攻撃者が最初に試みるものになります。そして、このツールが94文字のアルファベットから完全なCSPRNGランダム性で生成するため、新たに生成された16文字のパスワードがすでにHIBPに存在する確率は実用上ゼロです。（16文字のASCII記号パスワードの総数は 94^16 ≈ 3.7 × 10³¹ 通り、HIBPには既知のパスワードが約 10⁹ 件含まれており、衝突確率 ≈ 10⁻²²。）

    「Xビットのエントロピー」が意味するリアルな解読時間

    エントロピーのビット数に具体的な意味を与える数字は「現代の攻撃者にはどのくらいかかるか」ですが、その答えはハッシュアルゴリズムに完全に依存します。コミュニティが公開したhashcat v6.2.6を単一のNvidia RTX 4090で動かしたベンチマークでは、NTLMハッシュ（MicrosoftのWindows旧来のハッシュ）で約300 GH/s、bcryptで約200 kH/sという結果が記録されています。この両者の4桁の差こそが核心となる事実です。NTLMは速さを重視して設計され、bcryptは遅くなるよう設計されました。

    広く引用されるHive Systemsのパスワードテーブルは、ベンチマークを解読時間に変換しています。MD5ハッシュ（NTLMとほぼ同じ速さ）に対して計算された2025年版では、フル文字セットの8文字パスワードをRTX 4090 1枚でブルートフォースするのに約59分かかると示されています。同じ8文字のパスワードでもbcryptハッシュであれば同じハードウェアで約99年かかります。この4桁の差が、「昨日流出して昼食時に解読済み」と「昨日流出してもあなたより長生きする」の違いです。

    エンドユーザーはパスワードの長さと文字セットをコントロールできます。しかし、サーバーが保存に使用するハッシュアルゴリズムはコントロールできません。最近の多くの適切に運営されているサービスはbcrypt・scrypt・Argon2idを使用しており、これらは意図的に遅く設計されています。古いサービスや侵害を受けたサービスはMD5や無塩SHA-1を使っていることが多く、それが上記の速度で古い侵害コーパスを解読できる理由です。このツールで生成したパスワードについて：16文字のランダムパスワードはbcryptに対して実質的に永遠に安全で、現時点ではMD5に対しても概ね安全です。20文字のパスワードはどちらに対しても過剰な強度です。20文字以上のCSPRNG出力が弱点になる現実的な脅威モデルは存在しません。

    FIDO2・WebAuthn・パスキーへの移行

    セキュリティ業界で最も長く続く予言はパスワードがなくなるというものです。2019年以降、ついに信頼できる代替手段が登場しました。パスキー（FIDO2 / WebAuthn規格に基づく認証情報に付けられたコンシューマー向けのマーケティング名）です。WebAuthn Level 1は2019年3月4日にW3C勧告となり、Level 2は2021年4月8日に続きました。暗号モデルは非対称です。ユーザーが登録するとき、認証器が公開鍵/秘密鍵のペアを生成し、公開鍵をサーバーに送り、秘密鍵をセキュアなローカルハードウェアに保存します。認証は秘密鍵で署名されたチャレンジ・レスポンスを使用します。サーバーはシークレットを一切見ないため、サーバーサイドの侵害でログイン認証情報が流出することはありません。

    主要プラットフォームのロールアウトは2022〜2023年にかけて一斉に進みました。Appleは2022年6月6日のWWDCでパスキーをデモし、2022年9月にiOS 16・iPadOS 16・macOS Venturaとともに公開リリースし、エンドツーエンド暗号化されたiCloud Keychainで同期します。Googleは2022年10月12日にAndroidとChromeのパスキーサポートを発表し、Chrome 108（2022年12月）でのStableサポートはGoogle パスワードマネージャーで同期します。Microsoftは2023年9月21日にWindows HelloとのWindows 11向けパスキー管理を発表しました。

    パスキーはパスワード障害の最も深刻なパターン（フィッシング・クレデンシャルスタッフィング・サーバー侵害）を解決しますが、パスワードを完全に排除していません。その理由：多くのサイトやほとんどのレガシーシステムではまだパスワードが必要です。パスキーはデバイスまたは同期エコシステムに紐付けられており（Apple・Google・Microsoftのアカウントを持たないユーザーには代替手段が必要）、ヘッドレスシステム（IoTデバイス・サーバーサイドのサービスアカウント・一括オンボーディングシナリオ）は登録ステップで生体認証器を使えません。そして多くのエンタープライズパスワードポリシー・銀行システム・政府ポータルではまだパスワードが義務付けられています。パスワードの一括生成は明確に後者のカテゴリーに属します。50件の新規アカウントをプロビジョニングするシステム管理者は、アカウントが存在する前に各ユーザーにパスキーを登録するよう求めることができません。

    クライアントサイド生成が特に重要な理由

    あるツールがユーザーのリクエストをサーバーにPOSTし、サーバーが乱数生成器を実行して結果をJSONで返すとします。すべてが宣伝通りに動作したとしても、次の関係者が生成されたパスワードを平文で見ることができます：リクエスト処理中のサーバーのプロセスメモリ。サーバーのリクエストログ（ロギングが不十分な場合）。サーバーに接続されたAPMやエラートラッキングサービス。TLSを終端するリバースプロキシ（Cloudflare・AWSロードバランサー・nginx）。サーバー上で動作するデバッグツール。それらのログに将来アクセスする攻撃者。RockYouモデルがそのすべての結果とともに当てはまります。

    window.crypto.getRandomValues()を通じてユーザーのブラウザで生成が行われる場合、そのいずれも適用されません。バイトはユーザーのマシン上のブラウザプロセス内で、ユーザーが監査できるコード（ページのソースが表示可能）によって生成されます。ネットワークを越えることは一切ありません。Absolutoolのサーバーはそれらを見ることも、ログに記録することも、将来の侵害で漏洩させることもできません。一度も保持したことがないからです。生成されたパスワードを見る唯一のエンティティは、ユーザー、ユーザーのブラウザセッションにアクセスできる者（通常はユーザーのみ）、そしてページ上で動作しているブラウザ拡張機能です。これはパスワードマネージャーのローカル生成器と同じセキュリティモデルであり、サーバーから生成されたパスワードを返すウェブサービスのモデルよりも強固です。

    Mirai 2016：IoTデフォルトのネガティブな事例

    「すべてのユニットに同じデフォルトパスワードを使えばいい」の教科書的なネガティブ事例はMiraiボットネットです。Miraiは約62個のメーカーデフォルトのユーザー名/パスワードの組み合わせ（admin/admin・root/root・root/xc3511・root/vizxv）のハードコードされたリストを悪用して、2016年後半に数十万台のIPカメラ・DVR・家庭用ルーターに感染し、2016年10月21日に主要DNSプロバイダーのDynを攻撃してTwitter・Reddit・Netflix・GitHubを一時的にダウンさせました。パスワードの一括生成器は代替手段として正確に適した道具です。製造ラインでユニットごとに一意の強力なデフォルトパスワードを生成し、ステッカーに印刷して箱の中に入れて出荷します。

    よくある質問

    NISTが複雑さよりも長さを推奨するのはなぜですか？

    複雑さを強制すること（数字・記号・大文字）は、攻撃者がすでにモデル化した予測可能なパターンにユーザーを誘導するからです。Password1!はpasswordよりも数学的にはエントロピーが高いですが、実際にはすべての攻撃者のワードリストはそこから始まります。CSPRNGで生成した20文字の英小文字オンリーの文字列は約94ビットのエントロピーを持ち、ワードリストに一致しないためどのワードリストでも推測できません。NIST SP 800-63B Rev 4（2025年7月）は構成ルールの禁止を厳格なSHALL NOT要件にしました。

    パスフレーズを使うべきですか？

    記憶が必要なパスワードには、はい。それがxkcd #936（2011年8月10日）の主張でした。ダイスウェア方式（Arnold Reinhold、1995年）では7,776語のリストから1語あたり12.9ビットが得られ、6語 ≈ 77.5ビットが現代の推奨値です。EFFは2016年7月に更新されたダイスウェア互換の単語リストを公開しました。ただし、このツールが対象とする一括プロビジョニングのユースケース（最初のログインで変更される一時トークン）では、ユーザーが入力する必要がないためランダムASCIIが適切です。

    曖昧な文字を除外することはセキュリティのトレードオフですか？

    技術的にはそうです。i・l・1・L・O・0・oを除くとアルファベットは94から87に縮小し、1文字あたりのエントロピーは6.55ビットから6.44ビットに低下します。16文字では104.8ビットではなく103.0ビットになりますが、完全に無関係な差です。このトレードオフが意味を持つのは、人間がパスワードを声に出して読んだり印刷されたシートから転記したりする場合で、それはまさにこのツールが対象とする一括配布シナリオです。

    生成されたリストを配布する最も安全な方法は？

    生成されたリストをワンショットの成果物として扱ってください。あらかじめ取り決めたチャネルを通じて配布します（PGP/GPGで暗号化したメール・セキュアなファイル転送・パスワードマネージャーへのインポート・重要度の高いケースでは対面での手渡し）。システムが最初のログイン時にパスワードの変更を要求するよう設定してください。配布後はファイルを削除してください。平文のリストをメールで送らないこと、バージョン管理にコミットしないこと、チャットに貼り付けないこと。生成されたパスワードはワンタイムトークンとして意図されており、価値は長期的な保持ではなく最初の引き渡し時の暗号論的なランダム性にあります。

    関連ツール

    パスワードジェネレーター

    強力なランダムパスワードを作成します。

    Base64エンコーダー

    Base64を瞬時にエンコードおよびデコードします。

    ランダム文字列ジェネレーター

    カスタムパターンでランダム文字列を生成します。