CAMARAプロジェクトのリリース構造

はじめに

CAMARAプロジェクトの組織構成では，CAMARAプロジェクト内の組織と各組織の役割に関して解説しましたが，本記事ではCAMARAで策定するNW-API仕様のリリース構造とライフサイクルについて，執筆時点におけるプロセスの概観を解説します。

CAMARAのリリースプロセスは，Release Management WG¹が策定しており，メタリリース，リポジトリリリース，APIバージョンという3層のリリース構造で管理され，それぞれが独立した採番ルールを持っています²。

また，Sub-PjやSandboxに割り当てられるGitHubのリポジトリ（API仕様書等の成果物が配置される）には，Sandbox→Incubating→Graduatedといった成熟度に応じたライフサイクルが定められており³，上位ステージへの移行には厳格な要件が課されています。

CAMARAのリリース

CAMARAのリリースは以下の3種類（3層構造）で管理されており，大きな塊の順にポイントを記載すると下表のようになります。以降でそれぞれについて触れていきたいと思います。

メタリリース

メタリリースとは，CAMARAプロジェクトとしてAPI仕様を市場に提供するための仕組みです。メタリリースに含まれる各API仕様は，Commonalities WG⁴やICM WG⁵が策定するデザインガイドラインの特定バージョンに準拠した形でリリースされ，API間の一貫性が確保されます。

メタリリースは年2回（春・秋）行われ，Fall25のように年の下2桁を含む名称が付けられます。直近では，2025年秋にメタリリースされ，Fall25として60のNW-APIがリリースされています⁶。

このメタリリースの検討プロセスとしては，以下のようにM0〜M6の7つのマイルストーンが設定され，TSCがメタリリースのM0宣言，つまり検討開始宣言した後，半年弱（Fall25の場合は，5か月程度）の期間をかけてM6まで完了させます。（alpha版・release candidate版・public版といったAPIステータスの遷移については，「APIバージョン」の部分で触れます。）

• M0: TSCがメタリリース計画を承認し，検討を開始
• M1: Commonalities & ICMのalpha版リリース
• M2: Commonalities & ICMのrelease candidate版リリース
• M3: 各API仕様のrelease candidate版リリース（Commonalities & ICMのrelease candidate版に準拠）
• M4（Commonalities & ICM）: Commonalities & ICMのpublic版リリース
• M4（APIs）: 各API仕様のpublic版リリース（Commonalities & ICMのpublic版に準拠）
• M5: メタリリース
• M6: 振り返り

この検討プロセスで特徴的なのは，Commonalities & ICM WGで規定するNW-APIのデザインガイドライン策定と，Sub-PjやSandboxでのNW-API仕様策定が並行で進むという点です。

デザインガイドラインのリリース（M4/Commonalities & ICM）は，NW-API仕様のリリース（M4/APIs）よりも前に締め切りが設定されているものの，M3の準備が遅れていたりすると，NW-APIを検討するSub-PjやSandboxでは短期間でデザインガイドラインにあわせて，API仕様書のYAMLを修正する必要があります。

WebRTCの場合は，リーダが率先してこのタスクを実施くださっています。M4/APIsの前にデザインガイドラインに大きな修正が入るような場合は，Commonalities WGに参加するメンバが情報共有してくれるものの，他作業で手一杯の状況ではリーダへの負荷が大きくなりリリースが間に合わなくなる状況も想定されます。

リポジトリリリース

リポジトリリリースとは，リポジトリ全体に対して付与されるタグ付きリリースです。GitHubのリリース機能を用いて作成され，リリースタグ（rx.y）とリリースパッケージ（リポジトリのzipファイル）の組み合わせで構成されます。

• x: メタリリースサイクルの番号（1から開始し，新サイクルごとに+1）
• y: サイクル内でのリリース通番（新サイクルで1にリセット）

このリリースタグ（rx.y）は，個々のAPI仕様に付与されるAPIバージョン番号とは独立した番号体系で採番されます。1つのリポジトリリリースは，リポジトリ内のすべてのAPI仕様を内包し，それぞれが自身のAPIバージョンを持ちます。

リポジトリリリースには，そのリリース全体の性格を示す属性 target_release_type が設定されます。この属性は，リポジトリ内のすべてのAPI仕様が満たすべき成熟度（ステータス）の下限を決定します。

例えば，メタリリースのM4の時点では，リポジトリ内の全API仕様の成熟度をpublicにする必要があります。つまり，メタリリースに参加する場合，一部のAPI仕様だけを先行公開したり，未成熟なAPI仕様を除外してリポジトリリリースすることはできません。

リポジトリの成熟度(maturity level)

リポジトリには，リポジトリリリースとは独立して，Sandbox → Incubating → Graduatedという成熟度(maturity level)が定められています。

Sandbox→Incubatingへの昇格には，少なくとも1社のオペレーターによる実装実績が，Incubating→Graduatedへの昇格には，複数ステークホルダーによる本番環境での使用実績が必要になるなど，上位の成熟度への移行には実サービスでの実績が課せられます⁷。

この実績は，CAMARAプロジェクトと他標準化団体の関係で紹介したとおり実質的にはGSMAが認定する形になっており，普及展開を担うGSMA側の方針が色濃く反映されたライフサイクルといえます。

APIバージョン

前述のとおり，1つのリポジトリリリースには複数のAPI仕様が内包されます。

個々のAPI仕様に付与されるAPIバージョンは，NW-API仕様書（YAML）ごとにセマンティックバージョニング（vx.y.z）で管理されます。

APIのバージョン拡張識別子(version extension)

各APIバージョンには，リリース準備状況を示すAPIのバージョン拡張識別子(version extension)が設定されており，以下の順に遷移します。前述したalpha版・release candidate版・public版は，このステータスに対応しています。

draft → alpha → release candidate → public

• draft: 検討中の状態。バージョンはwip(work in progress)として扱われる。
• alpha: 初期フィードバックを得るための早期リリース。
• release candidate (rc): 実装・相互接続テスト向けのリリース候補。
• public: 正式リリース。メタリリースに含まれるのはこのステータスのAPIのみ。

APIステータスはAPIバージョン単位で定義されます。例えば，v0.2.0のrelease candidateの場合，YAMLのinfo.versionにはversion: 0.2.0-rc.1のように記載されます。alphaの場合はversion: 0.2.0-alpha.1，publicの場合はversion: 0.2.0となります。.1はイテレーション番号であり，同一ステータス内で修正が入るたびに加算されます。

さらに，publicリリースは，メジャーバージョン（x）の値によってさらにInitialとStableに区分されます。

• Initial（0.y.z）: 後方互換性は保証されない。メタリリース参加は任意。
• Stable（x.y.z, x≥1）: 後方互換性が原則保証される。メタリリース参加が必須。

APIのバージョン拡張識別子はリポジトリの成熟度（Sandbox / Incubating / Graduated）とは独立しており新バージョンのリリース自体は任意のタイミングで可能ですが，InitialからStableへの昇格では実質的にはサービス実績に関するGSMAの認定が求めらます。

まとめ

本記事では，CAMARAプロジェクトのリリース構造とAPIバージョンについて解説しました。

CAMARAは，実際に通信事業者によって実装・ローンチされ，商用環境で使用できる品質を持つことを保証する仕組みが，仕様書のライフサイクルに組み込まれています。

本記事が，CAMARAでの活動を始める方の参考になれば幸いです。

参考