AI利用料をどの部門が負担するか。共通費と個別費を分ける

AI費用の部門配賦では、利用人数による一律按分より、費用が生じた理由を基準にします。全社で使う共通契約、特定業務のための追加開発、出力やリスクを確かめる確認作業では、受益者も責任者も異なるからです。

基本線は、特定部門に帰属できる費用を個別費にし、複数部門にまたがる費用は中央予算で持つか、合意した基準で共通費として配賦することです。ただし、最も迷いやすいのは確認作業です。利用部門が行う業務上の確認と、AI推進・リスク管理などの共通機能が整える評価基準や独立レビューを同じ箱に入れると、責任と負担がずれます。

したがって、請求書を「契約」「変更」「確認」の作業単位に分解して負担先を決め、台帳に判断理由を残します。以下の判断表は、その合意をつくるためのたたき台です。

AI費用の部門配賦は「直接費か共通費か」から決める

FinOps FrameworkのAllocationは、コストを責任主体へ直接費または共通費として割り当て、アカウント構造、タグ、ラベル、派生メタデータなどで配賦先を識別する考え方を示しています。共通費は、中央予算で負担する項目と各コストセンターへ配賦する項目を併用でき、固定・比例・代理指標による可変配賦を選べるとしています（2026年9月21日確認）。

共通費は一律の扱いにそろえる必要がなく、費目ごとに方針を決められます。一方、取得できない利用データを前提にした精密な配賦式は運用できません。継続して識別できる情報だけを基準にします。

配賦方針には、少なくとも次を一組で記載します。

• 配賦単位：部門、予算単位、または中央予算のどれで管理するか
• 共通費の扱い：中央負担か、固定・比例・代理指標のどれで配るか
• 識別情報：契約所有者、利用部門、対象業務、作業項目など何を残すか
• 決定と承認：誰が案を作り、誰が承認し、誰が情報を保守するか
• 見直し契機：専用利用への変更、共通化、利用停止、確認方法の変更など何が起きたら再判定するか

この五点のどれかが空欄なら、配賦率より先に運用条件を埋めるべきです。

共通契約・追加開発・確認作業の配賦判断表

次の表は、上記の一般原則を基にした実務上の提案であり、FinOps FrameworkやNISTが定める所定の分類・義務ではありません。自社の管理会計方針や契約、税務・法務上の扱いを決めるものでもありません。

表では、負担先と判断条件を一組で決裁します。「どの条件に該当したため、その負担先にしたか」を台帳へ残して初めて、次の見直しができます。

共通契約は、取れる情報に合わせて配賦する

共通契約では、利用部門が複数あることだけを理由に、直ちに人数比などへ置き換えないことが肝心です。部門別の帰属を安定して識別できないなら中央予算、継続して取得できる利用・所有者情報があるなら合意した方法で部門配賦、専用部分を切り分けられるなら当該部門の個別費とします。

この区分は、費用管理上の責任を合わせるための提案です。会計処理の個別判断は、自社の管理会計方針や専門家への確認を踏まえて別途行います。固定・比例・代理指標のどれを採る場合も、基準名に加え、元情報、更新担当、欠損時の扱い、承認者を同じ記録に置きます。情報を保守できなくなった場合は、従来の配賦をいったん止め、中央負担を含めて再判定します。

全社導入前の対象業務や責任者がまだ曖昧なら、AI導入は何から始めるべきか｜中小企業の最初の90日で、社内ルール・最初の業務・効果の測り方を先に絞ると、配賦単位も決めやすくなります。

追加開発は、作業項目ごとに分ける

一つの改修成果物に、特定部門の専用要件と全社で再利用する基盤変更が同居することがあります。そのとき、成果物全体を個別費か共通費のどちらかへ寄せると、片方の責任が見えなくなります。要件や作業項目を分け、それぞれに負担先を記録します。

単一部門の業務要件に閉じる変更はその部門の個別費、複数部門が再利用する共通基盤の変更は中央予算または合意した共通費配賦とするのが判断の基本です。混在する場合は、「誰の要件か」「どこまでが再利用対象か」「誰が共通化を承認したか」を境界の記録にします。これはFinOpsの直接費・共通費と責任主体を識別する一般原則から導いた実務提案であり、原典所定の分類ではありません。

確認作業は、利用部門と共通機能の責任を分ける

確認作業をAI推進部門へ一括すると、業務上の正解を判断できる人と、費用を負担する部門が離れます。逆に利用部門へすべて寄せると、全社共通の評価基準、台帳、独立レビューを整える仕事の置き場がなくなります。

NIST AI RMF PlaybookのGovernは、リスク管理資源が有限であることを踏まえ、重要性の高い問題へ資源を振り向けるために、リスクの把握・測定・優先順位付けをガバナンスポリシーで明確にする考えを示しています。また、調達、開発、テスト・評価、影響評価、監督などの役割・責任を定義し、独立した軌道修正を可能にするため、開発機能とテスト機能を分ける方針を提案しています（2026年9月21日確認）。

さらに、NISTの生成AIプロファイルは、生成AIシステムの台帳に、人による監督の役割・責任、基盤モデル、モデルの版、アクセス方法などを含めることを提案しています。出力の正確性などを、既知の正解データ、人による監督、自動評価などで確認し、事実確認の方法を文書化する提案もあります（2024年7月26日公表、2026年9月21日確認）。

これらを負担判断へつなぐなら、業務上の正解や最終判断を確認する作業は利用部門、全社共通の評価基準・台帳・独立レビューを整備する作業はAI推進・リスク管理などの共通機能を負担候補とします。そのうえで、対象システムのリスク優先度、確認責任者、確認方法を台帳に残します。これも出典の一般原則を基にした実務提案で、NISTが費用負担区分を定めているわけではありません。

確認者や相談先を社内ルールへつなげる場合は、生成AIの社内ルール・利用ガイドラインの作り方【テンプレート付き】も参照してください。費用台帳と利用ルールでは同じ役割名を用い、確認者と承認者の対応関係を記録します。

配賦台帳は、金額より先に判断理由をそろえる

判断表を運用へ移す際は、一件につき次の項目を持つ簡潔な台帳から始めます。

• 費用・作業の区分：共通契約、追加開発、確認作業
• 対象：契約、システム、業務、作業項目
• 帰属：利用部門、要件所有者、共通機能の担当
• 判定：個別費、中央負担、共通費配賦
• 根拠：専用利用、再利用範囲、採用した配賦基準、リスク優先度
• 責任：決定者、承認者、識別情報の保守担当、確認責任者
• 見直し：再判定を起こす条件と変更理由

FinOps Frameworkの役割例では、財務が配賦先となる組織・予算単位と共通費の配賦割合を決め、リーダーシップが配賦と戦略を承認し、エンジニアリングが配賦用メタデータを整備・運用します（2026年9月21日確認）。自社の組織名へ置き換えても、決定、承認、情報保守を一人の暗黙知にしない点は残します。

最終合意には、共通契約の負担先に加え、再判定の手順まで含めます。追加開発が専用要件から共通基盤へ変わったとき、確認作業の優先度や責任者が変わったときに、誰が台帳を更新して再承認するかを決めます。これにより、AI費用の部門配賦を毎回の請求交渉から切り離し、条件が変わったときに見直す運用ルールへ移せます。