この記事は『実験』研究に近い性格のものであるため、

この記事に含まれるすべての数値は、この記事を読むすべての人が『再現』できるようにすることに重点を置いています。

そのため、使用した元のソースコードと、テストに使用したすべての手順をすべて記録し、

すべての実験者が同じ結果を得られるよう、情報を提供することに内容の重点を置いています。

コメント欄の雰囲気を見て感じたのですが、

今後は3行要約寄りの記事を1本と、
詳細を知りたい人向けの記事を分けて2本にして書くべきかとも考えています。

この記事のどの部分が過度に複雑に感じられたのか、そして冗長だったのかを教えていただけると、
今後の記事執筆にあたって大いに助けになると思います。

3. より多様な実験が必要

全面的に同意します。このような形の批判は大いに歓迎します。

世の中は一人で生きているわけではなく、個々人の能力や状況も異なります。

私もまた一介の開発者にすぎず、個人の費用ですべてのテストを実行することはできません。

この記事が種となって、多くの人々に良い影響を与え、そして続く多くの研究の出発点になればと願っています。

2. 前処理の前後でソースコードを比較する必要があります。

サブタイトルが内容と合っていませんね。整理し直すなら、「トークン削減を引き起こす、より明確な要因分析が必要だ」がサブタイトルとしてふさわしく見えます。

この内容には同意できる部分が多いです。ただし、本稿の性格としては、「この記事を見る人たちに現実的な適用方法を提案する」という要素を含んでいます。

すでに、この記事についたコメントを見るだけでも雰囲気は分かるのですが、私も最近知ったことではあるものの、AIユーザーの中には非開発者のバイブコーダーの方々も多いと推測されています。

AIを介さず、著者が直接調整したコードから大きな成果を生み出すことになった場合、

それは著者が開発力を誇示し、AIの能力を軽視している結果だと受け取られやすいです。

そのため、さまざまなバイブコーダーが活用できる「プロンプト」という要素として、その結果を誰もが体感できる例を扱うことになりました。

この研究に続いて、AIのトークン使用量に影響を与える要素を細分化できる研究が続くとよいと思います。

1. 公平な比較に関連して

• バイブコーディングでは、1回のプロンプトで成果物が完成するわけではありません。
  1回の構造修正によって、n回のプロンプトにおけるトークン消費率を下げる効果が生じる場合、トークン削減量は同様に行われるn回全体にわたって反映されます。
  nはプロジェクトの目的と機能数、そしてそのためのコード量と複雑さによって決まる数値であり、
  また最近の Cursor / Claude Code agent では、無限反復実行やAIの無分別なトークン使用の問題を解決するため、実行単位を小さくするアップデートが行われていることから、

プロジェクトの複雑度に関するnの値の研究は、別途行うのが適切だと考えます。

• できるだけ理解しやすくするため、別途指示がない場合にAIが作成しがちな、構造上の問題を持つコードからコード改善の例を挙げました。
  ここで見落としてはならないのは、構造の改善は決してコード開発と独立して起こる行為ではないという点です。
  最初のプロンプト、あるいはAI ruleset（.cursorrules）のような制約を通じて、base context として影響を与えられる部分であり、
  プロジェクト開発サイクルの途中で1回の構造改善だけですべてがうまくいくわけではありません。
  つまり、一定周期でコード改善を計画するよりも、base context として正しい構造へ導くほうがより良い方向です。

また、base context として構造誘導の指示ルールがある場合とない場合に関する研究は、別途行うのが適切に思われます。

1番の項目について整理すると、

• base context として構造誘導の指示ルールがある場合、全体のトークン使用量が減少する可能性もあり、
• n回のプロンプト命令を通じて最終成果物を得るという変数があるため、
  1回の構造改善プロンプト命令のトークン使用量を加算して計算すべきだという主張には語弊があります。

私も似たように感じました。
書かれた方の意図はわかるのですが、されていることに比べて文章がやや複雑すぎる気がします。
できるだけ実験に使われたディテールを文章に溶け込ませたくてこのように書かれたのだと思いますが、
核心だけを簡潔に抜き出しても、このテーマに関心のある方ならおそらく理解できると思います。
思い切ってディテールを削り、要点だけに絞ればもっと良くなるのではないかと思います。

私は、書き手の意図や結果自体は面白いと感じました。
より良いソースコードがより少ないトークン消費につながる、というのが主な論旨であり、
それに関連した実験設計をして実施されたように見えます。

実験について私が理解した部分だけを並べると、

1. AIに問い合わせるソースコードと、そのソースコードをプロンプトで前処理（？）したソースコードの2種類を準備
2. GPT5、Sonnetでそれぞれ5回ずつ2つのソースコードを実行させ、トークン消費量を比較
   ということのようです。
   そして私の理解が正しければ、プロンプトで前処理したソースコードのほうが全体的にトークン消費量が少ない、という結論のようです。

面白い結論ではありますが、実験に対する私の意見は次の通りです。

1. 公平な比較ではない
   数値上は下がっているように見えますが、ソースコードを処理するための総トークン数で比較するのが正しいと思います。
   言い換えると、前処理のために使われたトークン数も考慮されるべきだと思います。
   前処理に使われたトークン数が過度に大きければ、実質的にはトークンをより多く消費していて無意味になりますし、少なかったとしても、実際のトークン消費量の差は文章で示されたものよりかなり小さいのではないかと思います。

2. 前処理前後のソースコードを比較する必要がある
   前処理に使われたトークンを除外するなら、問い合わせ時のトークン消費量は有意に減少しているように見えます。
   ただし、ソースコードのどのような違いによってこうした差が出るのかを分析すれば、文章の意味はより大きくなると思います。
   そうした差を最大化するための前処理プロンプトの最適化が可能だという話になりますから。
   書き手の方はコード構造のリファクタリングがこの結果をもたらしたとおっしゃっていますが、私は同意しておらず、まだわからないと考えています。
   AIに対して、リファクタリング以外の部分を改善した場合でもトークン消費量の減少が起こりうるかもしれないからです。

3. もう少し多様な実験が必要
   現在のコードだけでなく、別のコードベースでも同じ実験を回してみるべきだと思います。
   これが一貫して良い結果になるのかどうかを判断する必要があるからです。
   ただ、現実的にはこれはテストが難しいかもしれないという点は理解できるので、参考程度に受け取るのがよいと思います。

役に立たないプレゼントを贈るのが人気みたいですし……新しい役に立たないプレゼントを発掘するには良さそうですね

追加で使用したプロンプトに関連する内容を整理してお伝えします。

どちらかといえば、開発者の方が構造改善用のプロンプト作成に向いています。プログラムごとに性質が異なるため、効率の高い改善を行うには、ある程度の開発知識が必要です。

とはいえ、非開発者のバイブコーダーの方々がこの方法を使えないという意味ではありません。効率には差が出るかもしれませんが、"プロジェクトのコードを整理して。使っていないコードは削除して。" のようなシンプルな命令だけでも、AIはファイルやクラスを分離・整理する動きをします。

ただし、構造改善の細部の違いが効率の差を生みうる点については、参考資料の扱いに注意が必要です.

空間情報を活用する機会があるなら、良い選択肢です。

この記事に多くの関心をお寄せいただき、ありがとうございます。海外向けの配布を主な目的としていたため英語で記事を作成しましたが、そのためにいろいろな問題が発生しているようです。

そこで、韓国語で整理したポストを共有します。

https://modgo.org/tokeun-sayongryang-37-91-reul-gamsosikin-dan-hanjuly…

AIにコード構造のリファクタリングを指示した後、消費されるトークン量が減ったというのが核心です。
逆に言えば、コードに構造的な欠陥がある状態で指示を続けると、トークン使用量が増えるとも説明できそうです。

要するに、ソースコードの構造改善が必要だという内容であり、プロンプトを要点だけに絞って論理的に書くべきだという意味ではありません。

プロンプトには要点だけを論理的に盛り込むべきだ。つまり、プロンプトにあれこれ多く付け加えるほどノイズが増え、結果として出てくるコードも複雑になり、ノイズも多くなる、ということですか？

さらに屋上屋を架す

著者です。フィードバックありがとうございます。次回の記事作成時の参考にさせていただきます。

私もこの紹介文と原文があまりにも冗長で、文章を書くのがあまり得意でない人が書いたように感じられて、読む過程が大変だったのですが、
要するに
「トークンを減らす構造的制約を盛り込んだ一行の指示を追加せよ」
くらいにまとめられますね

突然、すべての句点が消えました

結論
AI を使うことで生産性の向上により
コスト削減には役立つが
それ自体が収益になるわけではない。

Node.jsのようなものは、ほかのアプリケーションにバインドしようとするとかなり面倒になるので、もう少し簡単になってほしいですね。

Web Codecs API自体の性能が高いため、Web向けメディアライブラリはどれもパフォーマンスに優れています。純粋なTSと言うには少し微妙な感じもありますね。

ベンチマークを見ると、不思議なことに性能はそれほど悪くないですね

おお、ついにDelphiとC++BuilderにもAI開発コンポーネントが入るんですね。
Delphiはなんだか心のふるさとのようで、新しいニュースが出るたびについ見てしまいます。