AIトレーサビリティ：リネージとログの統合で実現する説明可能なAI運用

本番環境で運用されるAIシステムは、日々膨大な実行ログを出力し続けています。元データやモデルのバージョン、入力したプロンプト、AIの応答、アクセス履歴、さらには承認フローに至るまで、あらゆるデータが日々の業務プロセスの中で蓄積されていきます。しかし、いざ監査や障害対応が必要になった際、これら分散したデータを統合して追跡できるかどうかは、AIトレーサビリティの有無にかかっています。

AIトレーサビリティとは、データリネージ、アクセス履歴、プロンプトと応答のログ、各種ドキュメント、インシデント記録、監査証跡を相互に紐付け、過去のAIシステムの状態や挙動を正しく検証可能にする仕組みです。本ガイドでは、データリネージやモデルレジストリから、プロンプトのログ、AIBOM（AI構成要素表）、インシデントレポートに至るまで、トレーサビリティを支える各種記録の役割と、本番運用における監査対応への活用アプローチを解説します。

AIトレーサビリティとは、人工知能システムのライフサイクルにおける全ステップを追跡可能にする機能です。モデルの学習やグラウンディングに使用されたデータから、予測や応答を出力したモデルのバージョン、さらには入出力ログに至るまで、システムの一連の挙動を網羅して追跡します。

従来の機械学習（ML）では、学習データの特徴量から始まり、その加工および変換プロセス、データスナップショットとモデルバージョンの紐付け、そしてどのデプロイ環境がその予測を出力したかを追跡するのが一般的でした。

一方、生成AIの場合は追跡対象が広がり、システムプロンプト、ユーザー入力、参照（RAG）ドキュメント、ツール呼び出し、ガードレールの判定結果、モデル設定、最終出力といった、より多様な要素をカバーする必要があります。

トレーサビリティの目的は、チームが後からシステムの動作を正確に再現、検証できる状態を作ることです。これにより、障害発生時や監査の際に、以下のような具体的な疑問へ即座に回答できるようになります。

• どのデータが使用されたのか？ 

• どのモデルバージョンが稼働していたのか？

• 出力結果は承認済みの情報源に基づいているか？

• プロンプトのテンプレートを変更したのは誰か？

• 基盤テーブルにアクセスしたロールはどれか？

• インシデントの原因は、データドリフト、デプロイの変更、検索の失敗、あるいは安全制御をすり抜けたプロンプトのいずれなのか？

AIトレーサビリティは、データプロビナンスやリネージ、各種ログ、承認履歴などを相互に紐付けることで、問題発生時やレビュー時にいつでも検証できる確実な証拠を提供します。

AIシステムは事前テストを経てリリースされますが、本当に重大なトラブルの多くは本番稼働を開始した後に発生します。たとえば、顧客へ誤った回答を返してしまう、不正検知モデルが誤判定を起こし、正常な取引を弾き始めてしまう、RAG（検索拡張生成）がすでに古い社内規定を参照してしまう、といったケースです。

トレーサビリティがなければ、こうした問題が起きるたびに、ノートブックやチケットツール、ストレージ、アプリログ、仕様書などに分散した情報を、手動で1つずつ追跡、特定しなければなりません。

一方でトレーサビリティが確立されていれば、出力結果からモデルバージョン、参照データ、プロンプト、アクセス履歴、評価結果、リリース承認記録といった一連のログを一本の線で一気に遡り、原因を特定できます。

規制への対応準備

トレーサビリティは、各種規制や標準規格のコンプライアンス要件と極めて密接に関連しています。たとえばEU AI法の第12条では、高リスクAIシステムに対してシステムライフサイクル全体での自動ロギングと適切なトレーサビリティの確保を義務付けています。さらに同規定では、生成されたログを自社の管理下で目的に応じた期間（他の法令で定めがない限り、少なくとも6か月間）保持することもプロバイダーに求めています。

国際規格であるISO/IEC 42001は、AIマネジメントシステム（AIMS）の要件を定め、組織がAIの目的やリスク、管理策を統制するための枠組みを提供しています。また、米国のNIST AI RMF（リスクマネジメント・フレームワーク）は強制力のある規制ではないものの、その4つのコア機能（Govern、Map、Measure、Manage）を機能させるには、システムのコンテキスト、権限、パフォーマンス、リスク制御に関する客観的な証拠が欠かせません。

これらの規格やフレームワークに共通する本質的なテーマはエビデンスです。社内規定やポリシーは「どうあるべきか」を定義しますが、「実際に何が起きたのか」を証明できるのはトレーサビリティだけです。

EU AI法とISO/IEC 42001の詳細をご確認ください。

インシデント対応と根本原因分析

AIシステムでトラブルが発生した際、チームはモデル、データ、プロンプト、RAG（検索層）、アプリのロジック、あるいは人の承認プロセスのどこに原因があるのかを特定しなければなりません。

たとえば、事前の性能評価で優れたモデルであっても、古いコンテキストを受け取ったり、誤ったツールを実行したり、事後に変更されたプロンプトが適用されたりすれば、不適切な出力を引き起こす可能性があります。

トレーサビリティが確立されていれば、インシデント対応者はモデルバージョン、データスナップショット、ユーザーまたはワークロードID、プロンプトと応答、アクセス経路、承認履歴を一括で取得可能です。

この記録は、リリース後の継続的なモニタリングにも役立ちます。特定のデプロイ環境やデータソース、ユーザーグループだけに障害が集中している場合、トレーサビリティによってその傾向を迅速に発見し、セキュリティや運用の制御を見直す判断を下せます。

運用におけるアカウンタビリティ

AIにおけるアカウンタビリティを果たすには、誰がシステムの所有者であり、誰が変更を行ったのかを組織として明確に把握している必要があります。モデルのリリース承認や例外的なポリシーの適用、リスクのあるバージョンのロールバック判断などを、人間不在のAI任せにしてはなりません。

トレーサビリティは、システムの技術的なイベントと人間の意思決定を紐付けます。これにより、モデルの承認、プロンプトの更新、アクセスポリシーの変更、評価結果の受容、インシデントレビューといった各プロセスの責任者が誰なのかを可視化できます。

AIシステムは単なるコードとデータの集まりではありません。所有者やレビュー担当者、ユーザー、明確なエスカレーションルートを備えた人が運用するシステムだからこそ、こうした決定プロセスの可視化が不可欠なのです。

追跡可能なAIシステムは、データリネージ、モデルリネージ、プロンプト、応答ログ、アクセス履歴、各種ドキュメント、AIBOM、インシデント記録など、相互に紐付けられた複数の記録によって成り立っています。それぞれの記録が、AIライフサイクルの各フェーズを網羅して補完し合います。

データリネージ

データリネージは、特徴量やテーブルの列、ドキュメントなどのデータ要素を、途中で加えられた加工、変換処理も含めて上流の元データまで遡って追跡する仕組みです。たとえば信用リスク評価モデルの場合、年収データを元に算出された特徴量を、元のソーステーブル、変換ジョブ、データ品質チェックの履歴、さらには学習用データのスナップショットまで遡って特定することを指します。また、検索拡張生成（RAG）アプリであれば、生成された回答を推論時に参照されたドキュメントやその文書を取り込んだデータパイプラインまで一気に遡れる状態を意味します。

ここにはプロビナンスも含まれます。チームは、学習および参照データがどこから来たのか、どのようにフィルタリングされたのか、合成データは含まれているか、どのポリシーが適用されたか、削除・非推奨になったデータソースはないかを把握しなければなりません。特に合成データの識別は重要です。生成AIで作られたデータはデータ拡張やテストには便利ですが、実際の運用と混ざってしまうとモデルの精度を歪めてしまうからです。

データリネージの分断は、トレーサビリティにおいて最も起こりやすい不備の1つです。たとえ元データの管理が厳格であっても、誰かが特徴量セットをCSVファイルでローカルにダウンロードし、手作業で編集した後に履歴なしで再アップロードしてしまうと、最もリスクが潜みやすいデータ準備フェーズで追跡の糸口が完全に切れてしまいます。

モデルリネージ

モデルリネージは、モデルのバージョン履歴と、それに紐づく各種成果物（アーティファクト）を記録する仕組みです。具体的には、モデルのバージョンID、コードのバージョン、学習データのスナップショット、ハイパーパラメータ、評価結果、承認ステータス、デプロイ先などを網羅します。さらに生成AIシステムの場合、モデルプロバイダー、モデル名、パラメータ設定、検索ロジック、プロンプトテンプレートのバージョン、ガードレールの構成設定までが記録対象となります。

これらを一元管理する主要な管理拠点がモデルレジストリです。各モデルバージョンに一意のIDを割り当ててメタデータとともに保存し、学習や評価の実行履歴と本番環境に適用されたバージョンを1対1で結び付けます。ここで最も重要なのは、モデルレジストリとデプロイプラットフォームを密接に連携させることです。これにより、推論ログからどの正確なバージョンがその応答を出力したかを確実に特定できるようになります。もし両者が分離していると、いくら承認済みのレジストリを運用していても本番環境で実際にどのモデルが動いたのかを証明できなくなるリスクを抱えることになります。

プロンプトと応答のログ

生成AIシステムでは、個々のインタラクションレベルでのトレーサビリティが不可欠です。網羅的なプロンプト・応答ログには、ユーザー入力やシステムプロンプト、モデル設定、参照したコンテキスト、ツールの呼び出し履歴、ガードレールの判定結果、最終出力に加え、ユーザーまたは呼び出し元のIDやタイムスタンプが含まれます。さらにエージェント型システムの場合は、中間的な推論ステップやツールの選択イベントまでトレース対象となります。

これらのログは単なるデバッグ用にとどまりません。特定の顧客とのやりとりを正確に再現し、モデルが適切な情報を参照できていたか、最終回答が社内ポリシーや公式ドキュメント、承認済みデータソースに基づいているかを検証、評価するために活用されます。

ここで注意すべきはログのサンプリングリスクです。ランダムサンプリングされたログは全体的な品質分析には役立ちますが、調査対象のログが抜け落ちていれば特定のインタラクションを再現できなくなります。特に高リスク領域や規制対象のワークフローでは、単なるコスト削減のためのロギングではなく、監査やプライバシー、運用要件を満たす確実な保持ポリシーが求められます。

監査証跡とアクセス履歴

AIトレーサビリティの実現には、誰が、いつ、どのロールやワークロードを通じて、どのデータにアクセスしたかの把握が不可欠です。どれほどモデルが優秀であっても、許容されたアクセス境界外のデータを取得していたり、セキュリティポリシーを回避する権限で実行されていたりすれば、その運用自体がコンプライアンス違反やセキュリティリスクとなります。

アクセス履歴は、AIの具体的な挙動とガバナンス管理を紐付ける要素です。これにより、どのテーブルやビュー、カラムにアクセスしたのか、どのロールがクエリを実行したのか、オブジェクト間でデータがどう移動したのかを客観的に証明できます。

こうしたアクセス履歴は、プロンプトログだけでは判別できない重大な問いに答えてくれます。プロンプトログにはユーザーの質問内容しか残りませんが、アクセス履歴を確認することでシステムが機密情報に触れていないか、保護対象のオブジェクトが関与していないか、アクセス経路が承認された設計通りかまでを検証できます。

モデルカードとドキュメント

追跡性を高めるには、システムが吐き出す技術ログに加え、人間が読み解くための補足ドキュメントが欠かせません。モデルカードやシステムカードなどの文書は、AIの用途、制限事項、評価方法、学習データ概要、リスク制御、責任体制などを明記し、レビュー担当者が承認理由や運用ルールを把握するのに役立ちます。

重要なのは、ドキュメントを技術ログから切り離さないことです。モデルカードが、実際のモデルバージョン、評価実行ログ、データスナップショット、承認履歴、障害記録と紐付いていてこそ、生きた情報となります。技術ログとのリンクがなければ、ドキュメントは実態を反映しない形骸化したマニュアルと化します。単に設計上の理想を示すにとどまり、現場でシステムがどう変更、運用されているかという事実を追跡できなくなります。

AI部品表

AI部品表（AIBOM）とは、ソフトウェア部品表（SBOM）の概念をAIシステムに応用したものです。モデルやデータセット、ライブラリ、API、検索インデックス、外部サービス、プロンプト、ツール、ガードレールなど、AIシステムを構成するすべての要素をインベントリとして管理します。

AIBOMの目的は、システムの全体構造と外部への依存関係を正しく把握することです。たとえば、モデルプロバイダーの仕様変更、ライブラリの脆弱性発覚、データソースの許諾撤回、利用ツールの提供停止といったトラブルが発生した際も、AIBOMがあれば影響を受けるシステムを即座に特定し、リスクの範囲を迅速に評価できます。

実効性のあるトレーサビリティを確保するには、AIBOMをリリース時に一度作って放置されるスプレッドシートにしてはなりません。CI/CDパイプラインなどのリリースプロセスに組み込み、システムの変更に合わせて自動的に目録が更新される仕組みを構築することが不可欠です。

インシデント記録

インシデント記録は、AIシステムが予期しない挙動を示したり、被害を引き起こしたりした際に何が起きたかを記録するものです。構造化されたインシデントレポートには通常、システム名、モデルバージョン、インシデントの発生時刻、影響を受けたユーザーまたはワークロード、入出力の記録、重大度、根本原因、修復手順、レビュー担当者の決定、クローズのステータスが含まれます。

インシデントレポートは、システムの他の部分と同じリネージグラフ（モデルバージョン、プロンプトのログ、アクセスイベント、評価結果、展開の承認）にリンクされている必要があります。インシデント記録がデータやモデルのグラフから切り離され、チケット管理システムにのみ存在する場合、ワークフロー管理はサポートできても、完全なトレーサビリティはサポートできない可能性があります。

トレーサビリティ、透明性、説明可能性は、AIガバナンスでセットで語られがちですが、それぞれが担う役割は明確に異なります。

• トレーサビリティは履歴の記録です。特定のイベントに対し、どのデータ、モデル、プロンプト、ユーザー、承認記録、出力が関与したのかという実行履歴を記録、追跡します。

• 透明性は情報の開示です。ユーザーや関係者に対し、システムの用途、依存データ、制限事項、認識されているリスクなどをオープンにし、システムの全体像を伝えます。 

• 説明可能性は意思決定の根拠です。モデルの設計、特徴量の貢献度、事後解析、自然言語による解説などを通じ、AIがその予測や回答を出力した判断の理由を人間が理解できるようにします。

トレーサビリティは、最後にドキュメントとして追加するのではなく、AIアーキテクチャの一部として扱うと、最も構築しやすくなります。以下の実践は、データ、モデル、ログ、承認、インシデントをつなぐ役割を果たします。

すべての特徴量をガバナンスが適用されたソースまでトレースする

すべての特徴量は、途中の変換履歴も含めて、元のソーステーブルやビュー、ドキュメント、承認済みデータソースと確実に紐付けられていることが前提です。ローカルで手修正したCSVファイルや、個人のノートブック内にしか存在しない特徴量は、適切なガバナンスプロセスを通さない限り、本番モデルに組み込むべきではありません。

不変のバージョンIDを持つモデルレジストリを使用する

各モデルのバージョンには、コード、トレーニングデータのスナップショット、評価の実行、承認ステータス、展開ターゲットにリンクされた安定した識別子が必須です。本番環境の推論システムは、すべての予測または応答とともにその識別子をログに記録しなければなりません。

推論イベントを再構成できるだけの十分なコンテキストとともにログに記録する 

従来の予測モデルであれば、推論時のログとしてモデルバージョン、入力特徴量、呼び出し元のID、出力結果、タイムスタンプを記録しておく必要があります。一方、生成AIシステムの場合は追跡対象が広がり、システムまたはユーザープロンプト、参照コンテキスト、ツールの呼び出し履歴、モデル設定、応答内容に加え、セキュリティや安全制御の判定結果までを網羅することが求められます。

展開されたシステムごとにAIBOMを維持する

AIBOMには、システムを構成するモデルやデータセット、ライブラリ、検索インデックス、外部サービス、プロンプト、各種ツール、ガードレールなどを網羅的に記載します。そしてこれは、ローンチ時に一度作って終わりの静的な成果物ではありません。リリースプロセスやCI/CDワークフローに組み込み、システムの変更に合わせて継続的に更新していくことが不可欠です。

適用可能な最も厳格な要件に基づいてログ保持期間を定義する

ログの保持期間は、規制要件やプライバシー保護の義務、監査対応、運用上のトラブル調査に必要な期間を総合的に判断して決定します。たとえばEU AI法の場合、高リスクAIシステムのプロバイダーに対し、自社の管理下で自動生成ログを適切な期間（原則として少なくとも6か月間）保持することを明確に義務付けています。

インシデント記録をリネージグラフに接続する

インシデントレポートは、発生したイベントに関連するモデルバージョン、プロンプトまたは応答ログ、アクセス履歴、評価結果、リリース承認記録と直接紐付いていることが理想的です。こうした構造を整えておくことで、根本原因の分析がスムーズになるだけでなく、今回の障害が一時的な不具合なのか、それとも繰り返し発生している構造的なパターンなのかを正確に見極められるようになります。

各トレーサビリティ成果物にオーナーを割り当てる

データリネージ、モデルのメタデータ、対話ログ、AIBOM、アクセス履歴、インシデントレポートといった情報は、社内の複数チームに分散しがちです。トレーサビリティを機能させるには、責任の所在をあらかじめ明確にしておくことが不可欠です。台帳の維持管理、ログのレビュー、保持方針の例外承認、システムの停止やロールバック判断といった各プロセスの実行権限と責任者をはっきりと定義しておくべきです。

AIのトレーサビリティが機能しなくなる原因の多くは、システム同士のつなぎ目に潜んでいます。いざインシデントの調査や再現を行おうとしても、個々のログやデータを突き合わせて1つの流れとして復元できないのです。主な要因としては、以下が挙げられます。

データ準備フェーズでリネージが分断されている

正規のデータベース上には所有者やタグ、アクセスポリシーが設定されていても、データが個人のノートブックや単発のスクリプト、手動作成のファイルへと切り出された瞬間に、リネージは途切れてしまいます。これによりシャドウパイプラインが発生し、本番モデルがリネージグラフに存在しないデータに依存するというリスクを生み出します。

解決策：特徴量エンジニアリングや学習データの作成プロセスを、変換履歴、元データへの参照情報、バージョン管理されたスナップショットを含めて、一元管理された標準ワークフローに組み込みます。

モデルレジストリとデプロイ基盤が分断されている

モデルレジストリ上で承認済みバージョンを適切に管理していても、サービングレイヤーがバージョンIDをログに残していなければ、特定のアウトプットをどのモデルが生成したのかを客観的に証明できません。その結果、応答ログだけが存在し、それを裏付けるモデルの記録が辿れない浮いた推論が発生してしまいます。

解決策：モデルのバージョンIDを推論APIの仕様に組み込みます。本番環境におけるすべての推論リクエストにおいて、実際に応答を返したモデルバージョンをログへ確実に刻み込みます。

サンプリングによってインタラクションが追跡不能になる

コスト削減や日常の品質モニタリングを目的に、生成AIの対話ログをサンプリング保存しているケースがよく見られます。全体傾向の分析にはこれで十分ですが、ユーザーからの苦情やセキュリティインシデント、監査対応などが発生した際、該当のやり取りが存在せず、トラブルを再現、特定できないという致命的な欠陥につながります。

解決策：分析用ログと監査用ログを明確に分離して運用します。ダッシュボードなどでの集計分析にはサンプリングログを活用する一方で、規制対象や影響度の高い重要なインタラクションについては、規定の保持期間中、全件の完全なログを確実に保存する設計とします。

インシデント記録と技術ログが孤立化している

障害やトラブルの記録はITサービス管理ツールやGRCツール上で管理される一方、モデルのメタデータやアクセス履歴、対話ログは別の基盤に個別保存されがちです。このように障害チケットと技術的なログが紐付いていないと、単に問い合わせ対応のテキストが残るだけで、障害当時のシステム状態や原因を後から追跡、再現することが不可能になります。

解決策：インシデント記録に対し、対象のモデルバージョン、ログ、アクセス履歴、評価結果を直接リンクさせて管理します。 インシデントレポートを単なる管理上の処理書類で終わらせず、システムの運用履歴を構成する重要データとして組み込むことが不可欠です。

ドリフト監視にリネージのコンテキストが欠けている

モデルドリフトは、ユーザー行動の変化だけでなく、データ品質の低下やソースシステムのスキーマ変更、RAG用インデックスの陳腐化など、多様な要因で発生します。このときデータリネージが整備されていないと、アラートによって精度が落ちているという兆候は察知できても、上流のどこに根本原因があるのかを特定できません。

解決策：監視アラートとデータおよびモデルのリネージを連動させます。評価指標の悪化を検知した際、その変化を引き起こした直前のデータソース変更、データ変換処理、モデルバージョン、デプロイ履歴を一気に遡って調査できる環境を整えます。

トレーニングデータ、モデル、プロンプト、アクセスログ、ガバナンス制御が、分断されたシステム全体に分散している場合、AIトレーサビリティの確保は困難になります。Snowflakeは、こうした多くの証拠を同じガバナンス環境内に保持できるようにします。データ、メタデータ、アクセス制御、モデル管理、AIアプリケーションのトレースを相互に紐付けることが可能になり、事後に突き合わせる必要はなくなります。

Snowflake Horizonカタログは、データとAIのためのガバナンスが確保されたカタログレイヤーを提供し、Snowflakeデータ、Apache Icebergデータ、外部リレーショナルソース、BIツールにわたる可視性を実現します。また、リネージの可視性もサポートしているため、チームはサポートされているアセット間の関係やデータの移動を理解できます。外部リネージは、Snowflakeのネイティブリネージを拡張して外部データソースと宛先を含めることで、システムの境界を越えるパイプラインをデータがどのように移動するかについて、より広範な視野をチームに提供します。

モデルリネージについては、Snowflakeモデルレジストリを使用することで、モデルバージョン、アーティファクト、アクセス制御をSnowflakeのロールや権限と結び付け、Snowflake内でモデルとメタデータを管理できます。これにより、モデルのガバナンスを、トレーニング、グラウンディング、推論に使用されるデータを管理するのと同じセキュリティ境界に接続できます。

SnowflakeのACCESS_HISTORYビューを活用すれば、どのデータにいつアクセスされたかだけでなく、ソースオブジェクトからターゲットオブジェクトへどのようにデータが移動したかまで正確に把握できます。サポートされる書き込み操作については、列レベルのリネージも得られます。AIワークフローにおいては、この機能により、モデルの挙動をその基盤となるテーブル、列、ロール、ワークロードに結び付けられるようになります。

生成AIアプリケーションについては、Snowflake CortexのAIオブザーバビリティ機能が、デバッグやパフォーマンス評価のためのアプリケーショントレースを含め、生成AIアプリケーションの評価とトレースをサポートします。Cortex GuardはSnowflake Cortex AIで一般提供されており、安全でない可能性のあるLLMの応答をフィルタリングするのに役立ちます。一方、Cortex AIガードレールは、Snowflake CoCoに対するプロンプトインジェクションやジェイルブレイク攻撃からのランタイム保護を提供します。

リネージ、モデルのメタデータ、アクセス履歴、AIオブザーバビリティ、ガバナンス制御がSnowflakeのプラットフォーム内で機能していれば、問題発生後に部分的な記録をつなぎ合わせることに依存せずにトレーサビリティを確保できます。チームは、データとAIワークロードがすでに実行されている場所でより多くの証拠パスを保持できるため、トレーサビリティを本番環境に後付けされた別のシステムとして扱うことなく、監査、インシデント対応、継続的なガバナンスをサポートできます。

AIガバナンスの本質は、あらゆる意思決定を後から再検証できる点にあります。特徴量は元データまで確実に遡れる状態を保ち、モデルのバージョンは背後にあるデータ、コード、評価結果と1対1で紐付いていなければなりません。生成AIの回答についても、それを導いたプロンプト、参照コンテキスト、ツールの呼び出し履歴、モデル設定までを一貫して追跡できることが求められます。そしてインシデントレポートは、対象のシステムから独立した単なる書類ではなく、こうした一連の技術ログへ直接アクセス可能でなければ意味をなしません。

AIトレーサビリティは、本番運用における不可欠な要件となりつつあります。データやAIチーム、リスク管理者、監査担当者が同じ追跡記録を共有することで、システムがどう構築および変更され、現場でどう振る舞ったかという正確な事実を客観的に検証できるようになるからです。AIの適用領域が、より厳格な規制を受ける顧客対応や基幹業務へと広がるなかで、何が起きたのかを正確に再現、再構築する能力は、単に出力を生成する能力と同等以上の重みを持っています。