トークン使用量を37.91%削減した、たった1行のプロンプト
(modgo.org)要約
- コード構造（戦略・ファクトリーパターン、ファイル分割、
.cursorrulesの整理）を1行のプロンプトでリファクタリングした後、同一の機能追加プロンプトを実行したところ、AIのトークン使用量が大幅に減少したという実験レポート（Zero-context、N=5）。実験に使用したプロンプトとソースが公開されており、再現可能。
主要データ
-
Claude-4 Sonnet: 平均 390,159 → 242,265 tokens（−37.91%）
-
GPT-5: 平均 315,839 → 233,634 tokens（−26.03%）
-
基準: Cursorが表示した Total Tokens。モデル間の絶対値比較には意味がない（モデルごとに集計差があるため）。
設定（要約）
-
IDE Cursor 1.6.6、モデル GPT-5 / Claude-4 Sonnet
-
すべてのプロンプトは Zero-context、各ラウンドごとにエディタを完全再起動
-
成功判定: 単一プロンプトで要件を実装できた場合を成功として集計
なぜ重要か
-
「良いコード構造」は人が読みやすいだけでなく、AIのトークン・コスト・時間にも影響することを示す定量的根拠
-
プロンプトとリポジトリの公開により再現性を確保（実務適用・後続実験にすぐ活用可能）
個人的な感想
- Cursorユーザーとして、コスト削減のための重要な方法論を提供する優れた手法の提案だと思います。
- 本文にもあるように、サンプリングが十分でない点はやや惜しいです。
34件のコメント
タイトル釣りがうまいですね..
実験は楽しく拝見しました。
ありがとうございます。
内容とは別に、「たった一行のプロンプト」というタイトルのせいで、期待していた内容と本文の中身が違って見えて、なおさらそう感じる気がします
はい、私も同じ考えです。 しくしく
申し訳ありません;;
この記事に多くの関心をお寄せいただき、ありがとうございます。海外向けの配布を主な目的としていたため英語で記事を作成しましたが、そのためにいろいろな問題が発生しているようです。
そこで、韓国語で整理したポストを共有します。
https://modgo.org/tokeun-sayongryang-37-91-reul-gamsosikin-dan-hanjuly…
追加で使用したプロンプトに関連する内容を整理してお伝えします。
どちらかといえば、開発者の方が構造改善用のプロンプト作成に向いています。プログラムごとに性質が異なるため、効率の高い改善を行うには、ある程度の開発知識が必要です。
とはいえ、非開発者のバイブコーダーの方々がこの方法を使えないという意味ではありません。効率には差が出るかもしれませんが、"プロジェクトのコードを整理して。使っていないコードは削除して。" のようなシンプルな命令だけでも、AIはファイルやクラスを分離・整理する動きをします。
ただし、構造改善の細部の違いが効率の差を生みうる点については、参考資料の扱いに注意が必要です.
プロンプトには要点だけを論理的に盛り込むべきだ。つまり、プロンプトにあれこれ多く付け加えるほどノイズが増え、結果として出てくるコードも複雑になり、ノイズも多くなる、ということですか？
AIにコード構造のリファクタリングを指示した後、消費されるトークン量が減ったというのが核心です。
逆に言えば、コードに構造的な欠陥がある状態で指示を続けると、トークン使用量が増えるとも説明できそうです。
要するに、ソースコードの構造改善が必要だという内容であり、プロンプトを要点だけに絞って論理的に書くべきだという意味ではありません。
私もこの紹介文と原文があまりにも冗長で、文章を書くのがあまり得意でない人が書いたように感じられて、読む過程が大変だったのですが、
要するに
「トークンを減らす構造的制約を盛り込んだ一行の指示を追加せよ」
くらいにまとめられますね
この記事は『実験』研究に近い性格のものであるため、
この記事に含まれるすべての数値は、この記事を読むすべての人が『再現』できるようにすることに重点を置いています。
そのため、使用した元のソースコードと、テストに使用したすべての手順をすべて記録し、
すべての実験者が同じ結果を得られるよう、情報を提供することに内容の重点を置いています。
コメント欄の雰囲気を見て感じたのですが、
今後は3行要約寄りの記事を1本と、
詳細を知りたい人向けの記事を分けて2本にして書くべきかとも考えています。
この記事のどの部分が過度に複雑に感じられたのか、そして冗長だったのかを教えていただけると、
今後の記事執筆にあたって大いに助けになると思います。
私も似たように感じました。
書かれた方の意図はわかるのですが、されていることに比べて文章がやや複雑すぎる気がします。
できるだけ実験に使われたディテールを文章に溶け込ませたくてこのように書かれたのだと思いますが、
核心だけを簡潔に抜き出しても、このテーマに関心のある方ならおそらく理解できると思います。
思い切ってディテールを削り、要点だけに絞ればもっと良くなるのではないかと思います。
私は、書き手の意図や結果自体は面白いと感じました。
より良いソースコードがより少ないトークン消費につながる、というのが主な論旨であり、
それに関連した実験設計をして実施されたように見えます。
実験について私が理解した部分だけを並べると、
ということのようです。
そして私の理解が正しければ、プロンプトで前処理したソースコードのほうが全体的にトークン消費量が少ない、という結論のようです。
面白い結論ではありますが、実験に対する私の意見は次の通りです。
公平な比較ではない
数値上は下がっているように見えますが、ソースコードを処理するための総トークン数で比較するのが正しいと思います。
言い換えると、前処理のために使われたトークン数も考慮されるべきだと思います。
前処理に使われたトークン数が過度に大きければ、実質的にはトークンをより多く消費していて無意味になりますし、少なかったとしても、実際のトークン消費量の差は文章で示されたものよりかなり小さいのではないかと思います。
前処理前後のソースコードを比較する必要がある
前処理に使われたトークンを除外するなら、問い合わせ時のトークン消費量は有意に減少しているように見えます。
ただし、ソースコードのどのような違いによってこうした差が出るのかを分析すれば、文章の意味はより大きくなると思います。
そうした差を最大化するための前処理プロンプトの最適化が可能だという話になりますから。
書き手の方はコード構造のリファクタリングがこの結果をもたらしたとおっしゃっていますが、私は同意しておらず、まだわからないと考えています。
AIに対して、リファクタリング以外の部分を改善した場合でもトークン消費量の減少が起こりうるかもしれないからです。
もう少し多様な実験が必要
現在のコードだけでなく、別のコードベースでも同じ実験を回してみるべきだと思います。
これが一貫して良い結果になるのかどうかを判断する必要があるからです。
ただ、現実的にはこれはテストが難しいかもしれないという点は理解できるので、参考程度に受け取るのがよいと思います。
全面的に同意します。このような形の批判は大いに歓迎します。
世の中は一人で生きているわけではなく、個々人の能力や状況も異なります。
私もまた一介の開発者にすぎず、個人の費用ですべてのテストを実行することはできません。
この記事が種となって、多くの人々に良い影響を与え、そして続く多くの研究の出発点になればと願っています。
サブタイトルが内容と合っていませんね。整理し直すなら、「トークン削減を引き起こす、より明確な要因分析が必要だ」がサブタイトルとしてふさわしく見えます。
この内容には同意できる部分が多いです。ただし、本稿の性格としては、「この記事を見る人たちに現実的な適用方法を提案する」という要素を含んでいます。
すでに、この記事についたコメントを見るだけでも雰囲気は分かるのですが、私も最近知ったことではあるものの、AIユーザーの中には非開発者のバイブコーダーの方々も多いと推測されています。
AIを介さず、著者が直接調整したコードから大きな成果を生み出すことになった場合、
それは著者が開発力を誇示し、AIの能力を軽視している結果だと受け取られやすいです。
そのため、さまざまなバイブコーダーが活用できる「プロンプト」という要素として、その結果を誰もが体感できる例を扱うことになりました。
この研究に続いて、AIのトークン使用量に影響を与える要素を細分化できる研究が続くとよいと思います。
1回の構造修正によって、n回のプロンプトにおけるトークン消費率を下げる効果が生じる場合、トークン削減量は同様に行われるn回全体にわたって反映されます。
nはプロジェクトの目的と機能数、そしてそのためのコード量と複雑さによって決まる数値であり、
また最近の Cursor / Claude Code agent では、無限反復実行やAIの無分別なトークン使用の問題を解決するため、実行単位を小さくするアップデートが行われていることから、
プロジェクトの複雑度に関するnの値の研究は、別途行うのが適切だと考えます。
ここで見落としてはならないのは、構造の改善は決してコード開発と独立して起こる行為ではないという点です。
最初のプロンプト、あるいはAI ruleset（
.cursorrules）のような制約を通じて、base context として影響を与えられる部分であり、プロジェクト開発サイクルの途中で1回の構造改善だけですべてがうまくいくわけではありません。
つまり、一定周期でコード改善を計画するよりも、base context として正しい構造へ導くほうがより良い方向です。
また、base context として構造誘導の指示ルールがある場合とない場合に関する研究は、別途行うのが適切に思われます。
1番の項目について整理すると、
1回の構造改善プロンプト命令のトークン使用量を加算して計算すべきだという主張には語弊があります。
コメントでおっしゃっていることが何なのか、正直よく理解できません。私は、2つの方法を公平に比較するなら、消費される総トークン数を比較すべきではないか、というのが私のコメントでした。リファクタリングもやはりトークンを消費するのではありませんか？
加えて、ご返信いただいた内容は記事にも書かれておらず、実験も行われていない内容のように思えます。1回の問い合わせあたりのトークン比較ではなく、複数回問い合わせた場合にはリファクタリングのオーバーヘッドが低くなり、各問い合わせあたりの期待トークン数が減るため、総トークン数で得になるだろう、というお話のように見えます。これは、複数回の問い合わせでも筆者のお考えどおりにコストダウンが維持される場合に限って言えることで、かなり理想的な状況を想定した話のように思います。リファクタリングによるコストダウンが、その後の問い合わせ回数に関係なく維持される保証はありませんし、実験なしに仮定することもできません。意図された主張をされるのであれば、1回を超える問い合わせに対するコストダウンを実験で示していただければよいと思います。しかし、実験は1回だけ行って比較されたのではないでしょうか？
付け加えると、これはあくまで私の仮定にすぎませんが、同じ目標（理想的な最終出力物）のために問い合わせを無限に繰り返していくなら、理想的な状況ではリファクタリングの有無に関係なく、コードは同じ形に収束していくはずです。（理想的な最終出力物は一意）
この仮定が合理的であるなら、問い合わせが繰り返されるほどリファクタリングの有無による差は小さくなるため、トークンのコストダウンによる利得も次第に小さくなるように思います。したがって、巨視的に考えたとき、このコストダウンによる利得が十分に持続しないのであれば、問い合わせに使われる総トークン数の差は有意ではない可能性もあるのではないでしょうか
また、プロンプトの連結回数の実験に関する内容についてもご質問いただきました。
実のところ、これは逆に言えば、著者が俗にいうところのごまかしをしやすい要素でもあります。
開発という行為そのものには、進める方向に非常に多くの選択肢が存在しており、トークン使用量がより大きく開く方向にプロンプトを積み重ねてしまえば、その数値は雪だるま式にさらに大きく膨れ上がってしまうでしょう。
研究には「Cumulative Science」という哲学があります。
少なくとも私の基準では、1回の命令に対するトークン使用量に関する研究をこれまで一度も見つけたことがなかったため、
いきなりN回の研究をするのではなく、確実な1回分のテストと結論を扱うことに集中したのであり、
N回の研究は、この実験に続いて研究が進めばよいでしょう。
また別の記事として、コードベースの違いによるAIの挙動の差を扱ったことがあります。
（これもこのGeekNewsで紹介されたことがあります: https://modgo.org/aineun-hyeonjae-kodeu-gujoyi-byeoge-maghyeoissda/）
簡単に説明すると、AIに入力されるコードベースによって出力物の品質が変わる、というテストと結果を扱っています。
初期コードベースの品質や方向性によって、その後のコード品質が維持されることもあれば、継続的に悪化していくこともある、という意味です。
つまり、プロジェクト初期段階でのリファクタリングコストと、かなり進行したプロジェクトでのリファクタリングコストは大きく異なりうる、ということです。
もし質問者の方が開発者であれば、「帆船の上の空母」という言葉を一度くらい聞いたことがあるかもしれませんが、
リファクタリングをどの時点で行うべきか、あるいはプロジェクト初期に塗られる思想や設計によってコストが莫大に変わる、という深遠なテーマです。
これを変数として含めて結論を不安定にするより、
「なるほど、コードベースの品質が良ければトークン使用量が減るのだな」という点だけは確実に説明できるテストを行った、ということです。
改めて説明します。
バイブコーディングの実践者は、非開発者から熟練開発者まで幅広く存在します。彼らが持つ知識の状態によって、この文章の内容とはまったく無関係に、出力物の品質は大きく異なります。
ある人は、Cursor の利用を前提に
.cursorrulesに基本的な OOP 規約やクラス／メソッド分離ルールを入れて、ほとんどリファクタリングが不要な形で運用できているかもしれませんが、また別の人は、あまりにも基本的な主要内容の把握不足によって、低水準のコードを大量生産してしまっているかもしれません。
そもそも、プロジェクトルールの設定によってコード品質を高く保つべきだという記事や経験談は、以前から多くあります。
これは、明示的なリファクタリングをしなくても、トークン使用量の観点で利益を得ている人がいる可能性を示唆しています。
ただし、上記のケースでは、そのルール定義によって実行単位ごとの明確なトークン使用量削減までは整理されていません。そこで本稿では、コードベースの品質によるトークン使用量の差をテストし、その結果を整理しました。
つまり、ユーザーによっては、明示的リファクタリングの回数そのものが再び 0〜n 回という変数になり、
この文章の本質的な意図は、『なぜ品質の高いコードベースを気にかけるべきなのか？』を説明している、と捉えていただくのがよいと思います。
著者です。フィードバックありがとうございます。次回の記事作成時の参考にさせていただきます。
このプロンプトも一緒に入れたらコストが下がった、ということですか？ 私が要点を正しく理解できているのか、いまいちよく分かりません。
補足すると、コードの構造はそのプロジェクトに合った形へと構造改善が起こるべきです。下の回答にある内容のように、AIに構造改善について尋ねると、そのプロジェクトに適した適切な構造改善の方法を教えてくれます。
個人的におすすめのやり方は、AIにいきなり構造改善の命令を入れるのではなく、まず提案してみるようにさせることです。すると応答を返してくれるので、対話をしながら十分に効率的な提案に到達した後で、適用してほしいという形で進めるとよいです。
追加のヒントを一つ挙げると、できるだけコンテキスト要約（文脈バッファの初期化）が起こる前に作業を完了するのがよく、文脈バッファの初期化が避けられない場合は、事前に
.cursorrulesに改善ルールを追加するよう依頼しておくのがよいです。作業中に文脈の初期化が起こると、AIがミスをする可能性が高くなります.ちなみに、入力されるソースのサイズが小さくなるほど消費されるトークン量が減るというのは、よく知られた明白な事実です。.cursorignore ファイルもそのために作られたわけです。
一般的に、AI に構造改善をさせると、ほとんどの場合ソースコード量が減る傾向があるので、どんな理由であれ整理させればコストが下がるというのは信ぴょう性のある主張に思えます。
この記事には、良い構造へと誘導することで、追加のトークン使用量削減を実現できるという主張が加わっているわけです。
その通りです。本文にもあるとおり、コード改善後にプロジェクトのコードサイズが小さくなったのは事実です。
ただし、この例では文字数ベースで約10%程度の減少が起きていますが、これだけでトークン使用量の37.91%減少を説明することはできません。
本文にソースリポジトリのリンクがあり、誰でも再現してテストできます。
私自身は実際にこのようなテストをしてみたわけではありませんが、
「現在のコードを分析して、あなたが管理しやすい形に構造改善してほしい」
というプロンプトも機能するのではないかと思います。
正確な要点としては、AIに機能要件だけを伝えるのではなく、適切で正しい構造へうまく導くことがコスト削減に役立つ可能性がある、という意味だと考えます。
https://modgo.org/dib-rag-gaelreogtig-modeu-seuteurimeoreul-wihan-ciji…
このディープラクギャルモードはご自身で直接作られたのですか？
これもバイブコーディングで作業されたのでしょうか？
こんにちは。ブログ運営者です。
DeepRAGGalモードは私が直接制作したもので、現在は個人サーバーを通じてサービス中です。（チジジク OAuth認証のために必要です）
このモードにはUnreal Engineによる開発が含まれますが、残念ながらUnreal Engine側はバイブコーディングが難しいです。
その代わり、モード開発の方法自体は難しくないため、興味があればモード開発ガイド（https://modgo.org/dib-rag-gaelreogtig-modeu-gaebal-part-1/…
他のコミュニティでモードを公開されたのを見ましたが、本当にそのモードを作った方が書いた文章だったんですね。
ブループリントモードの講座記事まで書かれていたとは思わず、ありがとうございます。
もともと開発がとてもお上手な方だったんですね！
ああ、他のコミュニティで私のモードをご覧になったことがあったのですね。
投稿した文章には至らない部分も多いですが、お役に立てるならうれしいです。
ああ、イライラする
どの点がご不快だったかをお知らせいただければ、丁寧に回答いたします。
サイトの利用方法 のコメント投稿項目をご確認ください。
親切で丁寧に話してください。
反論がある場合は、その内容だけを書いてください