ソフトウェア業界は何十年もの間、間違ったものを測り続けてきた。
開発者が非生産的だからではない——測定ツールが思考ではなく活動を捉えているからだ。作業時間、コミット数、完了したストーリー。すべて数えられ、すべて可視化されているが、問題がどれだけうまく解決されたかを理解するうえではほとんど意味がない。
AIは開発を加速するためだけに登場したわけではない。予期せぬものをもたらした：新しいシグナルだ。言語モデルとのすべての作業セッションは定量化可能な痕跡——トークン消費量——を残す。これにより、初めてタスクの背後にある実際の認知的努力を垣間見ることができる。
どんな方法論でも答えられない問い
フリーランスで開発しているか、コンサルティングチームを率いているかにかかわらず、すべてのプロジェクトで繰り返し登場し、ほとんど満足のいく答えが得られない問いがある：
これにいくら請求すればいい？
これはビジネスの問いではない。ビジネスの問いに見せかけた技術的な問いだ。適切に答えるには、問題の実際の複雑さを見積もる必要がある——そこですべてが複雑になる。
業界はさまざまな方法を試みてきた。工数：理論上は合理的だが、効率よく働く人を罰する不公平な実践。ストーリーポイント：チームの内部計画には有用だが、クライアントへの価格に翻訳するのが難しい。機能ごとの固定価格：クライアントには快適だが、開発者にはリスクが高い。
すべてに共通する根本的な問題がある：誰も客観的に測定できなかったもの——ソフトウェア問題の実際の複雑さ——への主観的な近似にすぎない。
AIはそれを変えるかもしれない何かをもたらしている。
なぜ複雑さは測定が難しいのか
2つのタスクは表面上似て見えても、深さでは根本的に異なる場合がある。
「登録フォームにフィールドを追加する」は簡単に聞こえる。しかし、そのフォームが3つのレガシーシステムに接続され、4つのレイヤーにバリデーションがあり、ビジネスルールを誰もドキュメント化していなければ、実際のタスクは外から見えるものとは無関係だ。
従来の指標はそれを捉えない。時間は経過時間を測るが、実際の難しさは測らない。ストーリーポイントはグループ見積もりを反映する。経験は助けになるが、スケールしない。
常に欠けていたのは、事前見積もりからではなく、作業そのものから生まれるシグナルだ。
トークン：とは何か、何を表すのか
AIモデルとのすべてのインタラクションはトークンを消費する。実際にトークンが表すものが重要だ：
- 問題が必要とするコンテキスト ——AIが何を解決するかを理解するためにどれだけ説明が必要か
- 推論の深さ ——複雑な問題はより長い応答を生成し、より多くの反復を必要とする
- 調整の回数 ——各修正、訂正、後退がトークンを追加する
具体例：データベースの初期スキーマ生成は約2,000トークンを消費する可能性がある。分散システムの並行性エラーのデバッグは50,000に達する可能性がある。この差は恣意的ではない——実際の複雑さを反映している。
浮かび上がるパターン：複雑さと消費量
AIでの作業履歴が十分に蓄積されると、完璧ではないが有意な相関関係が現れる：
| レベル | タスク種別 | 推定トークン数 | 例 |
|---|---|---|---|
| 1 – 運用 | 低不確実性 | 500〜2,000 | 基本的なCRUD、シンプルなスクリプト |
| 2 – 機能 | 中程度の変動性 | 5,000〜20,000 | API統合、ビジネスロジックを持つモジュール |
| 3 – システム | 高不確実性 | 20,000〜100,000+ | アーキテクチャ、複雑なデバッグ、深いリファクタリング |
これは固定ルールではない。独自の履歴があれば、これらの範囲は調整され、予測可能になる。
3つのレベルの詳細
レベル1 – 運用：低不確実性。問題は明確に定義されており、解決策には明確な経路がある。AIは追加のガイダンスをほとんど必要とせず実行する。変動が小さいため、このレベルが最も見積もりやすい。
レベル2 – 機能：中程度の変動性。設計上の決定が関与し、システムのコンテキストが必要だ。AIは代替案を提案し、開発者が誘導、却下、調整する。ここでトークン消費は決定の反復という価値あるものを反映し始める。
レベル3 – システム：高不確実性。問題が不明確に定義されているか、複数のシステムが関与するか、文書化されていない依存関係がある。従来の方法では見積もりが最も難しいレベルで、トークンがシグナルとして最も価値を提供する。
このモデルは経験に取って代わるものではない——補完するものだ。シニア開発者はレベル3をより少ないトークンでナビゲートする。なぜなら、最初から問題を適切にフレーム化する方法を知っているからだ。
トークンから価格へ：履歴を活用する方法
トークン消費量を測定する真の価値は単一のタスクにあるのではなく——蓄積された履歴にある。
3週間、完了したタスクごとの消費量を記録したとする：
- 第1週：8タスクで180,000トークン → 平均 約22,500/タスク
- 第2週：11タスクで210,000トークン → 平均 約19,000/タスク
- 第3週：10タスクで195,000トークン → 平均 約19,500/タスク
週に約200,000トークン、タスクあたり平均約20,000トークンという測定可能な生産能力がわかる。12の機能を持つ新しいプロジェクトが来たら、それらをレベルで分類し、予想される総消費量を履歴と照合して予測できる。
変わるモデル：時間から解決された価値へ
従来のモデル
価格 = 時間 × 単価
このモデルには根本的な問題がある：効率を罰する。2時間で解決する人は8時間かかる人より少ない請求になる。たとえ提供された価値が同一でも。
新しいアプローチ
価格 = 複雑さ × 解決能力
複雑さは問題によって決まる。解決能力は開発者——使用するツールとその使い方を含む——によってもたらされる。レベル3の問題は、AIを適切に使って6時間で解決されるか、AIなしで6日かかるかに関係なく、実際の難しさを反映した価格を持つ。
トークンは単独でこのモデルを実装するわけではないが、価格交渉をより確かなものにする証拠を提供する。
トークンが解決しないこと
すべての消費が価値を反映するわけではない。不適切に設計されたプロンプトは多くのトークンを生成するが結果は少ない。消費は複雑さと同様に非効率性の症状である場合もある。
経験は依然として最も重要な変数だ。シニア開発者はレベル3の問題をジュニアより少ないトークンで解決する。問題が単純だからではなく、最初から適切にフレーム化する方法を知っているからだ。
AIモデルは急速に進化している。今日30,000トークンを必要とするものが、6ヶ月後には8,000で解決できるかもしれない。履歴はツールの改善に合わせて更新する必要がある。
クライアントとの対話を代替しない。最終的に、価格設定は交渉でもある。トークンデータは議論を提供するが、自動的な答えではない。
チームへのオープンな問い
- プロジェクトを見積もる前に複雑さを測定しているか、それとも見積もってから複雑さを発見するのか？
- 現在の価格設定のうち、独自データに基づくものと蓄積された直感に基づくものはそれぞれどれくらいか？
- AIが数日を数時間に圧縮できることをクライアントが理解したとき、時間制モデルはどうなるか？
- プロジェクトの価格は投資した時間を反映すべきか、解決された問題を反映すべきか？
- 今日トークン消費量を記録しているか、それとも明日より良い決定を下すための貴重なデータを見逃しているか？
結論
「これにいくら請求すればいい？」は引き続き難しい問いだろう。今より良いツールがあるからといって、ソフトウェアの複雑さが消えるわけではない。
しかし初めて、作業そのものから生まれる定量化可能なシグナルがある。トークン消費は問題を解決するのに関与した実際の認知的努力の痕跡を残す。
これは数式ではない。今日は持っていない履歴を構築するための出発点だ——そして1年後には、自信を持って見積もるか、引き続き推測し続けるかの違いになりうる。