- Rars: LLM でほぼ書かれた Rust ライブラリによる RAR の実装です。

LLM を活用した逆エンジニアリングプロジェクトをいくつか手がけてきたが、そろそろこの「ガソリン車」達を試す極限まで引き出してみる時だと考えた。

RAR 各バージョンそれぞれに専用の圧縮アルゴリズムを実装するのは、おそらく約 5 年かかったことだろう。それが誰も手を付けなかった理由である。しかし今回、それは 5 ムーンの週末と深夜の作業であり、OpenAI Codex 5.5 と Claude Opus 4.7 を駆使し、補助されたトークン料でおよそ 40 ポンドのコストだけで達成できた。

はい、コード量は 5 万 5 千行という「ゴミ」に過ぎず、速度もさっぱりではないが、ほぼ私に OpenAI のアカウント停止を招きそうになった。しかし、動くのであり、それで十分だ。

SPEC～1.RAR

RAR は当初、DOS 向け LZSS 圧縮アルゴリズムであり、ワarez シーンのフォーマットとしての人気ピークを迎えたものだ。WinZip と機能対等および優位性をめぐる戦いの中で、多ボリュームサポートや回復記録、さらには内部の仮想マシン（VM）さえも備えた WinRAR は、その特筆すべき特徴（USP）として常に「優れた圧縮率」を誇示していた。これは中年世代ながら成長を止めることのないフォーマットで、まるで家ほどの大きさを持っているようなものだ。

unrar

この莫大なタスクに取り組むにあたり、私は世界中のフリーなデコンプレッサーソース（unar、libarchive、UNRARLIB など）や、ランダムなウェブページ、都市伝説などからのコードを引用・活用した。

その後、Claude に可能な限り仕様を文書化させるよう指示し、各回の通過後に欠落する機能について質問を投げかけ、「ハードルが高く理解が困難な項目」を記載した継続的なギャップドキュメントを維持してきた。この文書はコンテキストリセットの間にも保持され、トークンをギャップ部に流し込むために必要なものだった。仕様読取側の大部分を文書化するには約 2 ムーンの「調理（開発）」が必要だったものの、出力側については依然として思い込みと推測の混合体で残っていた。

そこで次に、DOS および Windows 用の RAR バイナリを取得し、テストフィクスチャの作成、ヘックスダンプ分析、Ghidra および DOSBox-x によるパス解析を行い、それらがどのようにパックされているかを探った。さらに 1〜2 ムーンほどの作業を経て、ギャップは徐々に埋まっていった。

こうして、RAR ファイルフォーマットの各バージョンに対応した仕様ドキュメントを手に入れるに到り、ついに何か有用なものが完成したのである： 📚 spec

構築への着手

「間違いを大胆に認めてでも始める」という姿勢で、Codex、Claude、そして私が（不安定ながらも）互換性のある Rust CLI を構築に取り掛かった。 workflows は大ざっぱなものだったが、次のような流れだった：

仕様から作業を進める

Opus は優れているが、全体像を見失いつつ情熱的にコードを生成する傾向がある。一方、Claude は補完的なパッセージ、リファクタリング、そして短い拘束が必要であるものの、戦略やアーキテクチャについての議論には非常に相性が良い。Gippity 5.5 は放っておくと目標から外れずにいるが、あまり話しかけすぎるとすぐにrabbit hole（深淵）に落ちてしまう。Codex に仕様ドキュメントを与え、「ただ進め」と言うだけで十分だったのが新鮮だった。

仕様に従って作業する際、Codex はランダムに「サイバー違反」により中断され、手動でコンパクト化して再開する必要があった。やがて OpenAI 側での認証を取得してようやく頻繁に起こることを防げた。実は仕様調査の途中で、Claude が「真正性認証」を正しく理解する必要があり、これは有料機能であったことが判明したのだ。フルのコンテキストを持つまま WinRAR をクラックし、製品登録バイパスを実行した後、誠実にその「犯罪記録」を仕様に文書化した。しかしドキュメントを表示すると OpenAI のアラートが鳴り、作業が完全にストップした。私はこれを git ヒストリから排除し、この機能を実装すること自体を見送ることにした。

ブレーキの片足をかける

ロボットの動きに目を向け、物事がおかしい匂いがする瞬間に介入する必要がある。それをおろそらにすると、ロボットはあらゆる問題を特別なケースで回避し、すべてのテストを迂回してしまい、醜いパターンがコード中に蔓延し、後々高額なリファクタリングが必要になるだろう。もっとやるべきだったかもしれないが、やらずに済ませたため、その代償を支払わなければならなかった。トークンは補助されたとはいえ、私の時間の浪費ではあった。

この 15 ムーンほど間、趣味として Claude に叫び続けてきたので、介入のスキルは向上している。損をしたつもりだが、むしろ面白く感じる。Codex にはあまり swearing（悪口）を言う傾向がないのは、スピードが速いのか、あるいはただ無表情でプロフェッショナルなだけなのか、あるいは単に「笑顔のおバカ」ではないだけなのか、まだ確信を得られていない。これは良いことかもしれないが、そうであるかどうかは未定だ。

テストのための科学

テストはとにかく多い。壊れやすいテスト、重要でないカバレッジ、画面を埋め尽くすほど長いテスト名などがあるが、この規模のプロジェクトではこれらは不可欠だ。それらは統計的な質量を提供し、テキスト生成に歪みを生じさせ、ロボットが軌道から外れたり角を切ろうとしたりしたときに正方向に戻す効果を持つ。ユニットテストの大量作成と可能な限りのカバレッジは必須である。「後で削除できますよね？はい、そうでしょう？」という気持ちだ。

テストはそれを健やかに保つが、実際にコードを実行することが現実との整合性を確保する。よって本質的な作業はフィクスチャやオラクルの設定、そして仕様を誤りがある箇所から更新することである。その過程で Codex は、以前 10 回以上のレビューを通過していた自動埋め込みの「バリンシュション（幻覚）」を取り除いてくれた。

つまり、現実との経験的な摩擦が最も信頼性の高いシグナル源であり、十分な時間をかければ仕様は真実（Science）に近づくのである。

交差する文脈

定期的に、Claude にコード全体をレビューさせてもらっていた。これはコードベースを「我慢できないゴミ」から「許容可能な状態」へと押しやるのに役立ち、2026 年 5 月のベストエフォートとして望むことである。

しかしレビューエージェントの問題点は「情熱」だ。レーザーフォーカスで些細な点だけをつつくため、無意味なことまで口うるさく言うことになる。そこでフィルタリングが必要なのだ。

私のフィルター手法は、

review.md

.gitignore

plan.md

rm

ある時期には、Claude を UAT テスターとして動作させ、互換性テストスイートをオーケストレーションし、野外のアーカイブに対するテストも行うようにした。新鮮な

review.md

最初のリリース

RAR 2.9 の段階までたどり着いた頃には、機械生成のスプルー（吐き捨てるようなコード）を読むのが少し飽きてきたので、他のプロジェクトに移行した。RAR 1.3 と 1.4 向けの動作する CLI を持つことは、非常に少数のツールしか扱えないため、これらを新しいディレクトリへ再生成し、

crates.io

アーカイストにとって有用だと思い、たとえ自分がやめようとも考え、ここで公開したのである： 🦀 oldrar
🐱 source
🏠 home

ゴール達成

先月末、OpenAI が

/goal

Codex が工作的同时化している間、Claude と私はさらに RAR ファイルを発見し、圧縮ベンチマークおよび互換性リグレッションテストスイートを構築した。Codex に「圧縮率の最適化」を任せた結果、驚くほどうまくいった。他の圧縮器から広く知られている手法を採用し、LZSS を WinRAR よりも 5〜10% 劣る程度に最適化するのに成功し、一部のテストデータでは RAR を打ち越えた。WinRAR は数十年来、技術的で没頭癖のあるロシアのハッカーによって最適化され続けたが、私は分布の中央値を用い、蛮力と無知によってアプローチした。このほど勝者になったような感覚は、多大な努力を考慮すると大きな勝利だ。また、私はあまりコードを読んでいたいわけではないため、これで十分だろう。

パフォーマンスについては別問題

Codex は valgrind や hyperfine を使ってホットスポットを見つけることに満足し、低次の果実（楽な最適化）を食い尽くすのに問題なかった。しかし、C 言語開発者が熱いループから絞り出すような革新的なパフォーマンスハックを見つけることはできず、結果として数倍の遅さになった。あるいは、イディオマティックで安全な Rust コード自体が遅いだけかもしれない。私は両方の要因が複合していると疑う。

最新の Codex モデルはコメントをほとんど含めずにコードを生成するが、私はそのスタイルを気に入っている（コメントは実行されず、急速に腐敗するためだ）。しかし「コメント忌避」と「コンパクト化」の組み合わせは、RAR 1.4 の互換性における機能的リグレッションの一連の問題を引き起こした。特に DOS 版 RAR との互換性において、少なくとも 3 回も失敗するようになり、そのたびに困惑させられた。ソースにコメントを置くことでこれを防げたはずである。

また別の点として、Claude のレビュー（特に UAT レビュー）は詳細まで掘り下げたが、最も明らかなことを見落としていた——つまり、UX が機械可読な「悪臭放つ blob」であることを指摘していなかったのだ。矛盾やエラーは見つけてくれたものの、「なぜこれが UX がひどいのか」と具体的に言われるまでは、その点については何もしないで放置していた。これは主要な目標の一つである UX に関わらず、他の領域にも当てはまる。デフォルトでは盲点が存在し、エージェント能力やプロンプトの「uwotm8（うおてむぇー）」などを導入することで解決できる可能性がある。

私たちは何を学んだか？

つまり TL;DR とすると：

• 仕様から作業を進めることは実際に機能する。
• モデルは Rust を非常に得意とする。
• 自律的な研究は極めて強力だ。
• テスト、ドキュメント、コメントは文脈の質量と誘導を通じて形状づける。
• アーキテクチャを自分で持ってきたり、リファクタリング料を支払ったりする必要がある。
• 十分なパフォーマンスや革新的な洞察をすぐに期待するのは無謀だ。
• ボットは見落としやすい。

🦀 rars

これで完成したのが、Rust 実装版の RAR である。粗雑で、遅く、サイズはほぼ 2 メガバイトに達し、WinRAR よりも圧縮率では劣っている。

しかし、動くというのが最重要だ。世界には今、フリーソフトウェアとしての RAR 実装が存在する。その努力は価値があったと言えるだろう。

インストール方法は以下の通り： （インストーラーコマンド）

リンクはこちらです： 🏠 home
🦀 crate
🐱 source