「トークンマックシング」とは？　自ら崩壊したAIメトリクス

30日間で、Metaの従業員たちは、消費量に基づいて順位付けを行う社内リーダーボードを通じて、約60兆個のAIトークンを消費した。その費用は1億ドルを超えたと推定され、その仕事の多くは見せかけのものであった。90日後、そのリーダーボードは廃止され、同社はAIの使用を厳格に制限するようになった。

この一連の流れは「トークンマクシング」と呼ばれます。これは、AIトークンの使用量を最大化することが、パフォーマンススコアや生産性の指標として推進される現象です。その後、企業は賢明になり、中には「トークンマイニング」と揶揄される現象に見られるように、計算コストを削減するためにAIトークンの使用を極限まで抑えるという、行き過ぎた是正を行ったところもあります。どちらのアプローチも、トークンの数をAI主導の成長の信頼できる指標として扱っている点で失敗しています。

この記事では、トークンマクシングが実際にどれほどのコストを伴うのか、エンジニアたちがどのようにそれを悪用したのか、そして数字を操るのが得意な人々に対しても通用するセットアップについて解説します。

「トークンマックシング」とは？

「トークンマクシング」とは、AIトークンの消費量を最大化し、その使用量の増加を生産性の向上やAI導入の進展の証拠と見なす慣行のことです。トークンとは、AIモデルが入力として処理し、出力として生成する単位のことです。

トークンの使用量は、可視性があり、定量化が可能で、すでに多くのAIプラットフォームで追跡されているため、魅力的なメトリクスとなりました。そのため、時間の節約、意思決定の改善、収益の創出といった成果よりもレポート作成がしやすくなっています。しかし、トークンは計算処理の活動量を測定するものであり、有用な仕事を測るものではありません。繰り返されるプロンプト、失敗したエージェントのループ、無意味な出力などは、何も生み出さないにもかかわらず、数値を押し上げてしまいます。

AIエージェントは、この状況をさらに悪化させます。エージェントはコンテキストを読み取り、ツールを呼び出し、自身の作業を修正し、他のエージェントにタスクを引き継ぎます。そのすべてのステップでトークンが消費されます。活動量が増えればより有用な仕事につながる可能性もありますが、一方で非効率なワークフローやコストの増加を招く可能性もあります。

簡単に言えば、トークンマックシングの根本的な欠陥は、生産性、品質、投資収益率が変わらないまま、チームが目に見える数値だけを最大化してしまう点にあります。

なぜ「トークンマックス」は人気を博したのでしょうか？

Tokenmaxxingが人気を博したのは、経営陣が社内のAI導入が進んでいることを証明するための番号を必要としていたためです。そして、課金コンソールに表示される唯一のメトリクスが、トークンの使用量だったのです。

NvidiaのCEO、ジェンセン・フアン氏は、2026年初頭に行われた「All-In Podcast」で、高給取りのエンジニアのトークン代に関する思考実験を提示し、その方向性を示しました。

「もしその年収50万ドルのエンジニアが、少なくとも25万ドル相当のトークンを消費していなければ、私は深く憂慮するだろう」と彼は語った。もしその答えが5,000ドルだったとしたら？　彼は激怒するだろう。

AIの利用状況は、誰が時代の流れについていけているかを示す目に見える指標となっていました。これは、どの役割がAIに代替されるのかという疑問が、あらゆる計画ミーティングで取り上げられていた時期に起こっていました。トークンを消費したエンジニアは新しいパラダイムに適応しているように見えたのに対し、消費しなかったエンジニアは問題視されるリスクを抱えていました。

皮肉なことに、最初のトークン・リーダーボードはそもそも競争を目的としたものではありませんでした。Shopifyは、トップユーザーたちがなぜそれほど多く支出しているのかを理解するためにこれを構築したものであり、ユーザー同士を順位付けするためではありませんでした。副社長兼エンジニアリング責任者のファーハン・タワール氏は、後にこのツールがどのように進化していったかを説明しています。

同社はこれを「利用状況ダッシュボード」と改名し、サーキットブレーカーや支出アラートを追加するとともに、そのデータを活用して制御不能なエージェントやインフラのバグを検知した。ファーハンは次のように記している：

「トークンマックシング」は議論を呼ぶトピックです。多ければ多いほど良いというわけではありません。私たちは最初のAIトークン・リーダーボードを構築しました。その後、考え方を進化させ、利用状況ダッシュボードへと変貌させました。データは同じですが、捉え方が異なります。サーキットブレーカーや支出の急増を監視する機能を追加し、暴走したエージェントを捕捉しました。そして、自社のインフラにバグがあることも発見しました。真の指標とは、最も多く支出した人ではなく、トークンが最大の影響を生み出した人です。私が話をしたいのは、まさにそのようなエンジニアたちです。

Shopifyのリーダーボードを模倣した企業のほとんどは、AIへの支出を分析する代わりに、従業員のランク付けにそれを利用しました。以下のテーブルは、各企業でそれがどのように展開したかを示しています。

このテーブルに示される傾向は一貫しています。トークンデータを活用して高額支出を調査した組織は、有効なシグナルを維持しました。一方、従業員のランク付けに利用した組織は、四半期以内にそのシグナルを失ってしまいました。

エンジニアたちはどのようにしてトークン使用量を水増ししたのか？

エンジニアたちは、リリースするつもりなどなかった高コストなAIアクティビティを生成することで、自身のトークン使用量を水増ししていました。『The Pragmatic Engineer』は、Meta、Microsoft、Salesforceにおけるこの行動について報告し、4つの共通した戦術を明らかにしました。いずれも悪意によるものではありませんでした。人々は単に目に見える数値を見て、リストラを懸念し、AIを多用すれば自分を守れるだろうと考えただけだったのです：

多くのエンジニアが、同僚がどれだけのリソースを消費しているかを確認しました。そして、平均をわずかに上回る程度に留まるよう、必要最低限のリソースしか消費しませんでした。彼らはトップの座に立つことよりも、AIを十分に活用していないと指摘されることを避けたかったのです。

アマゾンでは、従業員が「キロランク」スコアを上げるために、AIエージェントに些細な作業やでっち上げたタスクを割り当てていました。これにより、ビジネス上の成果を生み出すことなく、クラウドコストが増加しました。アマゾンがランキング表を廃止した際、上級副社長のデイブ・トレッドウェル氏は、それが善意に基づいて構築されたものだったと従業員に説明しました。そして、彼は率直にこう求めました。「AIを使うこと自体を目的として、AIを利用しないでください。」

この変更の一環として、Amazonは現在、AIが生成したコードが機能し、価値をもたらしているかどうかを追跡しています。トークンの消費量は、同社の優先度が高い事項ではありません。

「トークンマックス」は企業にどれほどのコストをもたらしたのか？

「トークンマクシング」は、Metaに1か月で1億ドル以上の損失をもたらし、Uberの年間AI予算をわずか4か月で使い果たしたと見られる。Metaの推定額は単純な計算によるものだ。Claude OpusのAPI価格リスト（ニュースが報じられた時点）によると、60.2兆トークンのコストは約9億ドルとなる。Metaのような大企業は大幅な割引を交渉できるが、それでも請求額は10桁に達する可能性がある。

Uberは、リーダーボードを一度も導入しなかったため、そのコストを最も明確に示しています。同社は、費用モデルを設けずに約5,000人のエンジニアに「エージェント型」コーディングツールを提供しました。1ヶ月も経たないうちに、「エージェント型」ユーザーと分類されたエンジニアの割合は32％から84％へと急上昇しました。年間予算の全額がわずか4ヶ月で底をついてしまいました。

CTOのプラヴィーン・ネッパリ・ナガ氏は、同社が前提条件について「白紙に戻った」ことを認めた。エンジニア1人あたりの月間費用は500ドルから2,000ドルまでの範囲にあり、その対策はきっぱりとしたものだった。すなわち、エンジニア1人あたり、コーディングツール1つにつき月額1,500ドルの上限を設けるというものだ。

同等の仕事を行うエンジニアの間で支出額にこれほど大きな差が生じているということは、適切な利用とはどのようなものかを誰も定義していなかったことを示しています。そのため、各エンジニアが独自の定義を編み出していたのです。UberのCOOであるアンドルー・マクドナルド氏はこの点を認め、フォーチュン誌の取材に対し、AI支援によるコードと実際にリリースされる有用な機能との間には「一線を引くのが非常に難しい」と語りました。

LeadDevの「AIインパクトレポート」によると、エンジニアリングリーダーのうち、トークンマクシングを「効果的」と評価しているのはわずか19％にとどまります。そのうち57％は、トークンマクシングでは真の価値を測ることができないと述べています。

資金の流動性がこれほど高い理由は次の通りです。コード変更を計画するエージェントは、リポジトリを読み込み、ツールを呼び出し、テストを実行し、成功するまで再試行を繰り返します。たった1回のループで数万トークンが消費されることもあり、プロンプトキャッシュの読み取りによってその消費量はさらに増加します。

財務チームは、AIをあたかも席ライセンスであるかのように予算を組んでいました。しかし、実際にはAIはクラウドコンピューティングのように振る舞います。複数のベンダーにまたがってAIスタックを構築する際、誰にも請求書の所有権を割り当てない場合にも、同様の会計上のギャップが生じます。これは、管理されていないツールの乱立と同じ失敗パターンですが、一段階上のレベルでの問題です。

「トークンマイニング」とは何か？

「トークンマイニング」とは、AIトークンの消費を最小限に抑え、使用量の低さを目標とする手法です。イントロで述べたように、これは行き過ぎた是正策であり、同様に悪い結果を招くものです。この名称は「トークン・ミニマイジング（token minimizing）」の略で、トークンマクシングに対する是正策として登場しました。『ニューヨーク・タイムズ』紙は、複数の企業でこの傾向が見られると報じています。

Metaは、コストが「指数関数的に増加」したことを受け、従業員に対しAIの利用のリミットを設けると通知した。Uberは月間支出にリミットを設け、ウォルマートはツールの利用制限を設定し、AmazonとMetaはともにランキング表を非公開にした。わずか数週間のうちに、かつてAIのヘビーユーザーを称賛していたこれらの企業は、全従業員にAIの利用を節制するよう指導するに至った。

今回の是正措置は、本来是正すべきだった過ちを繰り返している。グッドハートの法則が これを最もよく説明している 。すなわち、メトリクスがターゲットとなると、それはもはや有効なメトリクスではなくなる。したがって、AIトークンの使用量を目標に設定すれば、人々は本来の意図を損なうことになっても、そのメトリクスを最適化する方法を見つけ出すだろう。グッドハートの法則は、トークンマックシングやトークンマイニングに対して警鐘を鳴らしている。

トークンをバーンしたチームに報酬を与えれば、そのチームは不要なトークンまでバーンしてしまいます。トークンを節約したチームに報酬を与えれば、バグを発見できたはずのAI実行をスキップしてしまうでしょう。あるいは、1回の徹底的なセッションを3回の安価なセッションに分割し、それぞれから得られる答えの深さが浅くなってしまうこともあります。どちらのチームもトークン使用量のターゲットを達成する一方で、実際の仕事の質は低下してしまうのです。

コスト管理そのものが間違いというわけではありません。Uberの例のように、月額1,500ドルのリミット設定は、同社が1年分の予算を4ヶ月で使い果たした後に下された予算上の決定です。しかし、支出リミットを設定しても、それは財務上の問題しか解決しません。購入したトークンが何か有用なものを生み出したのかという問いには答えられません。

解決策は、2種類の数値を区別することです。つまり、注視すべき「シグナル」と、目指すべき「結果」です。トークンの利用状況、普及率、AIによって記述されたコードの割合などは、システム内部で何が起きているかを示すシグナルです。これらは問題を調査する際には有用ですが、目標としては不適切です。なぜなら、それぞれが大幅に変化しても、顧客にはその違いが全く気づかれない可能性があるからです。

組織はむしろ、結果の達成を目指すべきです。その論理は、適切に構築されたソフトウェア開発のKPIセットと同じです。つまり、早期のシグナルと、それが予測すべき結果とを接続することです。Shopifyのコンバージョンダッシュボードがそのテンプレートです。同じデータが使用されていますが、そこにランキング表のような要素は一切含まれていません。

IBMコンサルティングのシニアバイスプレジデント、ニール・ダール氏は、AIのコストに関するエッセイの中で、この混乱がどのように広がっているかを説明した。

#Tokenmaxxing は最近、あらゆるメディアで話題となっています。AIを可能な限り、かつ迅速に活用しようとする組織的な動きにより、その利用状況が価値の代用指標として扱われてきました。しかし今、そのツケが回ってきています。AIのコストがリターンを上回る中、直感的には支出を削減したくなるものです。しかし、支出を削減するだけでは、根本的なROIの問題は解決しません。

IBMによれば、解決策は利用状況をシグナルとして扱い、それを偽造できない結果と組み合わせることにある。

トークンの利用量が増えれば、生産性も高まるのか？

いいえ、トークンの使用量が多いからといって、生産性が高いとは限りません。入手可能な最大規模のデータセットによると、この2つは互いに独立して推移していることが示されています。開発者向けインテリジェンスプラットフォーム「DX」の調査によると、AIの導入率は飽和状態に近づいている一方で、測定された生産性の向上は横ばいにとどまっています。

DXのCTO、ローラ・タチョ氏がその数値を共有した。開発者のうち、92.6%が現在、少なくとも月に1回はAIコーディングアシスタントを利用しており、約75%が週に1回利用している。本番環境のコードの26.9%はAIによって記述されている。しかし、自己申告による時間短縮効果は、1年以上もの間、週に約4時間のまま横ばい状態が続いている。また、当初見込まれた10%の生産性向上も、それ以上伸びることはなかった。

利用状況は上昇し続けた一方で、結果は横ばいだった。利用状況だけを追跡するメトリクスは、実際には実現しなかった成功をレポート作成し続けてきたのだ。

Google CloudのDORAレポートは、同じツールがなぜこれほど異なる結果を生み出すのかを解説しています。同レポートによると、AIの導入はデリバリー速度を向上させた一方で、デリバリーの安定性を損なったことが判明しました。レポートでは、AIを「増幅器」と表現しており、適切に運営されている組織の強みをさらに引き出し、苦戦している組織の弱点をさらに際立たせるとしています。

DX独自のデータは、この増幅効果が実際に働いていることを示しています。67,000人の開発者からなるあるグループでは、同じ期間に同じツールを使用していたにもかかわらず、顧客に影響を与えるインシデントが倍増した組織もあれば、半減させた組織もありました。Tachoは、データが示す通りに責任の所在を明確にします：

これは本質的に経営上の問題です。過度な期待から、AIを試すだけで自動的に利益が得られるかのように思われていました。しかし、これまでのところ、ほとんどのツールは個別のコーディングタスクにのみ使用されてきました。真の効果を実感するためには、単一のタスクだけでなく、組織レベルでAIを活用する必要があります。

この問題の根底には、もう一つの問題があります。それは、人々がAIによる作業効率の向上を過大評価してしまうことです。 非営利の研究機関METRは、無作為化比較試験を実施した。経験豊富なオープンソース開発者16名が、平均5年間メンテナンスしてきたリポジトリ内の246件の問題を完了した。開始前、開発者たちはAIによって作業速度が24%向上すると予測していた。終了後、彼らは約20%の速度向上があったと推定した。しかし、ストップウォッチの計測結果によると、実際には19%遅くなっていた。

その後のアップデートで、同研究所は次の実験において、補正できない選択バイアスに直面したことを説明した。また、主にエージェント型ツールのおかげで、開発者は現在、AIを活用することで真に作業効率が向上している可能性が高いとも述べた。残された教訓：自己申告による生産性は、測定された生産性の代わりにはならず、その間の乖離はどちらの方向にも生じ得る。

トークンの使用状況の代わりに、何を測定すべきか？

トークンの使用量ではなく、チームレベル、ひいては組織レベルでの結果を測定しましょう。トークンの使用量は、評価の対象とはならないコストの指標として扱うべきです。重要なのは、生み出された結果なのです。

実践すべき1つのルール： 公開するあらゆる指標には、その指標によって水増しできない結果を必ず結びつけること。チームは、何もリリースせずにトークンをバーンすることはできます。しかし、変更の失敗率が低下しているという事実を偽造することはできません。

この構造は、エンジニアリングリーダーたちがすでに信頼を寄せている測定フレームワークに基づいています。DORAはデリバリー速度と安定性を網羅しており、AIが両者を増幅させるというその知見こそが、この組み合わせが重要である理由です。

「DX Core 4」は、スピード、有効性、品質、ビジネスへの影響という4つの側面を測定します。Abi Noda氏とLaura Tacho氏は、DORA、SPACE、DevExの開発に携わった研究者であるNicole Forsgren氏およびMargaret-Anne Storey氏と共に、この指標を構築しました。これら4つの側面は、意図的に互いに相反する関係にあります。

一方を犠牲にして他方を向上させるチームは、そのトレードオフを即座に露呈させてしまう。どちらのフレームワークにもトークンメトリクスは含まれておらず、追加されたこともない。

この組み合わせが実際に機能するためには、次の3つのルールが必要です：

従業員が不正に操作できないAI利用ポリシーをどのように設定すればよいでしょうか？

従業員が操作できないAI利用ポリシーを設定するには、個人の評価から可視性のある番号をすべて排除し、以下の5つの決定を下してください：

1. データを収集する前に、その番号の目的を明確にしておく

ポリシーに含まれるすべてのメトリクスには、最初のダッシュボードが公開される前に、その目的を文書化する必要があります。Shopifyのリーダーボードは、当初はうまく機能していました。経営陣はこれを利用して、多額の支出を行っているユーザーと、彼らが何を作っているのかについて会話を始めました。その番号は調査のきっかけとなりました。しかし、同じ番号が、仕事について質問するのではなく、その人自身について何かを結論づけることで一つの調査を締めくくるようになると、それはスコアへと変化します。そして、スコアは管理されるようになるのです。

各メトリクスについて、以下の3点を書き出してください：

「何もしない」という選択肢が最も大きな仕事を果たします。なぜなら、従業員はこの基準を基にポリシーを検証するからです。「支出が急増した場合はどうなるか」という問いに対する正直な答えに、誰かの立場が絡んでくるのであれば、あなたは余計なステップを伴うランキング制度を構築してしまったことになります。

2. チーム単位で予算を設定する

チームで共有する予算枠は、一人あたりの上限に代わるものであり、その違いは会計上の問題ではなく、行動上の問題です。Uberでは、同等の仕事を行うエンジニアの間で月々の支出に500ドルから2,000ドルものばらつきが見られますが、これは共通の基準点がない場合に何が起こるかを示しています。誰もが自分なりの「妥当」という定義を作り出してしまうのです。予算枠は、ばらばらなAI支出を1つの説明責任の明確な場所に集約しようとする、他のあらゆる努力と同様に機能します。

この「エンベロープ」には、1人あたりの上限では得られない3つのメリットがあります：

観測データから最初の予算枠のサイズを算出します。チームの過去3ヶ月間の平均値を取り、コストのかかるプロジェクト1件分の余裕を加算します。推測で設定された予算枠は2週目には超過し、この方針が形だけのものだと全員に思い知らせることになります。

3. 高コストな経路の可視性を高める

エンジニアに対して、支出上限を設けるのではなく、実行ごとのコストを提示しましょう。テストの失敗を繰り返すエージェント型の実行が予算を食い尽くし、ハードキャップの設定が急務となります。別の選択肢として、上層部にはレポート作成せずに、実行をトリガーしたエンジニアに対して実行ごとのコストを表示する方法もあります。

リトライループによって40ドルが無駄になるのを見ているエンジニアなら、そのループを修正するでしょう。一方、レポート作成を恐れるエンジニアは、その高コストな実行が正しい判断だった場合であっても、エージェントの使用を完全に止めてしまうでしょう。

Shopifyのサーキットブレーカーは次のように機能します。システムが異常を検知すると、その仕事に最も近い担当者がやることを決めます。可視性は上限設定よりも迅速に行動変容をもたらし、仕事上の必要性が費用に見合う場合には、コストはかかるものの適切な運用を維持することができます。

4. AI導入の目標と業績評価を区別する

解雇のサイクルが押し寄せた際、口頭での保証だけでは通用しないため、分離の合意は書面に残しておきましょう。『The Pragmatic Engineer』誌に対し、自身のメトリクスを水増ししていたと語ったMicrosoftのエンジニアは、賞を狙っていたわけではありません。AIを理由とした解雇が相次いだその年、彼らはラベルを貼られることを避けていたのです。

利用データが評価ミーティングに持ち込まれると人々が信じれば、たとえ誰かが口に出して何と言おうとも、彼らはそのデータを管理するようになるでしょう。

ポリシー文は、正確に2行で済みます：

そして、その両方を尊重しましょう。レビューで利用データが提示されたのを最初に目にしたエンジニアが、そのことを皆に広め、そのメトリクスが不要であることを証明してしまうでしょう。

5. 四半期ごとにペアリングを見直す

四半期ごとに、各診断項目が依然としてそれに対応する結果を説明できているかどうかを検証してください。モデルの価格設定、キャッシュの挙動、エージェントのアーキテクチャは、いずれも年次プランサイクルよりも速いペースで変化しています。

チームがプランやレポート作成にAIをどのように活用するかは、常に変化し続けています。1月にはある意味を持っていたトークン数は、2回の価格引き下げとエージェントのアップグレードを経て、6月になると全く異なる意味を持つようになります。

このレビューでは、各メトリクスについて率直な評価が示されています。依然としてペアの結果を予測しているもの、新しい価格に合わせて再調整が必要なものはある一方で、もはや何の説明もできなくなり、あっさりと廃止されるものもあります。チームは廃止に最も抵抗します。しかし、これは重要なことです。なぜなら、その意味を失ったまま存続するメトリクスこそが、まさにリーダーボード時代を支えてきた数字そのものだからです。

AI導入状況を測定する際にチームが犯しがちな間違い

最もよくある4つの過ちは、普及率をゴールと見なすこと、自己申告による時間短縮を鵜呑みにすること、個人のランキングを公開すること、そして安定性を測らずに速度だけを測定することです。これらは、多額のコストがかかる前にそれぞれ見抜くことができます。

1. 普及をゴールと見なすこと

導入ダッシュボードに「90%」と表示され、経営陣はAIイニシアチブが完了したことを宣言するが、下流で何が変わったのかを問う者は誰もいない。DXのデータはこの罠を大規模に暴いた。導入率は92.6%に達したものの、生産性は10%で横ばいだったのだ。導入率は、ツールがユーザーに届いたことを示すに過ぎない。ツールが何を変えたかについては、何も語っていない。

解決策： 展開が終了したら、採用率チャートを廃止し、シグナルと結果の組み合わせに置き換える。

2. 自己申告による時間短縮効果を鵜呑みにすること

あるアンケートによると、チームは週に5時間の時間を節約しているとの結果が出ていますが、サイクルタイムは2四半期にわたって変化が見られません。METRの試用版は、この2つの数値に食い違いが生じる理由を明らかにしています。AIの使用により作業速度が明らかに低下した開発者たちでさえ、その後も作業速度が20％向上したと推定していたのです。人々の認識と、実際に計測された数値とは、まったく別のものなのです。

解決策： 認識が重要な開発者体験については、アンケートを維持する。時間に関する主張には、システムデータを活用する。

3. 単なる楽しみのために、個人別のリーダーボードを公開する

誰かが社内のwikiで午後一でそれを構築し、遊び心のあるタイトルを付け、チームはおよそ3週間ほど心からそれを楽しんだ。その後、インセンティブが優先されるようになった。Metaの「Claudeonomics」もAmazonの「Kirorank」も、当初は草の根的な楽しみとして始まった。どちらの企業も、ゲーム的な要素が熱意を上回った時点で、それらを廃止した。

解決策： データをチームレベルに集約するか、あるいは送信しないこと。

4. 安定性を測定せずに速度を測定する

スループットが向上し、皆が喜ぶ一方で、別のチームのダッシュボードではインシデント件数が増加している。DORAレポートは、まさにこの二極化を指摘した。つまり、速度は向上する一方で安定性は低下しているのだ。この2つの数値を別々のダッシュボードに表示し続けることで、問題は見えなくなってしまう。

解決策： 変更の失敗率を、速度のメトリクスと同じ画面に表示する。誰も参照しない別の信頼性レビューに含めるのではなく。

ClickUpでAIの影響を追跡する方法

ClickUpでAIの影響を把握するには、作業そのもの――つまり、AIによって効率化されるはずだったタスク、スプリント、成果物――と並べて結果を測定しましょう。多くのトークンダッシュボードはプロバイダーのコンソール上にあり、それらが表す実際の仕事とはかけ離れています。結果のメトリクスをワークスペース内に移すことで、そのギャップを埋めることができます。

前述の「シグナルと結果」の組み合わせは、このプラットフォームにそのまま当てはまります：

スコア付けをせずにトークン数を把握する

この一連の経緯は、ある一つのルールに集約されます。それは、「トークンデータは疑問を投げかけるために使い、決して人を評価するために使ってはいけない」ということです。Shopifyは「当社のトップユーザーは何を構築しているのか？」と問いかけ、制御不能なエージェントやインフラのバグを発見しました。MetaとAmazonは「誰がAIを最も活用しているのか？」と問いかけ、偽のタスクや数百万の無駄遣い、そして機能しなくなったランキングリストという結果に終わりました。

そこで、今四半期は次の3つのことをやること。トークンの追跡をチームレベルに移行し、個人の名前が記載されているものはすべて削除してください。利用データが業績評価に一切反映されないことをポリシーに明記してください。そして、報告するすべての速度メトリクスと同じ画面に、1つの品質メトリクス（失敗率の改善が最も簡単です）を表示するようにしてください。

その画面を、別のレポート作成ツールではなく、実際の仕事のすぐ横に表示させたいなら、今すぐClickUpを無料で使い始め、必要になる前にダッシュボードを作成しておきましょう。

Tokenmaxxingに関するよくある質問（FAQ）

トークンマクシングにおける「30％ルール」とは何でしょうか？

トークンマクシングに特化した公式の「30%ルール」は存在しません。この言葉は通常、人々が混同しがちな2つの別々の知見を簡略化したものです。1つは、AIによって測定されるエンジニアリングの生産性が30%ではなく、およそ10%向上する傾向にあること。もう1つは、開発者が日常的に20～30%程度の向上を予測するものの、それが実現しないということです。固定されたパーセンテージは、ターゲットではなく、調査すべき指標として扱うべきです。

100万トークンは、英語のテキストで約75万語に相当します。これは、1トークンが平均して約4分の3語に相当するためです。コストは、モデルと入出力比率に完全に依存します。2026年の最先端モデルのレートでは、100万トークンあたり数ドルから数十ドル程度となります。エージェント型セッションでは、各ループでコンテキストを再読み込みするため、またプロンプトキャッシュの読み込みもカウントに加算されるため、数百万トークンが急速に消費されます。

「トークンマクシング（Tokenmaxxing）」は、「トークン（token）」と、ある特性を最大化することを意味するインターネット用語の接尾辞「-maxxing」を組み合わせた造語です。2026年初頭、MetaとAmazonの社内トークンランキングが報道機関にリークされたことをきっかけに、エンジニアリング界隈で広まりました。 2026年4月、ビジネス・インサイダーはこの現象を「シリコンバレーにおける新たなAI論争」と称した。その後、Viberankやtokenmaxxing.shといった公開ランキングサイトがこのラベルを採用し、API使用量に基づいて世界中の個々の開発者をランク付けするようになった。

概ねその通りです。『フォーチュン』誌は、Meta、Amazon、Microsoft、Uberがトークンランキングの縮小や廃止に踏み切ったことを受け、2026年5月に「トークンマックス」の終焉を宣言しました。LeadDevの「AIインパクトレポート」によると、回答者のわずか19％が「トークンマックス」をAIの価値を測定する有効な手段と評価しているのに対し、57％は「完全に失敗している」と答えています。愛好家による公開ランキングは依然として存在していますが、それは管理手法というよりは、あくまでゲームとしての側面が強いものです。

確立されたベンチマークは存在しません。Uberでの導入当初、エンジニア1人あたりの月額請求額の範囲は500ドルから2,000ドルでしたが、その後同社はツール1つあたり1,500ドルに上限を設けました。NvidiaのCEO、ジェンセン・フアン氏は、年収50万ドルのエンジニアなら年間25万ドル分のトークンを消費すべきだと主張していますが、これはおそらく挑発的な発言であり、基準ではありません。 調査結果によると、同等の仕事間でも大きなばらつきが見られることから、適切な利用形態がまだ定義されていないことがわかります。

「バイブコーディング」とは、実装をAIエージェントに委任し、成果に基づいて方向性を定める働き方のことです。「トークンマクシング」とは、消費したトークンを生産性の証拠として扱う測定手法です。バイブコーディングには効率的な方法もあれば、無駄の多い方法もありますが、トークンマクシングは消費量のみをカウントするため、無駄の多い方法を助長してしまいます。トークンマクシングを阻止するためにトークンの上限を設けた企業は、その過程で正当なエージェントによる仕事を不当に評価してしまうことがよくありました。