業務アプリに AI 機能を載せる前に、月額の幅を見積もる：トークンの内訳とキャッシュ・モデル選びの考え方

業務アプリに生成 AI の機能を入れる企画では、「月にいくらかかるのか」が最後まで決まらないことがよくあります。画面や機能の見積もりは固定でも、AI の利用料は使った量に応じて変わる従量課金だからです。

この記事では、運用を始める前に、AI の利用料を「1 つの金額」ではなく「幅」で見積もる手順を整理します。素材として、Cloudflare が自社の AI コードレビューで費用を下げた事例を使います。業務アプリとは用途が違いますが、費用がどこで増え、どこで減らせるかがよく分かる公開事例だからです。

費用は「回数 × 長さ × 単価」で決まる

API 型の生成 AI は、入力と出力の文字量(トークン)に単価を掛けて課金されます。見積もりでは、次の 4 つを分けて考えると整理しやすくなります。

• 月に何回呼び出すか(利用回数)
• 1 回あたりの入力の長さと、出力の長さ
• どのモデルを使うか(モデルごとに単価が違う)
• 同じ入力の部分を使い回せるか(キャッシュ)

Cloudflare の事例は、この 4 つがどう効くかを数字で見せています。同社の公表によると、AI コードレビュー 1 回あたりの平均費用は、4 月の 1.19 ドルから 8 月末には約 2.46 ドルへ、ほぼ倍になりました。主な要因は、8 月初めに全レビュアーを Anthropic のモデルに切り替えたことです(1 ジョブあたりの費用が 1.38 ドルから 2.03 ドルへ)。さらに、4 月から 9 月の間にレビュー 1 回あたりのトークン数が 0.91M から 2.99M へ 3 倍以上になっていました(出典:Cloudflare Blog)。

注目したいのは、キャッシュの当たり率(ヒット率)が 85.7% から 97% に上がっていたのに、費用は下がらなかったことです。同社はこう書いています。

A high hit rate on three times as many tokens still costs a lot more, even with the low cache read cost.

出典:Obsessive inference optimization(Cloudflare Blog)

キャッシュが効いていても、長さが 3 倍になれば費用は増えます。「キャッシュを使うから安い」という見積もりは、入力の長さが変わらないという前提の上に立っています。

内訳を見ないと、削る場所が決まらない

同社が最適化の前に分けた費用の内訳は、出力トークンが約 23%、キャッシュの書き込みが 43%、キャッシュの読み取りが 34% でした。会話全体を毎回の呼び出しで送り直す作りのため、すでに見た内容や、これから再び使う内容に費用の多くが使われていた、と説明されています。

業務アプリでも同じ見方ができると考えています。承認フローの要約、問い合わせの分類、帳票の読み取りなど、AI 機能ごとに「入力の何割が毎回同じ内容か」「出力はどれくらいの長さか」を分けて書き出すと、どこを削れば効くかが見えます。

同社が下げた方法を、見積もりの観点に引き直す

同社の公表では、最も費用が高かった 2 週間の平均 2.43 ドルに対し、現在の平均は 0.77 ドルで、約 68% の削減です。効いた手段は次のとおりです。

• キャッシュの区切りを直した:最初のリクエストのヒット率は 14〜26% しかありませんでした。システムプロンプトが 1 つのブロックにまとまっていて、リポジトリをまたいで共通部分を使い回せなかったためです。共通部分の末尾で区切るようにして、ヒット率は 91〜99.5% になりました
• 呼び出しの回数を減らした:使えないツールの除外、ファイルの並列読み込み、変更のない再レビューのスキップなど、複数の変更の合計で、1 レビューあたり約 0.20 ドル下がりました
• モデルと思考の深さ(effort)を使い分けた:コード品質のレビューは高 effort にして、1 日分の比較で、費用は約 61% 増えましたが、指摘は約 58% 増えました

ここから、見積もりに使える考え方が 3 つ取り出せます。

1. 費用を下げる手段は「単価の安いモデルに替える」だけではなく、入力の構成を変える、呼び出しを減らすもある
2. 安くするだけが目的ではなく、効果が出る箇所は費用をかけてよい(同社は品質が上がる箇所には費用を足している)
3. 下げた結果は、品質への影響を見ながら確かめる必要がある

同社自身も、削減の約 40% はレビュアーのコード改善、残りはモデルと effort の実験によるものとし、効果の分解は対照実験ではなく時間帯の前後比較に基づくと書いています。パフォーマンスとセキュリティのレビューは、中 effort のままで、高 effort での検証はこれからです。数字は「この規模でここまで下がった例」として読むのが妥当で、自社の業務アプリにそのまま当てはまる値ではありません。

業務アプリの月額を幅で見積もる手順

次の順で、AI 機能ごとに表を作ります。

手順 1:機能ごとに、呼び出しの単位を決める

「承認申請 1 件につき 1 回要約する」「問い合わせ 1 通につき 1 回分類する」のように、業務の 1 単位と呼び出しの回数を結びつけます。月の業務件数が分かれば、回数が出ます。

手順 2:入力と出力の長さを、実物で測る

想定ではなく、実際の申請文や帳票のサンプルで入力の長さを測ります。入力のうち、毎回同じ部分(指示文、社内ルール、書式の説明)と、毎回変わる部分(その日の案件の内容)を分けておきます。

手順 3:モデルの単価を公式の料金ページで確認する

単価は改定されます。見積もりには、確認した日付と公式ページの URL を添えます。Anthropic の公式料金ページ(2026 年 10 月 26 日確認)では、たとえば Claude Sonnet 5.5 は入力が 100 万トークンあたり 2 ドル、出力が 10 ドルです。キャッシュの読み取りは、この機種では入力単価の 0.05 倍(0.10 ドル)と記載されています。ほかのモデルでは倍率が異なり、書き込みには 1.25 倍(5 分間のキャッシュ)の費用がかかります(出典:Pricing(Anthropic))。

手順 4:計算して、前提を変えて幅にする

次は、数字を仮に置いた計算例です。月に 4,000 件(1 日 200 件、20 営業日)の要約を、入力 3,000 トークン、出力 500 トークンで行うとします。

• 入力:3,000 × 4,000 = 1,200 万トークン → 2 ドル × 12 = 24 ドル
• 出力:500 × 4,000 = 200 万トークン → 10 ドル × 2 = 20 ドル
• 合計:44 ドル

入力のうち 2,000 トークンが毎回同じ指示文で、すべてキャッシュから読めたと仮定すると(書き込みの費用は省略)、次のようになります。

• 固定部分:800 万トークン × 0.10 ドル = 0.8 ドル
• 変わる部分:400 万トークン × 2 ドル = 8 ドル
• 入力は 8.8 ドル、出力 20 ドルと合わせて 28.8 ドル(約 35% 減)

この例で分かるのは、キャッシュで入力が安くなっても、出力が費用の中心に残ることです。出力を短くする設計(要約の長さを決める、項目だけを返させる)が、次の手になります。

そのうえで、利用回数が半分の場合と 2 倍の場合、入力が 2 倍に伸びた場合を並べて、月額の下限と上限を出します。幅を示すことで、予算の承認も「この範囲に収める」という約束にできます。

運用開始前に決めておく 3 つの上限

見積もりが当たらなくても、費用が青天井にならない仕組みを先に入れておきます。

• 月額の上限と通知の閾値:予算の 50%、80% に達したら担当者に知らせる
• 1 回あたりの入力・出力の上限:想定外に長い入力が来ても、1 回の費用が決まった範囲に収まるようにする
• 急ぎでない処理は後回しにできる設計:Anthropic の公式料金ページでは、Batch API(非同期で大量に処理する方式)は入力・出力とも 50% の割引と記載されています。夜間の一括処理にできる業務なら、検討する価値があります

まとめ

• 費用は「回数 × 長さ × モデル × キャッシュ」で決まる。長さが伸びれば、キャッシュが効いていても増える
• 削る前に、機能ごとの内訳(固定の入力、変わる入力、出力)を書き出す
• 単価は公式ページで確認した日付を添え、前提を変えた幅で月額を出す
• 上限と通知を、運用開始前に入れておく

私たちの「AIプロトタイプ・MVP開発」は、本開発の前に、動くものを短期間で確かめる入口です。AI 機能の費用が気になる段階でも、お気軽にご相談ください。