mameさんはなぜ、Quineや難解プログラミングに挑戦し続けるのですか？

エンジニアリングの世界においては、「読みやすく、理解しやすいコード」が正義とされます。ですが、その対極にある「複雑怪奇で難解なコード」を書くことに情熱を注ぎ、それを職人技の域にまで高めたエンジニアがいます。Rubyコミッターである遠藤侑介（mame）さんです。

故意に難解なC言語のプログラムを書き、読みにくさと複雑さを競う「IOCCC」や自身のソースコードと完全に同一の文字列を出力する「Quine」などに、20年以上も取り組んでいます。今回は、遠藤さんがこれまで書いてきたコードの数々を紹介していただきました。

「プログラミングでこんなことができるのか！」徹夜で解読した原体験

― 遠藤さんが、Quineや難解プログラミングの世界に触れたきっかけは何だったのでしょうか？

大学時代のプログラミングサークルですね。いろいろな領域に詳しい先輩がいて、「IOCCC」や「Quine」という概念をその方から教えてもらいました。当時知ったなかでも特に印象に残っているのは、「IOCCC 2000」の入賞作であるOmoikaneさんの作品です。これは本当に衝撃的でした。

引用元 : https://github.com/ioccc-src/winner/blob/master/2000/dhyang/dhyang.c

漫画『るろうに剣心』の斎藤一をモチーフにしたアスキーアートなのですが、これがそのままC言語のプログラムになっています。実行すると「あく」と出力され、そのコードを実行すると「そく」、さらに実行すると「ざん」と続き、最後はまた「あく」に戻ります。つまり、斎藤一の信条である「悪・即・斬」のループがQuineとして実装されているんです。

実行結果

これを見たときは「一体何をやっているんだ！？」と圧倒されました。どうにかして仕組みを知りたくて、その日のうちに徹夜でコードを解析したのを覚えています。

― 徹夜とは。すごい情熱ですね。

もともと、コードゴルフ（アルゴリズムをいかに短いコードで書けるかを競うもの）やProject Euler（数学的な問題をプログラミングで解く問題集）などで遊んでいたこともあり、「制約があるなかで条件を達成するためのコードを書く」というテクニックは多少なりとも持ち合わせていました。そうしたパズル的な感覚と、IOCCCの「こんなことができるのか！」という感動が、その時点で結びついたんだと思います。

根底にあるのは「不思議なコードを書いて自分が楽しみたい」というモチベーション

― その後、ご自身で書いたコードのなかで、最初に納得のいくクオリティになったのは？

まずは「quineclock」です。これは現在時刻を表示する時計のアスキーアートなのですが、出力結果がそのまま次の時刻を表示するプログラムになっています。

実行結果

引用元 : https://mametter.hatenablog.com/entry/20090106/p1

ただ、こうして振り返ると、数字フォントの埋め込み方などがまだ甘いなと感じますね。当時はこのフォントを表現するのに苦労したのですが、その後に研究が進んだので、今ならもっとコンパクトに書けます。

初期に書いた他のコードとしては、「15quzzle」もあります。これは15パズルを模したコードです。

実行すると、コードで書かれた盤面が出ます。

実行結果

「右に動かして」といった指示を与えて実行すると、パズルの空白部分が動き、その状態を保持した新しいプログラムが出力されます。

実行結果

引用元 : https://mametter.hatenablog.com/entry/20090109/p1

かなり初期のコードですが、いい感じのひらめきがあって、自分でも「よくできているな」と満足した記憶があります。

― こうした難解なプログラムを作るには、多大なエネルギーが必要だと思います。遠藤さんのモチベーションは何にあるのでしょうか？

世界で最初に「こんなことができるんだ！」という発見をして、自分自身で驚けるのが楽しみですね。自分が満足できればいいので、もともとは、誰かに見せたり楽しんでもらったりすることはあまり考えていませんでした。「面白いものができたから保存しておこう」くらいの気持ちだったんです。

― そのスタンスが変わった転機はありましたか？

2010年の「RubyKaigi」ですね。変なプログラムばかりを紹介するセッション枠をいただいたのですが、当時は「こんな内容を発表したら、怒られるんじゃないか」と本気で緊張していました（笑）。

ところが、いざ発表してみたら予想に反してすごく好評でした。自分の書いた奇怪なコードを、多くのエンジニアが面白がってくれるのだと知りました。ただ、それはある程度のモチベーションになってはいるものの、根っこにあるのはやはり「自分が最初に楽しみたい」という気持ちです。

日常生活のあらゆる要素が、アイデアの種になる

― Quineや難解プログラミングのアイデアをどう思いつき、実装していくのでしょうか？

プログラミングは子どもの頃からずっと好きで、何事も「プログラミングで表現するとどうなるか」と考える癖はありました。そこにQuineや難解プログラミングという概念が加わってからは、その傾向がより強くなったかもしれません。例えば、先ほどお話しした「quineclock」は、ふと時計が目に入ったときに「これをQuineと組み合わせたらどうなるだろう」と考えて生まれたものです。「15quzzle」もそうですね。

― 日常の何気ない出来事が、プログラミングの題材につながっていくのですね。

そうですね。あと、アイデア出しの面では妻の存在も大きいです。妻は研究者でプログラマーなのですが、よく相談に乗ってもらっています。象徴的なのが、山手線をモチーフにした「山手Quine」です。

これは、「東京」というアスキーアートが描かれたコードを実行すると「有楽町」に変わり、次は「新橋」……と、当時の山手線全29駅を一周して戻ってくるプログラムです。もともと私は沿線を散歩するのが趣味で、「駅名を順番に出すQuine」というネタを思いついたのが始まりでした。最初は東海道線で作り始めたのですが、妻に話したところ「（ループして戻るのがQuineなのだから）そこは山手線でしょ」と返されて。「確かにその通りだ」と納得して山手線に修正しました（笑）。

実行結果

引用元 : https://mametter.hatenablog.com/entry/20091130/p1

この「山手Quine」は2010年の「RubyKaigi」で発表して大きな反響をいただいたのですが、今度は海外の「RubyConf」でも発表したいという話が出てきました。ただ、山手線ネタは東京の人にしか通じません。そこで「海外の人にも伝わり、かつ回るものといったら何だろう？」と妻と話し、出てきたのが地球儀でした。そうして完成したのが、回転する地球を描く「Qlobe」です。実行するたびに、アスキーアートの地球が回っていきます。

実行結果

引用元 : https://mametter.hatenablog.com/entry/20100905/p1

他にも、新しいアルゴリズムを知ったときに「これをQuineや変なプログラムにできないか」と考えることも多いです。例えば、初めて「IOCCC」に入賞した「変な流体シミュレータ」は、もともと興味があった流体シミュレーションを、応募のために勉強して実装したものです。コード自体が流体シミュレーターになっていて、実行するとアスキーアートの流体がダーッと流れていく様子が出力されます。

引用元 : https://mame.github.io/ioccc-ja-spoilers/2012/endoh1.html

YouTube：ASCII fluid dynamics -- IOCCC2012 endoh1.c

もう一つ、同時期に入賞したのが「スピゴットアルゴリズム（spigot algorithm）」という、円周率を1桁ずつ計算していくアルゴリズムを応用したプログラムです。

「spigot」は「蛇口」という意味なので、コード自体を蛇口の形にしました。実行するとπのアスキーアートが出てくるのですが、それをコンパイル・実行すると、縦書きで「3.14」と出力されます。そのコードを実行すると「3.14159……」となり、円周率が1桁ずつ増えていくQuineになっています。

ただ、スピゴットアルゴリズムは単なる着想元で、このプログラム自身は（その形状に反して）スピゴットアルゴリズムを実装していません。

引用元 : https://mame.github.io/ioccc-ja-spoilers/2012/endoh2.html

他にも、「Quine」という概念をどこまで拡張できるかに挑戦したのが「Quine Relay」です。これはRubyから始まって、Rust、Scala……と、合計128ものプログラミング言語を経由して、最後にまた最初のRubyのコードに戻ってくるという長大なリレー形式のQuineです。

引用元 : https://github.com/mame/quine-relay

― 数あるコードの中で、ご自身でも感動したものはありますか？

完成したときに一番感動したのは、「放射線耐性Quine」ですね。これは「コードの中のどの1文字を勝手に消しても、正しく動いて元のソースコードを復元する」という性質を持ったQuineです。本来の「放射線耐性」とは少し意味が違いますが、データの改変を検知して復元する「誤り訂正技術」から着想を得ました。正直、自分でも「本当にできるのか？」と半信半疑で作っていたので、動いたときはRubyの柔軟さに驚きました。今同じものを作れと言われても、できる自信がありません（笑）。

引用元 : https://github.com/mame/radiation-hardened-quine

― どのような処理によって「消された1文字」を復元しているのでしょうか？

まず、プログラムの中に自分自身の「ハッシュ値」を埋め込んでおきます。

1文字消された状態で実行されたプログラムは、「今、どこかの1文字が欠けている」という前提で動きます。そこで、コードのあらゆる場所に、あらゆる文字を順番に埋めては、その都度ハッシュ値を計算して、埋め込まれた値と比較するんです。総当たりでチェックしていき、ハッシュ値が一致するパターンが見つかったら、それが「元の正しいコード」であると判断して出力します。

自分で言うのもなんですが、本当にすごい仕組みだなと思いますし、こんな無茶な処理を受け入れてくれるRubyという言語のすごさを改めて実感したコードでもあります。

余談ですが、実はこのコード、最初はアスキーアートの形にできていませんでした。このコンセプトのコードを、特定の絵の形にするのは不可能だと思っていたんです。ところが、僕の初期版を見たDarren Smithさんという方が、「ハッシュ値に適合するように、欠損箇所を埋めながら自己修復するプロセス」をさらに効率化するアイデアを提案してくれました。

そのアプローチを取り入れたことで、ようやくアスキーアート化に成功しました。自分一人の力ではなく、コミュニティの知恵が加わって技術的な限界を突破できたという意味でも、非常に思い出深いコードです。

参考 : 放射線耐性Quine アスキーアート化の経緯 - まめめも

「プログラミングを楽しむこと」は人間だからこそできる営み

― これまで発表されたコードの中で、特に反響が大きかったものは何でしょうか？

まずは、大塚製薬さんからお声がけいただいた『カロリーメイト リキッド』プロモーション用の「流体Quine」です。リキッド、つまり液体なので「流体シミュレーションを使って何かできないか」というご依頼でした。そこで、アスキーアートで『カロリーメイト リキッド』を描き、実行するたびに液体の色が変わって、表示される味のラベルも切り替わるQuineを作成しました。

引用元 : https://www.otsuka.co.jp/cmt/to_programmer/cui/

― 商品のプロモーションに「Quine」が使われるというのは、前代未聞ですね。

そうかもしれません（笑）。他にも面白いご縁があって、アニメ『Sonny Boy』の夏目真悟監督からプロデューサーの方を介してご依頼をいただき、劇中に登場するプログラムを書かせてもらったこともあります。

監督からは「映像の中で何かが『解ける』ような演出が欲しい」というお題をいただきました。そこで「難解」という二文字で構成されたプログラムを作成し、実行するとその文字がバラバラに崩れて「解けていく」という演出を提案したところ、喜んでいただけました。

引用元 : https://github.com/mame/sonny-boy-nankai

YouTube：アニメ「Sonny Boy」の『難解』プログラム ― nankai.rb

加えて、多くの人に届いたのは、先ほど話した「Quine Relay」ですね。今でも数年に一度のペースで海外の「Hacker News」などで話題になります。定期的に誰かが再発見して、面白がってくれているみたいです。

― 遠藤さんのコードを見て、「自分もこんな世界に挑戦したい」と思う方もいるはずです。何から学び始めるのが良いでしょうか？

いい教科書がありますよ！ 私が10年前に書いた、『あなたの知らない超絶技巧プログラミングの世界』(技術評論社)です。私が当時知っていた限りのテクニックは、すべてこの1冊にまとめてあります。

この本の類書は他に存在しません。当たり前ですが、学んだところで仕事や生活に役立つわけではないですから。でも、だからこそこの本にしかない内容が詰まっています。

ちなみに、私が「Quine」を知った頃は、ネット上に日本語の解説なんて全くなくて、英語の文献を必死に読み解いていました。それに比べれば、今はインターネット上にいくらでも情報があります。「始めたい」というモチベーションがあるのなら、調べる手段には困らないはずです。

そうそう、RubyKaigiでは「TRICK」というコンクールも不定期でやっています。同好の士が書いた「すばらしく無意味」なコードを持ち寄って、みんなで愛でる大会です。次の開催は未定ですが、たぶんきっとやるので、ぜひ挑戦してみてください！

TRICK 2025 入賞作品：https://github.com/tric/trick2025
TRICK 2025 表彰・解説スライド：https://speakerdeck.com/mame/trick-2025-results

― こうした類のプログラミングに全力で取り組むことは、エンジニアのスキルやキャリアにどのような影響を与えると思われますか？

私はこれで生計を立てているプロの芸術家ではないので、キャリアにどうこうといった大それた話はできません。ですが少なくとも、「遊び」としてプログラミング生活を彩ってくれるものだとは思っています。

よく「プログラミング言語は課題解決のための道具だ」と言われますよね。それは一つの真理ですし、否定もしません。ただ、プロとして自分が使う道具を「必要以上によく知っていること」は、決して損にはならないと思うんです。「こんなことできるわけがない」と思っていた言語の限界を突破できる体験は、エンジニアとしての視野を広げてくれます。

もちろん、実用的なプログラムをたくさん書いて経験を積むほうが正しい道だとは思います。でも、仕事で言われたものを作るだけでなく、自分の好きなものを作って楽しむ時間があってもいい。そうした「ゆとり」や「遊び」が、プログラミングを続ける上での活力になるはずです。

― 昨今では、AIによるコード生成も普及しています。それに伴い、こうした「遊び」の領域も変わっていくのでしょうか？

これは完全に与太話ですが、プログラミングがAIに置き換わっていく流れの中で、こうした「遊び」は最後まで人間に残る活動じゃないかな、と思っています。

なぜなら、AIでプログラムを生成しようとする強い動機は「効率化したいから」とか「ビジネスにプラスになるから」ですよね。一方で、こうした奇怪なコードはAIで解いたところで誰も得をしないですし、お金にもなりません。だからこそ、最後まで「人間だけの楽しみ」として残る気がしています。

― 非常にワクワクするお話を伺えました。プログラミングの深遠な世界を見せていただき、ありがとうございました！