BLUEPRINT

3 バージョン進化ロードマップ

第3章：バージョン進化ロードマップ

本章では CAP プロトコルのバージョン進化ロードマップを定義し、v1 バージョンの機能範囲と除外項目を明確にし、バージョン番号の命名規則と互換性ポリシーを確立し、ドラフトから正式バージョンまでのリリースフローを記述する。バージョンロードマップはプロトコルの反復開発とコミュニティ協力に明確なパスガイダンスを提供する。

3.1 v1 バージョンの機能範囲

CAP プロトコル v1 バージョンは、完全な端末制御権限管理の基盤フレームワークの確立に焦点を当て、以下の6種類のコア能力を含む：

  1. オフライン認可（Authorization_Descriptor）：v1 バージョンの中核メカニズム。Authorization_Descriptor の完全なライフサイクル管理を実装し、発行、ローカル保存、検証、失効、更新を含む。端末はオフライン状態でローカルに保存された Authorization_Descriptor を通じて独立して認可検証を完了でき、ネットワークのない環境での Fay の基本的な可用性を保証する。v1 バージョンでは完全な信頼チェーンモデルとローカル失効リストメカニズムを実装する。

  2. オンラインチケット（Trusted_Ticket）：v1 バージョンの補完メカニズム。ネットワーク接続環境下でのリアルタイム認可発行と失効状態照会機能を実装し、Trusted_Ticket からローカル Authorization_Descriptor フォーマットへの変換、およびオンラインからオフラインへのスムーズなデグレードポリシーをサポートする。v1 バージョンではオンラインチケットとオフライン認可の協調動作を保証する。

  3. セッション管理（Session lifecycle）：制御セッションの完全なライフサイクル管理を実装し、作成、アクティブ、終了の3つのフェーズをカバーする。v1 バージョンでは Session と Terminal_Resource の一対一バインド関係をサポートし、能動的解放、タイムアウト終了、失効終了の3種類のセッション終了方式を実装する。

  4. 制御権ハンドオーバーポリシー（Handover_Policy）：複数の制御者間の制御権移転機能を実装し、Fay 間および Fay と人間ユーザー間のハンドオーバーシナリオをカバーする。v1 バージョンでは3種類のポリシータイプ（優先度ルールスクリプト、AI モデルリアルタイム判定、人間ユーザー決定）をサポートし、ハンドオーバープロセスの原子性を保証し、タイムアウトロールバックメカニズムを実装する。

  5. 生存検知（Liveness_Detection）：長時間接続とアプリケーション層ハートビートの組み合わせに基づくセッション生存検知メカニズムを実装する。v1 バージョンでは二重判定ロジック（長時間接続の切断とハートビートタイムアウトの同時満足）、設定可能なハートビート間隔とタイムアウト閾値、および失効セッションの自動終了とリソース回収をサポートする。

  6. リソースアクセスモード（Resource_Access_Mode）：操作タイプに基づくリソースアクセスの階層管理を実装し、read、write、execute、configure の4種類のアクセスモードをサポートする。v1 バージョンでは完全な読み書きロックモデルを実装し、read モードの複数者並行アクセスと write、execute、configure モードの排他制御をサポートする。

以上の6種類のコア能力が v1 バージョンの完全な機能セットを構成し、iFay 体系におけるインテリジェントエージェントが端末を安全に引き継ぐための基盤となる制御権限フレームワークを提供する。

3.2 v1 で明確に除外される機能

以下の機能は v1 バージョンに明確に含まれず、将来のバージョンの候補項目として標記される：

除外機能説明候補バージョン
クロス端末セッション移行アクティブ Session を1つの端末から別の端末に移行し、セッション状態の連続性を維持するv2+
マルチ端末協調認可複数の端末間での認可状態の同期と協調検証メカニズムv2+
認可委任チェーン（Delegation Chain）Fay が自身の取得した認可の一部を他の Fay に委任するカスケード認可メカニズムv2+
きめ細かいリソースアクセス制御（ABAC）属性ベースのアクセス制御ポリシーで、より複雑なリソースアクセス条件の表現をサポートするv2+
監査ログ標準化フォーマット統一された監査ログ（Audit_Logger）出力フォーマットとクエリインターフェース仕様v2+
プロトコルメッセージ暗号化転送仕様CAP プロトコルメッセージのネットワーク転送層における暗号化方式と鍵ネゴシエーションフローの標準化定義v2+
オフライン認可の分散失効コンセンサス複数の端末間でオフライン環境下において失効状態の合意に達するコンセンサスメカニズムv3+
動的権限昇格（Session 内）アクティブ Session のライフサイクル内で新しい Session を作成することなくアクセス権限を動的に昇格させるv3+

v1 バージョンは「まず基盤を確立し、その後能力を拡張する」原則に従い、6種類のコア能力の完全性と安定性を優先的に確保し、高度な機能は後続バージョンの反復に委ねる。

3.3 バージョン番号命名規則と互換性ポリシー

バージョン番号命名規則

CAP プロトコルはセマンティックバージョニング（Semantic Versioning）フォーマットを採用する：MAJOR.MINOR.PATCH

  • MAJOR（メジャーバージョン番号）：プロトコルに後方互換性のない重大な変更が発生した場合にインクリメントする。例えばコアメッセージフォーマットの構造的な調整、認可検証フローの根本的な変更など。メジャーバージョン番号の変更は既存の実装に適応修正が必要であることを意味する
  • MINOR（マイナーバージョン番号）：プロトコルに後方互換性のある機能や能力が追加された場合にインクリメントする。例えば新しいリソースアクセスモードの追加、Handover_Policy のポリシータイプの拡張など。マイナーバージョン番号の変更は既存の実装の正常な動作に影響しない
  • PATCH（パッチ番号）：プロトコルに後方互換性のあるエラー修正やドキュメントの明確化が行われた場合にインクリメントする。例えば仕様ドキュメントの曖昧な記述の修正、境界ケースの処理説明の補足など

ドラフトバージョンは draft 識別子を使用し、バージョン番号は付与しない。ドラフトバージョンはいかなる互換性保証も約束せず、いつでも破壊的変更を行うことができる。

正式リリースのバージョン番号例：1.0.0、1.1.0、1.1.1、2.0.0

互換性ポリシー

CAP プロトコルの互換性ポリシーは以下の原則に従う：

  • 同一メジャーバージョン内での後方互換性：同一 MAJOR バージョン内で、新バージョンのプロトコル実装は旧バージョンのプロトコルメッセージを処理できなければならない。例えば、v1.2.0 を実装した端末は v1.0.0 フォーマットの Authorization_Descriptor を処理できなければならない
  • メジャーバージョン間の互換性は保証しない：異なる MAJOR バージョン間では後方互換性を保証しない。メジャーバージョン番号がインクリメントされた際、プロトコル仕様はすべての破壊的変更と移行ガイドを明確にリストする
  • Schema バージョンとプロトコルバージョンの整合：各プロトコルバージョンは1つの Schema バージョンに対応し、Schema ファイルはプロトコルバージョン番号で命名されたディレクトリに格納される（例：schema/2025-10-25/）。これによりバージョン対応関係が明確に追跡可能となる
  • 最低サポートバージョン宣言：プロトコル実装はサポートする最低プロトコルバージョンを宣言でき、そのバージョンより低いプロトコルメッセージは処理を拒否される

3.4 ドラフトから正式バージョンまでのリリースフロー

CAP プロトコルのドラフトから正式バージョンまでのリリースは以下のフローに従う：

フェーズ1：ドラフト（Draft）

  • プロトコル仕様と Schema 定義は draft/ ディレクトリに格納される（例：schema/draft/、specification/draft/）
  • ドラフトフェーズでは頻繁な破壊的変更が許可され、互換性は約束しない
  • ドラフト内容はコミュニティのフィードバックとレビューを受け、継続的に反復最適化される
  • ドラフトフェーズのドキュメントと Schema はいつでも更新でき、バージョン番号のインクリメント規則に従う必要はない

フェーズ2：リリース候補（Release Candidate）

  • ドラフト内容が安定に向かった段階で、リリース候補フェーズに入る
  • リリース候補バージョンは -rc.N サフィックスで識別される（例：1.0.0-rc.1）
  • リリース候補フェーズではエラー修正とドキュメントの明確化のみを受け付け、新機能は受け付けない
  • リリース候補バージョンは完全なテスト検証を通過する必要があり、Schema 検証、多言語ドキュメント構造等価性チェック、プロパティテストを含む

フェーズ3：正式リリース（Release）

  • リリース候補バージョンが十分な検証を経た後、-rc.N サフィックスを除去して正式バージョンとなる
  • 正式バージョンのプロトコル仕様と Schema 定義は draft/ ディレクトリからバージョン日付で命名されたディレクトリにコピーされる（例：schema/2025-10-25/）
  • 正式バージョンリリース後、当該バージョンのプロトコル仕様と Schema 定義は変更されない（immutable）。いかなる変更も新バージョンのリリースを通じて行う
  • 正式バージョンリリース時、全9言語のブループリントドキュメントとプロトコル仕様が同期的に完成し、構造等価性検証を通過しなければならない

フェーズ4：メンテナンス（Maintenance）

  • 正式バージョンリリース後、メンテナンスフェーズに入り、PATCH レベルのエラー修正のみを受け付ける
  • 新しい MAJOR または MINOR バージョンがリリースされた後、旧バージョンは限定メンテナンス期間に入り、最終的に非推奨（deprecated）としてマークされる
  • 非推奨バージョンのドキュメントと Schema 定義はリポジトリに歴史的参照用として保持されるが、いかなる更新も受け付けない