AIにコードを書かせると、頼んだ以上の出力が返ってくることはありませんか。
使う予定のない汎用化、過剰なコメント、ていねいすぎる説明文。
こうした「余分」は、そのままトークン消費に跳ね返ります。
そして、コストを押し上げます。
しかも出力が増えれば、人間が読む手間も増えていく。
海外の開発者コミュニティで、この問題に正面から取り組むスキルが話題になっていました。
本記事では、そこで交わされた議論を整理します。
そのうえで、AIの出力を小さく保つ考え方を紹介します。
そもそも「出力を削る」とは何か
AIコーディング向けのスキルには、出力を絞る方向の工夫がいくつかあります。
議論の出発点になったのは、すでに知られていた2つのスキルでした。
ひとつは「最小限のコードしか書かせない」方針のスキルです。
いわゆるYAGNI、つまり「今いらない機能は作らない」を徹底させます。
もうひとつは「文章を簡潔にさせる」方針のスキル。
こちらはAIが返す説明やレポートの言葉数を削ります。
片方はコードを、もう片方は文章を削る。
狙う場所が違うわけです。
話題のスキル(投稿者は「Honey」と呼んでいました)は、この2つを置き換えるためのものではありません。
それぞれの得意な部分を取り出して組み合わせる。
さらに、3つ目のレバーを足す。
そういう立ち位置のスキルです。
ベンチマークの中身
投稿には、3つのスキルを比べたベンチマークが添えられていました。
条件は次のとおりです。
23のタスクをClaude Opus 4.8で実行し、それぞれ3回ずつ走らせる。
採点は4つのモデルからなる審査パネルが担当します。
評価基準は中立で、出力が長いことへの加点はありません。
フェアに数字を出そうとした設計が読み取れます。
結果を表にまとめると、こうなります。
| タスク種別 | 簡潔文章型(Caveman) | 最小コード型(Ponytail) | Honey |
|---|---|---|---|
| コード(14タスク) | 品質101% / −37% | 99% / +24% | 98% / −49% |
| ユーザー向け文章(7タスク) | 99% / −18% | 95% / −33% | 101% / −6% |
| エージェント間の受け渡し(2タスク) | 67% / −23% | 50% / −22% | 100% / −51% |
ここで一点、注意したい数字があります。
「品質101%」のような表記です。
これは絶対値ではありません。
スキルを何も使わない素の出力を100%としたときの相対値です。
あるタスクで素のAIより1%だけ高く採点された、という意味になります。
スキルを使ったほうが素の出力をわずかに上回る場合があるので、100%を超えることもあるわけです。
ただし、1%程度の差は審査のばらつきの範囲に収まります。
投稿者もこう補足していました。
ユニットテスト済みで答えがほぼ固まっているコード課題なら、98〜101%は事実上の引き分けと見るべきだ、と。
本当の差が出るのは、文章まわりとエージェント間の受け渡しのほうです。
「+24%」という意外な結果
表をよく見てください。
最小コード型がコードで「+24%」になっています。
トークンを減らすはずのスキルが、なぜか出力を増やしている。
投稿者自身も意外だったと書いていました。
理由は、そのスキルが持つ必須の自己チェック機能にありました。
書いたコードを毎回自分で検証させる仕組みです。
ところが、検証するものが何もない簡単なタスクでも、その手続きが律儀に走ってしまう。
結果として、たいして中身のない確認パートが出力をふくらませていたわけです。
Honeyはこの点に手を入れています。
最小コードを書かせる「はしご」の部分は受け継ぐ。
けれど、無駄に重い自己チェックは外す。
良いところだけを抜き出した、というのはこういう意味です。
3つ目のレバー：受け渡しの圧縮
3つ目のレバーは、エージェント同士がデータを渡し合う場面で効いてきます。
簡潔文章型のスキルは、この受け渡しを圧縮しすぎる弱点を抱えていました。
表のとおり、エージェント間タスクでは品質が67%まで落ちます。
情報を削りすぎるからです。
そのため、あとから正確に元の内容を取り出せなくなります。
そこでHoneyが採用したのが、ESO(Efficient Structured Output)と呼ばれる専用の書式でした。
きれいに整形したJSONの代わりに、もっと詰まった形式でデータを渡します。
仕組み自体はシンプルです。
まず、項目名を最初に一度だけ宣言する。
次に、データの各行はタブ区切りで並べる。
さらに、行数を先頭に書いておく。
これで受け取った側がチェックサム代わりに使えます。
たとえば、検出した問題を渡す場面なら、おおよそ次のような形になります。
!eso/1
issues[2]{level,path,detail}
high src/login.py 入力検証が抜けている
low src/util.py 未使用の変数が残る
この書式によって、受け渡しのサイズは約半分に縮みます。
それでいて、意地悪な質問で内容を問い直しても情報が欠けません。
投稿によれば、ロスのない復元が100%通ったとのこと。
同じテストで、ほかの2つのスキルはどちらも失敗したそうです。
サイズを削りながら情報も守る。
この両立がレバーの肝です。
入力側の圧縮とは別の話
コメント欄では、別のツールとの違いを問う質問が出ていました。
トークンを減らす道具は他にもあるけれど、何が違うのか、という疑問です。
投稿者の答えは明快でした。
狙う層がそもそも違う、と。
比較に挙がったツールは、モデルに「入っていく」ものを圧縮します。
ツールの実行結果、ログ、検索で引っぱってきた文書のかたまり。
こうした入力側を縮める役割です。
いっぽうHoneyが扱うのは、モデルから「出てくる」もの。
AIがそもそも書くコードや文章の量を、最初から減らします。
別のコメントは、両者を組み合わせたほうが得だと指摘していました。
層が違うのだから、削減効果は重なる。
だから、入力を縮めるツールと出力を縮めるツールを併用すれば、トークン効率はさらに上がる。
理にかなった見方でしょう。
投稿者によれば、Honey側でも入力圧縮に取り組んでいるとのことでした。
機械学習を使わない決定論的な方式だそうです。
いまのところ入力トークンを26%ほど減らしても、品質は落ちていない、という段階だといいます。
ワークフロー系スキルとの相性
もうひとつ、興味深いやり取りがありました。
「Superpowers」のような別系統のスキルと一緒に使えるか、という質問です。
投稿者の回答は、問題なく重ねられる、というものでした。
役割が分かれているからです。
Superpowersはワークフローやサブエージェントの分担といった「進め方」を司る層。
Honeyは「出てくるもの」を縮める層。
だから、Superpowersの各ステップが吐き出す量をHoneyが小さくする。
そういう形で噛み合います。
ただし、ひとつ落とし穴があると説明されていました。
Honeyはセッション単位のフックで有効になります。
ところが、Superpowersが新しく立ち上げるサブエージェントは、独立した文脈で動きます。
そのため、その設定を受け継ぎません。
つまり、実装役も、レビュー役も、修正役も、それぞれHoneyが効いていない状態で動いてしまう。
フルサイズのコードと長いレポートが返ってくるわけです。
こうしたワークフローは大量のサブエージェントに枝分かれします。
だから、まさにそこでコストが積み上がります。
この穴をふさぐため、両者をつなぐ追加のスキルを用意中だといいます。
サブエージェントに作業を振る直前に発動し、貼り付け用の指示文を渡してくれる仕組みです。
指示は役割ごとに2種類に分かれます。
実装役には、本当に必要なコードだけを書かせ、レポートは短くさせる。
ただし、コードや識別子、仕様で決まった値はそのまま正確に残させます。
いっぽうレビュー役には、文章だけを縮めさせ、判定や深刻度には手を付けさせません。
レビューが短くなるのは構わない。
けれど、甘くなるのは品質低下になる。
この線引きの明確さが、設計の細やかさを物語っています。
導入方法
Honeyはオープンソースで、MITライセンスのもとで公開されています。
Claude Codeで使う場合は、プラグインのマーケットプレイスに登録します。
そのうえでインストールする流れです。
/plugin marketplace add Green-PT/honey-for-devs /plugin install honey@greenpt
特定の環境に縛られず、幅広いエージェントで使いたい場合もあります。
そのときは、配布されているインストールスクリプトを実行する方法が案内されていました。
ベンチマークも自分の手元で再現できるよう公開されています。
数字をうのみにせず、気になるなら自分で回して確かめられる。
この姿勢は信頼につながります。
まとめ
今回の議論から見えてくるのは、トークン削減が一枚岩ではないという事実です。
コードを削る、文章を削る、受け渡しを圧縮する。
役割の違う複数のレバーがあります。
そして、それぞれ効く場所も、効きすぎて壊れる場所も異なります。
Honeyという例は、既存スキルの長所を組み合わせました。
さらに、弱点を補う3つ目のレバーを足しました。
その結果、品質をほぼ保ったまま出力を大きく縮めています。
そして、入力側の圧縮や進め方を司るスキルとは、競合ではなく共存できる。
層が違えば、組み合わせて効果を重ねられる。
そういう見方も示されました。
AIへの指示の出し方ひとつで、出てくる量も、かかるコストも変わってきます。
その手応えを、ぜひご自身で確かめてみてください。
