Oisix Creator's Blog(オイシックスクリエイターズブログ)

オイシックス株式会社のエンジニア・デザイナーが執筆している公式ブログです。

クラウドネイティブ会議参加レポート

はじめに

こんにちは!SREセクションの三木、高木、内山です。

2026/5/14-15に、名古屋で クラウドネイティブ会議が開催されました。「CloudNative Days」「Platform Engineering Kaigi」「SRE Kaigi」の3イベント合同で開催されたカンファレンスです。
オイシックスからは、SREセクションの3名が現地参加しました。

この記事では、印象に残ったセッションの紹介と、チームで参加した「GameDay」の参加レポートをお届けします。 これからクラウドネイティブ技術に取り組む方や、カンファレンスの雰囲気が気になる方の参考になれば幸いです。

alt text

印象に残ったセッションの紹介

高木

生成AI時代に信頼性をどう保ち続けるか - Policy as Code の実践


ビジネス成長に伴いProduction Readiness Checklist (PRC)のレビューがボトルネックになったとのことです。 そこで、チェック項目をPolicy as Code (PaC)に置き換え、CIでチェックする取り組みが紹介されていました。

生成AIの普及でPull Requestの数が増える一方で、人間のレビューがボトルネックになるというのはよくある話です。 レビューもAIに任せることで一定の品質向上にはなります。一方で、決定論的なコードでガードレールを敷くこともやった方がいいかなとも考えていました。その考えが確信になる、大変参考になる事例でした。 弊社ではまだPRCを始めるに至っていませんが、PaCを始めようと考えるきっかけになりました。 PaCのコードを記述して維持するのは難しい印象がありましたが、人間が厳密に構文を覚えずともAIがポリシーを記述してくれる点はハードルが下がります。ポリシー自体の品質をテストできる点も便利です。この事例の技術スタック(Terraform, Kubernetes)を弊社も同様に使っているので、PaCに取り組んでいきたいです。

そのSLO 99.9%、本当に必要ですか? 〜優先度付きSLOによる責任共有の設計思想〜


このセッションは時間の都合上現地で聴講できませんでしたが、後日スライドを拝読しました。 SREのリソースが限られている中で「SREは何に時間を使うのか」という問いは、私たちも悩んでいます。 またSLI/SLOについて、OisixではDatadogを利用してSLOを設定し、ダッシュボードで閲覧できるようにしています。 SLI/SLOを「5XXエラー率」「レスポンスタイムN秒以内」と定めています。SLI/SLO運用を始めてはいますが、ユーザー体験と密接に関わるSLIの定義には至っていません。Service SLOとEnd-to-end SLOの考え方が非常に参考になりそうです。 CSチームへのヒアリングは特に興味深いです。SLOは高いほど良いわけではなく、実際にユーザーと距離が近い人からの声を聞くことがSLOの再考、ひいては自分たちの戦略と時間の使い方を再考するきっかけになるという、示唆に富む事例でした。

内山

クラウド・ネイティブ技術を総動員してオンプレミス中心の病院システムのクラウド化を推進する挑戦


株式会社ispecによる、オンプレミス中心の病院システムのクラウド化推進に関する事例紹介です。
病院のシステムについては普段あまり知る機会がないため、興味深く拝聴しました。

病院の電子カルテはネットワークが閉じられていることが多く、そのままではコピー&ペーストすらできない環境です。 同社は「CloudSail」というプラットフォームでこの課題に取り組み、院内サーバでリバースプロキシを動かすことで、生成AIなどの外部サービスを活用可能にしています。
院内ではエッジ版Kubernetesのk3sを採用することで、AWSから院内へのアクセス経路を極力減らしつつ、複数のアプリケーションを動かす構成としていました。

また、技術選定の考え方も非常に印象に残りました。この事例では意思決定の状況をクネビン・フレームワークの「複雑系」と捉え、「探索・検知・対応」を行動指針としていました。
そのため、最初から「イケてる基盤」を入れるのではなく、まずはマニュアルでリリースしてトイルを可視化し、見えてきた課題に応じて基盤を構築するという地道なアプローチが採用されていました。

不確実性の高い環境で意思決定を行うのは難しいことですが、意思決定を急ぎすぎず、並行して調査や検証をすることが最適な解決策に繋がるという学びになりました。


1人目SREが開発組織のトポロジーを変えるまでの実践知


イオンスマートテクノロジー株式会社による、SREを支える組織設計についての実践知の共有でした。
2,000万ダウンロードを突破したサービスを支える同社では、横軸組織を廃止し、開発チーム全員でSREの責務を担う方針へ転換しています。こうした変革では技術以外の壁に直面しますが、それを乗り越える鍵として「対話と協働」の積み重ねが重要だと紹介されていました。

セッションでは対話に関する書籍がいくつか紹介されていましたが、特に印象に残ったものは『組織を変える5つの対話』『「変化を嫌う人」を動かす』です。
『組織を変える5つの対話』では、次の5つのステップで対話を進めることが重要だとされています。

  1. 信頼を築く対話
  2. 不安を乗り越える対話
  3. Whyを作り上げる対話
  4. コミットメントを行う対話
  5. 説明責任を果たす対話

ポイントは「いきなりWhyから始めない」ことです。信頼関係が不十分な状態で『Why』を問いかけても、時に本心や事実が隠れてしまうことがあります。この課題は私自身も過去に実感した事があり、非常に腑に落ちる内容でした。

また、『「変化を嫌う人」を動かす』では、変化を嫌う人の抵抗パターン(惰性・労力・感情・心理的反発)に応じて異なる対処法が紹介されていました。「惰性」の場合は段階的な変化や単純接触効果を狙う、「感情」の場合は「なぜ?」に目を向ける等です。変化への抵抗を画一的に捉えるのではなく、相手を観察し、状況に応じたアプローチを取ることが重要だと学びました。

組織設計と対話に焦点を当てた内容で、SREのみならず組織横断の取り組みを進める幅広い立場の人にとって参考になるセッションでした。


GameDayの参加レポート 〜障害対応を「競技」として楽しむ〜

三木

「目の前のKubernetesクラスタで障害が起きています。直してください。制限時間内に。チーム対抗で。」

そんなイベントがGameDayです。マイクロサービス環境で実際に発生している障害を、全11問、チームで解いていきます。私たちSREセクションの3人はチームを組んで参加し、全問クリアで3位という結果でした(悔しくもあり、嬉しくもあり)。

とても楽しかったので、感想を書きます。 公式の問題解説はこちら。

https://kaigi.cloudnativedays.jp/blog/gameday-4/

ちょうど良いレベルデザイン

最初の数問は kubectl describekubectl logs で状況を確認すれば解ける、基本的な問題から始まります。このあたりは「まあこれは初歩的なミスだね」とすぐに直せるレベル。 ところが問題が進むにつれて、そんな簡単なものではなくなっていきます。 「あー、実務だとこういう複雑さのやつあるよね」と、現場のエンジニアなら思わず頷いてしまう現実的なシナリオに変わっていくのです。

今回のGameDay、このレベルデザインの塩梅が良かったです。最初の簡単な問題で「解けた」という自信をつけさせて、「よし、次に行くぞ」という気持ちにさせる。 そこから1問ごとに少しずつレベルが上がっていくから、気づけば夢中で画面に張り付いている。Grafanaでメトリクスを、Jaegerでトレースを追いかけ、OOMで死ぬPodにリソース制限を設定する。そうして道中で扱うツールや観点も自然と広がっていきます。

「k8sは知ってるけど、現場の保守は経験薄くて...参加できるか心配です」という人でも、ちょうどいい難易度だと感じました。

高難易度問題の感想

難易度Hardとなっていた問題はどれも難しかったです。特に最後の問題は大変でしたが、それゆえに面白かったです。

「Pod間通信が散発的に失敗する」という、聞くだけで胃が痛くなるやつでした。 (再現したりしなかったりする障害ほど厄介なものはありませんね...。)

調査を進めると、DoS対策として入れたnftablesのルールが、内部のPod間通信まで巻き込んでドロップしていたことが判明。 原因の特定までがなかなか大変だったのですが、ヒントがちゃんと用意されていて、時間をかければ辿り着ける絶妙な塩梅でした。

「本番でもこういうのあるよね」という納得感もあって、面白い問題でした。 (各問題の解説は、冒頭の公式レポートを参照ください)

3人で1台の端末を囲む楽しさ

そして何より楽しかったのが、チーム戦であったこと。 3人で1台の端末を覗き込みながら「これじゃないかな」「いや待って、設定のここ見て」「あ、分かったかも」と言い合いながら進めていく。この時間は、大人になってからなかなか味わえない文化祭前夜のような盛り上がりでした。 普段はリモートで別々のタスクを抱えている私たちが、同じ場所で同じ問題に向かって頭を突き合わせる。なんだか新鮮で、これだけで参加した価値があったように思えました。

トラブル対応を「疑似体験」できる場として

トラブル対応の経験は、実際に障害の渦中に立った回数でしか積み上がらないところがあります。 でも本物の障害はそう都合よく起きてくれないし、起きたら起きたで強いストレスがかかります。

GameDayなら、その経験を本物の障害ではない環境で、ストレスの少ない状態で疑似体験できる。 これはエントリークラスから中堅くらいの人にこそやってもらいたい体験だと感じました。社内研修やオンボーディングにもそのまま使えそうです。

このコンテンツを作り上げた運営の皆さまに、心から感謝と敬意を。 来年もし開催されたら、ぜひ皆さんも参加してみてください。障害対応がこんなに楽しいなんて、と思えるはずです。

おわりに

クラウドネイティブ領域の最新動向や各社の実践事例に触れられる、貴重な機会となりました。 最後までお読みいただき、ありがとうございました。

Oisix Creator's Blogはオイシックス株式会社のエンジニア・デザイナーが執筆している公式ブログです。

オイシックス株式会社では一緒に働く仲間を募集しています