コンテンツにスキップ

DCP-AI ロードマップ

英語版の参考訳です（27/10/2026 更新）。内容が異なる場合は英語版が優先されます。識別子、コマンド、コードブロックは翻訳せずにそのまま掲載しています。

この文書は DCP-AI プロジェクトの予定された進化を説明します。ロードマップは重なり合うこともある段階（フェーズ）で構成されますが、依存関係の順序は守らなければなりません。現在公開されているものは公開済みバージョンにあります。

フェーズ 1 — 中核のセマンティクスを安定させる

状態： 完了

すべての DCP 実装がサポートしなければならない、相互運用のための最小限のプロトコル面（アーティファクト、それらの関係、検証モデル）を定義し、文書化します。

  • ✅ spec/core/dcp-core.md を中核の編集上の仕様として公開
  • ✅ 中核のアーティファクトとプロファイル固有のアーティファクトを区別
  • ✅ Responsible Principal Record（RPR）を正式な用語として確立
  • ✅ 暗号アルゴリズムの選択から独立して検証モデルを文書化
  • ✅ 中核の仕様と DCP-01 〜 DCP-09、および DCP-AI v2.0 の間に相互参照を設置

成果物

  • spec/core/dcp-core.md — 中核の編集上の仕様
  • spec/core/README.md — 中核の索引と根拠
  • DCP Core / プロファイル / サービスというアーキテクチャを示す README.md

フェーズ 2 — プロファイルを分離する

状態： README については完了。プロファイルの規範的な文書は作業中です。

アルゴリズム、トランスポート、ガバナンスに固有の詳細を、中核を拡張しつつ基本的な相互運用には必須でないプロファイル文書に切り出します。

  • 暗号プロファイル — アルゴリズムのレジストリ、ハイブリッド/PQ 署名、複合バインディング、暗号アジリティ、検証器のポリシー
  • A2A プロファイル — エージェントの発見、ハンドシェイクのプロトコル、セッション管理、トランスポートへのバインディング
  • ガバナンスプロファイル — リスクティア、管轄の証明、失効のポリシー、鍵の回復、ガバナンスのセレモニー

成果物

  • spec/profiles/crypto/README.md
  • spec/profiles/a2a/README.md
  • spec/profiles/governance/README.md
  • プロファイル固有の規範的な文書（今後。最初の README 以降）

原則

  • プロファイルは中核と矛盾してはならない（MUST NOT）
  • プロファイルはアーティファクト、フィールド、検証手順を追加で定義してよい（MAY）
  • 中核に適合した実装は、プロファイルがなくても有効である
  • プロファイルは中核とは独立にバージョン管理される

フェーズ 3 — 標準化での位置づけ

状態： 延期

標準化団体への正式な提出（IETF の Internet-Draft、W3C のワーキンググループでの採択、DIF への寄与）は、アーリーアダプターから実際の採用に基づくフィードバックが得られるまで延期します。理由は、標準化団体は本番での使用実績がある設計を好むこと、そして一般的なドラフトにかかる約 12 か月は、実際の統合が v2.0.x を使い込む前よりも後のほうが有効に使えることです。

再開する場合の候補となる場は次のとおりです。

  • IETF — ワイヤーフォーマット、正規化、検証ポリシーの部分
  • W3C — Verifiable Credentials との統合層
  • DIF（Decentralized Identity Foundation） — エージェントのアイデンティティモデル

それまでの間も、プロジェクトの仕様は Zenodo を通じて引用できます（論文の DOI 10.5281/zenodo.19040913、ソフトウェアの DOI 10.5281/zenodo.19656026）。

フェーズ 4 — スキーマと実装を揃える

状態： v2.0.x の公開により概ね完了。

  • ✅ RPR の名称に基づくスキーマを 5 つの SDK（TS、Python、Go、Rust、WASM）で検証
  • ✅ SDK 間の適合性テストを CI のすべての push で実行（tests/interop/v2/）
  • ✅ schemas/ に v2 の JSON スキーマ 39 個と v1 のスキーマ 9 個を公開
  • 🔄 中核のみの適合性と完全な適合性の分離（今後の改良。現在のスイートは単一のマトリクスとして実行）
  • 🔄 schemas/profiles/ のプロファイル固有の JSON スキーマ（今後。現在のプロファイルは説明的な README）

原則

  • RPR の用語がすべてのアーティファクトでの正式な名称である
  • 中核の適合性テストは、完全な適合性の厳密な部分集合である

フェーズ 5 — 採用と運用

状態： 進行中

スタックを公開した今、次のフェーズは採用です。

  • アーリーアダプタープログラムに沿ってアーリーアダプターを集める
  • 実際の統合からフィードバックを集め、以降のマイナーリリースに活かす
  • コミュニティの需要が見合う場合には、4 つのサービス（verification、anchor、transparency-log、revocation）の管理されたリファレンスデプロイを運用する
  • 創設時のメンテナー以外にもメンテナーを増やす（GOVERNANCE.md を参照）
  • 事例と統合パターンを公開する

v2.0 の公開以降に提供したもの

2026-04-22〜23 に公開した 7 つのマイナーリリース（v2.1.0 〜 v2.7.0）で、最初の外部比較が明らかにした SDK 間の動作の差を解消しました。これらのリリースの前は、DCP-04〜09 の動作は TypeScript SDK にしかなく、その後はすべての主要 SDK が同じプロトコル面を扱えます。続いて v2.8.0 と v2.8.1（2026-04-26）で 4 つの SDK の正規化をバイト単位で一致させ、v2.9.0（2026-10-21）でリファレンス検証器が規範的な V2 バンドルを検証するようになり、v2.10.0（2026-10-22）ですべての SDK の検証器が、セキュリティティアを含む V2 の手順全体を適用するようになりました。

  • v2.1.0 — TS と Python のテレメトリーを揃えるための OpenTelemetry OTLP エクスポーター。
  • v2.2.0 — DCP-05 のライフサイクルと DCP-06 の継承を Python、Rust、Go に移植。
  • v2.3.0 — DCP-07 の紛争、DCP-08 の権利、DCP-09 の委任・認識しきい値・ミラーを Python、Rust、Go に移植（21 関数 × 3 SDK）。
  • v2.4.0 — Python、Rust、Go に本番向けの堅牢化のための基本機能（セッション nonce のヘルパー、セキュリティティアのエンジン、緊急失効、PQCheckpointManager による遅延 PQ チェックポイント）。
  • v2.5.0 — DCP-04 エージェント間通信：Python（cryptography を使用）と Go（標準ライブラリの crypto/aes）に完全な AES-256-GCM セッション層、Rust に発見とハンドシェイクの土台。
  • v2.6.0 — Blinded RPR、マルチパーティ承認、アルゴリズムのアドバイザリーのヘルパーを Python から Rust と Go に移植。
  • v2.7.0 — 正式な DcpErrorCode の 38 個の値と detect_wire_format ヘルパーを 4 つの主要 SDK で統一し、SDK 間のエラー処理を 1 つの安定した文字列で一致させる。
  • v2.8.0 — 正規化プロファイル dcp-jcs-v1（spec/CANONICALIZATION_PROFILE.md）で RFC 8785 が実装依存としている場合を固定し、1.0、1e2、undefined についての 4 SDK 間の相違を解消。境界ケースの共通相互運用ベクター 14 件。
  • v2.8.1 — マニフェストの canonicalization_profile フィールドを 4 つの SDK に組み込み。ビルダーは "dcp-jcs-v1" を出力し、検証器はフィールドがなければ dcp-jcs-v1 とみなし、未知の値は拒否する。
  • v2.9.0（2026-10-21）— リファレンス検証器、CLI、サーバーが @dcp-ai/sdk を通じて規範的な V2 バンドルを検証。Go と TypeScript の正規化を dcp-jcs-v1 に合わせて修正。依存関係に関する未解決のセキュリティアラートをすべて解消（Go と Rust 2.9.0、Python 2.8.2、@dcp-ai/sdk 2.1.2）。
  • v2.10.0（2026-10-22）— 4 つの SDK の検証器が VERIFICATION.md の V2-7/V2-8、セキュリティティア、監査証跡の結び付け、鍵の有効性を適用。@dcp-ai/sdk の検証を回避できる重大な問題を修正。Blinded RPR のコミットメントにソルトを追加。Python に ML-KEM-768、FIPS 205、V2 バンドルを追加。サービスにオペレーター認証、登録の制限、サービス拒否への制限を追加。

v2.10.0 以降

これらの変更は v2.10.0 タグ以降の main にあります。2026 年 10 月 26 日時点で、npm では SDK 2.2.0、WASM 2.1.0、更新済みのアダプターと CLI が公開されています。公開済み一覧を参照してください。他の環境の公開は別です。変更履歴の [Unreleased] セクションは開発履歴を保持しており、これらの npm 機能が利用できないという意味ではありません。

  • アドミッション — 信頼できるプリンシパルと strict-v1 プロファイル（docs/ADMISSION.md、spec/profiles/admission）。4 つの SDK、Express・FastAPI・OpenClaw の統合、リファレンス検証器、サーバー、CLI にあります。検証だけでは引き続き信頼は与えられず、アドミッションがアクションを認可することもありません。
  • 正規化の候補 dcp-jcs-v2 — TypeScript、Python、Go、Rust、WASM の、実験的でオプトインの取り込み、ルーター、バイト検証器、生成側。5 × 5 のクロスマトリクス付き（docs/proposals/canonicalization-candidate）。規範的ではなく有効化もされていません。プロファイルは引き続き dcp-jcs-v1 だけで、候補を次の段階に進めたり既定にしたりするには、別途の判断が必要です。

フェーズ 5 の対象外

  • リファレンスサービスの自社運営 SaaS（オペレーターが自分でホストします）
  • 認証や認定のプログラムの取得（時期尚早）

提案：v2.10 以降の方向性

状態： メンテナーの議論のための提案です。このセクションの内容は何も予定も約束もされていません。各項目は、それぞれの issue または pull request で受け入れられて初めてロードマップの一部になります。

位置づけ

DCP は、ツールへのアクセスのためのプロトコル（MCP）、エージェント間のプロトコル（A2A）、エージェントの支払いのプロトコル、IETF における AI エージェントのアイデンティティに関するドラフト（執筆時点の 2026 年 10 月では、知る限り個人提出）と競合しません。それらの上にある説明責任と証拠の層です。それらのプロトコルが答えないままにしている問い、つまり「このエージェントが行ったことに誰が責任を負うのか、そして第三者はオペレーターを信頼せずにどう確認できるのか」に答えます。

v2.10 の取り組みで分かったこと

  • 対象範囲が採用の規模より大きい：仕様 9、v2 スキーマ 39、SDK 5、統合 10、サービス 4。
  • 見つかった検証器の不具合の多くは、単一のアルゴリズムの欠陥ではなく、4 つの SDK の検証器間の食い違いでした。TypeScript での検証モードの回避、Go と Rust でポスト量子の位置に Ed25519 を受け入れていたこと、Go での null アーティファクトの見落とし、Rust でのタイムスタンプの文字列比較です。
  • 運用が 1 人に依存しています（2026 年 10 月時点）。npm の公開用の資格情報がセキュリティ修正のリリースを止め、セキュリティアドバイザリーの作成にはメンテナーのアカウントにない権限が必要です。

提案する優先順位

  1. 運用上のセキュリティ（数週間）。 長期の有効期間を持つトークンなしで公開する（PyPI がすでに行っているように、npm と crates.io でも trusted publishing を使う）。v2.10 の取り組みで見つかった各脆弱性を、4 つの SDK すべてが拒否しなければならない否定ベクターにする。差分ファジングでは、同一のバイト列、ポリシー、検証時刻を各検証器に与え、既知の結果を対照として確認し、食い違いを仕様に照らして調べる。食い違いは調査の手掛かりであり、必ずしも検証器の不具合ではない。テストツールも誤る可能性がある。外部監査。管理者権限を持つ 2 人目のメンテナー。
  2. 小さな中核と独立した適合検証器。 規範は引き続き仕様であり、いずれかの SDK の挙動が標準になるわけではない。Rust/WASM をバインディング付きの参照実装としつつ、独立した実装も同じ要件に従って証拠を検証し続けられる。セキュリティのカバレッジマップで中核、プロファイル、アダプターに関する主張を区別し、実装者向けガイドで外部検証を準備する。Core 3.0 への再編の可能性は別途検討する設計上の問題である。この提案は、既存のアーティファクトを実験的な位置付けに変更したり、SDK の検証機能を削除したり、互換性や既定値を変更したりするものではない。
  3. 委任のチェーン。 人、エージェント、サブエージェント、ツール、支払い：各段階は署名され、権限を狭めることしかできず、広げることはできない。チェーンは責任ある人までオフラインで検証できる。サブエージェントは、自分に委任した者のセキュリティティアを下げられない（意図はすでに自分のティアを下げられない）。これらは DCP-09 の委任の権限委任状を拡張する案である。中核への移動には、別途レビューした設計と互換性に関する判断が必要になる。
  4. 競合せず統合する。 既存の MCP 統合でツール呼び出しごとに署名済みの受領証を出す。A2A の Agent Card の中に DCP パスポートを入れる（google-a2a 統合はすでに両者を変換できる）。HTTP Message Signatures（RFC 9421）。WIMSE/SPIFFE、OAuth、DID からのアイデンティティを受け入れ、責任ある人に結び付ける。
  5. 規制上の証拠。 docs/NIST_CONFORMITY.md と同様の形式で、監査証跡を EU AI 法のログ記録、人による監督、記録保持の義務（第 12 条、第 14 条、第 26 条）に対応付ける。対応関係と適用日は、引用する前に現行の条文と照合しなければならない。

エージェントの立場からの注記

  • 日常的なアクションは安価なままでなければなりません。ツールを呼び出すたびにポスト量子署名と完全なバンドルのコストがかかるなら、誰も採用しないでしょう。1 つのセッションの受領証を Merkle ツリーにまとめ、セッションの終了時やセキュリティティアが上がったときにハイブリッド方式で署名できます。
  • エージェントにとっての主なリスクは鍵の盗難ではありません。正当な鍵を持ったままのプロンプトインジェクションです。それを抑えるのは、行動する前に署名した意図、独立したポリシー判断、短期間で最小権限の権限委任、そしてアクションが宣言した意図から外れたかどうかを示す証拠です。
  • 権限の範囲内で行動したことを証明できることは、エージェントと、その責任を負う人を守ります。

提案しないこと

  • 独立した実装者が少なくとも 2 人いない新しい仕様。
  • プロジェクトが運営する中央サービス（「フェーズ 5 の対象外」を参照）。
  • 2 〜 3 の統合が本番で稼働する前の IETF への提出（フェーズ 3 は採用のフィードバックを待つために延期しており、これはその基準を具体化するものです）。

未解決の問い

  • 「削除より追加」という指針の原則に照らして、Core 3.0 への縮小は受け入れられるか。DCP-05 〜 DCP-09 を実験的なプロファイルに移すことは互換性のない変更です。
  • 独立した実装と仕様に基づく適合性を維持しながら、どのコンポーネントが共通の Rust/WASM 参照実装から恩恵を受けられるか。
  • 委任のチェーンは既存のケイパビリティ形式（UCAN、Biscuit）を再利用すべきか、DCP 独自のままにすべきか。
  • 2 人目のメンテナーは誰か。管理者権限をどう安全に共有するか。

対象外（全般）

以下は引き続き明示的に延期します。

  • 後方互換の別名を伴わないスキーマのフィールド名の変更
  • 明確なメジャーバージョンの移行を経ない、レジストリで公開済みのパッケージへの互換性のない変更
  • プロジェクト自身が所有する中央集権的な実行基盤

指針となる原則

  1. 破壊的でない移行 — すべての変更は元に戻せるものでなければならず、既存のインポート、テスト、スクリプトを壊してはならない
  2. 編集を優先 — ドキュメントと概念の明確さをコードの変更より先に行う
  3. 削除より追加 — 既存のファイルの移動や削除より、新しいファイルと相互参照の作成を優先する
  4. 中核は最小限に — 中核はプロトコルの最小の有用な範囲を定義し、それ以外はすべてプロファイルかサービスとする
  5. 相互運用性を重視 — 中核は、フレームワーク固有の依存関係なしに、どの言語でも実装できなければならない