CloudNativeKaigi 2026 に参加してきました

conferencecloud-nativeplatform-engineeringsre

はじめに

2026年5月、名古屋で開催された CloudNativeKaigi 2026 に参加してきました。

クラウドネイティブ周りの技術はインターンや個人開発で触ってきましたが、各社が実運用で何を構築し、何に悩んでいるかは、登壇やブースで聞かないとわからない部分が多いです。今回はそこを知りたいと思い、学生として参加してきました。

この記事では、聴いたセッションのうち 特に印象に残った4つ を、内容と自分の気づきを添えて紹介します。

CloudNativeKaigi 2026 とは

CloudNativeKaigi は、CloudNativeDays 系列のコミュニティが主催する国内最大規模のクラウドネイティブカンファレンスのひとつです。

2026年は名古屋開催で、「Cloud Native」「Platform Engineering」「SRE」のトラックが並行する形式でした。

CloudNativeKaigi 2026 会場

印象的だった4つのセッション

サンプリングは「作る」のか「使う」のか？分散トレースのコストと運用を両立する実践的戦略

分散トレースを組むと、スロークエリや不要な直列処理、思っていなかった依存関係まで見えるようになります。ただ規模が大きくなると、ストレージコスト、分析ツールの負荷、計装のオーバーヘッドが増えていきますし、コレクター自体も SPOF（単一障害点）になりやすいです。

定番の対策はコレクターを増やして LB を置くことですが、これで消えるのは SPOF だけで、バックエンドに全量が流れ続ける問題は残ります。データ量と観測品質は別の問題で、量を増やせばよい観測になるわけではありません。

Head-based sampling（最初のスパンを受け取った時点で記録するかを判定）は速い反面、判定後にエラーが起きたり遅延が出たりするかもしれず、最後まで見ないと価値がわからない情報 を取りこぼします。これを補うのが Tail Sampling で、全スパンが揃ったあとに判定します。ただし判定が出るまでスパンをメモリに保持する必要があるため、コレクタープールと素朴に併用するとスパンが別 Pod に散ってしまい、テイル全体を持つコレクターがいない状態になります。

直感的には LB が Trace ID を見て同じコレクターに送ればよさそうですが、スパンは gRPC のバッチで束ねて送られるため、汎用の L4/L7 LB から見えるのはバッチ自体のトレースだけで、ペイロード内のスパンの trace_id は見えません。OpenTelemetry の loadbalancing exporter は protobuf の中身まで見て traceID 単位でルーティングできるため、ここを担保するのに使います。

Tier1 のゲートウェイは loadbalancing exporter で routing_key: 'traceID' を指定し、DNS リゾルバで Tier2 を解決します。

exporters:
  loadbalancing:
    routing_key: 'traceID'
    protocol:
      otlp:
        resolver:
          dns:
            hostname: otel-tier2-internal
            port: '4317'

Tier2 のサンプリングプールは StatefulSet + Headless Service で Pod 名を otel-tier2-0, otel-tier2-1… に固定し、DNS 解決とハッシュ振り分けの一貫性を担保します。tail_sampling プロセッサーには decision_wait（テイル判定待ち時間）、num_traces（メモリ保持数）、expected_new_traces_per_sec を渡し、実トラフィックに合わせてチューニングします。

processors:
  tail_sampling:
    decision_wait: 5s
    num_traces: 10000
    expected_new_traces_per_sec: 100
    policies:
      - name: latency-policy
        type: latency
        latency: { threshold_ms: 100 }

構成は組めますが、これを本当に自分で運用したいか、という問いが残ります。代替案として挙がっていたのが Grafana Cloud の Adaptive Traces です。全トレースを一旦送り、クラウド側で RED 指標（Rate / Errors / Duration ＝リクエストの正しさを見る指標）でサンプリングポリシーを推奨・適用する仕組みで、最大 90% ほどのトレース削減ができ、現在は GA です。「課金サービスでコスト削減」は一見矛盾しますが、ストレージに全量を貯め続けるよりはトータルで安くなる、という比較です。

Q&A では閉域網やオンプレ環境への適用、機微情報のマスキングの話も出ていました。マスキングは OTel 側で属性をマスクして送れば足りる、という答えで、自前で二階層構成を組まないとできないことではありません。

「観測したい」と「観測コストを払いたい」は別の話 だ、というのがこのセッションの軸です。OSS で全部自前で組むのが正解とは限らず、運用負担まで含めて勘定したうえで「マネージドを使う」を選ぶのも一つの技術判断、と捉え直せたのが収穫でした。

「OSSがあるなら自作するな」はAI時代も正しいか — Build vs Adoptの新しい判断基準

石川さんのチームは5年前に KubeVela（Kubernetes Manifest の抽象化ツール）を採用しました。当時は Platform 構築に最適な選択でしたが、3年ほど前に開発元 Alibaba Cloud が撤退し、2代目・3代目とメンテナチームが入れ替わるなかで、自分たちが欲しい方向（Template 機能の増強）と OSS の方向が離れていきます。すでに KubeVela は Platform に深く結合していて簡単には捨てられず、代替候補も Helm は抽象度が低くて運用負荷が高い、Crossplane はオーバースペック、Kro は GA 前で未成熟 と、決定打がない状況です。

「AI があるなら自分たちで Build できるのでは」という発想は自然ですが、その前に確認すべきは 「それはアンチパターンの Build になっていないか」 です。Build そのものが悪いのではなく、作るべきでないものを維持できない形で Build してしまうこと が問題で、この本質は AI 時代になっても変わりません。

Build のコストは 実装コスト（仕様整理、実装、テスト、ドキュメント、組み込み）と 所有コスト（保守、障害対応、セキュリティ追従、仕様変更、チーム引き継ぎ、信頼性担保）に分けられます。AI で減らせるのは前者だけで、後者は AI 時代でも変わらず残ります。ここを混同すると、AI を理由に Build に走った瞬間に過去のアンチパターンに戻ります。

一方、Adopt にも 依存コスト があります。別 OSS に移行できなくなる、Platform の方向性が OSS のロードマップに引っ張られる、開発停止や脆弱性放置のリスクなど。本当の問いは「AI で作れるか」ではなく、「Adopt して依存するコストと、Build して所有するコスト、どちらを払うか」 です。

判断の枠組みとして示されていたのが3つのマトリクスです。

  1. 主判断 — コア要件 × 重要度
    • 「何割使えるか」ではなく「コア要件を満たせるか」で見る。80% 使えてもコア要件が欠けていれば Adopt しづらく、30% しか使わなくてもコアを満たせば Adopt する価値がある。
    • 結果: Heavy Adopt（重要 × OSSで満たせる）／Light Adopt／Build（重要 × OSSで満たせない）／Drop or Light Build。
  2. Adopt コスト — システム結合度 × OSS 持続性
    • OSS の持続性は時間とともに変わるので、Adopt 判断は採用時だけでなく定期的に見直す必要がある。
    • 結合度が高いこと自体は悪ではない。Heavy Adopt の領域では、Kubernetes を採用するなら土台として受け入れる前提で結合度が上がっているのが普通。問題が起きるのは 結合度が高いのに持続性が崩れた "採用危険" の状態 に移ったとき。
    • 採用危険になったら、結合度を下げて代替 OSS を探すか、代替がなければ Fork してメンテナー化する。Light でも持続性が崩れた "限定利用" になったら、基本は別 OSS への切り替え、代替がなければ Build も出口になる。
  3. Build コスト — Working Set Size × 継続保守負荷
    • Working Set Size は コード量ではない。暗黙仕様、影響範囲、AI に渡す文脈量、次の人が再開しやすいか、で測る。
    • 継続保守負荷も変更頻度だけでなく、障害影響・セキュリティ・周辺システム変更・責任分界まで含む。
    • 「CLAUDE.md / AGENTS.md / Spec は保守可能性の保証にはならない」 という言葉が印象に残りました。Spec は次の人が AI と一緒に Working Set に載せ直すための補助線であって、保守できる根拠ではありません。判断軸は「作れたか」ではなく 「次も扱えるか」 に置く必要があります。

事例として krbac（Kubernetes RBAC を宣言的に管理する Operator）が紹介されていました。以前は Controller / Operator の初期実装の重さで諦めていたものを、AI と要件整理・技術比較・CRD 設計・実装プランをやり取りしながら 相談から実機テスト完了まで約4時間 で形にし、Secret deny の安全弁・Guide・API Reference まで Spec として揃っているそうです。ポイントは Kubernetes は Adopt したままで、足りない権限管理の部分だけを Build した ことです。

全部 Adopt でも全部 Build でもなく、Adopt しながら必要な部分を Build する。

これがセッションの結論です。Build にも Core / Extension / Configuration / Fork と種類があり、AI 時代に増えるのは主に後ろ3つ、OSS を土台にしたうえで自社固有の拡張・設定・パッチを作る領域です。KubeVela 自体については「全面 Build はせず、Fork しつつ upstream に Contribute、利用範囲は Kubernetes Manifest Template と Application Controller に絞り、機能単位で段階的に移行する」という判断でした。

AI でハードルが下がる世界であるからこその、所有コストと依存コストを最初の判断軸に置く視点を得られました。

プラットフォームエンジニアリング、結局なにをすればいいのか？

プラットフォームの定義は次のとおりでした。

開発者にとって役立つ機能を、魅力的な社内プロダクトにしたもの

ツール・ナレッジ・セルフサービスの API を束ねた共通基盤を提供することで、サービス提供を速くする仕組みです。空港のようなもの、という例えがしっくりきました。現在は 90% の組織が少なくとも1つは内部プラットフォームを持ち、76% は専任チームを置いている そうです。

注目されている背景にあるのは「認知負荷の爆発」です。CI/CD、マニフェスト、Observability、IaC など、クラウドネイティブの便利技術が増え続けているため、共通基盤化したくなります。よく言われる「IDP」も2種類あります。

  • Internal Developer Platform: 開発チーム向けの内部基盤（認証や CI、抽象化レイヤなど）
  • Internal Developer Portal: 開発者向けの UI / 窓口。代表例は OSS の Backstage

これらを束ねたベストプラクティスの道が ゴールデンパス です。ただし「IDP を作れば成功する」というほど単純な話ではありません。共通プラットフォームを作る取り組み自体は昔からあるもので、本質は「社内で活用され、ビジネス成果を出す共通基盤を作り、育てる方法論」であって、成功するのは2割以下 と言われています。

失敗の理由は「使う人のことを考えていない」こと。「考えていますか？」と聞くと「考えています」と返ってくるが、「じゃあ誰が？」と踏み込むと曖昧になる。「みんな同じことをやっているから共通化しよう」「世の中で流行っているからやろう」という出発点だと、ほとんどの場合「考えることが増えるだけ」で終わってしまいます。

では何をすればいいか。答えは技術的なものではなく 「一緒にご飯を食べに行く」 でした。Stream-aligned team と 1:1 でコラボし、相手のチームの一員として動くなかで見えてくる「本当に欲しいもの」を起点に作ります。最初は ただの Wiki / 便利なリンク集 で十分。そこから Platform as a Product の発想で、開発者を顧客と捉え、North Star Metrics、ユーザーヒアリング、優先度付け、ブランディング・社内マーケまで行います。技術と組織は 社会7：技術3 のソシオテクニカル として同時に設計する必要があり、片方だけを最適化しても効きません。

プラットフォームをベストプラクティスの集合体として捉えるだけだと本質を見失う、という点が特に残りました。技術を作る前に対話する、という当たり前のことをより意識していきたいです。

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

きっかけは登壇者が CS（カスタマーサクセス）チームに「最近サービスの障害をよく検知している。それでユーザーから意見や解約はあった？」と尋ねたエピソードでした。

実は、機能不足による失注や解約のほうが数は多いです

という返答が返ってきて、SLO を機能開発と運用のバランス判断に使えていなかった、という気づきが出発点になっています。

中規模以上の組織だと、Dev チーム数が SRE 数を上回り、SRE は支援業務（ドキュメント、情報ポータル、Toil 削減、ペアワーク委譲、チケット運用など）に追われがちです。これが進むと SRE は本番から離れ、Google SRE Workbook でいう「新たなゲート組織」化してしまうリスクがあります。

これを避けるための考え方が Google の Product-Focused Reliability (PFR) で、信頼性の単位を「サービス」から「プロダクトの重要機能」に変えるアプローチです。SLO は次の3層で扱います。

SLO 種別計測対象コストカバレッジ担当
Service SLOサーバー側の技術メトリクス低狭いDev
Client-side SLOブラウザ/アプリ実体験（RUM など）中広いDev
End-to-end SLOCUJ 全体の集約非常に高い深いSRE

CUJ (Critical User Journey) は 「① このユーザーは誰か／② そのユーザーにとって何が成功か／③ 目的を果たすにはどの手続きが必要か」 の3つの問いでステップを分解し、各ステップを SLI に落として作ります。自販機の例を Web サービスの購買フローに当てはめると、商品検索 UI → 決済入力 → 注文確定 → 完了通知の4ステップそれぞれに SLI が立ちます。

個々の Service SLO がすべて緑（例: 99.5%、99.9%、99.95%、99.0%）でも、掛け合わせると

0.995 × 0.999 × 0.9995 × 0.990 ≒ 98.36%

に劣化するという例が特に印象的でした。「ユーザーが商品を買って受け取る」という本来の目的は、Service SLO の積み上げだけでは守れません。そのため End-to-end SLO は SRE が引き受け、責任を 層（横）ではなく機能（縦） で分担します。SRE も Dev も、同じ本番環境について同じユーザー価値の指標で考えられるようになります。

「99.9% は本当に必要か」は答えるための問いではなく、ビジネスとの対話を始めるきっかけの問い だ、というのがこのセッションの軸です。数字に守られて本質を見失う現象は、往々にして起きそうだと感じます。SLO を技術指標としてだけでなくコミュニケーション設計の道具として使う、という捉え方が今回の収穫でした。

コミュニティ・交流で感じたこと

セッションの合間や懇親会で、他社の SRE / Platform Engineer の方、ブースのスポンサー企業の方と直接話す機会がありました。スライドや資料からは読み取れない現場の温度感や日々の悩みを聞けたのは、現地参加ならではの価値だと改めて感じました！

今後お世話になる予定の企業の方とも繋がりが作れて、刺激的で充実した時間を過ごせました！

終わりに

去年の Google Cloud Next Tokyo 2025 に続き、2回目のカンファレンス参加でした！

前回はカンファレンス自体の進み方に慣れていない部分も多かったですが、今回はセッションの内容に集中したり、ブースで話を聞いて議論したりできて、純粋に楽しく過ごせました！

今後も継続的に色々なカンファレンスに参加していきたいです！

参考リンク