【KubeCon Japan】CNCFのリサーチ「クラウドネイティブ開発の現状」から見える日本のITが抱える問題点を考察する

Cloud Native Computing Foundation（CNCF）がKubeCon＋CloudNativeCon Japan 2026に合わせて公開した、日本におけるクラウドネイティブなシステム開発および運用に関する調査を紹介し、同時に日本が抱える問題点に関する考察をお届けする。リサーチはCNCFとSlashDataの共同で行われ、リサーチの部分は主にSlashDataが担当、2025年12月から2026年1月にかけて世界規模で実施され、95ヶ国から12500人が参加した。アジアからの回答者は全体の9％に相当するという。リサーチの要約については以下のページから参照可能だ。

●リサーチのページ：日本におけるクラウドネイティブ開発の現状 2026

このレポートのタイトルは「日本におけるクラウドネイティブ開発の現状2026」、クラウドネイティブなシステムの開発と運用の現状を世界のデータと比較して考察するという内容だ。このレポートの冒頭で日本のクラウドネイティブな開発者の数が95万人になったことを紹介。しかしながら2025年のQ3の数からは減少している。この95万人はThe Linux Foundationのプレスリリースでは「クラウドネイティブな開発者が100万人」になったと高く評価していた内容だが、より詳細に読み込むと減少しているが、調査の誤差かもしれないというのがこのレポートの最初のポイントになる。LFのプレスリリースは以下を参照して欲しい。

●参考：CNCFとSlashDataの調査レポート：日本のクラウドネイティブコミュニティの開発者数が約100万人に到達

クラウドネイティブ開発者の割合が減少していることを示すグラフ

また次のポイントとして、日本が世界と比べてパブリッククラウドを使う割合が低く、オンプレミスサーバーの利用が高いことを紹介している。パブリッククラウドの利用が29％、プライベートクラウドも同じく29％、それに対してオンプレミスサーバーの利用は47％となっている。この数値は1年前、つまり2025年のQ1からさらに拡大している。これに対して世界の数値はオンプレミスが38％、パブリッククラウドが33％、そしてプライベートクラウドが38％であるという。日本でオンプレミスサーバーの利用が大きいことについて、その背景を探るのであれば、コストについて質問するべきだろう。パブリッククラウドが即座に使えるプラットフォームとして存在感を増しているとしても、オンプレミスサーバーとのコスト比較により徐々にオンプレミスに戻る傾向は存在する。特にGPUサーバーが調達できない状況ではパブリッククラウドを使う以外の選択肢がない。外部の生成AIサービスを使うのであれば、コストはさらに上昇する。その観点で比較しない限り、どうしてオンプレミスサーバーが未だに主流なのかは説明が難しい。必要なリソースのためにはパブリッククラウドも使うが、コストのプレッシャーからオンプレミスを使うという選択の結果としてオンプレミスに戻る流れが発生したのかどうかは、単にテクノロジーの利用調査だけでは考察できないだろう。

オンプレミスが未だに大きな割合を占める日本のITインフラストラクチャー

またこのレポートは日本のIT実装についての特異的なポイントについても指摘している。17ページに記載されている日本の状況を解説する一文を引用する。

「日本では、システムインテグレーター（SI）が、組織や開発者のニーズに応えるため、オンプレミスサーバー向けにカスタマイズされた専用システムを構築してきた長い歴史があります。その結果、こうしたシステムの多くは、クラウドサービスへの移行が困難なほどに複雑になっています。さらにその高性能さゆえに、クラウドサービスのメリットは、オンプレミスサーバーが提供するデータ主権やリスク管理の制御機能と競合せざるを得ない状況にあります。」

ここで足らないのは構造的な視点だろう。これまでは日本の事業会社のITを提供するのは要求仕様を顧客と一緒になって考え、設計開発して納品を行うシステムインテグレーターだった。事業会社は運用を担当し、機能開発や改良、不具合の修正は開発を行ったシステムインテグレーターの仕事だった。システムインテグレーターはエンジニアを顧客に常駐させ、開発を行い、運用の設計についても多大な影響力を持っていた。機能が競合するだけではなく、構造的に開発から実装までが分離されていた。だからCI（コードのビルドからテストそしてステージング環境への実装）は実現可能でもCD（変更を継続的に本番環境に実装）は難しいはずであるが、このリサーチではCI/CDの利用については言及していないのが残念である。

また19ページではこのシステムインテグレーター主導のインフラシステム開発によって、オープンソースへの貢献が少なくなってしまう点に直接言及している。これはシステム開発に使われるツールの選定が事業会社ではなくシステムインテグレーターによって行われるために、自社が依存しているオープンソースソフトウェアに対する認識が低く、その活動に貢献しようとする意識が低くなってしまうと記載されている。

これは事業会社がオープンソースの消費者でしかなく、その活動を支援するという方向に動かないことを意味している。要件は事業会社が書いたとしてもその実装とツール選択はシステムインテグレーターが行い、開発もシステムインテグレーターが担当するのであれば、事業会社のIT部門が「開発に使われるツールは何か？」という意識を持つことはないだろう。結果としてそのプロジェクトに対する貢献、バグレポート、修正などを事業会社が行うはずもない。

またシステムインテグレーターにとっても受託事業として顧客向けのソフトウェア開発を行う中で見つけたオープンソースのバグについても修正する行為、結果として書かれたパッチは顧客のコストの中で作られた成果物としてオープンソースコミュニティに還元する理由は乏しくなる。結果としてフォークされたコードに対するカスタムなパッチとして生き残り、コミュニティに還元されることはなくバージョンが上がった時にバックポートする作業が発生するため、バックポートは行われない。その結果、そのソフトウェアはオープンソースの継続的改善からは外れた塩漬けプロジェクトと化してしまう。

この構造はコンテナの利用が減っていることと相似形かもしれない。システムの運用を行うエンジニアはKubernetesを使ってインフラストラクチャーを構築していても、その上で開発を行うエンジニアはKubernetesを抽象化されたサービス、いわゆる「Kubernetes-as-a-Service」として使用している。抽象化されているがゆえにKubernetes、つまりコンテナを使っていると認識していない開発者の数が拡がっているということだろう。運用側が実行環境をPaaSのように提供して、開発者は意識せずにコンテナやサーバーレスを使っているという理解が妥当だろう。

後半の「クラウドネイティブ成熟度向上への道」についても考察する。

バックエンドで使われる要素技術の関連を示す図

ここではマイクロサービスやKubernetes、オブザーバビリティ、ストリーミングおよびメッセージングが挙げられているが、これは要素技術でしかなく、成熟度の道のりを語るのであれば、CNCFが公開しているトレイルマップを参考にするべきだろう。

●参考：https://github.com/cncf/trailmap

このマップ自体がすでに5年前からアップデートされていないということも問題だが、むしろ「基本的な部分は5年間（以上）変わっていない」という証拠とも言える。最初に手を付けるべき3つのステップがコンテナ化、CI/CDの導入、オーケストレーションということをもう一度、思い出すべきだろう。

このスライドでは要素技術の関連が解説されているが、マイクロサービス化は必須ではなく、KubeVirtによる仮想マシンもKubernetesでオーケストレーションすることで生成AI関連のワークロードもスムーズに管理できることに注目が集まっていることがこのリサーチでは浮き上がってこない。

またフィーチャーフラッグが大きく取り上げられているが、フィーチャーフラッグは機能の更新を本番環境で素早く行うための仕組みであり、CI/CDが実践されていない開発と運用が分断されているような企業が機能の実装を素早く行うための方法論かもしれない可能性についても深く分析できないのが残念だ。

全体として日本のバックエンドとフロントエンドの開発者の状況を世界と比較して検証するには十分かもしれないが、日本の事業会社やシステムインテグレーターからオープンソースへの貢献が少ない点について気付いているのにそこを掘り下げないのは残念に感じた。生成AIによってプルリクエストを作るコストが劇的に下がったにも関わらず、レビューを行うメンテナーのコストは下がらずプロジェクトが疲弊してしまっているという状態に加担しているかもしれない日本のオープンソース消費者の課題を取り上げることは、オープンソースの加護者としてのLF/CNCFには必須だろう。Akritesに続くLF/CNCFの次の一手に期待したい。