AI APIのトークン最適化｜コスト削減の実践方法

VFAのベトナム人エンジニアが執筆した記事です。原文は、こちらのベトナム語版です。なお、実際の開発案件で発生した事例ではありませんので、あらかじめご了承ください。

応答品質を保ちながらAPIコストを削減する

物語はごく普通のリクエストから始まった!!!

「一見なんの変哲もないリクエストがきっかけで、チーム全体がAI APIコストがほぼ倍増していた原因を突き止めることになった。」

待てよ、何かがおかしい……

ある月曜日の朝、いつものようにプロジェクトのAI APIコストを確認するためダッシュボードを開いた。

思わず二度見してしまう数字があった――「コストがほぼ倍増している」!? 奇妙なことに、その週は新規ユーザーも増えておらず、AIモデルも変更しておらず、新機能もリリースしていなかった。

チーム全員の最初の反応はほぼ同じだった。「きっとプロンプトがどんどん長くなっているんだろう」。これは筋が通っているように聞こえた。何ヶ月も開発を重ねる中で、AIがより正確に答えられるようルールが次々と追加されていたからだ。エンジニアとして、ログを見ずに結論を出さないという習慣があるので、とあるリクエストのログを開いて確認してみた。

📊 リクエストのログ

System Prompt        : 612トークン
Conversation History : 4,382トークン
RAG Documents        : 1,756トークン
User Question        : 48トークン

改めて見直すと、プロンプトが消費していたのはわずか600トークン強で、会話履歴はすでに4,000トークンを超えていた。その瞬間、「もしかしたらチーム全体が犯人を見誤っていたのでは」と気づいた。

本当の「犯人」を見つけるため、まず「トークンとは何か」を再確認することから始めた。

トークンとは、AIがテキストを読み取り処理する際の最小単位である。同時に、OpenAI、Anthropic、Googleなど多くのAIプロバイダーがAPIコストを算出する際に用いる単位でもある。

つまりAIはAPI呼び出しの回数ではなく、各リクエストで処理するトークンの総数によって課金される。

例えば、2つのアプリケーションがそれぞれAIを1回呼び出すとする。

• アプリAは約500トークンを送信する。
• アプリBは約5,000トークンを送信する。

API呼び出し回数は同じでも、AIがより多くのデータを処理しなければならないため、アプリBのコストは高くなる。

したがって、AIコストを最適化するには、API呼び出し回数を減らすだけでなく、各リクエストで送信するトークン数を減らすことが重要になる。

なぜトークンがコストに影響するのか?

実際のリクエストは、ユーザーの質問だけで構成されているわけではない。システムプロンプト、会話履歴、RAGから取得したドキュメント、その他のコンテキストデータも含まれている。

AIが最も多くのトークンを消費する要素はどれか?

トークンについて再確認した後、本当の「犯人」を突き止めるため手がかりを追い始めた。

原因の絞り込みを開始

システムをデバッグするときと同じように、当てずっぽうで進めるのではなく、リクエストの各要素を一つずつ切り分け、どこが最もトークンを消費しているかを調べ始めた。

調査対象の要素:

• プロンプト (Prompt)
• 会話履歴 (Conversation History)
• RAGドキュメント (RAG Documents)
• ツール呼び出し (Tool Calling)
• 出力トークン (Output Token)

調査結果まとめ

結論:

分析の結果、トークン数を押し上げている主な原因はConversation History(会話履歴)とRAG Documents(RAGドキュメント)の2つであることが分かった。会話履歴は、システムが毎回のリクエストで会話履歴全体を再送信するために多くのトークンを消費し、RAGドキュメントは現在の質問と無関係なドキュメントやチャンクを大量に含めてしまうことが原因だった。

さらに、Tool Calling(ツール呼び出し)とOutput Token(出力トークン)もコスト増加の一因となっている。ツールが不要なフィールドを大量に返したり、AIが実際の必要量より長い回答を生成したりするためだ。一方、プロンプトはリクエスト全体のトークン数のうちごく一部しか占めないため、今回のケースでは主な原因ではなかった。

したがって、プロンプトを短くすることだけに注力するのではなく、会話履歴の最適化、取得するRAGドキュメントの制限、ツール呼び出しから得るデータの絞り込み、そして出力の長さの制御を優先すべきである。

とはいえ、原因を特定できたのはまだ第一歩に過ぎない。次のセクションでは、これらの最適化手法を実際のカスタマーサポートチャットボットに適用する方法を紹介する。

カスタマーサポートチャットボットにおけるトークン最適化

💡 前提条件

あなたは（ベトナムの）スマートフォン販売サイト向けのカスタマーサポートチャットボットを構築している。ユーザーが「iPhone 16 Proは24ヶ月保証がありますか?」と質問した。

📤 最適化前のリクエスト

✓ System Prompt (600トークン)
✓ Conversation History
  過去35回分の会話
  - 色
  - 価格
  - 分割払い
  - 店舗住所
  - 返品ポリシー
  (4,200トークン)
✓ RAG Documents
  - 保証ポリシー(18ページ)
  - 購入ガイド(25ページ)
  - 会社紹介(12ページ)
  - 商品カタログ(80ページ)
  (2,300トークン)
✓ Tool Calling
  customerName, phone, email, address,
  orderHistory, rewardPoint, favoriteProducts, ...
  (800トークン)
✓ User Question
  iPhone 16 Proは24ヶ月保証がありますか?
  (18トークン)

合計すると、AIはこの非常にシンプルな質問に答えるためだけに、約8,000トークンを処理しなければならなかった。

🔍 ログを確認した結果

リクエストを各要素に分解してみると、トークンの大部分はユーザーの質問そのものからではないことが分かった。古い会話履歴、関連性のないドキュメント、Tool Callingから得られる余分なデータこそ対処すべき部分だった。データを無計画に削るのではなく、以下の4つのステップで各要素を最適化した。

ステップ1 - 会話履歴(Conversation History)を圧縮する:

システムはもはや35回分の会話全体を毎回送信しない。過去の会話は短い要約にまとめられ、直近8件のメッセージのみを保持することで、AIは現在の文脈を理解できるようにした。

ステップ2 - 本当に関連性のあるRAGドキュメントのみを取得する:

ドキュメントは小さなチャンクに分割された。ユーザーが保証について質問すると、システムは質問内容に基づいて検索を行い、購入ガイド・会社紹介・商品カタログをすべて含めるのではなく、関連度が最も高いTop 3チャンクのみを送信する。

ステップ3 - Tool Callingから得るデータを絞り込む:

これまでツールは顧客プロフィール全体を返していた。保証期間についての質問であれば、AIが実際に必要とするのは商品名と保証期間だけである。

最適化前:

{ customerName, phone, email, address, orderHistory, rewardPoint, favoriteProducts, ... }

最適化後:

{ productName, warrantyPeriod }

これら4つの変更を行った後、トークンの最適化が回答内容を変えていないかを確認するため、同じ質問に対する最適化前後の回答を比較した。

📤 最適化後のリクエスト

✓ System Prompt (600トークン)
✓ Conversation History
  過去の会話の要約
  + 直近8件のメッセージ
  (650トークン)
✓ RAG Documents
  保証に関連するTop 3チャンク
  (350トークン)
✓ Tool Calling
  productName, warrantyPeriod
  (40トークン)
✓ User Question
  iPhone 16 Proは24ヶ月保証がありますか?
  (18トークン)

最適化後の応答品質を確認する:

トークンを削減することに意味があるのは、最適化後の回答がユーザーのニーズに正しく応えられている場合のみである。そこで、リクエスト変更の前後で同じ質問セットを再実行し、以下の3つの基準で比較した。

• 回答が保証ポリシーの内容と一致しているか。
• ユーザーの質問を解決するのに十分な直接的な情報を提供しているか。
• 誤った情報、文脈の欠如、あるいは無関係な情報が含まれていないか。

「iPhone 16 Proは24ヶ月保証がありますか?」という質問に対して、最適化前後どちらのバージョンも正しい保証期間と適用条件を返した。最適化後のバージョンはより簡潔になったが、必要な情報は失われていなかった。

🎯 結果

Conversation History、RAG Documents、Tool Callingを最適化した結果、リクエストあたりのトークン総数は約8,000から1,600トークンへ減少し、約80%の削減となった。

💬 最適化前後の回答比較

トークン削減が応答品質に影響していないかを確認するため、リクエスト最適化の前後で同じ質問を再実行した。

質問: 「iPhone 16 Proは24ヶ月保証がありますか?」

回答:

所感:

• 保証期間に関する情報はそのまま保持されていた。
• 適用条件も変わらなかった。
• 最適化後のバージョンはより簡潔だが、ユーザーの質問に十分答えられていた。

💡 得られた教訓

重要なのはプロンプトを短くすることではなく、AIに不要なものを読ませないことである。リクエスト数が日々増加する中で、1リクエストあたり約8,000トークンから1,600トークンへ削減することは、運用コストに非常に大きな差を生み出す一方で、応答品質はほとんど変わらない。

🏁 まとめ

これらの変更を適用した後、最初に確認したのは回答の品質ではなく、AI APIコストのダッシュボードだった。数字は目に見えて下がり始めた一方、ユーザーは利用体験の変化にほとんど気づかなかった。

興味深いのは、より安価なモデルに切り替えたわけでも、機能を削減したわけでも、プロンプトを全面的に書き直したわけでもないという点だ。私たちが変えたのは、システムがAIにコンテキストを提供する方法――より少なく、しかしより正確に送ることだけだった。AIは会話履歴全体やドキュメント、無関係なデータをすべて読む必要がなく、質問に答えるために本当に必要な情報だけを受け取るようになった。

調査の全プロセスを振り返ると、AIコストが単一の原因だけで増加することはほとんどないと気づいた。もはや価値のなくなった会話履歴の一部、取得しすぎたRAGドキュメント、大きすぎるTool CallingのJSON、必要以上に長い回答――それぞれは些細に見えても、1日に何千件ものリクエストにわたって積み重なると、無視できないコストになる。

以前は、AI APIコストが上がるたびに「自分のプロンプトはもう最適化されているだろうか?」と自問していた。今回の調査を経て、より適切な問いは「AIは自分が送っているデータすべてを本当に必要としているのか?」だと思うようになった。

この視点を変えるだけで、より多くの最適化の機会に気づきやすくなるはずだ。

この記事で共有した経験が、AI統合アプリケーションを構築する際の新たな視点となれば幸いである。次回、コストを抑えるためにモデルの変更や機能削減を考える前に、まずは任意のリクエストのログを開いてみてほしい。

多くのAIプロジェクトにおいて、コストが上がるのはモデルが高すぎるからではなく、実際に必要な量以上のデータをAIに送っているからである。この視点を変えるだけで、応答品質を犠牲にすることなく、かなりのコストを削減できるはずだ。

参考文献

[1] OpenAI - What are tokens and how to count them?
[2] Anthropic - Context windows
[3] Liu et al. - Lost in the Middle: How Language Models Use Long Contexts
[4] OpenAI - Controlling the length of model responses
[5] OpenAI - Prompt Caching
[6] Anthropic - Prompt caching
[7] Google AI for Developers - Context caching
[8] OpenAI - How to check token usage
[9] OpenAI API Pricing