AIの判断をあとから追えるようにする——AIネイティブな監査ログ・トレーサビリティ設計

「AIが承認した」「AIが分類した」という結果だけがデータベースに残り、なぜその判断に至ったのかが誰にも説明できない——AIネイティブな業務システムでは、こうした状態に陥りやすい構造があります。人が判断していた頃は、判断者に聞けば理由がわかりました。AIが判断するようになると、その「聞けば分かる」が失われるため、代わりにログとして記録しておく設計が必要になります。

なぜトレーサビリティが要件になるのか

AIの判断を業務に組み込む場面では、次のような理由からトレーサビリティ（判断の追跡可能性）が求められます。

利用者からの異議申し立てに対応する必要がある（「なぜこの申請が却下されたのか」を説明する義務が生じる）
監査・規制対応で判断根拠の提示を求められる（与信・与信枠の変更、契約審査など）
AIの誤判断が疑われたときに、原因を切り分ける必要がある（モデルの問題か、参照データの問題か、プロンプトの問題か）
モデルやプロンプトを変更した際に、判断の傾向がどう変わったかを比較したい

これらは開発が始まってから後付けで対応しようとすると、必要なログがそもそも記録されていない、という事態になりがちです。要件定義の段階で「何を記録するか」を業務要件として確定させておく必要があります。

ログに残すべき5つの要素

AIネイティブなシステムの監査ログとして最低限押さえておきたい要素は、次の5つです。

入力: AIに何が渡されたか（利用者の入力そのもの、参照した文書やデータ）
判断根拠として参照した情報: RAG構成であれば、どの文書のどの部分を参照して回答を組み立てたか
使用したツール・実行した操作: AIエージェントが外部システムを操作した場合、どのツールをどんなパラメータで呼び出したか
出力と信頼度: AIが出した結論と、それに付随する信頼度・確信度のスコア（モデルやサービスが提供している場合）
モデルとプロンプトのバージョン: どのモデル・どのバージョンのプロンプト（指示文）で処理されたか

このうち見落とされやすいのが5番目です。モデルやプロンプトは運用中に改善のため更新されることが多く、「先月と今月で判断基準が変わった」原因を追うには、判断結果とモデル・プロンプトのバージョンを紐づけて記録しておく必要があります。

誰でも参照できる形にする

ログをシステム内部のデータとして残すだけでは不十分です。実際に異議申し立てやクレーム対応が発生するのは、エンジニアではなく現場の担当者やカスタマーサポートです。要件定義では、次のような「参照する側」の使い勝手も含めて設計します。

特定の申請・特定の利用者に紐づく判断履歴を、非エンジニアでも検索・閲覧できる画面を用意する
判断の理由を、生ログではなく人が読める要約の形で提示する（「入力された年収と借入希望額の比率が基準値を超えたため」など）
いつ・誰が・どの記録を閲覧したかも記録する（監査ログ自体へのアクセスも監査対象にする）

LangSmithやLangfuse、Datadog LLM Observabilityといった、AIの実行過程を可視化する専用ツールも増えていますが、これらは主にエンジニアが問題を調査するための道具です。業務担当者が日常的に参照する画面は別途、業務要件に合わせて設計する必要があります。

保存期間とデータ量の見積もり

AIとのやり取りは、人が判断していた頃の記録（承認印や決裁書類）に比べてデータ量が大きくなりがちです。入力文書の全文や、参照した文書の該当箇所、モデルの出力をすべて記録すると、想定以上にストレージを消費します。

要件定義の段階で、次の2点を決めておきます。

保存期間: 法令や社内規程で定められた保存期間（会計関連なら7年など）に合わせるか、それとも運用上必要な期間（直近1年など）にとどめるか
個人情報・機密情報の扱い: ログに個人情報や機密情報がそのまま残る場合、ログ自体を個人情報保護法などの規制対象データとして扱う必要が生じる。マスキングや暗号化、アクセス権限の設計をログ設計と同時に検討する

まとめ

AIネイティブなシステムでは、判断の速さや自動化そのものより、「その判断を後から説明できるか」が業務への信頼につながります。入力・参照情報・実行操作・出力・モデルバージョンという5要素を記録する設計を要件定義の段階で組み込み、非エンジニアでも参照できる形に整えておくことが、AIに実務判断を任せるための前提条件になります。