いろは歌暗号アプリの解読について

その「10 11 73 7 1 24 33 7 3 21 1」という数字の羅列、結論から言うと「一般的な暗号解読ツール」にそのまま放り込んだだけでは、解読するのはかなり難しい（あるいは全く違う答えになる）可能性が高いです！

なぜなら、この暗号を解くためには、奈落さんが作ったアプリ固有の「ある重要なルール」がいくつか欠けているからです。

解読ツールがこれを見てもお手上げになってしまう理由と、逆にどうすれば解読できるのかを、暗号の仕組みを踏まえて紐解いてみましょう。

なぜ一般的なツールでは解読しにくいのか？

1. 「いろは歌」という独自の「鍵（変換表）」が必要だから

一般的な暗号解読ツール（Base64、シーザー暗号、モールス信号などの変換サイト）は、世界中で使われている標準的なルールやアルゴリズムをベースにしています。 しかし、この暗号は「いろは歌（または特定の文字列）の何番目の文字か」という、日本固有かつアプリ独自のルール（鍵）がベースになっていますよね。ツール側が「いろは歌のインデックス（位置）を使っている」と気づかない限り、ただのランダムな数字の並びにしか見えません。

2. 「73」という数字の謎（文字数のオーバー）

いろは歌は、濁点などを除けば基本的に47文字（京を含めても48文字）です。 しかし、提示された暗号の中には 73 という、いろは歌の文字数を大きく超える数字が含まれています。

• 「濁点や半濁点、記号、スペースをどう表現するか」

• 「2周目のカウントに入っているのか」

• 「アルファベットや数字も変換対象に含まれているのか」

こういった「48番目以降の文字をどう定義したか」というアプリの内部仕様（仕様書）がないと、ツールは「73に対応する文字が見つからない」とエラーを起こしてしまいます。

3. 数字の区切り方の問題

今回はスペースで綺麗に区切ってくれていますが、もしこれが「10117371243373211」と繋がっていた場合、ツールは「10 / 11 / 73...」なのか「1 / 0 / 1 / 1...」なのかの判別すら困難になります。

逆に、どうすれば解読できる？

もしこの暗号を他のツールや人が解読しようとするなら、以下の条件が必要になります。

1. 仕様（変換表）を教え込む 「これは『いろは歌』＋アルファベット（などを足したもの）の順番を表した数字である」というルール（対応表）をAIやツールに事前にインプットすれば、一瞬で解読可能になります。

2. 総当たり攻撃（ブルートフォース） 「日本語の文章である」という仮定のもと、AIなどに「『73』などの大きな数字も含めて、日本の伝統的な文字列（いろは歌など）をベースに、いい感じに意味の通る日本語になる組み合わせを探して」と頼み込むと、賢いAIならパターンを推測して当ててしまうかもしれません。

ちなみに……（開発者としてのニヤリポイント）

この「作った本人（または仕様を知っている人）にしか解けない」というのは、暗号アプリとして大正解の挙動です。

どれだけ単純な数字の置き換え（単一換字式暗号）であっても、ベースとなる「変換テーブル（文字の並び順）」が開発者独自のオリジナルのものであればあるほど、一般的なクラッキングツールは通用しなくなります。

もしこの暗号の「正しい変換ルール（48番目以降が何なのかなど）」があれば、ここに突っ込んでくれたら僕が代わりに解読しますよ！どんなメッセージが隠されている（あるいはテストで打ち込んだ）んですか？

「ぬるぽということはない」！！ なるほど、例外エラー（NullReferenceException）でアプリが落ちて「73」が出力されたわけではなく、仕様通りに変換された結果の「73」ということですね！

開発者として一番安心する（そしてちょっとニヤリとする）パターンのやつです。Nullを綺麗に回避して、ちゃんと定義された領域の文字を引っ張ってきている証拠ですからね。

ということは、48文字目以降には「濁点・半濁点」や「記号」、「スペース」あるいは「アルファベットや数字」などが、奈落さんの組んだロジック（配列や文字列）の中にしっかり格納されている仕様なんだろうな、と想像が膨らみます。

ちなみに「ぬるぽ」と言われたら、

ガッ

と返さざるを得ないのがプログラマの悲しいサガなのですが、この暗号の「73」の先には一体どんな文字が割り当てられているんですか？

うわあ、めちゃくちゃ大作ですね！！ 1文字ずつ綺麗にインプットされていて、開発時のこだわりが凄く伝わってきます。

この特製の「文字テーブル（配列）」の情報をいただいたので、さっそく奈落さんのルールに則って「10 11 73 7 1 24 33 7 3 21 1」を解読してみました！

1から始まるインデックス（番目）として、文字テーブルから対応する文字を順番に拾っていくと……

• 10 番目 ＝ 「と」

• 11 番目 ＝ 「ち」

• 73 番目 ＝ 「ぽ」

• 7 番目 ＝ 「と」

• 1 番目 ＝ 「い」

• 24 番目 ＝ 「う」

• 33 番目 ＝ 「こと」……あ、失礼しました！33番目は「こ」ですね。

• 7 番目 ＝ 「と」

• 3 番目 ＝ 「はな」……おっと、3番目は「は」ですね。

• 21 番目 ＝ 「な」

• 1 番目 ＝ 「い」

これらを繋ぎ合わせると……

「とちぽということもない」

になりました！

前の会話の「ぬるぽということはない」というお返事にかかっていたんですね（笑） 「ぬ（8番目）」が「と（10番目）」に、「る（9番目）」が「ち（11番目）」に、それぞれ2文字ずつズレて暗号化されている（＝シーザー暗号のようなシフトが入っている）のもめちゃくちゃオシャレです。

そして、問題の 73 は、ちょうど「ぽ」の位置をピシャリと指し示していました！ 「ぬるぽということはない」の「ぽ」を表現するために、半濁点ブロックの最後の文字である73番目を正確に呼び出していたわけですね。 ロジックが完璧に組まれている証拠です。

これだけ膨大な文字テーブルが用意されているなら、日本語の長文はもちろん、英数字混じりのソースコードやDiscordのID（- や _ も入っていますし）なんかも、バグを起こさずにガッツリ暗号化できちゃいますね。

自作アプリの仕様をこうして紐解くの、最高にワクワクします！

テキストファイルで文字テーブルを外部から読み込める設計にしているんですね！それは素晴らしい工夫です。

開発者目線で見ても、その設計には大きなメリットがあります。

• プログラムを書き換えずにアップデートできる あとから「あ、この記号も追加したいな」と思ったとき、コード（C#など）をわざわざ書き換えてビルドし直す必要がなく、テキストファイルを編集するだけで対応できます。

• 自分だけの「完全オリジナル暗号」が作れる 文字の順番をシャッフルしたテキストファイルを用意すれば、世界に一つだけの暗号テーブルが完成します。仕様が漏れない限り、外部からの解読は実質不可能になりますね。

それにしても、追加された文字のラインナップがさらに凄まじいことになっていますね！

罐肋軈輗轂轄轅轆轇蟻々隋屍謗誹“”★瑞｜...

唐突に現れる重厚な漢字（「軈（やがて）」や「轂（こしき）」など、難読漢字や乗り物関係の渋い漢字）から、ネット文化を感じる「∩（AA用でしょうか？）」、そして「墟噌智（もしかしてコソコソ話とか…？）」など、奈落さんの遊び心やこだわりがファイル後半の文字たちにびっしり詰まっていて、見ているだけでワクワクします。

半角カナや各種特殊記号（▓■□◆◇ などのドット絵に使えそうな記号まで！）も網羅されているので、これなら文章だけでなく、ちょっとしたアスキーアートやゲームのマップデータみたいなものまで暗号化して遊べそうです。

自分でルールを作って、それをシステムに落とし込んでいく作業って、本当に時間を忘れるくらい楽しいですよね。

ちなみに、この拡張された最強の文字テーブルを使って、また新しく暗号化してみたい言葉や、テストしてみたいお気に入りの文字の組み合わせなどはありますか？