# 暗号論的に安全なパスワード自動生成ツール：技術アーキテクチャと詳細実践ガイド

現代のゼロトラスト（Zero-Trust）アーキテクチャおよびアイデンティティ＆アクセス管理（IAM）において、認証情報の暗号学的強度はセキュリティ境界を防衛する最前線です。エンタープライズの秘密鍵保管庫（Key Vault）のマスターパスワード策定から、本番データベースのroot認証情報のプロビジョニング、マイクロサービス間通信を認証するAPIトークンやHMAC署名シークレットの発行に至るまで、暗号論的に安全なランダム文字列の生成は不正アクセスを阻止するための絶対的な基盤です。

しかしながら、実務のソフトウェア開発現場では、パスワード生成ロジックの不備に起因する深刻なセキュリティ脆弱性が後を絶ちません。多くの開発者が依然としてJavaScriptの Math.random() のような予測可能な疑似乱数生成器（PRNG）に依存していたり、ナイーブな剰余演算（Modulo arithmetic）によって統計的な偏り（剰余バイアス：Modulo Bias）を混入させていたり、生成された認証情報をサードパーティのリモートAPIサーバー経由で取得していたりします。エントロピー採取やサンプリングアルゴリズムにおけるわずか1つの暗号学的欠陥が、自動化されたクラッキングツールやGPUクラスタによるオフライン総当たり攻撃（ブルートフォース攻撃）への突破口を与えてしまいます。

ToolsAA 暗号論的に安全なパスワード自動生成ツール（Cryptographically Secure Password Generator Online） は、数学的に偏りのない 強力なランダムパスワード作成ツール（Strong Random Password Maker） と、ブラウザネイティブの Web Crypto API パスワードエンジン を統合したプロフェッショナル仕様のセキュリティユーティリティです。本ツールは厳格なゼロ知識クライアントサイドアーキテクチャ（"use client"）を基盤としており、エントロピー採取、文字サンプリング、置換シャッフル、強度解析のすべての演算がお使いのブラウザ内部の揮発性メモリサンドボックス内で100%完結します。生成されたパスワードやメタデータが外部サーバーへ送信されることは1バイトたりともなく、GDPR、HIPAA、SOC 2、および日本の「個人情報の保護に関する法律（APPI）」への完全な準拠を保証します。

# 包括的概要と実践的なユースケース

パスワードセキュリティの数学的強度は、情報エントロピー（Information Entropy）——すなわち文字列に含まれる予測不可能性の度合いによって厳密に定義されます。強固な認証情報は、レートリミットされたWebログイン試行に対する防衛にとどまらず、漏洩したハッシュ値に対して分散GPUクラスタが毎秒数千億回の試行を行うオフラインクラッキング攻撃に耐えうるものでなければなりません。

+-----------------------------------------------------------------------------------------+
|                  ゼロ知識アーキテクチャに基づくパスワード生成パイプライン                    |
|  [ OSカーネルエントロピー ] ──► /dev/urandom / BCryptGenRandom (256ビット暗号学的プール)  |
|  [ Web Crypto API ]        ──► window.crypto.getRandomValues() (均一な Uint32Array)     |
|  [ サンプリングエンジン ]  ──► 棄却サンプリング (剰余バイアス完全排除: P(x) = 1/N)        |
|  [ 置換アルゴリズム ]      ──► 暗号学的フィッシャー–イェーツ法 (N! 通りの空間的一様性)    |
|  [ クライアントUI ]        ──► 揮発性メモリ描画 & 一時クリップボード (サーバー通信 0バイト) |
+-----------------------------------------------------------------------------------------+

# エンタープライズ開発における主要ユースケース

• マスターパスワード＆暗号化ボールトのルート鍵: Bitwarden、1Password、KeePassXC などのパスワードマネージャーは、Argon2id や PBKDF2 を通じてマスターパスワードから暗号化ルート鍵を導出します。高エントロピーな Diceware パスフレーズは、ボールト全体の暗号化基盤を保護します。
• データベース＆クラウドインフラのマスター認証情報: PostgreSQL、MySQL、Redis、MongoDB などの本番データベースや AWS IAM / GCP Cloud IAM の初期プロビジョニング時において、自動ポートスキャンや辞書攻撃を完全に無力化する予測不能なパスワードを配備します。
• CI/CD パイプラインシークレット＆Webhook 署名鍵: GitHub Actions、GitLab CI、CircleCI の環境変数、および AWS KMS や Stripe Webhook で利用される HMAC-SHA256 共有鍵として、暗号論的に均一なランダムトークンを供給します。
• エンタープライズ Wi-Fi（WPA2 / WPA3 Enterprise）: 企業内無線LAN環境において、辞書攻撃に耐性を持ちつつ、モバイル端末からの手動入力時にも誤認を起こさない視覚的混同文字（Ambiguous Characters）を排除した事前共有鍵（PSK）を生成します。
• 暗号学的ソルト（Salt）、ナンス（Nonce）、およびステートトークン: パスワードハッシュ化用のソルトや、OAuth 2.0 / OIDC の CSRF 対策ステートトークン（PKCE コードベリファイアなど）として、暗号学的に純粋な Base64URL や Hex 文字列を生成します。

# 現代のセキュリティ標準：NIST SP 800-63B ガイドライン

米国国立標準技術研究所（NIST）が策定した最新のデジタルアイデンティティガイドライン「NIST SP 800-63B」は、従来の「90日ごとの強制定期変更」や「大文字・数字・記号の複雑な組み合わせ強制ルール」といった旧来のセキュリティ慣行を明確に否定しています。

実証研究により、頻繁な変更を強制すると、ユーザーは Password2025! から Password2026! のように予測可能な微小置換を行うようになり、かえって全体的なセキュリティ強度が低下することが判明しました。NIST は以下の原則を強く推奨しています：

1. 複雑さ（Complexity）よりも長さ（Length）を最優先する: 最低でも16文字以上、推奨は20文字以上。
2. 恣意的な有効期限（定期ローテーション）の撤廃: 認証情報の漏洩が確認された場合のみ変更を実施する。
3. 人間が記憶可能なパスフレーズ（Diceware Passphrase）の積極採用: 複数の独立した単語で構成されるパスフレーズを許容し、メモへの物理的書き留めリスクを最小化する。

# クライアントサイド処理（ローカル実行）がデータ漏洩防止に不可欠な理由

旧来の一般的なオンラインパスワード生成サイトの多くは、HTTP POST リクエストをバックエンドサーバーに送信し、サーバー側で生成した文字列をブラウザに返送する方式を採用していました。しかし、ゼロトラストの観点において、このアプローチは極めて重大なセキュリティリスクを孕んでいます：

• リバースプロキシや WAF のアクセスログへの平文記録: Nginx、Envoy、Cloudflare などのエッジ層や WAF のログに、平文の認証情報がリクエスト本文やクエリパラメータとして記録される危険性があります。
• サーバーサイド監視ツール・APM によるトレース捕捉: Datadog、New Relic、Sentry などのクラッシュレポートや APM トレーシングツールに、生成されたシークレットが意図せずペイロードとして送信・永続化されるリスクがあります。
• 通信経路上のパケット解析と中間者攻撃（MitM）: TLS 設定の不備や企業内プロキシのSSL復号機能が存在する場合、平文の認証情報が第三者に傍受される可能性があります。

ToolsAA は、Web Crypto API を活用した 100% クライアントサイド実行モデル（Zero-Server Processing Model） を徹底しています。パスワードはブラウザの揮発性 RAM 領域にのみ一時的に存在し、ネットワーク通信は 0 バイトです。タブを閉じた瞬間にメモリから完全に破棄されるため、情報漏洩の懸念が根本から排除されています。

# 技術アーキテクチャと内部動作原理

暗号学的に破綻のない真に予測不可能な認証情報を生成するためには、OS カーネルのエントロピープールの利用、サンプリング時の統計的偏りの数理的排除、そして情報理論に基づく正確な強度評価が不可欠です。

# 1. CSPRNG（暗号論的擬似乱数生成器）対 一般的な擬似乱数生成器（Math.random()）

JavaScript の標準メソッドである Math.random() は、高速な数値計算やゲーム演出を目的として設計されたアルゴリズム（V8 エンジンにおける XorShift128+ など）を採用しています。このアルゴリズムの内部状態はわずか 128 ビットしかなく、暗号論的擬似乱数生成器（CSPRNG: Cryptographically Secure Pseudo-Random Number Generator）ではありません。攻撃者がブラウザ上で生成された連続する出力を観測した場合、内部のシード状態を数学的に逆算し、過去および将来に生成されるすべての乱数列を完全に予測することが可能です。

[ 一般的な PRNG: Math.random() ]
  内部シード (128ビット) ──► 線形演算 (XorShift128+) ──► 状態逆算可能 (暗号学的脆弱性)

[ ToolsAA CSPRNG: window.crypto.getRandomValues() ]
  OS カーネル (HWノイズ / 中断タイミング) ──► 256ビット暗号学的プール ──► 非可逆かつ均一

対照的に、W3C 標準規格である Web Crypto API の window.crypto.getRandomValues() は、ホスト OS のカーネルが管理する真のハードウェアエントロピープールに直接アクセスします：

• Linux / Android: getrandom(2) システムコールおよび /dev/urandom（ChaCha20 ベースのエントロピープール）
• macOS / iOS: SecRandomCopyBytes（CommonCrypto 基盤）
• Windows: BCryptGenRandom（CNG 暗号化プリミティブ）

これにより、CPU の熱雑音、キーボード入力のマイクロ秒単位のタイミング差、割り込みジッターなどの物理的エントロピーを取り込み、予測不可能性が数学的に保証された真に均一な 32 ビット符号なし整数列（Uint32Array）を取得します。

# 2. 剰余バイアス（Modulo Bias）と公平な棄却サンプリング（Rejection Sampling）

乱数から特定の文字セット（プールサイズ $N$）の文字を選択する際、多くの初学者や素朴なスクリプトは剰余演算子（Modulo: rand % N）を使用します。しかし、乱数生成器が返す値の定義域が $N$ の倍数でない場合、剰余バイアス（Modulo Bias） と呼ばれる統計的歪みが不可避的に発生します。

32 ビット符号なし整数の最大値は $2^{{32} - 1 = 4,294,967,295$ です。値域の幅は $2}{32} = 4,294,967,296$ 通り存在します。この範囲をプールサイズ $N$（例: 英数字＋記号の94文字）で割った場合、$2^{32} \bmod 94 = 2$ となり、割り切れません。

その結果、インデックス $0$ および $1$ に対応する文字は、インデックス $2$ から $93$ の文字よりも出現確率がわずかに高くなります。この偏りは個別の生成では微小に見えても、GPU を用いた統計的攻撃（頻度分析攻撃）においては、攻撃者が探索範囲を特定文字セットに優先配分できる致命的な弱点となります。

ToolsAA は、この偏りを数学的に完全にゼロにする 棄却サンプリング（Rejection Sampling） アルゴリズムを実装しています：

$$\text{limit} = \left\lfloor \frac{2^{32}}{N} \right\rfloor \times N$$

0                                           limit                      2^32 - 1
[==================== 有効範囲 ====================][=== 棄却範囲 (バイアス) ===]
       均一確率 P(x) = floor(2^32 / N) / 2^32               再サンプリング実行

サンプリングした 32 ビット整数 $R$ が $\text{limit}$ 以上である場合、その値を破棄して直ちに新しい乱数を取得します。これにより、$R < \text{limit}$ の範囲内でのみ剰余演算が適用され、すべての文字が厳密に $P(x) = 1/N$ の完全一様確率で選択されることが数学的に証明されます。

# 3. 暗号学的フィッシャー–イェーツ置換法（Fisher-Yates Permutation）

「大文字・小文字・数字・記号をそれぞれ最低1文字含む」というポリシーを満たすため、各プールから1文字ずつ順番に配列へ追加してから残りをランダムに埋めるという実装が頻繁に見られます。しかし、配列のシャッフルを行わなかったり、不完全なソート（例: arr.sort(() => Math.random() - 0.5)）を行ったりすると、先頭のインデックスに必ず特定の文字種が存在するという位置的バイアス（Positional Bias） が発生します。

高度なパスワード解析ツール（Hashcat や John the Ripper）を操る攻撃者は、この配置ルールを悪用してマスク攻撃の探索空間を劇的に削減します。

ToolsAA は、暗号学的フィッシャー–イェーツ・シャッフル（Cryptographic Fisher-Yates Shuffle） を採用しています。配列の末尾（インデックス $L-1$）から先頭（インデックス 1）に向かって逆順に走査し、各要素 $i$ に対して、CSPRNG を用いた棄却サンプリングによって選ばれた乱数インデックス $j \in [0, i]$ とスワップします。このアルゴリズムにより、長さ $L$ の文字列に対して $L!$ 通りのすべての順列が完全に等確率で生成され、文字の位置的偏りが空間的に完全に排除されます。

# 4. 情報理論的エントロピー計算（Shannon Entropy）

認証情報の強度は、Claude Shannon（クロード・シャノン）が提唱した情報エントロピーの公式によってビット単位（Bits）で定量化されます：

$$H = L \times \log_2(R)$$

ここで、$L$ はパスワードの文字数（長さ）、$R$ は利用可能な文字プールの基数（Character Pool Cardinality）です。

• ASCII 印字可能文字（全文字種）の場合: $R = 94$（大文字26 + 小文字26 + 数字10 + 記号32）
• 長さ 16 文字の場合：

$$H = 16 \times \log_2(94) \approx 16 \times 6.5546 \approx 104.9\text{ ビット}$$

• 総組み合わせ数：$94^{{16} \approx 3.71 \times 10}{31}$ パターン

• Diceware パスフレーズの場合:

語彙サイズ $|\mathcal{V}|$ の辞書から $W$ 個の独立した単語を選択し、追加の区切り文字や数値ソルト（$H_{\text{modifiers}}$）を付加した場合： $$H = W \times \log2(|\mathcal{V}|) + H{\text{modifiers}}$$ 例えば、厳選された 7,776 語（$6^5$ 通り、標準 Diceware リスト）の辞書から 6 単語を選択した場合、単語部分だけで $6 \times \log_2(7776) \approx 6 \times 12.92 \approx 77.5$ ビットの純粋なエントロピーが得られます。

さらに、ToolsAA のエントロピー評価エンジンは、同一文字が過剰に繰り返されることによる実効エントロピーの低下を検知する ユニーク率ペナルティ（Uniqueness Penalty） を適用します。重複文字の割合が異常に高い場合（$|\text{unique}| / L < 0.6$）、スコアを適切に減衰補正して過大評価を防止します。

# 5. ハードウェア攻撃経済性とクラック所要時間モデリング

攻撃者の計算資源とハッシュアルゴリズムの特性によって、パスワードのクラック速度は天文学的に異なります。現代の最新パスワードクラッキングリグ（例: 8台の NVIDIA GeForce RTX 4090 GPU を搭載したクラスタ）におけるハッシュ関数の計算能力の比較は以下の通りです：

• 高速・脆弱なハッシュ（NTLM, MD5）: 毎秒 2,000 億〜5,000 億試行（$5 \times 10^{11}\text{ hashes/sec}$）
• 標準的な暗号学的ハッシュ（SHA-256）: 毎秒 500 億〜1,000 億試行（$1 \times 10^{11}\text{ hashes/sec}$）
• 反復型鍵導出関数（PBKDF2-HMAC-SHA256, 10,000回反復）: 毎秒 100 万〜500 万試行（$5 \times 10^6\text{ hashes/sec}$）
• メモリ困難型アルゴリズム（Argon2id, bcrypt, scrypt）: 毎秒 数百〜数千試行（GPU の並列メモリアクセス帯域がボトルネックとなる）

$$\text{推定クラック所要時間 (秒)} = \frac{2^H}{\text{毎秒ハッシュ試行速度}}$$

ToolsAA は、最悪ケースの脅威モデルとして「ソルトなしの高速ハッシュに対して、専用 GPU クラスタが毎秒 $10^{{10} \sim 10}{11}$ 回の並列総当たり試行を行う」という過酷な攻撃シナリオを前提にクラック耐性を算出しています。

# 実践ステップバイステップ利用ガイド

ToolsAA の直感的な UI を活用し、要件に応じた最適な認証情報を数秒で安全に生成・配備する手順を解説します。

# ステップ 1: パスワード生成モード（アーキテクチャ）の選択

上部のモードセレクターから、用途に応じた生成プリセットを選択します：

• カスタムパスワード（Custom Password）: 英大文字・英小文字・数字・特殊記号を自由に組み合わせる標準的な英数字パスワード。WebサービスのアカウントやDBの認証情報に最適です。
• 記憶可能なパスフレーズ（Memorable Passphrase）: 人間が暗記しやすく入力しやすい、複数の独立した単語を連結する Diceware 方式。マスターキーやディスク暗号化パスフレーズに推奨されます。
• 数値PINコード（Numeric PIN）: 数字（0-9）のみで構成されるコード。ATM、スマートフォン画面ロック、二要素認証のバックアップコードに適しています。
• 開発者向けトークン（Developer Token）: 暗号学的に均一な 256 ビット Hex（16進数）、JWTシークレットに適した Base64URL、または RFC 4122 準拠の UUIDv4 を生成します。

# ステップ 2: 文字列長とエントロピーパラメータの精密調整

スライダーまたは数値入力フィールドを使用して、必要な長さを設定します：

• 一般 Web アカウント: 最低 16 文字（約 95〜105 ビットエントロピー）
• 本番データベース / SSH キー: 24〜32 文字（約 150〜200 ビットエントロピー）
• ルート暗号化鍵 / クラウドプロビジョニング: 48〜64 文字以上（300 ビット以上の不可逆強度）

必要に応じて、大文字（A-Z）、小文字（a-z）、数字（0-9）、特殊記号（!@#$%...）のチェックボックスをオン/オフします。

# ステップ 3: 類似・誤認文字（Ambiguous Characters）の除外設定

目視確認や手動タイピングが発生する環境（紙のリカバリーシートへの印刷、電話口での認証コード伝達、モバイル端末の仮想キーボード入力）では、「類似・誤認文字を除外（Avoid Ambiguous Characters）」 オプションを有効にします。 視覚的に混同しやすい 0（数字）と O / o（英字）、1（数字）と l（小文字エル）/ I（大文字アイ）/ |（パイプ記号）などのグリフが自動的にサンプリング対象から除外され、人為的な入力ミスをゼロにします。

# ステップ 4: 高エントロピー Diceware パスフレーズの設定

パスフレーズモードでは、単語数（4〜8単語）、単語の区切り文字（ハイフン -、アンダースコア _、ピリオド .、スペース）、単語の先頭を大文字化する TitleCase オプション、および末尾への数字・記号ソルトの自動付与をカスタマイズできます。

# ステップ 5: 開発者向け暗号トークン（Hex / Base64URL / UUIDv4）の生成

API ゲートウェイや JWT 署名鍵、セッション ID を作成する場合、トークン生成タブからダイレクトに 256 ビット（64 文字の Hex 文字列）や、URL クエリパラメータでエスケープ不要な Base64URL 文字列をワンクリックで生成します。

# ステップ 6: リアルタイム・エントロピーおよびクラック耐性の検証

パラメータ変更に伴い、ツール下部に以下のセキュリティ指標がリアルタイムで即座に再計算・表示されます：

• シャノンエントロピー値（Bits）: 理論上の情報量。
• 文字空間の総組み合わせ数（Combinations）: 指数表記による全探索パターンの総数。
• GPU クラスタによる推定クラック所要時間: $10^{11}\text{ hashes/sec}$ 規模での解読耐性年数。
• プール分布インジケーター: 各文字種が均等に割り振られているかの視覚的プロファイル。

# ステップ 7: 揮発性クリップボードコピーとセッション履歴の安全な管理

生成されたパスワードの横にある 「コピー（Copy）」 ボタンをクリックすると、モダン Web 標準である navigator.clipboard.writeText() を介してクリップボードに格納されます。 画面上に表示されるセッション生成履歴は、React の内部ステート（揮発性メモリ）にのみ保持され、ブラウザの localStorage や sessionStorage などの不揮発ストレージには一切書き込まれません。ブラウザのタブを閉じるかリロードした瞬間に、すべてのデータは完全に揮発・消去されます。

# 本番環境向けコード実装例

ToolsAA と同等の暗号論的ランダム性、剰余バイアスのない棄却サンプリング、フィッシャー–イェーツ・シャッフル、およびシャノンエントロピー計算を備えた実用コードを、TypeScript、JavaScript、Python 3.11+ で提供します。

# 1. モダン TypeScript 5.x 実装

/**
 * パスワード生成オプションの型定義
 */
export interface PasswordOptions {
  length: number;           // パスワードの長さ（推奨: 16文字以上）
  useUpper?: boolean;       // 英大文字 (A-Z) の使用フラグ
  useLower?: boolean;       // 英小文字 (a-z) の使用フラグ
  useNumbers?: boolean;     // 数字 (0-9) の使用フラグ
  useSymbols?: boolean;     // 記号 (!@#$%...) の使用フラグ
  avoidAmbiguous?: boolean; // 類似・混同文字 (0, O, 1, l, I 等) の除外フラグ
}

const UPPER = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
const LOWER = "abcdefghijklmnopqrstuvwxyz";
const DIGITS = "0123456789";
const SYMBOLS = "!@#$%^&*()_+-=[]{}|;:,.<>?~";
const AMBIGUOUS_CHARS = new Set(["0", "O", "o", "1", "l", "I", "|"]);

/**
 * 棄却サンプリング（Rejection Sampling）を用いて剰余バイアスを完全に排除した
 * 暗号論的一様乱数整数 [0, max - 1] を取得する関数
 */
export function getCryptoRandomInt(max: number): number {
  if (max <= 1) return 0;

  // 32ビット符号なし整数（0x100000000 = 2^32）の均等分割リミットを計算
  const limit = Math.floor(0x100000000 / max) * max;
  const buffer = new Uint32Array(1);
  let randomVal: number;

  // バイアスが発生する余剰区間の乱数が出た場合は破棄して再サンプリング
  do {
    window.crypto.getRandomValues(buffer);
    randomVal = buffer[0];
  } while (randomVal >= limit);

  return randomVal % max;
}

/**
 * 暗号論的に安全なパスワードを生成するメイン関数
 */
export function generateSecurePassword(opts: PasswordOptions): string {
  // 類似文字除外フィルター
  const filterAmbiguous = (charset: string) =>
    opts.avoidAmbiguous
      ? charset.split("").filter((c) => !AMBIGUOUS_CHARS.has(c)).join("")
      : charset;

  // 有効な文字プールの構築
  const activePools: string[] = [
    opts.useUpper !== false ? filterAmbiguous(UPPER) : "",
    opts.useLower !== false ? filterAmbiguous(LOWER) : "",
    opts.useNumbers !== false ? filterAmbiguous(DIGITS) : "",
    opts.useSymbols !== false ? filterAmbiguous(SYMBOLS) : "",
  ].filter((p) => p.length > 0);

  if (activePools.length === 0) {
    throw new Error("最低でも1つの文字種を選択する必要があります。");
  }

  // 1. 各文字プールから最低1文字をサンプリング（文字種ポリシーの充足を保証）
  const resultChars: string[] = activePools.map(
    (pool) => pool[getCryptoRandomInt(pool.length)]
  );

  // 全文字を統合したマスタープールを作成
  const combinedPool = activePools.join("");

  // 2. 指定された長さまでマスタープールから均等サンプリングして補充
  while (resultChars.length < opts.length) {
    resultChars.push(combinedPool[getCryptoRandomInt(combinedPool.length)]);
  }

  // 3. 暗号学的フィッシャー–イェーツ法による完全シャッフル（位置的偏りを完全排除）
  for (let i = resultChars.length - 1; i > 0; i--) {
    const j = getCryptoRandomInt(i + 1);
    [resultChars[i], resultChars[j]] = [resultChars[j], resultChars[i]];
  }

  return resultChars.join("");
}

/**
 * シャノン情報エントロピー（ビット単位）を計算する関数
 */
export function calculateEntropy(password: string): number {
  if (!password) return 0;

  let poolSize = 0;
  if (/[a-z]/.test(password)) poolSize += 26;
  if (/[A-Z]/.test(password)) poolSize += 26;
  if (/[0-9]/.test(password)) poolSize += 10;
  if (/[^a-zA-Z0-9]/.test(password)) poolSize += 32;

  // 基本シャノンエントロピー: H = L * log2(Pool)
  const baseEntropy = password.length * Math.log2(poolSize || 10);

  // ユニーク文字率によるペナルティ計算（同一文字の反復による強度偽装の防止）
  const uniqueCount = new Set(password).size;
  const uniquenessRatio = uniqueCount / password.length;

  const adjustedEntropy =
    uniquenessRatio < 0.6
      ? baseEntropy * Math.max(0.15, uniquenessRatio)
      : baseEntropy;

  return Math.round(adjustedEntropy * 10) / 10;
}

# 2. ネイティブ ブラウザ JavaScript (ES2022+ / Web Crypto API 準拠) 実装

外部ライブラリを一切使わず、モダンブラウザ環境でそのまま動作するゼロ依存（Zero-Dependency）のモジュール実装です。

/**
 * ブラウザネイティブの Web Crypto API を利用したパスワード生成モジュール
 */
export class BrowserCryptoPassword {
  static #UPPER = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
  static #LOWER = "abcdefghijklmnopqrstuvwxyz";
  static #DIGITS = "0123456789";
  static #SYMBOLS = "!@#$%^&*()_+-=[]{}|;:,.<>?~";
  static #AMBIGUOUS = new Set(["0", "O", "o", "1", "l", "I", "|"]);

  /**
   * 棄却サンプリングによる均一乱数インデックス生成
   * @param {number} max - 最大値（上限）
   * @returns {number} 0 から max - 1 までの均一な整数
   */
  static getRandomIndex(max) {
    if (max <= 1) return 0;
    const limit = Math.floor(0x100000000 / max) * max;
    const buf = new Uint32Array(1);
    let rand;
    do {
      window.crypto.getRandomValues(buf);
      rand = buf[0];
    } while (rand >= limit);
    return rand % max;
  }

  /**
   * 暗号論的に安全なパスワード文字列の生成
   */
  static create({
    length = 20,
    upper = true,
    lower = true,
    digits = true,
    symbols = true,
    avoidAmbiguous = true
  } = {}) {
    const filter = (str) =>
      avoidAmbiguous ? [...str].filter((c) => !this.#AMBIGUOUS.has(c)).join("") : str;

    const pools = [
      upper ? filter(this.#UPPER) : "",
      lower ? filter(this.#LOWER) : "",
      digits ? filter(this.#DIGITS) : "",
      symbols ? filter(this.#SYMBOLS) : ""
    ].filter(Boolean);

    if (pools.length === 0) throw new Error("少なくとも1つの文字種が必要です。");

    // 各プールから必ず1文字抽出
    const chars = pools.map((p) => p[this.getRandomIndex(p.length)]);
    const fullPool = pools.join("");

    // 残りの文字数を充填
    while (chars.length < length) {
      chars.push(fullPool[this.getRandomIndex(fullPool.length)]);
    }

    // フィッシャー–イェーツ法によるインプレース・シャッフル
    for (let i = chars.length - 1; i > 0; i--) {
      const j = this.getRandomIndex(i + 1);
      [chars[i], chars[j]] = [chars[j], chars[i]];
    }

    return chars.join("");
  }
}

# 3. Python 3.11+ 本番環境実装

Python の標準ライブラリ secrets モジュールは、OS カーネルのエントロピーソース（/dev/urandom や Windows CNG）を呼び出す CSPRNG ラッパーであり、暗号論的用途に最適化されています。

import math
import secrets
import string
from typing import Set

AMBIGUOUS_GLYPHS: Set[str] = set("0Oo1lI|")

def generate_secure_password(
    length: int = 24,
    use_upper: bool = True,
    use_lower: bool = True,
    use_digits: bool = True,
    use_symbols: bool = True,
    avoid_ambiguous: bool = True
) -> str:
    """
    OSカーネルエントロピー（secretsモジュール）とフィッシャー–イェーツ置換を用いた
    暗号論的に安全なパスワード生成関数
    """
    # 各文字種プールの定義
    candidate_pools = [
        (string.ascii_uppercase, use_upper),
        (string.ascii_lowercase, use_lower),
        (string.digits, use_digits),
        ("!@#$%^&*()_+-=[]{}|;:,.<>?~", use_symbols),
    ]

    active_pools = []
    for charset, enabled in candidate_pools:
        if enabled:
            filtered = (
                "".join(c for c in charset if c not in AMBIGUOUS_GLYPHS)
                if avoid_ambiguous
                else charset
            )
            if filtered:
                active_pools.append(filtered)

    if not active_pools:
        raise ValueError("最低でも1つの文字種プールを有効にする必要があります。")

    # 1. 各プールから1文字ずつ抽出し、文字種要件を保証
    selected_chars = [secrets.choice(pool) for pool in active_pools]

    # 2. 残りの文字を全文字プールの和集合から補充
    combined_pool = "".join(active_pools)
    remaining_length = length - len(selected_chars)
    selected_chars.extend(secrets.choice(combined_pool) for _ in range(remaining_length))

    # 3. secrets.randbelow() を用いた暗号学的フィッシャー–イェーツ・シャッフル
    for i in range(len(selected_chars) - 1, 0, -1):
        j = secrets.randbelow(i + 1)
        selected_chars[i], selected_chars[j] = selected_chars[j], selected_chars[i]

    return "".join(selected_chars)

def evaluate_password_entropy(password: str) -> float:
    """
    Claude Shannon の情報エントロピーの定義式に基づくビット計算関数
    """
    if not password:
        return 0.0

    pool_size = (
        (26 if any(c.islower() for c in password) else 0)
        + (26 if any(c.isupper() for c in password) else 0)
        + (10 if any(c.isdigit() for c in password) else 0)
        + (32 if any(not c.isalnum() for c in password) else 0)
    )

    base_entropy = len(password) * math.log2(max(pool_size, 10))

    # ユニーク文字率による過大評価ペナルティの適用
    unique_ratio = len(set(password)) / len(password)
    if unique_ratio < 0.6:
        base_entropy *= max(0.15, unique_ratio)

    return round(base_entropy, 1)

if __name__ == "__main__":
    # 使用例: 24文字のセキュアパスワード生成と強度評価
    pwd = generate_secure_password(length=24, avoid_ambiguous=True)
    entropy_bits = evaluate_password_entropy(pwd)
    print(f"生成されたパスワード: {pwd}")
    print(f"情報エントロピー: {entropy_bits} bits")

# よくある落とし穴・エッジケースとトラブルシューティング

セキュアな認証基盤を構築する際、エンジニアが遭遇しやすい典型的な設計ミスと回避策を詳解します。

# 1. Math.random() の使用による暗号学的脆弱性

フロントエンドや Node.js アプリケーションで Math.random().toString(36) を用いて一時トークンや初期パスワードを生成するアンチパターンが散見されます。前述の通り、V8 内部の XorShift128+ アルゴリズムは非暗号学的であり、生成されたトークンが公衆の目に触れた場合、攻撃者は内部状態を復元して他のユーザーのセッショントークンやパスワードリセットトークンを先回りして推測・乗っ取ることが可能です。認証や機密保持に関わる文字列生成には、必ず window.crypto.getRandomValues() または crypto.randomBytes() を使用してください。

# 2. 自作乱数スクリプトにおける剰余バイアス（Modulo Bias）の潜在

「0 から文字数までのインデックスを得る」ために Math.floor(random * pool.length) や randomUint % pool.length を無邪気に行うと、数学的な剰余バイアスによって特定文字の出現確率が偏ります。パスワード空間の特定の枝が統計的に太くなる現象は、辞書攻撃ツールによる最適化攻撃に直結します。必ず棄却サンプリングを導入し、均等な $1/N$ 分布を維持してください。

# 3. 文字種強制時のシーケンシャル配置アンチパターン

「大文字を1文字、小文字を1文字、数字を1文字、記号を1文字」というパスワードポリシーを実装する際、res = [upper[rnd], lower[rnd], digit[rnd], sym[rnd], ...] のように生成し、シャッフルを省略すると、「先頭は大文字、2文字目は小文字、3文字目は数字…」という致命的な配置パターンが固定化されます。Hashcat などのツールでは、こうした文字種マスク（Mask）を指定することで探索空間を $10^{15}$ 分の 1 以下に圧縮して瞬時に突破することが可能です。文字列構築後の Fisher-Yates シャッフルを絶対に省略してはなりません。

# 4. 特殊文字のエスケープ問題・シェル展開・DBエンコーディング

記号文字の選定には、システムのパーサーやインフラ構成上の互換性を考慮する必要があります：

• Bash / Shell 展開: $（環境変数展開）、` `（コマンド置換）、!（ヒストリ展開）、\`（エスケープ）がパスワードに含まれていると、Docker Compose や CI/CD スクリプトでの環境変数引き渡し時に構文エラーや意図しないコマンド実行を引き起こします。
• YAML / JSON 設定ファイルのパースエラー: コロン : の直後にスペースが入ったり、二重引用符 " やシングル引用符 ' が含まれると設定パーサーがクラッシュする原因になります。
• MySQL のレガシー utf8 カラム問題: 一部のパスワード生成ツールが 4 バイトの絵文字を混ぜる場合がありますが、MySQL の旧 utf8 文字セット（最大 3 バイト）を使用しているデータベースでは、絵文字以降の文字列がサイレントに切り捨てられ、重大な認証バグを招きます。

環境変数やインフラ設定ファイルに組み込む場合は、ToolsAA の 「URL & Shell Safe」 プリセット（英数字と _, -, ., ~ のみ）の活用を強く推奨します。

# 5. メモリ残留とクリップボード監視マルウェアへの対策

生成したパスワードをクリップボードにコピーしたまま長時間放置すると、バックグラウンドで動作する常駐型クリップボード監視ツールや悪意あるブラウザ拡張機能によって平文データが盗み見られるリスクが生じます。

• 本番運用のパスワードマネージャーでは、クリップボードの自動消去タイマー（30〜60秒）を有効に設定してください。
• ToolsAA はブラウザのメモリ上にのみデータを展開し、localStorage や sessionStorage などのブラウザ不揮発ストレージには一切永続化しません。

# 6. 定期的なパスワード強制変更（定期ローテーション）というアンチパターン

四半期ごと（90日ごと）のパスワード変更を従業員に義務付けるポリシーは、NIST SP 800-63B において「有害なプラクティス」として正式に廃止が勧告されています。強制変更は、末尾の数字をインクリメントするだけ（Tokyo2025# $\to$ Tokyo2026#）の形骸化を招き、セキュリティを著しく脆弱化させます。十分な長さ（16文字以上）を持つ暗号学的パスワードを策定し、多要素認証（MFA / FIDO2 / Passkeys）を必須化した上で、漏洩インシデント発生時のみ変更を行う運用が現代の国際標準です。

# 詳細FAQセクション

日本のエンジニアやセキュリティ担当者が検索・検討する頻度の高い核心的な疑問に回答します。

# Q1: なぜ crypto.getRandomValues() は安全で、Math.random() は危険なのですか？

回答: Math.random() は擬似乱数アルゴリズム（V8 の XorShift128+ 等）による計算値であり、内部状態がわずか 128 ビットしかありません。攻撃者が過去の出力を観測することで内部シードを逆算し、将来および過去の数値を 100% 予測することが可能です。一方、window.crypto.getRandomValues() は、OS カーネルが収集した物理的ハードウェアノイズ（CPUジッター、熱雑音、パケット割り込み等）に基づく 256 ビット以上の暗号学的エントロピープールに直結しているため、数学的に予測が不可能です。

# Q2: 剰余バイアス（Modulo Bias）とは何であり、ToolsAA はどのように排除していますか？

回答: 32 ビット整数の全空間（$2^{{32} = 4,294,967,296$ 通り）は、一般的な文字プール数 $N$（例: 94文字）で割り切れません。そのため、単純に rand % N を行うと、$2}{32} \bmod N$ 個のインデックスの出現確率が他のインデックスよりもわずかに高くなってしまいます。ToolsAA は「棄却サンプリング」を導入し、$R \ge \lfloor 2^{32} / N \rfloor \times N$ となる余剰領域の乱数を破棄して再サンプリングすることで、すべての文字の出現確率を厳密に $P(x) = 1/N$ の均一状態に保っています。

# Q3: 現代の GPU クラスタによる総当たり攻撃を防ぐには、何ビットのエントロピーが必要ですか？

回答: 一般的な Web アプリケーションのログインフォーム（適切なレートリミットとアカウントロックアウトが存在する場合）であれば 60 ビット程度で防衛可能です。しかし、データベースダンプが漏洩し、高速ハッシュ（MD5 / NTLM）に対して最新 GPU クラスタ（毎秒数千億回試行）でオフラインクラッキングが行われる最悪の事態を想定する場合、最低でも 80 ビット以上、エンタープライズ基準としては 100〜128 ビット以上（英数記号混在で16〜20文字以上）が必須です。100 ビットを超えると、全宇宙の計算資源を投じてもクラックに数億年を要するため、物理的に解読不能となります。

# Q4: 6単語の Diceware パスフレーズは、ランダムな12文字の英数字パスワードより本当に安全ですか？

回答: はい、数学的に明確に安全です。一般的な 12 文字の英数字・記号パスワード（プール94文字）のエントロピーは $12 \times \log2(94) \approx 78.6$ ビットです。一方、7,776 語のリストから選ばれた 6 単語の Diceware パスフレーズのエントロピーは $6 \times \log2(7776) \approx 77.5$ ビットであり、ほぼ同等です。さらに、単語間に区切り記号や数字を混ぜることで 85 ビット以上に達します。何より、Diceware は人間が自然言語のイメージとして記憶できるため、メモ帳への平文記録や付箋への書き置きといった人為的漏洩を大幅に防ぐ利点があります。

# Q5: なぜサーバーサイドのオンライン生成ツールでパスワードを生成してはいけないのですか？

回答: サーバーサイドで生成する Web サイトでは、生成された秘密情報が HTTP 通信を通じてサーバーからクライアントへ返送されます。この過程で、リバースプロキシのログ、CDN のキャッシュ、クラウドの監視ログ（APM）、WAF のペイロード履歴などに平文パスワードが残存するリスクが常に存在します。ToolsAA は完全クライアントサイド（"use client"）で動作し、ブラウザの Web Crypto API のみを用いてローカルメモリ内で生成するため、サーバー通信は一切発生せず、第三者によるログ傍受が原理的に不可能です。

# Q6: ToolsAA はどのようにクラック所要時間を計算しており、どのような攻撃モデルを想定していますか？

回答: ToolsAA は、最も過酷なオフライン総当たり攻撃シナリオ（ソルトなしのハッシュ値を入手した攻撃者が、ハイエンド GPU クラスタを用いて毎秒 $10^{{10} \sim 10}{11}$ 回のハッシュ計算を並列実行する環境）をモデル化しています。パスワードの文字空間の総組み合わせ数（$2^H$）をこの試行速度で除算し、50% の確率で解読に至るまでの平均時間を算出しています。

# Q7: 誤認文字（Ambiguous Characters）とは何であり、なぜ除外すべきなのですか？

回答: 視覚的に類似しており、フォントによって区別が困難な文字（数字の 0 と英大文字 O・小文字 o、数字の 1 と小文字 l・大文字 I・記号 | など）を指します。これらを除外しても、文字プールが 94 から 87 に減少する程度であり、エントロピーの低下は 1 文字あたりわずか 0.1 ビット程度に過ぎません。一方で、手動タイピング時の入力ミスや認証失敗によるアカウントロックアウトを劇的に低減できるため、実務において非常に有効な設定です。

# Q8: ToolsAA は生成されたパスワードを保存、送信、またはキャッシュしていますか？

回答: 一切行いません。ToolsAA は「プライバシー・ファースト」のアーキテクチャ設計を絶対の原則としています。すべての生成処理はブラウザのローカル JavaScript 実行スレッド内でのみ完結します。クッキー、ローカルストレージ、外部アナリティクス、遠隔データベースへのシークレット送信はゼロです。ブラウザのタブを閉じるかリロードした瞬間、生成されたデータはガベージコレクションによってメモリから完全に消滅します。

# 技術仕様比較マトリクス：標準構成一覧

実務における各ユースケースの推奨パラメータ、文字プール規模、情報エントロピー、および耐性評価の標準マトリクスです。

# 総括・まとめ

ゼロトラストモデルが標準となった現代のクラウドネイティブ環境において、認証シークレットの強度はシステム全体の安全性を左右する最重要ファクターです。安易なパスワード生成スクリプトや予測可能な乱数は、多重防衛（Defense in Depth）の境界を内側から崩壊させ、データベースやバックエンド基盤を不正アクセスの危機に晒します。

旧来の形骸化した「90日ごとの強制定期変更」や「記号の機械的強制」を脱却し、NIST SP 800-63B に準拠した「十分な長さの確保」と「暗号学的ランダム性」を軸としたセキュリティ運用への刷新が求められています。W3C 標準の Web Crypto API による OS カーネルエントロピーの直接取得、剰余バイアスを数学的にゼロにする棄却サンプリング、空間的偏りを排除する Fisher-Yates シャッフル、そして Claude Shannon の情報理論に基づくエントロピー評価を組み合わせることで、いかなる GPU クラスタによる総当たり攻撃にも屈しない鉄壁の認証基盤が実現します。

ToolsAA 暗号論的に安全なパスワード自動生成ツール は、これら最高峰の数学的厳密性と、サーバー通信を完全に排除した 100% クライアントサイド・プライバシーアーキテクチャを両立しています。本番インフラの構築、API キーの払い出し、日々のセキュリティ管理において、一切のデータ漏洩リスクなしに、最高水準の認証シークレットを安心して生成・運用してください。