仕様

Faying Protocol/1.0 — §1 Overview

プロトコル本文ナビ：章目次 ｜ 次章 §2 アーキテクチャ

§1 Overview

本章では Faying Protocol が何であり、何を解決し、何を解決しないのかを述べる。すなわち、プロトコルの命名、技術スタック上での位置、8 項目の設計目標、OAuth／WebAuthn などの既存方式との役割分担、一文での定義、仕様の適用範囲と明示的な非目標、そしてバージョン管理と互換性規則である。本章を読み終えれば、後続の §2–§11 と付録で用いる用語や制約に拠り所ができる。

本文中の規則の後ろには、対応する EARS 細目条項の番号を Trace: として示す（出典は本仕様の要件ベースライン）。形式は R<requirement>.<criterion>.<clause> であり、要件の出所を遡って確認しやすくしている。

§1.1 プロトコルの命名

プロトコル仕様の名称は Faying Protocol、バージョン番号は Faying Protocol/1.0 と表記する。

このプロトコルに独立した略称はなく、略記が必要なときはフルネームを用いる。初期ドラフトでは "Faying Auth Protocol（FAP）" を用いていたが、現在は廃止済みである。新しい文書では FAP、FAP/1.0、Faying Auth Protocol、application/fap+json、POST /fap/v1/... といった旧表記は登場しない。外部資料で FAP に遭遇した場合は、Faying Protocol の旧称とみなせばよい。

§1.2 プロトコルの位置づけ

Faying Protocol は TLS の上に位置するアプリケーション層の「継続的認可レイヤー」プロトコルであり、「人類原型がその iFay に対し、どのような在場状態のもとで、どの範囲について、どのグレードで、どの期間に認可するか」という一群の意味論を担う。

  • TLS の下：チャネルの機密性と相手側の身元は TLS 1.3（mTLS の選択利用を含む）が担い、Faying Protocol が作り直すことはしない。
  • OAuth/OIDC の傍ら：OAuth はアプリケーションへの認可を、OIDC は身元アサーションを担うが、いずれも「一時的なトークン」モデルである。Faying Protocol は両者がいずれも解決しない問題を解決する——継続的な代理 + 在場バインディング + グレード切り替え + 責任帰属の一意性である。
  • WebAuthn の上：WebAuthn / FIDO2 は Bootstrapping 段階で人類原型に「ユーザー在場」のハードウェアレベルの証明を提供する。Faying Protocol はその資格情報の形態を、派生信頼の根（root）として再利用する。

Faying Protocol は TLS を置き換えるものでも、OAuth を再発明するものでもない。TLS の上、業務意味論の下に位置し、iFay のあらゆる対外行為を Mandate 検証ゲートに通すことを強制する。本プロトコルのゲートを迂回する対外呼び出しはすべて Rogue Action とみなされ、トランスポート層より上・業務層より下のミドルウェアで拒否されなければならない。

§1.3 設計目標

下表は Faying Protocol の 8 項目の設計目標 G1–G8（中核目標）と、§9 / §5 から派生する 2 項目の工学目標（セキュリティ特性 / プロトコル相互運用性）を示す。各目標は要件ベースラインのちょうど 1 つの Requirement に対応することで、本プロトコル本文と Requirements 文書との間の双方向リンクのアンカーを構成する。

目標意味ブループリント出典対応 Requirement
G1 責任帰属の一意性任意の時点で iFay の対外行為は、必ず一人の Human Prime（人類原型）に曖昧さなく帰責できる第 13 章 倫理的最低線Requirement 1
G2 デフォルト拒否有効な Mandate がなければ対外行動できない。いずれかのフィールドが欠落すれば即拒否第 13 章 Rogue デフォルトRequirement 2
G3 可観測・可監査・可撤回状態遷移、Action の発起、更新／撤回の 3 種のイベントはすべて可観測・可監査・独立検証可能第 11、13 章Requirement 3
G4 対称的な撤回撤回経路の到達性 ≥ 確立経路の到達性。撤回は不可逆第 10、12 章Requirement 4
G5 継続的なキャリブレーション在場信号と Mandate グレードは各時点で再確認できる。期限切れの信頼をキャッシュしない第 11、12 章Requirement 5
G6 グレード化された認可単一の Mandate がすべての強度を代表することはできない。グレードは表現可能・切り替え可能・降格可能でなければならず、昇格には必ず HP の見証を伴うユーザー原案の要点 3Requirement 6
G7 デバイス横断の派生可能性同一の iFay が端末をまたいで作業するとき、信頼は派生できるが責任端は不変。scope / grade は厳密に収束するPhase 2/3 進化のための予約Requirement 7
G8 ポスト量子への進化可能性アルゴリズムスイートはネゴシエーション可能・ローリングアップグレード可能。PQC ネゴシエーションビットを予約工学上の汎用要件Requirement 8
—（派生）セキュリティ特性リプレイ／乗っ取り／フィッシング耐性、離脱状態の識別、AI-Era Adversarial Threats§9 セキュリティ考慮事項Requirement 9（13 の派生を含む）
—（派生）プロトコル相互運用性CBOR / JSON の等価性、Deterministic CBOR、実装横断の互換性マトリクス§5 プロトコルメッセージRequirement 10

目標 ↔ Requirement 一対一原則：本表はプロトコル本文と Requirements 文書との間の唯一の権威的マッピングである。後続の章が不変条件やメカニズムを説明する際に引用する EARS 細目条項番号 R<n>.<m>.<k> について、その根 Requirement 番号 <n> は必ず本表の「対応 Requirement」列に収まる。G6 / G4 / G5 / G7 から派生する Endorsed_Mandate（Requirement 11）、Disconnection 戦略（Requirement 12）、AI-Era 防護（Requirement 13）は G1–G8 を詳細化した要件として、それぞれ §4 / §8 / §9 でプロトコルレベルの落とし込みを与える。

§1.4 既存方式との中核的な差異（一文版）

既存方式解決していることFaying Protocol が解決せねばならぬ未解決事項
OAuth 2.0 / 2.1アプリケーションのリソースへのアクセス認可使い捨てトークン。グレードなし、在場なし、対称的な撤回なし
OIDC SSO身元アサーション（who）継続的な代理（acting on behalf of）がない。グレードがない
mTLSチャネル両端の相手側身元「誰がどのような在場状態のもとで誰に何を委任するか」を表現できない
JWT自己完結クレームの署名失効なし、グレード意味論なし、長寿命と「対称的な撤回」が矛盾する
FIDO2 / WebAuthn人類原型のハードウェアレベル在場証明ログイン瞬間のみをカバー。iFay の継続的代理をカバーしない
Macaroonscaveats 付きの派生可能トークン在場バインディングなし、人類原型の明示的な見証なし
SPIFFE / SPIREワークロード IDワークロード視点であり、人間の責任端がない

Faying Protocol は上記いずれの方式とも競合しない——TLS の上、業務意味論の下で「人類原型 ↔ iFay」という一群の専属的な意味論を補完する。すなわち、継続的な代理 + 在場バインディング + グレード切り替え + 責任帰属の一意性 + 対称的な撤回である。

§1.5 一文での定義

Faying Protocol = 「Mandate（token の代替）+ Presence Signal（在場信号）+ Attestation Chain（証言チェーン）+ Revocation Registry（撤回登録）」の四要素が TLS の上で協調して表現する、人類原型と iFay によって双方向に発起され、人類原型の明示的な認可によって発効し、継続的にキャリブレーションされ、対称的に撤回される認可契約。

§1.5.1 双方向 Faying は HP の明示的認可によって発効する（中核命題）

Faying 関係（確立または調整）の発起は双方向である。

  • HP-initiated：Human Prime（人類原型）は能動的に Faying を発起でき、BOOTSTRAP チャネルを通る（詳細は §2.4 Phase A、§5.3.1）。
  • IF-initiated：iFay は能動的に Human Prime へ Faying を求めることができ（すなわち FAYING_REQUEST）、§2.4 Phase A0 → BOOTSTRAP の 2 ステップ経路を通る（詳細は §5.3.6）。

ただし、いずれの側が発起しようとも、Faying 状態の変化が最終的に発効する条件は、Human Prime が明確で、欺かれておらず、検証可能な認可確認を与えることである（既定の形態は WebAuthn のユーザー在場アサーション、または同等のハードウェアレベルの証明）。

ここから直ちに、本プロトコルの 3 つの越えてはならないハード制約が導かれる。

  1. iFay 自身は Faying 発効の条件を構成しない：iFay が能動的に発起した FAYING_REQUEST が BootstrapTimeout（既定 60s、詳細は付録 B）以内に HP の明確な認可を得られなければ、期限切れまたは拒否となり、いかなる Faying 状態の変化も生じない。Mandate_Service は E_FAYING_REQUEST_NOT_CONFIRMED（エラーコード 1014）を返さなければならず、当該イベントを Attestation Chain へ書き込んで「どちらが発起し、いつ確認され、発効したか否か」という不可逆の証拠を保全しなければならない。
    • Trace：R1.3.2（IF-initiated 経路は HP の明確な認可確認後にのみ発効する）、R1.3.3（BootstrapTimeout 以内に認可されなければ拒否し、状態変化を生じない）、R1.3.4（発効の有無にかかわらず AC へ書き込む）。
  2. 代替の見証経路は存在しない：プロトコル層は、iFay、Mandate_Service、Supervisory_Agent が Human Prime に代わって Faying の認可確認を完了する正当な経路を一切提供しない。human_witness を欠く、あるいは human_witness の検証に失敗したいかなる BOOTSTRAP も、E_HUMAN_WITNESS_REQUIRED（エラーコード 1010）で拒否しなければならない。
    • Trace：R1.3.5（IF / MS / SA が HP に代わって Faying の認可確認を完了する正当な経路を提供しない）。
  3. 撤回を iFay が一方的に迂回することはできない：iFay は「Faying の切断を求める」メッセージ（Disclosure_Report とみなす）を発起できるが、自身の Mandate を撤回する権限は持たない。いかなる撤回も、最終的には Human Prime またはコンプライアンス上の権威機関が発起し、HP ビューチャネルを通じて可視でなければならない（詳細は §4 / §10）。
    • Trace：R4.1.4（IF は自身の Mandate を撤回する権限を持たない）、R4.1.5（切断要求は Disclosure_Report として AC へ書き込み、HP ビューへプッシュする）。

本款は §2.4 Phase A0、§5.3.6 FAYING_REQUEST、§5.4 エラーコード 1010 / 1014 を Overview レベルで統一するアンカーであり、後続の章における「HP の見証なくして Faying なし」に関するすべての論証の起点でもある。

§1.6 プロトコル成果物の範囲と非目標

§1.6.1 範囲内（Normative、本プロトコル本文が担う）

本プロトコル本文（すなわちこの一連のファイル）は、下記の内容を規範化し、かつそれのみを規範化する。

  • プロトコルデータオブジェクト：Mandate / Presence_Signal / Attestation / SignatureBundle / Faying Protocol Envelope / Endorsed_Mandate / Disclosure_Report などの CBOR 主フォーマットと JSON フォールバックフォーマット（CDDL を権威とする、詳細は §4 / §5）。
    • Trace：R10.1.1、R10.1.2、R10.2.1–R10.2.4。
  • プロトコルコンポーネントのインターフェース：Mandate_Service / Presence_Channel / Attestation_Chain / Revocation_Registry / Liveness_Channel / Behavior_Baseline_Service の責務境界と不変条件（詳細は §3）。
  • プロトコルメッセージ：BOOTSTRAP / PRESENCE / GRADE_SWITCH / DELEGATE / REVOKE / FAYING_REQUEST / DISCLOSURE の 7 種類のメッセージのフィールド定義、エラーコード、プロトコルレベルのハード制約（詳細は §5）。
  • 暗号規則：アルゴリズムスイートのネゴシエーション、鍵派生の階層、署名入力の正規化（Endorsed_Mandate の署名入力アンカーを含む、詳細は §6）。
    • Trace：R8.1.1–R8.1.4、R8.2.1–R8.2.4。
  • 認可グレードの意味論：G0–G4 の 5 段階グレードの厳密な定義、トリガー条件行列、降格の単調性原則、Endorsement Grades 子グレード（詳細は §7）。
    • Trace：R5.1.1、R6.1.1、R6.1.2。
  • ライフサイクルと状態機械：Unpaired / Pairing / Active / Degraded / Disconnected / Suspended / Revoked の 7 状態の遷移条件と再接続照合トランザクション（詳細は §8）。
  • セキュリティ考慮事項：STRIDE 脅威モデル、リプレイ／乗っ取り／フィッシング耐性、離脱状態の識別、デバイス横断の派生信頼の伝播、AI-Era Adversarial Threats T1–T7（詳細は §9）。
  • エラー処理：14 項目のエラーコード（1010 E_HUMAN_WITNESS_REQUIRED、1013 E_ENDORSEMENT_INVALID、1014 E_FAYING_REQUEST_NOT_CONFIRMED を含む）のプロトコル応答、回復経路、可観測性の制約、Default-Deny への収束（詳細は §10）。
    • Trace：R2.1.1–R2.1.4（デフォルト拒否）、R3.3.1（HP ビューチャネルへの必達）。
  • 付録：用語アライメント早見表（付録 A）、デフォルトパラメータ予算（付録 B）。

§1.6.2 範囲外（Non-normative、本プロトコルは担わない）

下記の内容は本プロトコル本文の規範範囲には属さず、参考実装・工学的ガイダンスにとどまり、本プロトコル本文の互換性テストとは無関係である。

  • 業務意味論：iFay の具体的な業務行為、端末ドライバ、アプリケーション統合方式。
  • UI / UX 設計：Human Prime ビューチャネルの具体的な表示形態、確認ダイアログの設計、モバイル／デスクトップのインタラクション。
  • 運用とデプロイ：Mandate_Service / Revocation_Registry の高可用性デプロイモデル、スケーリング戦略、リージョン間同期。
  • トランスポート層の詳細：TLS 1.3 自体のハンドシェイク詳細（RFC 8446 が規定）、HTTP/2 / gRPC / QUIC の具体的なパラメータチューニング。
  • PD（Presence Device）の実装：WebAuthn authenticator / TPM / Platform Keystore 自体のハードウェア実装（W3C / ISO / TCG がそれぞれ規定）。
  • 法務とコンプライアンスの詳細：規制・コンプライアンス側がプロトコル外で法的意味の「権威機関」役割をどう実施するか（プロトコル層は RevokeReason 列挙におけるその位置づけと署名チェーンの要件のみを規定し、その法的制度は規定しない）。
  • 参考実装コード：本プロトコルのあらゆる reference 実装（schemas/types.ts の TypeScript ビュー、pbt/ プロパティテストスイートなど）は明確に "Reference Implementation, Not Normative" と表示され、プロトコル本体を構成しない。
  • 未解決課題：§11 Open Questions のうち status: open のすべての項目。

§1.6.3 提供形態

本仕様の本文は章ごとに分割され、§1–§11 の計 11 ファイルに付録 A/B/C の 3 部を加えたもので、いずれも docs/ja/specification/2025-10-25/ 配下に置く。章番号入りのファイル名は目次を参照のこと。このうち付録 A（用語アライメント早見表）、付録 B（デフォルトパラメータ予算）は規範レベルの参考であり、付録 C（変更履歴）はプロトコルがドラフトから確定稿に至る進化とバージョン番号方針を記録し、参加者がプロトコルの成り立ちと進化のしかたを理解できるようにしている。

英語仕様は docs/en/specification/2025-10-25/ にあり、単一ファイル構成——プロトコル本文（§1–§11 + 付録 A/B）はすべて Faying-Protocol-1.0.md という 1 ファイルにインライン化されており、英語側では付録 C（変更履歴）のような日本語側独立ファイルは保守しない。両側の「一対一対応」は章節アンカーのレベルでの対応である。すなわち、章節番号、Mermaid 図、CDDL / TypeScript コードブロック、エラーコード表、付録 A/B が逐一そろっており、ファイル単位の一対一対応ではない。日本語版と英語版で差異が生じた場合は簡体中国語版（zh-CN）を正とし、次回のレビューで英語側を同期して修正する。

§1.7 バージョン管理と互換性

本節は Faying Protocol のバージョン番号付けの権威的定義である。バージョン番号は単なる文書上の印ではなく、相互運用契約の一部である——ワイヤエンベロープ、schema、ネゴシエーションビットに現れ、2 つの独立した実装が対話できるか否かを直接左右する。したがって本節は Normative であり、実装者は本節の規則に従ってバージョン番号を解釈し、バージョンネゴシエーションを実行しなければならない。付録 C の変更履歴は歴史を記録するのみで、規則を重複して定義しない。

§1.7.1 3 本の直交するバージョン軸

Faying Protocol は互いに独立した 3 本の軸で 1 つの仕様のバージョンを記述し、3 者を 1 つの番号に混同してはならない。

軸答える問い形態担い手例
プロトコルバージョン（相互運用契約）2 つの実装が対話できるかMAJOR.MINOR散文 / ワイヤエンベロープの version フィールド / schema ファイル名Faying Protocol/1.0
文書ステータス（ライフサイクル）この仕様は確定したか列挙front matter の statusDraft / Final / Deprecated / Obsolete
編集版次（正誤訂正と明確化）同一プロトコルバージョン配下の何回目の文面改訂か公開日公開ディレクトリ名 / front matter の date2025-10-25

中核制約：「プロトコルバージョン」MAJOR.MINOR のみがワイヤフォーマットに入る（エンベロープの version フィールド、schema ファイル名）。文書ステータスと編集版次はワイヤフォーマットに入ってはならない——これらは文書ガバナンスの印であり、相互運用の判定には関与しない。実装は、相手側の文書ステータスや編集版次が異なるという理由で、そのメッセージ処理の挙動を変えては決してならない。

§1.7.2 プロトコルバージョン MAJOR.MINOR の意味論

プロトコルバージョン番号は Faying Protocol/MAJOR.MINOR と表記し、2 段階のみで PATCH 桁を設けない——ワイヤフォーマットと相互運用意味論は 2 段階の互換性しか区別しない。

  • MAJOR（破壊的変更）：旧版仕様に厳密に従って実装された相手側に、新しいメッセージを拒否または誤解させるような変更。例：§4.2 CDDL 権威 schema のフィールド意味論の変更、メッセージ型の削除、エラーコード意味論の再定義、状態機械の吸収状態の変更。
    • 規則：MAJOR を繰り上げ、MINOR をゼロに戻す（例：1.4 → 2.0）。
    • 互換性：異なる MAJOR の間では相互運用を保証しない。
  • MINOR（後方互換の追加）：新しい実装が旧メッセージを理解でき、旧実装が認識できないオプション項目を安全に無視できるような追加。例：オプションフィールドの追加、メッセージやエラーコードの新設、AI-Era 脅威カタログ項目の追加、付録パラメータの追加、Correctness Property の追加。
    • 規則：MINOR をインクリメントする（例：1.0 → 1.1）。
    • 互換性：同一 MAJOR 内では、高い MINOR が低い MINOR に対する後方互換性を維持しなければならない。

判定基準（実装者の自己チェック）：その変更は、旧版仕様に厳密に従って実装された相手側に、新しいメッセージを拒否または誤解させるか？

  • させる → MAJOR。
  • させないが、ワイヤフォーマット上で可視な内容を追加した → MINOR。
  • 文面のみを変え、ワイヤフォーマットの意味論をいっさい変えない（typo 修正、例の補足、曖昧さの明確化）→ プロトコルバージョンを変えず、§1.7.4 の編集版次で扱う。

現在のベースラインは Faying Protocol/1.0 である。

§1.7.3 バージョンネゴシエーションと互換性規則（Normative）

バージョンネゴシエーションは §6.1 アルゴリズムスイートのネゴシエーションと同じ流儀を再利用する（各自が宣言し、共通でサポートする最高値を取る）。実装は次に従わなければならない。

  1. 宣言：BOOTSTRAP 段階で、クライアントとサーバーは各自がサポートするプロトコルバージョンの集合を宣言する（例：supported: [1.0, 1.1]）。
  2. 同一 MAJOR では最高 MINOR を取る：双方の MAJOR が同一のとき、両者が共通でサポートする最高 MINOR を当該セッションの発効バージョンとして選択しなければならない。高い MINOR の実装は、低い MINOR の相手側にサービスできなければならない（MAJOR.0 まで後方互換）。
  3. MAJOR をまたぐ場合は拒否：双方に共通でサポートする MAJOR が存在しないときはネゴシエーションを行わず、E_PROTOCOL（エラーコード 1099）で当該 BOOTSTRAP を拒否しなければならない。「ベストエフォート」で降格して相互通信してはならない。
  4. ローリングアップグレードは既存 Mandate を壊さない：バージョンネゴシエーションによって新しい既定アルゴリズムスイートや新しい MINOR を導入する場合、既存の Mandate がその not_after 以前であれば依然として検証可能であることを保証しなければならない。バージョンアップグレードは、進行中の有効な Mandate を失効させてはならない。
    • Trace：R8.2.4（バージョンネゴシエーションによるローリングアップグレードが既存 Mandate の検証可能性を壊さない）。
  5. 未知の高 MINOR の扱い：同一 MAJOR でありながら、MINOR が自身より高いと宣言されたメッセージを受信したとき、実装は自身がサポートする最高 MINOR に従って解釈し、認識できないオプションフィールドは（拒否せず）無視しなければならない。これがまさに MINOR 後方互換の約束の実行時の落としどころである。

§1.7.4 編集版次と正誤訂正（Non-normative な変更）

Faying Protocol/1.0 が確定稿（Final）となった後にも、純粋な文面の正誤訂正——typo 修正、例の補足、曖昧さの明確化、内部リンクの修正——は避けられない。この種の変更は次のとおりである。

  • プロトコルバージョン番号を変えてはならない（さもなくば、相互運用契約が変わったと偽ることになる）。
  • 公開日を版次のアンカーとする。例：Faying Protocol/1.0 (2025-10-25) は 1.0 の最初の Final 版次であり、以降の正誤訂正は新しい公開ディレクトリ（例：2026-03-xx/）を生むが、プロトコルバージョンは依然 1.0 である。
  • 付録 C の変更履歴では Editorial カテゴリとして登録し、front matter では edition フィールドで版次の遷移を表示する。
  • ハード制約：編集版次は Non-normative な変更のみを許す。ワイヤフォーマットの意味論に手を入れる修正は、いかなるものでも MINOR または MAJOR を上げなければならず、編集上の正誤訂正に偽装して公開してはならない。

§1.7.5 バージョン番号の落としどころと標準実装者の注意事項

下表はバージョン番号が各所に落ちる正確な位置を示す。実装者はこれに基づき「どの差異が相互運用に影響し、どれが影響しないか」を判断する。

落としどころ何を書くか注意事項
ワイヤエンベロープの version フィールド（§5.2）"Faying Protocol/MAJOR.MINOR"MAJOR.MINOR のみを置く。版次日付や文書ステータスは置かない
schema ファイル名（fap-1.0.cddl など）MAJOR.MINOR に追従ファイル名は編集版次で改名しない——正誤訂正で fap-1.0.cddl を変えず、既存参照の安定性を保つ（初期の fap プレフィックスの保留も同じ理由、付録 C 参照）
content-type（§5.1）application/faying-protocol+cbor（または +json）content-type はプロトコルファミリーを識別する。ゲートウェイ層でバージョン別にルーティングしたい場合は version= パラメータをデプロイ上の便宜として付与できるが、当該パラメータはワイヤフォーマットの意味論には属さず、互換性判定に影響しない
front matter の status / date文書ステータス / 編集版次文書ガバナンスの印であり、ワイヤフォーマットに入らない。相手側はこれに基づいてメッセージ処理を変えてはならない
git tagfaying-protocol-v<MAJOR.MINOR>-<ステータス>確定稿は faying-protocol-v1.0-final、版次スナップショットは faying-protocol-v1.0-2026-03-xx。tag は必ず本文 + vectors/ + schemas/ を同時にカバーし、相互運用の三点セットを一括で凍結する

標準実装者の必読注意事項：

  1. 相互運用の判定はプロトコルバージョンのみを見る：「対話できるか」を決める唯一の根拠は MAJOR.MINOR である。相手側の文書ステータス（Draft/Final）、編集版次（公開日）はいずれも相互運用の挙動を変えない——相手側が Draft 表記である、あるいは版次が古いという理由で、その正当なメッセージを決して拒否してはならない。
  2. 同一 MAJOR では後方互換が必須：ある高い MINOR バージョンを実装するとき、MAJOR.0 から始まるすべての低い MINOR の相手側に正しくサービスできなければならない。
  3. 正誤訂正をアップグレードと取り違えない：公開ディレクトリの日付変化（編集版次）はプロトコルが変わったことを意味しない。MAJOR.MINOR の変化のみが相互運用への影響評価を要する。
  4. schema ファイル名の安定性：ファイル名に版次がエンコードされていることに依存しない。同一 MAJOR.MINOR の正誤訂正は同名の schema ファイルを再利用し、git tag / 公開ディレクトリで版次を区別する。
  5. Draft 期間は互換性の約束なし：status: Draft の期間は、MAJOR.MINOR が凍結されないまま調整される可能性がある。Final 以降に初めて、本節の MAJOR/MINOR 互換性の約束が完全に発効する。