AIエージェントのコスト最適化というと、どのモデルを使うか、プロンプトキャッシュをどう設定するかが語られます。しかし、「何語で書かせるか」というタスク設計段階の選択肢は、ほとんど検討されていません。

本記事は先行研究の紹介だけで終わらせず、実際にAIエージェントへ同一タスクを複数言語で書かせてトークン消費量を実測します。具体的には、本リポジトリのClaude Codeセッション上で general-purpose サブエージェントを3体（TypeScript担当・Python担当・Bash担当）並列起動し、同一仕様のCLIツールを実装させました。その結果、数字だけでなく、数字の裏にある運用上の落とし穴も見えてきました。

先行研究が測ってきたもの、測ってこなかったもの

言語選択とトークン効率の関係を調べたとき、まず見つかるのはMartin Aldersonによる2本の記事です。

1本目は、19言語のトークン効率を比較したベンチマークです。RosettaCodeから取得した静的なコードサンプルをGPT-4トークナイザで比較し、最も効率の悪いC言語と最も効率の良いClojureの間に 2.6倍の差 があったと報告しています1。ただしこれは「AIエージェントに実際に書かせた」比較ではなく、既存の解答例同士の逐語比較です。TypeScriptはこのデータセットに含まれていません。理由は意図的な除外ではなく、RosettaCodeにおけるTypeScriptの解答数が少なかったという技術的な制約です1。Bash/Shellも比較対象に入っていません。

2本目は、同じ著者によるWebフレームワーク比較です。こちらはClaude Code + Opus 4.6を使い、19フレームワークで同一のブログアプリケーションを実装させるという、AIエージェントによる実測です。結果は最も安いASP.NET Minimal APIが26,000トークン、最も高いPhoenixが74,000トークンで、2.9倍の差 が出ています2。著者はこの差について「1回のタスクでは大きな差に見えないが、エージェントが1日に何百回もコードを書いたり直したりする運用では大きく効いてくる」と述べています2。ただし比較対象は「フレームワーク」であり「言語」ではありません。

もう一つ参照すべきなのが、Dan Luuによる記事です。「動的型付け言語の方がLLMのトークンコストが低い」という広く引用される主張に対し、簡単なタスクで成立していた強い相関が、より難易度の高いタスクでは成立しないと報告しています3。難易度の高いタスクでは静的型付け言語が最良の結果を示すこともあり、著者は「エキセントリックで簡潔な言語を選ぶより、メジャーな言語を選ぶ方が無難だ」と結論づけています3。

この3本を並べると、ある空白が見えてきます。「言語選択」を「AIエージェントに実際に書かせて」測った研究は見当たりません。Aldersonの言語比較は静的なコードサンプルの比較、フレームワーク比較はエージェント実測ですが対象が言語ではない、Dan Luuの記事は言語間の相関を扱うものの「タスクを書かせた」実測ではありません。ここに、自社実測を接続します。

自社実測 — 同一タスクをTypeScript/Python/Bashに書かせてみる

タスクの仕様は、RFC4180準拠の最小限のCSVパーサ（外部ライブラリ禁止）を自作し、age>=30 でフィルタしてJSON出力するというものです。この同一仕様を、TypeScript・Python・Bashそれぞれの担当エージェントに独立して実装させました。

実測結果は次のとおりです（scripts/token-usage.mjs による集計）。

言語総トークンリクエスト数実装行数
Python191,556576行
TypeScript316,093866行
Bash403,37010111行

この表の値は、各言語の担当エージェント自身のセッション全体（試行錯誤も含む）をそのまま集計したものです。最も消費が少なかったPythonに対し、最も多かったBashは 約2.1倍（403,370 ÷ 191,556 ≈ 2.11）でした。3実装とも、メインセッションが正本の入力ファイルに対して独立に動作検証を行い、一発で正しい出力（3件抽出・不正行のスキップ）を得ています。

差の内訳を見ると、総トークンの9割前後がキャッシュ読出しで占められています。たとえばBashは403,370トークンのうち375,462トークンがキャッシュ読出しでした（約93%）。Anthropicの公式ドキュメントによれば、total_input_tokens は cache_read_input_tokens（キャッシュ読出し）・cache_creation_input_tokens（キャッシュ書込み）・input_tokens（未キャッシュ分）の合計として計算され、マルチターンの会話ではリクエストが進むごとに「これまでの会話全体」がキャッシュ読出しとして毎回計上される仕組みになっています4。つまり往復（リクエスト数）が増えるたびに、それまでの会話全体が再計上され、総トークンが積み上がっていきます。

Bashの実装行数（111行）が3言語中最多だった理由もここに関係しています。BashにはJSON文字列のエスケープやCSVのフィールド分割を言語機能で吸収する手段がなく、手作業で書く必要がありました。この分がコード量と往復回数の両方に跳ね返っています。

ここで実験の限界を明記しておきます。この実験だけでは、「コード自体の言語間トークン効率」（Aldersonの静的比較が扱う領域）と「AIエージェントの探索・自己検証にかかる往復コスト」を分離できません。今回の差の大半は、往復に比例して積み上がる後者由来である可能性が高く、「Bashは常に非効率」という一般化はしません。また、各言語1回ずつの実装試行（n=1）であり、統計的な有意差を主張できる規模でもありません。

実測が明かした、数字より重要な落とし穴

トークン数の比較に気を取られていると見落としそうになりますが、今回の実測ではもう一つ重要な事実が見つかりました。

TypeScript担当エージェントは「一発で成功」と申告しました。しかし実際には、3エージェントが共有していた入力ファイルを無断で書き換えていました。この書き換え後の内容を前提に、後から完了したPython担当エージェントは「仕様の期待値が誤っている」と、存在しない仕様の齟齬を自己申告しました（本来 skip: 5 であるべき値について skip: 6 が正しいと誤認したものです）。

メインセッションはこの矛盾に気づき、正本を復元したうえで3実装すべてを独立に再実行して検証しました。復元後は3実装とも矛盾なく同じ結果を出力し、実装ロジック自体にバグはありませんでした。

この一件は特定言語の欠陥ではありません。並列サブエージェントに共有の入力ファイルを渡すという運用設計上の落とし穴です。エージェントの「成功しました」という自己申告は、独立した再実行で確かめるまで検証済みとは言えないという実例でもあります。

考察 — 言語選択は「トークン単価」ではなく「タスク単価」で見る

Aldersonのフレームワーク比較が指摘するとおり、1回のタスクでのトークン差は小さく見えても、エージェントが1日に何百回もコードを書いたり直したりする運用では効いてきます2。

自社実測が示したのは、その差の少なくとも一部が「言語そのものの表現力」ではなく「往復回数（＝キャッシュ読出しの累積）」に由来するという点です4。往復が増える言語ほど、キャッシュ機構の恩恵を受けつつも総量は膨らみます。

Dan Luuの指摘（難易度の高いタスクでは静的言語が優位になることもある）を踏まえると3、「動的言語だから安い」という単純な図式では語れません。タスクの性質――ボイラープレート量、型の要否、エージェントが自己検証にかかる往復の多さ――を含めた「タスク単価」で評価する視点が必要です。

前セクションで見た落とし穴も踏まえると、コスト評価は数値だけでなく運用設計――共有リソースの扱い、自己申告の検証――を含めて行うべきだと言えます。

結論 — タスクの性質に応じた言語選択の実践的な指針

今回の実測を振り返ると、トークン消費の総量を決めていたのは行数（ボイラープレート量）ではなく往復回数（リクエスト数）でした。リクエストあたりの平均トークンは、Python 約38,311、TypeScript 約39,512、Bash 約40,337とほぼ同水準です。総トークンの差は、リクエスト数の差（5→8→10）でほぼ説明できます。

行数の少なさが必ずしもトークン効率の良さに直結しない実例もあります。TypeScript（66行）はPython（76行）より行数が少ないにもかかわらず、総トークンは約1.65倍多くなりました（316,093 対 191,556）。

ここから言えるのは、「言語選択でコストが変わる」という事実だけでなく、「往復回数を減らす設計」――一発で正しく動くタスク粒度に切り分ける、共有リソースを介さないエージェント設計にする――の方が効果が大きい可能性があるということです。

まずは自分たちの実タスクで、token-usage.mjs のような手段を使って計測してみることをお勧めします。「言語Aは安いはず」といった思い込みのコスト構造を、実測で検算する価値は十分にあります。

おわりに

AIエージェントのコスト最適化やタスク設計に関するご相談・お問い合わせは コンタクトフォーム までお気軽にどうぞ。

Footnotes

  1. Martin Alderson - Which programming languages are most token-efficient? ↩ ↩2

  2. Martin Alderson - Which web frameworks are most token-efficient for AI agents? ↩ ↩2 ↩3

  3. Dan Luu - What’s the best programming language for coding agents? ↩ ↩2 ↩3

  4. Anthropic - Prompt caching ↩ ↩2