AIを組み込んだ業務システムを稼働させた後、必ずと言っていいほど出てくるのが「このAIの回答、なぜこうなったのか」という問い合わせです。請求書の読み取り結果が1件だけおかしい、問い合わせ対応チャットが社内規定と違う案内をした、見積もりの分類が想定と違う——こうした報告を受けたとき、原因を追えるかどうかはログの設計で決まります。
従来の業務システムであれば、プログラムのコードを読めば「なぜそうなったか」は原理的に追えました。しかしAI、特に大規模言語モデル（LLM：大量の文章を学習し、自然文で応答するAIモデル）を使う場合、同じ入力でも出力が揺れることがあり、コードを読んでも答えは出ません。残っている記録がすべてです。
本記事では、AI機能を受注開発する際に「何を、どこまで、どう残すか」を、発注側の判断材料として整理します。
なぜAI機能では従来のログでは足りないのか
一般的な業務システムのログは、「いつ・誰が・どの機能を使った」という操作記録と、エラー発生時のスタックトレース（エラーが起きた処理の経路）が中心です。これはAI機能でも必要ですが、それだけでは「なぜその出力になったか」に答えられません。
理由は主に3つです。
- 非決定性：LLMは同じ質問でも毎回まったく同じ文章を返すとは限りません。再現実験で問題が出ないことがあります。
- 入力が構造化されていない：画像、PDF、自由記述の文章など、入力そのものが多様で、「どんなデータが来たか」を保存しておかないと検証できません。
- 中間処理が見えない：社内文書を検索してからAIに渡すRAG（検索拡張生成：外部データを検索し、その内容を根拠としてAIに回答させる方式）のような構成では、「どの文書を拾ったか」が結果を大きく左右します。
つまり、AI機能のログ設計とは「あとで再現・検証できる状態を作る」ことだと考えるのが実務的です。
残すべき7つの記録項目
開発ベンダーと仕様を詰める際、最低限確認しておきたい記録項目を整理します。
| 項目 | 内容 | これがないと困ること |
|---|---|---|
| リクエストID | 1回の処理に振る一意の識別子 | 複数の記録を突き合わせられない |
| 入力データ | ユーザーが入力した文章、アップロードしたファイルの識別情報 | 何を投げたか分からず再現不能 |
| プロンプト全文 | AIに実際に送った指示文（テンプレート＋変数が展開された後のもの） | 指示の組み立てミスを特定できない |
| 参照データ | RAGで検索された文書のIDとスコア、使用した社内データ | 「どの文書を根拠にしたか」が不明 |
| モデル情報 | モデル名、バージョン、temperature等のパラメータ | モデル更新前後の挙動差を切り分けられない |
| 出力全文 | AIからの生の応答（加工前） | 後処理のバグかAIの問題か判別できない |
| 処理メタ情報 | 処理時間、トークン数、エラー・リトライの有無 | コストと性能の分析ができない |
特に見落とされやすいのが「プロンプト全文」と「出力の生データ」です。プロンプトはテンプレートに変数を埋め込んで生成することが多く、テンプレートだけ保存していても再現できません。出力も、アプリ側でJSONに整形したり不要文を削ったりした後のものだけ残すと、問題の切り分けができなくなります。
モデルのバージョンは必ず記録する
外部のAPIサービスを使う場合、モデルは提供側の都合で更新されます。「先月まで正しく動いていたのに急に精度が落ちた」という相談の背景に、モデル側の変更があるケースは珍しくありません。どのバージョンで処理したかを記録しておけば、少なくとも切り分けの出発点になります。
個人情報と機密情報をどう扱うか
ログを厚くすると、当然ながら個人情報や機密情報がそのまま蓄積されます。ここは設計段階で方針を決めておく必要があります。
日本国内でAIを扱う際に参照されることが多いものとして、個人情報保護法、個人情報保護委員会が公表している生成AIサービスの利用に関する注意喚起、総務省・経済産業省によるAI事業者ガイドラインなどがあります。また、EU域内の事業に関わる場合はGDPR（EU一般データ保護規則）やEU AI Actの適用可能性も検討対象になります。自社に適用される範囲は業種・取引先によって変わるため、具体的な判断は最新の原文や専門家の確認を経てください。
実務上の選択肢としては、次のような組み合わせが考えられます。
| 方式 | 内容 | 向いている場面 |
|---|---|---|
| 全量保存 | 入出力をそのまま保存 | 社内限定・機密度の低いデータ |
| マスキング保存 | 氏名・電話番号等を伏せ字化して保存 | 個人情報を含むが構造の検証はしたい場合 |
| 参照保存 | 本体は業務DBに置き、ログにはIDのみ記録 | 重複保管を避けたい場合 |
| ハッシュ保存 | 内容の一致判定だけできる形に変換 | 「同じ入力か」の確認で足りる場合 |
保存期間も決めておきます。長期保存は調査には有利ですが、情報漏えい時の影響範囲が広がります。「詳細ログは90日、集計値は3年」のように粒度ごとに期間を分ける設計がよく採られます。期間はあくまで一例で、業種の規制や社内規程に合わせて設定してください。
実装で詰まりやすい箇所
ログが巨大化してコストを圧迫する
プロンプト全文を残すと、1件あたり数千〜数万文字になることがあります。RAGで参照した文書まで丸ごと保存すると、ログの保存料金が本体の処理コストを上回ることもあり得ます。対策としては、参照文書は本文ではなくIDと抜粋のみを残す、詳細ログは一定期間後に圧縮・集計のみ残す、といった設計が現実的です。
非同期処理でリクエストIDが途切れる
ファイルのアップロードを受けて、裏側で順次AI処理を走らせるような構成では、処理が複数のプロセスにまたがります。ここでリクエストIDを引き継ぐ仕組みを入れておかないと、「この結果はどのアップロードのものか」を追えなくなります。設計の初期にID伝播のルールを決めておくべき部分です。
ログを見る手段がない
記録はしているが、確認できるのは開発ベンダーだけ、という状態もよくあります。日常的な問い合わせ対応を社内で完結させたいなら、管理画面から「この処理のときのAIの入出力」を担当者が参照できるようにしておく価値があります。ただし閲覧権限は絞り、誰がログを見たかも記録する——いわゆる監査ログ（システム上の重要操作を追跡するための記録）を併せて設計します。
人間の修正が記録されない
AIの出力を人が確認・修正して確定させる運用では、「AIが何を出し、人がどう直したか」の差分が最も価値のあるデータになります。修正後の値だけ保存していると、AIの精度改善に使える情報が丸ごと失われます。発注時の要件に入れておきたい項目です。
発注時にベンダーへ確認すべきこと
技術的な細部まで理解する必要はありませんが、次の点は見積もり段階で確認しておくと後の認識違いを防げます。
- プロンプト全文とAIの生出力を保存する仕様になっているか
- モデル名・バージョン・パラメータを記録しているか
- 個人情報のマスキング方針と保存期間はどうなっているか
- ログの保管先はどこか（国内か国外か、自社管理か）
- 社内担当者がログを参照する画面はあるか、権限はどう制御するか
- 人の修正差分を取得する仕組みはあるか
- ログの保管コストは月額いくら程度を見込んでいるか
たとえば次のような場面を想定して聞くと話が具体化します。「請求書読み取りで、金額が1件だけ1桁違っていたという報告が3日後に来ました。原因を特定するために、どの記録をどう見ますか」。この問いに具体的な手順で答えられるなら、ログ設計は考えられていると判断してよいでしょう。
まとめ
AI機能のログ設計は、「障害対応のための保険」であると同時に、精度改善のための資産でもあります。特に人間が最終確認を行う運用では、AIの出力と人の修正の差分が、次の改善サイクルの材料になります。
要点を整理します。
- AIは非決定性があるため、コードではなく記録でしか原因を追えない
- プロンプト全文・AIの生出力・モデルバージョンの3点は特に欠かせない
- RAG構成なら「どの文書を参照したか」も必須
- 個人情報の扱いは、マスキング方針と保存期間を設計段階で決める
- ログの保管コストは事前に試算し、粒度ごとに保存期間を分ける
- 社内担当者が参照できる手段と、閲覧権限の制御をセットで用意する
ログは後から追加しようとすると、過去分が存在しないため「問題が起きてから1か月待つ」ことになります。開発の初期段階、できれば要件定義の時点で、どこまで残すかを決めておくことをおすすめします。AI機能の導入を検討されている場合は、こうしたログ設計の方針も含めてご相談ください。