AIワークフローのログから、業務の1件を最後まで追えるか
AIワークフローのログ設計では、業務ID・実行ID・処理IDを分けて関連付け、本文を保存しすぎずに失敗地点を追える状態をつくります。再試行と保存範囲を決める判断表も示します。
AIワークフローのログ設計では、業務の1件、ワークフローの1回の実行、実行中の各処理を別々のIDで結びます。どの処理がどの入力・成果物・設定に依存したかを追える状態を、プロンプトや応答の保存範囲より先に設計します。
通常時は状態と参照情報を残し、失敗時にだけエラー属性を加えます。個人を識別し得る本文は既定の保存対象から外し、調査目的が明確な場合に限って保存条件を定めます。実装前に残る判断は、「本文を開く前に、どこまで原因を絞るか」という境界を自社業務に合わせて決めることです。
AIワークフローのログ設計は、三つの単位を分ける
一つの問い合わせが複数の処理を通るワークフローを考えます。受付、入力の整形、モデルの呼び出し、出力の検査、業務システムへの反映があったとして、すべてに同じIDだけを付けると「同じ案件に属する」ことは分かっても、失敗地点は特定できません。反対に、処理ごとのIDしかなければ、一連の業務として集め直せません。
そこで、ログの相関を三つの単位に分けます。
business_id：業務上の1件を表す。再試行や人手確認を含め、同じ案件として束ねる軸trace_id：ワークフローを1回実行した単位。同じ業務を再試行した場合は別の値にする軸span_id：実行中の個々の処理を表す。失敗した処理を指せる粒度
この三層は、出典にそのまま定められた項目構成ではありません。2026年9月21日時点のOpenTelemetryのLogs Data Modelが示すTraceIdとSpanIdの相関、およびGoogle Cloudの生成AIアプリケーション運用ガイドが求めるコンポーネント間のlineageを基にした、実務上の提案です。OpenTelemetryでは、TraceIdはリクエストのトレース、SpanIdは特定の処理との対応付けに使え、SpanIdがある場合はTraceIdも存在すべきとされています。
business_idだけを見れば案件の全履歴を集められ、trace_idを見れば初回実行と再試行を混同せず、span_idを見れば止まった処理へ到達できます。三つを一列に押し込まず、親子関係として扱うことが追跡の出発点です。
失敗地点を追うログ項目の判断表
ログ項目は、調査時の問いから逆算して選びます。次の表は、出典の一般原則を基に組み立てた実務上の提案です。原典所定の分類や義務とは異なります。
| 調査時の問い | 残す項目 | 記録する条件 | 判断できること |
|---|---|---|---|
| どの業務の処理か | business_id | 全処理 | 同じ業務に属する実行を束ねる |
| どの実行で起きたか | trace_id | 全処理 | 初回実行と再試行を分ける |
| どの処理で起きたか | span_id、step_name | 全処理 | 失敗地点を処理単位で指す |
| いつ、どの状態になったか | event_time、status、severity | 状態変化ごと | 処理の順序と失敗の有無を追う |
| 何に依存していたか | artifact_ref、parameter_ref | 参照や設定を使う処理 | 入力、成果物、設定との関連をたどる |
| 失敗の種類は何か | error_type、例外属性 | 失敗時のみ | 同じ処理内の失敗を分類する |
全処理にエラー本文を持たせる必要はありません。OpenTelemetryの論理モデルにはTimestamp、TraceId、SpanId、Severity、Body、Resource、Attributes、EventNameがあり、個々のイベントに必要な追加情報や、エラー・例外の情報を構造化されたAttributesへ含められます。2026年9月21日時点で確認できるこの仕様を、上表ではevent_timeやseverity、失敗時の例外属性へ対応させています。ただし、表の項目名自体は実装例であり、OpenTelemetryがbusiness_idやstep_nameを必須としているわけではありません。
たとえば、業務システムへの反映が失敗したとします。business_idから同じ案件の記録を集め、trace_idで失敗した実行を選び、span_idとstep_nameで反映処理まで絞ります。そこでartifact_refとparameter_refを確認できれば、本文を開く前に、調査対象となる成果物と設定を限定できます。
この流れが成立しない場合、追加対象は欠けている関連です。大量の本文を足す判断は後に置きます。処理名はあるが実行IDがない、成果物は残るが生成した処理を指せない、といった切れ目を埋めます。Google Cloudのガイドも、2026年9月21日時点で、アプリケーション全体の入出力と各コンポーネントを含むエンドツーエンドのログ記録・監視に加え、実行した全コンポーネントについて、入力とコンポーネントを依存するartifactやparameterへ対応付けるlineageを求めています。
再試行を上書きせず、同じ業務の別実行として残す
失敗後の再試行で初回の記録を上書きすると、最終的に成功した事実しか見えなくなります。business_idは維持し、再試行には新しいtrace_idを付け、その中の各処理にも別のspan_idを付けます。これにより、「この業務は完了したか」と「どの実行のどの処理が失敗したか」を別々に判断できます。
| 状況 | business_id | trace_id | span_id | 扱い |
|---|---|---|---|---|
| 初回実行 | 同じ業務ID | 初回の実行ID | 各処理のID | 処理ごとの状態を保持 |
| 失敗後の再試行 | 同じ業務ID | 新しい実行ID | 新しい各処理ID | 初回を上書きせず関連付ける |
| 人手確認後の再開 | 同じ業務ID | 再開を表す実行ID | 再開後の各処理ID | 人手確認前後を分けて追う |
この再試行の扱いは、lineageとTraceId・SpanIdの一般原則から組み立てた実務提案です。公式仕様が定める業務分類とは異なります。「成功」という最終状態だけで途中の失敗を消さず、実行単位の履歴を保持します。ワークフローの設計段階から運用への移行条件を整理する場合は、AI PoCを本番運用へ進めるための考え方も合わせて確認できます。
個人情報を全部保存せず、調査可能性を残す
プロンプト、応答、添付データを無条件に保存すると、調査に不要な情報までログへ入り得ます。本文を一切残さないという方針だけでも、参照関係まで失えば障害時に対象を絞れません。そこで、保存する情報と参照だけ残す情報を分けます。
| 情報 | 既定の扱い | 限定保存を検討する条件 | 代替する記録 |
|---|---|---|---|
| 業務・実行・処理の識別子 | 保存 | 全処理の追跡に使う | business_id、trace_id、span_id |
| 状態・重大度・処理名 | 保存 | 状態変化や失敗を追う | status、severity、step_name |
| 成果物・設定 | 参照を保存 | 対象の特定に必要 | artifact_ref、parameter_ref、設定識別子 |
| プロンプト・応答・添付データ | 既定では保存しない | 調査目的、閲覧権限、保持・削除方針、レビュー手順を定めた場合 | トークンまたは参照への置換を検討 |
| エラー・例外情報 | 失敗時に限定 | 失敗分類に必要 | 構造化したerror_typeと例外属性 |
これは、出典の一般原則を基に記事が提案する保存判断であり、NISTやOpenTelemetry所定の分類・義務ではありません。2026年9月21日時点で参照したNIST Privacy Framework 1.0のCT.DM-P8は、監査・ログ記録を方針に従って決定、文書化、実装、レビューし、データ最小化の原則を取り入れることを成果として示しています。CT.DP-P2は個人の識別を制限する処理の例に非識別化とトークン化を挙げ、CT.DP-P5は属性値を属性参照で置き換えることを示しています。
したがって、「後で役立つかもしれない」を保存理由にせず、誰が何の調査で見るのか、いつまで保持するのか、どう削除するのかを先に決めます。本文が必要と判断した場合も、全ログの標準項目にせず、対象、閲覧権限、保持・削除方針、レビュー手順を限定します。まず参照で対象を絞り、それでも調査できない場合にだけ本文の限定保存を検討する順序です。
実装前に通す四つの判定
ログ基盤の製品を選ぶ前に、対象ワークフローの各処理を一行ずつ並べ、次の条件を確認します。
- 任意の
business_idから、その業務に属する初回実行と再試行を列挙できるか - 任意の
trace_idから、各処理の順序、状態、失敗したspan_idを特定できるか - 失敗した処理から、依存した成果物と設定を参照でたどれるか
- プロンプトや応答を開かなくても、調査対象を十分に絞れるか
上の三つまで満たせず本文保存で補っているなら、相関設計を先に直す余地があります。四つ目で絞れない場合に限り、どの本文が、どの調査目的に必要かを切り分けます。AI導入全体の課題定義や実装順序から整理したい場合は、AI導入を実務へつなげる進め方も判断材料になります。
業務の1件を最後まで追うには、business_idで案件を束ね、trace_idで実行を分け、span_idで失敗地点を指し、成果物と設定を参照でたどれる状態が必要です。すべての内容を一か所へ保存する必要はありません。まず一つのワークフローで四つの判定を通し、欠けた関連だけを追加してください。個人を識別し得る本文の保存は、その相関だけでは調査できないと確認してから、目的と管理条件を限定して決めるのが実装の境界です。
自社のワークフローで、どのIDを業務の起点にし、どの情報を参照へ置き換えるべきか整理が必要な場合は、FDE型支援の無料相談・AI活用診断で、課題定義から実装、定着までの条件を確認できます。
FDE・AI実装ガイドへ戻る