【ITニュース解説】Measure Cost per Handled Enquiry: A Small Logging Pattern for LLM Workflows

AIを活用したシステム開発が進む中、システムエンジニアを目指す上で、その運用の効率性やコストを理解することは非常に重要だ。特に、大規模言語モデル（LLM）を使った自動化ワークフローにおいては、サービスの提供にかかる実際の費用を正確に把握することが成功の鍵となる。プロジェクト開始前に算出されるコスト見積もりはあくまで予測に過ぎず、実際にシステムが稼働してからでないと、真のコストは見えてこない。そこで、記事では「1件の問い合わせあたりのコスト」という指標に注目し、これを効率的に測定するためのシンプルな方法が提案されている。これは、顧客からの問い合わせメッセージがシステムに到達してから、完全に解決されるまでのすべてのプロセスにかかる費用を指し、特に小規模なビジネスのAI自動化において極めて有用な指標となる。

この「1件の問い合わせあたりのコスト」を算出するためには、具体的にいくつかの種類のデータを記録する必要がある。まず、LLMとのやり取りにかかるコストだ。これは「モデルのトークン入出力」として記録される。LLMはテキストを「トークン」という単位で処理し、入力されたテキストの量（入力トークン）や、AIが生成した応答の量（出力トークン）に応じて課金されることが多い。したがって、LLMへの各呼び出しごとに、どれだけのトークンが入力され、どれだけ出力されたかを記録することが基本となる。次に、「メッセージングイベント」だ。顧客とのやり取りにチャットアプリなどのメッセージングサービスを利用する場合、メッセージの送信数やそのカテゴリ（サービスメッセージ、マーケティングメッセージなど）に応じて費用が発生することがあるため、これらも記録対象となる。さらに、「自動化プラットフォームの実行回数またはタスク数」も重要だ。これは、問い合わせの処理を自動化するためのプラットフォームが、どれだけ起動し、タスクを実行したかを示すもので、プラットフォームの利用料に直結する。最後に、「人間の作業時間」だ。AIによる自動化が進んでも、最終的な承認や、AIが生成したドラフトの修正など、人間が介入する場面は存在する。これらの「人間が費やした時間」もコストの一部であるため、例えば承認作業にかかった時間などを分単位で記録する。これらの要素を1件の問い合わせごとに記録することで、多角的にコストを把握できる。

これらのデータを効率的に記録するために、記事では非常にシンプルな「イベントログ」のパターンが紹介されている。これは、jsonlという形式のファイルに、イベントが発生するたびに一行ずつデータを追記していくというものだ。jsonlは「JSON Lines」の略で、各行が独立したJSONオブジェクトになっているため、後からデータを読み込んで処理しやすいという利点がある。具体的には、Pythonのプログラムでlog_eventという関数を作成し、この関数を使ってイベントを記録する。この関数は、そのイベントがどの問い合わせに関するものかを示す一意の「問い合わせID（enquiry_id）」、何のイベントが発生したかを示す「イベント種別（kind）」、そのイベントの「数量（qty）」、そして必要に応じて追加情報を含む「メタデータ（meta）」を受け取る。例えば、「tokens_in」という種別で入力トークン数812を記録したり、「human_minutes」という種別で人間の作業時間2分を記録したりする。この方法のメリットは、既存のログファイルにただ追記していくだけなので、データベースを構築するような複雑な仕組みを必要とせず、手軽に導入できる点にある。

イベントログに記録された生データは、そのままだとコストを把握しにくい。そこで、記事では、これらのデータを「問い合わせごとのコスト」として集計する方法も示されている。集計には、それぞれのイベント種別に対応する「単価（rate）」をあらかじめ定義しておく必要がある。例えば、トークン1つあたりの料金、メッセージ1通あたりの料金、プラットフォームの実行1回あたりの料金、人間の作業1分あたりの料金などだ。これらの単価は、実際に利用しているサービスの請求書などを参照して設定する。集計プログラムは、ログファイルからイベントデータを一行ずつ読み込み、各イベントの種別（kind）と数量（qty）を参照する。そして、定義しておいた単価を数量に乗じることで、そのイベントにかかった費用を計算する。これを同じ「問い合わせID」を持つすべてのイベントに対して繰り返し、最終的に問い合わせIDごとに総コストを集計する。このプロセスにより、それぞれの問い合わせが最終的にいくらかかったのか、具体的な数値で把握できるようになる。

このようにして「1件の問い合わせあたりのコスト」を測定し、分析することで、システムの運用における様々な重要な洞察が得られる。記事が指摘する最もよくあるケースは、「人間の作業時間がトークン費用よりもコストを支配している」というものだ。もしAIが生成したドラフトの承認や修正に多くの時間がかかっているなら、なぜドラフトが頻繁に却下されるのか、その原因を深く探る必要があるだろう。例えば、AIの精度が低いのか、それともプロンプトの指示が不明瞭なのかといった点を改善することで、人間の介入時間を減らし、全体コストを削減できる可能性がある。また、「長いプロンプト」もコストに直結する問題だ。もし1件の問い合わせあたりのトークンコストが徐々に増加している場合、LLMに与える入力データ（コンテキスト）が過剰になっていないかを確認する必要がある。毎回大量の情報を詰め込んでいると、不要なトークン費用がかさんでしまうため、プロンプトの内容を最適化することが求められる。さらに、「リトライ」の問題もコスト増の原因となる。自動化プラットフォームの実行回数が1件の問い合わせあたりで異常に多い場合、それはワークフローの途中で何らかのステップが失敗し、何度も再実行されている可能性を示唆している。失敗の原因を特定し、ワークフローを安定させることで、無駄なリソース消費を防ぐことができる。これらの数値は、単なるコスト把握にとどまらず、システムの改善点を見つけ出し、効率を向上させるための重要な手がかりとなるのだ。

これらのコスト測定は、決して複雑なシステムを必要とするものではない。記事では、「追記専用のJSONLファイル、シンプルな集計スクリプト、そして週に一度のデータ確認」で十分だと強調されている。初期段階から高機能なダッシュボードや複雑な分析ツールを導入するよりも、まずは最小限の仕組みで継続的にデータを収集し、定期的に確認する習慣を身につけることが重要だ。必要であれば、その後に高度な分析ツールや可視化機能を導入することも考えられるが、まずは地道な記録と確認から始めるのが賢明だ。このようなシンプルなアプローチは、小規模なビジネスやスタートアップ企業にとって特に有効であり、コストをかけずにAI自動化ワークフローの健全性を保つための第一歩となるだろう。システムエンジニアとして、このような費用対効果の高い測定と改善のサイクルを理解し、実践できる能力は、将来のキャリアにおいて非常に価値のあるものとなる。