生成AIをWebシステムや業務システムへ組み込むとき、運用開始後に気になるのがAI APIの利用料金です。
「PoCでは安かったのに、本番運用したらAPI料金が増えた」
「毎回大量の社内文書をAIへ渡している」
「高性能なAIモデルをすべての処理に使っている」
「AIエージェントが何度もAPIを呼び出してコストが読めない」
このような問題は珍しくありません。
生成AI APIの料金は一般的に、
入力トークン
+
出力トークン
+
場合によっては追加機能
によって決まります。
そのため、
APIを使う回数を減らす
だけがコスト削減ではありません。
重要なのは、
適切なモデルを使う
不要な入力を減らす
不要な出力を減らす
同じ情報を何度も処理しない
リアルタイム処理が不要ならBatchを使う
AIを使わなくてもよい処理をAIから外す
ことです。
実際、現在のOpenAI APIでも同じGPT-5.6系の中に複数の価格・性能帯のモデルがあり、入力・出力単価には大きな違いがあります。つまり「とりあえず最上位モデルを使う」設計は、そのまま運用コスト増加につながります。
この記事では、生成AI APIのコストを削減する具体的な方法を、Webシステム・RAG・AIエージェントなどの実装を想定して解説します。
生成AI APIの料金は何で決まる？
まず基本構造を理解しておきます。
テキスト生成AIの場合、主に、
入力トークン
+
出力トークン
によって課金されます。
入力トークンとは、
システムプロンプト
ユーザーの質問
会話履歴
RAGで取得した文章
Tool定義
その他のコンテキスト
などです。
出力トークンはAIが生成した、
回答
要約
JSON
文章
コード
などです。
APIレスポンスでは入力・出力・キャッシュされたトークンなどの使用量を確認できるサービスもあり、これらを記録することでコスト分析ができます。
AI APIコスト削減で最初に確認する4つの数字
最初に次を計測します。
1．API呼び出し回数
2．平均入力トークン
3．平均出力トークン
4．モデル別利用量
例えば、
月10万リクエスト
平均入力：
5,000 tokens
平均出力：
1,000 tokens
なら、
入力：
5億tokens
出力：
1億tokens
を毎月処理していることになります。
ここから、
入力を30％削減
出力を20％削減
できるだけでも大きな差になります。
1．用途ごとにAIモデルを使い分ける
最も効果が大きくなりやすい方法です。
例えば、
問い合わせ分類
と、
複雑な契約書の分析
で同じ高性能モデルを利用する必要はありません。
業務を、
簡単
中程度
複雑
に分類します。
例えば、
| 処理 | モデル |
|---|---|
| メール分類 | 軽量モデル |
| 項目抽出 | 軽量モデル |
| 簡単な要約 | 軽量モデル |
| 顧客向け文章 | 標準モデル |
| 複雑な分析 | 高性能モデル |
| 難しい推論 | 高性能モデル |
とします。
現在のOpenAI APIでも、同一世代のモデルに複数の価格帯が用意されています。価格は更新されるため具体的な料金は公式情報を確認する必要がありますが、モデル選択そのものがコスト設計の重要な要素であることが分かります。
「最高性能モデルを全部に使う」をやめる
例えば問い合わせ分類が、
請求
解約
営業
不具合
その他
の5分類だけなら、最上位モデルは過剰かもしれません。
そこで、
通常
↓
軽量モデル
↓
判定不能
↓
高性能モデル
という構成もできます。
これをモデルルーティングとして実装できます。
2．入力トークンを減らす
AI APIでは、毎回AIへ大量の情報を送信するとコストが増加します。
ありがちな構成が、
ユーザー：
商品の返品期限は？
↓
AIへ
会社概要
商品一覧
返品規程
配送規程
利用規約
FAQ
問い合わせ履歴
その他マニュアル
↓
回答
です。
質問に必要なのが返品規程だけなら、その他の文章を送る必要はありません。
必要な情報だけ取得する
そこで、
質問
↓
検索
↓
必要な情報だけ取得
↓
生成AI
とします。
これがRAGを利用するメリットの一つでもあります。
例えば、
全社文書：
100万tokens
あったとしても、質問ごとに、
関連する3〜5チャンク：
5,000tokens
程度だけAIへ渡せば、入力コストを大きく抑えられます。
3．RAGの取得件数を増やしすぎない
RAGだから自動的に低コストになるわけではありません。
例えば、
top_k = 50
として50件の文書断片を毎回AIへ渡すと、入力トークンが増えます。
まず、
top_k = 3〜10
程度の必要十分な範囲を検証します。
重要なのは、
たくさん渡せば精度が上がる
とは限らないことです。
関係のない文章が増えることで、逆に回答品質が落ちる場合もあります。
4．会話履歴を毎回全部送らない
チャットシステムでよくある問題です。
例えば100回会話すると、
1回目
+
2回目
+
3回目
...
+
100回目
を毎回送る設計があります。
会話が長くなるほど入力トークンが増加します。
そこで、
直近10メッセージ
+
それ以前の要約
のようにします。
例えば、
過去80メッセージ
↓
AIで一度要約
↓
1,000tokens程度に圧縮
して保存します。
その後は、
会話要約
+
直近メッセージ
だけ送信します。
5．システムプロンプトを長くしすぎない
企業向けAIでは、システムプロンプトが長くなることがあります。
例えば、
あなたは〜
ルール1〜
ルール2〜
例1〜
例2〜
例3〜
と増え続け、
毎回10,000tokens
送信しているケースです。
1回なら大きな問題でなくても、
1日10,000回
実行されれば、
10,000tokens
×
10,000回
=
1億tokens／日
になります。
必要な指示だけ残し、
不要な説明
重複した例
冗長な文章
を削除します。
ただし、
短くすればよい
わけでもありません。
プロンプトを削りすぎて精度が落ち、人による修正時間が増えれば本末転倒です。
6．Prompt Cachingを活用する
同じ長い入力を何度も利用する場合は、Prompt Cachingを利用できるサービスがあります。
例えば、
共通システムプロンプト
+
商品マニュアル
+
Tool定義
+
ユーザーごとの質問
という構成です。
毎回変わるのは、
ユーザーごとの質問
だけかもしれません。
この場合、
共通部分
↓
キャッシュ対象
変動部分
↓
毎回追加
という設計が有効です。
OpenAIではPrompt Cachingにより、再利用される入力トークンに対して通常入力とは異なるキャッシュ料金が適用される仕組みがあります。また、キャッシュされたトークン数はAPI利用量から確認できます。
Google Gemini APIにもContext Cachingがあり、同じ大きなコンテキストを繰り返し利用するワークロード向けにキャッシュされた入力の料金体系が用意されています。
キャッシュしやすいプロンプト構成にする
例えば、
共通ルール
↓
共通資料
↓
Tool定義
↓
ユーザー固有情報
↓
今回の質問
のように、
固定部分
→ 前半
変動部分
→ 後半
へ配置します。
毎回プロンプト前半まで変更すると、キャッシュを活用しにくくなる場合があります。
7．リアルタイム不要ならBatch APIを使う
すべてのAI処理が即時回答を必要とするわけではありません。
例えば、
過去10万件の問い合わせ分類
商品説明文の一括生成
大量データの要約
Embedding作成
AI評価
などです。
これらは、
夜間処理
でも問題ない場合があります。
その場合はBatch処理を検討します。
OpenAIのBatch APIは非同期処理向けで、現在は同期APIに対して50％の料金割引が提供され、処理は最大24時間のウィンドウで実行されます。
Google Gemini APIでもPaid TierでBatch APIが提供されており、Standardと比較して50％低い料金設定のモデルがあります。
Batch向きの処理
例えば、
○ 夜間レポート
○ 大量分類
○ Embedding生成
○ 評価データ処理
○ 定期要約
です。
一方、
顧客チャット
のようなリアルタイム応答には向きません。
8．出力を必要以上に長くしない
AI APIでは入力だけでなく出力にも料金がかかります。
例えば、
問い合わせカテゴリだけ知りたい
のに、
この問い合わせは請求カテゴリに分類されます。
その理由は〜
さらに考えられる可能性として〜
と長文を生成する必要はありません。
必要なのが、
billing
だけなら、その値だけ返します。
Structured Outputで必要な項目だけ返す
例えば、
{
"category": "billing",
"priority": "high"
}
だけで十分なら、余計な説明文を生成させません。
これによって、
出力トークン削減
+
システム処理しやすい
というメリットがあります。
9．最大出力サイズを制限する
ユーザーが、
詳しく説明して
と入力した結果、数千トークン生成することがあります。
そこで用途に応じて、
要約：
300文字程度
メール：
500文字程度
分類：
JSONのみ
などと制限します。
またAPI側でも最大出力トークンを設定できる場合があります。
10．AIを使わなくてもよい処理をAIから外す
コスト削減では非常に重要です。
例えば、
売上合計
消費税計算
日付比較
在庫数確認
ステータス判定
はAIを使う必要がありません。
例えば、
今日が支払期限を過ぎているか？
なら、
通常プログラム
で判定できます。
AIに、
本日は2026年7月30日です。
支払期限は2026年7月20日です。
期限を過ぎていますか？
と問い合わせる必要はありません。
AIと通常プログラムを分ける
例えば、
メールを理解する
→ AI
日付計算
→ プログラム
顧客検索
→ DB
金額計算
→ プログラム
返信文章
→ AI
とします。
生成AIは、
自然言語理解
要約
文章生成
曖昧な分類
など、本当に必要な部分だけに使います。
11．同じAI処理を繰り返さない
例えば商品説明を生成するシステムで、
商品A
↓
AI生成
ページを再表示
↓
もう一度AI生成
再表示
↓
またAI生成
となっていると無駄です。
一度生成した結果を、
DB
Redis
キャッシュ
などへ保存します。
そして、
商品情報が変更されたときだけ
再生成
とします。
AI結果そのものをキャッシュする
例えば、
FAQ：
返品期限は？
という質問が大量にあるなら、
質問
↓
正規化
↓
キャッシュ確認
↓
存在すれば回答
↓
なければAI
という構成もできます。
Prompt Cachingとは別に、アプリケーション側の回答キャッシュを持つ考え方です。
12．Embeddingを毎回作り直さない
RAGでは文書をEmbeddingへ変換します。
しかし、
質問のたびに
全社文書をEmbedding
する必要はありません。
基本的には、
文書登録・更新
↓
Embedding生成
↓
Vector DB保存
です。
質問時には、
質問だけEmbedding
↓
Vector DB検索
とします。
文書が更新された部分だけ再Embeddingすれば十分です。
13．差分更新する
例えば毎晩Google DriveをRAGへ同期するとします。
1万ファイル
↓
毎日全部Embedding
ではなく、
updated_at
などを利用して、
昨日以降に変更された50ファイル
だけ処理します。
構成は、
Drive
↓
更新ファイル確認
↓
変更あり
↓
再解析
↓
Embedding
↓
Vector DB更新
です。
14．AIエージェントのループ回数を制限する
AIエージェントは通常のチャットよりAPI料金が増えやすい傾向があります。
例えば、
ユーザー
↓
AI
↓
Tool
↓
AI
↓
Tool
↓
AI
↓
Tool
↓
AI
↓
回答
と、一つの依頼でも複数回AIを呼び出すからです。
さらに判断に迷うと、
検索
↓
再検索
↓
再検索
を繰り返す可能性があります。
そこで、
最大ステップ数
最大Tool実行数
最大Token
最大再試行回数
を設定します。
エージェントに全部考えさせない
例えば、
顧客IDを探す
↓
AIが検索方法を考える
より、
get_customer(customer_id)
というToolを用意した方が簡単です。
Tool設計を明確にすると、
AIが試行錯誤する回数
を減らせる可能性があります。
15．失敗時の無限リトライを防ぐ
APIエラーが発生したとき、
失敗
↓
Retry
↓
失敗
↓
Retry
↓
失敗
↓
Retry...
となると、コストや負荷が増えます。
例えば、
最大3回
指数バックオフ
一定回数失敗したら終了
とします。
また、
AIがJSON形式を守らない
↓
もう一度AI
を何度も繰り返す構成も避けます。
可能ならStructured OutputやJSON Schemaなどを利用して、最初から形式を制約します。
16．前処理でデータを小さくする
例えば100ページのPDFから、
契約金額だけ知りたい
とします。
毎回100ページ全部をAIへ渡す必要はありません。
PDF
↓
テキスト抽出
↓
「契約金額」周辺を検索
↓
関連部分だけAI
とします。
AI OCRでも、
画像
↓
OCR
↓
必要部分抽出
↓
LLM
という構成にできます。
17．大きい画像・PDFを無条件にAIへ送らない
マルチモーダルAIでは、画像やPDFも入力コストになります。
例えば、
100ページPDF
から1ページだけ必要なら、
PDF全体
↓
AI
ではなく、
対象ページ抽出
↓
AI
とします。
資料検索・OCR・ページ判定などを先に行うと効率的です。
18．検索・Groundingも必要なときだけ使う
生成AIサービスによっては、
Web検索
外部検索
Grounding
各種Tool
に追加料金が発生する場合があります。
例えばGemini APIの現在の料金体系でも、モデル推論とは別にGoogle Search Groundingの利用料金が設定されています。
そのため、
今日のニュースを調べる
ならWeb検索が必要ですが、
文章を丁寧に書き直す
だけなら検索は不要です。
19．API利用量をユーザー単位・機能単位で記録する
AI API料金を削減するには、
どこで使っているか
を把握する必要があります。
最低限、
user_id
feature
model
input_tokens
output_tokens
cached_tokens
request_count
estimated_cost
などを記録します。
例えば、
| AI機能 | 月間費用 |
|---|---|
| メール分類 | 5,000円 |
| 社内RAG | 20,000円 |
| レポート生成 | 8,000円 |
| AIエージェント | 80,000円 |
と分かれば、
AIエージェントのコストが高い
と判断できます。
20．「1回いくら」ではなく「1業務いくら」で見る
AI APIのコストでは、
1リクエスト0.5円
だけを見るより、
問い合わせ1件を処理するのに
何円かかるか
を見る方が重要です。
例えば、
問い合わせ1件
分類：
0.1円
RAG：
0.3円
回答生成：
0.8円
合計：
1.2円
とします。
人が対応すると、
10分
×
時間単価3,000円
=
約500円
なら、
AI API：
1.2円
は十分小さい可能性があります。
AI APIは「最安」にすることが目的ではない
例えば、
高性能モデル：
1件5円
精度98％
軽量モデル：
1件1円
精度75％
だとします。
軽量モデルに変更した結果、
人による修正作業
が大幅に増えれば、総コストは高くなる可能性があります。
見るべきなのは、
API料金
+
人の確認時間
+
エラー対応
です。
AI APIのコスト計算例
例えば問い合わせAIが、
月10,000件
利用されているとします。
現在、
1件あたり平均API費用：
5円
なら、
10,000件 × 5円
=
月5万円
です。
改善として、
軽量モデル：
-30％
入力削減：
-20％
出力削減：
-10％
などが実現し、平均3円まで下げられれば、
10,000件 × 3円
=
月3万円
となります。
年間では、
24万円削減
です。
月100万件なら、この差はさらに大きくなります。
AI APIコスト削減の優先順位
おすすめは次の順番です。
1．利用量を計測
↓
2．用途別コストを把握
↓
3．高性能モデルが必要か確認
↓
4．不要な入力を減らす
↓
5．不要な出力を減らす
↓
6．同一処理をキャッシュ
↓
7．Batch化できる処理を探す
↓
8．RAG・Embeddingを最適化
↓
9．AIエージェントのステップ数を削減
↓
10．再度コストと精度を測定
いきなり複雑な最適化をする必要はありません。
コスト削減前後で品質を比較する
例えばモデルを変更するとき、
高性能モデル
↓
軽量モデル
へ変更して終わりではありません。
過去のデータ100〜1,000件程度を利用して、
正解率
AI出力採用率
人による修正率
レスポンス時間
API料金
を比較します。
例えば、
| 指標 | Model A | Model B |
|---|---|---|
| 正解率 | 97％ | 95％ |
| 1件コスト | 5円 | 1円 |
| 修正率 | 4％ | 6％ |
なら、Model Bへ変更する価値があるかもしれません。
AI APIコスト削減チェックリスト
□ 用途別のAPI利用量を把握している
□ input/output tokenを記録している
□ 高性能モデルを不要な処理に使っていない
□ 軽量モデルを評価している
□ 長すぎるsystem promptを見直している
□ 会話履歴を無制限に送っていない
□ RAGの取得件数を最適化している
□ 同一データを毎回Embeddingしていない
□ AI回答をキャッシュできないか検討した
□ Prompt Cachingを活用できないか確認した
□ Batch処理できる業務を確認した
□ 出力文字数を制御している
□ AI不要の計算・条件判定をプログラムへ移した
□ AIエージェントの最大ステップ数を設定している
□ リトライ回数を制限している
□ 1業務あたりのAI費用を計測している
AI APIコスト削減でよくある失敗
とにかく安いモデルへ変更する
精度低下による人件費増加まで確認します。
プロンプトだけ短くする
RAG取得文書や会話履歴が大部分を占めている場合があります。
API呼び出し回数しか見ない
1回1,000tokensと1回100,000tokensでは料金が大きく異なります。
RAGで大量文書を毎回渡す
関連性の高い文書だけ取得します。
AIエージェントを無制限に動かす
最大ステップ・Tool実行回数を制限します。
すべてリアルタイムAPIにする
即時結果が不要ならBatch APIを検討します。
コストだけをKPIにする
AI導入の本来の目的は業務改善です。
AI APIコスト削減に関するよくある質問
OpenAI APIの料金を削減する一番簡単な方法は？
まず現在のモデル・入力トークン・出力トークンを確認します。
そのうえで、
軽量モデルへ変更できないか
不要なコンテキストがないか
出力が長すぎないか
を確認すると効果を出しやすいでしょう。
Prompt Cachingとは何ですか？
同じ、または共通する長い入力を繰り返し利用する場合に、キャッシュされた入力を活用して処理コストやレイテンシを抑える仕組みです。
対応状況や料金はモデル・提供会社によって異なるため、利用サービスの最新仕様を確認します。OpenAIとGemini APIの双方にキャッシュされた入力を活用する仕組みがあります。
Batch APIは安くなりますか？
サービスによります。
現在OpenAIのBatch APIは同期APIに比べ50％割引で提供されています。Gemini APIでもBatch料金がStandardより低く設定されています。
リアルタイム応答が不要な大量処理と相性があります。
RAGにするとAPI料金は安くなりますか？
設計によります。
大量の全文を毎回AIへ渡す代わりに、関連部分だけ取得できれば入力トークン削減につながります。
ただし、検索件数を増やしすぎれば逆に入力が増えます。
AIエージェントは通常のAIより高いですか？
高くなる可能性があります。
一つの依頼で複数回モデル・Toolを呼び出すためです。
最大ステップ数やTool実行数を管理することが重要です。
API料金は毎月固定できますか？
通常は利用量による従量課金が中心ですが、提供会社によってエンタープライズ向けの予約・容量型プランなどもあります。
大量利用の場合は、通常の従量課金だけでなく契約体系も比較します。
hiro-dev-labの生成AI API・コスト最適化を考慮したシステム開発
hiro-dev-labでは、生成AI APIを利用したWeb・業務システムの設計・開発を支援しています。
例えば、
- OpenAI APIなどを利用したAI機能
- 用途別モデルの使い分け
- RAGによる入力データ削減
- Prompt Cachingを考慮したプロンプト設計
- Batch処理
- AI API利用ログ・コスト管理
- AIエージェントのTool設計
- AIエージェントの実行回数制御
- Embedding・Vector DBの最適化
- Python・TypeScriptによるAIシステム開発
- 既存WebシステムへのAI機能追加
などを検討できます。
例えば、
現在
全問い合わせ
↓
高性能モデル
↓
毎回長いFAQ全文
↓
長文回答
となっているシステムを、
問い合わせ
↓
軽量モデルで分類
↓
RAGで必要なFAQだけ検索
↓
必要に応じて高性能モデル
↓
回答文字数を制御
へ変更することで、品質を維持しながらAI APIコストを抑えられる可能性があります。
AI APIコスト削減は「安いAIへ変更する」だけではない
生成AI APIのコスト削減で重要なのは、
モデル単価
だけではありません。
実際には、
モデル
×
入力トークン
×
出力トークン
×
実行回数
×
AIエージェントのステップ数
によってコストが決まります。
そのため、
高性能モデル
↓
安いモデル
だけではなく、
1．モデルを用途別に分ける
2．必要な情報だけAIへ送る
3．会話履歴を圧縮する
4．RAGの取得件数を調整する
5．Prompt Cachingを活用する
6．AI回答をアプリ側でキャッシュする
7．リアルタイム不要ならBatch化する
8．出力を必要最小限にする
9．計算・条件判定を通常プログラムへ移す
10．AIエージェントのループを制限する
11．Embeddingを差分更新する
12．用途別のAPI費用を継続的に監視する
という複数の対策を組み合わせます。
そして最も重要なのは、
AI API料金だけを
最小にする
ことではありません。
API料金
+
人による確認時間
+
エラー修正
+
運用費
まで含めて、業務全体のコストを下げることが目的です。
「生成AI APIの料金が想定より高くなっている」
「RAGの入力トークンを減らしたい」
「AIエージェントのAPI利用量を管理したい」
「本番運用を想定してAI APIのコストを抑えた設計にしたい」
このような段階からでも、お気軽にお問い合わせください。
生成AI API・AIシステム開発について相談する