← Vim研究所

DockerでVim/Neovimの検証用サンドボックス環境を作る

2019-11-16 公開 ・ 更新: 2026-08-20

新しいプラグインや設定を試したいとき、いきなり普段使いの設定ファイルに手を入れるのは怖いものです。かといって仮想マシンを都度立てるのは重すぎます。そこで、簡単に作れて簡単に壊せるDockerコンテナを検証用サンドボックスとして使う方法を紹介します。

目次（11項目）

検証環境に求める条件

VMwareやHyper-Vのような仮想マシンでもこの条件は満たせますが、起動の重さを考えるとコンテナ技術の方が検証用途には向いています。Windows/Linux/Macいずれのホストでも同じ手順で使えます。

ファイル構成

ローカル側にはこのような構成で用意します。

vim-sandbox/
├─ init.vim        ← コンテナにコピーする設定ファイル
└─ vim/             ← プラグイン等、コンテナのVim関連ディレクトリへマウントするファイル群

あらかじめ用意するinit.vimは、検証したい内容に応じて最小限で十分です。

syntax enable
filetype plugin indent on
set number
set nocompatible
set wildmenu
set colorcolumn=81

Dockerfileを用意する

Alpine Linuxベースのシンプルな構成にしておくと、イメージサイズを抑えつつVim・Neovim両方を試せます。

FROM alpine:edge
RUN apk update && apk upgrade && \
    apk add --no-cache \
      curl git gcc musl-dev linux-headers \
      vim neovim \
      python3 py3-pip && \
    rm -rf /var/cache/apk/*
ENV LANG="ja_JP.UTF-8" LANGUAGE="ja_JP:ja" LC_ALL="ja_JP.UTF-8"
RUN pip3 install --no-cache-dir --break-system-packages pynvim
RUN mkdir -p /root/.vim /root/.config/nvim
COPY init.vim /root/.vimrc
COPY init.vim /root/.config/nvim/init.vim
WORKDIR /root
ENTRYPOINT ["nvim"]

ビルドコマンドはこちらです。

docker build -t vim-sandbox .

300MB前後になる点には注意が必要です。試すたびに大量にイメージを作ってしまうと、あっという間にディスクを圧迫します。

コンテナを起動する

docker run -it --name vim-sandbox \
  -v "$(pwd)/vim:/root/.config/nvim" \
  vim-sandbox

マウントパスは必ず絶対パスで指定します。相対パス（./vimなど）は環境によって解釈されずエラーになることがあるため避けます。

要点：-vのマウント元パスは絶対パスで指定します。Windowsでも同様にフルパスを書きます。

再開・削除

編集を終えてVimを閉じるとコンテナも停止します。用途に応じて次のコマンドを使い分けます。

コマンド用途
docker start -ia vim-sandbox停止したコンテナを再開する
docker container rm vim-sandbox検証が終わったコンテナを削除する
docker container prune停止中コンテナをまとめて掃除する（必要なコンテナまで消さないよう対象範囲に注意）

プラグインを検証する

プラグインまで検証したい場合は、モダンなプラグインマネージャーであるlazy.nvimをコンテナ内にセットアップしても構いませんが、1回限りの検証であれば、Neovimに組み込みのパッケージ機能（:packadd）でGitHubから直接cloneして試す方が手早く済みます。

git clone --depth=1 https://github.com/{owner}/{plugin}.git \
  ~/.local/share/nvim/site/pack/tmp/start/{plugin}

コンテナを起動し直せば設定はまっさらな状態に戻るため、「入れてみたけど気に入らなかった」プラグインの後片付けを考えずに試せるのがメリットです。

OSコマンドが必要なとき

コンテナ内でパッケージを追加したくなった場合は、Vim/Neovimの:terminalコマンドでシェルを開き、そのままapk addすれば済みます。検証用途であれば、その場しのぎでコンテナ内に直接インストールしてしまっても問題ありません。

使ってみて

新しいLSP関連プラグインを試すときは必ずこのサンドボックスを経由するようにしています。普段使いの設定を汚さずに済むうえ、うまくいかなかった場合もコンテナごと削除すれば後始末を考えなくて済むので、気軽に色々試せるようになりました。

コンテナを立てずに試す方法

プラグインの不具合を切り分けるだけなら、コンテナを用意しなくても設定を読まずに起動できます。いちばん軽いのがこの形です。

vim -u NONE -N               " 設定を読まず、互換モードも切る
nvim --clean                 " Neovim の同等
vim -u ~/minimal.vim         " 最小の設定だけ読む

設定ディレクトリごと切り替えたいなら、環境変数を差し替える方法もあります。XDG_CONFIG_HOME を別のディレクトリに向けて起動すれば、Neovimは普段の設定を一切読みません。

XDG_CONFIG_HOME=/tmp/nvim-test XDG_DATA_HOME=/tmp/nvim-test-data nvim

この方法なら数秒で試せて、普段の環境にも触りません。コンテナが要るのは、OSやライブラリのバージョンまで変えて試したいときです。

コンテナで引っかかるところ

まず日本語です。Alpineの最小構成にはロケールが入っていないため、日本語を含むファイルを開くと表示が崩れることがあります。LANG=C.UTF-8 を指定するか、ロケールを扱えるベースイメージを選んでください。

次にクリップボードです。コンテナの中にはXサーバーもクリップボードもないので、"+y は動きません。手元に持ってくるにはOSC 52に対応した端末を使うか、ファイル経由で受け渡すことになります。

3つめは時間です。プラグインを入れて試すたびにネットワークからの取得が走るので、イメージの段階で入れておくか、ボリュームでキャッシュを共有すると待ち時間が減ります。

不具合を報告するときに使う

この環境がいちばん役に立つのは、プラグインの不具合を報告するときです。多くのプロジェクトは「最小限の設定で再現するか」を聞いてくるので、素の状態から必要なプラグインだけを足した環境を用意できると話が早く進みます。

再現手順と一緒に、使ったDockerfileや最小設定をそのまま貼れる状態にしておくと、相手が同じ環境を再現できます。自分の設定が原因だったと分かる場合も多いので、報告する前の切り分けとしても有効です。

まとめ

DockerでVim/Neovimの検証環境を用意しておけば、普段使いの設定を壊す心配なく新しい設定やプラグインを試せます。マウントパスを絶対パスにすることと、イメージの肥大化にだけ注意すれば、日常的な検証用途に十分使えます。手元を汚さずに試すという目的なら、VPS+SSHの構成やブラウザのクラウドIDEも同じ問題の別の解き方になります。

関連記事

← Vim研究所 トップへ戻る