AIコーディング費用が月15万ドルまで膨らんだなら、「どのモデルを多く使ったか」より先に問うべきことがあります。そのお金で、約束したロードマップの何をリリースしたのかという問いです。
まず、数字の出所を分けます。月15万ドルは、Product HuntのユーザーがNavigaraに質問する際に言及したClaude請求額の規模であり、公開資料で検証されたNavigaraの顧客事例ではありません。一方、Navigaraが公開している製品機能は、Git履歴、Jira・Linear、AI支出を接続し、ロードマップ項目別コストと接続されていない作業を表示することです。 この記事では15万ドルを確定事例ではなく、大きな請求書をどう管理会計データに変えるかを説明する出発点として使います。
モデル別請求書だけを見ると、本当に高い理由を見逃します
モデル別コストは購入履歴であって、成果履歴ではありません。「Opusに6万ドル、Sonnetに5万ドルを使った」という表だけでは、決済改修が高かったのか、障害対応が高かったのか、中止した実験に資金が流れたのかは分かりません。
プロバイダーAPIが提供するデータも、おおむねこの境界で終わります。AnthropicのUsage & Cost APIは、使用量をモデル・ワークスペース・APIキーなどで分け、コストを日単位で取得できます。OpenAIの組織APIも、使用量とコストを取得し、プロジェクトIDなどでまとめられます。 このデータは請求書の照合には有用ですが、そのプロジェクトがどの製品目標を動かしたかは教えてくれません。
| 見る単位 | 答えられる質問 | 答えられない質問 |
|---|---|---|
| モデル・トークン | どのモデルでコストが発生したか？ | 何をリリースしたか？ |
| ユーザー・席 | 誰がツールを使ったか？ | その利用は必要な作業だったか？ |
| PR・コミット | どのコード変更と結び付いたか？ | 顧客やロードマップにどんな価値があったか？ |
| ロードマップ項目 | どの目標にいくらかかったか？ | その目標自体は正しかったか？ |
したがって、原価単位はモデルではなく、イニシアチブ・エピック・機能のようなコストオブジェクトであるべきです。Navigaraも、AI支出をイニシアチブ、プロジェクト、イシュー、PR、コミットにつなぎ、機能・保守・修正などに分類すると説明しています。 要点は特定の製品を買うことではありません。プロバイダーの請求データと実際のリリース記録の間に、追跡可能な接点を作ることです。
答えは「ドル→セッション→PR→イシュー→目標」の接続表です
ロードマップ原価は一度に計算できません。コストイベントがどの作業セッションで発生し、そのセッションが生んだ変更がどのイシューと目標に属するかを、順番に結び付ける必要があります。
自動接続の出発点は作業名の規則です。エージェントを実行するときにイシューキーを入れ、ブランチをENG-2917-checkoutのように作り、PR本文にも同じキーを残せば、3つのシステムを結合できます。直接API呼び出しを運用するなら、チームごとにワークスペースやプロジェクトを分けて最初のコスト境界を作れます。ただし、1つのセッションが複数のイシューに触れたり、共有席の費用が混ざったりする場合は、無理に1セント単位まで配賦せず、共通費として残すべきです。
GitHub Copilotも、組織・エンタープライズ・リポジトリ・ユーザー範囲の利用指標とPRライフサイクルデータを出力できます。ただしGitHubは、組織レベルの数値はメンバーシップ基準で帰属するため重複のように見えることがあり、異なるCopilot APIリソースを直接比較してはいけないと案内しています。 そのため、詳細な配賦を始める前に、プロバイダーダッシュボードの数値と自社元帳を月次請求総額に照合する必要があります。
「ロードマップ未接続 = 無駄」と自動判定してはいけません。
緊急障害対応、セキュリティパッチ、リファクタリング、探索的実験は、正当でもロードマップにない場合があります。Product HuntでNavigaraの創業者も、未接続の作業が必ずしも悪いわけではなく、必要だった理由を説明できるべきだと答えています。 未接続コストは無駄の確定額ではなく、分類が必要なキューとして扱うのが適切です。
実務では、コストを4つに分けると判断しやすくなります。1つ目はリリース済みのロードマップ作業、2つ目は承認済みの保守・リスク低減、3つ目は共通インフラや席などの共有費、4つ目は接続根拠のない未分類コストです。最後のグループだけを担当者が確認し、中止した実験、重複作業、漏れたチケットに再分類してください。
原価表には金額とともに信頼度・品質を付けるべきです
ロードマップ別のドル合計を1つ作るだけでは、別の虚栄指標になります。PR数やコミット数が増えても、価値が同じ比率で増えるとは限らないからです。Navigaraは、コミットをLLMとルールで評価した独自単位ETVを分母として提案していますが、これは同社が定義した独自指標です。公開された研究レポートも、分析は公開リポジトリのマージ済みコミットに限定され、コードレビュー・メンタリング・インシデント対応のような活動は観察できず、AI導入と成果の因果的な比率を算定しないと明記しています。
したがって、ETVであれ自社スコアであれ、単一の数字を真実のように扱わないでください。DORAもAIツールを評価する際、既存のデリバリー指標とともに、提案受諾率、モデル品質、信頼、レビュー時間などの補完指標を組み合わせるよう勧めています。 ロードマップ原価表には少なくとも次の3軸を併記すべきです。
たとえば、「決済改修のAI原価2万ドル」よりも、「直接接続1万4千ドル、共通費配賦4千ドル、推定2千ドル、計画より2週間早くリリース、デプロイ後の手戻り3件」というほうが、はるかに使える報告です。コスト削減を決めるときも、最も高いモデルから切るのではなく、未分類率が高く、手戻りも多い作業タイプを先に見られるからです。
今週、ロードマップ原価表を作る手順
1. プロバイダー請求額を1つの元帳に集める
Anthropicは組織向けの/v1/organizations/cost_reportと利用レポートを、OpenAIは/v1/organization/costsとUsage APIを基準に取得してください。API・Claude Enterprise・固定席のように課金方式が異なる項目は別の列に置き、月末合計が実際の請求書と一致するかをまず確認します。
2. イシューキーをすべての作業の共通識別子として必須にする
JiraやLinearでイニシアチブ→エピック→イシューの階層を整理し、エージェントプロンプト・ブランチ・コミット・PRのうち少なくとも2か所にイシューキーを残してください。緊急作業用のINC、保守用のMAINT、実験用のEXPタイプも作り、ロードマップ外の正当な作業が未分類に落ちないようにします。
3. 自動配賦と推定配賦を分ける
セッションIDや専用ワークスペースで直接接続されたコストは「確定」、時間帯・ユーザー・リポジトリだけが一致して推論したコストは「推定」、席と共用インフラは「共通費」と表示してください。1つのセッションが複数のイシューにまたがる場合は、変更ファイルや実行時間など事前合意した基準で分け、配賦ルールを元帳に残します。
4. 月次レビューでは3つの質問だけをする
「どの目標の単位原価が変わったか？」「未分類コストはなぜ発生したか？」「削減とともに手戻り・障害・レビュー時間も減ったか？」を確認してください。最初の月は正確なROIより直接接続率を高めることに集中し、個人別順位を人事評価に使わないでください。
こうして作れば、月15万ドルという数字は恐ろしい総額から意思決定可能なポートフォリオに変わります。高価なモデルを使ったという事実より、どのロードマップ項目にはもっと投資する価値があり、どの作業フローは接続と品質から直すべきかが見え始めます。
さらに深く知りたいなら
Navigara: Connect Your AI Spend Directly to Your Roadmap — 製品説明、創業者の測定方法、セキュリティ・未接続作業に関する回答を確認できます。 producthunt.com
Token Spend Intelligence · Navigara — モデルルーティング、コスト対作業単位、ロードマップ接続をNavigaraがどのように製品化しているかを示します。 navigara.com
Usage and Cost API - Claude Platform Docs — Anthropic組織の使用量・コスト照会の範囲とエンドポイントを確認できます。 platform.claude.com
Usage | OpenAI API Reference — OpenAI組織の使用量とコストデータをプロジェクトなどの基準で照会する公式APIドキュメントです。 developers.openai.com
Choosing measurement frameworks to fit your organizational goals — AI利用指標をデリバリー成果・品質・開発者体験とともに解釈すべき理由を説明します。 dora.dev
