CNCFプラットフォームホワイトペーパーv1.1 変更内容まとめ

はじめに

2026年1月にCNCFプラットフォームホワイトペーパーの更新活動が開始され、2026年5月にv1.1が公開されました。私も微力ながら貢献させていただき、貢献者一覧に名前を載せていただきました。("Genki Matsuda"で申告したはずですが、姓名が逆になってますね。日本人だからということで気を利かせてくれたのでしょうか。)

👁 クレジット

本記事では、v1からの変更内容のうち、私が気になったところをまとめます。

修正内容の詳細については、PRかCHANGELOGをご確認ください。

変更内容

今回はマイナーアップデートということで、大幅な内容変更は行わず、可読性の向上や内容の整理が中心となっています。

プラットフォームの成熟度

CNCFプラットフォームホワイトペーパーv1で語られていた成熟度は5段階のユースケースモデルでした。しかし、プラットフォームエンジニアリングの成熟度モデルでは、4段階の成熟度モデルが提唱されています。両方のドキュメントを読んだことのある方は、この違いに違和感を覚えたかもしれません。もともと、CNCFプラットフォームホワイトペーパーの初版公開時点では、プラットフォームエンジニアリングの成熟度モデルは作成されていませんでしたので、互いのドキュメントにズレが生じてしまいました。そのためv1.1では、成熟度モデルの内容がホワイトペーパーに反映され、4段階の成熟度になり、互いのドキュメントの内容が整合するようになりました。

1. 暫定的である - 必要に迫られて、一時的な担当者や有志によって機能が構築されます。そのため、導入状況は安定せず、運用や測定も場当たり的になりがちです。
2. 戦略的である - 専任の予算とチームを持つ体制が整い、共通機能が提供され、運用状況は中央集権的に管理されるようになります。ただし、多くの場合は課題発生後の対応が中心であり、ユーザーは組織からの指示やインセンティブによってプラットフォームを導入します。
3. スケーラブルである - プラットフォームが「製品」として扱われるようになり、顧客価値に基づいた投資や、プロダクト／UX担当者の配置が行われます。その結果、ユーザーは強制ではなく、プラットフォームそのものの価値を理由に導入を選択するようになります。
4. 最適化している - プラットフォームは、組織全体の効率化を支える「参加型エコシステム」へと発展します。プラットフォームのコアメンテナーは、各分野の専門家が機能を拡張できるよう支援することを重視し、利用者自身もプラットフォームの発展に参加する形で導入と活用が広がっていきます。

プラットフォーム特性

ユーザーエクスペリエンス

ちょっとしたAIエージェント要素ですが、プラットフォームはAIエージェントから実行されることも考慮に入れて設計されるべきである旨の記載が追記されました。

プラットフォームは、ユーザーが人間であってもAIエージェントであっても利用しやすいよう、状況に応じたインターフェースを提供する必要があります。

具体的に実現するとなると、MCPをサポートするとかになるのでしょうか。

セルフサービス

手動による審査や承認を待つことなく、プラットフォームの機能を利用できるべきであるということが強調されました。

例えば、ユーザーは、手動による審査や承認を待つことなく、コマンドラインツールを実行するか、Webポータル上のフォームに入力するだけで、データベースをリクエストし、そのロケーターと認証情報を受け取ることができるようにすべきです。

1エンジニアとしては、とても共感できるポイントで、新しいリソースを作成したいときにいちいち承認プロセスで待たされるのはストレスを感じます。一方、本番環境に同じチームのメンバーに承認ももらわず、リソースを作成できるようにするのは、セキュリティやコストの観点からも、望ましい状態ではないと思います。あくまでプロダクトチームが独力でリソースを作成管理できるようにすることが重要であり、ここで言う「手動による審査や承認」を行うのは、プラットフォームチームなど、プロダクトチーム以外によるものなのかなと、私は解釈しました。

Secure and compliant by default

プラットフォーム特性の一つ"Secure by default"が、v1.1では"Secure and compliant by default"に変更されました。
プラットフォームはデフォルトで、セキュアであることに加え、組織のルールや標準に準拠している状態であるべきである、とのことです。また、それらのルールや標準は、チェックリストのような形ではなく、あらかじめプラットフォームに組み込むことにより、ユーザーの認知負荷を軽減する、といった内容も追記されました。

デフォルトでセキュアかつコンプライアンス準拠。プラットフォームはデフォルトでセキュアであるべきであり、組織が定義したルールや標準に基づいて、コンプライアンスの確保や各種検証を行うための機能を提供する必要があります。ビジネスにおけるセキュリティ、ガバナンス、およびコンプライアンスに関する組織要件はプラットフォームにあらかじめ組み込まれているべきです。これにより、組織要件の一貫した適用を実現しつつ、ユーザーの認知的負荷を軽減できます。

例えば、ソフトウェアライセンス侵害がないか確認するなど、組織のルールに準拠することも、プラットフォームの機能として提供されるべきである、ということだと思います。また、セキュリティやコンプライアンスと聞いて、私は膨大なチェックリストを思い出したのですが、ここではそう言ったチェックリストではなく、プラットフォームにあらかじめ組み込むことにより、ユーザーの認知負荷を軽減することが重要である、ということが言いたいのかなと解釈しました。

プラットフォームの能力

プラットフォームの能力(Capabilities)の内容も、少し変更になっています。

アイデンティティおよびシークレットサービス

KeycloakがCNCF/CDFのプロジェクト例として追加されました。

tag-app-delivery側(古いサイト)でホワイトペーパーv1が公開された後、Keycloakを追加する修正が入ったのですが、Cloud Native Platform Engineering Community(新しいサイト)に移行したとき、移行が漏れちゃってたみたいです。ちなみにCloud Native Platform Engineering Communityの日本語版ホワイトペーパーv1にはちゃんとKeycloakが記載されており、ちぐはぐな状態になってしまっていました。

なんにせよ、日立として力を入れているプロジェクトなので、うれしい変更です。

機能のプロビジョニングおよび監視用Webポータル

説明から「プロジェクトテンプレート」を削除。現在はゴールデンパステンプレートに含めて整理。

こちらは、Webポータルの主な機能はプロビジョニングや監視であり、テンプレートはWebポータルの機能として「よい例」ではないということでしょう。

おわりに

CNCFプラットフォームホワイトペーパーv1.1のアップデート内容を紹介しました。今後、プラットフォームエンジニアリングの成熟度モデルの更新や、Platform Factors v1の公開もありますので、引き続き注目していきたいと思います。