生成AIを組み込んだシステムの費用は、性質の違う二つのお金に分けて考えると見通しが立ちます。一つは、画面や処理、データ連携を作るための「開発費」で、作るときにまとまってかかります。もう一つは、生成AIのモデルを呼び出すたびにかかる「API利用料」で、使えば使うほど増える従量課金です。これに、サーバーなどのインフラ費と、精度の維持や改善のための保守・運用費が加わります。
結論から言うと、見積もりで失敗しないためには、開発費の見積もりと並行して、利用量の想定から月額のAPI利用料を試算しておくことが欠かせません。開発費だけで判断して導入した結果、利用が広がるほど月々の費用が膨らみ、採算が合わなくなる例は珍しくないからです。逆に、利用料を正しく見積もれば、モデルの選び方や処理の設計で費用を大きく抑えられることも分かります。
この記事は、生成AIを使った社内ツールや顧客向けサービスの開発を検討し、予算を立てる立場の方に向けています。費用の内訳と、それぞれを左右する要素、API利用料の試算手順、見積もりの比較方法、費用を抑える設計の工夫を順に解説します。具体的な相場額ではなく、自社の条件で金額を出すための考え方をまとめています。
生成AIシステムの費用の全体像
生成AIを組み込んだシステムの費用は、次の四つに分けて整理します。
| 費用の種類 | 内容 | 発生のしかた | 主に何で変わるか |
|---|---|---|---|
| 開発費 | 要件整理、画面、処理、データ連携、プロンプト設計、評価、テスト | 初期にまとまって発生 | 機能の範囲、連携先、求める精度、評価の作り込み |
| API利用料 | 生成AIのモデルを呼び出すたびにかかる料金 | 毎月、利用量に比例 | 利用回数、1回あたりの文章量、モデルの種類 |
| インフラ費 | サーバー、データベース、検索用のデータベース、ログ保存 | 毎月、構成と規模に応じて | 利用者数、データ量、可用性の要件 |
| 保守・運用費 | 障害対応、精度の監視、プロンプトの改善、モデル更新への対応 | 毎月または年間契約 | 対応範囲、改善の頻度、対応時間 |
従来のシステム開発では、開発費が大部分を占め、運用費は比較的予測しやすいものでした。生成AIを組み込むと、API利用料という「使われ方で変わる費用」が加わります。また、モデルの提供元による更新や価格改定、旧モデルの提供終了への対応など、生成AI特有の保守作業も発生します。システム開発全般の費用の考え方は システム開発の費用相場はどう決まるか で解説しています。
開発費を左右する要素
開発費は、一般的なシステム開発と同じく、作業量（工数）と、作業する人の単価の掛け算で決まります。生成AIシステムで工数が増減しやすいのは、次の要素です。
機能の範囲
- 利用者が使う画面（チャット画面、入力フォーム、結果の一覧など）の数と複雑さ
- ログイン、権限管理、利用履歴の保存の要否
- 管理者向けの画面（プロンプトの調整、利用状況の確認、回答の評価など）の要否
データ連携
- 社内文書を検索して回答に使う仕組み（検索拡張生成、いわゆるRAG）の有無
- 参照する文書の形式（PDF、表計算、社内Wikiなど）と量、更新の頻度
- 既存の業務システムやデータベースとの連携の数
社内文書を参照させる仕組みは、文書の前処理や検索の調整に手間がかかり、開発費が大きく変わる要素です。
求める精度と評価の作り込み
生成AIシステムの開発で見落とされやすいのが、出力の品質を確かめる「評価」の工数です。業務で使える品質かを判断するには、想定される質問や入力の例と、望ましい回答の基準を用意し、プロンプトや検索の設定を変えるたびに確認する必要があります。求める精度が高いほど、この評価と改善の繰り返しが増えます。
安全対策
- 個人情報や機密情報をモデルに送らないための処理
- 不適切な入力や出力を検知する仕組み
- 誤回答の際に人へ引き継ぐ仕組み
顧客向けのサービスでは、社内ツールよりもこの部分の作り込みが必要になります。
API利用料の仕組み
生成AIのAPI利用料は、多くの場合「トークン」という単位で課金されます。トークンは、モデルが文章を処理するときの単位で、日本語の場合は文字数とトークン数の関係がモデルによって異なります。詳しくは トークン（LLM） の用語ページで説明しています。
料金は一般に、モデルに渡す文章（入力トークン）と、モデルが生成する文章（出力トークン）で単価が分かれており、出力の方が単価が高く設定されていることが多いです。また、同じ提供元でも、高性能なモデルと軽量なモデルで単価が大きく異なります。
ここで注意したいのは、「入力」には利用者が入力した文章だけでなく、システムが裏側で付け加える文章も含まれることです。
- モデルへの指示文（システムプロンプト）
- 回答の参考にさせる社内文書の抜粋
- 会話の履歴（チャット形式の場合、過去のやり取りを毎回送る）
- 出力の形式を指定する例文
利用者が一行の質問をしただけでも、裏側では数千字分の文章をモデルに送っている、ということはよくあります。試算では、この裏側の文章量を必ず含めます。
利用量から月額のAPI利用料を試算する手順
具体的な単価は提供元やモデル、時期によって変わるため、最新の料金表で確認したうえで、次の手順で試算します。
- 利用シーンを洗い出す：「社員が規程について質問する」「営業が商談メモから報告書を作る」など、AIを呼び出す場面を列挙します。
- シーンごとに1回あたりの入力量を見積もる：利用者の入力に、指示文・参照文書・会話履歴・例文の量を足し合わせます。実際のプロンプトの試作品があれば、提供元のツールでトークン数を数えるのが確実です。
- シーンごとに1回あたりの出力量を見積もる：回答の長さの目安を決めます。要約なら短く、報告書の下書きなら長くなります。
- 1回あたりの呼び出し回数を確認する：一つの操作で、検索用の問い直し・回答生成・チェックなど、複数回モデルを呼び出す設計もあります。
- 月間の利用回数を見積もる：利用者数 × 1人あたりの1日の利用回数 × 月の営業日数、のように積み上げます。
- 月額を計算する：シーンごとに「月間回数 × 1回あたりの呼び出し回数 ×（入力トークン × 入力単価 ＋ 出力トークン × 出力単価）」を計算し、合計します。
- 幅を持たせる：利用が想定の半分の場合、想定どおりの場合、数倍に増えた場合の三通りを出します。特に公開直後は利用量が読みにくいため、上振れのケースで採算が合うかを確認します。
試算の例（架空の社内ツール）
架空の例として、社員100名の会社で、社内規程に答えるチャットツールを作る場合を考えます。
- 1回の質問あたり：利用者の質問、指示文、検索で見つけた規程の抜粋3件分、直近の会話履歴を合わせた入力量を見積もる
- 回答は、短い説明と根拠の規程名を含む長さに制限する
- 1回の質問で、検索用の問い直しと回答生成の2回モデルを呼び出す
- 利用者は全社員だが、実際に使うのは一部と想定し、1日あたりの質問数を想定値として置く
試算は表計算ソフトで、シーンごとに「1回あたりの入力量」「出力量」「呼び出し回数」「月間利用回数」「単価」を列に並べ、掛け算で月額を出す形にしておくと、条件を変えたときの影響をすぐに確かめられます。単価の列だけを差し替えれば、モデルを変えた場合の比較もできます。
ここに提供元の最新単価を当てはめて計算すると、月額の目安が出ます。そのうえで、参照する規程の抜粋を3件から5件に増やした場合や、高性能なモデルに変えた場合にどれだけ増えるかも計算しておくと、設計の判断材料になります。この例で分かるのは、費用を大きく左右するのが利用者の質問の長さではなく、裏側で付け加える参照文書の量とモデルの選択だということです。
インフラ費と保守・運用費の見込み方
API利用料の試算に目が向きがちですが、インフラ費と保守・運用費も、年間で見ると無視できない金額になります。
インフラ費
生成AIシステムのインフラは、通常のWebシステムと同じ部分（画面や処理を動かすサーバー、データベース）に加えて、社内文書を検索するための仕組みが加わることがあります。文書を検索しやすい形に変換して保存するデータベースや、変換処理そのものの費用です。参照する文書の量が多いほど、また文書の更新が頻繁なほど、保存と再変換の費用が増えます。入出力のログをどれだけの期間保存するかも、保存容量に影響します。監査や品質改善のためにログは必要ですが、保存期間を決めずに貯め続けると費用が増え、個人情報の管理上も負担になります。
保守・運用費
生成AIシステムに特有の保守作業として、次のようなものがあります。
- 精度の監視：利用者の評価や、定期的な評価用データでの確認で、回答の品質が落ちていないかを見る
- プロンプトや検索設定の調整：誤回答の傾向に合わせて指示文や参照文書の範囲を見直す
- モデルの更新への対応：提供元が新しいモデルを出したり、古いモデルの提供を終了したりしたときに、切り替えと再評価を行う
- 参照文書の更新：規程やマニュアルが改訂されたときに、検索用のデータを更新する
これらを開発会社に任せるのか、社内で担うのかによって、保守費の見積もりは大きく変わります。参照文書の更新のように社内で担える作業は、手順書と管理画面を用意して社内で回すと、費用を抑えつつ反映も早くなります。
見積もりを比較するときの観点
複数の開発会社から見積もりを取ると、金額に大きな差が出ることがあります。金額だけで比べず、次の観点で中身を確認します。
- API利用料の試算が含まれているか：開発費だけを示し、運用時の利用料に触れていない見積もりは、後から想定外の費用が発生する可能性があります。
- 評価の工数が含まれているか：評価用のデータ作りや精度の確認作業が含まれていない場合、品質の確認が利用者任せになります。
- 精度の目標と、達成できなかった場合の扱い：「どの程度の正答を目標にするか」「目標に届かない場合にどこまで改善するか」が決まっているかを確認します。
- モデルの切り替えに備えた設計か：特定のモデルに強く依存した作りだと、価格改定や提供終了のときに大きな改修が必要になります。
- 保守の範囲：モデルの更新への対応、プロンプトの調整、精度の監視が保守に含まれるかを確認します。
- 前提条件：参照する文書の量や形式、利用者数など、見積もりの前提が明記されているかを確認します。
見積もりの金額差を読み解く一般的な方法は、システム開発の見積もり比較のコツ で詳しく解説しています。
費用を抑える設計の工夫
生成AIシステムの費用は、設計次第で大きく変わります。
モデルを使い分ける
すべての処理に最も高性能なモデルを使う必要はありません。質問の分類や簡単な要約は軽量なモデルに任せ、難しい判断や長い文章の生成だけ高性能なモデルを使う、といった使い分けで利用料を抑えられます。どのモデルをどこに使うかの判断軸は 業務に使うLLMの選び方 で整理しています。
送る文章を減らす
- 指示文を簡潔にし、重複した説明を削る
- 参照文書は、関係する部分だけを抜粋して渡す
- 会話履歴は全部送らず、直近の数往復や要約だけにする
- 出力の長さに上限を設ける
繰り返し使う部分を再利用する
毎回同じ指示文や参照資料を送る場合、提供元によっては、繰り返し送る部分の処理を割安にする仕組みが用意されています。プロンプトキャッシュ と呼ばれる仕組みで、条件が合えば利用料を抑えられます。また、よくある質問への回答をシステム側で保存しておき、同じ質問には保存した回答を返す方法もあります。
生成AIを使わない処理を見極める
決まった形式の計算、データの検索や集計、定型の通知文の作成など、従来のプログラムで確実にできる処理まで生成AIに任せると、費用も誤りも増えます。生成AIは、文章の理解や生成など、従来の方法では難しい部分に絞って使います。
利用量に上限を設ける
利用者ごと・部署ごとの1日の利用回数に上限を設ける、異常な利用を検知したら通知する、といった仕組みを入れておくと、想定外の費用増加を防げます。
よくある失敗と避け方
- 開発費だけで予算を組む：API利用料と保守費を含めた年間の費用で判断します。
- 試作の段階の利用料で本番を見積もる：試作では利用者も参照文書も少ないため、本番では裏側の文章量も利用回数も増えます。本番の条件で試算し直します。
- 料金改定やモデルの提供終了を想定しない：提供元の価格やモデルの提供状況は変わります。モデルを切り替えやすい設計にし、保守の範囲に移行作業を含めます。
- 評価の仕組みを作らない：品質を測る仕組みがないと、利用料を下げるためにモデルを変えたとき、品質が落ちたかどうかを判断できません。
- 利用状況を記録しない：シーン別・部署別の利用回数と利用料を記録しておかないと、どこに費用がかかっているか分からず、改善もできません。
- すべてを生成AIでやろうとする：従来のプログラムで済む処理を見極め、生成AIの利用を必要な部分に絞ります。
- 社内の作業時間を費用に入れない：評価用データの作成、回答の確認、参照文書の整理など、発注側の社員が担う作業も必ず発生します。誰がどれだけ時間を割くかを見込んでおかないと、開発が予定どおり進みません。
予算を立てる前のチェックリスト
- AIを呼び出す利用シーンを洗い出したか
- シーンごとの入力量（裏側で付け加える文章を含む）と出力量を見積もったか
- 1回の操作で何回モデルを呼び出すかを確認したか
- 利用者数と利用回数の想定を、少ない・想定どおり・多いの三通りで置いたか
- 提供元の最新の料金表で単価を確認したか
- 開発費・API利用料・インフラ費・保守費を分けて年間で集計したか
- 見積もりに評価の工数と精度の目標が含まれているか
- モデルの切り替えに備えた設計になっているか
- 利用量の上限設定と、利用状況の記録の方法を決めたか
顧客向けサービスとして生成AIを提供し、料金をいくらにするか検討している場合は、AIサービスの料金設計 で利用料の原価を価格に反映する考え方を紹介しています。
よくある質問
Q. 開発費とAPI利用料、どちらが大きくなりますか？
利用者数と使われ方によって変わります。社内の一部の部署だけで使うツールなら、開発費に比べてAPI利用料は小さくなることが多い一方、多くの利用者が日常的に使うサービスや、大量の文書を処理する仕組みでは、数年の累計でAPI利用料が開発費を上回ることもあります。試算の手順に沿って、自社の条件で比べることが大切です。
Q. 試作の段階で費用を確かめる方法はありますか？
想定する代表的な利用シーンで実際にプロンプトを作り、提供元のツールで入出力のトークン数を測るのが確実です。数十件の入力例で平均と最大を測れば、月額の試算の精度が上がります。この作業は、モデルの比較や品質の評価とあわせて行うと効率的です。
Q. 自社のサーバーでモデルを動かせばAPI利用料はかかりませんか？
API利用料はかかりませんが、モデルを動かすための高性能なサーバーの費用と、その運用の手間が発生します。利用量が少ないうちはAPIを使う方が安く済むことが多く、利用量が非常に多い場合や、データを外部に出せない事情がある場合に検討する選択肢です。
Q. 見積もりに精度の保証を求めることはできますか？
生成AIの出力は確率的に変わるため、すべての入力に対して正しい回答を保証することは難しいのが実情です。現実的には、評価用のデータで目標とする水準を合意し、その水準に向けて改善する作業の範囲と期間を契約で決める形になります。
Otsumuに相談できること
利用者が限られた社内ツールで、文章の要約や下書きのような単純な用途であれば、法人向けの生成AIサービスをそのまま使う方が、開発費をかけるより早く安く始められることがあります。まずはこの記事の手順で利用シーンと利用量を書き出し、既製のサービスで足りるかを確かめるのがよい出発点です。
一方、社内文書や業務データと組み合わせて回答させたい、既存の業務システムに組み込みたい、顧客向けサービスとして提供して利用量に応じた採算を管理したい、といった場合は、開発費と利用料の両方を見ながら設計を決める必要があります。どのモデルをどの処理に使うか、何を生成AIに任せないかの判断が、長期の費用を左右します。
Otsumuでは、利用シーンと利用量の想定を一緒に整理し、API利用料の試算を含めて、必要な機能に絞った開発を行います。進め方は 生成AIシステム開発 のページで紹介しています。小さく作って効果と費用を確かめたい場合は、PoC / MVP Sprint（300万円〜、税別・参考価格、6週間を目安に設計）で検証から始める方法もあります。詳しくは PoC / MVP Sprint をご覧ください。
予算の立て方や見積もりの見方を相談したい段階でも構いません。30分の無料相談 で、想定している使い方を伺いながら費用の考え方を一緒に整理します。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01