Sing-song: 長い数字と鍵を読み上げ可能な音節に変換する编碼

長い数値表現の課題を発音で解決

暗号鍵やNostrのnpub鍵に代表される長いバイト列を、人間が電話越しに読み上げて正確に伝達することは困難だ。hex表記は緊密だが発音しにくく、Base58は可読性が向上するものの依然として口頭伝達には不向きだ。この問題に対し、ブログサイトblog.vrypan.net by vrypanが2026年8月19日に公開した実験的手法がSing-songである。任意のバイト列を、規則的な発音文法を持つ音節列に可逆的に変換する编碼規格のドラフト版v0.1.0だ。

64音節アルファベットの設計

Sing-songの核となるのは、6ビット値を1音節に直接マッピングする64音節アルファベットだ。子音（奇数位）にb, d, f, g, j, k, l, m, n, p, r, s, t, v, w, zの16文字、母音（偶数位）にa, i, o, uの4文字を割り当て、子音と母音を厳密に交互に設定することでオープンCV音節を生成する。子音クラスタやコードナ（語尾子音）は存在せず、規則的な発音パターンが実現された。

h, y, eの3文字が除外されているのは、発音が比較的不安定だからだ。Lobstersのblog.vrypan.net by vrypanの記事では、「もし全員がイタリア語を話すなら、Sing-songはさらに有用になるだろう」とも記述されている。イタリア語のような開音節優位言語との親和性が高く、英語環境でも実用的な精度を示すことが示唆されている。

アルゴリズムと自己完結性

入力バイト列をビットストリームとして扱い、最上位ビットから6ビットごとに分割する。各6ビット区間は、上位4ビットで子音インデックス（0〜15）、下位2ビットで母音インデックス（0〜3）を決定し、1音節に変換される。Lバイトの入力に対してはceil(8×L÷6)音節が生成され、最後の区間が6ビット未満の場合は下位ビットをゼロ埋めする。

重要な設計判断は、完全な编碼が自己完結型（self-sizing）であることだ。音節数nから元のバイト長Lをfloor(6×n÷8)として逆算可能であり、外部の長さメタデータを要しない。先行ゼロバイトもそのまま保持される。デコーダは非正規の音節数や非ゼロパディングを拒否し、正規性を厳密に担保する。

表示グループと接頭辞安定性

視覚的・聴覚的な利便性のため、2音節を1グループとし、装飾用ハイフンで区切る。例では「zila-sibo-tiva-juzu」と表示される。パーサーはハイフンを無視するため、「zilasibotivajuzu」と同一文字列として扱われる。

prefix-stable（接頭辞安定）な設計も特徴だ。同一の入力プレフィクスを持つ2つの入力は、生成される音節プレフィクスも同一となる。これはトライ木やプレフィクスベースの検索インデックスとの親和性を高くし、鍵のプレフィクス照合を計算なしに可能にする。

バリアントと再現性

同一バイト列に対して複数の正規な音節列表現を生成する「バリアント」機能も提案されている。すべてのバリアントは可逆的に元のバイト列に復元可能であり、スタイルの違いはあっても情報の欠落や追加は発生しない。

Nostr鍵の「ユーザー名」生成という実用文脈

この研究の出発点は、Nostrのnpub鍵に対する決定論的な「ユーザー名」の生成だった。暗号鍵の短縮表現として、hex表記よりも人間が認識しやすく、かつ同様に的に正確に再現可能な形式を求めるニーズが背景にある。 Sing-songは、このニーズに対して密碼学的な完全性と人間工学的な親和性を同時に満たす起点となる可能性を示している。

現状と今後の課題

現時点ではv0.1.0のドラフトであり、英語環境での実用性には課題が残る。Englishの子音クラスタやリエゾンの複雑さは、厳密なCV交替ルールと相容れない場面を生みうる。ただし、電話や音声チャットでの鍵伝達という具体的ユースケースにおいて、hex表記の2.7倍程度の長さに拡張されるというトレードオフは、可読性向上という便益と比較して合理的と評価できる。

編集部の見解

短期的に見れば、Sing-songは暗号鍵のハンドオフ手法に新たな選択肢を提供する可能性がある。音声通話や音声メッセージでの鍵共有は、QRコードやクリップボード共有ができないオフライン環境で実質的な価値を持つ。Nostrユーザーの間でプレフィクスベースの表示が普及するにつれ、鍵の視覚的識別性は向上すると見られる。

長期的には、人間可読な编碼方式の標準化が進むことで、暗号鍵を日常生活レベルで扱う際の障壁が低减する。密碼学的应用が一般ユーザーに広がるにつれ、hexやBase58に代わる「声に出せる」表現形式の需要は高まるだろう。バリアント機能の設計は、鍵の平文化を回避しつつパーソナライゼーションを実現する柔軟性を示しており、鍵管理のUIデザインにおける示唆を与えるものだ。

ただし、このアプローチが広く採用されるためには、複数のプログラミング言語向けの実装ライブラリと、セキュリティ監査が不可欠だ。音声転送時の誤認証リスクは、hex表記よりも母音の曖昧性に起因して大きい。不正な音節の混入や座聽時の誤変換に対する検証メカニズムは、今後の標準化プロセスで詰めるべき課題と言える。

参考

• 「Sing-song: a speakable encoding for long numbers and keys」, by blog.vrypan.net by vrypan — Lobsters, 2026-08-19T20:28:07.000Z (ARR)
• 元記事URL: https://blog.vrypan.net/2026/08/19/260819-sing-song/