1. はじめに
横浜で開催された KubeCon + CloudNativeCon Japan 2026 に参加してきました。
本編は 2 日間の日程で、その前日にはコホストイベントが開かれています。私が参加できたのは 前日のコホストイベントと、本編の 1 日目 の 2 日分です（本編 2 日目は私用のため参加できませんでした）。本稿はその範囲で聞いた内容をまとめたものになります。
正直に書くと、参加前の私は Kubernetes にそこまで前のめりではありませんでした。K8s は大規模なトラフィックをさばくにあたって柔軟性が求められる組織のためのツールであり、NASEBANAL のような駆け出しのアプリ開発とは無縁だろう——そう考えていたのです。実際、NASEBANAL の各アプリは Cloudflare Workers 上で動いています。Serverless を使えば K8s のレイヤーを意識することなくスケーラブルなデプロイができますし、トラフィックがそこまで多くなく、運用コストよりも生産性を優先したい Public サービスを作っている限り、当面 K8s を触る機会はないだろう、と。
それでも足を運んだのは、ひとつには自宅からほど近い横浜での開催だったから。そしてもうひとつ、これまで Pivotal（のちの VMware）や Cloudflare での経験を通じて Kubernetes には接点があった ことから、最近のトレンド情報を収集しておきたい、という動機がありました。
結果として、NASEBANAL の事業にもつながるインサイト を持ち帰ることになりました。変わったのは「アプリのランタイム環境として K8s を選ぶべきだ」という方向ではありません。ランタイム環境ではない用途で、K8s が有力な選択肢として立ち上がってきた、という方向です。
上の写真は、KubeCon のコホストイベントとして本編の前日に開かれた「KubeAuto Day Japan」の様子です。テーマは "Making Kubernetes Smarter through AI-Driven Automation"。本稿で扱う学びのうち、②と④はこのイベントでの議論が中心になっています。
以下、特に学びの大きかった 4 点を順に振り返ります。
2. 学び① — Harness（テスト実行環境）としての K8s
まず一番の収穫は、K8s を アプリの実行環境ではなく、テストの実行環境（Harness）として捉え直す 視点でした。
直近で参加したプロジェクトでも、CI/CD パイプラインで Self-Hosted Runner を使い、プライベートネットワーク上でジョブを実行する場面がありました。そしてその Runner 群を束ねていたのが K8s です。振り返ってみれば、これは特殊な事情ではありません。プライベートネットワークからしかアクセスできないサービスとの連携をテストしたい という要件は、エンタープライズの開発では珍しくないどころか、むしろ標準的です。GitHub-hosted の Runner ではネットワーク的に届かない。だから Self-Hosted Runner を立てる。では、その Runner をどうスケールさせ、どう使い捨てにするのか——という問いに対して、K8s は今日もっとも有力な解のひとつです。
NASEBANAL との関連性
この観点は、私が取り組んでいる API の品質保証 と素直につながります。前々回 書いた Contract-Driven Development では、Specmatic の Stub を立てて Consumer 側のテストを回し、Provider 側では実際のサービスに対して契約テストを実行しています。いまは自分ひとりの環境なのでローカルとホスト型 Runner で完結していますが、この仕組みを お客様のプライベートネットワーク内の API に対して適用する となった瞬間、話は変わります。Stub も契約テストも、ネットワーク的に届く場所で動かさなければ意味がありません。そのとき「テスト環境を宣言的に立てて、使い終わったら壊す」ための基盤として、K8s が現実的な選択肢として浮かび上がってきます。
つまり NASEBANAL にとっての K8s は、アプリを載せる場所ではなく、品質保証の仕組みを載せる場所 かもしれない——これが今回の一番の視点の転換でした。
この文脈で印象に残ったのが、メルカリ社の 「CI as the Guardrail for AI-Native Development」 というセッションです。高速で信頼できる unit / e2e テスト、リグレッションテスト、セキュリティスキャン——これらを ガードレールのためのプラットフォームとしての CI と位置づけ、そのプラットフォームをスケールさせることが AI ネイティブ開発を加速させる中核コンポーネントの改善になる、という主張でした。
AI がコードを書く量が増えれば増えるほど、そのアウトプットを受け止める検証の器の重要性が上がります。そして、その器を大量・並列・使い捨てで回そうとすると、結局それを支える実行基盤の話になる。ここから、Harness としての K8s 利用に興味を持ちました。
3. 学び② — エージェントに何を期待するか：Probabilistic と Deterministic
2 つ目は、エージェントのアーキテクチャをめぐる議論 です。そもそもエージェントに何を期待するのか。今回はこの論点に多くの時間が割かれていました。
その象徴が、KubeCon 本編の前日に開かれた KubeAuto Day Japan の Fireside Chat、Kelsey Hightower 氏と Cast AI の President & Co-Founder である Laurent Gil 氏による "From 'The Hard Way' to 'The Invisible Way'" です。
セッションで Kelsey Hightower 氏が語っていたのは、こういう趣旨でした。Kubernetes はそもそも「アプリを安定して稼働させる」というシンプルなミッションのために作られたもの であり、本来、必ずしも複雑性が要求されるものではない。だからこそ、その次のフェーズとして Invisible——使う側から見えなくなっていく 方向に進んでいくのだ、と。"Kubernetes The Hard Way" の作者が語る "The Invisible Way" というタイトルは、そのまま Kubernetes というプロダクトの成熟の物語でもあったわけです。
そして、その議論の流れの中で、昨今の エージェント に話が及びました。私が強く興味を持ったのはここからです。
Kelsey Hightower 氏が触れていたことでもあり、また個人的にも感じていることですが、いまエージェントに対しては過剰な期待が起きている ように思います。
ここで前提を揃えておくと、本稿で言うエージェントとは、Claude のような AI エンジンに、RAG のような仕組みで追加のコンテキスト情報を与えたり、MCP を組み合わせて作業を指示したりするためのインターフェースを指しています。そのキーワードは Probabilistic（確率論的） です。そして、それに対置されるのが Deterministic（決定論的） です。
- Probabilistic である限り、回答は確率に基づいて生成されます。したがって出力には揺らぎが生じ、時に誤りが混じります。
- Deterministic なアプローチは、まさにルールベースのプログラミングが該当します。ロジックによる安定性が期待できます。
以前参加したプロジェクトでも、知識の属人化 が危惧され、その解としてエージェントの活用が期待されていました。しかし、トランザクションの都度 AI を呼び出す となると、どうしてもコストの問題は避けられません。さらに誤りの発生もあるため、時に人間によるダブルチェックが必要になります。コストと検証工数が、トランザクション数に比例して増えていくわけです。
エージェントは今日においては、確率論による誤りを有するのみならず、各トランザクションで LLM の推論を用いるとなると、それこそ 消費電力量の問題 も無視できなくなってくると感じます。だからこそ、とりわけ 同じ質問を繰り返しエージェントに投げるような処理——毎回ほぼ同じ判断を求めるトランザクション——であれば、AI に一度ルールベースのコードを書かせ、人間がダブルチェックしたうえで、そのコードを回す ほうがよいのではないか、と考えています。都度エージェントに聞き直すのではなく、答えが安定している部分はコードとして固定してしまう、ということです。そうすることで、これまで DX 化が進まなかった領域にも幅広くデジタル化が進み、それ自体はうまくやれれば 環境コストの低減 にもつながるのではないか。
Probabilistic なプロセスは設計時に一度だけ通し、実行時は Deterministic に倒す。前回のブログ で書いた「Figma のスクリーン設計を中間成果物として人間の手で固めてから実装に入る」という話とも、中間成果物を人間がダブルチェックしたうえで実装に落とす という点では似たところがあります。
なお、エージェントを実際に動かそうとすると、必ず コスト の話に行き着きます。その論点は学び④で改めて取り上げます。
4. 学び③ — 障害時のルートコーズ調査におけるエージェントの活用
3 つ目は、NVIDIA による発表で示された、障害時のルートコーズ調査へのエージェント活用 です。自分のプロダクト運用にも関係するテーマでした。
構成としては、Agent Host が Metrics MCP → Prometheus / Thanos、Logs MCP → Grafana Loki、Skill MCP → 承認済み Runbook という 3 つの経路を持ちます。インシデントのコンテキストを引き回しながら、次に投げるべきスコープ付きの問い合わせを選び、答えを組み立てていく。つまり Prometheus 上のメトリクスと Grafana Loki 上のログに MCP 経由でアクセスし、プロンプトを調整することで、障害時のルートコーズ調査に役立てる というアプローチです。
このスライドで強調されていたのが、「MCP はインターフェースを標準化するが、各データソースは自身の語彙・認可・ポリシーを保持する」という一文でした。ここも、学び② の Deterministic の話と地続きです。エージェントに全データへの無制限アクセスを与えるのではなく、MCP という標準化された口を通しつつ、権限とポリシーは各ソース側が握り続ける。エージェントの自由度を上げながら、ブラスト半径は上げない設計と言えます。
昨年参加した Linux Conference でも感じたことですが、オープンソースの実行形態がどんどん K8s 上でカバーされてきています。自前でオープンソースのサービスを立ち上げたいと思ったとき、K8s はもはや無視できない選択肢です。そこに MCP でエージェント連携を作り込めば、ルートコーズの早期発見 は確かに実現できるかもしれません。
5. 学び④ — エージェントにおける FinOps
4 つ目は、エージェント利用そのものに対する FinOps です。学び②の最後で触れたとおり、エージェントを実際に動かせば必ずコストの話に行き着きます。KubeAuto Day では、Cast AI と Kimchi の双方から、エージェント利用にあたっての FinOps の議論 があり、実用的で興味深い内容でした。
Cast AI — キャッシュと、Token In / Token Out
Cast AI 側からのコメントで印象に残ったのは、エージェント利用のコストを考えるとき、問い合わせのかなりの部分は実はキャッシュで対応されている という指摘です。そのうえでコストファクターとなるのは Token In と Token Out であり、特に Token In のほうがコストへの影響が大きい（私の記憶では Out よりも、という趣旨でした）という話でした。
ここが私にとっての学びでした。ポイントは、Token In と Token Out では単価が異なる ということです。Claude の場合、出力の単価は入力のおよそ 5 倍。つまり「トークンを合計で何個使ったか」ではコストは測れず、In と Out を区別したうえでコスト試算をする必要がある、ということになります。
そのうえで、単価の高い Out ではなく In のほうが総額に効いてくるのは、実際に流れる量が In のほうが圧倒的に多い からです——コンテキスト、RAG で流し込む参照情報、会話履歴、ツール定義。それらが毎回の呼び出しに乗ってきます。単価差が 5 倍でも、量の差がそれを上回れば In が支配的になる。さらに In 側は、キャッシュヒットした分の読み出しが入力単価の 1 割程度で済むため、ここでも区別が要ります。結果としてコスト試算の単位は「トークン総数」ではなく、Token In（キャッシュヒット／ミス別）と Token Out という内訳になります。
正直に言うと、Token In と Token Out に分けてトークンが管理されていること自体は、以前、自分で調べた際にも目にしていました。ただ、その両者で単価が異なり、区別したうえでコスト試算をする必要がある、という点までは考えが及んでいませんでした。
Kimchi — オープンソースエンジンの精度向上と「ベストミックス」
もうひとつが Kimchi（ターミナル上で動くコーディングエージェント）側の議論です。セッションで示されていたのは Multi-model orchestration——Planner / Builder / Reviewer / Explorer / Researcher / Judge といった 7 つの専門ロールを用意し、オーケストレーターがタスクごとに最適なモデルへ自動でルーティングする、というアプローチでした。
これが効いてくるのは精度の面だけではありません。今日において、Kimi のようなオープンソースエンジンの精度が上がってきている。だからコスト最適化を考える場合には、すべてを最上位のモデルで回すのではなく、ベストミックスを考えることで実現できる——タスクの性質に応じて、精度が要るところには高性能なモデルを、そうでないところには軽量・安価なモデルを割り当てる、という考え方です。そして Kimchi は、その使い分けを支えるオープンソースソフトウェア として紹介されていました。
つまり Multi-model orchestration は、単に「精度を上げるための構成」ではなく、コスト最適化の実装手段でもある ということです。そう捉え直すと、同じセッションで示されていたダッシュボードの意味もはっきりします。Total Cost、API Calls、Avg Duration、Error Rate、そして モデル別の使用量——エージェントの実行を、コストとレイテンシとエラー率という運用指標で見る発想です。
この議論を聞きながら思い出していたのが、以前 NASEBANAL API Specs の Cookbook で紹介した、ソフトウェア開発でどれくらいのトークンが利用されているのかを NASEBANAL Recorder を用いて可視化する レシピです。Claude Code の Stop hook を使い、Input / Output / CacheRead / CacheCreate の 4 種類をプロジェクト別の時系列として記録するというものでした（紹介したブログ記事）。
当時は「自分の開発コストを把握したい」という個人的な動機で作ったものですが、まさに Cast AI が挙げていた Token In / Token Out / キャッシュという切り口そのものです。そして今回、多くの人がこの領域をビジネスとして注目している ことが分かりました。エージェントのトークン消費を可視化し、最適化する——ここには確かに市場があるようです。
6. まとめ
振り返ってみれば、KubeAuto Day での Kelsey Hightower 氏の話にも共通するところですが、私が聞いた範囲での今年の KubeCon は「K8s そのものをどう使うか」という議論よりも、「AI / エージェント開発において K8s をどう使うか」「それをどうコスト最適化するか」という議論が多かった ように思います。K8s の利用実績が積み上がり、運用が枯れてきたからこそ、関心がその上のレイヤーへ移っている。新たなステージに移ってきている という印象を持ちました。
そして NASEBANAL にとっても、K8s の利用可能性が改めて意識される 2 日間でした（本編 2 日目に参加できなかったのは心残りです）。アプリのランタイムとしてではなく、品質保証の Harness として、あるいは将来のオブザーバビリティ基盤の土台として。
タイミングを見て、昨年失効してしまった CKA / CKAD を再取得 し、内製化支援にあたって K8s もカバーできるようになることを目指したいと思います。
