ずいぶん寒かった時期なので、たぶん1989年の明け頃だったと思う。 当時の僕は ASCII-NET でも駆け出しで、 すんげえプログラム書いて有名になってやるぅなんて感じのガキだった。 当時の流行は圧縮機能つきアーカイバで、 たしか LHarc(LHa) が出て間もない頃だった。 PKware を相手に圧縮率で鎬を削る吉崎さんは、あらゆる意味で憧れの的だった。 当然、圧縮ソフトを書いてみたくなる。 だがそもそも圧縮の原理が解っていなかったし、 まだC言語も習いたてぐらいで、 オモチャのような小さなプログラムを書き散らすのがせいぜいだった。 幼稚なアイディアをひねり出しては、 プログラミングの師匠だった Pen にダメ出しされる日々だった。 たとえばこんな風である。
---世にある圧縮ソフトは十指に余るほどだ。 それらはそれぞれアルゴリズムが違い、 対象ファイルによって得意不得意のレベルが違う。 例えば A で圧縮した後、B で再圧縮すれば、たとえわずかでも小さくして、 より高い圧縮率を達成できるのではないか。 そのような圧縮率の高い組み合わせを探すフロントエンドを作れば、 ある意味究極の圧縮ソフトができるのではないか。 今考えているプログラムのネタなんだけど、と相談してみると、 Pen はこう言った。 「だめだな」と。
問題は、圧縮後のファイルを再圧縮しても、 結果得られるものはより小さいものではないということだった。 圧縮アルゴリズムの基本的なアイディアは、 パターンを探し出しそれを小さなコードへ変換するというものだ。 圧縮後のファイルからは有効なパターンを検出するのは非常に難しい。 何度も圧縮を繰り返すことでは、僕が言うような効果は期待できないということだった。 圧縮後ファイルに最適化した圧縮アルゴリズムを考えたらどうかと提案したが、 それは面白いがテキストやバイナリプログラムよりずっと難しいだろうと言われた。 確かにそうだ。
それにね、と Pen は続けた。 そもそも繰り返し圧縮して本当に小さくなるとすれば、 究極的にはすべてのファイルが1バイトまで小さくなるということだ。 でも1バイトで保持できる情報量を超えることはできないはずだ。 257個のファイルすべてを1バイトにできるとしたら、おかしいだろう? --- 確かにその通りだった。 別に1バイトを目指して繰り返すわけじゃないと反論したが、 あるファイルを小さくしたいということは、 別のファイルを犠牲にしてより小さなコードを割り当てることなんだよと諭された。 ちょうど このページ の「情報は圧縮できないことの証明」にあたる議論だ。 圧縮というのは、有益なものと無益なものを分類することだ、というのが結論だった… と記憶している。
ところがね、と Pen は続けた。 ようするに究極の圧縮とは、与えられたファイル （これが有益であることは間違いない、ユーザがそう判断しているのだから!） に対して何でもいいから番号を割り当てることなんだよ。 展開するときは、番号に対応した元ファイルを復元すればいい。 人類滅亡までに圧縮されるファイルの数なんて 264個より少ないに決まってるんだから、 1から順番に番号を振ってもせいぜい8バイトで済む。
--- しかし、そんなの圧縮ソフトって言えるのだろうか。
有益なデータに小さなコードを割り当てるという意味では「圧縮」だ。 まあ一種のハッシュ関数だよね。 当然、展開しなきゃならないから逆関数も必要だ。 そういう超ハッシュ関数が作れれば… 実際には時計の問題もあるし、作成は無理だけど。 完成すればすごいプログラムになるぞ。 最初の256個は1バイトにできるわけだし ---こんな話で、2時間も3時間もしゃべり明かしたものだった。 もちろんこんなプログラムは作れない。 だがジョークとしてはよくできてるなと思った僕は、 なんとか他の人にも笑ってもらえるような形にできないかなと考え始めた。 最初に思ったのは小説にすることだった。 高校生の頃、 「相対アドレッシングでFFFF-0000を超えてアクセスすると一日未来のメモリにデータが書ける」 という SF 短編 （未来からのホットライン のパロディみたいなもんだ） を書いたこともあったし、 やって出来なくはないな、と思っていた。 だが2、3ヶ月捻り回してみたがうまくいかず、 結局思いついたのが junk.test という場を生かして、 あたかもそれが存在するようなログを偽造してしまうという方法だった。
そうして完成したのが これ である。 最初の草稿では res37 までしかなく、 「THcomp 自身は空ファイルが割り当てられる」というのがオチだった。 Pen に草稿の添削を頼んだら、後半の res57 までを追加してくれた。 res42 のようなアイディアや、 STEALTH氏のいじめ、 アイドルSIGの記事が混ざる件なども Pen のネタである。 これを僕が再度清書したのが最終稿だ。 最後の read.me の案は Pen によるものだが、僕が原典を引いて書き直した。 アップロードは僕の家でやったが、Pen も遊びに来ていて朝まで付き合ってくれた。 その後の顛末は、まあご存知の通りである。
THcomp はそれなりに評判を得たが、 あまり丁寧な解説をしなかったせいもあって、 そもそものジョークのネタであった超ハッシュ関数という発想は埋もれてしまったように思う。 実際 「THcomp は超通信機能とデータベースの組み合わせだ」 と考えている人の方が多いと思う。 どうせ非現実的な話なら、超通信機能なんかに頼らない方が面白いと思うのだが…。 Pen は結構物臭な人で、先の原理の解説ページにしても、もう何年も放置されてしまっている。 ネタばらしも嫌いなもんだから、裏設定や事情を知っている人も非常に少ない。 でももう15年も経ってるし、いい加減時効かなあとも思うので、 記念にまとめてみました。 解説ページ、早く続き書いてくださいね（わははのは）。
特別付録：元ネタ集
May-13-2004