計算力から生産性へ
AI の生産性は、人間の判断・計算力・コンテキスト・コントロールループが解決済みのエンジニアリング作業にどうなるかで測る。
Jensen Huang のトークンバジェットのフレーミングが有用なのは、AI を小さなソフトウェアサブスクリプションとして見る会話から外してくれるからだ。
注目すべき数字は、高給エンジニアが給与の大部分に相当するトークンバジェットを消費するかもしれないということだけではない。より深いポイントは、計算力がエンジニアリングの生産関数の一部になりつつあるということだ。
それが事実なら、有用な問いは「エンジニアは何トークン使ったか？」ではない。それは：
どれだけの計算力が解決済みの仕事になったか？
梃子としての計算力
旧来の管理モデルはほとんどが人数中心だった：
生産性 = エンジニアあたりの成果
このモデルはツールのコストを二次的な費用として扱った。AI は分母を変える。新しいモデルはより近い：
生産性 = エンジニア × 計算ループが生み出す成果
重要な単位はもはやエンジニア単体ではない。それは人間の判断・利用可能な計算力・モデルの能力・コンテキストの質、そして中間出力を完成した仕事に変えるコントロールループのバンドルだ。
これが「給与の半分をトークンに」というアイデアが正確な比率がすべてのチームに一般化しないとしても議論に値する理由だ。計算力をオプションのエディタープラグインよりも、コンパイラ・クラウドインフラ・CI・オブザーバビリティに近い必須の生産能力として位置づける。
反転
長い間、デフォルトの仮定は：
エンジニアのコスト >> ツールのコスト
だった。
この仮定は弱まっている。一部のチームでは、AI の計算費用がすでに人件費と競合または超過している。採用の会話では、トークンアクセスも報酬サーフェスの一部のように見え始めている：給与・株式・ボーナス、そして計算力。
それはすべてのチームが積極的に使うべきということではない。エンジニアリングリーダーが「AI は高すぎるか？」よりも鋭い問いを持つ必要があることを意味する。
より良い問いは、その費用が複利効果を持つかどうかだ。
曖昧さをレビュー可能な設計に変え、欠陥の検索時間を減らし、退屈なグルーコードを書き、複数の検証パスを並行して実行できる計算力は梃子になれる。リトライ・不明確なプロンプト・大きすぎるコンテキスト・境界のないエージェントループに消える計算力は単なる消費だ。
スレッド・ターン・トークン・クレジット
Codex と LLM ツールの日常的な利用は、チャットよりもリソースシステムのように見え始める。
| プリミティブ | 意味 |
|---|---|
| Thread | 問題空間のコンテキストコンテナ |
| Turn | コントロールループの一回の反復 |
| Token | 読み取り・推論・書き込みに費やされる計算単位 |
| Credit | その計算の周りのバジェットまたは制約 |
これらのプリミティブは関連しているが、線形ではない。
広いスレッドは問題が曖昧なときに有用だ。モデルがコンテキストを検査し、方向を比較し、欠けている制約を表面化できる。狭いスレッドは仕事が収束して目標が実行になったときに良い。
ターンは反復の深さを測る。より多くのターンが自動的により多くの進展を意味するわけではない。一定の点を超えると、追加のターンは通常、仕様が不明確・バリデーションループが弱い・またはモデルが既に持っているべきコンテキストを再発見するよう求められていることを意味する。
トークンは計算の強度を測るが、トークンのコスト自体にも構造がある。プロンプトトークンはロードされたコンテキストのコストを払う。推論トークンは検索と統合のコストを払う。出力トークンは可視のアーティファクトのコストを払う。それらを一つのフラットな数字として扱うと、仕事が実際に起きている場所が隠れる。
より良いメトリクス
トークンの総使用量は生産性ではない。高消費は梃子を意味するかもしれないが、無駄を意味することもある。
より良い測定システムは解決済みの仕事から始まる。
token efficiency = useful output / tokens used
これはトークンの使用がシグナルになっているかどうかを問う。高いトークン効率は通常、正確なタスク境界・良いコンテキスト選択・素早く閉じるバリデーションループから来る。
turn efficiency = problem resolved / turns
これはチャットスラッシングを捕まえる。小さな問題に多くのターンがかかるなら、ボトルネックは通常モデルの知性ではない。欠けている仕様・間違ったコンテキスト・または明確な受け入れチェックの不在だ。
thread compression ratio = final solution complexity / initial problem entropy
これは設計とアーキテクチャの仕事に有用だ。良いスレッドは曖昧さを減らすべきだ。始めたときよりも小さく鋭い問題を残すべきだ。
compute leverage ratio = output value / (human time + compute cost)
これが最も重要なメトリクスだ。システムの両側を含む：仕事を誘導するのに費やした人間の時間と、生産・チェック・修正するのに費やした計算力。
オーケストレーターとしてのエンジニア
エンジニアが多くのエージェントを調整できるなら、仕事は受動的にならない。より明示的になる。
エンジニアは問題の境界を定義し、どのコンテキストをロードする価値があるかを決め、探索と実行を分離し、ループを監視し、どの出力が信頼に値するかを判断しなければならない。プロンプトはモデルにコードを求めることだけではない。計算力で支えられた実行システムへの仕様インターフェースだ。
これはエンジニアリングの品質がどう見えるかを変える。強いエンジニアはまだセンス・デバッグ能力・アーキテクチャ判断・プロダクションの規律を必要とする。しかし計算力をいつ使うか、コンテキストをいつ圧縮するか、仕事をいつ別々のスレッドに分けるか、そしてエージェントが不確実性を減らさずにバジェットを燃やし続ける前にいつ止めるかも知る必要がある。
実践的な問い
チームは今や異なる問いをすべきだ。
何人のエンジニアが必要かだけを問うのではなく、各エンジニアが責任を持って有用な計算力をどれだけ駆動できるかを問う。
コードがどれだけ早く書けるかだけを問うのではなく、仕事が仕様化・実装・テスト・レビュー可能になる前に何ループ必要かを問う。
生のトークン使用量を祝うのではなく、トークンがどこで成果になり、どこでリトライ・曖昧さ・繰り返しのコンテキストロードに消えるかを問う。
目的はより多くのトークンを使うことではない。計算力を生産性に変換し無駄を減らすエンジニアリングシステムを構築することだ。
AI の時代、生産性はコードの行数やトークン量では測られない。チームが計算力を解決済みの仕事にどれだけ効果的に変換できるかで測られる。