[{"data":1,"prerenderedAt":267},["ShallowReactive",2],{"blog-ja-kubernetes-ai-inference-reversal-conformance-design":3,"blog-related-ja-kubernetes-ai-inference-reversal-conformance-design":218,"blog-ja-kubernetes-ai-inference-reversal-conformance-design-alt":207},{"id":4,"title":5,"author":6,"body":7,"date":201,"description":202,"extension":203,"image":204,"locale":205,"meta":206,"navigation":207,"path":208,"seo":209,"stem":210,"tags":211,"__hash__":217},"blog\u002Fblog\u002Fja\u002Fkubernetes-ai-inference-reversal-conformance-design.md","推論が学習を逆転した。KubeCon Japanで語られた、AI時代のKubernetesクラスタ設計指針","Kubo Team",{"type":8,"value":9,"toc":192},"minimark",[10,15,19,26,36,50,59,62,66,69,75,84,93,96,100,108,114,122,137,140,144,147,153,160,173,176,179],[11,12,14],"h2",{"id":13},"学習中心だったai計算需要が静かに逆転している","「学習中心」だったAI計算需要が、静かに逆転している",[16,17,18],"p",{},"Kubernetes AI推論という言葉を、この1年でよく見かけるようになったと感じていないでしょうか。KubeCon + CloudNativeCon Japan 2026の基調講演でも、CNCFの関係者がAIコンピューティング配分の変化について語っていました。数年前まで、AI関連の計算資源の大半はモデルの「学習（トレーニング）」に投じられていましたが、今その主役は「推論（インフェレンス）」に移りつつあります。",[16,20,21],{},[22,23],"img",{"alt":24,"src":25},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-ai-inference-reversal-conformance-design\u002Fsection01.webp",[16,27,28,35],{},[29,30,34],"a",{"href":31,"rel":32},"https:\u002F\u002Fbuild.inc\u002Finsights\u002Ftraining-vs-inference-data-center-design-differences",[33],"nofollow","データセンター需要に関する分析","によれば、AI推論向けの計算能力は2030年までに90ギガワット超（年平均成長率35%）に達すると予測されています。McKinseyの試算はさらに具体的で、AI学習向けのデータセンター需要は2025年の23.1ギガワットから2030年に62.2ギガワット（年平均成長率22%）へ拡大する一方、推論向けの需要は同じ期間で20.9ギガワットから93.3ギガワット（年平均成長率35%）へと急拡大するとされています。2030年時点で、推論はAI計算全体の半分以上を占め、学習を上回る最大のワークロードになる見込みです。",[16,37,38,39,44,45,49],{},"同様の傾向は他の調査でも指摘されています。",[29,40,43],{"href":41,"rel":42},"https:\u002F\u002Favidsolutionsinc.com\u002F13-data-center-growth-projections-that-will-shape-2026-2030\u002F",[33],"データセンター動向の分析記事","では、Deloitteの推計として「2025年時点で推論がAI計算全体の半分を占め、2026年には3分の2に達する」という見立てが紹介されており、Brookfieldの予測では2030年までに推論がAI計算需要の75%を占めるとされています。数字に幅はあるものの、方向性は一致しています。",[46,47,48],"strong",{},"学習中心で設計されたインフラは、もう前提が崩れている","ということです。",[16,51,52,53,58],{},"これだけの規模でワークロードの主役が入れ替わるとなると、これから基盤を選ぶ・見直す企業にとっては、コスト効率とベンダーロックイン回避を両立できるかどうかが重要な判断軸になっていきます。実際、",[29,54,57],{"href":55,"rel":56},"https:\u002F\u002Fkubo.hexabase.io\u002F",[33],"Kubo","のようなK3sベースのマネージドKubernetesを検討する動きも出てきています。",[16,60,61],{},"この変化が厄介なのは、学習と推論ではインフラに求められる性質がまったく異なる点です。次の章では、その違いがKubernetes運用にどう跳ね返ってくるかを見ていきます。",[11,63,65],{"id":64},"推論ワークロードはなぜkubernetesを作り直させるのか","推論ワークロードはなぜKubernetesを\"作り直させる\"のか",[16,67,68],{},"学習ジョブは基本的にバッチ処理です。数時間から数日かけて一度に大量のGPUを使い切り、終われば解放する。一方、推論ワークロードは常時稼働が前提で、リクエスト数に応じて秒単位・分単位でスケールし、レイテンシの悪化がそのままユーザー体験の悪化に直結します。学習用に最適化されたスケジューリングやリソース管理の仕組みを、そのまま推論に流用すると無駄が生まれやすいのです。",[16,70,71],{},[22,72],{"alt":73,"src":74},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-ai-inference-reversal-conformance-design\u002Fsection02.webp",[16,76,77,78,83],{},"この課題に対応するため、Kubernetes本体にも推論向けの機能追加が進んでいます。代表例が「In-Place Pod Resize」です。",[29,79,82],{"href":80,"rel":81},"https:\u002F\u002Fkubernetes.io\u002Fblog\u002F2025\u002F05\u002F16\u002Fkubernetes-v1-33-in-place-pod-resize-beta\u002F",[33],"Kubernetes公式ブログ","によると、この機能はPodを再起動せずにCPU・メモリのリクエスト\u002Fリミットを変更できるもので、v1.33でベータ昇格・デフォルト有効化されました。推論サービングでは、起動直後は高いCPUを必要とし、その後は低い水準で安定するようなケースが多く、再起動なしでリソース調整できることは可用性に直結します。",[16,85,86,87,92],{},"さらに、",[29,88,91],{"href":89,"rel":90},"https:\u002F\u002Fopensource.googleblog.com\u002F2026\u002F04\u002Fkubernetes-goes-ai-first-unpacking-the-new-ai-conformance-program.html",[33],"Google Cloudのブログ","では、推論・学習双方に対応するための技術要素として、GPU\u002FTPUをきめ細かく制御する「Dynamic Resource Allocation（DRA）」、分散学習ジョブがリソースを揃うまで待機する「All-or-Nothing Scheduling」、GPU使用率などのカスタムメトリクスに基づくオートスケーリング、アクセラレータの標準化された可観測性の4点が紹介されています。いずれも、Kubernetesが「コンテナオーケストレーター」から「AIワークロード基盤」へと役割を広げつつあることを示しています。",[16,94,95],{},"こうした機能拡張が個々のクラウドやディストリビューションでバラバラに実装されると、結局は「動く環境」が限定されてしまいます。そこで動き出したのが、CNCFによる標準化の取り組みです。",[11,97,99],{"id":98},"cncfのai-conformance-programは何を保証しようとしているのか","CNCFの「AI Conformance Program」は何を保証しようとしているのか",[16,101,102,107],{},[29,103,106],{"href":104,"rel":105},"https:\u002F\u002Fwww.cncf.io\u002Fannouncements\u002F2025\u002F11\u002F11\u002Fcncf-launches-certified-kubernetes-ai-conformance-program-to-standardize-ai-workloads-on-kubernetes\u002F",[33],"CNCFの公式発表","によると、Certified Kubernetes AI Conformance Programは2025年6月のKubeCon Japanでベータ版が発表され、同年11月11日のKubeCon North America（アトランタ）で正式ローンチされました。目的は明確で、AIワークロードの相互運用性と移植性を確保し、ベンダー間の断片化を減らすことです。AWS、Google Cloud、Microsoft Azure、Oracle、Red Hatなど主要クラウドがすでに認証プラットフォームとして参加しています。",[16,109,110],{},[22,111],{"alt":112,"src":113},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-ai-inference-reversal-conformance-design\u002Fsection03.webp",[16,115,116,121],{},[29,117,120],{"href":118,"rel":119},"https:\u002F\u002Fwww.forbes.com\u002Fsites\u002Fjanakirammsv\u002F2025\u002F11\u002F18\u002Fcncf-establishes-standards-for-running-ai-workloads-on-kubernetes\u002F",[33],"Forbesの解説記事","では、このプログラムが生まれた背景として「82%の組織が独自のAIソリューションを構築しており、うち58%がKubernetesを利用している」という調査結果を挙げ、プラットフォーム間の互換性不足がベンダーロックインのリスクを高めていたと指摘しています。認証を受けたプラットフォーム間であれば、あるKubernetes環境で動作確認したAIアプリケーションが、別の認証環境でも同じように動作することが期待できるわけです。",[16,123,124,125,130,131,136],{},"プログラムの要件も年々厳格化しています。",[29,126,129],{"href":127,"rel":128},"https:\u002F\u002Fcloudnativenow.com\u002Ffeatures\u002Fcncf-expands-efforts-to-run-ai-inference-workloads-on-kubernetes-clusters\u002F",[33],"Cloud Native Nowの報道","によれば、2026年のKubeCon Europeでは認証基準「Kubernetes AI Requirements（KAR）v1.35」が発表され、先述のIn-Place Pod Resizeの安定版対応とWorkload-Aware Schedulingが必須要件に追加されました。同時にOVHcloud、SpectroCloud、JD Cloud、China Unicom Cloudなど新プラットフォームが認証を取得し、認証プラットフォーム数は31まで増加しています。CNCFのJonathan Bryce氏は「AI推論ワークロードは近い将来、Kubernetesクラスタ上で動く他のあらゆるワークロードクラスを圧倒するようになるだろう」と述べており、詳細な要件定義は",[29,132,135],{"href":133,"rel":134},"https:\u002F\u002Fgithub.com\u002Fcncf\u002Fk8s-ai-conformance",[33],"GitHub上のリポジトリ","で公開が進んでいます。",[16,138,139],{},"つまりCNCFが目指しているのは、「推論ワークロードが急増しても、環境を選ばず一貫した挙動で動かせる」という状態です。この方向性は、そのままマネージドKubernetesを選ぶ際の判断基準にもなります。",[11,141,143],{"id":142},"マネージドk3s環境は推論時代のインフラ要件にどう向き合うべきか","マネージドK3s環境は推論時代のインフラ要件にどう向き合うべきか",[16,145,146],{},"ここまで見てきた変化を整理すると、推論時代のインフラに求められる条件は大きく3つに集約できます。1つ目は、GPU使用率や推論レイテンシといったAI固有の指標に基づくオートスケーリング。2つ目は、アクセラレータのメトリクスを標準化された形で可視化する可観測性。3つ目は、特定のクラウドやディストリビューションに縛られない可搬性、つまりベンダーロックインの回避です。",[16,148,149],{},[22,150],{"alt":151,"src":152},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-ai-inference-reversal-conformance-design\u002Fsection04.webp",[16,154,155,156,159],{},"この3条件は、EKSやAKSのようなフルマネージドサービスを単体で使う場合、コストとロックインのトレードオフに悩まされやすい領域です。K3sベースのマネージドKubernetesである",[29,157,57],{"href":55,"rel":158},[33],"は、標準準拠のPure Kubernetesを採用しているためCNCFが目指す「環境間の一貫性」と相性がよく、Prometheus+Grafana標準搭載により、アクセラレータのメトリクス可視化もそのまま土台にできます。",[16,161,162,163,166,167,172],{},"推論ワークロードの多くはAIエージェントやMLOpsパイプラインの一部として動いています。こうした自律的なワークロードの運用まで見据えるなら、",[29,164,57],{"href":55,"rel":165},[33],"の上で",[29,168,171],{"href":169,"rel":170},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fcaptain-ai\u002F",[33],"Captain.AI","のようなAIエージェント実行基盤を組み合わせる構成も選択肢になります。GitOps対応やHelmチャート対応が標準搭載のため、推論サービスのデプロイパイプラインを一から構築し直す必要もありません。",[11,174,175],{"id":175},"まとめ",[16,177,178],{},"AI計算需要は「学習中心」から「推論中心」へと逆転しつつあり、2030年には推論の計算能力が学習を大きく上回るという予測が複数の調査機関から示されています。Kubernetesはこの変化に対応するため、In-Place Pod ResizeやDynamic Resource Allocationといった推論特化の機能を取り込みながら、CNCFのAI Conformance Programを通じて「どの環境でも同じように動く」標準化を進めています。",[16,180,181,182,185,186,191],{},"この流れを踏まえると、これからのクラスタ設計に必要なのは、推論特有のメトリクスに基づくオートスケーリング、可観測性、そして特定ベンダーに縛られない可搬性の3点です。堅牢なインフラを一から構築する余力がない企業にとって、K3sベースで標準準拠、かつコスト効率に優れた",[29,183,57],{"href":55,"rel":184},[33],"は、推論時代のワークロードを支える基盤として現実的な選択肢になるはずです。まずは",[29,187,190],{"href":188,"rel":189},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[33],"お問い合わせ","から、自社の推論インフラの現状を整理してみてはいかがでしょうか。",{"title":193,"searchDepth":194,"depth":194,"links":195},"",2,[196,197,198,199,200],{"id":13,"depth":194,"text":14},{"id":64,"depth":194,"text":65},{"id":98,"depth":194,"text":99},{"id":142,"depth":194,"text":143},{"id":175,"depth":194,"text":175},"2026-08-01","AI計算需要は学習から推論へ逆転し、2030年には推論の計算能力が学習の1.5倍に達すると予測される。KubeCon Japanの議論とCNCF AI Conformance Programから、Kubernetes\u002FK3sクラスタが備えるべき設計指針を解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-ai-inference-reversal-conformance-design\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fkubernetes-ai-inference-reversal-conformance-design",{"title":5,"description":202},"blog\u002Fja\u002Fkubernetes-ai-inference-reversal-conformance-design",[212,213,214,215,216],"kubernetes","k3s","ai-inference","cncf","managed-kubernetes","exj4Hf68tlZERV4TSYdn_kA7kPWshZJjWZxR0F9_FYs",[219,227,235,244,252,259],{"path":220,"title":221,"description":222,"date":223,"tags":224},"\u002Fblog\u002Fja\u002Fcncf-graduated-project-oss-selection-criteria","CNCFの『卒業』ロゴを信じていいのか。TOC公開議事から見えた、審査の地味な実態とOSS選定基準","CNCFの「卒業（Graduated）」ロゴは安全証明ではない。TOC公開会議の議事から見える審査の実態と、Sandbox・Incubating・Graduatedの基準・タイムラインを解説し、本番導入前にOSSの成熟度を見極める視点を紹介する。","2026-07-23",[215,212,213,225,216,226],"oss","governance",{"path":228,"title":229,"description":230,"date":231,"tags":232},"\u002Fblog\u002Fja\u002Fk3s-harbor-private-registry-docker-hub-rate-limit","Docker Hubの無料枠が凍りついた朝、K3sクラスタは静かに詰む。Harborを自前で持つべきタイミング","Docker Hubのpull rate limitで本番K3sクラスタのイメージ取得が止まるリスクが現実味を増している。CNCF卒業プロジェクトHarborを自前運用する設計判断と隠れたコストを解説する。","2026-08-23",[213,212,233,234,215],"harbor","container-registry",{"path":236,"title":237,"description":238,"date":239,"tags":240},"\u002Fblog\u002Fja\u002Fkubernetes-cost-management-eks-aks-billing-visibility","EKSの請求書は月末にならないと読めない。Kubernetesのコストが『後から分かる』構造的な理由","EKS\u002FAKSのKubernetesコストはなぜ想定外に膨らむのか。オートスケールとクロスAZ課金がコストを見えなくする構造を分解し、K3sベースのマネージドインフラで固定費化する方法を解説します。","2026-08-22",[213,212,241,216,242,243],"cost-optimization","aks","finops",{"path":245,"title":246,"description":247,"date":248,"tags":249},"\u002Fblog\u002Fja\u002Fkubernetes-operations-specialization-managed-k3s-hiring","eBPFもcert-managerもService Meshも。Kubernetes運用がひとりのエンジニアの手に負えなくなった理由","Kubernetes運用の求人がなぜ埋まらないのか。原因はツール知識の不足ではなく、専門分野が広がりすぎたことにある。採用で埋めるのではなく基盤に吸収させる、マネージドK3sという解決策を解説する。","2026-08-21",[213,212,216,250,251],"devops","platform-engineering",{"path":253,"title":254,"description":255,"date":256,"tags":257},"\u002Fblog\u002Fja\u002Fcncf-project-maturity-graduation-criteria-production","GitHubスター1万は『卒業証書』にならない。KubernetesでCNCFプロジェクトを選ぶ基準はコミット数ではなく成熟度ステージ","Kubernetesの技術選定でCNCFプロジェクトを採用する際、GitHubスター数や知名度だけで判断していないか。Sandbox\u002FIncubating\u002FGraduatedという成熟度基準とHarborの事例から、本番導入前に確認すべき基準を解説する。","2026-08-19",[213,212,215,258,234],"oss-governance",{"path":260,"title":261,"description":262,"date":263,"tags":264},"\u002Fblog\u002Fja\u002Fkubernetes-ebpf-inspektor-gadget-observability","strace禁止、sidecar禁止、それでも診断できる。KubernetesをeBPFで透視するInspektor Gadgetという回答","特権コンテナもsidecarも追加できない本番Kubernetesで、Podの通信とシステムコールをどう診断するか。eBPFツール「Inspektor Gadget」の仕組みと2026年の最新動向を解説する。","2026-08-15",[213,212,265,266,215],"ebpf","observability",1787649512374]