生成AIのAPI料金の見積もり方と、稼働後のクラウド費用の見直し

生成 AI を業務に組み込むと、開発費とは別に、処理のたびに API の利用料がかかります。見積もりの段階では「月にいくらかかるのか」が読めず、稼働してからは「この請求額は妥当なのか」が分からない、ということが起きがちです。frectas は、PoC の段階で1件あたりの費用を測り、稼働後は呼び出しの記録とクラウドの請求を見て構成を直す 進め方を取っています。この記事では、API 料金がどう決まるか、PoC で何を測るか、モデルの割り当て、稼働後の見直しを、実案件の記録にもとづいて書きます。

PoC・本開発・伴走支援の費用の段階や目安の金額は「業務AI化・システム開発の費用の考え方」にまとめています。この記事は、そのうち AI とクラウドの利用料に絞った内容です。

この記事の数字は、frectas の案件の記録（検証の記録・費用の試算）によるもので、それぞれに区分（PoC 実測・概算・見込み）を添えています。

結論：利用料は「1件あたり」と「工程の数」で決まる

• 料金は1回の呼び出しごとに決まる。 入力のトークン、出力のトークン、画像の量、使うモデルで1回の費用が決まる
• 1件の処理に何回呼ぶかで掛け算になる。 工程を分ける、見直しの工程を足す、失敗して再試行する、のどれも回数を増やす
• モデルの割り当ては設計の一部。 どの工程に最上位のモデルを使い、どこを軽いモデルや AI を使わない処理にするかで、費用の桁が変わる
• 稼働後は記録を見て直す。 呼び出しの記録とクラウドの請求を見れば、どこを削れるかが分かる

生成AIのAPI料金が決まる仕組み

API の料金は、多くのサービスで「読ませた量」と「書かせた量」に応じた従量課金です。単価は各社が改定を重ねており、この記事では具体的な金額を書きません。見積もりでは、その時点の公式の料金表で確かめてください。仕組みとしては、次の要素が料金を動かします。

見落としやすいのは下の2つです。1件あたりの単価が安くても、1件の処理で何回も呼んでいれば、その回数分が掛かります。また、プロンプトを直すたびに過去分を処理し直す運用だと、再実行の費用が毎月の件数とは別に発生します。

各社のサービスには、同じ指示文を繰り返し送るときの割引（キャッシュ）や、急がない処理をまとめて送る割引（バッチ）があることもあります。使えるかどうかは業務の待ち時間の許容度で決まるので、方式を決めるときに一緒に検討します。

PoCで1件あたりの費用を測る

見積もりの出発点は、PoC で実際のデータを処理したときの記録です。設備メーカーの設計部門の案件では、図面 PDF から部屋の情報を抽出する方式を検証しました。

区分が「概算」になっているのは、トークン数は API が返した実測値でも、単価は試算した時点の仮定を置いているからです。単価が改定されれば、同じトークン数でも金額は変わります。見積もりの資料では、トークン数（実測）と単価（仮定）を分けて書く と、単価が変わったときに計算し直せます。

もう一つ大事なのは、PoC の累計費用をそのまま本番の見積もりに使わないことです。PoC には試行錯誤の呼び出しが含まれる一方、本番の構成とは呼び出し方が違うこともあります。本番の見積もりは、本番で採る方式での「1ページあたり」「1件あたり」の費用を測り、月の件数を掛けて出します。

モデルの割り当ては設計の一部

同じ図面の案件では、安いモデルを前提にした試算と、最上位のモデルでページ全面を読む条件とで、費用の桁が違いました。どのモデルを使うかは、あとから調整する設定ではなく、方式の設計そのものです。

この案件で最終的に採ったのは、生成 AI に部屋の輪郭を大まかになぞらせ、正確な座標は図面 PDF のベクターの線から機械が決める分担です。AI に正確さを求めなければ、AI に任せる範囲が狭まり、高い性能が要る工程を絞れます。方式の詳細は「図面PDFから部屋情報をAIで抽出」に書いています。

割り当てを考えるときは、工程ごとに次を確かめます。

1. その工程は、AI でなければできないか。 答えが一つに決まる計算や照合は、AI を使わない処理のほうが安く、結果も揺れません
2. 読ませる範囲を絞れるか。 ページ全面ではなく、必要な領域だけを切り出せば入力が減ります
3. 軽いモデルで足りるか。 分類や抽出のように形が決まった仕事は、軽いモデルで正解と照合してから決めます
4. 間違えたときに誰が気づくか。 人が確認して確定する画面があるなら、AI の精度を少し下げても業務は回ります

効かない工程は本番に入れない

精度を上げようとして工程を足すと、呼び出しの回数と時間が増えます。図面の案件では、結果を見直す工程を足したときの時間と費用を測りました。

見直しの工程を足しても、結果は変わりませんでした。そのため、この工程は本番では有効にしていません。「念のため AI にもう一度確かめさせる」工程は安心感がありますが、効果を測ると何も変わっていないことがあります。足す前と後で結果を比べ、変わらなければ外す、という判断を PoC のうちにしておくと、本番の利用料を無駄に積み上げずに済みます。

稼働後は、呼び出しを1回ごとに記録する

見積もりどおりに費用が収まっているかは、稼働してみないと分かりません。卸売・運送の会社の受注の案件では、AI を呼ぶたびに モデル名・トークン数・所要時間・成否 を記録する仕組みにしました。

この記録があると、次のことができます。

• 1件あたりの実際の費用を出せる。 見積もりの前提と比べ、ずれていれば原因を探せる
• 費用の大きい工程が分かる。 削る候補を、感覚ではなく数字で選べる
• 失敗した呼び出しの費用が見える。 応答の形式が崩れて再試行している、といった無駄に気づける
• モデルを更新したときに比べられる。 新しいモデルに切り替えた前後で、時間と費用と成否を並べられる

請求書だけでは、月の合計しか分かりません。どの業務・どの工程にいくらかかったかを後から説明できるよう、記録は最初の開発で入れておくのが安く済みます。

稼働後のクラウド費用の見直し

AI の利用料と並んで、毎月かかるのがクラウドの費用です。開発中は、障害に強い構成や余裕のある性能で立ち上げることが多く、稼働して実際の使われ方が分かると、業務に対して大きすぎる構成が見えてきます。

同じ卸売・運送の会社の案件では、稼働後に本番のデータベースの構成を見直しました。ゾーン障害（データセンターの一部が止まる障害）のときは手動で復旧することを受け入れる代わりに、データベースの構成を縮小しています。

この数字は、8月の請求から逆算した換算率による概算で、実際の請求額は翌月以降に確認する、と記録しています。見直しの直後に「いくら下がった」と言い切らず、次の請求で確かめるところまでが見直しの作業です。

構成を縮小する判断で大事なのは、止まったときの業務への影響を、業務の側と決めること です。受注のように人が画面で確認しながら進める業務なら、まれな障害で一時的に止まっても、復旧の手順があれば業務は続けられます。一方、止まると取引先に迷惑がかかる業務なら、冗長な構成の費用は必要な支出です。

稼働後の見直しでは、次の順に確かめます。

1. データベース: 冗長構成の要否、性能の段階、バックアップの保存期間
2. 常時起動しているサーバー: 夜間や休日も起動しておく必要があるか、利用がないときに止められる構成にできるか
3. 検証環境: 本番と同じ規模で常に動かしていないか
4. ログとストレージ: 保存期間が業務の要件より長くなっていないか
5. AI の利用料: 上で書いた呼び出しの記録から、費用の大きい工程を見る

見積もりを依頼するときに用意してほしいもの

生成 AI を使う仕組みの利用料を試算するには、次の情報があると早く進みます。

• 処理する書類・データの種類と、1件の大きさ（ページ数、文字数、画像の有無）
• 月の件数と、繁忙期の件数
• 結果が出るまで待てる時間（すぐ必要か、翌朝まででよいか）
• 間違えたときに人が確認する工程があるか
• 使えない AI サービスや、データを置ける場所の制約

構築から運用までの進め方は「システム・アプリの受託開発」に、図面の案件の全体は事例「設備メーカーの設計部門で、建物の図面 PDF から部屋の情報を抽出」にまとめています。

生成 AI の利用料が月にいくらになりそうか、いまのクラウドの請求額が業務に見合っているかを知りたい方は、お問い合わせからご相談ください。処理したい書類の種類と月の件数、いまの請求額の内訳を教えていただければ、PoC で何を測るべきか、どこから見直すべきかをお伝えします。