CNCFの「卒業」ロゴを見て安心していないか
CNCF（Cloud Native Computing Foundation）のプロジェクト一覧ページを開くと、Prometheus や Envoy、Kubernetes 本体の横に「Graduated」というバッジが並んでいる。多くのインフラエンジニアは、このバッジを見た瞬間に「本番投入OK」という判断を下す。だが、そのCNCF Graduatedというラベルの裏側で何が審査されているのかを、実際に説明できる人は少ない。
CNCFのプロジェクトは Sandbox → Incubating → Graduated という3段階の成熟度モデルで管理されている。公式の説明によれば、Sandboxは「まだ実験的・革新的な初期段階のプロジェクト」、Incubatingは「変更頻度が下がり、APIも安定してきた段階」、Graduatedは「高い安定性・機能性・広範な採用を実証した最高位」とされる。加えて、活動が止まったプロジェクトが移される「Archived」という第4のステータスも存在する。
問題は、この3段階のラベルが「静的な合格証」のように扱われがちなことだ。実際には、卒業判定は一度きりの試験ではなく、TOC（Technical Oversight Committee）による継続的な合議プロセスの結果にすぎない。
Kubernetes本体が初めて「卒業」プロジェクトとして認定されたのは2018年3月のことだ。当時CNCF傘下にあった16プロジェクトの中で卒業したのはKubernetesのみで、Publickeyの報道では「あらゆる規模の企業でコンテナを大規模に管理できるレジリエンスを備えている」ことの証明と説明されている。同時期のITmedia @ITの解説によれば、認定基準には「プロジェクトのガバナンス、コミュニティの成熟、コード品質、貢献度」などが含まれるとされていた。この記事では、CNCFのTOC公開会議の実態と公式ドキュメントを手がかりに、Kubernetes / K3sエコシステムでOSSを選ぶときに本当に見るべき基準を整理する。後半では、この見極めのコストを個々の企業がどこまで自前で負うべきか、CNCF認定のK3sをベースにしたKuboのようなマネージドK8s基盤の位置づけにも触れる。
TOC公開会議から見える、審査の地味な実態
CNCFのTOCは定期的に公開会議を開き、議事の一部を公開している。そこで語られている内容は、想像以上に地味で泥臭い。プロジェクトを評価する基準は「仕様（spec）に必ずしも紐づかない」ことが多く、TOCメンバーは既存の評価基準そのものを継続的に見直している。
例えば、あるプロジェクトの卒業審査で使われたデューデリジェンス手法自体を、別のプロジェクトの審査を通じて事後的に見直すという議論も行われている。これは「基準が一度決まったら固定される」ものではなく、TOCメンバー間の議論を通じて随時更新されていることを示している。
公式のTOC Due Diligenceガイドによれば、審査プロセスは以下のフェーズで進む。
- トリアージとアサイン: TOCメンバーが申請の基本要件を確認し、スポンサーにつく
- キックオフ: プロジェクト側とTOCメンバーが期待値とスケジュールを合意
- 基準評価: 該当する成熟度レベルの要件に対して実装を評価
- アダプター面接: 実際の採用企業への最低3件のインタビューで、本番導入の実態を検証
- 内部レビュー: TOCメンバー同士でおよそ1週間のピアレビュー
- パブリックコメント: コミュニティからのフィードバック募集
- 投票: TOCメンバーによる承認・否認の投票
（出典: CNCF TOC Due Diligence Guide）
このプロセスを見れば分かる通り、卒業審査は「コードの品質チェック」だけでは終わらない。アダプター面接というヒューマンなプロセスが必須であり、面接相手の日程調整が遅れれば審査全体のスケジュールも遅延する。TOC公開会議の議事では、まさにそうした調整の遅延や、面接候補者からの返信待ちといった実務的な足踏みが率直に語られている。
Sandbox・Incubating・Graduatedの審査タイミングと基準
「卒業ロゴ」を過信しないためには、各成熟度レベルでいつ・何が審査されるのかを正確に把握しておく必要がある。
審査タイミングの非対称性
CNCF公式のDue Diligenceガイドが明確にしているのは、審査のタイミングが3段階で全く異なるという点だ。
- Sandbox: 参加時点でのデューデリジェンスは実施されない。Incubationに申請したときに初めて審査対象になる
- Incubating: Graduationに申請したタイミングで審査を受ける
- Graduated: その段階に達した後、追加のデューデリジェンスは行われない
つまり、「Sandboxに入っている」という事実だけでは、TOCによる実質的な審査を一度も受けていない可能性がある。逆に「Graduated」であっても、その後の審査は行われないため、プロジェクトの現在の健全性を保証するものではない（出典: CNCF TOC Due Diligence Guide）。
Incubatingへの昇格に必要な条件
Sandboxからincubatingへ進むための核心的な基準は、「独立した3社以上のアダプター（採用企業）が本番環境で実際に使用していること」だ。申請時には5〜7社のアダプターに対するインタビュー協力が求められる（出典: cncf/toc Issue #1967、CNCF Project Lifecycle）。この「独立した採用実績」という条件が、単なる技術的完成度だけでなくエコシステム内での実採用を重視するCNCFのスタンスをよく表している。
卒業しても永久ではない
CNCFには「Archived」というステータスもあり、活動が停滞したプロジェクトはこちらに移される。CNCF公式のArchived Projectsページには、Brigade、OpenTracing、rkt、Open Service Mesh、Pravega、Keptnなど26のプロジェクトが掲載されている（出典: CNCF Archived Projects）。興味深いのは、Archived後も提案プロセスを経て復活できる点だ。実際にOpenEBSは一度Archivedになった後、再びSandboxプロジェクトとして復帰した例がある。つまり「卒業」だけでなく「引退」もまた、固定的なラベルではなく継続的な合議の結果ということになる。
本番導入前に自分でOSSの成熟度を評価するコストを考える
ここまで見てきたプロセスを、企業のインフラチームが自前で再現することは現実的だろうか。CNCFのランドスケープには数百のプロジェクトが並び、成熟度は日々更新されている。K8sバージョンやリリースノートと同様に、CNCFプロジェクトの成熟度も定期的な確認が欠かせない。
面白い実例として、Kubo が採用している軽量KubernetesディストリビューションのK3s自体を見てみよう。K3sはCNCFのCertified Kubernetes Conformance Programに合格した「認定Kubernetesディストリビューション」であり、標準Kubernetes向けに作られたワークロードがそのまま動作することが保証されている（出典: K3s 公式サイト）。一方で、K3sがCNCFに寄贈された際、Forbesの解説記事は「Kubernetesディストリビューションとして初めてCNCFにSandboxプロジェクトとして提出された」ことを、SUSEによるRancher買収後もコミュニティ主導の開発体制とガバナンスが維持される証として評価していた。
ここで重要なのは、「CNCF Conformance認定（適合性の技術検証）」と「CNCFの成熟度ラベル（Sandbox/Incubating/Graduated というガバナンス上の位置づけ）」は、そもそも別の軸の評価だという点だ。前者は「標準APIをきちんと実装しているか」という技術的な適合性の検証であり、後者は「エコシステム内での採用実績とガバナンスの成熟度」を示す指標である。この2つを混同して「CNCFに認定されているから安心」と一括りにしてしまうことが、まさに冒頭で触れた「ロゴを見て安心する」という誤解の正体だ。
こうした階層の違いを正確に理解し、継続的に追い続けるには専門知識と時間が必要になる。2025年のCNCF年次調査では、コンテナ利用企業の82%がKubernetesを本番環境で運用しており、調査対象組織の98%がクラウドネイティブ技術を採用していると報告されている。エコシステムの規模が拡大するほど、個々のプロジェクトの成熟度を自前で追い続けるコストは増す一方だ。
だからこそ、マネージドK8s基盤を選ぶ際には、単に「Kubernetesが動くこと」だけでなく、その基盤がどのOSSコンポーネントをどう選定・組み合わせているかという「エコシステムの目利き」を基盤側に委ねるという選択肢が現実的になる。KuboはCNCF認定（Conformance）のK3sをベースに、Prometheus + Grafanaによる監視、cert-managerによる証明書管理、ArgoCD/Fluxとの統合など、CNCFエコシステムの主要コンポーネントを標準搭載している。個々のOSSの成熟度を毎回自分で追いかけるのではなく、すでに組み合わせと運用実績が固まった基盤の上でスタートできる点が、Kubo CloudのPure Kubernetes（標準K8s準拠、ベンダーロックインなし）というコンセプトの核心でもある。
Sandbox・Incubating・Graduatedを、選定の「入口」として使う
CNCFのTOC公開会議の議事を読むと分かる通り、卒業審査は事務的な承認作業ではなく、仕様に紐づかない基準の議論、既存デューデリジェンス手法の見直し、アダプター面接の日程調整といった、地味で人間的なプロセスの積み重ねだ。Sandboxは審査を経ていない可能性がある段階、Incubatingは独立した3社以上の本番採用実績を示した段階、Graduatedはその実績に基づいてTOCの投票を通過した段階——この非対称性を理解しておけば、「Graduatedだから安全」「Sandboxだから使えない」という短絡的な判断を避けられる。
一方で、CNCFのラベルはあくまで「入口」の目安であり、自社のワークロードとの適合性、運用実績、サポート体制まで含めた最終判断は別途必要になる。その判断コストを減らす手段として、Rancher管理基盤によるマルチクラスタの可視化や、CNCF準拠のツールチェーンを標準搭載したマネージドK3s基盤を検討する価値はあるはずだ。次にCNCFのバッジを見かけたら、そのラベルの奥にある審査プロセスまで一歩踏み込んで確認してみてほしい。