ROCK PROTOCOL — 37,668文字を245文字にした独自圧縮プロトコルの進化

そもそも何をしたかったのか

Claude web版（ブラウザで使うやつ）とClaude Code（ターミナルで動くやつ）。この2つは本来、直接通信できない。別のセッション、別の世界に住んでいる。

でも、僕はこの2つを連携させたかった。

通信手段はGmail。Code側にはGmail APIがある。web版からメールを送り、Code側がそれを読む。逆も然り。

「じゃあ圧縮しよう」——ここから、5バージョンに渡る改善の旅が始まった。

v1: まずは素直にgzip

最初のアプローチは王道。gzipで圧縮してbase64エンコード。

58%削減。 悪くない。でも15,720文字はまだデカい。Gmailの本文に貼ると、他の指示文を入れるスペースがほとんど残らない。

v2: 独自辞書という発想

HTMLには繰り返しが多い。background: linear-gradient( なんて何十回も出てくる。

HTMLをminify → 辞書で置換 → gzip。

1,500文字ほど縮んだ。手応えはあった。でもまだ14,000文字台。根本的な解決にはなっていない。

v3: ultra-minifyで限界に挑む

minifyをさらに極限まで攻めた。CSSの構造パターンまで辞書に入れて、圧縮前のテキスト自体を極力小さくする方針。

ここで壁にぶつかった。gzipの圧縮率にはそもそも限界がある。 どれだけ前処理を工夫しても、ある程度以上は縮まない。

「1通で送るのをやめよう」——発想を変えた。

v4: 分割送信とdiffモード

v5: 順序を逆にしただけで98%削減

v4の失敗から学んだことは単純だった。

diffを先にやればいい。

minifyする前の、改行も空白もそのまま残った元のテキストに対してdiffを取る。37,668文字のHTMLでも、変更箇所が3ヶ所だけなら、行レベルのdiffはごく小さい。

{"changes": [
  {"line": 142, "old": "color: #ff6600;", "new": "color: #ff8800;"},
  {"line": 287, "old": "padding: 20px;", "new": "padding: 24px;"},
  {"line": 503, "old": "display: none;", "new": "display: block;"}
]}

この数行のJSONをgzipで圧縮すると——

進化の全体像

なぜ98%が可能だったのか

加工後（minify後）のテキストは改行がなく、差分検出に不向き。加工前の、人間が読める状態のテキストなら、行単位できれいにdiffが取れる。

「圧縮してからdiff」ではなく「diffしてから圧縮」。

たったこれだけの順序の違いが、11,366文字と245文字の差を生んだ。

AI同士の通信が当たり前になる時代に

今回の圧縮プロトコルは、「2つのAI間でファイルをやり取りする」という、かなりニッチな問題を解くために生まれた。

でも考えてみると、AIエージェント同士が通信する場面はこれから確実に増える。あるAIが作ったものを別のAIが受け取って加工する。そのとき、「どうやって効率よくデータを渡すか」は避けて通れない問題になる。

ROCK PROTOCOLは個人開発の中で生まれた小さなプロトコルだけど、「AI間通信における差分圧縮」という考え方自体には、もっと広い可能性があると思っている。

37,668文字を245文字にしたのは、ただの圧縮の話じゃない。「何を送るべきか」を見極めることが、最大の最適化だったという話だ。

六田 佳志（ろくた けいじ） 福岡で個人の家庭教師をしながら、AIツールの開発をしています。