これは2025年夏ごろの古いメモを記事に起こしたもの。今はだいたいAIにコーディングさせていてローカル開発環境への関心が当時ほど高くないので、結論というより「一度試して、こう判断した」という記録のノリで。
やろうとしたこと
container前提で開発するなら、いっそ開発環境ごとコンテナに閉じ込めるdevcontainerを使えるようにしたほうがいいんじゃないか、と思ったのがきっかけ。
イメージとしてはこう:
- Neovimでコンテナにアタッチして、その中で開発する
- Dockerfileもコマンド履歴あたりから半自動で起こせたら早そう
VS Codeのdevcontainer体験をnvimでやりたかった、というのが正直なところ。
試してわかったこと
実際にやってみると、思っていたほど噛み合わなかった。
- 起動が遅い。 数分レベルで待たされる。ちょっと触りたいだけなのに腰が重い。
- ストレージの無駄。 コンテナの中に開発ツール一式と、エディタ、プラグインまで入れることになる。プロジェクトごとにこれが積まれていく。
- そもそも自分で環境を用意できるなら要らない。 uvみたいな言語別のパッケージマネージャで環境分離はできてしまう。
「環境を汚さない」がdevcontainerの売りだけど、その目的なら他にも手段はある、というのが触ってみての感想だった。
結論: 個人開発なら優先順位はこう
環境構築スキルがある個人開発者なら、合理的な順序はこうだと思う。
nix > 言語別パッケージマネージャ > devcontainer- nix が一番きれい。宣言的に環境を固定できて、コンテナのオーバーヘッドもない。
- 言語別パッケージマネージャ(uv等)は手軽で、たいていの用途はこれで足りる。
- devcontainer はそのうえで、わざわざ選ぶ理由が薄い。
じゃあdevcontainerはダメなのかというとそうではなくて、「スキル差があるチーム」での最大公約数的な解決策として強い。「READMEのこのボタン押せば全員同じ環境」が効くのは、各自が環境を組めない前提のとき。個人開発はその前提に当てはまらない、というだけの話。
いま振り返って
冒頭のとおり、今はAIにコードを書かせることが増えて、手元の開発環境にこだわる場面自体が減った。それでも「コンテナに開発環境を閉じ込める」というアプローチを一度ちゃんと試して、自分の使い方には合わないと判断できたのは無駄ではなかった。道具は試して初めて要否がわかる。