【ITニュース解説】How I Cut My LLM API Costs by 70% Without Touching My Code

LLM（大規模言語モデル）のAPIを利用する際、そのコストが予想以上に高額になることは少なくない。ある開発者は、サイドプロジェクトで月に約200ドルのLLM API費用を消費していたが、コードに一切手を加えることなく、この費用を70%削減し、月60ドルにまで抑えることに成功した。これは、AIの賢さに対してお金を払っているのではなく、実はAIの「使い方」における無駄に対してお金を払っているという事実に気づいたからだ。

彼が最初に試したのは、モデルの切り替えやプロンプトの圧縮、タスクごとに最も安いモデルを呼び出すようなコード変更だったが、これらは大きな効果をもたらさなかった。真の問題は、AIを「どのように」呼び出しているか、つまりAPIの利用方法にあると彼は悟ったのだ。

LLM APIの料金は、主に二つの要素で決まる。一つは「プロンプト」（AIへの指示や入力データ）にかかる「入力トークン」の料金、もう一つはAIが生成する「回答」にかかる「出力トークン」の料金だ。多くの開発者は、ユーザーに見える「出力トークン」を気にしがちだが、実はコストの多くは「入力トークン」で発生していることが多い。これは、私たちがAIに送る指示や情報が、予想以上に膨大になっているためだ。

例えば、彼の開発した文書検索ツールでは、毎回2000トークン（AIが処理する言葉の最小単位）もの長い「システムプロンプト」（AIに役割や振る舞いを指示する固定の文章）を送信していた。さらにこのツールは、ユーザーの一つの質問に対して、情報の検索、下書きの作成、最終的な仕上げという三つのAPIコールを行っていた。その結果、同じ2000トークンのプロンプトが三回もAIに送られていたのだ。一日に50件の質問があると、静的な指示文だけで一日30万トークン、約1.5ドルの無駄なコストが発生していた。

この無駄を解消した方法は極めてシンプルだ。一つは、同じプロンプトを複数回送らないように、必要な情報を事前に計算して保持（キャッシュ）するか、APIの呼び出しフローを根本的に見直すことだった。彼は、下書きと仕上げのステップを統合し、AIに最初から最終的な回答を生成するよう指示を厳しく変更した。これにより、一つの質問に対するAPIコールが三回から一回に削減され、これだけで全体の費用を約30%削減できたという。AIに「自己修正」させるように指示することで、複数回のやり取りを不要にしたのだ。

次に彼が注目したのは、「キャッシュ」の活用だ。これは、以前にAIが生成した回答を保存しておき、同じ質問が来た場合にはAPIを呼び出すことなく保存済みの回答を返す仕組みだ。彼のSlackボットでは、要約するスレッドの約40%が過去に似たような内容だったり、繰り返し出てくる質問だったりすることに気づいた。そこで、スレッドIDと最終メッセージのタイムスタンプからハッシュ値（データのユニークな識別子）を計算し、それに対応する要約がキャッシュにあれば、すぐにその要約を返すようにした。これにより、毎日100回トリガーされるボットで約40回分のAPIコールを削減できた。カスタマーサポートのチャットボットのように、頻繁に同じ質問が来るようなケースでは、このキャッシュ戦略は費用を50%も削減する可能性を秘めている。

さらに、RAG（Retrieval-Augmented Generation：外部の知識とAIを組み合わせて回答を生成する技術）アプリケーションにおける「コンテキストのトリミング」も大きな削減ポイントだった。彼の文書検索ツールでは、関連しそうな情報を5つの塊（チャンク）に分け、それぞれ500トークン、合計2500トークンもの「コンテキスト」（参照情報）をAIに送っていた。しかし分析の結果、AIはほとんどの場合、最初の二つのチャンクしか使っていないことが判明した。残りの三つは、意味的には近いものの、回答には不要な情報だったのだ。そこで彼は、多くの候補（例えば10チャンク）を検索してくるが、AIにその中から最も関連性の高いものを二つだけ選ばせ、それから本質的な回答を生成させるようにフローを変更した。これにより、入力トークンの使用量を約60%削減し、AIが不要な情報に惑わされなくなったため、回答の品質も向上したという。

また、特定のLLMプロバイダー（OpenAIやAnthropicなど）にこだわるのではなく、複数のプロバイダーを使い分ける「API冗長性」も費用削減に繋がった。プロバイダーによって料金体系やモデルの得意分野が異なるため、シンプルな分類タスクには安価なモデルを、創造的な文章生成には出力トークンが少なく済むモデルを、というようにタスクに応じて最適なプロバイダーとモデルを動的に選択する「ルーター」を構築した。さらに、リアルタイムの応答が不要なタスクでは、バッチ処理（複数のリクエストをまとめて処理すること）のエンドポイントを利用することで、費用を最大50%削減できたケースもあった。

API呼び出しが失敗した場合の「リトライ」戦略も見直す必要があった。通常のリトライでは、失敗すると同じプロンプト（高価なコンテキストを含む）を最初から再送信してしまう。これを避けるため、彼は「チェックポイント」という考え方を導入した。これは、API呼び出しが途中で失敗した場合でも、最後に成功した時点から処理を再開できるようにする仕組みだ。これにより、無駄な再生成を防ぎ、コストと時間の両方を節約できた。

これらの工夫により、月200ドルだった費用は、APIコール数の統合で30%、レスポンスキャッシュで10%、コンテキストのトリミングで20%、複数プロバイダーのルーティングで15%、バッチエンドポイントの利用で10%、合計で約70%の削減を達成した。そして驚くべきことに、これらの変更はユーザーが使う機能には一切影響を与えず、むしろコードベースは無駄な呼び出しが減った分、シンプルになったという。

最終的に、彼はこれら全ての最適化を自動で行ってくれる「ゲートウェイサービス」の利用に行き着いた。これは、複数のLLMプロバイダーへのアクセスを一本化し、コスト制限の設定や、タスクに応じた最適なモデルの自動選択、さらには失敗時のリトライロジックやキャッシュまでを自動で処理してくれるサービスだ。これにより、自分で複雑なルーターを構築・維持する手間を省き、より効率的にコストを管理できるようになった。

まとめると、LLM APIのコストを削減するために必要なのは、大規模なコードの書き換えではなく、APIの呼び出し方やデータの送り方を賢くすることだ。具体的には、繰り返し送られる無駄なプロンプトをなくす、必要以上に多くのコンテキストを送らない、不必要なAPIコールを減らすといった点が重要となる。まず自分のトークン使用量を測定し、どこに無駄があるかを特定し、そして適切な最適化戦略を適用すること。そして、その最適化の多くは、アプリケーションのコードに触れることなく、APIの呼び出し側やサーバーサイドの工夫、あるいは専用のインフラサービスによって実現できるのだ。使わないトークンに対してお金を払うのをやめることこそが、最も賢い節約術と言えるだろう。