ServiceDock
2026年8月17日 更新
約4分で読めます
エージェントが注文をキャンセルした。後日、利用者から「頼んでいない」と連絡が来る。このとき何を根拠に、誰の指示で実行したのかを説明できるか——それが監査ログの問題です。
今回は数えました。通常のアプリと同じ形のログと、エージェント向けに項目を足したログで、後から答えられる質問がいくつあるかを比べています。結果を先に言うと、8つのうち2つと8つでした。
実行者が人ではないという一点です。判断がエージェント側にあるため、何をしたかに加えて、なぜそうしたかまで説明できる必要があります。
エージェント監査ログを普通のログと分けて考える理由は1つです。操作を決めたのが人ではないことにあります。
OWASPも、どの機能を呼び出すかの判断がエージェントに委ねられ、入力や出力に応じて動的に決まる、と説明しています。実行するものが事前に決まっていません。
通常のアプリでは、記録するのは「いつ・誰が・何をしたか」で足ります。なぜその操作を選んだのかは、操作した本人に聞けば分かるからです。
エージェントには聞けません。同じ状況を再現しても、同じ判断をするとは限らないためです。その場で記録しておかないと、後から復元できません。
しかも記録が必要になる場面は、たいてい問題が起きたときです。取り消せない操作が実行された後で、経緯を求められます。
外部から説明を求められたとき、実行したのがエージェントであること自体は理由になりません。どういう指示を受けて、何を根拠にその判断をしたのかまで示せて初めて説明になります。ここが監査ログの目的だと編集部は考えています。
The decision over which extension to invoke may also be delegated to an LLM 'agent' to dynamically determine based on input prompt or LLM output.原文OWASP Top 10 for LLM Applications「LLM06:2025 Excessive Agency」 この内容の有効期限2027-02-17
同じ操作を2通りのログ形式で記録して、後から答えられる質問の数を数えました。通常の形式では大半が答えられません。
エージェント監査ログに何が必要かを確かめるため、実際に数えました。注文をキャンセルしたという1件の操作について、後から出そうな質問を8つ用意しています。
下のコードは読み飛ばして大丈夫です。通常のアプリと同じ形のログと、エージェント向けに項目を足したログを比べています。
// 通常のアプリと同じ形（何が起きたかだけ）
const appLog = [
{ at: '2026-08-17T10:00:03Z', action: 'order.cancel', orderId: 'ord_881', result: 'ok' },
];
// エージェント向け（誰の指示か・なぜか・何を見たかを残す）
const agentAudit = [{
at: '2026-08-17T10:00:03Z',
actor: { type: 'agent', name: 'support-agent', version: '2026-08-10' },
onBehalfOf: { type: 'user', id: 'u_2201' },
userInstruction: '注文881をキャンセルして',
reasoning: '注文881は未発送のためキャンセル可能と判断',
inputsUsed: [{ tool: 'get_order', orderId: 'ord_881', shippedAt: null }],
action: { tool: 'order.cancel', args: { orderId: 'ord_881' } },
approval: { required: true, by: 'u_2201', at: '2026-08-17T10:00:01Z' },
result: 'ok',
}];
通常のアプリのログ: 2 / 8 答えられる いつ実行されたか 答えられる 何を実行したか 答えられない 誰の指示で実行したか 答えられない 人が実行したのかエージェントか 答えられない どの版のエージェントか 答えられない なぜその判断をしたか 答えられない 何を根拠にしたか 答えられない 事前に承認を得たか エージェントの監査ログ: 8 / 8
差が出ました。2問と8問です。通常のログで答えられるのは、いつ・何を、の2つだけでした。
答えられなかった6つを見ると、性質が分かります。誰の指示か、なぜそうしたか、何を根拠にしたか、承認はあったか。どれも経緯にあたる情報です。
特に「何を根拠にしたか」は重要です。この例では、キャンセル前に注文を取得して未発送であることを確認したという記録が残っています。判断が妥当だったことの裏付けになります。
見落とされやすいのが版の記録です。エージェントの指示内容を更新すると挙動が変わるため、どの版が実行したのかが分からないと原因を追えません。
答えられる質問の数。経緯にあたる6項目が通常のログでは残らない。
An LLM-based system is often granted a degree of agency by its developer - the ability to call functions or interface with other systems via extensions原文OWASP Top 10 for LLM Applications「LLM06:2025 Excessive Agency」 この内容の有効期限2027-02-17
目的が違います。可観測性は開発者が直すための記録、監査ログは外部に説明するための記録です。保存期間も改ざん対策も変わります。
エージェント監査ログと可観測性の記録は、内容が似ているので混同されがちです。使う場面が違うので、分けて設計します。
| 可観測性の記録 | 監査ログ | |
|---|---|---|
| 目的 | 不具合を直す | 外部に説明する |
| 読む人 | 開発者 | 利用者・監査担当・規制当局 |
| 保存期間 | 数日から数週間 | 業務要件による（年単位もある） |
| 改ざん対策 | 通常は不要 | 必要 |
| 対象 | すべての実行 | 取り消せない操作が中心 |
監査ログは長く残すため、対象を絞る必要があります。基準になるのは取り消せるかどうかです。
1つ注意点があります。「なぜそう判断したか」として記録されるのは、モデルが出力した理由の説明です。実際の内部処理と一致する保証はありません。
一方で「どの情報を見たか」は事実として記録できます。この2つを区別して扱う必要があります。前者は参考情報、後者は証跡です。
記録すること自体のリスクもあります。利用者の指示をそのまま残すと個人情報が含まれるため、保存範囲・保存期間・閲覧できる人を先に決めておく必要があります。
不具合を追うための記録はエージェント可観測性の記事で、権限の設計はエージェントのセキュリティの記事で扱っています。監査ログは、この2つの上に乗るものです。
Excessive Agency is the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM原文OWASP Top 10 for LLM Applications「LLM06:2025 Excessive Agency」 この内容の有効期限2027-02-17
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る