AI利用料が膨らまない設計

AI機能の費用は、サーバー代のように「月いくら」で固定されません。使った分だけ課金されるため、利用者が増えれば増え、一人あたりの使い方が変われば変わります。つまり、設計と料金設計が直結します。

本記事では、既存のAI APIを組み込んだサービスで、利用料が想定外に膨らまないようにするための打ち手を、効果と手間の順に整理します。

まず、何にお金がかかっているかを知る

AI APIの課金は、多くの場合トークンという単位で行われます。トークンは文章を細かく区切ったまとまりで、日本語では概ね一文字が一つ以上に相当します。送った文章の量（入力）と、返ってきた文章の量（出力）の両方に課金され、多くのモデルで出力側のほうが単価が高く設定されています。

ここから、費用の構造は次の掛け算になります。

一件あたりの費用 ＝（入力の長さ × 入力単価 ＋ 出力の長さ × 出力単価） 月額 ＝ 一件あたりの費用 × 一人あたりの利用回数 × 利用者数

見落とされがちなのは、この式に「一人あたりの利用回数」が入っていることです。利用者数の想定は立てても、ヘビーユーザーが想定の何十倍も使う可能性は見積もりに入っていないことが多くあります。

最初にやるべきは、試作の段階で実際のデータを通し、一件あたりのトークン数を測ることです。そのうえで、想定する利用回数と利用者数を掛けて月額の見込みを出します。この試算が事業として成り立たない場合、作り込む前に設計か料金体系を見直せます。

打ち手1：入力を短くする

効果が大きく、手間が小さいのがここです。入力は、気づかないうちに膨らみます。

毎回送っている固定の指示文を見直します。 役割の説明、出力形式の指定、禁止事項などを長々と書いた指示文は、利用者が一回操作するたびに毎回課金されます。丁寧に書くこと自体は品質のために必要ですが、重複した言い回しや、実際には効いていない記述が残っていることがよくあります。

渡す資料を絞ります。 社内文書を参照して答えさせる機能で、文書全体を毎回送っていると費用は跳ね上がります。質問に関係する部分だけを検索して渡す作りにすると、入力量は大きく下がります。

会話の履歴を全部渡さない。 チャット形式の機能で最も費用が膨らむ原因です。やり取りが増えるほど毎回の入力が長くなり、後半の一往復が最初の何倍にもなります。この扱いは会話をまたぐ文脈の持ち方で詳しく扱います。

出力の長さに上限を置きます。 出力側の単価は高いので、必要以上に長い回答を許さない設定は直接効きます。あわせて「300字以内で」といった指示も効果があります。

打ち手2：結果を使い回す

同じ入力に対しては同じ処理を繰り返さない、という当たり前のことが、AI機能では意外と実装されていません。

そのまま同じ入力が来る場合は、結果を保存して返します。よくある質問への回答、決まった文書の要約、同じ商品の説明文の生成などが該当します。保存期間は内容の鮮度で決めます。

似た入力が来る場合は、そもそもAIを呼ばずに済ませられないかを考えます。問い合わせ対応であれば、頻出の質問は定型の回答を用意し、そこに当てはまらないものだけAIに回す。この切り分けは、費用だけでなく応答速度と回答の安定性も改善します。

利用者をまたいで使い回せる場合は効果が特に大きくなります。ただし、個人の情報が混ざった入出力を他の利用者に見せることは絶対に避けなければなりません。使い回してよいのは、利用者に依存しない入力に対する結果だけです。ここを間違えると費用削減どころではない事故になります。

打ち手3：モデルを用途で分ける

AIモデルには性能と単価の幅があります。すべての処理に最上位のモデルを使う必要はありません。

実務では、まず軽いモデルで試し、質が足りない処理だけ上げる順番が有効です。逆に、全部を高性能なモデルで作ってから下げようとすると、どこまで下げてよいか判断がつかず、結局そのままになります。

二段構えにする方法もあります。軽いモデルで処理し、その結果が一定の基準を満たさない場合だけ高性能なモデルで処理し直す形です。ただし、判定と再処理の分だけ複雑さが増すため、単価差が十分に大きい場合に限って検討してください。

なお、モデルは短い周期で入れ替わり、単価も変わります。モデル名を設定として外に出しておくと、新しい選択肢が出たときに比較して切り替えられます。

打ち手4：上限を仕組みで持つ

ここまでの三つは単価を下げる話ですが、上限は総額を守る話です。事故を防ぐという意味では、こちらのほうが優先度が高い場合もあります。

置くべき上限は三層あります。

• 利用者ごと：一日あたり、一か月あたりの回数や量の上限。無料利用者と有料利用者で差をつけます。サブスクリプション型で提供するなら、この上限が実質的なプラン設計になります。
• 機能ごと：一件の処理で何回までAIを呼んでよいか。不具合による無限の呼び出しを防ぎます。
• 全体：一日あたりの総使用量。超えたら警告を出し、さらに超えたら機能を止める。

あわせて、使用量を日次で確認できる状態を作ります。多くのAI APIは提供元の管理画面で使用量を見られますが、それだけでは「誰が何に使ったか」が分かりません。自社側でも、利用者別・機能別に使用量を記録しておくと、原因の特定と料金設計の見直しに使えます。

着手する順番

限られた時間で費用を下げるなら、次の順序をおすすめします。

1. 上限を入れる：事故を防ぐ。最優先。
2. 測る：どこで使っているかを把握する。
3. 入力を短くする：最も効果が出やすい。
4. 使い回す：繰り返しが多い機能から。
5. モデルを分ける：質への影響を確かめながら。

逆に、最初からすべてを作り込むのはおすすめしません。使われ方が分からないうちに最適化すると、実際には発生しない費用を削るために複雑さを抱えることになります。MVPの段階では上限と記録だけ入れ、実際の使用量を見てから削る、という順番が結果的に安く済みます。

弊社は既存のAI APIを組み込む開発を行う立場として、この試算を設計の最初に行います。試算の結果、AIを使わずルールベースの処理で足りると判断できる場合は、そのようにお伝えします。AIを使わない選択が最も安いことは、実際によくあります。

AI活用開発やWebシステム開発での費用の見積もりや、料金体系との整合についてはお問い合わせからご相談ください。インフラ側の費用も含めた見直しはクラウドインフラコストの圧縮もあわせてご覧ください。