AI LAB

Insights and Innovations

ISMのAIツール

無料で文字起こしをはじめる
点線の用語から説明を表示できます AIキーワード辞書 ↗
Sus8システム
2026/11/12
AIニュース
クラウドネイティブ開発者が2,100万人超に、AI普及で問われるレビュー負荷とコスト管理

この記事の要点

CNCFとSlashDataの調査によると、クラウドネイティブ開発者は世界で2,100万人を超え、約75%がAIを利用しています。普及とともに、AI生成の変更提案を確認するメンテナーの負担や、モデル・トークンの費用管理が課題になっています。企業には、生成の速さに加え、レビューや手戻りを含む業務全体の負担を測る視点が求められます。

目次
2,100万人の開発者が支える、AI導入の足場


AIでコードを作る人が増えても、そのコードを確かめ、受け入れる人の時間まで増えるわけではありません。クラウドネイティブ分野で進むAI活用は、開発の裾野を広げると同時に、オープンソースを維持する人たちの負担を浮き彫りにしています。企業がAIによる開発効率の向上を考える際には、生成できる量と、責任を持って扱える量を分けて見る必要があります。

Cloud Native Computing Foundation(CNCF)と調査会社SlashDataの最新の「State of Cloud Native Development」によると、世界のクラウドネイティブ開発者は2,100万人を超え、開発者全体の41%を占めています。CNCFは、クラウド環境を前提とする技術やオープンソースの普及を支える団体です。今回の調査結果は、北米の技術イベント「KubeCon + CloudNativeCon NA」で、CNCFとSlashDataの担当者が紹介しました。



CNCFで技術プログラム管理を担当するディレクターのボブ・キレン氏は、2,100万人という数字でも実態を十分に捉えられていない可能性を指摘しています。クラウドネイティブのアプリケーションを使いながら、その基盤を意識していない人も多いためです。

企業にとって、この指摘は人数の上振れ以上の意味を持ちます。自社で基盤を構築する部門だけを見ていては、事業がどの技術に支えられているのかを把握しきれないかもしれません。AI導入の足場を考える出発点は、開発者の肩書ではなく、実際に利用しているサービスと、その背後にある基盤を確かめることにあります。
AI利用率75%と55%の差をどう読むか


調査で目を引くのは、クラウドネイティブ開発者の約75%が何らかの形でAIを利用しているのに対し、それ以外の開発者では約55%にとどまる点です。差は約20ポイントあります。SlashDataの主任市場調査コンサルタント、リアム・ボルマン=ドッド氏は、クラウドネイティブの環境が、組織や開発者による幅広いAI活用を後押ししているとの見方を示しました。

ただし、この数字だけで「クラウドネイティブを採用すればAI導入が進む」と因果関係を断定することはできません。示されているのは、二つの開発者群で利用率が異なるという結果です。組織の技術方針や開発業務の内容など、ほかの条件がどの程度影響しているかまでは、この比較から読み取れません。



「何らかの形でAIを利用」という表現の幅にも注意が必要です。コード作成を支援するツールの利用と、顧客向けAIサービスの運用では、必要な体制も責任も異なります。75%という利用率を、そのまま本番システムへの生成AI導入率や、AIエージェントの導入率として扱うことはできません。

日本企業が自社の状況と比べるなら、利用の有無だけを尋ねるより、用途を分けて確かめるほうが実務に役立つでしょう。個人の作業補助なのか、チームの開発工程に組み込まれているのか、顧客に提供する機能なのか。そうした違いを揃えて初めて、普及の速さと運用の成熟度を区別できます。今回の差は、自社が遅れているかを単純に判定する数字ではなく、AIを使いやすくする条件を点検する手がかりと考えられます。
クラウドネイティブがAIの基盤になる理由


クラウドネイティブは、単にサーバーをクラウドへ移すことを意味する言葉ではありません。一般に、アプリケーションを小さな単位で構成し、配備や更新、稼働状況の把握などを自動化しながら運用する考え方を指します。個々の技術を導入すること以上に、変更を繰り返すための仕組みを整える点に特徴があります。

関連技術のKubernetesは、アプリケーションと実行に必要なものをまとめた「コンテナ」の配置や稼働を管理するオープンソースの仕組みです。AIモデルそのものを提供する技術ではありませんが、AIを組み込んだアプリケーションを動かす基盤として捉えると、その役割を理解しやすくなります。



例えば、外部のAIモデルを呼び出す業務アプリケーションを考えてみます。モデルから回答を得るだけなら小さく試せても、社内で継続利用するには、利用者の認証、障害時の対応、処理状況の監視といった仕組みが必要です。クラウドネイティブの運用で整えてきた仕組みは、こうした周辺の課題にも応用できると考えられます。これはAI利用率の差を説明し得る背景であり、調査が個別に効果を証明したという意味ではありません。

既存の基盤を活用できるとしても、AI特有の確認が不要になるわけではありません。アプリケーションが正常に動くことと、生成された回答が業務上適切であることは別の問題です。基盤の安定性に加え、出力の評価や人による確認をどう組み込むかが問われます。AI導入を検討する企業には、技術の採用だけでなく、運用で引き受ける責任まで設計する視点が求められます。
AIが増やすコードを、誰が確認するのか


AI活用の広がりが直接的な負担として表れているのが、オープンソースのメンテナーによるレビューです。メンテナーは、変更提案を確認し、プロジェクトの品質や方針を維持する役割を担います。キレン氏によると、KubeConに先立つ「Maintainer Summit」では、活動を持続可能にすることが主要な議題になりました。背景には、AIエージェントが生成するものを含め、変更提案や課題報告が大量に届く状況があります。

変更提案は「プルリクエスト」、略してPRと呼ばれます。提案が届けば、その内容が正しいかだけでなく、既存の設計に合うか、ほかの機能を壊さないか、将来も保守できるかを確認しなければなりません。コードを作る側の負担が減っても、受け取る側の確認が同じ割合で軽くなるとは限らないのです。



キレン氏が問題視しているのは、明らかに不適切な提案ばかりではありません。低品質でも、一見すると一定の出来に見える提案は、判断に手間がかかります。もっともらしい説明や整ったコードが付いていれば、問題の有無を確かめるために中身へ踏み込む必要があるでしょう。投稿の量だけで貢献を評価すると、この負担を見落としかねません。

企業が従業員のAI利用を後押しするなら、外部プロジェクトへ送る成果物にも確認責任を持たせることが大切です。変更の必要性を説明できるか、問題を再現できるか、検証結果を示せるか。投稿前にこうした点を確かめる運用は、受け手の時間を尊重する具体策になります。開発速度の向上を社内だけで測るのではなく、利用するオープンソースにどのような作業を生んでいるかまで見る必要があります。
トークン消費量より、成果に対する費用へ


AI運用のもう一つの論点は費用です。ボルマン=ドッド氏は、クラウドの請求額が増えた後に費用管理の実務が発達したのと同様に、モデルの利用料やトークン消費も厳しく管理されるようになると予測しています。トークンは、AIモデルが文章などを処理する際の単位です。言葉や文字を細かく分けたものに相当し、多くのモデルサービスでは利用料金を考える際の基準になります。

同氏は、トークンを大量に使うこと自体を重視する姿勢が終わり、資金とトークンをどう使うかへ関心が移ると述べています。これは今後の方向性に関する同氏の見解であり、企業の費用管理がすでに一様に変わったことを示す調査結果ではありません。



企業の判断では、トークン数の削減だけを目標にしないほうがよいでしょう。短い指示で費用を抑えても、回答の修正や再実行が増えれば、業務全体の負担は軽くなりません。逆に、利用料が多少増えても、確認しやすい成果物が得られ、手戻りを減らせるのであれば、その使い方には合理性があると考えられます。

例えば、コード生成であれば、モデルの利用料に加え、採用できた変更の割合やレビューに要する時間を確認する方法があります。文章作成なら、生成回数だけでなく、担当者が修正して完成させるまでの作業量が判断材料になるでしょう。これらは調査で示された指標ではなく、費用管理を業務へ落とし込む際の考え方です。AIへの支出を評価する単位を「どれだけ使ったか」から「どの成果を、どれだけの総負担で得たか」へ移すことが、次の実務課題になります。
日本企業が点検したい、生成後の作業


今回の調査と両氏の指摘を企業の現場へ引き寄せると、注目すべき対象はAIの利用人数だけではありません。生成された成果物が増えたとき、誰の作業が増え、どこで判断が滞るのかという点です。クラウドネイティブの基盤が整い、AIを使い始めやすくなっていても、レビューや承認に必要な体制まで自動的に整うわけではありません。

導入を進める部門は、AIが作成する工程と、人が受け取って確認する工程を一続きで見る必要があります。コードであれば、生成からテスト、レビュー、採用までを追います。業務文書であれば、下書きの作成から内容確認、修正、承認までが対象です。生成時間だけを測ると、後工程へ移った負担を効率化の成果として数えてしまうおそれがあります。



小さく始めるなら、一つの業務を選び、AI利用前後で同じ範囲の作業を比べる方法が現実的です。モデルの利用料、担当者の確認時間、差し戻しの理由を記録すれば、改善すべき点を具体化しやすくなります。外部のオープンソースへ変更を提案する業務では、社内で確認を終えてから投稿する手順も、その範囲に含めるとよいでしょう。

クラウドネイティブ開発者の約75%がAIを使うという数字は、利用の広がりを示しています。ただし、自社が目指すべき成果を決めてくれる数字ではありません。次の導入判断では、利用者数の目標を置く前に、一つの業務で「生成した後に残る作業」を測ってみてください。AIの出力を増やす投資と、それを確実に受け止める体制への投資を、同じ材料で検討できるようになります。
参考情報


Cloud native is the on-ramp to AI, and maintainers are paying the price

SiliconANGLEが2026年11月12日に公開した、KubeCon + CloudNativeCon NAでのインタビューに基づいています。対談を配信したtheCUBEは、SiliconANGLE Mediaの動画メディアです。当該配信にはThe Linux Foundationがスポンサーとして参加しており、SiliconANGLEはスポンサーに編集権はないと明記しています。

ISM AI CONSULTING

AIを、自社の業務で
使える仕組みに。

ISM株式会社は、システム開発で培った技術と現場理解をもとに、AIの業務活用を支援します。課題の整理から導入・運用まで、貴社に合う進め方を一緒に考えます。

  • 活用テーマの整理
  • 業務への組み込み
  • 導入後の定着
AI活用について相談する

「何から始めるか」のご相談から承ります。

AI LAB 一覧へ戻る