ソフトウェアエンジニアリングは、常に間違った生産性指標を追い求めてきた。マネージャーはコード行数を数え、アジャイルチームはストーリーポイントを追跡してきた。しかし、それらは開発者が明晰に思考しているのか、単にタイピングを多くしているだけなのかを確実に測定することはできなかった。NvidiaのCEO、ジェンセン・ファン（Jensen Huang）は、キーボードとは無関係な、より優れた指標を持っていると考えている。GTC 2026後のAll-In Podcastへの最近の出演において、ファンは、現代のエンジニアの価値を測る真の尺度は、給与に対してどれだけのAIトークンを消費しているかであると主張した。そのメッセージは明快だ。もし年収が50万ドルであっても、大規模言語モデル（LLM）サービスへの支出がその半分にも満たないなら、その給与に見合うツールを使いこなせていない可能性が高いということだ。
過酷な比率
ファンが述べた指標は、驚くほど単純だ。エンジニアの年間報酬を取り、それをLLM APIの呼び出し、ファインチューニングの実行、エージェントによる推論にかかる年間費用と比較する。もし年収50万ドルの高度なスキルを持つエンジニアが、AIトークンコストに25万ドル未満しか費やしていないなら、ファンはそこに問題があると見ている。それは、その開発者が現代的な支援から孤立して作業しているか、あるいはAIを真のコラボレーターではなく、単なる高度な検索エンジンとして扱っていることを示唆している。
これは無謀な支出を推奨するものではない。これは「認知の負荷能力」のテストである。ファンの前提は、エリートエンジニアは、利用可能な最も有能なモデルに、可能な限り多くの精神的な単調作業をオフロードすべきであるというものだ。かつては3日間もかかっていたデバッグ作業も、モデルがコードベース全体をコンテキストとして保持していれば、数時間に圧縮できる。長時間の会議を必要としていたシステム設計の議論も、推論モデルを用いた迅速なプロトタイピングを通じて解決できる。ファンにとって、25万ドルという閾値は予算の上限ではなく、むしろ下限である。それは、トップクラスのエンジニアがフル稼働するために必要とされる、最低限の「知能への補助金」を意味している。
そのラインを下回る開発者は、あまりにも多くの作業を自分自身で行いすぎている。彼らは手動でバグを追跡し、手作業でボイラープレートを書き、適切にプロンプトを入力すればモデルが数秒で合成できるドキュメントを読み返している。推論コストが低下し、コンテキストウィンドウが拡大している時代において、トークンを節約することは規律ではなく、活用不足の兆候である。AIを積極的に活用してアウトプットを増強できないエンジニアは、この論理によれば、パフォーマンス不足である。
レバレッジの代用指標としてのトークン
従来のエンジニアリングマネジメントは、目に見えるアウトプットを好む。クローズされたJiraチケット、プッシュされたコミット、リリースされた機能。これらの数字は数えられるため、安心感を与える。しかし、ファンのフレームワークはそれらを大部分切り捨てている。彼の論理では、シニアスタッフエンジニアは、ミドルレベルの採用者よりも生のコミット数は少ないかもしれないが、より大きな価値を生み出す可能性がある。なぜなら、彼らの真のプロダクトは「意思決定」だからだ。トークンは、それらの意思決定の台帳となる。
エンジニアがLLMの推論に多額の費用を投じる際、彼らは単にテキスト生成を買っているのではない。彼らは「並列化された思考」を買っているのだ。リファクタリングの問題に対して膨大なコンテキストウィンドウを投入する年収50万ドルのエンジニアは、本番コードを一行も書く前に、実質的に十数もの思考スレッドを同時に走らせ、マイクロサービスにわたるエッジケースを確認し、アーキテクチャの仮定をストレス・テストしている。トークンは、給与に見合う労働時間を圧縮された成果へと変換する。それは、さもなければ数百時間の作業を要するであろうスピード、アーキテクチャの先見性、およびデバッグ能力を購入しているのである。
これは、従来のインセンティブ構造を逆転させる。エンジニアリングリーダーは歴史的に、クラウドコンピューティングの割引を厳しく交渉し、SaaSの調達を最小限に抑えるべきコストセンターとして扱ってきた。ファンは、AIにおいてはその考え方は逆であると示唆している。トークン予算は才能に合わせてスケールさせるべきだ。高価な人材を雇いながら、最も高価なモデルの使用を制限すれば、彼らをマニュアルなワークフローの中に閉じ込めてしまうことになる。彼らは「高額なタイピスト」に成り下がってしまう。ファンが示唆する目標は「知能密度（intelligence density）」、つまり、たとえクラウドの請求額が最初は驚くべきものであっても、人間の一時間あたりの適用認知を最大化することである。もしエンジニアが自身の高い報酬を正当化できるほどのトークンを消費していないのであれば、彼らは認知的な重労働をAIにオフロードできておらず、その結果、組織への潜在的なインパクトを制限してしまっている可能性が高い。
チームを維持し、計算資源を拡大する
運用コストの上昇は、通常、人員削減の検討を引き起こす。CFOは膨れ上がるAPIの請求書を見て、反射的に「誰を削減できるか」と問いかける。ファンはそれとは逆の処方箋を提示している。予算に合わせるためにチームを縮小するのではなく、チームに力を与えるために予算を最適化すべきである。
この議論の核心は、代替コストと調整コスト（オーバーヘッド）にある。レガシーなソフトウェア組織では、モノリスの維持、プルリクエストの相互レビュー、そしてサービスの緩やかな移行のために、30人のエンジニアを配置するかもしれない。一方、エンタープライズ級のトークン枠を使いこなす、AIによって高度に能力を拡張された5人の少人数のエンジニアチームであれば、それと同等、あるいはそれ以上のスループットを実現できる可能性がある。節約できるのはAPIの費用項目そのものではない。コミュニケーションの遅延、採用サイクル、そして官僚的な停滞がなくなることによってもたらされるのだ。
この戦略が機能するのは、膨大なトークンの流れを意図を持って制御できるエンジニアを採用した場合に限られる。スタックトレースをチャットボットに貼り付けるだけの開発者と、マルチエージェント・パイプラインをオーケストレートし、豊かなコンテキスト・ライブラリを維持し、ハルシネーションによる出力を厳格に検証する開発者とでは、決定的な違いがある。後者のような人材を見つけるのはより困難だ。だからこそ、Huangは（この）指標を給与に結びつけているのである。高額な報酬は、高いオーケストレーション能力と相関すべきである。週に一度モデルにプロンプトを投げるだけの人間に対して、50万ドルも支払うことはない。支払うのは、前例のないスピードで複雑なシステムを構築する「自動推論のエコシステム」を管理させるためである。
実践における意味
エンジニアリング組織にとって、「トークン対給与比率」は厳格な会計規則というよりも、むしろ文化的なチェックポイントである。リーダーは、最も高い給与を得ている開発者が、AIを積極的に活用するためのアクセス権、トレーニング、そして権限を与えられているかを問い直すべきだ。彼らはレガシーコードに対してロングコンテキスト分析を行っているだろうか、それとも依然としてログを一行ずつgrepしているだけだろうか？ 統合テストにエージェンティックなコーディングツールを使っているだろうか、それとも手作業でモックを書いているだろうか？ プロジェクトのボトルネックは、人間の注意力の限界にあるのか、それともAPIのレート制限にあるのか？
もし答えが「人間のボトルネック」を指しているなら、その解決策として労働時間を増やすことはまずない。通常は、トークンの上限を引き上げることだ。エンジニアに、より多くのエージェントを立ち上げさせよう。サービスメッシュ全体に対して永続的なコンテキストウィンドウを開かせよう。週に2回ではなく、午後のひとときで50回もアーキテクチャの反復（イテレーション）を行わせよう。トークンの消費が「不要なコスト」ではなく「レバレッジの高いエンジニアリング」の証として捉えられるとき、企業内の承認プロセスは変わる。
もちろん、支出すればそれで済むというわけではない。些細なクエリや、スコープの定まっていないプロンプトに注ぎ込まれるトークンは、単なる無駄である。規律とは、膨大な計算リソースを価値の高い問題、すなわち、サービスを横断する設計、セキュリティ監査、レガシー移行のための振る舞いクローニング、そして合成トレーニングデータの生成へと向けることにある。その狙いをマスターしたエンジニアは、マルチプライヤー（生産性の増幅器）となる。そうでない者は、報酬の額に関わらず、まさに間違った意味で「コストが高い」存在に見えてしまう。
真の教訓
Huangのテーゼは、結局のところAI支出の捉え方を変えることにある。LLMのトークンを「運用上の税金」として扱うのはやめよう。それを、エンジニアリングの速度へと変換される「原材料」として扱うのだ。その枠組みにおいて、エンジニアは