AIのAPI利用料が急に増えたとき見直す3つの順番

提供元のコンソールで利用状況のグラフを開くと、見慣れないモデル名が急に出ていました。普段は使っていない古い世代のモデルです。

自作のツールでAIのAPIを使っていると、こういう日が来ます。この記事では、利用料が増えたときに調べる順番と見直す順番を、3つの観点に分けて紹介します。

急な増加の原因を切り分ける3つの手順

利用料が増えたときは対策から考えたくなるものです。けれど先に調べるのは「どのモデル名で、どの機能が、いつから」の3点です。

この3点をグラフで切り分けてから対策すると、的外れな作り直しを避けられます。ここでは、グラフの見方と金額の比べ方、疑った仕組みの確かめ方を順に説明します。焦って手を入れる前の下調べです。

グラフでモデル名ごとの線を見る

最初に開くのは、提供元のコンソールにある利用状況のグラフです。日ごとの利用料が出ているのでまず眺めます。モデル名ごとに分けて表示し、ある日から急に出てきた名前がないかを探します。

自分の場合は、普段使っていない古い世代のモデルが出ていました。普段使っているモデルは、1日あたり約0.3ドルのままでした。

全体が膨らんだのではなく、別のモデルが足されていたわけです。ここが分かるだけで、見るべき範囲がだいぶ狭まります。モデル名を見たあとに機能を探す流れです。

増えた日の前後で金額を比べる

次は増えた日とその翌日の金額を並べて見ます。その日の利用料は約0.85ドルでした。翌日は記録した時点で約0.12ドルでした。

翌日の額が小さいなら、毎日回り続ける処理ではなく、一度きりの処理かもしれません。自分には、既存の記録の一括読み込みや動作テストのような動きに見えました。一度きりの処理なら、止めるより見守るほうが多いと考えています。

増え続けているのか跳ねて戻ったのか。この違いで、急いで止めるか様子を見るかが変わります。止める判断はここを見てからで遅くありません。

疑った仕組みが提供元に出るかを確かめる

原因の候補は一つとは限りません。思い込みで決めると別の原因を見逃します。自分は、文字起こしや分類を動かしている記録の仕組みも疑いました。

ただ、そちらは別の会社のAIで動いているので、この提供元のコンソールには出ません。出るとすれば、新しく進めている機能でこの提供元のAPIを足した場合だけです。

最有力と見ていたのは、再開した自作のツールが古いモデル名で呼んでいたことでした。モデル名がコードのあちこちに散らばっていた可能性を考えました。疑う先を減らす作業だと割り切っています。

呼び出しの数を減らす3つの工夫

対策は、効果が大きく副作用の小さい順に進めるのが基本です。いちばん最初に見るのは、モデルでも仕組みでもなく、呼び出しの数です。

同じ結果を得るのに何回呼んでいるかを減らせば、品質を保ったまま利用料が下がる場面があります。モデルを替えるより出力への影響が小さいのも利点です。

ここでは、3案を1回にまとめる、履歴を絞る、自動生成をやめる、の3つを説明します。どれも設定や小さな修正で試せる内容です。

3案を1回の呼び出しでまとめて作る

文章の案を3つほしいとき、3回に分けて呼び出す作りになっていないでしょうか。1回の呼び出しで3案をまとめて作らせれば、呼び出しの数はそのまま減ります。

指示文の共通部分を毎回送る無駄も、同時に減らせます。案ごとに分けて受け取りたいなら、区切りの書き方を指示文に入れるのがコツです。出力の形が決まれば後の処理も簡単です。

自分ならまずここから手を付けます。見た目が変わらない場面が多く、仕組みの作り直しも要らないと考えているからです。

会話履歴は直近のやり取りだけ渡す

会話の形で使っていると、やり取りが続くほど毎回送る文章が長くなります。履歴をすべて渡す作りだと、後半ほど1回あたりの入力が重くなります。長くなった分は、そのまま入力の利用料に乗ってくるのです。

履歴は直近のやり取りだけを渡す形にします。古い部分が要らない用途なら、答えの質が変わらない場面もあると考えています。

ただし前の内容を踏まえる必要がある用途では、削りすぎると答えがずれるのです。削る量は少しずつ変えて、出力を見ながら決めるのが安全です。一度に大きく削ると、原因の切り分けも難しくなります。

自動生成をやめてボタンを押したときだけ作る

画面を開くたびに自動で文章を作る作りは、使われなかった分にも料金がかかります。使う頻度が低い機能ほど無駄が目立ちやすいのです。読まれないまま捨てられる生成が、静かに積み上がっていきます。

ボタンを押したときだけ生成する形にすれば、必要な分しか呼び出されません。操作が1回増えるのは欠点です。それでも利用料の見通しは立てやすくなります。

自分は、使う頻度が読めない機能ほどボタン式にしたいと考えています。迷ったときは、勝手に動かさない側に倒すのが無難です。

単価を下げる3つの設定

呼び出しの数を整えたら、次に見るのは1回あたりの単価です。単価は、モデルの選び方、入力の量、出力の量で決まります。

ここでは、軽いモデルへの切り替え、固定の指示文のキャッシュ、出力の上限の3つを順に説明します。どれも仕組みを作り直さずに試せるので、呼び出しの数の次に置きました。副作用が小さい順という考え方は変わりません。

文章の生成は軽いモデルに切り替える

下書きの生成のような用途なら、軽いモデルのHaikuで足りる場面があります。賢さが要らない作業にまで重いモデルを使うのは、もったいない使い方です。重いモデルを標準にしているなら、ここを見直すだけで単価が変わります。

分類やタスク抽出のような決まった型の処理も、軽いモデルから試すのが向いた進め方です。急がない処理は、Batch APIにまわす手も使えます。

切り替えるときは、出力の質を数件見比べてから本番に移します。質が足りなければ、そこだけ元のモデルに戻せば十分です。最初から全部を替える必要はありません。

固定の指示文はキャッシュに載せる

毎回同じ長い指示文を送っているなら、プロンプトキャッシュが使えます。固定の指示文を何度も新しく読ませる無駄を、減らすための機能です。繰り返し使う部分を覚えさせておき、2回目以降の入力の負担を軽くする仕組みです。

自分は検証用のエージェントを、2回目以降のAPIコストを約1/10に抑える設計にしました。ただし設計の話で実測ではありません。

指示文が短いツールでは、効果は小さいかもしれません。長い固定の指示文があるときに検討するのが向いています。効果は使ったあとの利用料で確かめます。

出力の上限を決めておく

max_tokensで出力の長さの上限を決めておくと、想定外に長い返事で料金が膨らむのを防げる。出力が止まらない不具合が起きたときの保険にもなります。設定そのものは一行で足ります。

上限が低すぎると文章が途中で切れてしまう。出力の形が決まっている用途なら、必要な長さに少し余裕を足した値にするのが目安です。

定期実行になる処理は、最初から上限と軽いモデルを決めて組みます。後から直すより、作る時点で安く組むほうが楽だからです。固定の指示文のキャッシュも、同じ時点で入れておきます。

まとめ

利用料の急増は、「どのモデル名で、どの機能が、いつから」をグラフで切り分けてから対策します。順番は、まず呼び出しの数、次にモデル、最後に仕組みの作り直しです。手間の小さい順でもあります。

自分は対策の指示文を作り、実施後の本番確認まで済ませました。効果の判断は2〜3日使ってからにします。古いモデルが消えて軽いモデルに置き換わったかは、まだ確認できていません。

あわせて読みたい：AIの作り話を防ぐ指示の書き方／AIへの任せ方を分ける基準