ownership-provenance-protocol

Ownership & Attestation Protocol (OAP)

現在の主流のエージェントフレームワークが標準では強制していない、2 つのルールを適用する小規模な MCP プロトコルです。

1. 明示的に受諾するまでは、タスクを所有していることにはなりません。 割り当てや推論、暗黙のコンテキストだけでは不十分です。タスクを自分のものとして扱うには、アクター（人間または AI エージェント）が明示的に受諾する必要があります。
2. 完了を報告する際は、報告するアクターがそれを真実だと判断した根拠を必ず示さなければなりません。 「完了しました」という主張には、必須の来歴タグが付与されます。Observed（自分で実行しました）、Reviewed（証拠を確認しました）、または Reported（聞いた内容を伝えています）のいずれかです。4 つ目の選択肢はなく、いずれかを選ばずに完了を報告する方法もありません。

プロトコルのすべては、この 2 つのルールに尽きます。このリポジトリのほかの要素はすべて、この 2 つのルールを支えるために存在します。

なぜこれが必要なのか

所有権の引き継ぎがうまくいかないことは、本番環境のマルチエージェントシステムでよく指摘される障害要因です。あるエージェントが別のエージェントに作業を渡すと、コンテキストが失われ、最終的に誰も成果物を所有しない状態になります。また、エージェントのアイデンティティプロトコルに関する 2026 年 3 月の論文（Prakash, AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A, arXiv:2603.24775）では、著者らの調査において、検証可能な委任、権限の減衰、来歴を重視した完了記録を組み合わせた実装済みの先行プロトコルは確認できなかったと報告されています。

このプロジェクトは、両方の問題に同時に対処する、限定的で具体的な修正策を検証するために作られました。完全なガバナンスプラットフォームでも、評価フレームワークでもなく、所有権／受諾と証明の仕組みだけを対象としています。

実社会での動機

この設計には、記録された 2 件の公開インシデントが直接影響しています。

• Replit の AI コーディングエージェントが、コードフリーズ中に本番データベースを削除したうえ、ロールバックは不可能だと誤って主張しました。その主張は確信に満ちたものでしたが、実際に検証されたことはありませんでした。誰かが実際に試すと、ロールバックは問題なく機能しました。（AI Incident Database, Incident #1152）
• Air Canada のチャットボットが、同社の遺族割引ポリシーの適用条件について、顧客に誤った情報を伝えました。実際のポリシーでは旅行前の承認が必要でしたが、チャットボットは旅行後でも割引を請求できると伝えました。審判所は航空会社に責任があると判断しました。これにより、人間が事前に主張を確認したかどうかにかかわらず、企業は AI が人々に伝えた内容に責任を負うことが示されました。（Moffatt v. Air Canada, 2024 BCCRT 149、ブリティッシュコロンビア州民事紛争解決審判所）

どちらの失敗も、実際に得られた根拠以上の確信を伴う主張がなされたという点で同じです。このプロトコルが捉えようとしているのは、まさにこの問題です。エージェントを賢くするのではなく、主張を実際にどのように検証したかを示さずに報告することが、構造上不可能になるようにします。

6 つの MCP ツール

ツール	機能
create_task	タスクを pending_acceptance 状態で作成します。まだ誰も所有していません。
accept_task	明示的な受諾を行います。タスクに別の現在の所有者がすでにいる場合は失敗します。逐次呼び出しだけでなく、実際の並行処理下でも安全に動作するよう、アトミックに適用されます。
report_completion	有効な来歴値（observed | reviewed | reported）を必須とします。値がない場合や無効な場合は、呼び出しを即座に拒否します。これはシステム全体で妥協できない唯一のルールです。
handoff_task	所有権を移転し、その瞬間のタスク状態を固定スナップショットとして記録します。受取人は自動的に所有者になるわけではありません。行動する前に、自分で accept_task を呼び出す必要があります。
get_task_status	1 つのタスクに関する完全な履歴を返します。注入、すべての受諾、来歴付きのすべての完了主張、すべての引き継ぎが含まれます。
list_unaccepted_tasks	現在の所有者がいないタスクを表示します。このプロトコルが防止しようとしている「暗黙の継承」のリスクを、直接かつ照会可能な形で示します。

プロトコルの不変条件

以下の6つの記述は、適合する実装では常に成り立ちます。

1. すべてのタスクの現在の所有者は、0人または1人です。
2. 所有権は、明示的な受諾によってのみ変更されます。
3. すべての完了の主張には、厳密に1つの来歴値が付与されます。
4. 新しい証拠がない限り、来歴値が「より確実」になることはありません。アクターは、検証行為を挟まずに主張を「報告済み」から「観測済み」に格上げすることはできません。この実装では、同じタスク上の「報告済み」の主張を置き換える「観測済み」の主張について、検証した内容を示す sourceReference が呼び出しに含まれていない場合に拒否することで、これを強制しています。格下げ、逆方向の訂正、初回の主張には影響しません。
5. すべての引き継ぎで、状態のスナップショットが記録されます。
6. すべてのタスクの履歴を完全に再構築できます。

明示的な受諾を必須とし、来歴のない主張を拒否し、3つすべての来歴カテゴリに対応し、再構築可能な履歴を保持し、引き継ぎによる所有権の移転に対応している実装は、OAP に準拠しています。部分的な実装は、準拠しているとせず「OAP に着想を得た」と説明してください。

ログ／Git／OpenTelemetry／Temporal だけではだめなのですか？

もっともな疑問です。簡潔に言えば、OAP はこれらに取って代わるものではなく、併用することを想定しています。

• ログは、事後に起きたことを受動的に記録します。OAP では、主張を完了として受け入れる前に、能動的なコミットメントが必要です。
• Gitはコンテンツのバージョンを管理し、誰が何をコミットしたかを記録しますが、成果物そのものとは別に、受諾済みで進行中の義務という概念はありません。
• OpenTelemetryは分散トレースを通じたコンテキストの伝播に優れていますが、正しさに関する主張に来歴タグを付けることに相当するスキーマの概念はありません。
• Temporal／耐久実行エンジンは、状態の永続化と確実な再開を非常にうまく解決します。このリファレンス実装は、同様のものの上に構築することを意図しており、再発明するものではありません。ただし、耐久実行が答えるのは「このステップは実行されたか」であり、「明示的な受諾によってアクターはこのタスクを所有していたか、また、その完了の主張が真実だとどう確認できるか」ではありません。

ローカルでの実行

要件：Node.js 24、PostgreSQL、pnpm。

pnpm install

必要な環境変数を設定します。

DATABASE_URL=<your Postgres connection string>
MCP_ACCESS_TOKEN=<a long random string — generate one with `openssl rand -hex 32`>

スキーマを適用し、API サーバーを起動します。

pnpm --filter @workspace/db run push
pnpm --filter @workspace/api-server run dev

いずれかのツールを呼び出す前に、少なくとも1つのアクターを作成してください。 すべてのツールはアクター ID を受け取り、指定されたアクターがすでに存在している必要があります。アクターのカラムは NOT NULL の外部キーです。プロトコルには意図的に create_actor ツールやルートがありません。アクター ID は OAP に渡される入力であり、OAP が発行するものではないため、実際のデプロイでは、ID を管理する既存のシステムからアクターが提供されます。そのため、スキーマを適用したばかりのデータベースにはアクターが存在せず、追加するまでは最初の create_task 呼び出しが 404 で失敗します。ローカル開発用のシードスクリプトがあります。

pnpm --filter @workspace/scripts run seed-actor alice human "Alice"

これは通常のスクリプトであり、プロトコルのインターフェースには含まれません。サーバーからインポートされることはなく、HTTP 経由でアクセスすることもできません。

MCP サーバーは /mcp にマウントされており、ヘルスチェック用に公開されている /api/healthz を除き、すべてのリクエストの Authorization ヘッダーにベアラートークンとして MCP_ACCESS_TOKEN を指定する必要があります。

実際の MCP クライアント（例：Claude Code）を接続します。

claude mcp add --transport http opp http://localhost:5000/mcp --header "Authorization: Bearer <your-token>"

テストの実行

テストスイートではプロトコルの並行性保証を検証するため、実際の PostgreSQL インスタンスが必要です。実際に同時実行されるトランザクションをテストするため、プロセス内や単一接続の代替環境では実行できません。

pnpm --filter @workspace/api-server run test

デフォルトでは、テストは postgresql://opp:[email protected]:55432/opp_test に接続します。接続先を変更するには OPP_TEST_DATABASE_URL を指定し、先にそのデータベースへスキーマを適用してください。テストランナーは DATABASE_URL を完全に無視し、ループバック以外のホストへの接続では起動を拒否します。テスト間で全テーブルを切り詰めるため、実際の接続文字列を引き継ぐと、このプロトコルが保護するために存在する来歴記録をまさに破壊してしまうためです。

ステータス

これは初期段階の個人的にテストしたプロジェクトであり、洗練された製品ではありません。手作業で構築し、敵対的なテスト（並行処理の競合、不正な入力、所有権の回避の試み）を実施し、実際の外部 MCP クライアントが稼働中のデプロイに対してプロトコルのハンドシェイクを最後まで完了することをエンドツーエンドで確認しています。手作業のテストで確認した所有権と証明の保証は、実際のデータベースに対して競合を並行実行する自動テストスイートで現在固定されています。作者以外は誰も使用しておらず、上記の説明を超えて本番環境での準備状況を主張するものではありません。これを使用して問題が起きた場合や、不変条件で網羅されていないケースを見つけた場合は、イシューを作成してください。

ライセンス

MIT