英数字：定義、暗号化における使用法、セキュリティ

62。これは、「英数字のみを使用する」という条件で使用できる異なる記号の総数です。大文字が26個、小文字が26個、数字が10個です。大文字と小文字を区別しない場合、数は36個に減ります。これらの数字はどちらも重要です。なぜなら、ウォレットアドレス、Wi-Fiパスワード、トランザクションハッシュ、GitHubトークンなど、これまで入力したほぼすべてのデジタル識別子は、これら62個の記号の中から選択されたサブセットから構成されているからです。

どのサブセットを選択するか、そしてその理由は、ほとんどの解説者が省略している部分です。しかし、それは英数字の百科事典的な定義と、仮想通貨ウォレットの実際のセキュリティを結びつける重要な部分でもあります。この記事では、文字数、その背後にある標準、現代の暗号技術がどのようにサブセットを選択するか、そして米国のパスワードに関する国家機関が現在それについてどのように述べているかを解説します。その指針の中には、ほとんどのセキュリティアドバイスがまだ追いついていない変更点もあります。

英数字とは何か？定義と数え方

まずは定義から始めましょう。英数字とは、A～Zのアルファベット（大文字・小文字どちらでも可）または0～9の数字のことです。それだけです。あとは計算が簡単です。大文字・小文字を区別すると、アルファベットは26文字、数字は10文字なので、62文字になります。大文字・小文字を区別しない場合は36文字です。それ以外の文字はすべて「特殊文字」です。句読点、空白、数式記号、アクセント付き文字、絵文字などは、英数字には含まれません。

エンジニアは通常、2 つの省略形のいずれかを使用して定義を満たします。 grep、sed、awk などの POSIX ツールは、上記の 62 文字に一致する `[:alnum:]` を認識します。ほとんどの最新の正規表現 (Python、JavaScript、Java、PCRE) は代わりに `\w` を使用します。 `\w` の落とし穴は、アンダースコアがこっそり挿入されることです。アンダースコアは正式には英数字ではありません。ほとんどのプログラミング構文では名誉文字として扱われるため、Stripe キーのプレフィックス `sk_live_` や AWS キーのプレフィックス `AKIA` では、アンダースコアと大文字が数字と混在していても誰も気にしません。

この用語はどこから来たのでしょうか？意外なことに、パンチカードです。1930年代のIBMの集計機器では、文字と数字が混在するコードを表す単一の単語が必要で、「英数字」という言葉が定着しました。1960年代初頭のIBM 1401の頃には、この言葉はビジネスコンピューティングにおける標準的な用語となっていました。この区別は実際に有効で、「英数字」と宣言されたフィールドは任意の文字または数字を受け入れ、数字のみのフィールドはアルファベットを完全に拒否しました。そこからこの言葉は、ナンバープレート、IBAN銀行コード、電話のキーパッドの覚え方、製品のSKUなど、その他多くの場所に広まっていきました。

大文字と小文字を区別するかしないかの違いは、見た目以上に重要です。大文字の使用を許可すると、パスワードのエントロピーは2倍になります。ビットコインのBase58アドレスは、意図的に大文字と小文字の両方を保持しています。Bech32は、意図的に大文字と小文字を区別しません。これらの選択はすべて、表現力と人為的ミスとのトレードオフです。間違った選択をすると、入力ミスで人々が金銭を失うことになります。

ASCIIからUnicodeへ：簡潔な技術史

「英数字表記」は、60年にも及ぶ標準化戦争を生き延びた生き残りである。ほとんどのユーザーはその渦中に巻き込まれ、そのことに気づかなかった。

ASCIIが最初に登場しました。1963年にアメリカ規格協会（ANSA）の協力のもと出荷され、5年後の1968年にANSI X3.4-1968として正式に規格化されました。その後、1977年と1986年に2回の改訂が行われました。1968年版では、大文字のAは65番、小文字のaは97番、数字の0～9は48～57番に割り当てられていました。今すぐエディタを開いてみてください。バイト「A」は今も65番です。60年間、何も変わっていません。

約40年間、ASCII英数字セットが唯一の英数字セットでした。その後、グローバルウェブが登場しました。7ビットではもはや十分ではなくなりました。障害の形態は醜悪でした。文字化けしたメール、壊れたデータベース、東京では完璧に動作する日本のウェブサイトが、米国のノートパソコンでは疑問符の壁のように見えるなどです。1991年にUnicodeが登場し、壮大な野望を掲げました。それは、これまで誰かが書いたすべての文字、すべてのスクリプトのすべての文字に固有の番号を割り当てることでした。1992年には、Unicodeを通常のネットワークで実際に伝送するエンコーディングとしてUTF-8が登場しました。その秘訣は下位互換性でした。UTF-8の最初の128コードポイントは、1968年のオリジナルのASCIIバイトと全く同じです。1991年以前に送信された英語のテキストは、永久に動作し続けました。

この転換は2007年12月に起こりました。その月、公開されたウェブクロール統計で、UTF-8がオンラインで最も一般的なエンコーディングとしてASCIIを上回ったことがついに明らかになりました。それ以降、「英数字」は厳密には62個のASCII記号だけを意味するものではなくなりました。現在、Unicodeはキリル文字、ギリシャ文字、アラビア文字、ヘブライ文字、そしてCJK文字の英数字ブロックをカタログ化しています。それぞれの文字体系には、独自の文字と数字が用意されています。

しかし実際には、国境を越える必要のあるソフトウェアは、依然としてオリジナルのASCIIサブセットをデフォルトとして使用します。ラテン文字のA～Z、アラビア数字の0～9。それ以外はありません。理由は単純です。すべてのキーボードはASCIIを出力し、すべてのデータベースはASCIIを受け入れ、すべての正規表現エンジンはASCIIを認識します。この範囲から外れると、エンコードの誤り、類似文字、そして後述するフィッシング攻撃といった問題に直面することになります。

暗号における英数字：アドレス、ハッシュ、シード

一般的な解説では見落とされがちな点ですが、暗号通貨システムは62文字の英数字すべてを使用するわけではありません。厳選されたサブセットを使用するのです。それぞれのサブセットは、恣意的な美的感覚に基づくものではなく、文書化された技術的な妥協の産物です。

まずはビットコインから。従来のビットコインアドレス（1または3で始まるアドレス）はBase58でエンコードされています。このアルファベットはサトシ・ナカモトが手作業で設計しました。手順は次のとおりです。62文字の英数字セットから4文字を削除します。削除するのは、数字のゼロ、大文字のO、大文字のI、小文字のlです。なぜこの4文字なのか？付箋に下手な字で書いてみてください。そのまま放置します。5分後に戻ってきます。それらを区別しようとしてみてください。できません。これがBase58が解決するために作られた問題全体です。58文字が残ります。典型的な従来のアドレスは26～35文字の長さになり、どうしても必要なら手書きでコピーできるほど短くなります。

SegWitは2017年8月に有効化されました。それに伴い、BIP-173で定義された2つ目のBitcoinアドレス形式であるBech32が登場しました。Bech32は異なるアプローチを採用しています。大文字と小文字の区別は完全になくなり、すべてのアドレスが小文字になります。数字の1とb、i、oの4文字が削除されます。残りの32文字と数字にはチェックサムが組み込まれています。このチェックサムにより、ほぼすべての1文字の入力ミスが自動的に検出されます。2021年11月から稼働しているTaprootは、研究者が元の計算式に特殊なケースの欠陥を発見した後、この形式をBech32m（BIP-350）に改良しました。

イーサリアムは3つ目の方法を選びました。16進数を使うだけです。イーサリアムのアドレスは「0x」に続いて正確に40個の16進数文字、合計42文字です。16進数では、英数字は16文字に絞り込まれます。数字の0～9、文字のa～fだけで、それ以外はありません。2015年にはこの選択はすっきりしているように思えました。しかし、MetaMaskで生の16進数の塊を何年も目を凝らして見てきた2026の頃には、それは見苦しく見えました。EIP-55が解決策でした。小文字のアドレスのKeccak-256ハッシュから派生したパターンで特定の文字を選択的に大文字にします。その結果、無料のタイプミス検出が実現しました。EIP-55は、約99.975パーセントの信頼性でタイプミスを検出します。ミス率は約0.0247パーセントです。小さいですが、ゼロではありません。

ハッシュは最も単純な例です。SHA-256ハッシュの出力は256ビットで、64文字の16進数で表示されます。イーサリアムのKeccak-256も同じ長さの出力を生成します。ビットコインのトランザクションID（txid）は、トランザクション自体のSHA-256ハッシュなので、txidも64文字の英数字の16進数です。ブロックエクスプローラーでは難解に見えるかもしれませんが、すべて英数字です。

シードフレーズは、このパターンを破ります。BIP-39ウォレットの復元は、暗号技術が英数字から離れて純粋なアルファベットの領域に戻る唯一の例です。この規格では、128ビットまたは256ビットのエントロピーを、固定された2,048語のリストから抽出された12語または24語の英単語としてエンコードします。各単語は小文字のみで、数字や大文字小文字の混在はありません。なぜでしょうか？設計対象は、午前3時に携帯電話のバッテリーが切れた後に紙に単語を書き留める人であり、数字は文字にはない曖昧さを生じさせるからです。

それぞれのサブセットは、高度に技術的なシステムの中に隠された、人間中心設計の要素である。

英数字パスワード：NISTが2024年に実際に述べていること

ウェブ上で見かけるパスワードに関するアドバイスのほとんどは、数年前のもので時代遅れです。大文字と小文字を混ぜる、数字を入れる、少なくとも1つの特殊文字を含める、90日ごとに変更する――これらのルールは20年間も標準的なものでしたが、米国国立標準技術研究所（NIST）は公式にこれらのルールを廃止しました。

デジタルアイデンティティに関する連邦政府の指針であるNIST特別刊行物800-63Bは、2024年9月に改訂版4を最終決定しました。この新しい指針は、削除された内容が非常に多い点が注目に値します。単一要素認証の最小文字数に関する推奨事項は15文字に引き上げられました。文字構成規則に関する指示は「～してはならない」という表現で、サービスは特定の文字クラスを要求してはならないとされています。誰もが嫌っていた90日ごとの定期的なパスワード有効期限も同様に削除されました。これらの規則の代わりに、NISTはサービスに対し、送信されたパスワードを既知の侵害された認証情報のブロックリストと照合することを義務付けています。

この変更はエントロピーの計算によって正当化されます。62文字の英数字プールでは、1文字あたり約5.95ビットが生成されます。95文字の印刷可能なASCIIプール（英数字と特殊文字を含む）では、6.57ビットが生成されます。特殊文字をすべて追加すると、1文字あたり0.62ビット増加します。長さを1文字追加するだけで、5.95ビットすべて増加します。長さは複雑さを桁違いに支配します。

Verizonの2025年データ侵害調査報告書によると、認証情報は確認された侵害侵入経路全体の22%を占めている。クレデンシャルスタッフィング（漏洩したパスワードリストの自動再利用）は、認証試行の中央値で19%、ピーク時には44%に達する。ユーザーの49%は複数のサービスでパスワードを使い回している。これらの問題はいずれも、大文字の使用を義務付けることで解決できるものではない。

特殊文字を含まない、より長い英数字パスワードは、複雑性チェックリストを満たすために作成された短いパスワードよりも解読が困難です。もしあなたの銀行が、大文字1文字、数字1文字、特殊文字1文字を含む12文字のパスワードの作成を依然として義務付けているとしたら、その方針は現在、米国連邦基準に正式に違反しています。

英数字が他に現れる場所

暗号化の分野から一歩踏み出すと、システムが人間が入力でき、コンピュータが曖昧さなく解析できる識別子を必要とするあらゆる場面で、パスワードや英数字の文字列が依然として登場する。

銀行コードは分かりやすい例です。IBANは最大34文字の英数字で構成され、必ず2文字のISO国コードで始まります。SWIFT/BICコードは8文字または11文字です。ナンバープレートは国によって異なり、イギリスのナンバープレートはドイツのナンバープレートとは全く異なりますが、どちらも同じ62文字の記号プールから抽出された英数字です。車両識別番号（VIN）は世界中で正確に17文字で構成され、数字と視覚的に区別するために、I、O、Qの文字は意図的に使用禁止となっています。

APIキーは、ほとんどのユーザーが気に留めることのない日常的な例です。Stripeのライブキーは`sk_live_`に英数字トークンが付加されたものです。AWSのアクセスキーは`AKIA`に16文字の英数字が付加されたものです。2021年以降に発行されたGitHubの個人アクセストークンは`ghp_`です。これらの接頭辞は英数字で構成されており、プロバイダーが公開リポジトリやログをスキャンして漏洩したキーを検出できるように選ばれています。多くの場合、このスキャンによって攻撃者よりも先に漏洩が発見されます。

QRコードについて簡単に触れておきましょう。ISO/IEC 18004規格では、特定の45文字セット（大文字、数字、スペース、およびいくつかの句読点）をエンコードする専用の「英数字モード」が定義されており、これは一般的なバイトモードよりも効率的です。大文字の英数字のみを含むQRコードは、同じ内容を生のバイトでエンコードした場合よりも、1平方あたり約1.6倍のデータを保存できます。

Base32、Base58、Base64: Cryptoがサブセットを選択するとき

バイナリを英数字のサブセットにマッピングするためのエンコーディング規格がいくつか存在する。その代表例として、IETFが2006年に発行したRFC 4648が挙げられる。この規格では3つのエンコーディングが定義されている。

16 進数は最も単純なものです。正式には Base16 です。16 文字: 0～9、a～f。イーサリアム アドレス、暗号化ハッシュ、生のバイトを読み取る必要があるほとんどすべての低レベル デバッグに使用されます。Base32 はより興味深いものです。32 文字のアルファベットは、大文字と小文字を区別しないように選択され、一部のバリアントでは、視覚的に混同しやすい数字 0、1、8、9 が除外されています。2 要素認証を設定して Google Authenticator に秘密情報を入力したことがある人は、ほとんどの場合、知らず知らずのうちに Base32 を入力しています。

Base64は、まさに主力となるエンコード方式です。62個の英数字と、記号「+」と「/」で構成されます。URLセーフなバージョンでは、これらの記号が「-」と「_」に置き換えられます。Base64は、メールの添付ファイル、HTML内のデータURLのエンコード、OAuth用のJSON Webトークンのパッケージ化などに使用されています。

ビットコインのBase58はRFC 4648の範囲外にあります。サトシ・ナカモトが独自に開発しました。その目的は異なり、文字あたりのバイト数効率ではなく、人間がアドレスを再入力することだったため、他には誰も使用していない独自のアルファベットが生まれました。Base85（Ascii85とも呼ばれる）は逆の方向性で動作します。4バイトを5文字に詰め込み、PDFやPostScriptファイルで使用されます。これらのファイルでは、密度の高さが可読性の低下を正当化します。

よくある落とし穴：視覚的な混乱と類似品

暗号技術が英数字のサブセットを選択する理由は、誰もが間違いを犯す理由と同じです。ごく少数の文字の組み合わせが、ほとんどの問題を引き起こします。

よく混同される文字は、ゼロと大文字のO、数字の1（小文字のlと大文字のI）、小文字のlと大文字のIです。Bitcoin Base58では、このため4文字すべてが除外されます。他のシステムでは、異なる対策が取られています。VINではI、O、Qが除外され、一部の金融コードではOが完全に除外され、国のナンバープレート規則では、その国のフォントで0に最も似ている文字が禁止されている場合もあります。

より厄介で最近の問題として、Unicode同形異義語攻撃があります。このアイデアは、2001年にエフゲニー・ガブリロヴィッチとアレックス・ゴントマケルによって書かれた論文で説明されました。同形異義語とは、異なる文字体系の視覚的に同一の文字を入れ替えるものです。例えば、ラテン文字の「a」（U+0061）の代わりにキリル文字の「а」（U+0430）を使用するなどです。この置換を含むドメイン名を登録すれば、本物の銀行と見分けがつかないフィッシングページをホストできます。最新のブラウザは、ドメインが複数の文字体系を混在させている場合、`xn--80akhbyknj4f`のようなPunycodeの生の表現を表示します。この防御策はほとんどの攻撃を阻止しますが、すべてではありません。

強力な英数字パスワードを作成する方法 2026

3つのルール。これらはすべてNISTの数学から直接導き出されたものです。

1つ目：文字数よりも文字クラスが重要。16文字以上を目指しましょう。このルールは、システムが文字と数字のみを受け入れる場合でも、印刷可能なASCII文字セット全体を受け入れる場合でも当てはまります。

2つ目は、パスワードを暗記する必要がある場合は、パスフレーズを使用することです。大規模なリストからランダムに選んだ4つの単語（Dicewareのリストが標準的な選択肢です）は、人間が考え出すほぼすべての短いパスワードよりも優れています。

３つ目：それ以外のことはすべてパスワードマネージャーを使用してください。マネージャーに長い英数字の文字列を生成させれば、それを読んだり手動で入力したりする必要はなくなります。マネージャーが出力を処理してくれるので、出力の読みやすさは全く問題ではなくなります。

クイックリファレンス：英数字のカウントと例

大文字と小文字を区別する場合は 62 文字、区別しない場合は 36 文字です。ASCII コード 48～57 は数字、65～90 は大文字、97～122 は小文字です。正規表現 `[A-Za-z0-9]` または POSIX クラス `[:alnum:]` で全セットを照合します。この 62 文字のプールは、今週あなたが触れるほぼすべてのデジタル識別子の基盤となっています。パスワード、API キー、IBAN、ナンバープレート、トランザクション ID、生成するすべてのウォレット アドレスなどです。

Mathis Curcio

Mathis Curcio is a senior content strategist and NFT specialist at Plisio. With over 5 years of experience in the Web3 space, Mathis focuses on the evolution of NFT ecosystems, digital collectibles, and decentralized ownership models. He creates accessible, insight-driven content that bridges the gap between blockchain innovation and mainstream adoption. His expertise spans NFT market trends, use cases across art and gaming, and the infrastructure powering next-generation tokenized assets.