「AIエージェントで請求処理を自動化したのはいいんですが、先日、監査法人から『この振込はエージェントが誰の権限で、何を根拠に実行したのか証明できますか』と聞かれて、答えられなかったんです」。先日の相談で、ある中堅企業の情報システム責任者がこう切り出しました。エージェントは確かに動いている。ログも残っている。だが「そのログが事後に改ざんされていない」ことも、「実行時にどのポリシーが適用されたか」も、そのログ単体では示せなかったのです。
これは特殊な事例ではありません。「AIで自動化できます」と受託で提案し、実際に動くものを納めた後、半年後に「本当にこの通り動いたのか」「なぜこの判断をしたのか」を説明・監査できないことが発覚して炎上する。発注判断者が漠然と抱く「後から証明できないのが怖い」という不安は、技術的に見ても正しい不安です。本記事では、2026年6月に登場した Dapr 1.18 の「検証可能な実行（Verifiable Execution）」を手がかりに、受託でAI自動化を入れるとき監査証跡をどう設計するかを整理します。Dapr はあくまで手段の一つで、主役は「監査可能性をどう担保するか」という設計思想です。
「ログは残っています」が監査で通用しない理由
多くの現場で、AIエージェントの監査対策は「ログを出力している」で止まっています。だがエージェントのログには、従来システムにはなかった固有の弱点が三つあります。
一つ目は改ざん検知ができないこと。普通のアプリケーションログは追記式のテキストやJSONで、後から書き換えても痕跡が残りません。2026年以降、監査人は「改ざんされていないことを証明できないログは証拠として割り引く」方向に動いています。
二つ目は「誰の権限で」が抜けること。エージェントはサービスアカウントやAPIキーで外部システムを叩くため、ログには「サービスアカウントXがアクセスした」としか残らず、「どの人間の指示を受けて、どの委譲権限で実行したか」が記録されません。これは個人帰属を求める各種規制（GDPR、SOX 等）の観点で致命的です。
三つ目は「なぜ」が記録されないこと。エージェントが「ファイルを削除した」という事実と、「なぜ削除が正しいと判断したのか」は別物です。実行の事実だけでなく、その時点でどのポリシーが評価され、どのツールがどの引数で呼ばれたか — そこまで揃って初めて監査に耐える証跡になります。
| ログのレベル | 記録される内容 | 監査で通用するか |
|---|---|---|
| アプリログのみ | 「処理しました」のテキスト | 通用しない（改ざん検知不可） |
| 構造化ログ | ツール名・引数・タイムスタンプ | 弱い（改ざん検知・権限帰属が不足） |
| 検証可能な実行 | 上記＋署名・委譲権限・ポリシー判定 | 通用する（改ざん検知＋来歴証明） |
Dapr 1.18 が持ち込んだ「検証可能な実行」の中身
Dapr 1.18 が 2026年6月に導入した検証可能な実行は、ワークフローやAIエージェントの実行記録に暗号学的な信頼を持ち込む機能群です。具体的には三つの能力から構成されます。
ワークフロー履歴の署名（Workflow History Signing） は、ワークフローの実行履歴を SPIFFE 標準に基づくワークロード識別子で暗号署名し、改ざん検知可能（tamper-evident）な記録を作ります。各ステップの署名がサイドカーの mTLS 上の X.509 SPIFFE 識別子のもとで生成され、前のステップの署名に連鎖していくため、状態を読み込むたびに署名チェーン全体が検証されます。途中の1ステップを書き換えれば、チェーンが切れて検知できる、という仕組みです。
ワークフロー履歴の伝播（Workflow History Propagation） は、実行の来歴（lineage）をサービス・ワークフロー・アプリケーションの境界を越えて運びます。下流のシステムが「この要求はどこから来て、どんな先行アクションの影響を受けているか」を辿れるようになります。
ワークフローの証明（Workflow Attestation） は、アクティビティや子ワークフローが「検証済みの実行コンテキスト」を受け取れるようにし、ポリシー・コンプライアンス判定を検証済みの来歴に基づいて下せるようにします。
技術的には、Dapr のワークフローエンジンが各ステップの入力・出力・ツール呼び出しメタデータをハッシュ化し、SPIFFE/SPIRE が払い出したワークロードスコープの鍵で署名した「実行レシート」を生成、これを状態管理API経由で追記専用の台帳として保存します。要するに「エージェントが何をしたかの、改ざんできない元帳」を実行基盤のレイヤーで作る、ということです。重要なのは、これがアプリのログ実装に頼らず、ワークフローの中に暗号学的な証明を埋め込んでいる点です。
ここで効いてくるのが、誰の権限で動いたかを識別する基盤です。SPIFFE 識別子による権限の設計は、AIエージェントの認証・認可設計で扱った「エージェントに固有のアイデンティティを与える」議論と地続きで、その上に署名・証跡を重ねる構図になります。
なぜ「監査可能性」が今、発注判断の論点になったのか
技術的な話の前に、なぜ今これが経営とコンプライアンスの論点になったのかを押さえておく必要があります。きっかけは規制です。
EU AI Act の高リスクAIシステム義務が 2026年8月2日 に施行されます。Article 12 は高リスクシステムに対し「システムのライフタイムにわたるイベントの自動記録」を技術的に可能にすることを求め、ログの最低保持期間は6か月（広範な技術文書は撤去後10年）と定めています。非遵守の制裁は最大1,500万ユーロまたは全世界売上高の3%。信用スコアリング、重要インフラ、雇用に関わるAIは高リスクに分類されるため、対象は決して一部の特殊業種に限りません。
| 観点 | 求められること |
|---|---|
| 実行の記録 | 何を・いつ・どのツールで実行したかの自動記録 |
| 個人への帰属 | どの人間の指示・委譲権限で動いたか |
| 改ざん不可 | 記録が事後に書き換えられていない証明 |
NIST も2026年2月にエージェント型AIを独立した規制カテゴリとして扱う標準化イニシアチブを立ち上げており、規制の方向性は「説明責任・行動の透明性・人間の監督」で各国がそろってきています。発注側の責任者が「後から証明できないのが怖い」と感じるのは、感覚ではなく規制が現実にそれを求め始めたからです。そして重要なのは、監査証跡は後付けが圧倒的に弱く・高くつくという点です。実行時に証拠を作っていない仕組みに、半年後に改ざん検知可能なログを足すのは、ほぼ作り直しに近い工事になります。
「推論トレース」は監査証跡ではない
ここで受託の現場でよく混同される論点を一つ。「LLMの推論過程（reasoning trace）を保存しているから説明責任は果たせる」という主張です。これは半分正しく、半分危険です。
推論トレースは「なぜエージェントがその判断を正しいと考えたか」を示す貴重な材料です。だがそれ自体は監査証跡ではありません。理由は単純で、推論トレースは改ざんできるし、実行と結びついている保証がないからです。「削除が正しいと判断した」というトレースが残っていても、それが実際の削除実行と同一のもので、かつ事後に編集されていないことを証明できなければ、監査人はそれを証拠として採用しません。
監査に耐える証跡が要求するのは、実行の観測（何をしたか）と意図の観測（なぜしたか）の両方を、それぞれ改ざん検知可能な形で、実行と紐づけて残すことです。Dapr の検証可能な実行が「ツール呼び出しメタデータも含めてハッシュ化・署名する」のは、まさにこの「推論や意図を含む実行の塊を、まとめて改ざん不可にする」ためです。推論トレースを残すこと自体は良いことですが、それを監査証跡と呼べるかは「署名されているか／実行と結合されているか」で決まります。
事例: 与信判断を自動化した後の「証明できない」を作り直した案件
ある事業者向け金融サービスの会社から、稼働中のシステムについて相談を受けました。同社は申込審査の一次判定をAIエージェントに任せており、エージェントが外部の信用情報API・社内の取引履歴・ルールエンジンを横断して「承認／保留／否認」を出す構成でした。月間およそ8,000件を処理し、人間の審査担当はエージェントが保留にした分だけを見る運用です。
問題が表面化したのは、否認された申込者から不服の問い合わせが入り、社内で「この案件、なぜ否認になったのか」を再現しようとしたときでした。アプリログには「decision: reject」と残っているものの、判定時に参照したスコアの値も、適用されたルールのバージョンも、エージェントがどの権限で外部APIを呼んだのかも特定できなかったのです。さらに、ログはアプリのDBに平文で保存されており、改ざんされていないことを証明する手段もありませんでした。EU 圏の顧客も抱えていたため、2026年8月の高リスク義務を前に、これは放置できない欠陥でした。
打ち手は三段階に分けました。第一に、エージェントの各ステップを Dapr のワークフローとして再構成し、入力・出力・ツール呼び出しを署名付きレシートとして記録する基盤に載せ替え。第二に、外部API呼び出しを SPIFFE 識別子に紐づけ、「どのワークロードが・どの委譲権限で」呼んだかを証跡に残す設計に変更。第三に、ルールエンジンのバージョンと適用ポリシーを判定コンテキストとして証跡へ含め、後から「この判定はルールv2.3で、スコア閾値X未満だったため否認」と再現できるようにしました。
結果として、不服申し立てがあった案件の判定根拠を平均で数日かかっていた調査が、台帳の照会で当日中に再現できるようになりました。改ざん検知の署名チェーンが入ったことで、監査法人とのやり取りでも「ログが書き換えられていない証明」を提示できるようになり、8月の義務化に間に合いました。総工数はおよそ7週間。既存のエージェントロジックには大きく手を入れず、実行基盤のレイヤーに証跡を差し込んだことで、作り直しの範囲を抑えられたのが効きました。
なお、この案件では「エージェントが量産したコードのレビュー体制」も同時に課題になりました。証跡だけ整えても、生成されたコード自体の品質管理が無ければ片手落ちになる、という観点はAIが量産するコードのレビュー・管理で詳しく扱っています。
受託でAI自動化に監査証跡を設計するときの勘所
Dapr を使うかどうかに関わらず、受託でAI自動化を入れるなら、監査可能性は最初から SOW（作業範囲）に書くべき項目です。後付けが効かない領域だからです。設計時に握っておく論点を整理します。
| 論点 | 後付けが効かない理由 | 最初に決めること |
|---|---|---|
| 改ざん検知 | 後から署名しても過去ログは保証できない | 実行時に署名・ハッシュ連鎖を入れるか |
| 権限の帰属 | サービスアカウント運用は事後に分解不能 | エージェントに固有の識別子を与えるか |
| ポリシーの記録 | 当時のルール版は再現できない | 判定コンテキストに版を含めるか |
| 保持と提出 | 形式が分析不能だと監査で使えない | 保持期間と提出形式を規制要件で決める |
ベンダーロックを避ける観点も重要です。Dapr は CNCF のオープンソースプロジェクトで、SPIFFE という業界標準のアイデンティティ基盤の上に立っているため、特定クラウド・特定ベンダーに縛られにくい構成を取れます。ただし「Dapr を入れること」が目的化すると本末転倒です。発注側が確認すべきは製品名ではなく、「実行が改ざん検知可能か」「誰の権限で動いたか辿れるか」「なぜそう判断したか再現できるか」の三点が満たされる設計になっているかどうかです。
そしてもう一つ、見落とされがちなのが「正規の自動化以外のエージェントが動いていないか」という統制です。検証可能な実行で正規ワークフローの証跡を固めても、現場が勝手に立てたエージェントが裏で動いていれば監査範囲に穴が空きます。この点はシャドーAIのガバナンスと合わせて設計するのが現実的です。
次の一歩 — 「証明できるか」を今のシステムで試してみる
導入を検討する前に、まず手元のAI自動化で一つ試してほしいことがあります。直近にエージェントが実行した処理を一件選び、「何を・いつ・誰の権限で・なぜ実行したか」を、改ざんされていない証明付きで再現してみることです。これができないなら、監査が来たときに答えられないのと同じ状態です。
再現できなかった項目が、そのまま設計の不足リストになります。改ざん検知が無いのか、権限帰属が無いのか、ポリシーの版が残っていないのか — どこが欠けているかが分かれば、Dapr の検証可能な実行のような仕組みを入れるべきか、もっと軽い構造化ログの改善で足りるのかも判断できます。規制の対象になる業務（信用・人事・重要インフラ等）から優先的に試すのが現実的です。
グリームハブでは、稼働中のAIエージェント／自動化に対する監査証跡の設計レビューから、検証可能な実行を実装に落とし込む受託までを手がけています。「AIで自動化したものの、後から実行を証明できる自信がない」「2026年の規制に間に合わせたいが、何から手を付ければいいか分からない」といった開発・AI・自動化のご相談は、お問い合わせフォームからお気軽にどうぞ。動くものを作ることと、後から証明できるものを作ることは、別の設計判断です。
Sources
- Dapr 1.18 Introduces Verifiable Execution, Bringing Cryptographic Trust to AI Agents and Workflows（InfoQ）
- Introducing Verifiable Execution in Dapr 1.18（CNCF Blog）
- Why Dapr 1.18’s verifiable execution puts cryptographic proof inside the workflow itself（diginomica）
- Article 12: Record-Keeping（EU Artificial Intelligence Act）
- AI Agent Accountability: Reasoning Traces vs Real Audit Trails（Apptitude）
