[{"data":1,"prerenderedAt":376},["ShallowReactive",2],{"blog-ja-cncf-graduated-project-oss-selection-criteria":3,"blog-related-ja-cncf-graduated-project-oss-selection-criteria":327,"blog-ja-cncf-graduated-project-oss-selection-criteria-alt":315},{"id":4,"title":5,"author":6,"body":7,"date":309,"description":310,"extension":311,"image":312,"locale":313,"meta":314,"navigation":315,"path":316,"seo":317,"stem":318,"tags":319,"__hash__":326},"blog\u002Fblog\u002Fja\u002Fcncf-graduated-project-oss-selection-criteria.md","CNCFの『卒業』ロゴを信じていいのか。TOC公開議事から見えた、審査の地味な実態とOSS選定基準","Kubo Team",{"type":8,"value":9,"toc":295},"minimark",[10,15,19,26,37,40,61,65,68,74,77,80,127,136,139,143,146,152,156,159,180,187,191,205,208,217,221,224,230,256,259,268,280,284,287],[11,12,14],"h2",{"id":13},"cncfの卒業ロゴを見て安心していないか","CNCFの「卒業」ロゴを見て安心していないか",[16,17,18],"p",{},"CNCF（Cloud Native Computing Foundation）のプロジェクト一覧ページを開くと、Prometheus や Envoy、Kubernetes 本体の横に「Graduated」というバッジが並んでいる。多くのインフラエンジニアは、このバッジを見た瞬間に「本番投入OK」という判断を下す。だが、そのCNCF Graduatedというラベルの裏側で何が審査されているのかを、実際に説明できる人は少ない。",[16,20,21],{},[22,23],"img",{"alt":24,"src":25},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fcncf-graduated-project-oss-selection-criteria\u002Fsection01.webp",[16,27,28,29,36],{},"CNCFのプロジェクトは ",[30,31,35],"a",{"href":32,"rel":33},"https:\u002F\u002Fcontribute.cncf.io\u002Fprojects\u002Flifecycle\u002F",[34],"nofollow","Sandbox → Incubating → Graduated"," という3段階の成熟度モデルで管理されている。公式の説明によれば、Sandboxは「まだ実験的・革新的な初期段階のプロジェクト」、Incubatingは「変更頻度が下がり、APIも安定してきた段階」、Graduatedは「高い安定性・機能性・広範な採用を実証した最高位」とされる。加えて、活動が止まったプロジェクトが移される「Archived」という第4のステータスも存在する。",[16,38,39],{},"問題は、この3段階のラベルが「静的な合格証」のように扱われがちなことだ。実際には、卒業判定は一度きりの試験ではなく、TOC（Technical Oversight Committee）による継続的な合議プロセスの結果にすぎない。",[16,41,42,43,48,49,54,55,60],{},"Kubernetes本体が初めて「卒業」プロジェクトとして認定されたのは2018年3月のことだ。当時CNCF傘下にあった16プロジェクトの中で卒業したのはKubernetesのみで、",[30,44,47],{"href":45,"rel":46},"https:\u002F\u002Fwww.publickey1.jp\u002Fblog\u002F18\u002Fkubernetescncf.html",[34],"Publickeyの報道","では「あらゆる規模の企業でコンテナを大規模に管理できるレジリエンスを備えている」ことの証明と説明されている。同時期の",[30,50,53],{"href":51,"rel":52},"https:\u002F\u002Fatmarkit.itmedia.co.jp\u002Fait\u002Farticles\u002F1803\u002F07\u002Fnews122.html",[34],"ITmedia @ITの解説","によれば、認定基準には「プロジェクトのガバナンス、コミュニティの成熟、コード品質、貢献度」などが含まれるとされていた。この記事では、CNCFのTOC公開会議の実態と公式ドキュメントを手がかりに、Kubernetes \u002F K3sエコシステムでOSSを選ぶときに本当に見るべき基準を整理する。後半では、この見極めのコストを個々の企業がどこまで自前で負うべきか、CNCF認定のK3sをベースにした",[30,56,59],{"href":57,"rel":58},"https:\u002F\u002Fkubo.hexabase.io\u002F",[34],"Kubo","のようなマネージドK8s基盤の位置づけにも触れる。",[11,62,64],{"id":63},"toc公開会議から見える審査の地味な実態","TOC公開会議から見える、審査の地味な実態",[16,66,67],{},"CNCFのTOCは定期的に公開会議を開き、議事の一部を公開している。そこで語られている内容は、想像以上に地味で泥臭い。プロジェクトを評価する基準は「仕様（spec）に必ずしも紐づかない」ことが多く、TOCメンバーは既存の評価基準そのものを継続的に見直している。",[16,69,70],{},[22,71],{"alt":72,"src":73},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fcncf-graduated-project-oss-selection-criteria\u002Fsection02.webp",[16,75,76],{},"例えば、あるプロジェクトの卒業審査で使われたデューデリジェンス手法自体を、別のプロジェクトの審査を通じて事後的に見直すという議論も行われている。これは「基準が一度決まったら固定される」ものではなく、TOCメンバー間の議論を通じて随時更新されていることを示している。",[16,78,79],{},"公式のTOC Due Diligenceガイドによれば、審査プロセスは以下のフェーズで進む。",[81,82,83,91,97,103,109,115,121],"ol",{},[84,85,86,90],"li",{},[87,88,89],"strong",{},"トリアージとアサイン",": TOCメンバーが申請の基本要件を確認し、スポンサーにつく",[84,92,93,96],{},[87,94,95],{},"キックオフ",": プロジェクト側とTOCメンバーが期待値とスケジュールを合意",[84,98,99,102],{},[87,100,101],{},"基準評価",": 該当する成熟度レベルの要件に対して実装を評価",[84,104,105,108],{},[87,106,107],{},"アダプター面接",": 実際の採用企業への最低3件のインタビューで、本番導入の実態を検証",[84,110,111,114],{},[87,112,113],{},"内部レビュー",": TOCメンバー同士でおよそ1週間のピアレビュー",[84,116,117,120],{},[87,118,119],{},"パブリックコメント",": コミュニティからのフィードバック募集",[84,122,123,126],{},[87,124,125],{},"投票",": TOCメンバーによる承認・否認の投票",[16,128,129,130,135],{},"（出典: ",[30,131,134],{"href":132,"rel":133},"https:\u002F\u002Fcontribute.cncf.io\u002Fcommunity\u002Ftoc\u002Foperations\u002Fdd-toc-guide\u002F",[34],"CNCF TOC Due Diligence Guide","）",[16,137,138],{},"このプロセスを見れば分かる通り、卒業審査は「コードの品質チェック」だけでは終わらない。アダプター面接というヒューマンなプロセスが必須であり、面接相手の日程調整が遅れれば審査全体のスケジュールも遅延する。TOC公開会議の議事では、まさにそうした調整の遅延や、面接候補者からの返信待ちといった実務的な足踏みが率直に語られている。",[11,140,142],{"id":141},"sandboxincubatinggraduatedの審査タイミングと基準","Sandbox・Incubating・Graduatedの審査タイミングと基準",[16,144,145],{},"「卒業ロゴ」を過信しないためには、各成熟度レベルでいつ・何が審査されるのかを正確に把握しておく必要がある。",[16,147,148],{},[22,149],{"alt":150,"src":151},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fcncf-graduated-project-oss-selection-criteria\u002Fsection03.webp",[153,154,155],"h3",{"id":155},"審査タイミングの非対称性",[16,157,158],{},"CNCF公式のDue Diligenceガイドが明確にしているのは、審査のタイミングが3段階で全く異なるという点だ。",[160,161,162,168,174],"ul",{},[84,163,164,167],{},[87,165,166],{},"Sandbox",": 参加時点でのデューデリジェンスは実施されない。Incubationに申請したときに初めて審査対象になる",[84,169,170,173],{},[87,171,172],{},"Incubating",": Graduationに申請したタイミングで審査を受ける",[84,175,176,179],{},[87,177,178],{},"Graduated",": その段階に達した後、追加のデューデリジェンスは行われない",[16,181,182,183,186],{},"つまり、「Sandboxに入っている」という事実だけでは、TOCによる実質的な審査を一度も受けていない可能性がある。逆に「Graduated」であっても、その後の審査は行われないため、プロジェクトの現在の健全性を保証するものではない（出典: ",[30,184,134],{"href":132,"rel":185},[34],"）。",[153,188,190],{"id":189},"incubatingへの昇格に必要な条件","Incubatingへの昇格に必要な条件",[16,192,193,194,199,200,204],{},"Sandboxからincubatingへ進むための核心的な基準は、「独立した3社以上のアダプター（採用企業）が本番環境で実際に使用していること」だ。申請時には5〜7社のアダプターに対するインタビュー協力が求められる（出典: ",[30,195,198],{"href":196,"rel":197},"https:\u002F\u002Fgithub.com\u002Fcncf\u002Ftoc\u002Fissues\u002F1967",[34],"cncf\u002Ftoc Issue #1967","、",[30,201,203],{"href":32,"rel":202},[34],"CNCF Project Lifecycle","）。この「独立した採用実績」という条件が、単なる技術的完成度だけでなくエコシステム内での実採用を重視するCNCFのスタンスをよく表している。",[153,206,207],{"id":207},"卒業しても永久ではない",[16,209,210,211,216],{},"CNCFには「Archived」というステータスもあり、活動が停滞したプロジェクトはこちらに移される。CNCF公式のArchived Projectsページには、Brigade、OpenTracing、rkt、Open Service Mesh、Pravega、Keptnなど26のプロジェクトが掲載されている（出典: ",[30,212,215],{"href":213,"rel":214},"https:\u002F\u002Fwww.cncf.io\u002Farchived-projects\u002F",[34],"CNCF Archived Projects","）。興味深いのは、Archived後も提案プロセスを経て復活できる点だ。実際にOpenEBSは一度Archivedになった後、再びSandboxプロジェクトとして復帰した例がある。つまり「卒業」だけでなく「引退」もまた、固定的なラベルではなく継続的な合議の結果ということになる。",[11,218,220],{"id":219},"本番導入前に自分でossの成熟度を評価するコストを考える","本番導入前に自分でOSSの成熟度を評価するコストを考える",[16,222,223],{},"ここまで見てきたプロセスを、企業のインフラチームが自前で再現することは現実的だろうか。CNCFのランドスケープには数百のプロジェクトが並び、成熟度は日々更新されている。K8sバージョンやリリースノートと同様に、CNCFプロジェクトの成熟度も定期的な確認が欠かせない。",[16,225,226],{},[22,227],{"alt":228,"src":229},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fcncf-graduated-project-oss-selection-criteria\u002Fsection04.webp",[16,231,232,233,238,239,244,245,249,250,255],{},"面白い実例として、Kubo が採用している軽量Kubernetesディストリビューションの",[30,234,237],{"href":235,"rel":236},"https:\u002F\u002Fk3s.io\u002F",[34],"K3s","自体を見てみよう。K3sはCNCFの",[30,240,243],{"href":241,"rel":242},"https:\u002F\u002Fgithub.com\u002Fcncf\u002Fk8s-conformance",[34],"Certified Kubernetes Conformance Program","に合格した「認定Kubernetesディストリビューション」であり、標準Kubernetes向けに作られたワークロードがそのまま動作することが保証されている（出典: ",[30,246,248],{"href":235,"rel":247},[34],"K3s 公式サイト","）。一方で、K3sがCNCFに寄贈された際、",[30,251,254],{"href":252,"rel":253},"https:\u002F\u002Fwww.forbes.com\u002Fsites\u002Fjanakirammsv\u002F2020\u002F08\u002F28\u002Fwhy-is-the-open-source-community-excited-about-k3s-project-joining-cncf\u002F",[34],"Forbesの解説記事","は「Kubernetesディストリビューションとして初めてCNCFにSandboxプロジェクトとして提出された」ことを、SUSEによるRancher買収後もコミュニティ主導の開発体制とガバナンスが維持される証として評価していた。",[16,257,258],{},"ここで重要なのは、「CNCF Conformance認定（適合性の技術検証）」と「CNCFの成熟度ラベル（Sandbox\u002FIncubating\u002FGraduated というガバナンス上の位置づけ）」は、そもそも別の軸の評価だという点だ。前者は「標準APIをきちんと実装しているか」という技術的な適合性の検証であり、後者は「エコシステム内での採用実績とガバナンスの成熟度」を示す指標である。この2つを混同して「CNCFに認定されているから安心」と一括りにしてしまうことが、まさに冒頭で触れた「ロゴを見て安心する」という誤解の正体だ。",[16,260,261,262,267],{},"こうした階層の違いを正確に理解し、継続的に追い続けるには専門知識と時間が必要になる。",[30,263,266],{"href":264,"rel":265},"https:\u002F\u002Fwww.cncf.io\u002Fannouncements\u002F2026\u002F01\u002F20\u002Fkubernetes-established-as-the-de-facto-operating-system-for-ai-as-production-use-hits-82-in-2025-cncf-annual-cloud-native-survey\u002F",[34],"2025年のCNCF年次調査","では、コンテナ利用企業の82%がKubernetesを本番環境で運用しており、調査対象組織の98%がクラウドネイティブ技術を採用していると報告されている。エコシステムの規模が拡大するほど、個々のプロジェクトの成熟度を自前で追い続けるコストは増す一方だ。",[16,269,270,271,274,275,279],{},"だからこそ、マネージドK8s基盤を選ぶ際には、単に「Kubernetesが動くこと」だけでなく、その基盤がどのOSSコンポーネントをどう選定・組み合わせているかという「エコシステムの目利き」を基盤側に委ねるという選択肢が現実的になる。",[30,272,59],{"href":57,"rel":273},[34],"はCNCF認定（Conformance）のK3sをベースに、Prometheus + Grafanaによる監視、cert-managerによる証明書管理、ArgoCD\u002FFluxとの統合など、CNCFエコシステムの主要コンポーネントを標準搭載している。個々のOSSの成熟度を毎回自分で追いかけるのではなく、すでに組み合わせと運用実績が固まった基盤の上でスタートできる点が、",[30,276,278],{"href":57,"rel":277},[34],"Kubo Cloud","のPure Kubernetes（標準K8s準拠、ベンダーロックインなし）というコンセプトの核心でもある。",[11,281,283],{"id":282},"sandboxincubatinggraduatedを選定の入口として使う","Sandbox・Incubating・Graduatedを、選定の「入口」として使う",[16,285,286],{},"CNCFのTOC公開会議の議事を読むと分かる通り、卒業審査は事務的な承認作業ではなく、仕様に紐づかない基準の議論、既存デューデリジェンス手法の見直し、アダプター面接の日程調整といった、地味で人間的なプロセスの積み重ねだ。Sandboxは審査を経ていない可能性がある段階、Incubatingは独立した3社以上の本番採用実績を示した段階、Graduatedはその実績に基づいてTOCの投票を通過した段階——この非対称性を理解しておけば、「Graduatedだから安全」「Sandboxだから使えない」という短絡的な判断を避けられる。",[16,288,289,290,294],{},"一方で、CNCFのラベルはあくまで「入口」の目安であり、自社のワークロードとの適合性、運用実績、サポート体制まで含めた最終判断は別途必要になる。その判断コストを減らす手段として、",[30,291,293],{"href":57,"rel":292},[34],"Rancher管理基盤","によるマルチクラスタの可視化や、CNCF準拠のツールチェーンを標準搭載したマネージドK3s基盤を検討する価値はあるはずだ。次にCNCFのバッジを見かけたら、そのラベルの奥にある審査プロセスまで一歩踏み込んで確認してみてほしい。",{"title":296,"searchDepth":297,"depth":297,"links":298},"",2,[299,300,301,307,308],{"id":13,"depth":297,"text":14},{"id":63,"depth":297,"text":64},{"id":141,"depth":297,"text":142,"children":302},[303,305,306],{"id":155,"depth":304,"text":155},3,{"id":189,"depth":304,"text":190},{"id":207,"depth":304,"text":207},{"id":219,"depth":297,"text":220},{"id":282,"depth":297,"text":283},"2026-07-23","CNCFの「卒業（Graduated）」ロゴは安全証明ではない。TOC公開会議の議事から見える審査の実態と、Sandbox・Incubating・Graduatedの基準・タイムラインを解説し、本番導入前にOSSの成熟度を見極める視点を紹介する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fcncf-graduated-project-oss-selection-criteria\u002Feyecatch.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fcncf-graduated-project-oss-selection-criteria",{"title":5,"description":310},"blog\u002Fja\u002Fcncf-graduated-project-oss-selection-criteria",[320,321,322,323,324,325],"cncf","kubernetes","k3s","oss","managed-kubernetes","governance","MsLpMad34DJaVb6Yr00gXGQAUpYUDv-uPe5RMCAMxNU",[328,335,343,351,360,368],{"path":329,"title":330,"description":331,"date":332,"tags":333},"\u002Fblog\u002Fja\u002Fkubernetes-ai-inference-reversal-conformance-design","推論が学習を逆転した。KubeCon Japanで語られた、AI時代のKubernetesクラスタ設計指針","AI計算需要は学習から推論へ逆転し、2030年には推論の計算能力が学習の1.5倍に達すると予測される。KubeCon Japanの議論とCNCF AI Conformance Programから、Kubernetes\u002FK3sクラスタが備えるべき設計指針を解説する。","2026-08-01",[321,322,334,320,324],"ai-inference",{"path":336,"title":337,"description":338,"date":339,"tags":340},"\u002Fblog\u002Fja\u002Fkubevirt-calico-live-migration-networking","VMを動かしても通信は切れない。KubeVirtとCalicoが実現するKubernetesライブマイグレーションの舞台裏","KubernetesでVM（KubeVirt）をノード間へライブマイグレーションしても、なぜ通信が切れないのか。CalicoのIP永続化・BGPルート収束の仕組みと、VMware移行先としての実務的な意味を解説する。","2026-08-07",[322,321,341,342,324],"kubevirt","networking",{"path":344,"title":345,"description":346,"date":347,"tags":348},"\u002Fblog\u002Fja\u002Fai-generated-kubernetes-manifest-resource-overprovisioning","Kubernetesリソース設計はAI任せにできない。「動く」YAMLがクラウド代を69%溶かす理由","AIが生成したKubernetesマニフェストはkubectl applyが通り「動く」。しかしKubernetesリソース設計を誤ると過剰プロビジョニングでクラウド代が膨らむ。AIの限界と本番品質のrequests\u002Flimits設計を解説する。","2026-08-04",[322,321,349,350,324],"resource-management","capacity-planning",{"path":352,"title":353,"description":354,"date":355,"tags":356},"\u002Fblog\u002Fja\u002Fkubernetes-microservices-chatty-calls-latency","1つの注文処理で、裏側は5回叩かれていた。Kubernetesマイクロサービスの「チャッティ呼び出し」とレイテンシの正体","1回の注文処理の裏側でサービスが5回も呼び出されていた。原因はKubernetesマイクロサービスが陥る「チャッティ呼び出し」というアーキテクチャの問題。分散システムのN+1問題と解決策を解説する。","2026-08-02",[321,322,357,358,359,324],"microservices","service-mesh","latency",{"path":361,"title":362,"description":363,"date":364,"tags":365},"\u002Fblog\u002Fja\u002Fhybrid-k3s-edge-metrics-network-overhead","2000台のIoTデバイスがネットワーク回線を圧迫していた。ハイブリッドK3s運用でpush型メトリクスが牙を剥いた日","2000台規模のエッジデバイスを支えるK3sエッジ運用の現場で見えた、軽量Kubernetesを選ぶべき理由と、push型メトリクス収集が生むネットワークコストの実態を、具体的な数値とハイブリッドクラスタ設計の観点から詳しく解説する記事。エンジニア・運用担当者向け。","2026-07-31",[322,321,366,367,324],"edge-computing","hybrid-cluster",{"path":369,"title":370,"description":371,"date":372,"tags":373},"\u002Fblog\u002Fja\u002Fedge-k3s-observability-homelab-dashboard","壁に貼っただけで「安心」に変わる。ホームラボの壁掛けダッシュボードが教えてくれた、エッジK3sクラスタの観測性設計","自宅の壁掛けダッシュボード作りで起きた総当たりのトラブルシューティングは、工場や店舗に分散したエッジKubernetesクラスタの運用でも同じ罠になる。K3s・Prometheus・Grafanaの公式ドキュメントを引きながら、観測性を後回しにしないための設計原則を解説する。","2026-07-26",[322,321,366,374,375,324],"observability","monitoring",1786701428788]