生成AIがコードを書く時代にKubernetesのPodをローカルで実行しつつクラスターをテストできるツールを紹介

The Cloud Native Computing Foundation（CNCF）のWebinarから、KubernetesのPodをローカルでテストしながら、クラスターに大きな変更を行わずにインテグレーションテストを行えるMirrordの動画を紹介する。プレゼンテーションを行ったのはMetalBearのエンジニアであるArsh Sharma氏とJake Page氏の2名だ。動画は以下から視聴できる。

●リンク：What Happens After AI Writes Code

動画の最初のパートでは、Sharma氏がPage氏に「何をやっていたの？」と聞き、Page氏が「生成AIでコードを生成してそれを生成AIが書いたテストで検証、問題がなかったのでそのままステージング環境にデプロイした」と答える小芝居から始まった。開発のマネージャー役として「え？ そんなことしたの？ 生成AIがコードを書いて同じ生成AIがテストを書くならパスするに決まってるし、単体テストは良くてもインテグレーションテストはパスしないんじゃないの？ それはダメだよ」というやりとりを見せながら、生成AIがコードを書く時代にはこういう事態が頻発するだろうということを示唆した。

生成AIがコードを書いた後に起こることは何か？」というタイトルのセッション

ここですでに多くのデベロッパーが生成AIを使っていることが2025年に行われたデベロッパー向けの調査において明らかになっていることを示して、すでにAIがソフトウェア開発のプロセスに取り込まれていることを解説した。実際、ここに示されている「50％以上のデベロッパーが毎日なんらかの生成AIのツールを使っている」という結果は、2026年の時点ではさらに数値が大きくなっていると思われる。

デベロッパー向けの調査を紹介。ほぼ毎日、生成AIを使うデベロッパーはすでに50％を超えている

そしてソフトウェア開発におけるコーディング、単体テスト、インテグレーションテスト、コードのレビューというプロセスに生成AIが使われているが、このセッションでは単体テストとインテグレーションテストのプロセスにボトルネックが発生していることを示し、これがこのセッションで解説するポイントであると説明した。そしてこの課題を解決するのがMirrordというわけだ。

単体テストとインテグレーションテストのプロセスにボトルネックが発生している

開発プロセスの中で生成AIが使われている状況では、コーディングアシスタントがコードを生成し、デベロッパーのローカルマシンでテストを実行し、成功した後にステージング環境にプッシュしてインテグレーションテストを行うというループが実行されていることを説明。ここから単体テストとインテグレーションテストで発生するボトルネックを詳しく解説した。

デベロッパーが使うPCでの単体テストの環境と本番環境との違いが問題の原因

デベロッパーが使うPCの性能は年々向上していることから、すべてをクラスター上で行うのではなくローカルPCで実行するほうがコスト的に優位であるという点に関しては、2024年に書かれたCI/CDをローカルPCで実行するDaggerの記事を参照して欲しい。

●参考：KubeCon North America 2024から、ローカルPC上でCIを実行することでクラウドコストを激減させるDaggerのセッションを紹介

DaggerはSaaSのCI/CDサービスが開発プロセスをコスト的に圧迫していることを課題と捉え、ソリューションを開発したベンチャーだが、Mirrordを開発するMetalBearはそれをテストに応用するという発想だ。

生成AIが書いたコードをローカルでテストしてもステージング環境と違ってしまう

CI/CDについても毎回、クラスターにデプロイされることで時間がかかり、コストも必要となることを訴求。マイクロサービスの場合、多くの小さなサービスが連携して稼働することから、機能的に動いたとしても実際に性能的なテストをパスできるのか？ この点についてはこのフェーズをステージング環境で検証する必要がある。

CI/CDにも時間がかかり、コストも必要。そして多くのバグがここで発見される

そしてこの問題の根幹は「コードをテストするためにローカルPCからクラスターにコードをプッシュする必要があることだ」とまとめた。その結果、多くの時間とコストが無駄になるというのが主張だ。これはマイクロサービスなどが稼働するクラスターに、実際に新しいコードを入れてテストを行わないとインテグレーションテストにならないという大前提を確認した格好となっている。

問題の根幹は「コードをテストするためにローカルPCからクラスターにコードをプッシュする必要があること」

ここでもう一度、ローカルPCで実装したコードをクラスターで実行することが必要であること、CI/CDについてもステージング環境でデプロイしないとインテグレーションテストが終わらないことを確認した。

コードがローカルPCで動いても実際にクラスターで動くかどうかはわからない

CI/CDを検証するためにはクラスターにデプロイする必要があり、時間とコストが必要

そこでMetalBearが推奨する方法は「Remocal」による開発であると説明。RemocalはRemoteとLocalを組み合わせた新語だが、ローカルで生成されたコードをリモートに繋いで開発を行うというスタイルを表現していると思われる。

リモートとローカルを結合したRemocal開発を推奨

ここではローカルPCで新サービスを稼働させ、それをクラスターの他のサービス、アプリケーションと接続するという発想だ。ポイントは新しくコンテナを作り直したり、クラスター側の設定を特別なものにしたりする必要がないという部分だろう。

ローカルのPCがクラスターの他のサービスと接続してテストを実行

これを可能にするのが、Mirrordというオープンソースソフトウェアだ。同じような発想のソフトウェアとして紹介されたのはTelepresenceだ。Telepresenceもローカルのアプリケーションをリモートのクラスターに接続して実行するためのソフトウェアだが、TelepresenceがOperatorを使ってローカルPCをリモートのクラスターに接続させるという発想なのに対して、MirrordはローカルのPodをKubernetesに接続するという発想である。Mirrordの実装方法は、クラスター側に追加のソフトウェアを導入する必要がないこととさまざまな用途に実装のコストなしに応用できることが強みだろう。

Telepresenceを同じカテゴリのソフトウェアとして紹介

Mirrordのアーキテクチャーを簡単なイラストで紹介。ここではローカルのPCで稼働するPodがクラスター側のMirrordのPodと接続し、MirrordのPodが仲介役として動作することが示されている。

Mirrordのアーキテクチャーを簡単なイラストで紹介

Mirrordが可能にすることをリストとして紹介。きめ細かな制御が可能であることが要点であり、Telepresenceとのアーキテクチャーの違いが現れている部分でもあると思われる。

Mirrordでできることをリストで紹介

ここから実際にVisual Studio CodeでECサイトのデモを開発するというモデルを使ってMirrordを解説する内容となった。

簡単なECサイトを構築するデモでMirrordを紹介

このデモはフロントエンドから在庫をチェックするサービスが在庫情報をPostgreSQLから獲得し、それに対してユーザーが購入、決済は外部サービスに、オーダーによる在庫などの更新はKafkaのメッセージングを経て配送サービスに送信という仕組みになっている。

ブラウザーの開発ツールを使ってメッセージを確認しながらデモを実行

ここでは実際にVisual Studio Codeを開いてオーダーが確定した時のメッセージを書き換えてビルドを実行し、ローカルで実行しているモジュールがステージング環境の他のサービスと通信しながら実行される部分を解説している。

ローカルPCで実行しながら、他のサービスとも連携してテストを実行

デモののち、まとめとしてこのプロジェクトの公式ページを紹介し、約30分のセッションを終えた。

最後にMirrordについてClaude Sonnet 4.6と対話して解説させた内容を紹介しよう。筆者がClaudeにこのソフトウェアは「マイクロサービスにおけるアプリケーションプロキシーですか？」と質問した時にClaudeは「半分正しく、半分は少し違います」と答え、その理由として「EnvoyやNginxのようなサービス間通信を仲介するプロキシーではなく、開発者のローカル環境とクラスターを繋ぐ開発ツール」であるため、正確に表現すれば、「Kubernetes対応のローカル開発・デバッグツール」であり、より良い表現として「ローカルークラスター文脈ブリッジ（Local-Cluster Context Bridge）」が正確に機能を表していると回答した。これは双方向の「文脈（context）」の橋渡しという本質を表し、最も正確であるという。プロキシーがサービスメッシュやゲートウェイを想定してしまうことからあえて使わないほうが良いというのは的を射ていると言える。

またこれは開発用ツールであり定常的に本番環境で使われるものではないということを強調していたことも最新のAIらしい回答と言えるだろう。ちなみに同じような質問をCopilotに送ったところ、Mirrordのことを「実行環境プロキシー」と命名したことから考えれば、Claudeの理解の深さが感じられるかもしれない。Mirrordの開発元であるMetalBearは「開発の時点ではLLMをローカルで実行して、その他のサービスをクラスターで実行することで生成AIに関するコスト問題を解決できる」と訴求しているが、Claudeによれば「『クラウドLLMのコストを下げる』という利点はMirrordの特性ではなく、ローカルLLMツール（Ollama等）の利点です。Mirrordはそれらと組み合わせて『クラスター環境に繋ぎながらローカルLLMで開発・検証する』用途には使えますが、それはMirrord単体の利点とは言えません」とシビアな回答を出してきた。流行に乗ったマーケティングメッセージも大規模言語モデルによって素顔が暴かれる時代になってきている。

●公式リポジトリ：https://github.com/metalbear-co/mirrord