FinOps for AI｜生成AI費用に固有の難しさと対処

FinOps for AI（AI FinOps）とは、クラウド費用の管理で確立したFinOpsの考え方を、生成AI APIの費用に適用することです。「見える化 → 最適化 → 運用」の循環と、技術・財務・事業部門が同じ数字で判断するという原則はそのまま使えます。

ただし、生成AIの費用にはクラウドのインフラ費用にはなかった性質があり、クラウドで使っていた道具をそのまま持ち込むと機能しない場面があります。この記事では、その違いを4つに整理し、それぞれの対処を示します。配賦全体の設計は「生成AIコストの部署別配賦（チャージバック）完全ガイド」を参照してください。

FinOpsの何がそのまま使えるか

FinOpsの中核は、次の3つの循環です。

生成AIでもこの順番は変わりません。特に「見える化が先で、最適化は後」という順番は重要です。何にいくら使っているかが分からない状態で削減策を打っても、効いたかどうかを確認できないからです。

もう1つ使えるのが、技術部門・財務・事業部門が同じ数字を見るという原則です。情シスは利用量を、経営企画は予算を、事業部門は成果を見ている状態では、費用の増加を「良い増加」か「無駄」か判断できません。同じダッシュボードとレポートを共有することが出発点になります。

固有の難しさ1: 変動が大きく、月末まで確定しない

クラウドのインフラ費用は、サーバーの台数や契約で大枠が決まり、月の途中でもおおよその着地が読めます。生成AI APIは従量課金で、1回の呼び出しの長さも回数も日によって変わります。

• 新しい社内ツールをリリースした週に呼び出し回数が数倍になる
• 検証チームが長い文書を大量に処理して、その日だけ費用が跳ねる
• リトライ設計の不備で、失敗した呼び出しが連鎖する

対処: 月次の予算管理だけでは遅すぎるため、日次と時間単位の監視を組み合わせます。日次コスト上限、月次予算の消化率、直近の急増検知の3種類のアラートで、請求書より先に気づける状態にします。急増検知は倍率だけでなく、下限のトークン数を併用して、深夜の小さな利用で鳴らないようにします。

固有の難しさ2: 粒度がプロバイダで違う

クラウドでは、リソースごとにタグを付けて部署やプロジェクトに配賦するのが基本です。生成AIでは、経路によって取得できる単位が異なります。

BedrockやVertex AIでは、「誰が使ったか」はモデル単位の集計からは分かりません。部署別に見たければ、AWSアカウントやGCPプロジェクトを部署ごとに分けておく必要があります。

対処: 粒度の限界を隠さず、最初に関係者と共有します。「全プロバイダで利用者別に見える」と約束すると、後で信頼を失います。キーが利用者に紐づかない経路では、リソース名やリージョン／モデルの組み合わせを疑似キーとして扱い、部署に対応付ける仕組み（組織マッピング）を作ります。詳細は「組織マッピングとは」で解説しています。

固有の難しさ3: 実費と概算が分かれる

クラウドの請求データは、リソース単位まで実費で取れます。生成AIでは、請求系API（Costs API・Cost Management・Cost Explorer・Cloud Billing）が返すのはプロジェクト・ワークスペース・リソース・リージョンの単位までで、APIキーや利用者の単位の実費は存在しません。

利用者別・キー別の費用を出すには、トークン数 × モデル別単価で計算する概算を使うしかありません。概算は単価改定やキャッシュの扱いで実費とずれます。

対処: 実費と概算を常に区別して表示し、混ぜません。全社・プロジェクト単位は実費で経理に提出し、部署別・利用者別は概算であることを明記して判断材料に使います。実費と概算の差を月次で突合し、差が急に広がったら単価改定や二重計上を疑う、という運用にすると、乖離が異常検知のシグナルにもなります（ManageAIでは、Azure・AWS Bedrockの実測で差は1〜1.8%でした）。

固有の難しさ4: タグが使えない経路がある

クラウドの配賦はタグ設計が中心です。ところがOpenAIやClaudeの直接利用には、リソースにタグを付ける仕組みがありません。あるのはAPIキーの名前と所有者、プロジェクト（ワークスペース）だけです。

対処: タグの代わりに、APIキーの命名規則と台帳で対応付けます。「部署略称-用途-環境」のような命名規則を決め、キーの発行時に台帳へ登録する運用にします。Azure・Bedrock・Vertex AIのようにタグやアカウント分離が使える経路では、クラウドのタグ設計をそのまま活かせます。

経路ごとに配賦の方式が混在することになりますが、それ自体は問題ではありません。「どの費用がどの方式で配賦されたか」を区別できていれば、経理と経営層への説明は成り立ちます。方式の選び方は「生成AIコストの配賦方法3パターン」にまとめています。

クラウドFinOpsの道具は、どこまで使い回せるか

クラウドで使っている道具を、生成AIにそのまま使えるかどうかを整理します。

「使えるが不十分」なものが多いのが特徴です。クラウドの道具を捨てる必要はありませんが、生成AI固有の補完（横断アラート・キー台帳・実費と概算の区別）を足す前提で設計します。

ユニットエコノミクスの考え方

FinOpsでは、費用を「1ユーザーあたり」「1トランザクションあたり」に割った単位コストで管理します。生成AIでは「問い合わせ1件あたり」「文書1本あたり」「コード生成1回あたり」がそれに当たります。

単位コストが出せると、費用の増加が「件数が増えた（良い増加）」のか「1件あたりが高くなった（見直し対象）」のかを切り分けられます。ただし分母となる業務件数は生成AIの利用量からは取れないため、業務システム側の件数と組み合わせる必要があります。まずは部署別・モデル別の費用が見える状態を作り、件数が取れる業務から単位コストを出していくのが現実的です。

最適化フェーズで生成AI固有の打ち手

見える化ができると、最適化の打ち手も生成AI固有のものになります。

クラウドの「インスタンスを小さくする」「予約購入する」に相当するのが、モデル選定と呼び出し設計です。どちらも、部署・キー・モデルの単位で内訳が見えていないと、どこに効かせればよいか分かりません。

運用フェーズ——誰が何を見るか

FinOpsでは、役割ごとに見る数字と責任を決めます。生成AIの場合は次のような分担が現実的です。

月次レビューでこの3者が同席し、「実績の確認 → アラートの振り返り → 次月の打ち手」の3議題を30分で回すと、専任がいなくても運用が続きます。

よくある質問

Q. クラウドのFinOpsチームがそのまま生成AIも担当できますか？ できます。ただし、実費と概算の区別、プロバイダごとの粒度差、タグが使えない経路の3点は、クラウドの経験がある人ほど見落としやすいポイントです。最初にこの3点を共有しておくと、既存の運用に自然に組み込めます。

Q. 生成AIの費用は全社のクラウド費用と一緒に管理すべきですか？ 経営報告では一緒に見せて構いませんが、収集と配賦の仕組みは分けた方が運用しやすいです。生成AIはクラウド外の経路（OpenAI・Claudeの直接利用）を含み、クラウドの請求データだけでは全体像が出ないためです。

Q. 最適化から始めてはいけませんか？ 効いたかどうかを確認できないため、お勧めしません。モデルの切り替えやプロンプトの短縮は、部署・モデル別の費用が見えてから行うと、効果を数字で示せます。

まとめ

• FinOpsの「見える化 → 最適化 → 運用」の循環と、関係者が同じ数字を見る原則は、生成AIにもそのまま使える
• 固有の難しさは4つ。変動の大きさ（→ 日次・急増のアラート）、粒度差（→ 限界を開示し疑似キーで対応付け）、実費と概算の分離（→ 混ぜずに突合）、タグが使えない経路（→ 命名規則と台帳）
• 最適化はモデル選定・プロンプト・呼び出し設計・運用の4層。見える化なしには効かせどころが分からない
• 運用は情シス・経営企画・事業部門の3者が同じダッシュボードを見る体制で回す

ManageAIは、5プロバイダの利用量と費用を横断して取得し、組織マッピングで部署・利用者・プロジェクト・APIキー別に可視化します。実費と概算を区別して表示し、3種のアラートで請求書より先に気づけます。読み取り専用キーの登録だけで導入でき、通信経路には介在しません。現在、モニター企業を募集中です。

関連記事

• 生成AIコストの部署別配賦（チャージバック）完全ガイド｜FinOpsの考え方で設計する
• 組織マッピングとは｜APIキーと部署を紐づける設計の基本
• 生成AIの利用料、「誰が・いくら使ったか」から始める部署別コスト管理