はじめに
こんにちは、クラウド事業部の吉田です。
2026年5月14日～15日に名古屋の中日ホール&カンファレンスで開催された「クラウドネイティブ会議 2026」に現地参加しました。
イベントの様子とセッションの内容を振り返り、学んだことをまとめてみます。
※本記事は、クラウドネイティブ会議 2026 のセッションを現地で視聴したエンジニアが、内容をできる限り客観的に共有することを目的に作成しました。
クラウドネイティブ会議とは？
CloudNative Days、Platform Engineering Kaigi、SRE Kaigiの3つのコミュニティにより合同開催されたカンファレンスです。
クラウドネイティブ技術、SRE、プラットフォームエンジニアリングの3つの領域をテーマにそれぞれのコミュニティが培ってきた知見を集め、領域を超えた若手からベテランのエンジニアといった幅広いエンジニアを対象とした対話と学びの場をつくることを目的としたイベントです。
会場について
クラウドネイティブ会議は名古屋市の中日ホール＆カンファレンス(中日ビル6F)にて開催されました。
会場内では、3つのセッションルームとブースコーナーが用意されていました。
さらにアンケートコーナーも用意され、「興味のある技術領域」やイベントへどこの地方からきたかなどの展示もあり、参加者が実際に利用しているツールや技術トレンドを知ることができました。
セッションでは、たくさんの人が参加しており、現地参加ならではの盛り上がりを感じました。
セッション振り返り
現地で実際に参加したセッションの中から、特に印象に残った内容を紹介します。
セッション1： 実践AI SRE — AIワークロードの自律的パフォーマンスエンジニアリング
本セッションでは、AIワークロード特有の性能課題に対し、従来のSREの考え方をAIで拡張し、検知・分析・改善・計測を自律的に回していく「AI SRE」やパフォーマンスエンジニアリング（PE）の取り組みについて、実際のデモを交えながら紹介されていました。
特に印象に残ったのは、AIワークロードでは従来のシステム性能改善と異なり、「どこがボトルネックなのか特定すること自体が難しい」という点です。
学習や推論ではGPUが中心となるため、CPU中心の監視と比較して可観測性が低く、プロファイリング情報も限定的になりやすい。さらに、取得できた情報量が膨大であっても、そこから原因を特定し改善へつなげるには高度な専門知識が必要との説明がありました。
デモ実演では、さくらインターネットの高火力シリーズを用いたGPUノード上の情報を継続収集し、性能劣化を検知すると対象Podを特定し、一時コンテナを起動してGPUプロファイリングを実施する仕組みが実演されました。
AIを用いてAIワークロードを最適化する取り組みとして、Stable Diffusionのファインチューニングを対象とした事例では、人手による改善と比較してAIエージェントによる自律的な改善の方が大幅な性能向上を実現しているデータが出ているとのことで、AIを利用してAIワークロードを最適化する流れが実用段階に入りつつあることを感じました。
印象的だったのは、「観測なくして改善なし」という考え方です。
AIによる自律改善に注目が集まりがちですが、その前提として適切なモニタリングやプロファイリングによって十分なコンテキストを取得できていることが重要であり、入力データの質や粒度が改善結果を左右するという点は納得感がありました。
また、AIエージェントが強力になるほど、認証・認可を含めた制御や安全性も同時に考慮する必要があるという話も印象に残っています。
単純な性能改善だけでなく、運用・セキュリティまで含めて設計する重要性を改めて感じる内容でした。
セッション2：一人SREが歩んだ Platform Engineering スモールスタート実践録
本セッションでは、SRE専任やPlatformチームが存在しない環境の中で、一人のエンジニアが課題解決のためにPlatform Engineeringへ取り組み、約3年間かけて開発者体験や生産性向上につなげていった実践事例が紹介されました。
「SREは信頼性向上を目指し、Platform Engineeringは開発者体験向上を目指すが、トイル削減という点では重なる」という整理も非常に分かりやすく感じました。
特に印象的だったのは、Platform Engineeringを最初から目的化するのではなく、「CI/CD改善」「権限管理」「問い合わせ削減」といった現場課題への対応を積み重ねた結果としてPlatform Engineeringに到達していた点です。
大規模組織だけの手法ではなく、小規模チームでも開発者体験向上を目的に段階的に実践できるという示唆は、自社環境へ置き換えて考える上でも参考になりました。
また、中でも興味深かったのは、Slack BotとAIを組み合わせた権限管理のセルフサービス化です。
自然言語で必要なIAM権限を問い合わせるとAIが適切な権限を提案・付与する仕組みは、単なる自動化ではなく「認知負荷を減らす」というPlatform Engineeringらしいアプローチだと感じました。
Platform Engineeringを特別なものとして捉えるのではなく、まずは身近な課題改善から始め、小さな改善を積み重ねていく重要性を感じたセッションでした。
セッション3：Terraformモジュールはなぜ「魔境」化するのか
本セッションでは、Terraformモジュールがなぜ複雑化し、「誰も触りたくない状態（魔境）」へ陥ってしまうのかについて、その原因と設計の考え方が紹介されました。 特に印象に残ったのは、「DRY原則＝コード重複をなくすこと」という理解が誤りであり、本来は「知識を重複させない」という考え方であるという説明です。
Terraformではアプリケーションコードと異なり、「処理」ではなく「状態」を記述することから、一見同じS3バケットであっても、ログ保存用・監査用・コンテンツ配信用など用途やライフサイクルが異なれば、実際には別の知識として扱うべきという考え方は非常に納得感がありました。 これまで「同じリソースだから共通化した方が良い」と考えがちでしたが、無理な共通化によって変数が増え、結果的に利用者・管理者双方の認知負荷を高めてしまうという指摘は印象的でした。
さらに、「Terraformモジュールは再利用性を高めるために作るもの」ではなく、「ある概念や責務を表現するために作るもの」という考え方も興味深かったです。
モジュール化を進める際、共通化できそうな部分から考え始めることは多いですが、本来は「このモジュールは何を表現し、誰のために存在するのか」を先に定義することが重要だと感じました。
TerraformやIaCの運用では、機能追加や拡張を繰り返す中で徐々に複雑化しがちですが、今回のセッションは「なぜその複雑さが生まれるのか」を整理して理解する良い機会になりました。
今後モジュール設計を行う際には、単純な共通化だけでなく、利用者や責務を意識して設計を考える必要があると感じたセッションでした。
まとめ
クラウドネイティブ会議では、企画展示やセッションを通じて、単に新しい技術やツールを導入するだけではなく、「運用課題や開発現場の困りごとをどう継続的に改善していくか」という考え方や取り組みについて学ぶことができました。
また、会場内の交流企画やスポンサー企業ブースを通して、参加者や企業が実際に取り組んでいる技術・課題感にも触れることができ、現地参加ならではの熱量を感じられるイベントだったと思います。
今回の参加を通じて、最新技術だけでなく現場での実践や考え方にも触れることができ、非常に学びの多い時間となりました。 イベントのエンディングでは次回開催の案内もあり、機会があればぜひ参加し、最新技術や実践知見を継続的にキャッチアップしていきたいと感じました。
最後までお読みいただきありがとうございました。
