はじめに
みなさん、ローカルの開発環境ってどう管理していますか？ 僕は正直、プロジェクトごとに様々なツールや依存関係が入り乱れて、ローカルPCがどんどんカオスになっていくのがあまり好きではありません。
そこで今回は、その解決策としておうちKubernetes上に「使い捨てできるリモート開発環境（Coder）」を構築することにしました。 ただ、構成を考え始めた当初、私にはもう一つちょっとした野望がありました。 「出先やベッドで寝転がりながら、スマホでCopilot CLIやClaude Codeを叩いて、サクッと開発したい」というものです。
ですが、実際にやってみると現実は甘くありませんでした。スマホ画面ではcode-serverのUIが絶望的に見づらく、ターミナルでの細かい操作も非常にストレスがたまります。モバイルからのコーディングは、一旦見送ることにしました。
ということで、今回の着地点は「ブラウザから利用する、ローカルを完全に捨てていける隔離された開発環境」の構築です。PCブラウザをインターフェースとし、ローカルPCを汚さずに済むクリーンなリモート環境を目指します。
Coderのインストールとインフラ準備
前提として、おうちKubernetes（今回はMicroK8s）が構築されている環境を想定しています。バックエンドとしてPostgreSQLが必要になりますが、これはNamespace内に立てても、外部のDBを使っても構いません。ご自身のインフラ事情に合わせて選んでください。
デプロイにはArgoCDとHelmを使用しました。特別な操作は必要なく、公式のHelmチャートを読み込むだけです。参考までに、ベースとなる Chart.yaml を記載しておきます。values.yaml については環境に合わせてよしなに設定してください。
apiVersion: v2name: coderdescription: A Helm chart for Coder with custom homelab configurationstype: applicationversion: 0.1.0dependencies: - name: coder version: 2.30.0 repository: "https://helm.coder.com/v2"使い捨ての環境なので、ストレージは特別なプロビジョニングを行わず、Hostのストレージをそのまま利用します。MicroK8sを使っている場合は microk8s enable hostpath-storage コマンドでアドオンを忘れずに有効化しておきましょう。これを忘れると後でPodが起動しなくて首を傾げることになる、という罠だ。
環境のプロビジョニング
k8sへのArgoCD applyが完了したら、CoderのGUIにアクセスします。
GUI上から、デフォルトで用意されている k8s deployment template を選択して開発環境を作成します。カスタムテンプレートを作ることもできますが、最初はこれで十分です。
設定ミスがなければ、すぐにサーバーが立ち上がります。
立ち上がった環境で「code-server」のアイコンをクリックすると、ブラウザ上でVS Codeがスッと開きます。
これで環境構築はほぼ完了です。
リモート開発の体験
ブラウザからURLにアクセスし、OIDCログインを経てStartボタンを押すと、即座にブラウザでVS Codeが起動する。この一連の流れるような体験は非常に滑らかで、良い意味で期待を裏切られました。
パフォーマンスについても想定以上でした。私の環境はN150クラスの省電力CPUですが、k8s側で適切にリソース制限（Requests/Limits）をかけておけば、ローカルPCと遜色のない快適なエディタ体験が得られます。
ただ、運用を続けているとリアルな課題も見えてきました。 環境を立ち上げるたびに、OIDCログインやターミナルからのGitHubへのログインをやり直すのが地味に面倒ってことです。もちろん「完全に隔離されたクリーンな使い捨て環境」であることの裏返しではありますが、毎回ターミナルで認証を通すのは流石にスマートではありません。
自動停止（Auto-stop）を有効にしておいた場合、使い終わるとPodが消滅してk8sのリソースがきれいに解放されます。このお行儀の良さは、限られたリソースしか持たないおうちk8sにおいては大きなメリットです。
Tips: k8s特有のトラブルシューティング
読者の皆さんが同じ轍を踏まないよう、初期構築で遭遇しやすいk8s特有のエラーを2つ共有しておきます。
「Agent has not connected yet.」から進まない
環境を立ち上げたものの、このメッセージが表示されたまま固まることがあります。このとき、CoderのウェブUI上には何のエラーログも出力されないことが多い。UI上で悩むのは早々に諦めて、kubectl logs を叩くか、ArgoCDのGUIから直接Podのログを引っこ抜くのが手っ取り早い解決策です。
PVCがPendingのままになる
環境を作成する際にストレージの確保で止まるケースです。これは利用可能な StorageClass が正しく設定されていないか、先述の hostpath-storage のようなアドオンが有効になっていない可能性が高い。k8s側のストレージプロビジョナーの設定を真っ先に見直すと良いでしょう。
結論という名の「どんでん返し」と爆破予告
ここまで構築手順を解説してきてなんですが、あまり活用できる未来が見えなくなってきたので既に爆破しようかと思ってます。
Coderで自分専用のリモート環境を立てた直後は、「完璧な隔離環境ができた」と大満足していました。しかし、ふと冷静になって「Copilot Agent」「Claude Code」「Google Jules」といった最新の非同期AIエージェントの存在を考えたとき、一つの根源的な疑問が湧き上がってきたのです。
「AIエージェントが非同期で自律的にコードを書いてくれる時代に、わざわざ自分でリモートのVS Code環境（code-server）をk8s上でホストし、そのライフサイクルを管理する意味は一体どこにあるのだろうか？」
車輪の再発明はしたくないし、インフラの管理コストは極力ゼロに近いほうが良い。 ローカルを汚さないクリーンな環境は確かに魅力的ですが、AIエージェントとの役割分担が明確にならない限り、このおうちk8s上のCoder環境は近いうちに役目を終える可能性が濃厚です。
