クラウドネイティブ会議にダブルスポンサー（ブース・懇親会）で参加しました！

はじめに

こんにちは、株式会社スタメン、プラットフォーム部の勝間田です！

5月14日・15日に名古屋の中日ホールで開催された「クラウドネイティブ会議」に参加してきました！私自身、今年からプラットフォーム部に配属となり、日々の業務でSREやプラットフォームエンジニアリングに携わることが増えました。今回は、各領域の知見を吸収し、現地での参加者との交流を通して、これからの業務に活かせるヒントを得られればと思い参加してきました。この記事では、当日の会場の様子や、弊社のブース企画で行ったアンケートの結果、現地で聞いたセッションの学びについてまとめたいと思います。

クラウドネイティブ会議とは

クラウドネイティブ会議は、「CloudNative Days」「Platform Engineering Kaigi」「SRE Kaigi」の3つのコミュニティが合同で開催したカンファレンスです。

kaigi.cloudnativedays.jp

会場の様子

今回のカンファレンスは、現地参加者 684名、オンライン視聴者 998名と、平日にも関わらずたくさんの方が参加されていたようです！会場には、いくつかのアンケートボードがありました！(撮影したのはカンファレンス終了間際です)

名古屋での開催ということもあり、中部・関東圏からの参加者が目立ちましたが、関西やそれ以外の遠方から足を運んでいる方も多く、注目度の高さが伺えました。

オブザーバビリティツールについては、Datadog が最も多かったものの、GrafanaやNew Relicなど他のツールも広く使われており、大きく一強というよりは各社のニーズに合わせて選定されている印象でした。一方で、CI/CDツールについては GitHub Actions の使用率が圧倒的で、標準的な選択肢になっていることを改めて確認しました。

また、個人的に注目していたコーディングエージェントの利用状況では、Claude Code が一歩抜け出している様子でした。ブースで他社のエンジニアとお話ししていても Claude Code を利用しているとの声が多かったです！スタメンでは、現在プロダクトメンバーには Claude Code と GitHub Copilot を配布しており、各々状況に合わせて活用しております。

懇親会では弊社CTOの野口がスポンサーLTで登壇しました。

ブースアンケートの結果

スタメンは今回ブースを出展させていただき、お越しいただいた皆さんに「お仕事のタイプ」と「AIの活用方法」についてのアンケートをお願いしました。ご参加いただいた皆様ありがとうございました！結果は以下の通りでした。 (目で数えたので、数に間違いがある可能性があります...)

「あなたのお仕事はどのタイプ？」の結果

技術の探検家（新しいツールや技術を試すのが好き）：39
理論の伝道師（アーキテクチャやベストプラクティスを追求する）：36
安定の守護神（システムの安定性と信頼性を第一に考える）：32
現場の改革者（レガシーな環境をモダンに変えようと奮闘中）：30

クラウドネイティブ会議ということもあって、安定性やアーキテクチャに強みを持っていたり、関心が高かったりする方が多いのが印象的でした。また、現場でレガシーな環境と戦っている方も少なくなく、共感する部分も多かったです。

「あなたのAI活用はどのタイプ？」の結果

効率の魔術師（定型作業を撲滅してプロセスを徹底自動化）：53
爆速の開拓者（圧倒的なスピードと生産性で開発する）：45
価値の演出家（今までにないプロダクト価値や事業成長を生み出す）：22
信頼の守護神（システムの品質向上と安全性を強固にする）：13

こちらは「効率」や「爆速」といったキーワードに多くの票が集まりました。AIエージェントによる自律的な開発や、日々のトイル削減にAIを活用している方が多そうです。ブースで直接お話しさせていただく中でも、「一年前と今では仕事の仕方が全く変わった」という声をたくさん聞き、私自身も強く感じています。

２つのアンケートを別のカンファレンスでやってみたらまた違った結果になりそうで、比較してみるのも面白そうだなと思いました。

印象に残ったセッション

現地で実際に聞くことができたセッションの中で特に印象に残ったセッションを２つ紹介します。

エンタープライズの厳格な制約を開発者に意識させない：クラウドネイティブ開発基盤設計

kaigi.cloudnativedays.jp

エンタープライズ特有の厳しいセキュリティ要件がある中で、いかにアプリ開発のスピードを落とさないように「開発導線」の整備を進めるかについてのセッションでした。エンタープライズの制約が複雑でも、ゴールデンパスで吸収することで、開発者は安全かつ高速に前に進めるとのことでした。

今回の事例のような細かい制約は弊社にはないですが、「ゴールデンパス」の必要性を感じています。スタメンでも、最近はAI-DLC（AI駆動開発ライフサイクル）による体制へとシフトしており、各メンバーが自律的に機能を開発していきます。「ゴールデンパス」が整備されていれば、開発者の生産性も上がり、余計な不安を感じずに開発できそうです。そのために、スタメンにおけるプロダクトリリースの「最低限必要なもの」を改めて棚卸しし、ゴールデンパスの整備を進めていきたいと思いました。

また、「良いものを作っても、使われるとは限らない」という話も共感しました。ツールの存在を知らせるだけで終わらず、横で一緒に作ったりする「イネーブリング」を通して、その価値を直接伝えていくことの大切さを認識しました。

継続的な負荷検証を目指して

kaigi.cloudnativedays.jp

サービスが成長し新しいエンドポイントが日々増え続ける中で、いかに負荷検証の「網羅性」を担保し、継続的に試験を行っていくかについてのセッションでした。ピーク時に特定の条件下でのみ発生する高負荷なエンドポイントが試験から漏れていたという障害の反省から、AIを活用して負荷試験のシナリオを自動生成し、成長するサービスに対して継続的な負荷検証する仕組みを構築したとのことでした。

日々増加・変化するサービスに対して、手動でシナリオを網羅し続けるのには限界があるので、負荷試験のシナリオ作成をAIにやらせることで効率が良くなるのはもちろんですが、「人間では気づけないようなアクセスパターン」を発見できる可能性があるというというお話しはAIならではの強みだと思いました。

作成されたシナリオの妥当性（ビジネス的に意味があるエンドポイントか等）の判断や、実行・評価については人間が行っているとのことで、AIに任せられる部分は任せ、ビジネス面などの重要な判断はやはりまだ人が行う必要があることも再認識しました。スタメンでも、本番相当の検証環境の用意とAIを活用した検証手法について考えていきたいと思いました。