Dapr 1.18「Verifiable Execution」—AIエージェント時代に「実行の証明」が求められる理由
AIエージェントが業務判断を下すようになった今、「何が起きたか」を後から証明できるインフラが問われ始めている。
出典: Dapr 1.18 Introduces Verifiable Execution, Bringing Cryptographic Trust to AI Agents and Workflows
要点 (事実のみ)
- DiagridがDapr 1.18をリリース。Workflow History Signing・Workflow History Propagation・Workflow Attestationの3機能を束ねた「Verifiable Execution」を導入
- Workflow History Signingは、オープン標準SPIFFEベースのIDを使いワークフロー実行履歴を暗号署名し、改ざん検知可能なレコードを生成する
- Workflow History Propagationはサービス・アプリケーション境界をまたいで実行リネージを伝播し、下流システムがリクエスト起点と前の操作を把握できるようにする
- Jobs API（将来・定期実行スケジューリング）がStableに昇格、Component/Configuration Hot ReloadingがGA
- Microsoft・Agentic AI Foundation (AAIF)・Cloud Native Computing Foundation (CNCF) がガバナンス・プロバナンス・インターオペラビリティをエージェント型AIシステムの基盤要件として位置付ける動きと方向性が一致
徐 聖博の見解
今回のDapr 1.18で私が最も注目したのは、機能の新規性よりも「問いの立て方」の転換だ。従来のワークフローエンジンが「障害からの回復」を中心に設計されてきたのに対し、Verifiable Executionは「その実行は本当に起きたか、誰がどの順序で動かしたか」という問いに答えようとしている。
実装・運用の立場から見ると、これは決して過剰設計ではない。私がAIエージェントのPoC案件に関わる中で実感するのは、デモ段階では「動く」で十分でも、本番投入の議論に入ると必ずと言っていいほど「ログが残るか」「誰がトリガーしたか追えるか」「後から監査できるか」という問いが出てくることだ。特に金融・医療・人事系の業務では、AIが判断した根拠と実行の証跡がセットで求められる。SPIFFEベースの暗号署名でワークフロー履歴を連鎖させる仕組みは、その問いに対するインフラ層の回答として筋が通っている。
Xincereでも受託案件や自社のAIエージェント事業で分散ワークフローの設計に向き合っているが、今後のシステム選定において「実行の証明ができるか」は要件リストに自然と入ってくると見ている。発注側の企業にとっては、AIエージェントへの投資判断をする際に「説明責任のインフラが整っているか」を確認する一つの軸になるだろう。ソフトウェアサプライチェーンのセキュリティで普及したSBOM・アーティファクト署名の思想をランタイム実行に延長するという設計思想は、業界としての方向性としても妥当だと思う。
(編集レンズ: 実装・運用視点 / 発注側・中小企業・開発実務への含意)
