Frugal Computing → Token Design
メモリは安くなり、贅沢に使えるようになった。
では、AIが使う“トークン”も、同じ道を辿るのか。
——半分はイエス。半分は、決定的にノーだ。
メモリは、
量の問題だった。
トークンは、純度の問題だ。
だから借りるべき比喩は、メモリ管理ではない——という話を、コンピュータが1バイトを削っていた時代から、いまのAIエージェントまでを一本の線にして書いていく。狙いは、「削る技術」ではなく「配る技術」のほうを取り出すことにある。
この記事が答える問い
トークンは増え、単価は下がり続ける。
ならばいずれ、“富豪的エージェント”の
時代が来るのか？
先に結論を置く。素朴に 「省メモリ ＝ 省トークン」 と重ねた瞬間、この類推は二重に間違う。メモリは削っても中身（＝出力）が変わらなかったが、トークンは削り方で中身が変わる。しかも増やせば良いわけでもない——ある点を超えると、むしろ賢さが落ちる。だから正しい目標は「削る」ことでも「たっぷり使う」ことでもなく、配分すること。省スペースの工学ではなく、信号純度（SNR）の工学だ。
ざっくり言うと
料理の塩加減に近い。少なすぎると味がぼやけて決まらない。多すぎると塩辛くて食べられない。一番おいしい量は、必ず“途中”にある。メモリは冷蔵庫の大きさで、大きいほど困らない。でもトークン（＝AIに渡す文脈）は、塩のほうだ。たっぷり入れれば良い、という代物ではない。この違いを取り違えると、最適化がまるごと裏目に出る。
Chapter 01
ざっくり言うと——“富豪的プログラミング”とは、資源をケチらず「人間にとっての分かりやすさ」を優先して書くスタイル。メモリが安くなったから成立した。同じことがトークンでも起きるのでは、という誘惑から話は始まる。
コンピュータの黎明期は、1バイトを削る戦いだった。メモリは高価で、プログラマは限られた領域に処理を押し込むために、可読性を犠牲にしてでも切り詰めた。ところがメモリは年々安くなり、やがて潤沢になる。すると発想が反転した——節約に頭を使うより、人間が読みやすいコードを書くほうが割に合う。
この転換を一言で捉えた言葉が 富豪的プログラミング だ。日本では増井俊之さんが1990年代後半に広めた言い方で、要は 「安くなった資源は、ケチらず贅沢に使え」。メモリや計算力を惜しまず、その代わり人間の手間と分かりやすさを買う。いまでは当たり前の感覚だが、これは「資源が安くなった」という前提の上に立った、れっきとした設計判断だった。
さて、いまLLMエージェントを触っていると、同じ坂道を逆から登っている感覚がある。扱えるトークン——AIが文章を読み書きするときの最小単位、単語のかけらのようなもの——は年々増え、単価は下がり続けている。数年前なら数千語で音を上げていたモデルが、いまは本一冊ぶんの文脈を平気で飲み込む。ならば当然、こう考えたくなる。メモリがそうだったように、いずれ「富豪的エージェント」の時代——文脈をケチらず、たっぷり渡すのが正解になる時代——が来るのではないか。
歴史に学ぶのは、正しい姿勢だ。実際このサイトでも アーキテクチャは「希少資源の化石」 で、システム設計の50年を「その時代に最も希少だった資源」の移動史として読み直したことがある。その視点で言えば、トークンは いま新しく希少になった資源 だ。だから省メモリの歴史を参照するのは、筋がいい。
——ただし、素朴に重ねた瞬間に、この類推は転ぶ。どこが同じで、どこが決定的に違うのか。そこを分けないと、メモリの直感がそのまま罠になる。次の章で、その差が一番はっきり出るところから開けていく。
Chapter 02
ざっくり言うと——メモリ節約は「中身に影響しない」のが強みだった。トークンは逆で、量を変えると答えの中身が変わる。しかも多いほど良いわけでもない。ここを見落とすと、類推が丸ごと壊れる。
メモリ効率には、見過ごされがちな性質があった。品質に中立だったことだ。手で切り詰めたコードも、富豪的にゆったり書いたコードも、走らせれば出力は同じになる。効率化で買えるのは コストと速度 だけで、答えの正しさは1ミリも動かない。だから「最適化 ＝ ひたすら小さく」で、ずっと正しかった。削っても損はしなかったのだ。
トークンは、ここが違う。渡す文脈を変えると、返ってくる答えの中身そのものが変わる。しかも、多く渡せば良いというものでもない。ある点を超えると、文脈が増えるほど推論がむしろ劣化していく。
長すぎる文脈で起きること
真ん中が読み飛ばされる（通称 lost in the middle）。必要な事実が長い文脈の“中ほど”に埋もれると、モデルの注意がそこまで届かず、冒頭と末尾ばかり見てしまう。分厚い資料の真ん中のページが読み飛ばされるのと同じだ。
文脈が“腐る”（通称 context rot）。入力が長くなるほど、無関係な情報がノイズとして効いてきて、全体の精度がじわじわ落ちる。机に資料を積み上げすぎて、肝心の一枚が探せなくなる状態だ。
ところが、逆向きの力もある。いまの 推論モデル（答える前に、頭の中で手順を踏んで“考える”タイプのAI）は、意図的にトークンを多く使って考えることで、精度を上げる。じっくり考えたぶんだけ賢くなる領域が、確かに存在する。少なすぎると、今度は考える余地がなくて間違える。
つまりトークンは、品質と 非単調な関係 にある。むずかしい言葉だが、意味はシンプルだ——増やすほど良くなる、の一本調子ではない。少なすぎれば情報不足、多すぎればノイズに埋没し、一番いい点は途中のどこかにある。塩加減とまったく同じ形だ。メモリには、この“山”が無かった。
だから、正しい目標は「省トークン（とにかく小さく）」ではない。トークン配分の最適化——限られた注意を、どこに厚く、どこに薄く割り振るか——のほうだ。ここが、省メモリの直感と決定的に分かれる分岐点になる。
検証になる問いを一つ置いておく。「仮に明日、トークンが無料になったら、この工夫は無駄になるか？」。メモリ最適化なら、無駄になった。安くなれば削る意味は消える。だが「何を渡し、何を渡さないか」という目利きの価値は、無料になっても消えない。エージェントに“富豪的”の終着点が完全には来ないかもしれない理由が、ここにある。
言葉だけだと掴みにくい“山”を、次は一枚の図で見ておきたい。
Chapter 03 — Figure
ざっくり言うと——下の図は、トークン量と出力品質の関係。右肩上がりではなく“山型”だ。少なすぎれば情報不足、多すぎればノイズに埋もれ、最適点は途中にある。世代が上がると山は右へ動くが、消えはしない。
横軸に 渡すトークンの量（文脈の大きさ）、縦軸に 出力の品質 を取る。メモリの直感なら、この線は右上へまっすぐ伸びるはずだ。だが実際は、こうなる——立ち上がって、頂点をつくり、そこから下る。暖色の斜面は「情報を足すほど良くなる」領域、寒色の斜面は「足すほどノイズに埋もれる」領域。境目の 最適点 が、狙うべき配分だ。
白い太線が現行世代。暖色の斜面では、文脈を足すほど品質が上がる（＝渡す価値がある情報）。寒色の斜面では、足すほど品質が下がる（＝注意を薄めるノイズ）。世代が上がると 最適点は右へ動き、右側の下降もゆるくなる——長い文脈に強くなる。だが、山そのものは消えない。これが「富豪的エージェント」が完全には来ない、という主張の核だ。
この図が示すのは、トークン設計が 「固定の的（メモリ）を撃つ空間最適化」ではなく、「動く的（最適点）を追うチューニング」 だということ。的はタスクごとに動くし、モデルの世代でも動く。次の章から、この山を前提に——それでも歴史から持ち込めるもの、持ち込むと事故るものを、順に仕分けていく。
Chapter 04
ざっくり言うと——非単調だからといって、歴史が全部無効になるわけじゃない。省メモリ時代の知恵のうち、「計測してから」「近くに安く置く」「必要時に取りに行く」は、そのままトークンにも効く。ここは深く張ってよい場所だ。
仕分けの前提を一つ。ここで挙げる原則は、トークンが安くなっても消えないものだけを選んでいる。逆に「安くなったら不要になる工夫」は、次章より後で外していく。まずは、生き残る5つ。
「早すぎる最適化は諸悪の根源」——Knuth のこの警句は、トークンでもそのまま効く。どこでトークンが消え、どの経路が「量 × 頻度」で効いているかを測る前に、最適化しない。一回きりのタスクに刈り込みは要らない。だが1日に1万回叩くプロンプトなら、削った1トークンが1万倍で効く。CPUの内側ループだけ手で最適化したのと、同じ発想だ。
これは自分でも実測した領域で、1回$0.20の朝刊が、$0.02になるまで に書いたとおり、コストの大半は「どこで無駄にトークンを往復しているか」を測って初めて見えた。勘で削る前に、まず計器を付ける。
CPUには、速いが小さいキャッシュから、遅いが大きいディスクまでの階層があった。文脈も同じ形で組める。何度も再利用する“熱い”文脈（システムプロンプト、ツールの定義、お手本）は キャッシュで安く近くに置き、いま能動的に使っている作業セットは小さく保ち、参照材料は必要になってから読み込む。「作業セットは小さく、よく通る道は安く」が、そのまま効く。
この“熱い文脈をキャッシュする”仕組みが prompt caching（直前に計算した内部状態を覚えておいて使い回す）で、エージェントハーネスの内部 でも触れた。語彙こそ新しいが、やっていることはメモリ階層と変わらない。
全部を前もって積むのではなく、必要になったらエージェント自身に取りに行かせる。tool use（AIが道具を呼ぶ）や RAG（必要なときに外部資料を検索して差し込む仕組み）が、これにあたる。前もって全部積む（往復は減るが、使わない文脈が無駄になる）か、必要時に取りに行く（無駄はないが、その都度ひと呼吸遅れる）か——OSがデマンドページング（必要なページだけメモリに載せる方式）で下したのと、同じトレードオフだ。
適切なデータ構造が、いつもビット単位の小細工に勝ったように——問題をどう構造化してモデルに渡すか（整った型で渡す、大きなタスクを分解する、実体そのものではなく ID・参照だけを渡す）のほうが、単語を1つ2つ削る作業よりはるかに効く。「この巨大なJSONを全部貼る」のではなく「IDを渡して、必要なら取りに行かせる」。構造の決定が、語レベルの刈り込みを支配する。
限られた容量に映像や音楽を詰め込む「デモ」文化が、極限まで切り詰める工夫を生んだように——厳しいトークン予算は「本当に効くものは何か」の特定を強制する。そして、ここだけはメモリと決定的に違う。その規律が、コストだけでなく品質そのものを上げる。ノイズを削ぎ落とすと、信号の純度が上がるからだ。第2章で見た“山”の性質が、ここでは味方に回る。無駄を削ることが、そのまま賢さになる唯一の場所だ。
Chapter 05
ざっくり言うと——逆に、そのまま持ち込むと事故る差分が三つ。決定性・速さ・「多いほど賢い」。メモリの直感で最適化すると、この三つで足をすくわれる。
メモリは、最適化しても出力が同じだった。的は動かなかった。トークンは 文脈依存かつ確率的 で、最適化すると出力そのものが変わる。「削ったら速くなった、答えは同じ」ではなく「削ったら、答えが別物になった」が起きる。固定した的を撃つのではなく、撃つたびに的が動く。だから“正しさ”を測る仕組み（評価）を、最適化とセットで回さないと、静かに品質を落とす。
メモリの世界では、安さと速さが手をつないでいた。効率化すればコストも時間も下がる。トークンは違う。単価が安くなっても、生成は速くならない。AIは 一語ずつ、前の語を見て次の語を決める（自己回帰生成）ので、出力の長さはほぼそのまま実時間にのしかかる。かかる時間は、値段とは独立している。「安くなったから、たっぷり喋らせよう」とすると、財布は痛まないのに、待ち時間だけが伸びる。
RAMをいくら増やしても、コンピュータは賢くはならなかった。ところが 考えるためのトークン は、ある点までは 本当に賢くする。これはメモリ時代に対応物のない力学だ。だから、コスト削減だけを目的に「考える時間」まで一律に削ると、自分の推論の足を、自分で引っ張ることになる。削っていいノイズと、削ってはいけない思考を、同じ「トークン」という物差しで一緒くたにしてはいけない。
三つを一行で
メモリ：削れば、安く・速く・中身そのまま。
トークン：削れば、中身が変わり／速さは別問題／思考まで削ると逆効果。
この三点を混同したまま「とにかく小さく」を目指すと、メモリの成功体験が、そのままトークンの失敗になる。
Chapter 06
ざっくり言うと——単価が下がれば総支出も下がる、とは限らない。石炭の歴史がそれを反証している。効率化は、消費をむしろ増やす。だから省トークンの目的を「節約」に置くと、歴史に負ける。
ここで、動機そのものを歴史が裏返す。1865年、経済学者ジェヴォンズは、蒸気機関が効率化したのに石炭の消費が減らず、むしろ 増えた ことを指摘した。効率が上がったせいで、蒸気が新しい用途でも採算に乗り、使い道そのものが増えたからだ。1台あたりは減っても、台数が跳ねる。メモリも計算も、そっくり同じ道を辿ってきた。
トークンにも、同じ予測が立つ。単価が下がり、文脈効率が上がるほど、総トークン消費は減らずに増えていく。安くなれば、これまで採算に合わなかったタスク——長い調査、何時間もの自律作業、大量の並列試行——が次々に現実的になり、使う総量を押し上げる。1タスクの単価は確かに下がる。だが、できることが増えて、総支出はむしろ上がる。
1タスクの単価 ↓ 下がる ／ 総トークン消費 ↑ 増える
二本の線は、逆向きに伸びる。これがジェヴォンズの逆説だ。
だから「API料金を浮かせるために省トークン」という動機は、ミクロでは正しいが、マクロでは潮に逆らっている。節約したぶんは、より多くのタスクに吸い込まれて消える。転換点はここだ——省トークンの目的を 「支出削減」 に置くと、歴史に負ける。「同じ予算で、より難しいことをやる」 に置くと、歴史に乗る。
言い換えれば、目指すべきは フットプリント最小化 ではなく レバレッジ最大化 だ。同じトークンで、どれだけ大きな仕事に手を伸ばせるか。削って浮かせるのではなく、効かせて伸ばす。省メモリの倹約家の顔をしたまま、この分岐を見落とすと、せっかくの効率化が「使わない理由」に化けてしまう。
Chapter 07
ざっくり言うと——完璧なトークン効率を設計し続けて出さない人より、無駄を承知で出した人が勝つ。そのうえで「モデルが自前でやったら消える工夫」には浅く、消えない目利きには深く投資する。
最後に、古い教訓を二つ重ねて着地させたい。一つ目は Worse-is-Better。単純で出荷できるものが、正しく完全だが未出荷のものに勝つ、という有名な観察だ。理由はシンプルで、出荷したものだけが、現実からのフィードバックを受けて進化するから。トークンを多少浪費してでも「動くエージェント」を出した人が、完璧なトークン効率を設計し続けて出さない人に勝つ。最適化は、出荷の後にしか意味を持たない。まず動かす。話はそれからだ。
二つ目は 手最適化の陳腐化。かつて人が手で書いたアセンブリは、大半の場面でコンパイラの自動最適化に追い越され、専門的なニッチへ退いた。同じことが起きつつある——モデルは、自分の文脈管理が年々うまくなっている。だから投資の基準は、たった一つに絞れる。
投資の一問
その技術は、モデルが自前でやるようになったら、消えるか？
消えるもの → 浅く
手作業のプロンプト圧縮、お手本の手選別。モデルが賢くなるほど、自前でやってしまう領域。ここに深く張ると、次の世代で丸ごと無駄になる。
消えないもの → 深く
何を渡し何を渡さないかの目利き（＝表現の選択）と、正しさを測る評価・計測の仕組み。プロファイラとデータ構造が陳腐化しなかったのと同じ理由で、これは残る。
この「自前でやるようになったら消えるか」という問いは、AIエージェントは「誰が」動かしているのか で書いた「自律はモデルの外側の足場（ハーネス）に宿る」という話と裏表になっている。いま外側の足場でやっている工夫のうち、モデルの内側へ吸い込まれていくものほど、投資として浅くしておいたほうがいい。逆に、内側に吸い込まれない「判断」と「計測」は、どれだけモデルが賢くなっても人間の側に残る。
Coda
メモリは、量の問題だった。
トークンは、純度の問題だ。
借りるべき比喩は、メモリ管理じゃない。
削る技術ではなく、“配る”技術。
フットプリント最小化ではなく、レバレッジ最大化。
最適点はゆるやかな山を描き、しかもタスクとモデルの世代で動く。だとすれば、参照すべき古い分野はメモリ管理よりも、むしろアナログの信号工学や制御工学に近い——動く最適点を、信号とノイズの比で追い続けるチューニングの世界だ。省メモリの倹約が消えるわけではない。ただ 専門化する：オンデバイス、高頻度・低レイテンシ、消費者スケール。そこでは組込みの倹約が永続し、それ以外では富豪的でいい。「分野による」という直感は、はじめから正しかった。
Fact-check
主要な用語・出典は一次／準一次情報にあたっている：富豪的プログラミングは増井俊之が1990年代後半に広めた用語。「早すぎる最適化は諸悪の根源」は Donald Knuth「Structured Programming with go to Statements」（1974）で広まった警句（原典では Hoare への言及あり）。ジェヴォンズの逆説は W. S. Jevons『The Coal Question』（1865）。Worse-is-Betterは Richard P. Gabriel（1989〜91頃）。lost in the middleは Liu ら「Lost in the Middle: How Language Models Use Long Contexts」（2023）で命名された、長文脈の中ほどが軽視される現象。context rotは入力が長くなるほど精度が落ちる現象を指す通称。few-shot（文脈内学習）は GPT-3（2020）で広く実証された。推論時に「考える時間」を増やすと精度が上がる性質は o1 系の推論モデルで知られる。デマンドページング・メモリ階層・prompt caching・RAG・自己回帰生成は、いずれも一般的な技術用語。一方で、「省メモリとトークンの同型／非同型を5＋3に仕分ける」「これはSNRの工学だ」という補助線の引き方は、外部調査ではなく 筆者の見立て だ。図中の3本の曲線は概念を示すための模式で、特定モデルの実測値ではない。別の切り口や、事実の誤りには、反論を歓迎する。