中国の開発者は仕事のためにトークンアクセスを購入しているが、雇用維持の主張は立証されていない

中国の開発者が仕事のためにトークンアクセスを購入していると報じられている。一方で、雇用を守るために自費で支払わなければならないという拡散した主張は、なお検証されていない。

この疑惑は、2026年8月15日までにZhihuで話題となった。プログラマーが雇用可能性を維持するため、毎月AI利用料を支払っているという内容であり、「働くために支払う」慣行として描かれていた。ただし、このページには開発者、雇用主、契約、返金方針、解雇の脅威を裏付ける記録はいずれも特定されていなかった。

この証拠の欠落は重要だ。個人契約は、実験や利便性、あるいは雇用主が必要なインフラへの資金提供を拒んでいることを反映している可能性がある。最も強い形の主張を裏付けるのは、最後のケースだけである。

とはいえ、この論争が突然生まれたわけではない。開発者はより多くのAIコーディングエージェントを利用し、企業は大量利用を称賛し、計算コストは個人単位で可視化されつつある。対立はもはや単純に労働者対自動化ではない。雇用主の期待と、雇用主の責任との対立である。

拡散したトークン主張が実際に示していること

入手可能な証拠が裏付けているのは職場コストをめぐる論争であり、開発者が雇用維持のためにトークンを購入しているという検証済みの事例ではない。

Zhihuの質問は、懸念を招く因果関係を提示している。プログラマーは上昇する成果期待に応えるためAIを必要とする。雇用主は十分な利用量の負担を拒むとされる。その結果、遅れを取ることが雇用を脅かすため、労働者は追加の利用枠を購入するというものだ。

この流れはもっともらしいが、もっともらしさは検証ではない。公開質問には、給与記録、社内方針文書、請求書、特定企業に結びつく証言は示されていない。また、労働者が有料ツールの利用を命じられたかどうかも立証されていない。

7月18日の企業トークン予算に関する報道は、最も明確な背景を示している。中国のテクノロジー企業がAI消費を新たな職場リソースとして扱っている状況が描かれた。一部の雇用主はアクセスを割り当て、エンジニアは給与やその他の福利厚生と並べてトークン利用枠を議論していた。

トークンとは、AIモデルが処理または生成するテキストの小さな単位である。コーディングエージェントは、リポジトリの繰り返しの調査、変更の生成、テストの実行、エラーの読み取り、作業の修正を行うため、大量に消費することがある。

つまり、エージェント型コーディングのセッションは単純な一問一答ではない。多くの場合、長いソースファイルと反復的な推論を伴う、モデル呼び出しの連鎖である。そのため、最終的なコード変更が小さく見えても、より自律的な作業はより多くの利用量を生み出しうる。

企業負担のアクセスと従業員負担のアクセスの違いは核心的だ。任意の個人アカウントは、従業員が好みのキーボードを選ぶことに似ている。必須でありながら補償されないアクセスは、雇用主が労働者に本番用インフラを用意させることに似ている。

中間的なケースもある。一部の企業は承認済みのアシスタントを1つ提供する一方で、開発者は自分の仕事をより適切に処理できる別のツールを購入する。その選択は当初は任意でも、管理職がそこで得られた速度を締め切りに織り込めば、手放しにくくなる。

拡散した主張は、こうした異なる取り決めを一つの劇的な表現に圧縮している。そのため、この質問は警告としては有用だが、広範な雇用慣行の証拠としては信頼できない。

それでも、この疑惑が注目すべき議論になるほどもっともらしく感じられたことには意味がある。その反応は、AIアクセスが任意の実験から、職業上の競争力を左右する非公式な条件へと急速に移行していることを示している。

トークンアクセスは仕事の一部になりつつある

企業方針がなお個人の生産性に関する好みとして扱っている場合でも、AIコーディング能力は職場インフラのように機能し始めている。

JetBrainsは2026年1月、1万人を超えるプロの開発者を調査した。開発者向けAI調査では、90％がコーディングおよび開発作業で少なくとも1つのAIツールを定期的に使用していると回答した。

同じ調査では、74％が一般的なチャットボットだけに頼るのではなく、専門の開発者向けツールを導入していた。GitHub Copilotは依然として最も広く使われている専門製品であり、Claude CodeとCursorが職場での導入率でその次の位置を共有した。

これらの数字は、誰が費用を負担したかを示すものではない。しかし、AI支援開発がアーリーアダプターに限られた珍しい慣行ではなくなったことは示している。

以前のGitHub調査も、異なる標本から同様の結論に達している。この調査は4カ国のエンタープライズソフトウェア従事者2,000人を対象とした。公開されたエンタープライズ利用データによると、97％超が何らかの時点で職場でAIコーディングツールを使用したと回答した。

企業の支援にはばらつきがあった。国によって59％から88％が、雇用主がAI利用を認めている、または積極的に推奨していると回答した。これは、導入と制度的支援の間に無視できない隔たりがあることを意味する。

雇用主は、AI利用を許可していると言いながら、ライセンス、利用予算、セキュリティ管理、研修、評価基準を提供しないことがある。許可だけでは、労働者からほとんどリスクを移転できない。

管理職がAI支援による成果を見た後に期待値を見直すと、圧力はさらに強まる。以前は数日かかっていた作業を、開発者はより早く終えるよう求められるかもしれない。無料枠が尽きたり、好みのモデルが利用できなくなったりしても、新しい締め切りは維持されうる。

これはラチェット効果を生む。一時的な向上が恒久的な期待へと変わる一方で、ツールのコストは変動したままだ。労働者は、自費で支払うか、見かけ上低い成果を受け入れるか、制約を隠そうとするかという選択を迫られる。

この力学は、求職者、契約社員、業績評価中の従業員にとって特に厳しい。彼らには生産性の義務付けに異議を唱える交渉力が少なく、ツールへの支出を防衛的な行動と見なす理由が多い。

AIアクセスは、従業員が引き受ける仕事にも影響しうる。有能なコーディングエージェントを持つ開発者は、不慣れなコードベースを調査し、テストを下書きし、言語間の翻訳をより速く行える。アクセスが限られる同僚は、両者に同程度のエンジニアリング上の判断力があっても、同じ作業を避けるかもしれない。

これは、より多くの資金を得た開発者が本質的に高いスキルを持つことを意味しない。組織が購買力によって測定される成果が左右されることを許している、という意味である。

企業はすでに、クラウド環境、テストデバイス、コンパイラ、可観測性システムについてこの原則を認識している。より良いインフラを使えば競争力が高まるからといって、従業員に本番データベースの費用負担を求めることはめったにない。

エージェントが日常的な開発により深く入り込むにつれ、AIだけを異なる扱いにすることは難しくなる。ツールの利用が期待され、監視され、または納品目標に反映されるなら、アクセスは事業上の投入資源である。

これが、この論争が明らかにした最初の業界課題だ。企業は、誰が費用、アカウント、データ、そして生じる責任を担うのかを定義するより速く、AIへの期待を業務化している。

トークン支出が生産性の指標として不適切な理由

トークン消費が測るのは計算活動であり、顧客価値、エンジニアリング品質、完了した仕事ではない。

企業の熱狂は、消費量をステータスシンボルへと変える一因となった。経営陣は、大量利用を従業員がAIを受け入れている証拠として推進した。一部の組織は、消費量をめぐる社内キャンペーンや競争を行ったと報じられている。

その論理は直感的に聞こえる。エージェントが労働者の生産性を高めるなら、より多くのエージェントを動かす従業員はより多くの価値を生むはずだ。しかし、この議論の各段階には、利用状況ダッシュボードでは示せない証拠が必要である。

消費量が多いのは、エージェントが複雑な作業を処理したことを意味するかもしれない。一方で、プロンプトに文脈が不足していた、モデルが不適切な経路を選んだ、ユーザーが弱い出力を何度も修正した、といった可能性もある。2人の開発者が、まったく異なる処理量で同じ結果に到達することもある。

生産性が低下する際に、利用量が増えることさえある。エージェントは不要なファイルを生成したり、パッチを過度に複雑にしたり、無関係な解決策を探ったりする可能性がある。追加の試行は活動量を増やす一方で、レビュー作業も増やす。

Associated Pressは7月27日、tokenmaxxingの限界をめぐる企業の熱狂が、コスト精査へと移りつつあると報じた。企業は、AI消費量の増加が自動的に見合う成果を生まないことを認識し始めていた。

この転換は、従業員が自費で利用量を最大化すべきだという考えを弱める。企業自身が消費量と収益を確実に結びつけられないなら、労働者は献身を示すためだけに活動量を購入する必要はないはずだ。

ソフトウェア管理の歴史は、役立つ比較を提供する。かつてコード行数は明確な生産性指標に見えた。チームはやがて、コードが多いことは重複、不必要な複雑さ、あるいは保守負担を表す場合があると認識した。

トークン数は、この誤りをより高速に繰り返す恐れがある。中間的なリソースを、業績目標へと変えてしまうからだ。

優れたエンジニアリングは、将来の作業を減らすことが多い。開発者は、時代遅れのシステムを削除したり、要件を絞り込んだり、ある機能の開発自体を防いだりするかもしれない。そうした判断は、わずかなAI利用量で大きな価値を生み出しうる。

一方で、エージェントは数分で大規模なパッチを生成できる。その出力にはなお、人間が動作を検証し、セキュリティを評価し、アーキテクチャ上の影響を理解し、その変更が製品に含まれるべきか判断することが必要だ。

したがって管理職には、消費量の指標ではなく成果の指標が必要である。有用なシグナルには、サイクルタイム、流出欠陥、レビュー負荷、信頼性、顧客への影響、完了した変更の保守性が含まれる。

これらの指標にも注意が必要だ。より速い納品は先送りされたテストを隠す可能性があり、可視化される欠陥の減少は検出能力の低下を反映している可能性がある。単一の指標で、開発者がAIを効果的に使ったかどうかを決めるべきではない。

従業員負担のモデルは、測定をさらに悪化させる。個人で支払う従業員は、雇用主が管理も監査もできないアカウントを使う可能性がある。そうなると管理職は、背後にあるプロンプト、モデル、データ露出、処理経路を確認せずに成果だけを見ることになる。

それは、成熟したエンジニアリング組織が抑制すべき行動そのものを報いる可能性がある。見かけ上最も速い貢献者が、知的財産やセキュリティに関して最大のリスクを負っているかもしれない。

したがって、この議論は返金の問題にとどまらない。企業がAIを管理された本番システムとして扱うのか、それとも目に見えない個人的優位性として扱うのかが問われている。

生産性向上という約束には、なお検証上の問題がある

AIは特定のコーディング作業を加速できるが、有料アクセスを低業績に対する万能の防御策として扱うことを、証拠は正当化していない。

開発者は、コーディングアシスタントによる有意義な利点を報告している。GitHubのエンタープライズ調査回答者は、これらのツールによってコードベースの把握、テスト生成、言語の習得が容易になり、システム設計に充てる時間が増えると関連付けた。

JetBrainsも、複数の製品について幅広い導入と高い満足度を記録した。開発者は、使い続けるだけの価値を明らかに見いだしている。

しかし、体感上の速度と実測上の速度は一致しないことがある。研究機関METRが2025年に実施した調査では、使い慣れたリポジトリで作業する経験豊富なオープンソース開発者16人を対象に検証した。参加者はAIによって作業が速くなると予想していたが、測定結果は逆だった。

実測によるコーディング調査の要約によると、参加者はAIによって作業が約20％加速したと考えていた。しかし実験では、実際には約20％長い時間がかかっていたことが判明した。

研究者らは、この結果をすべての開発者やタスクに一般化すべきではないと注意を促した。サンプル数は少なく、参加者は経験者であり、ツールも変化を続けている。

こうした限界は重要だ。同時に、確信と測定結果の隔たりも重要である。

エージェントがすぐに目に見えるコードを生成するため、従業員は自分が速くなったと感じることがある。だが、遅い工程はその後に、読み込み、テスト、デバッグ、前提の修正として現れる。心理的な報酬は先に得られる一方で、検証コストはワークフロー全体に分散する。

タスクによって得られる効果も異なる。ボイラープレート、独立したテスト、APIの例、移行の下書きは、エージェントと相性がよい場合がある。一方、曖昧な製品要件、レガシーな挙動、セキュリティに敏感なコード、アーキテクチャ上の判断には、より多くの文脈と判断力が必要になる。

モデル選択も重要だ。より大きなモデルは難しい推論を処理できるが、より多くのリソースを消費する可能性がある。あらゆるタスクを最も高性能な選択肢に振り分けても、日常的な作業を改善せずにコストだけを押し上げることがある。

従業員に個人負担を求める組織は、こうした違いに向き合わずに済ませている。各従業員に管理されない実験をさせ、その後で目に見える結果を評価するだけになる。

その仕組みは、失敗した利用も見えにくくする。特に経営側がすでにAIを生産性の必須要件として掲げている場合、従業員がエージェントの修正に費やした時間を積極的に公表することはほとんどない。成功事例は上層部へ伝わるが、無駄になった時間は個人の中にとどまる。

その結果、選択バイアスが生じる。リーダーは洗練されたデモや迅速に処理されたチケットを見る一方、放棄された試みや後工程の保守を必ずしも目にしない。

公正な評価制度では、アクセスと能力を分けて考えなければならない。企業負担のエージェントを使う開発者と、無料アクセスに限られる開発者を比較すべきではない。また、より多く支払う人がより優れたエンジニアだと想定すべきでもない。

代わりに、雇用主は統制された評価を実施できる。チームはタスクの分類を特定し、エンドツーエンドの提供を測定し、レビュー時間を追跡し、不具合の結果を検証できる。個人の利用量を競争に変えることなく、ワークフローを比較できる。

開発者には、AIが摩擦を増やす場合に利用を断る余地が必要だ。あるリポジトリで役立つツールが、言語サポート、ドキュメントの品質、テストカバレッジ、コンテキスト量の違いにより、別のリポジトリでは機能しないことがある。

あらゆる拒否を変化への抵抗と呼べば、専門的な判断を妨げる。また、機密性や信頼性を優先すべき場面で、従業員にAIの利用を促すことにもなり得る。

したがって、AIコーディングツールを支持する最も強い根拠は条件付きのものだ。タスクに適合し、モデルに十分なコンテキストがあり、開発者が結果を検証でき、周囲のプロセスがその効果を捉えられる場合に有用である。

このどれも、アクセスをより多く購入すれば仕事がより安全になる、という自動的な結論を裏付けるものではない。

従業員負担のAIはセキュリティと説明責任の空白を生む

開発者が業務用AIを個別に購入する場合、雇用主は調達コストを抑えられるかもしれないが、その一方で法務、セキュリティ、保守に関するより大きなリスクを積み上げることになる。

個人のAIアカウントは、多くの企業統制の外にある。集中型のID管理、承認済みの保存設定、利用ログ、送信コードを規律する契約条項が欠けている可能性がある。

締め切りに追われる開発者は、スタックトレース、ソースファイル、データベーススキーマ、顧客情報、社内ドキュメントをモデルに貼り付けてしまうかもしれない。組織が承認済みのワークフローを提供しない場合、責任感のある従業員であっても、プロンプトが何を明かしているかを誤って判断することがある。

リスクはデータが企業外へ流出することに限られない。AI生成コードは、依存関係を持ち込み、安全でないパターンを複製し、権限を誤解し、レビュー担当者が追跡しにくい挙動を生み出す可能性がある。

GitLabが2026年に実施し、公開されたAIガバナンスに関する調査結果で報じられた調査では、1,500人超の開発者を対象にした。その結果、79％が、ソフトウェア提供は個々の開発者の生産性ほどには加速していないと考えていた。

同じ報告書では、85％がレビューと検証を主な制約と見なしているとされた。また、43％はAI生成コードと人間が書いたコードの区別に苦労していることも明らかになった。

これらの結果はベンダーによる調査に基づくものであり、その文脈を踏まえて読むべきだ。それでも、個人購入では解決できない組織的な問題を示している。

コード生成は個人のレベルで行われるが、レビュー、デプロイ、インシデント、保守はチーム全体で行われる。ある従業員が時間を節約する一方で、同僚により大きなコストを移転することもあり得る。

これは局所的な生産性とシステム全体の生産性の違いである。局所的な生産性は、1人が下書きをより速く完成させたかを問う。システム全体の生産性は、組織がより少ない総労力で信頼できる価値を提供したかを問う。

未補償のツールは、その両方をゆがめる可能性がある。従業員は、セキュリティ、統合性、長期的なサポートではなく、個人で負担できる価格を基準に製品を選ぶかもしれない。結果として、チーム内で互換性のないワークフローを通じて複数のエージェントがコードを生成する状況になり得る。

その後、説明責任は不明確になる。企業がAI利用を期待しながらツールを承認していない場合、データ漏洩の責任は誰が負うのか。マネージャーが速度を評価しながら出所を無視する場合、AI生成の不具合の責任は誰が負うのか。

ほとんどのエンジニアリング文化では、従業員は提出したコードに責任を負い続ける。この原則には合理性があるが、検証の時間を与えないままツール導入を迫る場合、経営側の姿勢は不公平になる。

雇用主は、AIに合わせた締め切りを維持したまま、あらゆる個人ツールを禁止することで解決すべきではない。それでは生産性への期待を残したまま、従業員からそれを満たす手段を取り上げることになる。

実行可能な方針には、相互に結び付いた4つの要素が必要だ。費用負担されたアクセス、承認済みのデータ取り扱い、タスク別の指針、現実的なレビュー時間である。そのうち1つでも欠ければ、抜け穴が生まれる。

費用負担されたアクセスは、個人の所得が職場での能力を決めることを防ぐ。承認済みの慣行は、どのデータをモデルに入力できるかを定める。タスク別の指針は、有用な利用と高リスクな利用を区別する。レビュー時間は、生成されたコードが完成済みのコードではないことを認めるものだ。

チームには持続的な記録も必要である。プロンプト、判断、テスト、アーキテクチャ上の文脈は、個々のセッションが終わった後も利用できる状態にしておくべきだ。検索可能なエンジニアリングナレッジベースは、生のトークン量を作業記録にすることなく、思考過程を保存できる。

このアプローチは、AIをソフトウェアサプライチェーンの一部として扱う。また、不確実性を個々の従業員に押し付けるのではなく、調達に結果への説明責任を持たせる。

労働問題の核心は、利益を誰が得るかにある

AIが成果への期待を高める一方で、従業員がツール費用を負担し、そのリスクを引き受けるなら、雇用主は利益を得る一方で、従業員がコストを負うことになる。

企業は専門職にスキル開発を期待するのが一般的だ。従業員は本を買い、講座を受け、ソフトウェアを試し、個人プロジェクトを維持する。すべてのキャリア関連費用が補償を必要とするわけではない。

しかし、必須の生産投入物は別である。この区別は、統制、必要性、利益によって決まる。

開発者が学習や個人的な利便性のために自由意思でツールを購入するなら、その費用は専門能力開発に近い。雇用主がツールを要求し、AI依存の目標を設定し、アクセスのない従業員に不利益を与えるなら、その費用は事業用設備により近いものとなる。

非公式な圧力は、この判断を複雑にする。マネージャーが書面で義務を出すことはないかもしれない。チームがより速い成果を当たり前にするだけで、従業員は有料アクセスが必要だと結論付ける場合がある。

明示的な解雇の脅しが確認できなくても、「働くために支払う」という表現が現実の懸念を捉えるのはこのためだ。雇用上の圧力は、明示的な命令ではなく、順位付け、締め切り、契約更新、配分される仕事の質を通じて働くことが多い。

所得の高い従業員は、より多くの能力を購入し、複数のサブスクリプションを維持し、追加のモデルを試すことができる。若手従業員や契約社員は選択肢が少ないかもしれないが、速度を示すよう求められる圧力はより強い可能性がある。

その結果生じる不平等は自己再生産され得る。より良いアクセスはより目に見える成果を生み、目に見える成果はより良い仕事の割り当てにつながり、より良い割り当ては従業員の立場を強める。

AIベンダーは、この分断から利益を得る。需要が集中調達から数百万人の個人購入者へ移るためだ。雇用主は難しいガバナンスの判断を先送りできる一方、従業員が導入費用を負担する。

ただし、分散型の実験には利点もある。開発者は、企業調達が追い付く前に新製品を試せる。小規模なチームは、長い承認プロセスを待たずに有用なワークフローを見つけられる。

問題は、実験が期待に変わるときに始まる。経営側がその成果に依存し始めたなら、企業はアクセスと責任を正式に整備すべきだ。

個人による交渉力は弱いため、集団としての明確さが重要になる。ツールへの費用負担を拒む1人の開発者は、その異議が企業データを守り、公正な費用負担の境界を定めるものであっても、協力的でないように見えることがある。

チームは、AI利用が任意なのか、推奨なのか、必須なのかを明示すべきだ。これらの区分には運用上の意味が必要である。

任意利用とは、評価基準がアクセスを前提としないことを意味する。推奨利用とは、雇用主が承認済みの経路を提供する一方で、タスクに基づく拒否を認めることを意味する。必須利用とは、雇用主が必要なリソース、トレーニング、レビューのプロセスを提供することを意味する。

報酬についても注意が必要だ。AIによって1人の従業員が本当により価値の高い仕事を生み出せるなら、議論はより高いノルマで終えるべきではない。組織は、生産性向上が人員配置、賃金、業務量、キャリア開発にどう影響するかを決めなければならない。

そうでなければ、従業員は一方的な取引に直面する。成果を増やすために自ら支払い、雇用主は期待を引き上げ、節約された時間は追加業務に消えていく。

この構図は導入を損なう可能性がある。開発者がAIを監視、補償されない支出、雇用不安と結び付けるなら、防御的に利用するようになるかもしれない。ワークフローを隠し、利点を誇張し、失敗を報告しなくなる可能性がある。

信頼はより良いデータを生む。エージェントがどこで失敗するかを、評価を脅かされずに従業員が議論できるとき、企業はどのタスクに投資すべきかを学べる。

したがって、業界には技術的な枠組みと並んで労働に関する枠組みが必要だ。トークン効率、モデルルーティング、コード品質は重要だが、コスト配分と交渉力も同様に重要である。

トークン反発の後に注目すべきこと

従業員負担のAIが非公式な慣行として残るのか、それとも説明責任のある職場インフラになるのかは、3つの兆候が示す。

最初の兆候は調達方針である。雇用主は、どのコーディングツールに費用を出すのか、どのような利用制限があるのか、従業員が追加の利用枠をどう申請するのかを明示し始めるべきだ。

明確な費用精算ルールは、AIが標準的な事業投入物になったという見方を強める。沈黙が続けば、従業員は個人アカウントを通じてコストを負担し続けることになる。

企業がモデル選択をどう扱うかにも注目すべきだ。タスクに基づくルーティングのない固定の利用枠では、複雑なリポジトリを割り当てられた人を依然として不利にする可能性がある。公正なアクセスには、単に同一の上限を設けるだけでなく、例外に対応するプロセスが必要だ。

2つ目の兆候は、パフォーマンス測定である。企業は、トークン量、生成コード数、生のチケット処理速度から距離を置くべきだ。

エンドツーエンドの指標へ移行することは、より成熟した導入サイクルを示すだろう。関連する成果には、レビュー時間、不具合率、インシデントの影響、保守性、顧客価値が含まれる。

反対のシグナルは、利用量にひも付いたリーダーボードがさらに増えることだ。それは、AI利用が成果で評価されるツールではなく、コミットメントの代替指標になりつつあるという懸念を強める。

3つ目のシグナルは、ガバナンスの適用範囲である。雇用主は、承認済みアカウントをID管理、データ規則、追跡可能性、コードレビューと結び付けるべきだ。

個人利用がなくなることはない。本質的な問いは、企業が従業員の私用アカウントよりも安全で有用な、サポートされたワークフローを提供できるかどうかである。

ガバナンスの改善は、この論争に対する最も厳しい解釈を弱めるだろう。それは、雇用主が労働者に使わせたい技術に対する責任を受け入れていることを示す。

懲戒を巡る紛争、コード流出、隠れた個人アカウントが増加すれば、逆の方向を示す。それは、組織が必要な運用体制を整えないまま、AIに形作られた期待を課したことを示唆する。

識別可能な証拠が現れない限り、元のZhihuの主張は未検証として扱い続けるべきだ。匿名の議論を、プログラマーが解雇を避けるためにトークン利用枠を広く購入している証拠として提示する責任ある根拠はない。

ただし、この論争を退けることも、より大きな変化を見落とすことになる。AIコーディングツールは広く普及し、利用コストは可視化され、個人のアウトプットはAI支援を受ける同業者との比較で評価される場面が増えている。

開発者は、仕事に関わる利用枠に支払う前に、直接的な問いを投げかけるべきだ。そのツールは任意か。会社のデータを入力してよいのか。費用は精算されるのか。締め切りはその利用を前提としているのか。そこで生じたミスの責任は誰が負うのか。

エンジニアリングリーダーは、利用量の増加を歓迎する前に、こうした問いに答えるべきだ。AIが業務に不可欠なら、企業は費用を負担し、ガバナンスを整備すべきである。任意利用なら、評価制度はその選択を守らなければならない。

決定的な論点は、プログラマーがどれだけ多くのトークン単位を消費できるかではない。組織が、コスト、リスク、不安定さを実務を担う人々に転嫁することなく、AI活動を信頼できる価値へと変換できるかどうかである。