DCP コアの仕様¶

英語の仕様の参考訳です（25/10/2026 更新）。規範となるのは英語版です。この翻訳に規範的な効力はなく、内容が異なる場合は英語版が優先されます。識別子とコードブロックは翻訳せずにそのまま掲載しています。

状態： 公開済み — v2.0
バージョン： 2.0
日付： 2026-03-01

1. はじめに¶

Digital Citizenship Protocol（DCP）は、開かれたネットワークで動く AI エージェントのための、持ち運べる説明責任の層を定義します。DCP コアは、プロトコルの最小限の相互運用可能な範囲で、すべての適合した実装がサポートしなければならないアーティファクト、関係、検証の規則の集合です。

DCP のバンドルを受け取った検証器は、中央の権威に頼らずに 4 つの問いに答えられます：

このエージェントに誰が責任を負うか？
エージェントは何をするつもりだと宣言したか？
その意図にどのポリシーの結果が適用されたか？
エージェントの行動についてどの検証可能な証拠があるか？

DCP コアは、これらの答えの構造と意味を定義します。特定の暗号アルゴリズム、伝送の仕組み、ガバナンスのポリシー、運用のインフラは定めません。それらはプロファイルとサービスに属します。

1.1 既存の仕様との関係¶

この文書は、すでに次で公開されている内容を整理し統合する、編集上の仕様です：

DCP-01 — アイデンティティとプリンシパルへの結び付け
DCP-02 — 意図の宣言とポリシーによる制御
DCP-03 — 監査チェーンと透明性
BUNDLE — Citizenship Bundle の形式
VERIFICATION — 検証のチェックリスト
DCP-AI v2.0 — ポスト量子の拡張を含む完全な規範的な仕様

これらの文書を置き換えるものではありません。コアを一望できるようにし、コアとプロファイルの境界を明確にします。

2. 問題の記述¶

AI エージェントは、開かれたネットワークでますます自律的に動くようになっています。API を呼び、データを交換し、取引を行い、ほかのエージェントと協働します。既存の認証の仕組み（API キー、OAuth のトークン、mTLS の証明書）はアクセス制御を確立しますが、説明責任は確立しません。

次の問いに答える標準的な方法はありません：

誰がこのエージェントを展開し、その行動の責任を引き受けるのか？
エージェントは行動する前に何をすると宣言したのか？
その行動はポリシーによって認可されたのか？
実際に何が起きたかについて、改ざんを検出できる記録があるか？

DCP コアは、どのエージェントも持ち運べ、どの検証器も評価できる、最小限で持ち運べるアーティファクトの集合を定義することで、この欠落に対処します。

3. 範囲¶

範囲内（コア）¶

6 つのコアのアーティファクトとその必須のフィールド
アーティファクトの間の関係（結び付け、ハッシュ、チェーン）
検証のモデル（検証器が何を確認しなければならないか）
バンドルの形式（伝送のためにアーティファクトをどうまとめるか）
暗号の署名の要件（アルゴリズムは指定しない）
監査エントリーをハッシュチェーンでつなぐ要件（ハッシュ関数は指定しない）

範囲外（プロファイルとサービス）¶

特定の暗号アルゴリズム → Crypto プロファイル
エージェント間の発見と通信 → A2A プロファイル
リスクティアの割り当て、管轄区域、失効、ガバナンス → Governance プロファイル
検証サーバー、ブロックチェーンへのアンカリング、透明性ログ → インフラのサービス
ポリシーエンジンの実装
鍵の管理のインフラの展開
通信路上の形式を超えるネットワークの伝送の要件

4. コアのアーティファクト¶

DCP コアは 6 つのアーティファクトを定義します。有効な Citizenship Bundle は 6 つすべてを含みます（ただし行動の証拠は 1 つ以上のエントリーを含むことがあります）。

4.1 責任を負うプリンシパルへの結び付け¶

すべてのエージェントは、責任を負うプリンシパル、つまりエージェントの行動について説明責任を引き受ける人、組織、または法人に結び付けられていなければなりません（MUST）。

結び付けの記録は次を含みます：

プリンシパルの一意の識別子
実体の種類（自然人、法人）
プリンシパルが活動する管轄区域
署名の検証のための暗号の鍵の材料
失効の約束（署名なしの緊急の失効を可能にする）
プロトコルのバージョンとセッションの結び付け

この結び付けは説明責任の連鎖を確立します。エージェントが不正な振る舞いをすれば、責任を負うプリンシパルを特定できます。

規範的な定義は DCP-01 を、スキーマは schemas/v1/responsible_principal_record.schema.json を参照してください。

4.2 エージェントのパスポート¶

各エージェントは、そのアイデンティティを確立し、責任を負うプリンシパルに結び付けるパスポートを持ちます。パスポートは次を含みます：

エージェントの一意の識別子
人が読める名前
宣言された能力
責任を負うプリンシパルの結び付けの記録の暗号ハッシュ（owner_rpr_hash）
エージェント自身の鍵の材料
状態（active、suspended、revoked）
プロトコルのバージョンとセッションの結び付け

パスポートは責任を負うプリンシパルが署名します。検証器は、プリンシパルの署名とハッシュのつながりを確認することで、エージェントが認可されていることを確かめられます。

規範的な定義は DCP-01 を、スキーマは schemas/v1/agent_passport.schema.json を参照してください。

4.3 意図の宣言¶

どの行動を行う前にも、エージェントはその意図を宣言しなければなりません（MUST）。意図は次の構造化された記述です：

エージェントがどの行動を取るつもりか
行動の対象は何か
どのデータの分類が関わるか
評価したリスクスコア

意図には 2 つの目的があります。ポリシーによる制御を可能にすること（4.4 節）と、監査証跡の中の実際の振る舞いと比べられる事前の約束の記録を作ることです。

規範的な定義は DCP-02 を、スキーマは schemas/v1/intent.schema.json を参照してください。

4.4 ポリシーの結果¶

各意図は、ポリシーエンジンからポリシーの結果を受け取ります。ポリシーエンジンは DCP の外にあり、プロトコルは結果の形式だけを定義します：

判断： approve、escalate、または block
意図のハッシュ： 評価した意図への暗号の結び付け
条件： 承認に付く省略可能な制約（レートの上限、人の確認など）

DCP コアは、バンドルの中のすべての意図にポリシーの結果があることを求めます。特定のポリシーエンジンや判断のアルゴリズムは求めません。

規範的な定義は DCP-02 を、スキーマは schemas/v1/policy_decision.schema.json を参照してください。

4.5 行動の証拠¶

すべての行動は、ハッシュチェーンでつながり改ざんを検出できるログを形づくる、1 つ以上の監査エントリーを生みます。各エントリーは次を含みます：

イベントの一意の識別子
イベントの種類
エージェントと意図への参照
意図のハッシュ（証拠を宣言に結び付ける）
直前の監査エントリーのハッシュ（prev_hash）。不変のチェーンを形づくる
タイムスタンプ

チェーンの最初のエントリーは、prev_hash として番兵の値 "GENESIS" を使います。以降のエントリーは SHA-256(canonical(previous_entry)) で前のものにつながります。

省略可能ですが、すべてのエントリーの上に Merkle ルートを計算でき、監査証跡全体を要約する 1 つのハッシュになります。

規範的な定義は DCP-03 を、スキーマは schemas/v1/audit_entry.schema.json を参照してください。

4.6 バンドルのマニフェスト¶

Citizenship Bundle は、すべてのアーティファクトをまとめる持ち運べるパッケージです。バンドルはちょうど次を含みます：

責任を負うプリンシパルの結び付けの記録 1 つ
エージェントのパスポート 1 つ
意図の宣言 1 つ
ポリシーの結果 1 つ
1 つ以上の行動の証拠のエントリー（監査証跡）

Signed Bundle は、Citizenship Bundle を、暗号の署名、bundle_hash（正規のバンドルのハッシュ）、そして省略可能な監査エントリーの上の merkle_root で包みます。

規範的な定義は BUNDLE を、スキーマは schemas/v1/citizenship_bundle.schema.json / schemas/v1/signed_bundle.schema.json を参照してください。

5. 検証のモデル¶

Signed Bundle を受け取った検証器は、次の確認を行います。すべての確認はローカルで、サーバーの呼び出しは必要ありません。

スキーマの検証 — バンドルとその内側のアーティファクトが、期待されるスキーマに適合している
署名の検証 — バンドルの署名が署名者の公開鍵に対して有効である
ハッシュの完全性 — bundle_hash が、正規のバンドルを再計算したハッシュと一致する
プリンシパルの有効性 — 責任を負うプリンシパルの記録が期限切れでない
エージェントの状態 — エージェントのパスポートの状態が active である
意図への結び付け — 各監査エントリーの intent_hash が、宣言された意図のハッシュと一致する
監査チェーンの完全性 — prev_hash のチェーンが GENESIS からすべてのエントリーまで有効である
Merkle ルート（存在する場合）— 宣言された Merkle ルートが再計算したルートと一致する

追加の省略可能な確認（コアではなくプロファイルで定義）：

失効のリストの照会（Governance プロファイル）
管轄区域の証明の検証（Governance プロファイル）
透明性ログへの包含の証明（Governance プロファイル）
ブロックチェーンのアンカーの検証（Governance プロファイル）
複合署名 / PQ の検証（Crypto プロファイル）

完全な規範的なチェックリストは VERIFICATION を参照してください。

6. セキュリティの注記¶

6.1 アルゴリズムからの独立¶

DCP コアは暗号の署名とハッシュ関数を求めますが、特定のアルゴリズムは義務づけません。この分離により、次が可能になります：

実装がクラシカルなアルゴリズムから始め、後でポスト量子を採用する
検証器が独自のアルゴリズムのポリシーを適用する
プロトコルが、コアの仕様を壊さずにアルゴリズムの移行を乗り越える

Crypto プロファイルは、DCP v2.0 で使う特定のアルゴリズム、複合署名の結び付け、暗号の俊敏性の仕組みを定義します。

6.2 信頼のモデル¶

DCP は中央の権威を前提としません。検証はローカルで P2P です。検証器に必要なのは Signed Bundle と（省略可能な）失効の記録の集合だけです。責任を負うプリンシパルへの信頼は、中央のレジストリではなく、結び付けの記録とその署名の連鎖によって確立されます。

6.3 プライバシー¶

コアはブラインドのモードをサポートします。プリンシパルの結び付けの中の個人データのフィールドが、ソルト付きの約束のハッシュ（pii_hash、DCP-AI v2.0 §12.1 を参照）に置き換えられます。個人データでないフィールド（鍵、管轄区域、責任）は検証のために保たれます。完全な記録は、求めに応じて権限のある当事者に開示できます。

6.4 リプレイの防止¶

DCP v2.0 では、session_nonce のフィールドがバンドルのすべてのアーティファクトを 1 つのセッションに結び付けます。検証器は、すべてのアーティファクトが同じ nonce を共有することを確認しなければなりません。これはセッションのつなぎ替えの攻撃を防ぎます。セッションの結び付けは v2.0 では規範的に必須ですが、v1.0 にはありませんでした。

7. 拡張性¶

DCP コアは、プロファイルによって拡張されるように設計されています。プロファイルは：

コアの要件と矛盾してはならない（MUST NOT）
追加のアーティファクト、フィールド、検証の手順を定義してもよい（MAY）
アルゴリズムの選択、伝送の結び付け、ガバナンスのポリシーを指定してもよい（MAY）
コアとは独立にバージョン付けされる

適合したコアの実装は、プロファイルがなくても有効です。プロファイルは要件ではなく機能を加えます。

現在定義されているプロファイルは次のとおりです：

プロファイル	範囲	文書
Crypto	アルゴリズム、複合署名、暗号の俊敏性	spec/profiles/crypto/
A2A	エージェントの発見、ハンドシェイク、セッションの管理	spec/profiles/a2a/
Governance	リスクティア、管轄区域、失効、回復	spec/profiles/governance/

参照¶

DCP-01 — アイデンティティとプリンシパルへの結び付け
DCP-02 — 意図の宣言とポリシーによる制御
DCP-03 — 監査チェーンと透明性
DCP-04 — エージェント間の通信
BUNDLE — Citizenship Bundle の形式
VERIFICATION — 検証のチェックリスト
DCP-AI v2.0 — ポスト量子の規範的な仕様
ROADMAP — プロジェクトの発展のロードマップ

実装に関する注記（参考）¶

2026 年 10 月 25 日に追加。規範的ではありません。 これらの注記は要件を加えず、上の内容を何も変えません。main のリファレンスのコードがこの文書とどう関係するかを説明するものです。食い違う場合は、上の規範的な本文がそのまま有効です。

フィールドの名前。 §4 の記述の一部は概念的なもので、スキーマとフィールド単位では一致しません。どちらの RPR のスキーマにも失効の約束のフィールドはありません。V2 のパスポートには省略可能な emergency_revocation_token があります。どのパスポートのスキーマにも名前や owner_rpr_hash はなく、パスポートは principal_binding_reference でプリンシパルを指します。リスクスコアは意図ではなくポリシー判断（risk_score）にあり、ポリシー判断は intent_id で意図を参照し、条件を required_confirmation に挙げます。監査エントリーはイベントの種類ではなく audit_id と outcome を持ちます。
V1 と V2。 §4.6 のバンドルと §5 の確認は V1 のものです。バンドルに対する 1 つの Ed25519 の署名と、少なくとも 1 つの監査エントリーです。V2 のバンドルは、各アーティファクトを約束する署名付きのマニフェスト、4 つの主なアーティファクトのための SignedPayload のエンベロープ、セッションの nonce、複合署名を持ち、監査証跡は空でもかまいません（VERIFICATION.md、V2 のチェックリスト）。
誰がパスポートに署名するか。 V2 では、エージェントがパスポートの keys で自分のパスポートに署名します。それは、RPR の binding_keys で作られたマニフェストに対するプリンシパルの署名によって、プリンシパルに結び付けられます（VERIFICATION.md V2-6）。
監査の証拠（§4.5、§6）。 検証済みの監査証跡は、記録されたエントリーが損なわれておらず、バンドルが列挙する鍵で約束されたことを示します。行動が本当に起きたことは示さず、チェーンは、それらの鍵を持ち新しいものに署名する者に対しては不変ではありません。検証もアドミッションも、それだけでは行動を認可しません。
信頼（§6.2）。 検証を通るバンドルは、その署名が列挙する鍵と一致することを証明しますが、プリンシパルが誰かは証明しません。誰でも RPR を作れるからです。プリンシパルへの信頼は、検証器自身の信頼セットから来ます。 docs/ADMISSION.md とアドミッションのプロファイルを参照してください。
プロファイル（§7）。 「プロファイルがなくても有効」とは、コアのアーティファクトの相互運用についてのことです。実装をコアの要件から免除するものではなく、展開は引き続き自らの検証器のポリシーと、使う場合はアドミッションのプロファイルを適用します。