#トークン

この記事を読んでまず思ったのは、AIコーディングを“魔法”として持ち上げるのではなく、ちゃんと現場の道具として並べているのが好ましい、ということだった。Claude Code、VS Code、GitHub Copilot、Cursor。名前だけ並ぶと華やかだけれど、記事の温度はかなり実務寄りで、派手な成功談よりも「どう使い分けるのか」「どこに効くのか」に寄っている。その距離感が、むしろ信頼できる。 特に引っかかったのは、「トークン」という言葉を前提にしているところだ。AIの文脈では当たり前でも、普通の開発者にとってはまだ少し抽象的だと思う。要するに、AIが一度に扱える情報量の単位みたいなものだが、それが増えると会話やコード全体をまたいだ作業がしやすくなる。一方で、量が増えれば何でも解決するわけでもない。記事はそこを煽りすぎず、トークンの扱いが実用上の差になる、という線で止めている。その控えめさがよかった。 もう一つ、AIコーディングを「個人の生産性向上」だけで終わらせず、チームや開発プロセス全体の話に接続しているのも印象に残った。AIがコードを書く速さは目立つけれど、本当に面倒なのはそ

一番ひっかかったのは、「自分はまだ何も打っていないのに、もう減っている」という感覚です。AI系のツールって、どうしてもプロンプトの量や使い方だけが消費の原因だと思いがちですが、この記事はその前段にある設定そのものがコストを押し上げる、と言っていて、そこがかなり実感に近いなと思いました。 とくにCLAUDE.mdは便利な反面、便利さの代償がわりと素直に出るんだなと感じます。毎回読み込む以上、長くなればなるほど効く。しかも、今回の作業に関係ない指示まで抱え込むと、静かにムダが積み上がる。人間の感覚だと「念のため入れておく」が、そのままモデル側では固定費になってしまうわけで、ここは使い慣れるほど見落としやすそうです。 もうひとつ面白かったのは、MCPサーバーやスキルのような“拡張機能”が、単に機能を増やすだけではなく、常時読み込みのコストも増やすところです。便利な道具を足していくほど、起動時の重さも増える。これはソフトウェア全般にある話ですが、トークンという目に見えにくい単位で出てくると、急に現実味が増します。派手な使い方をしなくても減る、というのはかなり嫌なタイプの消費です。 逆に言うと、

読んでまず思ったのは、これはかなり“地味だけど効く”種類の道具だな、ということだった。AIツールの利用量って、体感と実際がずれやすい。ちょっと触っただけなのに急に制限に当たると、「自分が使いすぎた」のか「裏で何かが回っていた」のか、感覚では分からない。そこを、端末に残っている session log だけで追いかける発想はかなり筋がいいと思う。 面白いのは、単なる token カウンターではなく、「なぜ増えたか」に寄せているところだ。大きいファイルを早い段階で読んだせいで後から何度も context に載り直す、とか、短い session が大量に並んでいるのは人間の作業ではなく automation の気配だ、とか。こういう説明が返ってくるなら、ただ数字を見てため息をつくよりずっと使える。特に、limit に引っかかった理由が“自分の作業”ではなく“どこかの仕組み”だったと分かるのは、気持ちの整理にもなるはずだ。 もう一つ、README で強く押しているのが「何も外に出さない」という点だった。usage の監査系ツールは、便利そうでもログをどこかのサーバーに投げるのが気になって踏み切

この記事を読んでいちばん強く思ったのは、「同じモデルを使っているのに、こんなに差が出るのか」という驚きでした。LLM の話はつい「どのモデルが賢いか」に寄りがちですが、この記事はその手前にある harness、つまりエージェントを包む実行の仕組みが、実はかなり財布に効いてくると突きつけています。 面白いのは、差が単なる誤差ではなく、70倍という桁で出ていることです。ここまで来ると、モデル選びよりも「どう会話させるか」「どこまで確認させるか」「何を毎回与えるか」の方がコストを食っている可能性が高い。しかも coding agent では、その“余計なやり取り”がそのまま token に化ける。人間が見れば丁寧さに見えるものが、機械側では請求書になるわけです。 もうひとつ引っかかったのは、こういう話が思った以上に見えにくいことです。出力の品質だけ見ていると、ハーネスの違いは気づきにくい。でも実際には、同じモデルでも、包み方次第でまるで別物のサービスになる。これは開発者にとってかなり不公平にも見えるし、逆に言えば最適化の余地が大きいとも言えます。モデル性能の比較だけで満足していると、

読み終えてまず思ったのは、「やっぱりこういう話は、体験してみないと分からないな」ということだった。APIでファイルを渡せるようになると、つい“無駄が減りそう”と期待してしまう。でもこの記事では、その期待がかなりきれいに外れている。少なくとも、単に文書を貼り付けるのを Files API に置き換えたくらいでは、請求額はあまり下がらなかったどころか、少し増えたというのが面白い。 ここで引っかかったのは、便利さとコスト削減が同じ方向を向くとは限らない、という当たり前の事実が、LLM まわりだとつい見えなくなることだ。Files API はたしかに手間を減らす。毎回同じ文書を貼り付ける面倒は消えるし、アプリ側の実装もすっきりするはずだ。でも、モデルにとっては「ファイルとして渡された」こと自体が無料券ではない。結局のところ、その中身を読むならトークンは使う。むしろ、処理のしかたによっては貼り付けより少し高くつくこともある、というのはかなり現実的だと思う。 それでも最後に prompt caching を足したら節約できた、という流れには納得した。ここでようやく“同じものを何度も読ませる”という

最初に思ったのは、これはかなり気持ち悪いな、ということでした。質問に答える前から 200,000 tokens も食っていた、という話は、単なる「遅い」よりずっと嫌な種類の問題です。遅さなら体感できるけれど、見えないところでコストだけ先に積み上がっているのは、使う側としてかなり不信感が残ると思いました。 特に引っかかったのは、原因が「skill」だという点です。Claude Code のような開発支援ツールは、便利さの代わりに内部で色々な文書や設定を抱え込むわけですが、その読み込み方が雑だと、賢くなるどころか巨大な前置きで首を絞めることになる。AI の文脈では、モデルの性能ばかり語られがちですが、実際にはこういう「周辺の設計」の方が効くのだと改めて感じました。 25K tokens に減った、という改善は素直にいい話です。ただ、ここでも少し気になったのは、そもそも 200K まで膨らんだことが“静かに”起きていた点です。人間のソフトウェアなら、そんなに無駄な読み込みがあればメモリや起動時間で早めに気づけそうなのに、LLM 系だと請求やレイテンシに現れるまで見逃されやすい。便利な道具ほど