Sreake事業部アプリケーション開発支援チームの太田暢（@iorandd）です。
2026年7月29・30日に横浜で開催された KubeCon + CloudNativeCon Japan 2026 に参加してきました。本記事では聴講したセッションや現地会場の様子を紹介します。
KubeCon + CloudNativeCon Japan とは
KubeCon + CloudNativeCon は Cloud Native Computing Foundation（CNCF）が主催するクラウドネイティブ技術のカンファレンスです。Kubernetes を中心に、コンテナ、通信、監視、セキュリティ、AI 基盤、オープンソースの運用に関する講演とコミュニティ活動が行われます。
世界各地で開催されており、2026 年はヨーロッパ（3 月・アムステルダム）、インド（6 月・ムンバイ）、日本（7 月・横浜）、中国（9 月・上海）、北米（11 月・ソルトレイクシティ）の 5 か所で開かれます。
日本では昨年の初開催に続く 2 回目で、前日には ArgoCon Japan・KeycloakCon Japan・Japan Community Day が併催されました。
スリーシェイクはシルバースポンサーとしてブースを出展しており、そちらの様子は Tech Branding チームの澤田さんによる記事にまとまっているため、あわせてご覧ください！
今回のプログラムでは AI + ML・Cloud Native Novice・Connectivity・Observability・Operations + Performance・Platform Engineering・Security など、幅広い分野のセッションがありました。
タイムテーブルには講演ごとに対象レベル（Beginner・Intermediate・Advanced・Any）が示されていて、私は普段アプリケーション開発を主に担当しているのですが、Kubernetes 周辺の経験が浅くても関心や業務との接点に合わせて聞きたいセッションを事前に選ぶことができました。
クラウドネイティブの現在地
キーノートではクラウドネイティブが 10年かけて蓄積した知見を AI ワークロードにも生かすという方向性が示されました。大規模な推論に必要な分散処理、オーケストレーション、ネットワーク、可観測性、スケジューリングは、クラウドネイティブコミュニティが取り組んできた課題と重なります。コンテナとサンドボックス、マイクロサービスとエージェント、サービスメッシュと MCP などの Agentic Protocols、宣言的 API と Model as a Service などが、従来のクラウドネイティブと AI 時代の要件の対応例として挙げられていました。
The State of Cloud Native: The Shift Towards AI
Apple の Katie Gamanji 氏（Engineering Manager）もこの変化を「確立されたクラウドネイティブの領域で起きているイノベーション」と位置づけ、クラウドネイティブを支えてきた設計パターンだけでなく、オープンなガバナンス、ベンダー中立性、コミュニティの運営方法もオープンソース AI を持続的に発展させる基盤になると語っていました。
2026 年 1 月に公開された CNCF Annual Cloud Native Survey（2025 年版）によると、クラウドネイティブを採用する組織は 98%、生成 AI をホストする組織のうち推論ワークロードの一部または全部を Kubernetes で動かす組織は 66%、モデルを日次でデプロイする組織は 7% ということです。既存のモデルをファインチューニングして使うことが多く、クラウドネイティブがアプリケーションに対して積み上げてきた継続的デリバリーの水準に AI ワークロードはまだ届いてないようです。
CNCF Tech Radar という調査も紹介されました。こちらでは 300 人を超えるクラウドネイティブ開発者が成熟度や有用性を採点し、AI 推論・ML オーケストレーション・エージェントの 3 分野それぞれで ADOPT・TRIAL・ASSESS に分類されています。本番に投入できる水準を意味する ADOPT へ届いていたのはエージェント分野では MCP と Llama Stack の 2 つということで、今後さらに増えていくことに期待したいです。
個人的には、Apple のエンジニアの登壇を生で聴くのは初めてでしたが、Gamanji 氏の話し方や間の使い方、スライドの見せ方は Apple らしさに溢れていて、 30 分間が短く感じる引き込まれるような素晴らしいセッションでした。
proxyless gRPC
Pluggable Interception: Using ExtAuthz and ExtProc in gRPC using xDS
Google の Pawan Bhardwaj 氏（Sr. Software Engineer、gRPC Maintainer）のセッションでは、サイドカーを置かない proxyless サービスメッシュへ新しいフィルタを追加する取り組みが紹介されていました。proxyless とは、Envoy サイドカーの代わりに gRPC ライブラリ自身が xDS（コントロールプレーンがルーティングやフィルタの設定をデータプレーンへ配る API 群）を解釈する構成で、ホップが 1 つ減る分レイテンシとリソース使用量を抑えられます。
新しく加わるのは ext_authz と ext_proc の 2 つで、Envoy の HTTP フィルタとして使われてきた仕組みを gRPC ライブラリ側に持たせます。ext_authz はメッセージ本体を送らずに RPC 開始時のヘッダやパスなどのメタデータで通してよいかを 1 回だけ判定し、クライアント側でも動くためサーバーへ届く前に止められます。ext_proc はヘッダとメッセージ本体を外部サービスへストリームし、検査、書き換え、RPC の打ち切りまで任せられます。AI / LLM ゲートウェイ向けには、モデルのバックエンドへ届く前の API キーやトークンの検証、ストリームを流れるリクエストとレスポンスから PII を伏せる使い方が示されました。
なおスライドで参照されていた 4 つの gRFC のうち、2026 年 7 月 30 日時点で gRPC proposal リポジトリへマージ済みなのは Composite Filter（A103）だけで、ExtAuthz（A92）・ExtProc（A93）・GrpcService（A102）は Pull Request の段階です。A103 の実装も環境変数で保護された実験的な扱いです。
ext_authz は RPC あたり 1 往復、ext_proc は RPC ごとに張るストリームで継続的に往復するため、導入時は遅延と可用性が設計の論点になります。レイテンシへの影響は RPC の属性でマッチする Composite Filter で適用範囲を絞って限定でき、ext_authz では認可サービスの障害時に failure_mode_allow を有効にすれば RPC を通せます（ext_proc の同名の設定は observability mode かメッセージ送信前に限られます）。外部呼び出しは元の RPC のトレースコンテキストを引き継ぐため子スパンとして追跡でき、メトリクスには ext_authz の許可・拒否・失敗の件数と ext_proc の待ち時間が出ます。
私も普段の開発で gRPC を利用しているため関心の強いセッションで、サービスごとに散らばりがちな認可やマスキングを xDS の設定で差し替えられる外部サービスへ寄せられる点に魅力を感じました。
オブザーバビリティ
From Statsd to OpenTelemetry: Atlassian’s Metrics Platform Migration at Scale
Atlassian の Iris Grace Endozo 氏（Principal Software Engineer）と Farzad Vazirnia 氏（Senior Software Engineer）のセッションでは、14 リージョン・約 10 万ホストで利用していた StatsD 基盤を OpenTelemetry Collector へ移行した事例が紹介されました。従来使用していた gostatsd は安定して動いていたものの、OTLP を受け取れないうえ、Collector 相当の最適化を gostatsd 側で追い続ける保守の負担が大きくなっていたそうです。
移行の際はアプリケーションに手を加えず、各ホストのサイドカーを StatsD/UDP と OTLP の両方を受信する Collector へ差し替えていました。Collector は用途ごとに含めるコンポーネントを変えてビルドし、収集・取り込み・集約・転送で別々のバイナリを動かしています。集約段は 60 秒ごとに同じ時系列のデータポイントを 1 点へまとめ、毎分約 48 億のデータポイントを約 2.3 億へ減らします。同じ時系列が別々のサーバーへ届くと合計が分かれるため、従来はサービス名と環境をキーに振り分けていましたが、サービスごとの流量差で各サーバーの受信量は毎秒 5 万から 60 万ポイントまで開いていたそうです。移行後は時系列そのものを表す streamID をキーにして毎秒約 22 万ポイントへ揃え、集約を gostatsd から Collector へ移すにつれ集約フリートの CPU 使用量も 2,200 コアから 1,500 コアへ下がったとのことです。展開も低い環境から始めてクリティカルでないサービスを先行させ、新旧の基盤が長く併存するため運用手順を揃えていたそうです。
利用者が参照するメトリクスの意味を変えないことが最優先に置かれていたことが印象的でした。基盤の置き換えでは新しいツールの機能に目が向きがちですが、このセッションでは既存のアラートやダッシュボードが同じ値を返すかどうかで移行の可否を決めており、重要な観点だと再認識しました。
Designing for High-cardinality Metrics
Reddit の Walther Lee 氏（Software Engineer）と Aleksandr Krivoshchekov 氏（Staff Software Engineer）のセッションでは、数千の Pod を持つ環境でダッシュボード用のクエリが多数の時系列を読み込む必要がある中で、Deployment 単位の集約値を取り込み時に作成し、障害調査に使う Pod 単位の時系列と分けて保存する方法が紹介されていました。
Pod ごとの累積カウンタは再起動でリセットされるため、そのままでは合計できません。そこで scrape 時に delta へ変換して集約し、累積形式へ戻していました。累積として保つ期間を scrape interval と同等にまで縮め、集約値を書き込んだ直後にリセットする仕組みなので、系列は増加と下降を繰り返す形になり、これを zigzag カウンタと呼んでいました。Prometheus はこの下降をカウンタのリセットとして扱うため、rate や increase は正しい増分を返します。対象となるのは counter と、バケットが累積カウンタとなっている classic histogram で、検証ではクエリが読み込む時系列数が 88%、レイテンシが 80% 減り、生データとの差は平均 0.15% に収まったそうです。詳しいアルゴリズムは登壇者による Materialized metrics in Prometheus でも解説されています。
累積を保つ幅を scrape interval まで縮めてカウンタを zigzag にするという、シンプルな発想で解決しようというのは個人的に好みでした。
One Binary, Two Ecosystems: Embedding Prometheus Exporters with OCB
Grafana Labs の Kyle Eckhart 氏（Principal Software Engineer）と Arthur Sens 氏（Software Engineer）のセッションでは、Prometheus exporter を OpenTelemetry Collector の receiver として動かす opentelemetry-collector-bridge が紹介されていました。既存の exporter をライブラリとして再利用し、Collector のプロセス内で動かす仕組みです。HTTP のエンドポイントは公開せず、Bridge の receiver が Collector 内でスクレイプループを回してインメモリで読み取り、OTel 形式へ変換します。対応する OTel receiver をゼロから作り直さずに実績のある実装を新しいパイプラインへつなげられ、OCB（OpenTelemetry Collector Builder）が必要なコンポーネントだけを選んで単一のバイナリへビルドします。
一方、バイナリを一つにまとめても、Prometheus と OTel で異なるメトリクス名や属性の対応付けは残ります。たとえば node_cpu_seconds_total と system.cpu.time を同じ情報として扱うには変換が必要で、現状は利用者が OTTL で一つずつ書いている状態です。今後は Bridge 側に変換を同梱して利用者が書かずに済むようにし、その先はメトリクス名を変えないままスキーマに対応関係を持たせ、schema-aware な PromQL がどちらの名前でもクエリに一致する形を目指すとのことでした。なお Bridge も、Bridge を使った receiver を集める Prometheus 版の Collector ディストリビューションは、2026 年 7 月 30 日時点では [EXPERIMENTAL] となっています。
移行で再利用できるのは実装だけではないと感じました。既存のダッシュボードやアラートが依存するデータの意味も引き継ぐ対象になります。バイナリを一つにまとめること自体より、二つのエコシステムで実装と運用の知識を重複させないことに主眼が置かれていた点が印象に残りました。
Repurposing OpenTelemetry Traces as Test Data: Breaking the Cost Barrier in System Migration
CyberAgent, Inc. の Yoshiki Fujikane 氏（Platform Engineer）のセッションでは、稼働中のシステムから得たトレースをシステム移行後の動作確認に再利用する手法が紹介されていました。リクエストとレスポンスをスパンに記録し、移行先にも同じリクエストを投げて結果を比較することで、失われた仕様書やテストのないコードを読み解かなくても characterization test（仕様化テスト）を用意できるというものです。
ただし、取得したトレースをそのままテストデータとして利用することはできません。現状では HTTP のリクエストとレスポンスのボディが OpenTelemetry の Semantic Conventions の対象外であり、標準の計装では記録されないためです。今回の PoC では独自の属性としてボディを追加していましたが、すべてのリクエストにボディを含めるとレイテンシの悪化やトレース量の増加を招きます。また、SaaS 型のトレースバックエンドを利用している場合、機微なデータがシステムの外へ出ていくことになります。そこで記録対象のルートをフィーチャーフラグで絞り込んだうえで、Collector 側でボディを含むトレースを仕分けローカルファイルへ書き出す構成をとっていました。アプリケーション本体への計装が困難なシステム向けには eBPF ベースの OBI（OpenTelemetry eBPF Instrumentation）を用いて、コードを変更せずにボディを取得する手法も紹介されていました。
観測データはただ貯めるだけでは価値を生まず、安全に再利用できる範囲まで設計してはじめて別の用途に昇華できるという、オブザーバビリティの応用的な可能性を感じる内容でした。
From Tool Calls to Context Fabric: Building AI-Native Observability for Platform Engineering
NVIDIA の Deepak Choudhary 氏（Senior Software Engineer）のセッションでは、AI エージェントに運用調査を任せるために、調査の下敷きとなるコンテキストを先に用意しておく「Context Fabric」という構成が紹介されていました。題材は Thanos の Store API のレイテンシが上がったアラートで、原因の候補が 3 つ並ぶものの、どれも証拠がないという状況から始まります。
メトリクスやログを引く Tool を渡すだけでは足りません。デモの前半でエージェントは対象のメトリクスを特定できずに止まります。名前に store を含むメトリクスが 128 個あり、いちばん名前の近いものを選んでも p95 は 0.095 秒しかなく、アラートの 47 秒と合わないためです。そこでコンポーネント・依存先・操作・時間帯をスコープとして先に固め、メトリクス名やラベルの候補は事前に組み上げたグラフから引く形にしていました。グラフはオブジェクトストレージ上の TSDB ブロックを 1 時間ごとに走査して作るため、調査のたびにカーディナリティの重いスキャンは走りません。窓口は Metrics・Logs・Skill の 3 つの MCP（Model Context Protocol）に分かれ、Skill MCP は承認済みの Runbook から調査手順を返します。インターフェースは MCP で統一しつつ、認可は各 MCP の内側でライブクエリの前に効かせます。後半のデモではメトリクスとログが同じ時間帯で一致しても、原因は未証明だとしてエージェントがいったん止まり、次に何を見るかの承認を求めていました。承認後も自分でシステムへ手を入れることはなく、出力には no change is authorized by this investigation と明記されます。
AI が参照できる範囲、調査の順序、そして操作のガードレールを人間側がしっかり設計・提供して初めて、実用的な AIOps が成立するのだと実感しました。
AI に任せるための評価設計
AI エージェントに判断や作業を任せるセッションからは 3 つ紹介します。どの事例も AI の判断をそのまま信用するのではなく、閾値や集計、テストといった AI の外側の仕組みで結果を確かめる工夫が凝らされていました。
AIOps: (near) Zero-Touch Production Rollout Fixes
IBM の Kevin Dubois 氏（Sr. Principal Developer Advocate）と Adobe の Carlos Sanchez 氏のセッションでは、Argo Rollouts のカナリア分析の判定を AI エージェントに任せる構成が紹介されました。カナリアリリースでは新バージョンへ流すトラフィックを段階的に増やし、各段階で問題がないかを分析して先へ進むか切り戻すかを決めます。従来はこの判定の条件をメトリクスごとに PromQL で書く必要があり、その手間を AI の分析で置き換えるという発想です。
合否の条件は AnalysisTemplate という設定に書きます。ここへ PromQL の代わりに metric plugin（rollouts-plugin-metric-ai）を指定すると、分析のタイミングでプラグインが外部の AI エージェントを呼び出します。エージェントはメトリクス、ログ、Pod の情報を並列に調べてスコアと根拠を返し、Argo Rollouts はそのスコアを successCondition: result > 0.50 の条件で判定します。AI が担うのは調査とスコア付けまでで、合否を分ける線は人が設定に書いたまま残ります。デモのカナリアはエラー率が 1.03% でレイテンシも正常でしたが、エージェントはログに出ていた NullPointerException を根拠に ROLLBACK と判定し、展開は直前の状態へ切り戻されました。ロールバック後は非同期に修復へ進み、単純なコードの修正で済むなら Pull Request、済まないなら詳細な Issue を作ります。
ロールバックは判断が外れても直前の既知の状態へ戻れる一方、修正は外れたときの着地点が決まりません。エージェントの精度ではなく外れたときの戻り先で任せる範囲を決めるという線引きは、自動化の範囲を考えるときに参考にしたいと感じました。
From Experiment to Enterprise: Scaling an AI Agent for Code Review
Sony Interactive Entertainment の Adam Phan 氏（Staff Software Engineer）のセッションでは、コードレビュー用の AI エージェントを 400 以上の PlayStation リポジトリへ展開した事例が紹介されました。難しかったのはエージェントにレビューをさせること自体ではなく、全社の共有サービスとして信頼を得ながら運用し続けることだったそうです。そこで 1 回のレビューを入力・出力・実行時間に上限のあるジョブとして定義し、エージェントが読めるのは Pull Request の差分と参照を許したコンテキスト、使えるツールも許可した範囲、返すのは根拠付きの指摘までと決めていました。その指摘を受け入れるかや変更をマージするかはエンジニアの役割です。
実行環境はレビューのたびに Kubernetes の Pod を立ち上げて終わったら使い捨てです。Pod と一緒に中の情報も消えるため、終了状態やエンジニアに見せた結果は破棄の前に書き出し、成功・失敗・タイムアウトのいずれで終わっても記録を残していました。この記録が役立ったのが本番で最初に起きた問題です。レビューの振り分けをわずかに変えたところ品質が劣化したのですが、1 実行ずつ見ると正常に見え、記録を集計した傾向とコストの上振れで初めて異常だと分かったそうです。この経験から、複数回の結果を集計して前のリリースと比較する検証を置くようになったとのことです。
印象に残ったのは 1 実行ずつ見ると正常なのに集計すると劣化が見えたという点です。AI エージェントを使うときにも起こり得ることなので、気をつけておきたいですね。
The Great Doubt: What Building an AI Agent Taught Us About Trust
Grafana Labs の Nicole van der Hoeven 氏（Senior Developer Advocate）のセッションでは、Grafana Assistant が受け取っていない Tempo のトレースを参照したような分析を返した事例が紹介されました。コンテキストにトレースが渡らないバグがあったのに回答はもっともらしく、人によるレビューでも誤りを見抜けなかったそうです。ここを起点に、エージェント・テスト・採点するモデル・スコア・疑いそのものへと疑う対象を深めていく構成で、哲学者・西谷啓治が説いた「大疑」を枠組みに置いていました。
疑いはまず Assistant の回答そのものに向かい、実運用の会話からテスト用の質問集を作って、正解が事前に分かる検証環境（Docker 上の Prometheus・Loki・Tempo）で自動で答え合わせできるようにしていました。ただし LLM は同じ質問でも毎回同じ回答を返すとは限りません。そこでテストは 3 回ずつ実行し、1 回でも成功する pass@3 と 3 回すべて成功する pass^3 を分けて測り、たまたまできるのか安定してできるのかを区別する仕組みです。採点も LLM に任せていましたが、自分の採点基準を緩めて合格させる事例が見つかりました。そのため、リリース前に質問集で確かめる offline evals だけでなく、本番の回答を継続的に採点する online evals も併用していました。それでも、システムプロンプトが読み込まれないままベンチマークが高得点を出す問題が起きたそうです。
評価そのものが正しく機能しているかまで観測するというのを日本の哲学者になぞらえたユニークなセッションでした。
番外編
セッション以外の場も非常に充実していました。ウェルカムレセプションやコーヒーブレイクが絶妙なタイミングで用意されており、参加者同士が自然と交流しやすい配慮が随所に感じられました。美味しいお弁当やケータリング、飲み物を片手に、会場のあちこちで技術談義に花が咲いている光景は、国際カンファレンスの活気そのものでした。
カンファレンスのもう一つの楽しみといえば企業ブースの Swag ですが、HashiCorp の箸、Argo の T シャツ、Datadog の靴下など、各社バラエティに富んだノベルティを用意されていました。カンファレンス公式 T シャツの受け取りにも長蛇の列ができており、セッションの合間も常にカンファレンス全体を楽しむ熱気に包まれていました。
素晴らしい会場の空気をつくり、2日間にわたる巨大イベントを滞りなく進行・サポートしてくださったボランティアおよび運営スタッフのみなさま、本当にありがとうございました！
まとめ
単なる技術トレンドのキャッチアップにとどまらず、技術者としてのモチベーションを大きく高めてくれた2日間でした。
世界中から集まったエンジニアたちの熱量に触れ、複雑な課題にどう立ち向かっているかを直接聞くなかで、自分が理解できていることと理解が及ばないことを客観的に見つめ直したり、技術の面白さを再確認する素晴らしい時間になりました。
また日本で開催されるとのことだったので、楽しみにしたいですね！