目次
生成AIを業務に組み込むと、いつか必ず「結果がおかしい」という連絡が来ます。そのとき、原因をどれだけ早く特定できるかは、AIの性能ではなくログの設計で決まります。
私たちはOCR（帳票の読み取り）の本番運用で、AI呼び出しの結果が想定と違う事象に当たりました。ところがログには、AIの返答を整形した後の結果しか残っていませんでした。結果として、原因の特定に半日かかりました。
その後、AIの返答を加工せず全文で残すようにしたところ、同種の事象は数分で原因を特定できるようになりました。この記事では、ログに何を残すか、どこへ出すか、障害時にどう辿るかを整理します。
この記事の結論
- パース後の結果だけのログでは、AIの不具合は追えない
- 生レスポンス全文を、識別子と実行時刻とともに残す
- AIは出力が揺れる前提で、再現できる記録を残す
実案件で起きたこと：原因特定に半日かかった
実案件（匿名）の、OCR本番運用での出来事です。帳票をAIに読み取らせ、返ってきた内容をプログラムで整形（パース）してシステムに取り込む仕組みでした。
ある日、取り込まれた結果が想定と違うという事象が起きました。ログを確認すると、残っていたのはパース後の結果だけです。そのため、次のどれが原因なのかを判別できませんでした。
- AIがそもそも間違った内容を返したのか
- AIの返答は正しく、パース処理で崩れたのか
- 途中でリトライが走り、別の返答が採用されたのか
再実行して確かめようにも、AIは同じ入力でも毎回まったく同じ返答をするとは限りません。当時の状況を再現できず、推測と検証を繰り返して半日が過ぎました。
生成AIの不具合が調査できない原因
原因は、処理の途中にある「AIの生の返答」が記録から抜け落ちていたことです。
問題は2つに分けられます。
- 切り分けができない：パース結果しか無いと、AI側の問題か、変換処理の問題かを判断する材料がありません。
- 再現ができない：通常のプログラムなら同じ入力で同じ結果が出るため、再実行で原因を追えます。生成AIは出力が揺れるため、再実行しても同じ返答が得られる保証がありません。
つまり、その時点の記録を残していなければ、後から事実を確かめる手段がほぼ無くなります。
生成AIのログに残すべき5項目
現在、私たちがAI呼び出しのたびに残しているのは次の5項目です。
| 項目 | 何のために残すか |
|---|---|
| 対象ファイルの識別子 | 問い合わせを受けた帳票と、ログを結び付ける |
| 実行時刻 | いつの処理かを特定し、前後の処理と照らし合わせる |
| 生レスポンス全文 | AIが実際に何を返したかを、加工なしで確認する |
| パース結果 | 生レスポンスと並べて、変換で何が変わったかを見る |
| リトライの有無 | 最終的にどの返答が採用されたかを把握する |
中心になるのは生レスポンス全文です。ここで「全文」にこだわるのは、要約や一部の抜き出しでは、パースが崩れた箇所がちょうど欠けていることがあるからです。問題の多くは、返答のどこか一部の書き方の揺れで起きます。
残りの4項目は、その全文を「どの帳票の、いつの、何回目の処理か」に結び付けるための情報です。生レスポンスだけあっても、該当するものを探し出せなければ調査は速くなりません。
ログの出し先の選び方
出し先を選ぶときは、次の3点を満たすかで判断します。
- 識別子で引ける：問い合わせの起点は、たいてい「この帳票がおかしい」です。対象ファイルの識別子で検索し、該当する記録にすぐ辿り着ける場所を選びます。
- 全文が途中で切れない：生レスポンスは長くなることがあります。出し先によっては長い文字列の扱いに制限がある場合もあるため、全文がそのまま残るかを事前に確認します。仕様は変わるため、最新の条件は各サービスの公式情報で確認してください。
- 閲覧できる人を限定できる：生レスポンスには帳票の中身がそのまま含まれます。通常の動作ログと同じ感覚で広く共有せず、見られる人と保存期間を決めて扱います。
特に3点目は見落としがちです。調査のための記録が、そのまま情報漏えいの入口にならないように設計します。
障害時の辿り方
「結果がおかしい」と連絡を受けたら、次の順で辿ります。
比較の結果で、原因はおおむね次のように切り分けられます。
| 見えたこと | 疑う場所 |
|---|---|
| 生レスポンスの時点で内容が違う | AI側（指示の出し方や入力の状態） |
| 生レスポンスは正しく、パース結果が違う | パース処理 |
| リトライがあり、採用された返答が想定外 | リトライ時の扱い |
以前は「どこを疑うか」を決めるまでに時間を使っていました。今は記録を並べて見るだけで、疑う場所が一つに絞れます。半日かかっていた調査が数分で済むようになったのは、この切り分けを記録が肩代わりしてくれるからです。
判断軸：AIは出力が揺れる前提で記録する
従来のシステムでは「エラーが出たら再実行して確かめる」が通用しました。生成AIではその前提が崩れます。同じ入力でも返答が揺れる以上、その時点の記録だけが事実を確かめる手段です。
ですから、AIを業務に組み込むときは、動かすことと同じくらい「後から再現できる記録を残すこと」を最初の設計に含めるべきです。問題が起きてからログを足しても、その問題の記録は残っていません。
まとめ
- パース後の結果だけのログでは、AI側と変換処理のどちらが原因か切り分けられない
- 残すのは識別子・実行時刻・生レスポンス全文・パース結果・リトライの有無の5項目
- 出し先は、識別子で引けて、全文が残り、閲覧者を限定できる場所を選ぶ
- AIは出力が揺れる前提で、後から再現できる記録を最初から設計に入れる
よくある質問
Q. 生成AIのAPIのログには何を残せばよいですか？ 対象ファイルの識別子、実行時刻、生レスポンス全文、パース結果、リトライの有無の5つです。特に生レスポンス全文があれば、AIの返答と変換処理のどちらに原因があるかをすぐに切り分けられます。
Q. パース後の結果だけをログに残すと何が困りますか？ 結果が想定と違ったとき、AIの返答自体がおかしいのか、変換処理で崩れたのかを判別できません。AIは同じ入力でも出力が揺れるため、再実行しても同じ状況を再現できず、調査が長引きます。
Q. 生レスポンスには帳票の内容が含まれますが、ログに残して大丈夫ですか？ 残すこと自体は必要ですが、閲覧できる人を限定し、保存期間を決めて扱うのが前提です。外部共有の資料には内容を出さず、調査は識別子で該当ログを引いて社内で完結させる運用にします。
RENOYでは、AI-OCRや生成AIを業務に組み込む際に、読み取りの精度だけでなく「問題が起きたときに追える記録」まで含めて設計しています。「AIを入れたが、おかしな結果の原因が分からない」という段階のご相談も歓迎です。まずはお気軽に無料個別相談（オンライン・60分）をご利用ください。サービス内容をまとめた資料は資料請求からご覧いただけます。