高性能モデルを使いすぎている部署の見つけ方
高性能（高単価）な生成AIモデルを、簡単な作業にまで使いすぎている部署やシステムを見つける方法を解説します。見つけるために必要なデータ（部署・キー・モデル別の費用）、偏りを見つける4つの指標、見つけた後の確認と切り替えの進め方、部署に伝えるときの注意点、再発を防ぐ仕組みまでをまとめました。
高性能なモデルを使いすぎている部署は、部署・APIキー・モデル別の費用を並べ、「費用に占める高単価モデルの割合」と「1回あたりの費用」を比べることで見つけられます。要約や分類など簡単な作業が中心のはずの部署で、高単価モデルの割合が高ければ、モデルの選び方を見直す余地があります。
ただし、高性能なモデルを使うこと自体が悪いわけではありません。用途に対して過剰かどうかを確かめ、必要十分なモデルに切り替えられるかを試すのが目的です。この記事では、必要なデータ、偏りを見つける指標、見つけた後の進め方を説明します。全体像は「生成AIコスト削減 完全ガイド」を参照してください。
見つけるために必要なデータ
| データ | 内容 | 取得元 |
|---|---|---|
| 部署・キー別の費用 | どの部署・システムがいくら使っているか | キーと部署の対応付け（組織マッピング）＋利用量 |
| モデル別の内訳 | 部署・キーごとに、どのモデルをどれだけ使っているか | プロバイダの利用量のデータ（キー × モデル） |
| 呼び出し回数 | 1回あたりの費用を出すため | 利用量のデータ（取れるプロバイダ） |
| 用途 | そのキー・部署が何に使っているか | キーの台帳、担当者への聞き取り |
キーを用途ごとに分けておくと、「このキーは議事録の要約用」と分かり、モデルの選び方が用途に合っているかを判断しやすくなります。用途が混ざったキーでは、高単価モデルの割合が高くても、どの用途のせいなのかが分かりません。
偏りを見つける4つの指標
| # | 指標 | 見方 |
|---|---|---|
| 1 | 高単価モデルの費用の割合 | 部署・キーの費用のうち、高単価モデルが占める割合。簡単な用途で高ければ要確認 |
| 2 | 1回あたりの費用 | 費用 ÷ 呼び出し回数。同じ用途の他部署・他キーより大きければ要確認 |
| 3 | モデルの構成の変化 | 前月と比べて高単価モデルの割合が急に増えていないか |
| 4 | 出力トークンの比率 | 出力が多い用途で高単価モデルを使っていると、費用が膨らみやすい |
指標の比べ方の例（架空の例）
| 部署 | 主な用途 | 月の費用 | 高単価モデルの割合 | 1回あたりの費用 |
|---|---|---|---|---|
| 開発部 | コードの作成・レビュー | 40万円 | 70% | 高い |
| 営業部 | 議事録の要約・メールの下書き | 15万円 | 85% | 高い |
| 管理部 | 社内規程の検索・要約 | 5万円 | 10% | 低い |
（数字は説明のための架空の例）
この例では、営業部は用途（要約・下書き）が比較的簡単なのに、高単価モデルの割合が高いため、見直しの候補になります。開発部は用途が複雑なため、高単価モデルの割合が高いこと自体は自然かもしれません。
見つけた後の進め方
| 手順 | やること |
|---|---|
| 1. 用途を確認する | 担当者に、どんな作業に使っているかを聞く |
| 2. 理由を聞く | 高性能なモデルを選んだ理由（品質の要件、初期設定のまま、など）を確認する |
| 3. 試す | 代表的な依頼で、安価なモデルの結果を比べる |
| 4. 判断する | 業務上許容できる品質なら切り替える。できなければそのまま |
| 5. 効果を確かめる | 切り替えの前後で、費用と品質を比べる |
よくある理由は、「最初に設定したモデルをそのまま使っている」ことです。品質の要件から選んだのではなく、導入時の初期設定や、試しに使った高性能なモデルが残っているケースが多くあります。新しいモデルが出たときに見直されず、古い高単価のモデルが使われ続けていることもあります。
用途とモデルの対応の目安
| 用途 | 求められる性能 |
|---|---|
| 要約・分類・定型文の作成 | 必要十分な性能のモデルで足りることが多い |
| 翻訳・文章の校正 | 用途と品質の要件による |
| 複雑な推論・分析・コードの作成 | 高性能なモデルが向くことが多い |
| 顧客向けの重要な回答 | 品質の要件に合わせて選ぶ |
目安であり、最終的には代表的な依頼での品質の比較で判断します。
部署に伝えるときの注意点
- 責めない: 高性能なモデルを使っていたことを責めると、利用が申告されなくなる
- 数字で示す: 高単価モデルの割合と、切り替えた場合の費用の見込みを示す
- 品質の確認を一緒に行う: 担当者に結果を比べてもらい、許容できるかを判断してもらう
- 選択肢を示す: すべてを切り替えるのではなく、簡単な作業だけ切り替える、などの選択肢を示す
再発を防ぐ仕組み
| 仕組み | 内容 |
|---|---|
| 用途ごとの推奨モデル | よくある用途ごとに、推奨のモデルを社内で共有する |
| 新しいキーの発行時の確認 | 用途と使うモデルを台帳に記録する |
| 月次の確認 | 部署・キーごとの高単価モデルの割合を月次で確認する |
| 構成の変化の通知 | 高単価モデルの割合が急に増えたときに気づけるようにする |
確認に使う表の作り方
月次の確認では、次のような表を作ると偏りが見えやすくなります。
| 列 | 内容 |
|---|---|
| 部署・キー | 集計の単位 |
| 主な用途 | 台帳や聞き取りから |
| 月の費用 | 概算（トークン数 × 単価） |
| 高単価モデルの割合 | 費用のうち高単価モデルが占める割合 |
| 前月からの変化 | 割合の増減 |
| 1回あたりの費用 | 取れるプロバイダのみ |
| 判断 | 維持／確認／切り替えを試す |
「判断」の列を毎月埋めると、確認が形だけで終わらず、切り替えの試行につながります。
切り替えの効果を確かめる
| 確かめること | 方法 |
|---|---|
| 費用 | 切り替えの前後1か月で、そのキー・部署の費用を比べる |
| 品質 | 代表的な依頼で結果を比べ、担当者に評価してもらう |
| 利用の変化 | 切り替え後に利用が減っていないか（使いにくくなっていないか） |
よくある質問
Q. 高単価モデルの割合が何%を超えたら見直すべきですか？ 一律の基準はありません。用途によって適切な割合が違うため、同じ用途の他部署・他キーと比べるか、前月と比べて急に増えていないかで判断します。
Q. 利用者ごとにモデルを選べる環境では、どう管理しますか？ 利用者ごとのモデル別の内訳を見て、偏りの大きい利用者に使い方を聞きます。推奨のモデルを示し、必要なときだけ高性能なモデルを使う運用を共有します。
Q. モデル別の内訳が取れないプロバイダもありますか？ 主要なプロバイダの利用量のデータは、モデル単位で取得できるのが一般的です。ただし、利用者個人やキー単位の内訳が取れるかはプロバイダによって違います（Azure OpenAI はデプロイメント、AWS Bedrock・Google Vertex AI はモデル単位まで）。部署単位で見たい場合は、デプロイメントやアカウントを部署ごとに分けておきます。
Q. 切り替えた後に品質の苦情が出たら？ すぐに元のモデルに戻せるようにしておき、どの依頼で品質が足りなかったかを確認します。その種類の依頼だけ高性能なモデルを使う、という振り分けも選択肢です。
まとめ
- 高性能モデルの使いすぎは、部署・キー・モデル別の費用を並べて見つける
- 指標は、高単価モデルの費用の割合、1回あたりの費用、モデル構成の変化、出力トークンの比率
- 見つけたら用途と理由を聞き、代表的な依頼で安価なモデルを試してから切り替えを判断する
- 責めずに数字で示し、推奨モデルの共有と月次の確認で再発を防ぐ
ManageAIは、部署・利用者・APIキー別の費用を可視化し、利用者の詳細画面やCSVでモデル別の内訳を確認できます。どの部署・キーが高単価モデルに偏っているかを見つけ、切り替えの前後の費用の変化も追えます。モニター企業を募集中です。
関連記事
次に読む
この記事を書いた人
モニター企業募集
初期費用0円・月額5万円（税別）
先着5社・2026年11月末まで
5プロバイダの利用量と費用を部署・利用者・APIキー別に可視化。読み取り専用キーの登録だけで当日から始められます。
募集要項を見る資料請求・お問い合わせ