業務でAIを使う仕組みを作って、しばらく動かしていたら、ある日「最近、答えがなんだかずれている気がする」「先月より料金が増えている」と言われた。でも、なぜそうなったのか、どこから調べればいいか分からない。本番でAIを動かし始めると、こうした「見えない不調」が起こります。
これに備える考え方が、プロンプトトラッキングです。あまり日本語の解説がない言葉なので、意味と、なぜ必要か、何から始めればいいかを整理します。
プロンプトトラッキングとは：やり取りを1件ずつ記録して、後から追えるようにすること
プロンプトトラッキングは、AI(LLM)を業務で動かすときに、そのやり取りを1回ごとに記録して、後から調べられるようにしておくことです。記録するのは、AIに送ったプロンプト(指示)と、返ってきた回答だけではありません。どのモデルを使ったか、どれだけの分量(トークン)を消費したか、返答までにかかった時間、かかった費用(トークン数から計算した推定のこともあります)なども一緒に残します。
なお、「プロンプトトラッキング」という言葉が指す範囲は、製品や文脈によって少し異なります。この記事では、プロンプトの版とLLMへの呼び出しを紐づけ、入力・出力・モデル・トークン・遅延・参照資料などを後から追えるようにする、という広い意味で使います。これは一般に、LLMトレーシングやLLMオブザーバビリティと呼ばれる領域の一部です。
これは、AIの分野で可観測性(オブザーバビリティ)と呼ばれる、「動いているシステムの中で何が起きているかを、外から分かるようにする」考え方の一部です。ふつうのWebシステムでアクセスログを取るのと同じ発想を、AIのやり取りに広げたもの、と捉えると分かりやすいです。
AIを業務に導入する流れで言えば、資料を渡して精度を上げるRAGや、安全に動かすための設計の次に来る、運用フェーズの話です。作って、守って、そのうえで動き続けているかを見張る、という位置づけです。
なぜ必要か：AIは「作って終わり」にできない
AIを使った仕組みは、一度作れば同じ品質で動き続ける、とはかぎりません。次のような理由で、知らないうちに振る舞いが変わります。
- 固定したバージョンではなく、提供側が更新するモデル名を使っていると、同じ名前でも中身が変わることがある。
- プロンプトを少し直したら、別の場面で答えが崩れた。
- 参照させている資料(RAGなど)が増減して、回答が変わった。
- 利用が増えて、費用や遅延がふくらむ。
記録が何も残っていないと、「いつからおかしくなったのか」「どの変更が原因か」を追えません。プロンプトトラッキングは、こうした変化に後から気づき、原因までたどるための土台です。作ったあとに安心して使い続けるための、運用の仕組みだと考えてください。
何を記録するのか
具体的には、1回のやり取りごとに、次のような情報をまとめて残します。
- 送ったプロンプト(入力)と、返ってきた回答(出力)。
- 使ったモデルの種類とバージョン。
- 消費したトークン量と、かかった費用(トークン数から計算した推定のこともあります)。
- 返答までの時間(遅延)と、成功・失敗やエラーの内容。
- RAGを使っているなら、そのとき参照した資料。
- 実行した日時、どの機能からの呼び出しか、どの利用者か(氏名やメールではなく、識別用の仮名化したID)。
発展的には、1回の回答の中で行われた検索やツールの実行、それらをつなぐ一連の処理も、まとめて記録します。
こうしておくと、あとで「この変な回答は、どの入力で、どの資料を見て、どのモデルが出したのか」を1件単位でたどれます。
プロンプトの「版」も一緒に管理する
もう一つ、プロンプトトラッキングで欠かせないのが、プロンプトそのものの版(バージョン)を管理することです。
プロンプトは、運用しながら少しずつ手を入れていきます。そのとき、どの版のプロンプトが、どんな回答を出していたかを紐づけて記録しておくと、「前の書き方のほうが良かった」「この修正で悪化した」といった比較ができます。行き当たりばったりで直すのではなく、記録を根拠に改善できるようになります。
何が分かるようになるか
記録がたまると、次のようなことに使えます。
- 品質の調査：おかしな回答が出たときの条件を確認し、原因を調査しやすくなる。ハルシネーション(もっともらしい嘘)の調査にも役立つ。なお、LLMは同じ入力でも必ず同じ回答を返すとは限らないため、完全な再現というより、条件の確認や比較がしやすくなる、と捉えます。
- コストの管理：どの機能が費用を使っているかが見え、増加に早く気づける。
- 遅延・障害の把握：応答が遅い、失敗している箇所を特定できる。
- 品質の推移：記録に利用者の評価やテスト結果を紐づけることで、モデル更新やプロンプト変更の前後で、品質が良くなったか悪くなったかを比べられる。記録を残すだけでは「変わった」ことは分かっても「良くなったか」までは分からないため、評価とセットにします。
記録すること自体が、新しいリスクになる
ここはZELKとして強くお伝えしたい点です。プロンプトや回答を無条件に保存すればよい、というわけではありません。入力や回答には、顧客の氏名やメールアドレス、社内文書や営業情報、APIキーやトークン、契約情報、RAGで取得した機密資料などが混じることがあります。
つまり、何も考えずにすべてログへ保存すると、監視のために作ったログが、新しい情報漏洩の経路になりかねません。実際、この分野のツールでも、保存前に入力・出力をマスキングする、特定の記録は残さない、閲覧できる人を制限する、といった機能が用意されています。
だからこそ、保存前に機密情報をマスキングする、利用者は氏名ではなく識別用のIDで残す、ログを見られる人を制限する、保存期間を決めて古い記録を消す、といった設計が要ります。「何を記録するか」だけでなく、「何を記録しないか」も、プロンプトトラッキングの重要な設計です。守り方の考え方は騙されても被害が出ないAIの設計にも通じます。
小さく始める
専用のツールもあります(Datadog、Langfuse など、この可観測性の分野の製品)。ただ、いきなり導入しなくても、考え方は小さく始められます。順番が大事で、最初から入力・回答を全部保存しないのがコツです。
- まずは、内容そのものではなく、メタデータから記録する。日時、機能名、使ったモデル、プロンプトの版、処理時間、トークン数、成功・失敗など。
- 入力や回答の中身も残す場合は、個人情報や機密情報を取り除いたうえで、閲覧できる人と保存期間を決める。
- プロンプトを直したら、版に番号や日付をつけて、いつ変えたかを残す。
- 問題のあった処理を、記録から後追いできるようにしておく。
この「必要なものを、安全な形で、後から追える状態にする」だけでも、運用の安心感は大きく変わります。仕組みが育ってきたら、専用ツールへ進む、という順序が現実的です。
まとめ
- プロンプトトラッキングは、AIのやり取り(プロンプト・回答・モデル・トークン・費用・遅延・参照資料など)を1件ずつ記録し、後から追えるようにすること。LLMトレーシング/オブザーバビリティと呼ばれる領域の一部。
- AIは作って終わりにできない。モデル更新やプロンプト変更で品質は変わるため、記録がないと原因を追えない。
- プロンプトの版を管理し、利用者の評価やテスト結果と紐づけると、品質が良くなったか悪くなったかまで追える(記録だけでは分からない)。
- ただし記録自体が新しいリスクになる。入力・回答に個人情報や機密が混じるため、マスキング・仮名化ID・閲覧制限・保存期間の設計が要る。何を記録しないかも設計のうち。
- 始めるときは、まずメタデータから。中身を残すなら機密を除き、権限と保存期間を決めてから。
