入力データはサーバーに送信されますか?

いいえ。すべてブラウザ内で完結します。生成されたパスワードは画面表示・クリップボードコピーのみで、外部に送信もログ記録もされません。

なぜ「発音可能」が便利?

**口に出して読める = 短期記憶に残しやすい**。`x7@K!w` を電話越しに伝えるのは大変ですが、`MofeJivo23` は「mo-fe-ji-vo-にじゅうさん」と音節で言えるので確実に伝わります。Wi-Fi のゲスト用パスワード、新人さんへの初期発行、会議室の入室コードなど、**人間がスマホに直打ちする・口頭で伝える** 場面に最適。

セキュリティは大丈夫?

**乱数源**: `crypto.getRandomValues` を使用 (Web Crypto API、暗号学的に安全)。Math.random は使いません。**エントロピー**: 12 文字 + 数字 2 桁の標準設定で約 45 bit、これは 2^45 ≒ 35 兆通りで、オフライン辞書攻撃にもしばらく耐えます (ただし暗号鍵の用途には 80+ bit 推奨)。**注意**: 発音可能パターンは完全ランダムより 1 文字あたりのエントロピー (4.4 bit) が低く、同じ文字数の `password-generate` の完全ランダム (95 文字、6.6 bit/char) より弱いので、要求されるセキュリティレベルに応じて使い分けてください。

「子音 + 母音」のパターンって?

**CV 交互パターン**: `子音 → 母音 → 子音 → 母音 → ...` の順で文字を選び、自然に音節として読めるようにしています (例: `ka-ri-po`)。母音は a / e / i / o / u の 5 文字、子音は b / c / d / f / g / h / j / k / l / m / n / p / q / r / s / t / v / w / x / y / z の 21 文字 (大文字化オンの時は両方の大文字も含む)。`r` の後に `l` が来るような発音しにくい連続子音は出ません (必ず C V の交互)。

なぜ末尾に数字や記号?

**ポリシー対応**: 多くのサイトの「数字 1 つと記号 1 つを含むこと」というパスワード要件を満たすため、末尾に固定で追加できるようにしました。**先頭ではなく末尾** にする理由: 音節として読みやすい本体を壊さないため。数字 0 桁 + 記号 OFF にすれば純粋な CV 列だけが出ます。

大文字化って 1 文字目だけ?

本ツールの実装では **4 文字 (= 2 音節 = CV CV) ごとに 1 つの大文字** を入れます (`KaRiPoMu`)。各音節ペアの最初の子音だけ大文字化することで、見た目にメリハリがありつつ発音は崩れません。トグル OFF にすると全部小文字 (`karipomu`)。

覚えやすさで言うと何文字くらいがおすすめ?

**音節 3〜4 つ (6〜8 文字) + 数字 2〜4 桁** が記憶可能性とエントロピーのバランス良いゾーン。例: `MofeJivo + 2347` = 60 bit、十分強くてかつ覚えられる。一度に 5〜10 件生成して、一番気に入った響きのものを選ぶワークフローがおすすめ。

完全ランダムの方が安全じゃないの?

**bit/char では完全ランダムが勝ち** ですが、人は完全ランダム文字列を覚えられないので結局メモして使い、メモが流出すると本末転倒。**人間が口頭/手書きで扱う場面では発音可能パスワードの方が運用上安全** という考え方があります (NIST SP 800-63B でも記憶しやすさを評価)。サーバー API キーやプログラム間通信には完全ランダムを、人が打鍵/口伝するパスワードには発音可能を、と使い分け。

再現性 (シード) ありますか?

**意図的にありません**。乱数源を固定すると、知っているだけで全パスワードを再構成できてしまうため、暗号学的乱数 (毎回 OS のエントロピープール) を使っています。再現可能な「予測可能なパスワード」は安全性が無いので本ツールではサポートしません。

開発へ戻る

発音可能パスワード生成 (CVCV パターン・覚えやすい)

**子音 + 母音** (CV) を交互に組み合わせて、**口に出して読める** パスワードを生成。`Karipo23` `MofeJivo` のように音節として認識でき、`x7@K!w` のようなランダム文字列より格段に記憶しやすい。長さ 4〜32 文字、末尾に数字 0〜4 桁 / 記号 1 文字を追加可能、CV ペアごとの先頭大文字化トグル付き。**`crypto.getRandomValues`** で暗号学的に安全な乱数を使用、entropy (探索空間 bit 数) も表示。一度に最大 50 件まとめて生成可能 (見比べて気に入った 1 つを採用するワークフローに最適)。

開発生成

使い方

**子音 + 母音** (CV) を交互に並べた **音節として読める** パスワードを生成。`Karipo23` / `MofeJivo` のように口に出して読めるので、ランダム英数字列より格段に記憶しやすい。長さ (4〜32 文字)、末尾数字 (0〜4 桁)、末尾記号 (1 文字)、音節先頭の大文字化、一度の生成件数 (1〜50) を調整可能。乱数は **`crypto.getRandomValues`** を使うので暗号学的に安全 (`Math.random` は使わない)。**エントロピー** (探索空間の bit 数) を各パスワードの右に表示し、40 未満 = 弱い、40-60 = 普通、60-80 = 強い、80+ = 非常に強い、で色分け。Wi-Fi パスワード・初期 PIN・社内システムの一時パスワードなど、**人間が読み上げる前提** の場面で重宝。

詳細解説

口頭で伝えるパスワードが持つ固有のリスク

発音可能パスワードは、人が口頭で読み上げる・電話越しに伝える・手書きでメモするといった用途のために設計されます。Wi-Fi のゲスト用パスワード、新入社員への初期発行、会議室の入室コードなど、「人が直接扱う」場面が前提です。このような経路では、パスワード本体がネットワーク外の音声や紙の上を流れます。

この用途の逆説的なリスクは、「覚えやすいから口頭で伝えやすい」ことで生成・伝達・入力のサイクルが増えることです。何度も使い回しやすく、複数の人が知っていることが多い。生成の段階でさらに外部サービスが介在すれば、伝達経路がオフラインだけでなくオンラインにも広がります。

オンラインの発音可能パスワード生成ツールが持つ構造的問題

「pronounceable password generator」で検索して出るサービスでは、生成リクエストがサーバーに届きます。生成されたパスワードは HTTP レスポンスに含まれ、サービス側のログに記録される可能性があります。HTTPS で経路は暗号化されていても、サービス運営者はリクエストとレスポンスの両方を確認できます。

発音可能パスワードは Wi-Fi キーや初期 PIN として使われることが多く、同じパスワードが長期間使い続けられる傾向があります。生成時点でサーバーログに記録されたパスワードは、後のデータ漏洩時に有効な状態で流出するリスクがあります。ランダム文字列より短命に使われる完全ランダムパスワードと比べて、露出期間が長い点に注意が必要です。

crypto.getRandomValues と CV 交互テーブルでブラウザ内完結

このツールは子音 21 文字 (b/c/d/f/g/h/j/k/l/m/n/p/q/r/s/t/v/w/x/y/z) と母音 5 文字 (a/e/i/o/u) の静的テーブルをページバンドルに持ちます。乱数源は Web Crypto API の crypto.getRandomValues() で、OS のエントロピープールから暗号学的に安全な乱数を取得します。Math.random() (セキュリティ用途に不適切な疑似乱数) は使いません。モジュロバイアスを避けるための棄却サンプリングも実装しています。

生成されたパスワードはページメモリにのみ存在し、ネットワーク送信は一切発生しません。DevTools の Network タブを開いた状態で生成操作を行っても、リクエストが発生しないことを確認できます。コードは GitHub で公開されており、外部 API 呼び出しが無いことを実装レベルで監査できます。

発音可能パスワードの運用上の使いどころ

完全ランダム文字列は 1 文字あたりのエントロピー (最大約 6.6 bit) が高い反面、人間には覚えられず、手書きや口頭での伝達でミスが起きやすい。発音可能パスワードは 1 文字あたり約 4.4 bit と低いですが、正確に伝達できる確率が高い。NIST SP 800-63B でも記憶しやすさを評価しており、人が扱う場面での運用上の安全性を認めています。

用途別の使い分けとして、サービス間 API キーや証明書の秘密鍵には完全ランダムの password-generate を、Wi-Fi ゲストパスワード・新人への初期 PIN・会議室コードなど人が口頭や手書きで扱うものには発音可能パスワードを選ぶのが合理的です。12 文字 + 数字 2 桁の構成で約 45 bit。エントロピーが不足すると感じるなら文字数を増やして補います。

FIPS 181 と発音可能パスワード生成アルゴリズムの歴史

発音可能パスワードの自動生成は意外に古い研究領域で、米国標準 FIPS 181 (Automated Password Generator、1993 年公開、2015 年廃止) が最も知られたアルゴリズムを定義しています。FIPS 181 は (a) 英語の音素 (digram + trigram) の出現確率テーブルを使い、(b) Markov chain 風の状態遷移で「英語らしい単語」を生成、(c) ANSI X3.92 (DES) の擬似乱数源を使う、という設計でした。その後 NIST SP 800-63B (2017) で FIPS 181 自体は廃止されましたが、「人間が記憶しやすいパスワード」の概念は EFF Dice Wordlist (Diceware) のような passphrase 方式に発展しています。

本ツールは FIPS 181 の音素モデルほど複雑ではなく、より単純な CVCV (子音 + 母音の交互) パターンを採用しています。21 個の子音 × 5 個の母音 = 105 通りの CV ペアを基本単位とし、N 個の CV ペアを連結することで N × log2(105) ≈ 6.71 × N bit のエントロピーを得ます。FIPS 181 のような英語音素モデルは生成パスワードが英単語に近づくため辞書攻撃のリスクが微増しますが、CVCV モデルは英語の音素分布と独立した一様分布のため、辞書攻撃に対しても理論的なエントロピーを保ちます。本ツールが CVCV を選ぶ理由はこの「読みやすさと辞書非依存性のバランス」です。

Diceware / passphrase との比較とハイブリッド運用

発音可能パスワードの代替として広く使われるのが Diceware (EFF wordlist) です。これは 7776 個の英単語リスト (= 6^5 通り、サイコロ 5 回振り) からランダムに 6-8 個選んで連結する方式で、correct horse battery staple (XKCD 936) のようなパスフレーズを作ります。1 単語あたり log2(7776) ≈ 12.92 bit のエントロピーを得るため、6 単語で約 77 bit と本ツールの 12 文字 (約 80 bit) に近い強度を得られます。日本語向けには Diceware 日本語版 (松崎達彦氏が公開) もあります。

Passphrase の利点は (a) 単語単位なので口頭伝達でのミスが少ない、(b) タイピングが速い、(c) 暗記しやすい、ですが、(d) パスワードフィールドの長さ制限 (古いシステムだと 16 文字以下) で入力できないことがあり、(e) スペースを許容しないシステムも多く、(f) ブランドや内輪ネタで覚えやすくしようとすると安全性が下がります。本ツールの CVCV パスワードは長さ制限のあるシステムにも入り、Wi-Fi の WPA2 PSK や会議室コードのように「短い、覚えやすい、口頭伝達」が必要な場面に特化しています。両者は競合ではなく補完で、本ツールで生成したパスワードを Bitwarden / 1Password などのマネージャーで保存し、本当に記憶が必要な「マスターパスワード」だけ Diceware で作る、という運用が実用的です。生成した発音可能パスワードのエントロピー / 弱点を確認したい場合は password-strength-check も併用できます。

よくある質問

入力データはサーバーに送信されますか?: いいえ。すべてブラウザ内で完結します。生成されたパスワードは画面表示・クリップボードコピーのみで、外部に送信もログ記録もされません。
なぜ「発音可能」が便利?: **口に出して読める = 短期記憶に残しやすい**。`x7@K!w` を電話越しに伝えるのは大変ですが、`MofeJivo23` は「mo-fe-ji-vo-にじゅうさん」と音節で言えるので確実に伝わります。Wi-Fi のゲスト用パスワード、新人さんへの初期発行、会議室の入室コードなど、**人間がスマホに直打ちする・口頭で伝える** 場面に最適。
セキュリティは大丈夫?: **乱数源**: `crypto.getRandomValues` を使用 (Web Crypto API、暗号学的に安全)。Math.random は使いません。**エントロピー**: 12 文字 + 数字 2 桁の標準設定で約 45 bit、これは 2^45 ≒ 35 兆通りで、オフライン辞書攻撃にもしばらく耐えます (ただし暗号鍵の用途には 80+ bit 推奨)。**注意**: 発音可能パターンは完全ランダムより 1 文字あたりのエントロピー (4.4 bit) が低く、同じ文字数の `password-generate` の完全ランダム (95 文字、6.6 bit/char) より弱いので、要求されるセキュリティレベルに応じて使い分けてください。
「子音 + 母音」のパターンって?: **CV 交互パターン**: `子音 → 母音 → 子音 → 母音 → ...` の順で文字を選び、自然に音節として読めるようにしています (例: `ka-ri-po`)。母音は a / e / i / o / u の 5 文字、子音は b / c / d / f / g / h / j / k / l / m / n / p / q / r / s / t / v / w / x / y / z の 21 文字 (大文字化オンの時は両方の大文字も含む)。`r` の後に `l` が来るような発音しにくい連続子音は出ません (必ず C V の交互)。
なぜ末尾に数字や記号?: **ポリシー対応**: 多くのサイトの「数字 1 つと記号 1 つを含むこと」というパスワード要件を満たすため、末尾に固定で追加できるようにしました。**先頭ではなく末尾** にする理由: 音節として読みやすい本体を壊さないため。数字 0 桁 + 記号 OFF にすれば純粋な CV 列だけが出ます。
大文字化って 1 文字目だけ?: 本ツールの実装では **4 文字 (= 2 音節 = CV CV) ごとに 1 つの大文字** を入れます (`KaRiPoMu`)。各音節ペアの最初の子音だけ大文字化することで、見た目にメリハリがありつつ発音は崩れません。トグル OFF にすると全部小文字 (`karipomu`)。
覚えやすさで言うと何文字くらいがおすすめ?: **音節 3〜4 つ (6〜8 文字) + 数字 2〜4 桁** が記憶可能性とエントロピーのバランス良いゾーン。例: `MofeJivo + 2347` = 60 bit、十分強くてかつ覚えられる。一度に 5〜10 件生成して、一番気に入った響きのものを選ぶワークフローがおすすめ。
完全ランダムの方が安全じゃないの?: **bit/char では完全ランダムが勝ち** ですが、人は完全ランダム文字列を覚えられないので結局メモして使い、メモが流出すると本末転倒。**人間が口頭/手書きで扱う場面では発音可能パスワードの方が運用上安全** という考え方があります (NIST SP 800-63B でも記憶しやすさを評価)。サーバー API キーやプログラム間通信には完全ランダムを、人が打鍵/口伝するパスワードには発音可能を、と使い分け。
再現性 (シード) ありますか?: **意図的にありません**。乱数源を固定すると、知っているだけで全パスワードを再構成できてしまうため、暗号学的乱数 (毎回 OS のエントロピープール) を使っています。再現可能な「予測可能なパスワード」は安全性が無いので本ツールではサポートしません。

「送らない」を確かめるには

このツールは入力データを外部に送信しません。仕組み・監査手順・運営方針は以下で詳しく説明しています。

類似のツール

パスワード生成 — 強度 / 文字種 / 桁数指定

強いランダムパスワードを 1〜25 件まとめて生成できます。長さ・文字種・紛らわしい文字の除外を選択可。crypto.getRandomValues ベースでブラウザ内処理。

開発セキュリティ生成

パスワード強度チェック (zxcvbn によるスコア / 推測時間 / 改善案)

Dropbox 由来の `zxcvbn-ts` (MIT) をブラウザ内で実行し、パスワードの推測難易度を 0〜4 のスコア / エントロピー (log2 換算) / 推測回数 / 4 種類の攻撃シナリオでの推定突破時間 / 検出された弱点パターン (辞書 / 連続 / 反復 / 日付 / 鍵盤シーケンス / leet 変形) を表示します。改善案は『大文字を混ぜる』『よく使われる単語を避ける』などフィードバック形式で日英対応。表示と切替で入力フィールドはマスク表示 (目アイコンでトグル) +『紛らわしい文字 (i/l/1/L/o/0/O) を強調表示』オプション。入力したパスワードはブラウザ内処理のみ、ネットワークに送信しません。

開発セキュリティ

UUID 生成 — v4 / v7 をまとめて発行

UUID v4 (完全ランダム) と UUID v7 (タイムスタンプ付き) を 1〜100 件まとめて生成できます。crypto.getRandomValues ベースでブラウザ内処理。

開発生成

バーコード生成 — JAN / EAN / UPC / CODE128 / CODE39

数字や文字列を 1 次元バーコード (JAN-13 / EAN-13・JAN-8 / EAN-8・UPC-A・CODE128・CODE39・ITF・Codabar/NW-7・MSI) に変換し、PNG / SVG として保存できます。バーの太さ・高さ・色・余白や、下部の数字表示の有無を細かく調整可能。チェックディジットの検証も自動で行います。生成はすべてブラウザ内で完結し、入力した値が外部に送信されることはありません。

開発生成画像