はじめに
こんにちは。プラットフォームSREブロックの酒部・高塚・亀井です。私たちは2026年5月14日〜15日に名古屋で開催された「クラウドネイティブ会議」に参加してきました。本記事では印象に残ったセッションをご紹介します！
クラウドネイティブ会議とは
クラウドネイティブ会議は、CloudNative Days、Platform Engineering Kaigi、SRE Kaigiという3つの大規模テックイベントで合同開催されたカンファレンスです。現地参加とオンライン参加のハイブリッド形式で開催され、会場の名古屋・中日ホール＆カンファレンスには約1,000人が集まりました。
当日の様子は公式のXのポストまとめで見ることができます。現地の雰囲気を感じることができるので、ぜひご覧ください。
セッションレポート
ここからは各メンバーからのセッション紹介をお届けします。
キーノート：老舗IoTクラウドサービス組織の変革 -クラウドネイティブをはじめよう-
高塚です。1日目のキーノートでは、パナソニックさんの事例として、巨大なモノリスだった老舗IoTサービスをマイクロサービス化した熱い話を聞くことができました。
見切り発車でマイクロサービス化を始めたものの、最初は問題が山積みだったとのことです。
かなり昔からあるAWSアカウントでしか見られない「ap-northeast-1b」アベイラビリティゾーンがあった話では会場もざわざわしていました。
GitLabの導入は、社内から「Gitを使うなんて危険だ、けしからん」という声も上がるなど「正直ここが一番しんどかった部分」だったそうです。しかし、そういった意見を軽々しく否定せず、既存のシステムがお客様に価値を提供してきたことに敬意を持ちながらクラウドネイティブ化を進めたそうです。
その結果、無事に本番稼働させることができました。
後半ではIoT特有のE2Eトレーシングについて紹介がありました。
組み込みデバイスはCPU・メモリが限られており、スパン送信による性能劣化を避けるため、OpenTelemetry SDKは利用せずにトレーシングを自前実装したとのことです。
また、IoTデバイスはネットワークやOSなどの問題が障害の原因になりやすいため、eBPFでカーネルイベントもスパンにしたそうです。
約30分の発表はとても濃い内容で、大変勉強になりました。また私もZOZOTOWNのマイクロサービス化を長年担当しているため、発表で赤裸々に語られる苦労話には「わかりみが深い〜」と100回くらい頷いていました。
本記事では主に技術的な話をご紹介しましたが、組織の文化を醸成する話や「これからクラウドネイティブをはじめる方へのメッセージ」などとても学びになる内容が盛りだくさんですので、ぜひアーカイブ動画をご覧ください。
GameDay：チームで挑むリアルな障害対応
酒部です。GameDayはKubernetes環境上で発生するさまざまな障害シナリオに対して、チームで協力して原因を特定し、復旧させるという内容でした。参加者にはKubernetes上で稼働するアプリケーション環境が提供され、その環境にはあらかじめ障害が仕込まれており、クエスト形式で出題される問題を解きながら、システムを正常な状態に復旧させていくという形式でした。
形式は約2時間のチーム対抗戦で、Kubernetes初心者から経験者まで幅広い層が集まっていました。ルールはシンプルで、障害を復旧することでスコアが加算され、最終的にチーム単位で順位が決まる仕組みです。
困ったときに相談できるメンターがサポートしてくれる体制に加え、行き詰まっても段階的なヒントで前に進める仕組みも用意されており、勝負というよりもチームで協力して問題に取り組む過程が重視されているように感じました。
題材として用意されていたのは、OpenTelemetry DemoをベースとしたECサイトのマイクロサービス構成です。各チームにCode Server、Grafana、Jaeger、Argo CD、GitHubリポジトリが一式与えられました。基本フローは障害を発見 → GitHub上で修正 → commit & push → Argo CDが自動同期 → Verifierによって各問題の合否判定する流れです。
問題の内容や解説は下記の公式記事に解説があるため、そちらをご覧ください。
結果としては、最後の問題だけ時間内に解くことができませんでした。ただ、作問者が解かせるつもりで作っていないと言うほどの難問で、ほとんどのチームが解けていなかったので、終了後残り時間で会場でも簡単な解説をしていただきました。解説後、会場のあちこちから「そういうことだったのか」「やられた」といった声が漏れ、参加者全員が思わず唸ってしまうような巧妙な問題設計だったことが印象に残っています。
観察・操作系のチュートリアル問題も用意されていて、Kubernetesに触り始めたばかりの方でも問題なく楽しめる内容で、自信を持っておすすめできるプログラムでした。
100マイクロサービスのTerraform/Kubernetes管理地獄から抜け出すためのAI活用術
酒部です。このセッションでは膨大なTerraformやKubernetesマニフェストファイルを扱う構成において、日々の運用をAIエージェントでどう解決するかがテーマでした。
セッションは大きく4パートで構成されており、以下のトピックが扱われました。
- Linear × Codexで全マイクロサービスのTerraform / K8s manifest更新を効率化
- AIによるレビューで200 PR/dayの50％を自動化
- 問い合わせ・トラブルシューティングをAIに任せる試み
- Production Readiness Check（PRC）のEvidence確認もAIにやってもらう
特に、2と4は弊チームと似た取り組みも紹介されており大変興味深い内容でした。
まず、PRレビューへのAI活用について、Notionに整理されたガイドラインがあるのに、サービス・人数の増加で存在を知らない人が増え、結果としてガイドラインが守られないという課題がありました。
解決アプローチはガイドラインをAIエージェントが利用できる形でリポジトリに降ろすというものです。Notionは引き続きSoT（Source of Truth）として残しつつ、AIレビュー用のコンテキストはリポジトリに固定する設計としました。
紹介されていた実例では、Codex ReviewがIAM設定の重複を「社内ガイドライン違反」として指摘し、参照したガイドラインのファイルパスまで引用していました。一般論ではなく、社内ルールに照らした具体的な指摘ができている点が印象的でした。AIに指摘されない部分こそが暗黙知であるという気づきから、「AIが指摘してこない部分」を観察することで、ドキュメント化されていない暗黙知が浮かび上がってくる、というメタな視点が学びになりました。
本番リリース前のProduction Readiness Check（PRC）の自動化ですが、開発者はEvidenceを集め、SREはその妥当性をチェックするという、両者にとって骨の折れるプロセスがあるそうです。ここで、いきなりAIに丸投げするのではなく、AIに任せるべき項目を選定したり、Code化できる項目はCIで自動チェックしたりするなど工夫されていました。
また、AIに任せるためフォーマットを整理する過程で、以前はやや解釈が難しいPRC項目もあったが、自動化に向けて解釈がブレないようにしたという副次効果も語られていました。AI活用のためのドキュメント整備が、人間にとっても理解しやすいドキュメント整備につながるという気づきがありました。
セッション全体として、AIに使わせるために何を整えるかが重視されており、共感する内容も多かったです。弊チームでもGitHub Actions上でAIレビューを動かしていますが、Kyverno Policyで機械的に守れるルールはPolicyに、非決定論的な項目はAIレビューに任せるという棲み分けをとっています。また、AIレビューに渡す情報も何を入れるかと同じくらい何を入れないかが重要だと再認識しました。チームでも、AIが解釈しやすい形にドキュメントやタスクを整えるということを意識していきたいと思いました。
巨大組織の認知負荷をどう下げるか？ソフトバンクが描くCNAP×Backstageによるクラウドネイティブの新時代
亀井です。クラウドネイティブ化が進むほど、クラウド、Kubernetes、CI/CD、ドキュメント、申請フローなどの選択肢や情報が増え、開発者の認知負荷は高まっていきます。
ソフトバンクさんでは、共通基盤「CNAP」によって、GitOps、自動化、ローコードパッケージ、マルチクラウド対応を提供し、インフラの作り方を標準化していました。
一方で、GitOpsだけでは誰もが迷わず使える状態にはならず、GUIで直感的に操作できる入口としてBackstageを導入した点が印象的でした。Backstageでは、サービスやドキュメントの「見える化」と、アカウント、権限、リソース申請などの「自動化」を実現していました。特にAzureアカウント申請の例では、申請、承認、権限付与、通知までをBackstage上で標準化し、手動の対応工数を大きく削減していたのが具体的で分かりやすかったです。
ただし、アカウント設計、SSO連携、既存ドキュメントサイトとの連携、PluginとCustom開発の見極めなど、運用して初めて見える課題も共有されていました。「Backstageは銀の弾丸ではない」という点も重要で、作って終わりではなく、情報と業務導線をつなぎ、改善を回し続ける設計が必要だと感じました。
後半では、Agentic DevOps時代に向けて、BackstageがAIエージェントに組織のコンテキストやガードレールを渡す基盤になり得るという話がありました。TechDocs、Software Template、Software Catalog、catalog-info.yamlといった機能は、人間の認知負荷を下げるだけでなく、AIに正しい文脈を渡すうえでも有効そうです。
CNAPが「安全で標準化された実行基盤」、Backstageが「迷わず使える入口」として役割分担し、両者を連携させることで、使われ続けるPlatform Engineeringに近づけるという学びがありました。
生成AI時代に信頼性をどう保ち続けるか - Policy as Codeの実践
亀井です。このセッションでは、サービス成長やマルチプロダクト化、生成AI活用による開発量の増加に対して、信頼性をどうスケールさせるかがテーマでした。キャディさんではProduction Readiness Checklist（PRC）を定義し、信頼性、可用性、セキュリティ、完全性、運用性、オブザーバビリティをGAの必須条件としていました。
しかし、SREがPRCを目視レビューする運用は、プロダクト数やチェック項目が増えるにつれて限界を迎え、人によるレビューがボトルネックになっていました。その解決策として、Manual ChecklistをPolicy as Codeに置き換え、手動で属人的な確認から、自動で安定したガードレールへ移行していました。具体的には、Terraform planの結果をConftestとRegoで検証し、KubernetesマニフェストはKyverno CLIでチェックするなど、CI上でシフトレフトしていました。
さらに、Google Cloud Organization Policyを使い、CIを通らない手動操作もAPIレベルで遮断する多層防御の考え方が紹介されていました。印象的だったのは、Policy自体にもテストCIを組み込み、Positive Test、Negative Test、Context Mockingで、誤検知や過剰検知を防ぐ品質管理をしていた点です。
ポリシー記述は生成AIに任せつつ、品質はテストで支えるという考え方は、生成AI時代らしい現実的なアプローチだと感じました。
また、既存負債に対しては警告通知、全件トリアージ、段階的強制、エラー通知という流れで進め、単にブロックするのではなく、SREが自ら主導してEnableする姿勢が印象的でした。検知結果に修正例や除外方法へのリンクを付ける、除外ポリシーをCentral SREが管理する、変更ファイル単位で最小限にチェックするなど、形骸化させないための泥臭い工夫に学びがありました。
おわりに
普段ZOZOTOWNのプラットフォームを管理するチームとして共感する内容が多く、規模やフェーズが違っても各社が同じような問題意識を持って取り組んでいることが強く印象に残りました。
また、GameDayや公式の懇親会などで、セッション以外の企画でも他社のSREやプラットフォームエンジニアの方々と直接交流できたのは、現地参加ならではの大きな価値でした。
今回のカンファレンスで得た知見と刺激を活かして、自分たちの基盤をより使いやすく、より安全に進化させていきたいと思います。そして、自分たちの取り組みや学びを引き続きたくさんアウトプットしていきたいと思っております。
ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。
