AIの判断を後から追えるようにする

AIを組み込んだ機能で問題が起きたとき、最初に聞かれるのは「何人に、どの期間、同じことが起きたか」です。この質問に答えられるかどうかは、機能を出す前にログを設計したかどうかでほぼ決まります。

記録は後から遡って取れません。運用を始めてから追加しても、それ以前の期間については答えられない状態が残ります。ここでは、何を残し、何を残さず、どれだけ保つかの決め方を整理します。

何のために残すのかを先に決める

ログの設計でよくある失敗は、目的を決めずに「とりあえず全部残す」ことです。量が増えて費用がかさみ、個人情報を抱え込み、いざ調べようとしても必要な情報が見つからない、という状態になります。

目的は三つに分かれます。

第一に、誤りの説明です。特定の利用者に返した回答を再現し、影響範囲を特定するために使います。

第二に、品質の改善です。どのような入力で望ましくない出力が出やすいかを把握し、指示の文面や処理の仕組みを直すために使います。

第三に、費用と性能の監視です。呼び出しの回数、応答時間、失敗率を見て、想定と乖離していないかを確かめます。

この三つは必要な粒度が違います。三つ目は集計値だけで足ります。二つ目は代表的な事例があれば十分です。全文が要るのは一つ目だけであり、しかも全機能で必要とは限りません。

残す項目の基本形

どの目的でも共通して必要になるのは次の項目です。

呼び出しの日時。使用したモデルとバージョン。処理にかかった時間。成功したか失敗したか。失敗した場合の理由。どの機能からの呼び出しか。そして、同じ一連の処理を後から辿るための識別子です。

識別子は軽視されがちですが、調査の実務ではこれが効きます。利用者の一回の操作が複数回の呼び出しに分かれることは普通にあり、識別子で紐づいていなければ、後から経緯を組み立てられません。

失敗の記録も忘れないでください。呼び出しが失敗した、時間切れになった、出力が途中で打ち切られた、といった事象は、成功したものより調査で重要になります。利用者から「回答が途中で止まった」と言われたとき、成功分しか残っていなければ確認できません。

入力と出力をどこまで残すか

ここが判断の分かれ目です。用途ごとに決めるのが実際的です。

顧客向けの回答機能で全文を残すのは、説明責任が直接かかるためです。ただしこの選択には代償があります。利用者が入力した内容には個人情報が含まれることがあり、それを自社のログに蓄積することになります。

このとき併せて決めるのは、閲覧できる人を絞ること、保存期間を短くすること、そして入力に含まれやすい情報（電話番号やメールアドレスの形をしたもの）を記録前に伏せる処理を入れるかどうかです。伏せる処理を入れると調査のときに不便になるため、機能の性質に応じて選びます。

想定例として、問い合わせ対応の下書きを作る機能を考えます。入力には顧客の氏名や契約内容が含まれます。全文を残せば調査はしやすくなりますが、ログが個人情報の保管庫になります。この機能では、問い合わせ番号と出力の全文を残し、入力は元の問い合わせデータを参照する形にすれば、二重に保持せずに経緯を辿れます。

保存期間を決める

期間は、次の三つを並べて最も長いものに合わせます。

誤りの指摘が実際に届くまでの期間。自社の問い合わせ履歴を見れば、おおよその見当がつきます。契約や法令で求められる保持期間。業種によっては明確な定めがあります。そして、費用として許容できる範囲です。

決めたら、自動で削除される仕組みまで作ってください。手動で消す運用は続きません。クラウドの保管サービスには一定期間で削除する設定があるのが普通なので、それを使います。

長期に残すものと短期で消すものを分ける方法もあります。集計値や失敗率は軽いので長く残し、全文は短い期間で消す、という設計です。調査の大半は直近の期間で行われるため、実務上の不便は小さくなります。保管の構成やコストの考え方はサーバーインフラ整備の領域とも重なります。

調査で実際に使えるようにする

残していても使えないログはよくあります。防ぐ工夫は三つです。

検索できる形にすること。日時と識別子と機能名で絞り込めれば、大半の調査は進みます。逆に、テキストファイルに書き出しているだけだと、量が増えた時点で追えなくなります。

一件の記録で経緯が分かること。入力、出力、モデル、結果が別々の場所に散っていると、突き合わせに時間がかかります。可能なら一件の記録にまとめます。

調べ方を文書にしておくこと。誤答の報告を受けたとき、どこを見て、どう絞り込むかを一枚に書いておきます。調査は頻繁には起きないため、手順を覚えている人がいない前提で用意しておくのが安全です。誤答が起きたときの初動全体については、別の記事で扱っています。

記録は機能を出す前に決める

ここまでの内容を一つにまとめると、ログは機能の一部だという整理になります。後から足す付属品ではありません。

具体的には、AI機能の仕様を検討する段階で、何を記録するか、どれだけ保つか、誰が見られるかを決めます。この三点が決まっていない機能は、まだ設計が終わっていないと考えてください。実装量としては大きくないので、最初に入れておくほうが結果的に安く済みます。

記録があれば、誤答が起きても影響範囲を特定して対応できます。なければ、誠実に対応しようとしても材料がありません。この差は、精度の差より事業への影響が大きくなります。AI活用開発で、ログを含めた運用の設計から相談したい方はお問い合わせください。

本記事は一般的な情報であり、個別の事案は専門家・所管官庁にご確認ください。