SIerに任せた生成AI基盤で費用が見えなくなる問題
生成AIの社内基盤の構築・運用を外部のベンダー（SIer）に任せたときに、費用の内訳が見えなくなる問題を解説します。見えなくなる4つの理由（契約・アカウントの持ち方・キーの設計・報告の粒度）、発注前に決めておくべきこと、すでに見えなくなっている場合の取り戻し方までをまとめました。
生成AIの社内基盤（社内チャットや業務システムへの組み込み）の構築・運用を外部のベンダー（SIer）に任せると、費用の合計は分かっても、部署別・用途別の内訳が見えなくなることがよくあります。ベンダーが悪いのではなく、クラウドのアカウントの持ち方、APIキーの設計、報告の粒度を、発注の段階で決めていないことが原因です。
費用の見え方は、後から変えるのが難しい部分です。この記事では、見えなくなる理由、発注前に決めておくべきこと、すでに見えなくなっている場合の取り戻し方を説明します。全体像は「生成AIの全社導入 完全ガイド」を参照してください。
費用が見えなくなる4つの理由
| # | 理由 | 起きること |
|---|---|---|
| 1 | 契約の形 | 生成AIの利用料が、ベンダーの運用費に含まれた一括の請求になる |
| 2 | アカウントの持ち方 | クラウドのアカウントや API の組織を、ベンダー側が所有している |
| 3 | キーの設計 | 全部署・全用途で1本の APIキー（または1つのデプロイメント）を共用している |
| 4 | 報告の粒度 | 月次の報告が「全体の利用料」だけで、部署別・用途別の内訳がない |
1. 契約の形
生成AIの利用料がベンダーの請求に含まれていると、請求書には「基盤の利用料」として一行で載るだけになります。どれだけが生成AIの利用料で、どれだけが運用の費用なのかも分かりにくくなります。
2. アカウントの持ち方
クラウド（Azure・AWS・Google Cloud）のアカウントや、OpenAI・Anthropic の組織をベンダーが所有していると、自社から利用量や費用のデータに直接アクセスできません。内訳を知るには、毎回ベンダーに依頼することになります。
3. キーの設計
構築を早く進めるため、全部署・全用途で1本のキーや1つのデプロイメントを共用する設計にされることがあります。この設計では、プロバイダの利用量のデータにも部署の区別が残らないため、後から部署別に分けることができません。
4. 報告の粒度
運用の報告が月1回の全体の利用料だけだと、月の途中の増加にも気づけず、部署別の予算も立てられません。
見えなくなると困ること
| 困ること | 内容 |
|---|---|
| 部署別の費用が出せない | 配賦・予算の配分ができない |
| 効果と比べられない | 部署・用途ごとの投資対効果が示せない |
| 急増に気づけない | 月次の報告を待つまで、費用の増加が分からない |
| 見直しの判断ができない | 使われていない用途や、高価なモデルの使いすぎが分からない |
| ベンダーを替えにくい | 利用のデータとアカウントがベンダー側にあり、移行が難しい |
発注前に決めておくべきこと
費用の見え方は、発注の段階で要件として書いておくことが大切です。
| 決めること | 要件の例 |
|---|---|
| アカウントの所有 | クラウドのアカウント（サブスクリプション・プロジェクト）と API の組織は自社が所有し、ベンダーには構築・運用の権限を付与する |
| 利用料の請求 | 生成AIの利用料は、プロバイダ（クラウド）から自社に直接請求される形にする。ベンダーの費用とは分ける |
| キー・デプロイメントの設計 | 部署・用途・環境（本番・検証）ごとに、APIキーやデプロイメントを分ける |
| 利用量データへのアクセス | 自社が利用量・費用のデータを、読み取り専用の権限でいつでも取得できるようにする |
| 報告の内容 | 月次で、部署別・用途別・モデル別の利用量と費用を報告する |
キー・デプロイメントを分ける単位
| プロバイダ | 分ける単位 |
|---|---|
| OpenAI・Claude | 部署・用途ごとに APIキー（またはプロジェクト・ワークスペース）を分ける |
| Azure OpenAI | 部署・用途ごとにデプロイメント（またはリソース）を分ける |
| AWS Bedrock・Google Vertex AI | 部署・用途ごとにアカウント・プロジェクトを分ける |
分ける単位を最初に決めておけば、プロバイダの利用量のデータに部署・用途の区別が残り、後から部署別の費用を出せます。粒度の考え方は「生成AI利用状況の粒度はプロバイダで違う」を参照してください。
すでに見えなくなっている場合の取り戻し方
| 手順 | やること |
|---|---|
| 1. 現状を確認する | アカウント・組織の所有者、キー・デプロイメントの構成、請求の形をベンダーに確認する |
| 2. データへのアクセスを得る | 自社が利用量・費用のデータを読み取れる権限を、ベンダーに付与してもらう |
| 3. 分けられる単位を探す | 既存のキー・デプロイメントのうち、部署や用途に対応するものを特定する |
| 4. 新しい利用から分ける | 新しい部署・用途の追加時は、キー・デプロイメントを分けてもらう |
| 5. 契約の見直し時に直す | 次の契約更新で、アカウントの所有と請求の形を要件に入れる |
すべてを一度に直すのは難しいため、まず自社がデータを読める状態を作り、新しい利用から分けるところから始めます。共用のまま残る部分は、利用者数などで按分するルールを決めて扱います。
ベンダーとの役割分担
| 役割 | 自社 | ベンダー |
|---|---|---|
| アカウントの所有 | ○ | |
| 基盤の構築・運用 | ○ | |
| キー・デプロイメントの設計 | 分ける単位を決める | 設計・実装する |
| 費用の把握 | 利用量データを自社で見る | 報告を補助する |
| 部署への配賦・予算 | ○ |
「作る・動かす」はベンダー、「持つ・見る・決める」は自社と分けると、ベンダーに任せながら費用の主導権を自社に残せます。
発注時の要件の書き方の例
提案依頼書や仕様書に、費用の見え方の要件として次のように書きます。
生成AIの利用に係るクラウドのアカウント（またはサブスクリプション・プロジェクト）および API の組織は、当社名義で契約・所有するものとし、受託者には構築・運用に必要な権限を付与する。生成AIの利用料は、提供元から当社に直接請求されるものとする。APIキー（またはデプロイメント・アカウント）は、当社が指定する部署・用途・環境の単位で分けて設計すること。当社が利用量および費用のデータを読み取り専用の権限で取得できるようにすること。月次の報告には、部署別・用途別・モデル別の利用量と費用を含めること。
要件として書いておけば、提案の段階で費用の見え方を比較できるようになります。
定例会議で確認すること
基盤の運用が始まったら、ベンダーとの定例会議で次を確認します。
| 確認すること | 見るもの |
|---|---|
| 部署別・用途別の費用 | 自社で取得した利用量データ、またはベンダーの報告 |
| 新しいキー・デプロイメント | 追加されたものが、決めた単位で分かれているか |
| 共用のまま残っている部分 | 分割の予定と、それまでの按分の方法 |
| 次の月の見込み | 利用の拡大予定と、費用の見込み |
よくある質問
Q. ベンダーから「アカウントはこちらで持つほうが運用しやすい」と言われました。 運用のしやすさと、費用の透明性・移行のしやすさのバランスで判断します。少なくとも、自社が利用量・費用のデータを読み取れる権限と、部署別の報告は要件に入れます。
Q. 部署別の報告をベンダーに求めると、費用が上がりませんか？ 手作業の集計を求めると、その分の費用がかかる場合があります。キー・デプロイメントを部署ごとに分け、自社が読み取り専用の権限でデータを取得できるようにすれば、報告の手間を増やさずに済みます。
まとめ
- SIer に任せた生成AI基盤で費用が見えなくなるのは、契約・アカウントの所有・キーの設計・報告の粒度を発注時に決めていないため
- 発注前に、アカウントの自社所有、利用料の直接請求、部署・用途ごとのキーの分離、データへのアクセス、報告の内容を要件にする
- すでに見えない場合は、データへのアクセスを得て、新しい利用から分け、契約更新で直す
- 「作る・動かす」はベンダー、「持つ・見る・決める」は自社に残す
ManageAIは、読み取り専用の認証情報を登録するだけで、5プロバイダの利用量と費用を部署・用途別に可視化します。基盤の構築・運用をベンダーに任せている場合も、読み取り専用の権限を付与してもらえば、自社で費用の内訳を確認できます。モニター企業を募集中です。
関連記事
次に読む
この記事を書いた人
モニター企業募集
初期費用0円・月額5万円（税別）
先着5社・2026年11月末まで
5プロバイダの利用量と費用を部署・利用者・APIキー別に可視化。読み取り専用キーの登録だけで当日から始められます。
募集要項を見る資料請求・お問い合わせ