GitHub でいま最も人気の新しい技は、口数を減らすこと

GitHub でいま最も人気の新しい技は、口数を減らすこと

今週 GitHub で最も急成長しているリポジトリは caveman という Go プロジェクトで、スター数は 112,000 を超えている。その前提は、たまたま正しいジョークだ。キャッチコピーは「少ない言葉で足りるなら、なぜ多く使うのか」。コーディングエージェント向けの skill 兼プロキシで、モデルに原始人のように話させることで token 使用量を約 65% 削減できると主張している。

このネタを剥がすと、本物のエンジニアリング上の主張が残る。コーディングエージェントがやり取りする内容のほとんどは情報ではない。足場、丁寧さ、繰り返し、そして言語モデルが既定で行う礼儀正しい前置きだ。意味を捨てずにこれらを捨てられれば、セッションは安くなり、コンテキストウィンドウはもっと長くもつ。

このジョークは診断でもある。アシスタントをより愚かに聞こえさせるのが最善手だというなら、ボトルネックは知能ではない。オーバーヘッドだ。

請求書はコンテキストであって、モデルではない

エージェントのワークロードが実際にどう高くつくのかを腹に落とすには時間がかかる。直感的なモデルは、答えごとに払うので長い答えほど高いというものだ。実際のモデルは、モデルが注意を向けなければならないコンテキストの token ごとに払い、そのコンテキストはターンごとに増えるというものだ。

エージェントがリポジトリを読み、いくつかのコマンドを実行し、結果を見て、コードを書き、エラーメッセージを読むころには、会話は膨大になっている。新しいターンは毎回、履歴全体を引きずる。10 番目のステップは 1 番目よりはるかに高くつく。モデルが遅くなったからではなく、運んでいるものが増えたからだ。

だからこそ、token を 65% 削るツールは些細な最適化ではない。何時間も動くエージェントに当てれば、予算内に収まるセッションと、途中で再起動しなければならないセッションの差になる。

同じ問題への 3 つの攻め方

同じ波に乗る他のプロジェクトは、別の角度からこの問題を攻めており、並べて比べると示唆に富む。

Headroom は 1 週間で約 13,000 スター増えて約 39,000 に達した Python プロジェクトで、ライブラリ、プロキシ、または MCP サーバーとして動くコンテキスト圧縮レイヤーだ。6 つの圧縮アルゴリズムを提供し、60 から 95% の削減を主張している。重要な設計上の選択は、ローカル優先で可逆であることだ。情報を壊す圧縮は圧縮しないより悪いからだ。解凍できるということは、エージェントが埋めたものを取り戻せるということでもある。

Xerj は、特定の、しかも非常に高くつく癖を狙っている。コード、ドキュメント、ログ、PDF を 1 つのコマンドでインデックス化する Rust ツールで、エージェントは grep と sed の探索に token を燃やす代わりに、構造化されたインデックスに問い合わせられる。探索、読み取り、また探索というループは、数行の関連コードのために膨大なコンテキストを消費する。このプロジェクトは grep より約 40 倍少ない token で済むと主張し、Elasticsearch 互換を保っているので、既存のクライアントはそのまま動く。

3 つを並べるとパターンが見えてくる。Caveman はモデルの話し方を変える。Headroom は何が記憶されるかを変える。Xerj はモデルがどこを見るかを変える。節約される token は同じ token だが、レバーが違う。成熟したツール群はいずれ 3 つすべてを必要とする。

原始人の技はなぜ効くのか

原始人のアプローチは、世間で言われるほど効くはずがない。それでもなお効く理由を知る価値はある。

指示で調整されたモデルは、特定のスタイルで役立つように訓練されている。答えの前に質問を復唱し、今やったことを要約し、完全な文で推論を説明し、友好的な一言で締め、すべてに見出しを付ける。どれもタスクには必要なく、どれも token で課金される。

丁寧さを捨て、意味を支える言葉だけを残すようモデルに指示すれば、見た目は粗いがほぼ同じことを伝える出力が得られる。儀式が消える分、情報密度が上がる。簡潔なエンジニアのメモが 10 語で、100 語の会議アジェンダより多くを語りうるのと同じ理屈だ。

ただしトレードオフは現実にある。簡潔な出力は人間が拾い読みしにくく、曖昧な略記は誤解を生み、節約分より高くつく。意図を明示する言葉を削るのは、周囲のコンテキストが十分な意味を運んでいるという賭けであり、その賭けはまさにタスクが異例なときに負ける。圧縮は反復的な作業で最も役立ち、ニュアンスが大事な場面で最も害になる。どこにでも適用する前に覚えておく価値のあるルールだ。

注意力の需要と供給

このカテゴリが今爆発しているのは構造的な理由があり、特定のリポジトリとは無関係だ。

コンテキストウィンドウは大きくなったが、それを埋めたい欲求も大きくなった。リポジトリ全体を読み、長いタスク履歴を保持し、サブエージェントを調整するエージェントは、与えられた空間をすべて使い切る。コンテキストを消費することが仕事を成し遂げる方法だからだ。容量が増えるたびに数週間で吸収され、圧力が戻ってくる。

これは見慣れた力学だ。高速道路を広げても長期的には交通量は減らない。人は通勤が安くなった分だけもっと通勤するからだ。コンテキストも同じだ。窓が大きくなっても不足は終わらない。むしろ妥当な使用量の定義を塗り替え、不足はより高い水準で再び現れる。

つまり圧縮は場当たり的な策ではない。スタックの恒久的な層であり、これを正しく作ったプロジェクトは、データベースやキャッシュに近い位置に落ち着くだろう。目立たず、華がなく、人々が依存し始めたら外せない存在だ。

実際に何を見るべきか

ここではスター数は当てにならない。面白い名前は良いアルゴリズムより速く広がる。どれかを採用する前に確認すべきことが 3 つある。

1 つ目は可逆性だ。元に戻せない非可逆圧縮はバグを見つけにくくする。エージェントが、重要だった細部を落とした要約から推論しているかもしれないからだ。2 つ目は適用範囲だ。すべてのトラフィックを無差別に圧縮するプロキシはいずれ、意味を支える何かを食べてしまい、その失敗はツールのバグではなくモデルのハルシネーションに見える。3 つ目は測定だ。token が 65% 減るというのは特定の種類のセッションについての主張であり、意味がある数字は自分のトラフィックで測ったものだけだ。

もっと深い点は、業界が 2 年かけて能力を追いかけ、いま効率こそが次の実用的な勝ち筋だと気づきつつあることだ。正しく答えるモデルは前提条件にすぎない。10 分の 1 のコストで正しく答えるパイプラインが製品だ。Caveman、Headroom、Xerj は同じ真実を指している。エージェントの仕事では、注意力こそが希少資源で、それ以外はすべて帳簿付けだ。