#トークン削減

最初に思ったのは、AI coding agent のコストって、たしかに「思考」より「運搬」で膨らんでいるんだな、ということでした。記事の言い方を借りるなら、Claude Code がやっている仕事の多くは reasoning ではなく I/O です。ファイルを何本も読ませたり、同じ形の test を吐かせたり、更新済みの doc を整えたり。人間から見ると地味な作業ですが、こういう処理ほど frontier model の token を平気で食います。 そこを Portal の mode に逃がす、という発想はかなり筋がいいと思いました。bulk-reader と code-writer の役割分担は、派手さはないけれど実務では効きそうです。特に印象的だったのは、「output only the code」といった細かい指示まで含めて、Claude に余計な整形や説明をさせないようにしている点です。生成された Markdown fence を Claude がまた剥がす、みたいな無駄が積み上がるのは、現場では本当にある話だろうなと思います。 一方で、ここはうまく切り分けているな、と

200,000 tokens を先に食ってからようやく答え始める、という話を読むと、便利そうに見えるAIツールの裏側で、ずいぶん雑なことが起きていたんだなと感じる。人間なら「資料が多いから少し重い」で済む場面でも、LLM だとその「少し重い」がそのままコストと待ち時間に跳ねる。しかも利用者から見えにくい形で起きていたのが、かなり気持ち悪い。 いちばん引っかかったのは、問題が“賢さ”ではなく“読み込み方”にあったことだと思う。Claude Code の skill が、質問に答える前に関係ありそうなドキュメントをまとめて抱え込んでいたわけで、これは人間でいえば「とりあえず本棚の全部を机に積む」みたいなものだ。実際の作業では、必要なページを必要なときに開けばいい。そこを on-demand に変えて 25K まで落とした、というのはかなり素直な改善に見える。 ただ、ここで終わらないのも面白い。LLM 周辺の製品は「モデルの性能」ばかり話題になりがちだけれど、実際には入力の設計、ドキュメントの切り出し方、どのタイミングで何を読むか、みたいな地味な部分が体験を決める。今回の話は、その地味な部分

Claude CodeのようなLLM向けツールで、長いテキストをそのまま送らず、画像に変換してからモデルに渡す仕組み 文字がぎゅっと詰まった内容ほど得をしやすく、場合によってはトークン使用量を大きく削減できる ただし万能ではなく、IDやハッシュのような“1文字でも間違えたら困る情報”は危ない だからこそ、安くなる場面と危ない場面を見極める設計になっている 発想はかなり攻めているが、実務の痛点をちゃんと突いていて面白い pxpipeは、ひとことで言うと「LLMに渡す長文を、必要に応じて画像に圧縮してしまうローカルProxy」です。Proxyというのは、アプリとAPIのあいだに入って通信を中継する仕組みのこと。ブラウザの世界でいう“中継サーバー”みたいなものだと思えば大きく外れていません。 普通、LLMにたくさんの文章を読ませると、そのぶんトークンが増えます。トークンは、AIが文章を扱うときの細かい単位で、課金やコンテキスト長の計算に使われます。つまり、長文を入れるほどお金も容量も食う。これは避けようがない、と思われがちです。 でも pxpipe はそこに逆張りをします。大量のテキストをP