• GitHubがAIコーディングエージェントのコスト検証を公開。「出力を短くする」と総コストが増える現象を実測
  • 削った情報が必要だったとき、AIはコマンドを再実行して取り戻す。その往復でトークンが膨らむ
  • 実際に効いたのは行番号の削除（3.1%減）や選択的な圧縮（5.5%減）など、品質を落とさない地味な改善
  • GitHubの結論は「ツール呼び出し単位ではなく、タスク全体の成果で最適化せよ」
  • 2026年6月からCopilotは従量課金に移行。日本の開発チームの請求額にも直結する

AIに仕事を任せていて、「もっと短く答えて」と指示したことはありませんか。トークンが減ればお金も減る。そう考えるのは自然です。ところがGitHubの実測は逆でした。出力を短くしたのに、タスク全体ではかえって高くついたのです。何が起きていたのかを見ていきます。

GitHubが公開した「短くしたのに高くなる」検証

2026年9月2日、GitHubが公式ブログで1本の記事を公開しました。テーマは「品質を落とさずにAIコーディングのコスト効率を上げる方法」です。

書いたのはCopilotの開発に関わるErik KristensenさんとNapalys Kliciusさん。Copilotのエージェント機能を安く動かすために試した施策と、その実測結果をまとめています。

日本では9月7日にGIGAZINEが取り上げ、話題になりました。

この記事がおもしろいのは、うまくいかなかった実験まで正直に書いている点です。そのひとつが「出力を短くする」という、いちばん素直に思いつく作戦でした。

RTKという「トークン削り機」

GitHubのチームは、RTK（Rust Token Killer）というツールを使って検証しました。名前のとおり、ツールの応答からムダな部分を削ってトークンを減らす仕組みです。

エージェントがファイルを読んだりコマンドを走らせたりすると、その結果は長々と返ってきます。そこを圧縮すればAIに渡す文章が短くなる。1回あたりのトークンは、たしかに減りました。

ところがベンチマークで測ると、タスク全体のトークン消費はむしろ増えていたのです。

なぜ削ると増えるのか、その正体

理由はシンプルでした。削った部分が、たまたま必要な情報だったときに起きます。

GitHubの説明はこうです。省略された箇所が重要だった場合、モデルは元の出力を開き直したり、同じコマンドをもう一度実行したりして、失った情報を取り戻そうとする。

この「取り戻す作業」が曲者です。やり取りの回数（ターン）が増え、増えた分の文脈がその後もずっと引き継がれていきます。

1回の節約は数百トークン。しかし取り戻すための再実行は数千トークンを一気に食います。しかも、その記録は会話が終わるまで消えません。

資料を半分捨てて臨む会議

会議に必要な資料を「かさばるから」と半分置いてきたとします。運よく捨てた部分が不要なら、身軽で済みます。でも必要だったら、席を立って取りに戻ることになります。

往復した時間、探した時間、会議が延びた時間。すべて足すと、最初から全部持っていったほうが早かった。エージェントの中で起きていたのは、これとまったく同じことでした。

GitHubはこの結果を、はっきりひとことでまとめています。「ツール呼び出しあたりのトークン数は、間違った目標だ」。

実際に効いた4つの改善策

では何が効いたのでしょうか。GitHubが公開した数字を並べます。

  • 行番号プレフィックスの削除：3.1%のコスト削減。ファイルを表示するときの「1:」「2:」といった行頭の番号をやめました。成功率への悪影響は見られていません
  • 出力の選択的な圧縮：5.5%のコスト削減。すべてを一律に削るのではなく、削っても問題ない部分だけを選んで縮めます。今回いちばん効いた施策です
  • タスクツール向けプロンプトの圧縮：2.9%のコスト削減。1ターンあたり約1,300トークンを削り、セッション全体のプロンプトトークンが約1.8%減りました
  • 通知まわりの往復削減：2.3%のコスト削減。エージェントが状況を知らせるためだけに発生していたムダなやり取りを整理しました

単純に足すと約14%です。ただしこれは別々の実験結果なので、そのまま合算できるとは限りません。

それでも品質の目立った低下は検出されなかったと報告されています。安くなったのに、仕事の質は落ちなかったということです。

派手さはありません。行番号を消す、通知の往復を減らす。地味な作業の積み重ねです。ちなみに「短くする」という大鉈が失敗したのに対し、こちらは静かに効きました。

GitHubが示した新しい物差し

今回いちばん重要なのは、個々の数字ではなく考え方の転換です。

GitHubはこう書いています。目標はトークンを減らすことではなく、タスクを前に進めるのにちょうどよい量の文脈にアクセスすること。そして「ツール呼び出しではなく、成果を最適化せよ」と。

ここには2つの物差しがあります。ツール呼び出し1回ごとのトークン数と、タスクが完了するまでの総コストです。

前者は測りやすく、管理画面にもきれいに並びます。けれど下がって喜んでいたその数字が、実は後者を押し上げていました。測りやすい指標を追いかけた結果、本当に払っているお金が増えていたわけです。

「短いほどいい」が半分だけ正しい理由

文脈は短いほうがいい、という主張にも根拠はあります。AI研究企業のChromaは18の主要モデルを検証し、入力が長くなるほど出力の品質が下がることを確認しました。「コンテキストロット（文脈の腐敗）」と呼ばれる現象です。

公称の対応量に収まっていても品質は落ちますし、大事な情報が真ん中に埋もれると見落とされやすいこともわかっています。

だから「短く」は間違いではありません。問題は削る場所です。要らないものを捨てるのが整理で、要るものまで捨てるのはただの紛失。GitHubの実験は、その境目を実測で示しました。

他の節約テクニックとどう違うのか

トークン代を下げる手法は、2026年に入ってから一気に増えました。今回の結果を、代表的なやり方と並べてみます。

プロンプト圧縮・Caveman Prompt

2026年3月に話題になった「Caveman Prompt（原始人プロンプト）」は、冠詞や前置き、あいまいな言い回しを削り、矢印や記号で関係を示す書き方です。出力トークンが減り、精度は落ちにくいとされています。

ただしこれは人間が書く指示文を削る話。GitHubが失敗したのはツールが返す結果を削る話です。同じ「短くする」でも、削る対象がまったく違います。指示は削れても、証拠は削れないと考えるとわかりやすいはずです。

プロンプトキャッシュ

同じ文章を繰り返し送るとき、2回目以降を割引価格で処理する仕組みです。読み出しは通常入力の1割程度まで下がる場合があり、削減効果は大きくなります。

こちらは情報を捨てずに安くする方法なので、今回の落とし穴とは無縁です。むしろ相性のいい組み合わせといえます。

AIメモリ系のツール

Hugging Faceが2026年9月に公開した「Funes」のように、セッションをまたいで記憶を持たせるアプローチもあります。毎回ゼロから説明し直す手間が消えるため、トークンが大きく減ります。

これも「必要な文脈を、必要な形で渡す」という発想です。GitHubの結論と同じ方向を向いています。

モデルの使い分け

安いモデルで何度もやり直すより、高いモデルで一発で終わらせたほうが総額は安い。そんな考え方も広まっています。これもまた、1回の単価ではなくタスク単位で見るという同じ発想です。

整理すると、情報を捨てて安くする手法だけが危ない。渡し方を工夫する手法は、素直に効きます。

日本の開発現場に効いてくる理由

「海外の大企業の話でしょう」と思うかもしれません。ところがこれは、日本のチームの請求書に直結します。

GitHub Copilotは2026年6月1日から全プランが従量課金に移行しました。それまでの「プレミアムリクエスト」という回数制は廃止され、GitHub AI Creditsという仕組みに変わっています。

課金は入力トークン・出力トークン・キャッシュ済みトークンの消費量で計算され、1クレジット＝0.01ドル換算です。つまりエージェントが動いた分だけ、そのまま請求額に反映される構造になりました。

コード補完は今も無料枠で使えますが、エージェントモード・チャット・コードレビューはクレジットを消費します。

個人向けはPro（月10ドル・15ドル分のクレジット）、Pro+（月39ドル・70ドル分）、Max（月100ドル・200ドル分）。法人はBusinessが1人あたり月19ドル、Enterpriseが39ドルで、そこにクレジット消費が乗ります。

ある開発チームの月末

従業員50人のソフトウェア企業を想像してみてください。情シス担当者が月末に管理画面を開くと、想定していた金額を大きく超えています。

原因を追うと、一部のエンジニアがエージェントに大きなリファクタリング（コードの作り直し）を任せていました。悪気はありません。ただ、1回のタスクが数十ターンに膨らんでいたのです。

ここで「出力を短く設定しよう」と対策を打つと、今回GitHubが踏んだ地雷をそのまま踏みます。見るべきは1ターンの長さではなく、1タスクが何ターンで終わっているかでした。

今日から見られる数字

日本の実務家からは、月初にユーザー別の消費ランキングと使われていないシート（利用枠）を点検する運用が推奨されています。ヘビーユーザーはコストが大きく膨らむ可能性がある、とも指摘されています。

そこに1項目足すとしたら、「1タスクあたりの平均ターン数」です。ターンが増えているなら、エージェントはどこかで情報を取り戻すために走り回っています。

よくある質問（FAQ）

Q1. 結局、AIの出力は短くしないほうがいいのですか？

いいえ、短くすること自体は有効です。GitHubも選択的な圧縮で5.5%削減しています。危ないのは中身を見ずに一律で削るやり方です。削っても支障のない部分を選べているかどうかが分かれ目になります。

Q2. 個人でChatGPTやClaudeを使う場合にも関係しますか？

関係します。定額プランでも、無理に短く指示した結果AIが何度も確認し直せば、利用上限に早く到達します。API従量課金なら、そのまま金額に跳ね返ります。

Q3.「タスク単位で見る」とは具体的に何を測ればいいですか？

ひとつの依頼が完了するまでの合計トークン数・合計時間・やり直し回数の3つです。1回の応答の長さだけを見ていると、今回のような逆転を見逃します。

Q4. 削減率が3%や5%と小さく見えますが、意味はありますか？

あります。従量課金では毎日・全員に効き続けるためです。月100万円使うチームなら、合わせて1割強でも年間で百万円単位の差になります。品質を落とさずに得られる点も重要です。

Q5. GitHubの数字はそのまま自社に当てはまりますか？

そのままとは限りません。GitHubはベンチマークとオープンソースのリポジトリで測っており、具体的なタスク数やモデル名までは公開していません。考え方を借りて、自社の数字で測り直すのが現実的です。

まとめ

  • GitHubは、AIエージェントの出力を短くしたらタスク全体のコストが増える現象を実測した
  • 原因は、削られた情報を取り戻すための再実行。ターンが増え、文脈が後に引き継がれる
  • 効いたのは行番号削除（3.1%）、選択的圧縮（5.5%）、プロンプト圧縮（2.9%）、通知の往復削減（2.3%）
  • 結論は「ツール呼び出しではなく、タスクの成果を最適化せよ」
  • 2026年6月からCopilotは従量課金。日本のチームにも請求額として直接効いてくる

まずは自分のチームで、1タスクが何ターンで終わっているかを1週間だけ記録してみてください。削るべき場所は、その数字が教えてくれます。

参考文献