AIエージェントの判断根拠を守る監査証跡設計とSCFの物語

午前六時四十五分。青葉ロジスティクスの窓に、淡い朝日が差し始めていた。水野結衣は、注文処理画面に残った「登録しました」「承認済み」の文字を見つめた。

画面の右側には、AIエージェントの灯が処理を終えたと表示されている。灯は取引先のメールを読み、注文管理システムへ登録し、発送の準備まで進めたらしい。けれど、どのメールを読んだのかは分からなかった。

結衣は「詳細」を開いた。表示されたのは、開始時刻、処理時間、成功という三つの項目だけだった。参照した社内文書も、判断に使ったルールも、実際に呼び出したAPIやデータベース操作も見当たらない。

「誰が、何を根拠に承認したの？」

結衣の声が、まだ人の少ないフロアに落ちた。そこへ、監査と情報管理を担う佐伯が、紙コップのコーヒーを片手に近づいてきた。

「その注文、結果は残っているね。でも、途中の道が消えている」

佐伯は画面を指でなぞった。既存の性能ログには、処理時間やエラーの有無が記録されている。速かったか、止まらなかったかは分かるが、なぜその結論になったかを説明する記録ではなかった。

「入力が間違っていたのかもしれない。参照したデータが古かったのかもしれない。判断のルールや承認条件に抜けがあった可能性もあるよ」

結衣は、昨日の処理をもう一度たどろうとした。まず注文番号をコピーし、注文管理システムの検索欄に貼り付けた。登録された商品と数量は見つかったが、元のメールへのリンクは空白だった。

次に、共有のGmail受信箱で取引先名を検索した。似た件名のメールが三通並び、転送されたものと返信されたものが混ざっていた。灯が読んだ一通を特定できず、結衣は眉を寄せた。

「メールの本文を全部保存すれば、あとで分かるかな」

「機密情報まで、どこにでも複製することになるよ」

佐伯は、保存欄に小さな赤い印を付けた。元データを無制限に写すのではなく、メールID、受信時刻、データ区分、内容のハッシュを残す。必要な人だけが元の保管場所を確認できる形にする、と説明した。

結衣は空の検証用注文を作った。実際の取引先名は使わず、商品名を「検証用パレット」とした。Gmailから検証用の依頼を送り、灯を動かし、注文管理システムへの登録までを一度だけ実行する手順だった。

「最初から全部を直すのではなく、一件の道を見えるようにするんだね」

「そう。まず、依頼に一つの番号を付ける。今回は trace_id と呼ぶよ。検索、判断、承認、登録が同じ番号でつながる」

結衣は検証画面で trace_id を発行し、灯の親エージェントへ渡した。さらに、実行時刻をUTCのミリ秒まで記録し、実行主体をAIエージェント、接続先をGmailと注文管理システムとして登録した。記録は表計算ではなく、項目が崩れにくいJSON形式にした。

ところが、最初の実行後にログを開くと、検索までは同じ trace_id だった。承認判定のところで番号が別物に変わり、最後の登録処理には番号そのものが残っていない。画面には、また「承認済み」とだけ表示された。

「つながったと思ったのに、途中で糸が切れている」

「子エージェントが新しい番号を作っていたんだね。データベースを更新した処理も、性能ログにしか出ていない」

結衣は処理の入口だけを見るのをやめた。灯から検索役、承認役、登録役へ渡す共通の実行情報を一つにまとめ、各処理へ同じ trace_id を渡した。OpenTelemetryで使われるトレースの考え方も参考にし、APIを呼ぶ前後に、対象システム、操作名、引数の識別子、結果を記録する薄い記録処理を挟んだ。

二度目の実行では、登録直前でまた止まった。注文管理システムのAPIが、監査ログに記録する項目のうち、変更されたレコードIDを返していなかったのだ。結衣は失敗として隠さず、status を「記録不完全」として残し、処理をいったん停止した。

佐伯は承認台帳を開いた。そこには承認者の名前ではなく、灯が使うサービスアカウントの名前だけが入っていた。誰の権限で、どの条件を満たしたのかが、まだ分かれて記録されていなかった。

「灯そのものと、灯に許可を出した人を別に残そう。実行主体はエージェント。承認主体は人、または承認を委任された仕組み。ここを一つにすると、責任の道がまた消える」

結衣は記録項目に actor_type、actor_id、approver_id を追加した。判断理由は長い思考の文章ではなく、適用したルールの版、参照文書のID、判断ラベル、停止条件として残した。佐伯はその三つを、ポリシー、権限、時間で確認するSCFの柵だと説明した。

検証用APIを改修して三度目に動かすと、画面に一本の線が現れた。GmailのメールID、参照した注文規程の版、灯のエージェントID、承認申請ID、承認者、注文管理システムの更新レコードIDが、同じ trace_id で並んでいる。

結衣は承認済みの文字を見た。今度は、その下に「注文金額が規程内」「承認権限あり」「規程の有効期限内」という短い理由もあった。結果だけだった画面に、戻って歩ける道ができていた。

佐伯は、検証用の注文を停止状態に戻した。二人は最後に、例外が起きたときの停止理由、承認者、使用期限、再確認日も同じ台帳へ記録した。朝の光が机の上へ広がるころ、結衣は本番切り替えの前に、まずこの一件を監査担当と一緒に再確認する予定を書き込んだ。

昼前、倉庫から「同じ発送依頼が二つ届いている」と連絡が入った。結衣が注文処理画面を開くと、同じ取引先からの依頼が、外部の発送システムへ二度送られたように並んでいた。検証用の注文では一本の trace_id で流れを追えたのに、今回はその糸が途中でほどけていた。

「灯は、勝手に二回送ったの？」

結衣の声に、佐伯は画面を見たまま首を横に振った。

「そう見える。でも、今の記録では、通信障害による再送なのか、別の判断による新しい処理なのか、切り分けられないよ」

灯は、Gmailに届いた発送依頼を読み、注文を探し、送信の準備をした。一度目の外部API呼び出しのあと、応答が返らなかったため、灯は処理が失敗したと考えた。そして、同じ依頼をもう一度送ったらしい。けれども、ログに残っていたのは「APIを呼び出した」という短い記録だけだった。

「このログには、どの注文を処理したかがないね」

「送信先は分かる。でも、対象の注文番号も、使った受付番号もない。再送で同じ受付番号を使ったのか、新しい番号を作ったのかも見えない」

結衣は、二つの記録を交互に見た。片方が外部側で成功していたなら、二度目の送信は重複になる。片方が届いていなければ、二度目は必要な再送かもしれない。倉庫に届いた二つの依頼だけでは、最初の処理が成功したかどうかを確かめられなかった。

「送信前に、人へ確認を求めたかも残っていないよ」

「承認者も、承認の時刻も、停止した理由もない。権限チェックが許可だったのか、拒否だったのか、それとも人への確認だったのかも分からない」

結衣の指が、画面の空白をなぞった。灯が注文を読んだことは分かる。外部APIを呼んだことも分かる。だが、どの入力を使い、どのルールを当て、どの権限で、誰の承認を受けて実行したのかが、一本の流れになっていなかった。

佐伯は、付箋に「入力」「判断」「承認」「実行」と書いた。さらに、その横へ「応答なし」「再送」「外部結果」と小さく足した。

「監査証跡は、最後の結果だけを置く棚じゃない。誰が、何を根拠に、どんな条件で動かしたかを、あとからたどれる道なんだ」

その考え方は、AIエージェントの呼び出しや判断理由、対象リソース、送信先まで具体的に残す監査ログの設計にも示されている。出典5

「読むだけの処理や下書き作成なら、戻せることもある。でも、外部送信や削除は、相手の業務を動かしてしまう。だから、同じ依頼をもう一度動かす前に、もっと慎重に確かめないといけない」

佐伯は、前章で整えたSCFの図を開いた。ポリシー、権限、時間の三つの層で、「してよいか」を確かめる仕組みだと、結衣に説明した。そこへ承認の記録と例外の記録がつながれば、通信が切れたときにも、再送してよい条件を確認できる。

「SCFの判定が、許可だったか、拒否だったか、人へ確認だったか。それも、同じ trace_id の中に残すんだね」

「そう。成功した処理だけじゃない。失敗した呼び出しも、応答がない時間も、再送した理由も、同じ注文の出来事として残す」

倉庫から届いた二つの依頼は、まだ一つに戻せなかった。けれど、結衣たちの視線は、灯を責める画面から、途切れた道を探す画面へ移っていた。原因を追うために必要なのは、結果の数ではなく、入力から判断、承認、実行までを結ぶ記録なのだと、結衣は静かに気づき始めていた。

夕方、青葉ロジスティクスの小さな会議室で、結衣と佐伯は二度送られた発送依頼を紙に書き出していた。窓の外では、倉庫の灯りが一つずつ点き始めていた。

結衣は、注文画面に残る「登録しました」という短い記録を見た。紙の上には、結果の前にあったはずの道が、まだ何も描かれていなかった。

「まず、受け取った指示を書こう。次に、その指示を実行した人かエージェントを書くんだ」

佐伯は青い付箋を一枚、ホワイトボードに貼った。隣へ、もう一枚。その下へ、さらに一枚と、処理の順番に沿って並べていく。

受け取った指示 → 実行したユーザーやエージェント → 参照した文書IDと検索結果の要約 → 判断内容と信頼度 → 適用したポリシー → 承認や例外処理 → 呼び出したツール → 実行結果とエラー

「これが、灯の一回の仕事をたどる道だよ。別々のログを、同じ処理の道としてたどれるようにする。その道の名前を、trace_idにするんだ」

佐伯は一枚目から最後の付箋まで、青いペンで一本の線を引いた。結衣はその線を目で追いながら、途中で古い在庫表を参照していたことや、承認前に発送登録を呼び出していた可能性を思い出した。

「灯の考えていることを、全部保存するの？」

「全部ではないよ。モデルの思考過程をそのまま残すのではなく、あとから確かめられる形にするんだ。たとえば、判断の要約、参照した文書のID、検索結果の要約、適用したルールを残す」

佐伯は、ホワイトボードの端に大きな箱を二つ描いた。左の箱には「本文ログ」、右の箱には「判断ログ」と書いた。

「本文ログには、入力文面や灯の応答など、調査に必要な原文を入れる。ただし、機密情報や個人情報があるから、誰でも見られる場所には置かない。判断ログには、判断理由、参照先、承認、権限の結果を入れて、長く残すんだ」

「本文を見なくても、どの判断が、どのデータをもとに行われたか分かるようにするのね」

「そう。SCFのポリシー・権限・時間の階層も、判断ログに印を残す。どのルールが働き、誰の権限で、いつ実行されたかが分かれば、結果だけを見て悩まずにすむ」

佐伯は、本文ログと判断ログの間に細い線を引いた。必要な人だけが原文を開き、監査や原因調査では、まず判断ログから道筋を確認できる形だった。

「EU AI Actでも、自動で起きた出来事を記録し、あとから追跡できるようにする考え方が大切にされている。これは開発者だけのデバッグログではない。説明責任を支える記録なんだ」

会議室の時計が、六時を知らせた。結衣は青い付箋の端をそっと押さえ、空いていた場所に小さくtrace_idと書いた。

朝は、画面に浮かぶ「承認済み」だけを見ていた。夕方のホワイトボードには、その文字へ続く一本の道が、静かに残っていた。

青葉ロジスティクスの会議室で、結衣は新しい監査ログの設計画面を開いた。灯の処理を大きな一枚の記録にせず、小さな箱に分けて残す作業が始まった。

「最初は、全部を保存しようと思っていました。でも、何を残せば判断の道筋を追えるのでしょう」

「一つの処理を、あとから歩ける形にしよう。まずは時刻と trace_id だね」

佐伯はホワイトボードに、細い線を一本引いた。入力、判断、承認、実行をつなぐ線だった。結衣はその線の横に、エージェントID、セッションID、実行ユーザー、指示やリクエストの要約、使用モデルを書き足した。

「参照したデータやドキュメントIDも必要です。判断内容と信頼度、適用したポリシー、例外の有無も残します」

「それから、承認者と承認結果。呼び出したAPIやデータベース操作。権限チェックの結果。実行結果とエラー詳細も忘れないで」

結衣は入力欄を増やした。時刻は各システムで同じ形式にする。ログを作った機器だけでなく、中央のログ管理システムにも送る。時計がずれていると線が切れるため、サーバーのNTP設定も確認することにした。

二人は、最初からすべての会話を保存することはやめた。影響の大きい発送登録、返金、取引先マスタの変更から、構造化した記録を始めることにした。

「まずは四つのイベントに分けます。利用、判断、変更、費用です」

結衣は画面に四つの箱を並べた。利用イベントには、誰が、どの業務で、どのモデルを使ったかを入れる。判断イベントには、ポリシー、例外、信頼度、承認の有無を入れる。SCFの考え方に合わせ、ポリシー、権限、時間の順に確認できるようにした。

変更イベントには、プロンプト、評価データ、権限、外部連携先の変更を記録する。費用イベントには、使用モデル、処理件数、トークン、部署ごとの利用状況を入れる。結衣は、モデル名だけでなく、どの処理がどの部署で動いたかも追えるようにした。

試験運用の日、灯は取引先から届いたメールを読み、配送先の変更を判断した。処理は成功したが、判断ログを開いた結衣の顔から笑みが消えた。

「佐伯さん、メール本文がそのまま入っています。氏名も電話番号も残っています」

佐伯は画面を閉じずに、入力された文字列を指でなぞった。

「本文ログには、調査に必要な原文を残してもいい。でも、判断ログまで全文にしなくていいよ。判断ログは要約と参照先を中心にしよう」

結衣はメール本文を判断ログから外した。そこには「配送先変更の依頼を受信。取引先文書IDと権限台帳を参照」とだけ残し、文書IDと本文のハッシュを記録した。原文を置く本文ログは短期間だけ保存し、閲覧できる人も監査担当と情報管理担当に絞った。判断ログはアクセスを制限し、要約と参照先を長く残す形に直した。

その修正で、別の小さな問題も見つかった。結衣は request_id、trace_id、Idempotency-Key に、同じ値を入れようとしていた。

「三つとも、処理を見つける番号ではありませんか？」

「似ているけれど、役目が違うよ。trace_id は、入力から実行までの経路をたどる番号。request_id は、一つの要求を識別する番号だ。Idempotency-Key は、同じ処理の意図を重ねて実行しないための鍵なんだ」

佐伯は、再送の例を描いた。通信が切れて同じ発送登録を再送しても、同じ Idempotency-Key なら二重登録を止める。一方で、再送された要求には別の request_id が付くことがある。その二つも同じ trace_id の親子関係で追えるよう、結衣は項目を分けた。

「これなら、失敗した要求と、重複を止めた判断を別々に見られますね」

二人は次に、記録の形を確かめた。OpenTelemetryのトレースに沿って、エージェントの呼び出しとツール実行をつなぎ、GenAI向けの記録形式も参考にした。OpenAI Audit Logs APIのような監査記録の考え方も見比べ、誰が管理操作をしたかを別のイベントとして残すことにした。

結衣は小さなテストを三つ作った。正常な発送登録、権限のない変更、承認待ちの返金である。最初のテストでは、権限チェックの結果が「成功」とだけ記録され、どの権限を確認したのか分からなかった。

「成功だけでは、あとで確かめられませんね」

「権限名と判定時刻、参照した台帳の版も残そう。SCFの時間の箱が空いていたんだ」

結衣は項目を増やした。二度目のテストでは、古い台帳を参照したことまで見つかった。灯が判断する直前に権限台帳の版を固定し、判断イベントにその版とポリシーの識別子を入れると、古い情報を使った理由が追えるようになった。

画面の最後に、結衣は一つの処理を表す記録を表示した。agent_id、session_id、実行ユーザー、要約、モデル、参照文書、判断、信頼度、ポリシー、例外、承認者、API操作、権限結果、実行結果、エラー詳細が並び、すべてが trace_id で結ばれている。

佐伯はその記録を見て、静かにうなずいた。

「これなら、結果だけでなく、どの箱でつまずいたかが分かる。ログは秘密情報でもあるから、保存先の権限と改ざん対策も一緒に管理しよう」

結衣は本文ログと判断ログの保存場所を分け、中央の保管庫への送信を確認した。総務省の監査ログの管理にも目を通し、保存期間と閲覧範囲を処理の性質に合わせて決めた。

夕方、灯は承認待ちの返金を勝手に実行しなかった。判断ログには、信頼度、適用ポリシー、例外、必要な承認が並び、承認者が確認するまで実行結果は空欄のままだった。結衣はその空欄を見ながら、記録を増やすことより、あとで確かめられる小さな箱を正しく置くことが大切なのだと感じていた。

数日後、青葉ロジスティクスで、別の注文に外部送信の警告が上がった。配送先が、いつもの取引先とは違っていた。画面の赤い印を見た結衣の指が、静かに止まった。

「また、結果だけが残っているのかな」

佐伯が首を横に振った。前の調査で整えた監査証跡には、入力の要約、参照したドキュメントID、検索結果の要約が並んでいた。適用ルール、信頼度、権限チェック、承認状態も、同じ記録に結び付いていた。

「まず、trace_idを探そう。これがあれば、ばらばらのログを一本の流れとして見られる」

結衣は注文画面に表示されたtrace_idをコピーした。検索欄に貼り付けると、入力を受けた灯が配送先を読み取り、検索エージェントが文書を探し、判断エージェントがルールを適用した順に、細い線が画面へ伸びた。最後には、外部送信ツールの実行記録がつながっていた。

「入力の要約には、配送先変更の依頼と書かれている。でも、取引先名が少し曖昧ね」

「曖昧さは残っている。ただ、ここで決めつけない。入力、参照データ、判断ルール、権限、承認、ツール実行の順に分けて見よう」

結衣は検索結果の要約を開いた。参照されたのは、配送ルール文書の古いドキュメントIDだった。最新の配送ルールは存在していたが、検索対象から外れていた。

「古い文書だけを見て、通常の配送先ではない場所へ送れると判断したのね」

「そう見える。でも、まだ送信まで進んだ理由がある」

承認状態の欄には、「未承認」と表示されていた。外部送信の前に必要な承認は、まだ誰も行っていない。それでも例外処理の記録が、未承認のまま実行へ進めていた。

結衣は画面を見つめた。以前なら、出力を見て「AIが間違えた」と言うしかなかった。今は、どこで道が曲がったのかを、記録の順番に沿って確かめられた。

「入力が曖昧だった。参照データも古かった。承認フローにも抜けがある」

「判断ルールそのものが悪いとは、まだ言えないね。権限が広すぎたのか、ツールが重複して動いたのかも確認しよう」

結衣は判断ログに残る要約を使い、個人情報を含む注文本文は開かなかった。必要な箇所だけを、文書IDとイベントの時刻で照合した。監査ログは、誰が、いつ、何に触れたかを含む機密情報だから、扱いにも注意がいると、総務省の監査ログ管理の案内にも記されている。

画面の下には、変更イベントが残っていた。前日、灯のプロンプトと参照先が変更されていた。変更した担当者、変更前後の設定、承認の記録が、同じtrace_idに結ばれていた。

「参照先を変えたあと、最新ルールを戻す登録が抜けたんだ」

「性能観測のログだけなら、処理が速かったか、エラーが出たかは分かる。でも、どの権限で動き、承認が済んでいたかまでは説明できない」

佐伯の声は、夜の調査室に低く響いた。結衣は、灯を止めるのではなく、灯が進める道に柵を置くように設定を直した。古い文書は検索対象から外し、最新ルールだけを有効にした。承認状態が「未承認」の外部送信は、例外処理でも拒否する設定に変えた。

送信ボタンの横には、新しい確認表示が出た。承認者が記録されるまで、外部送信ツールは動かない。結衣が人の確認で処理を止めると、赤い警告は消え、画面には保留のままの注文だけが残った。

「今回は、送られる前に止められた」

佐伯はうなずいた。誰かが勘で止めたのではない。結衣が判断ログを見て、佐伯が変更イベントを確かめ、二人で古い文書と承認前の実行にたどり着いた。その夜から、調査室のログは、結果を並べる記録ではなく、理由へ戻るための道しるべになった。

新しい運用が始まった朝、青葉ロジスティクスの窓には、前の日と同じ淡い光が差していた。けれど、結衣のモニターに並ぶ文字は、もう「登録しました」だけではなかった。灯が止めた処理と、その理由が、静かに表示されていた。

結衣が注文を一件開くと、画面の左側で灯が依頼文を読み取った。参照した文書ID、使った配送ルール、判断の要約が、短い行になって並んでいる。読み取りと下書きの作成は自動で進んだが、外部送信の欄には「権限チェック済み・承認待ち」と出ていた。

「今日は、送信の前で立ち止まったのね」

灯は答えの代わりに、送信先の確認、現在の権限、承認者の指定を画面に示した。結衣が理由の欄を開くと、「注文内容と参照文書の条件に差があります。確認が必要です」とあった。削除に近い操作にも同じ表示が出て、処理は先へ進まず、途中の状態を保ったまま待っていた。

佐伯が隣の席から画面をのぞいた。結衣は、SCFの欄に並ぶ三つの言葉を指でなぞった。

「ポリシーは、何をしてよいか。権限は、誰がしてよいか。時間は、いつしてよいか。灯は、この三つを順番に確かめているんだね」

「うん。前は結果だけが先に見えていた。でも今は、止まった場所も見える」

運用担当者の画面には、通常処理の線と例外処理の線が分かれて表示されていた。自動で完了した箇所は細い青い線になり、人の確認が必要な箇所は、やわらかな橙色で灯っている。結衣は、確認すべき参照先を一つずつ開き、古い文書が混じっていないことを確かめた。

別のモニターでは、佐伯が監査用の画面を見ていた。本文そのものは開かず、入力、検索、判断、承認、実行という流れだけを追っている。画面の時計はNTPでそろい、OpenTelemetryから渡されたtrace_idが、システムをまたぐ処理を一本につないでいた。

「本文ログは、保存期間を過ぎると読めなくなる。でも判断ログには、処理の要約と参照証跡、承認履歴、変更履歴が残る」

佐伯はそう言って、変更イベントの欄を開いた。プロンプトが変わった時、評価データを入れ替えた時、権限や連携先を更新した時も、別の記録が残るようになっている。誰かが大きな声で説明しなくても、画面の小さな印が、いつ何が変わったかを伝えていた。

昼前、灯は別の注文で動きを止めた。読み取った住所と取引先台帳の表記が少し違い、判断の確かさが足りなかった。

「確認が必要です」

結衣は承認画面を開いた。以前なら、登録済みの文字を見て首をかしげていたはずだった。今は入力された注文から、参照した台帳、灯の判断、止まった理由、承認者の欄まで、静かに指でたどることができた。

「ここなら、何を見て決めればいいか分かるね」

承認が済むと、灯は送信を再開した。画面の線が橙色から青色へ変わり、処理の最後に一つのtrace_idが残った。朝の光はモニターの端をそっと照らし、その小さな文字だけが、静かな画面で長く灯っていた。