依頼を流れる仕組みにするとき、依頼が今どこにあるかを見えるようにするのと同じくらい、終わった依頼を後から追えるかが効いてきます。AIや外部に作業を任せて問題が出たとき、「誰がいつ何をして、誰が承認したのか」を追えないと、原因も責任も分かりません。この後から追うための記録が監査ログ（監査証跡）です。この記事では、監査ログとは何を指すのか、なぜ後から足せないのか、任せる前に何を決めておくと追える状態を保てるのかを整理します。
監査ログ（監査証跡）とは何を指すか
監査ログは、いつ・誰（人かAIか）が・何をしたかを、あとから順に追える記録です。監査証跡（audit trail）もほぼ同じ意味で、一つの作業や依頼が、着手から承認、差し戻し、完了までどう進んだかを時系列でたどれる記録を指します。誰かを疑うための記録ではなく、問題が起きたときに、どこで何が起きたかを事実で確かめるための記録です。
EU の AI 規制（EU AI Act）の第12条は、リスクの高いAIについて、運用期間を通じて出来事のログを自動で残せるように作ることを求めています。狙いは、リスクにつながる状況を後から特定できるようにすること、運用を監視できるようにすることです。手作業のメモでは代わりになりません。理由は単純で、忙しいときほど記録は後回しになり、問題が起きた後には残っていないからです。
なぜ後から足せないのか
監査ログの厄介なところは、必要になる場面が「問題が起きた後」なのに、記録を残す作業は「問題が起きる前」に済ませておかないと間に合わない点です。トラブルが起きてから「あの依頼、誰が承認したんだっけ」と探しても、チャットは流れ、口頭のやり取りは残っていません。担当がAIでも人でも同じで、記録する仕組みを先に置いていなければ、追える手がかりは残りません。
「うちはそんな厳密な記録は要らない」と思うかもしれません。規制対象のAIを使っていなくても、外注に出した成果物で顧客クレームが出た、社内の承認を経ずに請求が出た、という場面で「誰がGOを出したか」を追えないと、対応が止まります。監査ログは規制のためだけのものではなく、任せた依頼で何かあったときに、事実から次の手を決めるための土台です。
何を残すか、を依頼のリスクで絞る
とはいえ、すべての操作を細かく残すと、記録する手間も、後で読む手間も増えます。全部を残そうとして続かないより、間違えたときの損害が大きい依頼に絞って、次の最小限を残すほうが続きます。
- 誰が承認したか。その依頼を次へ進める判断をした人（またはAI）。
- いつ、どの状態に変わったか。着手・確認待ち・差し戻し・完了の時刻。
- 差し戻したときの理由。なぜ止めたか、何を直させたか。
この3つが残っていれば、問題が出たときに「どこで判断が入り、どこで止まったか」を追えます。逆にこれが口頭やチャットに散っていると、追うために関係者へ聞いて回ることになり、対応が遅れます。
PATHWORK での扱い方
PATHWORK は、チャットで来た依頼をタスクに起こし、担当と状態と期限を1画面で追う道具です。監査ログの文脈でいえば、依頼の状態が変わった記録がその依頼に紐づいて残る点が対応します。誰がいつ「確認待ち」から「完了」へ動かしたか、差し戻しがどこで入ったかが、依頼を開けば時系列でたどれます。承認や差し戻しのやり取りを、別のチャットや口頭に散らさず、その依頼の上に残せます。
ただし、何を残すべきかを決めるのは運用ルールです。道具は状態の変化を記録しますが、差し戻しの理由をきちんと書くか、承認を口頭で済ませず状態で通すかは、チームの決め事です。記録の器があっても、そこに通す運用を決めていなければ、追える情報は溜まりません。
まとめ
監査ログ（監査証跡）は、いつ・誰が・何をしたかを後から追える記録です。必要になるのは問題が起きた後ですが、残す作業は起きる前に済ませないと間に合いません。だから、任せる前に「誰が承認したか」「いつ状態が変わったか」「なぜ差し戻したか」を、どこに残すかを決めておく。次の一手は、今その3つが口頭やチャットに散っていないか、依頼に紐づいて残っているかを確かめることです。