LLM API利用料の見積もり方｜上限を先に決める考え方

AI機能を組み込んだサービスは、使われるほど費用が増えます。この記事では、LLM APIの利用料を見積もる手順と、運用が始まる前に決めておきたい上限の考え方を整理します。トークンの数え方、利用量の仮置き方、上限に近づいたときの動き方まで、順に確認します。

LLM APIの利用料はどう決まるのか

最初に、利用料の仕組みを押さえます。ここを曖昧にしたまま見積もると、後で大きくずれやすくなります。

基本は「トークン」の量で決まる

多くのLLM APIは、処理した文章の量に応じて課金されます。その単位が「トークン」です。トークンとは、AIが文章を処理するときの区切りの単位で、文字数とは一致しません。同じ内容でも、言語や使うモデルによって数え方が変わります。

もう一つの特徴は、入力と出力で単価が分かれていることが多い点です。入力はAIに渡す文章、出力はAIが返す文章です。単価はモデルごと、提供元ごとに異なり、改定されることもあります。そのため、この記事では具体的な金額を載せません。見積もりの際は、使う予定の提供元の公式の料金ページで、最新の単価を確認してください。

利用料を左右する主な要因

利用料は、次の要素の掛け算で決まります。

• 使うモデル：同じ提供元でも、大型のモデルと小型のモデルでは単価が大きく違うことがあります
• 1回あたりの入力量：ユーザーの質問だけでなく、AIへの指示文、参照させる資料、過去のやり取りも含まれます
• 1回あたりの出力量：長い回答ほど、出力の分が増えます
• 利用回数：利用者数と、1人あたりの使用頻度で決まります
• 想定外の呼び出し：失敗時の再実行や、AIが自分で何度も処理を繰り返す動きなどが含まれます

「ユーザーが1回質問する」ように見えても、裏側では複数回のAI呼び出しが走っていることがあります。見積もりでは、画面上の操作ではなく、AIへの呼び出しを数える必要があります。

利用量を見積もる手順

見積もりは、1回の処理を分解し、回数を掛け、幅を持たせる、という順番で進めると整理しやすくなります。

手順1：1回の処理を部品に分解する

AI機能が1回動くときに、AIへ渡す入力と、返ってくる出力を書き出します。たとえば、利用者の質問に社内外の文書をもとに答える機能なら、次のように分けられます。

• AIへの指示文（役割やルールを書いた固定の文章）
• 参照させる文書（検索で取り出した資料の抜粋）
• 過去のやり取り（会話の履歴）
• 利用者の今回の入力
• AIが返す回答

資料を検索して答えさせる仕組みは「RAG」と呼ばれます。仕組みの詳細はRAG開発とは？自社の専門知識で答えるAI機能の考え方で扱っています。RAGでは参照文書の分だけ入力が増えるため、利用料の中で大きな割合になりやすい部分です。

各部品のトークン数は、頭の中で推測せず、実際の文章で測ります。多くの提供元が、トークン数を数える機能やツールを用意しています。実際に使う予定の文章を入れて測るのが、いちばん確実です。

手順2：1人あたりの利用回数を仮置きする

次に、1人の利用者が月に何回、AI機能を使うかを考えます。ここは新規事業ならではの難しさで、実績がないため推測になります。そこで、1つの数字に決めず、少なめ・想定・多めの3つのシナリオを置きます。

• 少なめ：使われ方が定着せず、試す程度で終わる場合
• 想定：企画で描いた使われ方になる場合
• 多め：気に入った利用者が毎日使う場合

特に「多め」のシナリオは大切です。AI機能は便利だと感じた利用者ほど頻繁に使うため、サービスが好調なときほど費用が膨らみます。

手順3：掛け算で月の利用量を出す

仮の数字で計算してみます。以下は、考え方を示すための練習用の数字で、実際の単価や実績ではありません。

資料を参照して答える機能で、1回あたりの入力が次のとおりだとします。

• 指示文：500トークン
• 参照文書：3,000トークン
• 会話の履歴：1,000トークン
• 今回の質問：100トークン

入力は合計4,600トークン、出力が500トークンです。

1人が月に20回使い、利用者が1,000人なら、月の利用量は次のとおりです。

• 入力：4,600 × 20 × 1,000 ＝ 9,200万トークン
• 出力：500 × 20 × 1,000 ＝ 1,000万トークン

これに、入力の単価と出力の単価をそれぞれ掛けて足せば、月の利用料の目安になります。

月の利用料 ＝ 入力トークン量 × 入力単価 ＋ 出力トークン量 × 出力単価

シナリオごとに回数と人数を変えて、3通りの金額を出します。幅を見ることで、「最悪の場合でもこの範囲に収まるか」を事業の側で判断できるようになります。

見積もりがずれやすいポイント

見積もりと実績がずれる原因は、ある程度決まっています。あらかじめ想定しておくと、余裕の持たせ方が変わります。

会話の履歴は、やり取りが続くほど増える

チャット形式の機能では、前のやり取りを毎回AIに渡し直すことが一般的です。会話が続くと、入力が1回ごとに増えていきます。上の計算で履歴を1,000トークンと置いたのは、平均的な長さを想定した仮の数字です。長く会話する利用者が多いサービスでは、履歴の分だけ入力が大きく膨らむ可能性があります。

1つの操作が、複数回のAI呼び出しになる

AIに回答の下書きを作らせてから別の呼び出しで検査させる、複数のステップに分けて処理させる、といった設計では、1回の操作で複数回呼び出しが発生します。また、AIが自分で判断して何度も処理を繰り返すエージェント型の機能では、呼び出し回数が事前に読みにくくなります。エージェントの動かし方や権限の決め方は、AIエージェントの権限を開発でどう決める？本番とデータの線引きでも触れています。

失敗と再実行

通信エラーや、回答の形式が期待どおりでなかったときに、自動でやり直す仕組みを入れることがあります。やり直しの分も課金されるため、再実行の上限回数は設計の段階で決めておくと安心です。

利用者の使い方が、想定と違う

想定より長い文章を貼り付ける利用者や、短時間に連続して使う利用者が現れることがあります。好意的な使い方でも起こります。意図的な悪用や、外部から大量のリクエストを送られる場合も考えられます。そのため、見積もりとは別に、使いすぎを止める仕組みが必要になります。

モデルや単価の変更

提供元が新しいモデルを出したり、単価を見直したりすることがあります。小型モデルの料金改定を扱ったClaude Haiku 5.5、小型モデルの料金が最大9割減のように、条件が下がる動きもあれば、旧モデルの提供終了で移行を迫られる動きもあります。Gemini 2.5の旧ID、12月1日に新モデルへ自動転送のように、指定していたモデルが別のモデルに切り替わる場合もあります。単価は固定ではない前提で、定期的に見積もりを見直す運用が必要です。モデル変更への備えは、LLMモデル変更に備える開発の進め方｜提供終了の前にで詳しく扱っています。

事前に決めておく上限の考え方

見積もりは予測にすぎません。予測が外れたときに備えて、使いすぎを止めるための上限を、運用の前に決めておきます。

上限は、事業の採算から逆算する

上限の金額は、技術側の都合ではなく、事業の側から決めます。考え方は次のとおりです。

1. 1人の利用者から得られる収入、または見込む価値を整理する
2. そのうちAI機能に使ってよい割合を決める
3. 利用者数の見込みを掛けて、月の上限を出す

たとえばサブスクリプション型のサービスなら、月額の利用料のうち、AIの費用に充てられる範囲があるはずです。その範囲を超える使い方をする利用者がいると、使われるほど赤字になります。料金設計とAI費用の関係は、サブスク新規事業のシステム開発｜先に決める6つのことの視点も参考になります。

検証段階のサービスでは、収入がまだ立っていないこともあります。その場合は、検証期間の予算の中でAI費用に充てる額を先に決め、その範囲で何が確かめられるかを考えます。

上限は、複数の切り口で置く

月全体の上限だけでは、一部の利用者や一部の機能が予算を使い切ってしまう恐れがあります。そこで、次のように複数の層で上限を置きます。

• 月全体の上限：サービス全体で使える総額
• 利用者ごとの上限：1人あたりの1日・1か月の利用回数や量
• 1回あたりの上限：1回の入力文字数、出力の長さ、繰り返し回数の制限
• 機能ごとの上限：複数のAI機能がある場合の、機能別の予算
• 時間あたりの上限：短時間に集中する呼び出しを抑える回数制限

提供元の管理画面で、月の支出上限や通知を設定できる場合があります。使える機能は提供元によって異なるため、公式のドキュメントで確認してください。ただし、提供元側の設定だけに頼らず、自分たちのサービス側でも利用回数を数え、制限できる設計にしておくと、より安全です。

上限に近づいたときの動きを決める

上限は「到達したら止める」だけでは不十分です。止まったときに利用者がどう感じるかも含めて、段階的な動きを決めます。

• 予算の50％、80％など、段階ごとに担当者へ通知する
• 上限に近づいたら、軽いモデルへ切り替える
• 上限に達した利用者には、「今月の利用回数に達した」と分かる表示を出す
• 重要な機能だけを残し、それ以外のAI機能を一時停止する

「誰が通知を受けて、誰が上限を引き上げるか判断するか」も、先に決めておきます。判断者が曖昧だと、夜間や休日に費用が膨らんだとき、対応が遅れます。

上限は見直す前提で置く

最初に置いた上限は、あくまで仮です。運用して実際の利用量が分かってきたら、見直します。見直しの時期（たとえば月次の振り返り）も、あわせて決めておくと運用が安定します。

プロトタイプで実測して見積もりを直す

机の上の見積もりには限界があります。利用量の見積もりを現実に近づける一番の方法は、実際に動かして測ることです。

動くものがあれば、トークン数を実測できる

プロトタイプが動いていれば、1回の処理で入力・出力が何トークンだったかを記録できます。指示文の長さや参照文書の量が想定とどれだけ違うか、実測値で分かります。生成AIを使うサービスのプロトタイプで確認したい点は、生成AIを使う新規事業サービスで、プロトタイプで確かめたいことにまとめています。

精度と費用のバランスも、同時に見られる

小型で単価の低いモデルに切り替えたとき、回答の質がどこまで保たれるかは、触ってみないと分かりません。回答の質を測る基準は、費用の議論の前に決めておくと判断しやすくなります。評価の項目はLLMアプリ開発の精度評価｜開発前に決める5つの項目で整理しています。「この質が必要なら、この費用がかかる」という組み合わせを、実物で確かめながら選べます。

測った値で、3つのシナリオを作り直す

プロトタイプを数人で使ってみると、1人あたりの利用回数や1回あたりのトークン数の実測値が得られます。その値で、少なめ・想定・多めの見積もりを作り直します。机上の仮置きより、ずっと根拠のある数字になります。検証で何を指標にするかは、MVP検証の指標を先に決める方法｜判断基準の作り方も参考になります。

運用に入る前に確認したいこと

見積もりと上限を決めたあとも、運用で確認しておきたい点があります。

• 利用量の記録：誰が、どの機能で、どれだけ使ったかを後から追える形で残す
• APIキーの管理：キーが漏れると、第三者に使われて費用が発生する。保管場所と権限を決める
• 契約や支払いの名義：利用料の請求がどのアカウントに紐づくかを確認する。名義の考え方は、システム開発のサーバー名義は誰にする？外注前の決め方の内容がそのまま当てはまる
• モデルの選び方：用途ごとに必要な精度が違うため、全部の処理に大型モデルを使う必要があるかを見直す。比較の視点はAIシステム開発でのAIの選び方｜2026年10月比較で扱っている
• 利用者が増えたときの備え：費用だけでなく、処理の速度や制限の影響も考える。新規事業のシステムの拡張性｜利用者増への備えはどこまでが参考になる

まとめ

LLM APIの利用料は、入力と出力のトークン量に、モデルごとの単価を掛けて決まります。見積もりは、1回の処理を部品に分け、回数を掛け、少なめ・想定・多めの3つのシナリオで幅を持たせる手順で進めると整理しやすくなります。会話履歴の増加、複数回の呼び出し、再実行、単価の改定など、ずれやすい点も前もって織り込んでおきたいところです。

上限は、事業の採算から逆算して決めます。月全体だけでなく、利用者ごと、1回ごと、機能ごとに置き、近づいたときの通知や動きまで決めておくと、費用が想定外に膨らむ事態を抑えられます。最初の数字は仮のもので、動かして測った値で見直すことが前提です。

私たちJustFitは、構想をもとに約1ヶ月で動くプロトタイプを先に作り、実物を見てから契約を判断できる進め方をとっています。動く実物があれば、トークン量や回答の質を確かめながら、AI機能の運用コストと上限を具体的に話し合えます。AI機能を組み込んだ新規事業の進め方に迷うときは、JustFitのサービス紹介もご覧ください。