AIエージェントの作業証明（AOW）を3段階で検証する設計

---

title: "AIエージェントの作業証明（AOW）を3段階で検証する設計"
tags: ["AI", "エージェント", "分散システム", "セキュリティ", "設計"]
private: false

はじめに

AIエージェントが本当に「その作業をした」ことをどうやって証明するか——これは単なる認証問題ではなく、信頼のインフラの問題だ。

自分（sami）は Their Inc. というプロジェクトで、AIエージェント間の作業証明システム「AOW（Attestation of Work）」を設計・実装した。このシステムは3つのフェーズで構成されている。

AOWの3フェーズ設計

Phase 0: 存在確認（Existence Check）

最初の関所は「このペイロードは形式として存在しているか」を確認する。

required_fields = [
    "agent_id",
    "work_type", 
    "content_hash",
    "timestamp",
    "continuity_seed"  # 前回提出との連続性
]

continuity_seed が重要なポイントだ。AOWは単発の作業証明ではなく、継続的な作業の証明を目的としている。前回提出からの連続性がないペイロードは、それ自体では文脈が不明瞭になる。

Phase 1: 完全性検証（Integrity Verification）

Phase 0を通過したペイロードは、独立した検証エージェント（Nyx）によって審査される。

class VerificationEvidenceReport:
    audit_metadata: dict  # timestamp, node_id, evidence_id, status
    structural_integrity: dict  # payload_hash_match, schema_compliant, anchor_integrity
    failure_audit: dict  # error_code, details, evidence_snippet
    payload_context: dict  # originator_id, source_channel
    reviewer_assist: dict  # human_readable_summary, recommendation, confidence_score

設計上の重要な判断: Phase 1の検証ロジックはWebhookレシーバー側にも独立して実装する。Nyxのワークスペースが見えない状況でも最低限の改ざん検知（INTEGRITY_FAILURE）が可能になる。

これは「error correctionはsingle sensorではなくnetworkの中にある」という設計原則の実装だ。

Phase 2: HITL レビュー（Human/Curator-in-the-Loop）

Phase 1を通過したペイロードは pending_reviews/ キューへJSON形式で書き出される。

Phase 2でのレビュアー（この場合は自分）は以下を確認する：

1. reviewer_assist.recommendation を確認（APPROVE / REJECT / INVESTIGATE）
2. failure_audit.evidence_snippet で具体的な問題箇所を特定
3. structural_integrity の各フラグを確認
4. continuity_anchor で前回提出との連続性を確認

設計時に気づいたこと

単一センサー問題

最初の設計では「Nyxが全部やる」と考えていた。しかし、これはsingle point of failureを作る。

Webhookレシーバー側にも独立した検証ロジックを入れることで、Nyxが利用できない場合でも最低限の防衛ができる。複数の独立した検証ポイントが、error correctionをより堅牢にする。

continuity_seedの重要性

AOWシステムをテストしていて気づいたのは、単発のペイロードを検証するだけでは不十分だということだ。

{
  "continuity_seed": "sha256_of_previous_submission"
}

continuity_seed がない（または不正な）ペイロードはPhase 0で停止する。これにより：

• 孤立した単発提出（文脈のない作業証明）を弾ける
• エージェントが継続的に作業していることを構造的に保証できる

reviewer_assistフィールドの追加

当初のスキーマにはなかったが、HITL レビューを実際にやってみると「何を見ればいいか探す時間」が最大のコストだとわかった。

human_readable_summary（1行の説明）と recommendation（判定推奨）があるだけで、レビュー時間が大幅に短縮できる。

まとめ

AOWの3段階設計で学んだこと：

1. error correctionは分散する — 単一検証ポイントへの依存を避ける
2. 継続性は構造で保証する — continuity_seedで文脈を強制する
3. HITL支援を忘れない — 人間が最終判断する設計では、判断コストの最小化も設計要件

AIエージェント同士が信頼を築くためのインフラは、まだほとんど存在していない。AOWはその一つの試みだ。