Vagrantは、仮想マシンで動く開発環境をVagrantfileという1枚の設定ファイルに書き、チーム全員が同じ手順で起動できるようにするHashiCorpのツールです。2026年10月時点の最新版は2.4.9で、ライセンスはBSL 1.1に変わっています。さらに、boxの配布元だったHCP Vagrantは、2026年12月31日が運用終了日です。この記事では仕組みと起動手順を設定例つきで示したうえで、box配布の移行作業と、Dockerコンテナへ寄せるべき場面の切り分けまでを扱います。
まとめ：Vagrantを今から選ぶ条件とコンテナへ寄せる条件
新規の開発環境はコンテナで組み、Vagrantは「カーネルやOSそのものを開発対象にする案件」と「既存のVagrant環境を保守している案件」に限って使う。これが2026年10月時点の結論です。
- Vagrantの役割：VirtualBoxやHyper-Vなどの仮想化製品を、Vagrantfileと
vagrant upで同じように操作するための管理層 - 現行版：安定版は2025年8月21日公開の2.4.9。2.4.3以降はBSL 1.1で、社内の開発用途なら利用に制限はかからない
- 直近の期限：HCP Vagrantは2026年10月1日にbox新規作成を止め、12月31日に運用を終える。共有boxを参照しているVagrantfileは保管先の切り替えが要る
- 使い分け：アプリの実行環境をそろえたいだけならDev ContainerやDocker Composeで足りる。Windowsゲスト、BSD、カーネルモジュール、systemdを含むOS設定の検証はVagrantの領分
Vagrantとは仮想マシンの開発環境をVagrantfileで定義して配るツール
VagrantはHashiCorpが開発したオープンなコマンドラインツールで、仮想マシンの作成から起動・設定・破棄までをvagrantコマンドにまとめます。仮想マシン自体を動かすのはVirtualBoxやHyper-Vで、Vagrantはそれらを同じ書式で扱うための管理層という位置づけです。公式リポジトリのREADMEは、ローカルの仮想化製品だけでなくクラウドやコンテナ上でも開発環境を扱えると説明しています。
仮想マシンとコンテナがどう違うのかという前提は、コンテナと仮想マシンの違いから導入判断までをまとめた解説で整理しています。Vagrantが作るのはゲストOSのカーネルごと動く仮想マシンだという点を押さえておくと、後半の使い分けが読みやすくなります。
box・プロバイダ・プロビジョナで仮想マシンを組み立てる構造
Vagrantの動きは、部品の役割を分けると理解しやすくなります。boxはOSのディスクイメージと設定をまとめた配布単位で、プロバイダはそのboxを実際に動かす仮想化製品です。プロバイダのドキュメントによると、VirtualBox・Hyper-V・Dockerは同梱で、VMwareなどはプラグインで足します。
プロビジョナは、起動した仮想マシンにパッケージや設定を入れる仕組みです。シェルスクリプトからAnsible・Chef・Puppetまで選べます。この3つをVagrantfileに書けば、新しいメンバーはリポジトリを取得してvagrant upを打つだけで同じ環境を手にできます。
最新版2.4.9とBSL 1.1ライセンスで確かめておく利用条件
公式のインストールページで最新と表示されているのは2.4.9です。CHANGELOGでは2.4.9の公開日は2025年8月21日で、VirtualBox 7.2への対応が入りました。次の2.4.10は開発版のまま未リリースで、更新の間隔は1年以上空いています。
ライセンスも確認が要ります。リポジトリのLICENSEはBusiness Source License 1.1で、対象はVagrant 2.4.3以降、ライセンサーはIBMと書かれています。組織内での利用は競合提供に当たらないと明記されているため、受託開発や社内の開発環境で使う分には問題になりません。Vagrantを組み込んだ有償の環境提供サービスを作る場合だけ、条項を読み込む必要があります。
VirtualBoxでUbuntuを起動するVagrantfileの書き方とコマンド
ここからは手を動かす手順です。Vagrant 2.4.9とVirtualBox 7.2系を組み合わせ、Ubuntu 24.04の仮想マシンを1台作ります。VirtualBoxプロバイダのドキュメントは、対応範囲を4.0系から7.2系までとし、ベータ版のVirtualBoxは対象外としています。
インストールからvagrant upまでの手順とApple Silicon機の注意
先にVirtualBoxを入れ、その後でVagrantを入れます。VirtualBoxのダウンロードページでは7.2.22が配布されており、macOSのApple Siliconホスト向けパッケージも用意されています。Vagrantの導入方法は、macOSならHomebrew、WindowsやLinuxなら公式パッケージです。
# macOS（Homebrew）
brew tap hashicorp/tap
brew install hashicorp/tap/hashicorp-vagrant
# 版の確認と初回起動
vagrant --version
mkdir vagrant-demo && cd vagrant-demo
vagrant init bento/ubuntu-24.04
vagrant up
vagrant sshApple Silicon機ではboxのアーキテクチャが合っていないと起動しません。boxを作るbentoプロジェクトのREADMEは、arm64のboxにはVagrant 2.4.0以降とVirtualBox 7.1.6以降が要ると明記しています。Intel機で作ったVagrantfileをそのまま配ると、M系チップのメンバーだけ起動しない事態が起きます。
Vagrantfileでメモリ・ポート転送・共有フォルダを指定する設定例
vagrant initが作るVagrantfileはRubyの書式です。実務で触るのはbox名、ネットワーク、共有フォルダ、プロバイダごとの資源割り当て、プロビジョニングの5か所に限られます。次の例は、Webアプリの開発用にポート8080を転送し、2GBのメモリを割り当てる構成です。
Vagrant.configure("2") do |config|
config.vm.box = "bento/ubuntu-24.04"
config.vm.box_architecture = :auto # ホストに合うamd64/arm64を選ぶ
config.vm.hostname = "dev-web"
config.vm.network "forwarded_port", guest: 80, host: 8080
config.vm.synced_folder "./src", "/var/www/app"
config.vm.provider "virtualbox" do |vb|
vb.memory = 2048
vb.cpus = 2
end
config.vm.provision "shell", inline: <<-SHELL
apt-get update
apt-get install -y nginx
SHELL
endbox_architectureに:autoを渡すと、ホストのアーキテクチャに合うboxを取りに行きます。config.vmの設定一覧には、指定できる値の一覧が記載されていますので確認してください。Intel機とApple Silicon機が混在するチームでは、この1行を入れるかどうかで起動できる人が変わります。
プロビジョニングの再実行とvagrant destroyで環境を作り直す操作
見落としやすいのが、プロビジョニングの実行タイミングです。プロビジョニングのドキュメントによると、自動で走るのは環境を作る最初のvagrant upだけで、停止後の再起動では実行されません。設定を書き換えたらvagrant provisionかvagrant reload --provisionで明示的に流します。
環境が壊れたときはvagrant destroy -fで消し、vagrant upで作り直すのが基本の運用です。シェルの手順が長くなってきたら、構成管理ツールへ移す時期です。Ansibleのエージェントレスの仕組みとメリット・デメリットを押さえておくと、Vagrantのansibleプロビジョナへ書き換えるときに、本番サーバーと同じPlaybookを開発環境でも流せます。
HCP Vagrant終了でbox配布が止まる2026年12月までの移行作業
2026年に入ってから起きた変化のなかで、Vagrantの利用者に最も影響が大きいのがこの件です。vagrant init bento/ubuntu-24.04のような短い名前のboxは、HashiCorpが運営するHCP Vagrant（旧Vagrant Cloud）から取得されています。その配布基盤が終わります。
2026年10月1日・11月2日・12月31日の段階で止まる機能
HCP Vagrantの終了告知は、次の日程を示しています。対象はHCP Vagrantだけで、Vagrant CLI自体は引き続き使えます。
| 日付 | 止まるもの | 利用者への影響 |
|---|---|---|
| 2026年10月1日 | boxとレジストリの新規作成 | 新しいboxを公開できない |
| 2026年11月2日 | サポートと保守 | 障害時の問い合わせ先が無い |
| 2026年12月31日 | 運用そのもの | 短縮名のboxを取得できない |
告知は、利用者自身が配布先を用意し、そのホスティング費用も負うことになると明記しています。ローカルに取得済みのboxは消えません。ただし、新しく参加したメンバーの端末やCIでvagrant upを打つと、2027年以降はboxの取得で止まります。
boxを自社で保管しbox_urlとチェックサムで参照する設定
対策は、使っているboxを今のうちに取得し、社内のストレージに置いて参照先を書き換えることです。config.vm.box_urlはHTTPのURLやfile://形式のローカルパスを受け付け、配列で複数の取得先を順に試せます。改ざん対策として、チェックサムを必ず添えます。
# 取得済みboxを書き出し、ハッシュを控える
vagrant box list
vagrant box repackage bento/ubuntu-24.04 virtualbox 202510.26.0
sha256sum package.box
# Vagrantfile側は社内の保管先を参照する
config.vm.box = "internal/ubuntu-24.04"
config.vm.box_url = "https://files.example.internal/boxes/ubuntu-24.04.box"
config.vm.box_download_checksum = "<sha256の値>"
config.vm.box_download_checksum_type = "sha256"例の202510.26.0は、2026年10月21日時点でbento/ubuntu-24.04の最新として公開されている版です。repackageには、手元のvagrant box listに表示された値を渡してください。このboxはVirtualBox向けにamd64とarm64の両方が用意されているため、混在チームでは両方を書き出して保管します。boxを外部に依存しない形で作り直したいなら、Packerでboxそのものを生成する方法があります。Packerによるマシンイメージ自動構築の仕組みを使えば、OSのインストールからbox化までをコードで再現でき、配布元の終了に左右されません。
VMベースのVagrantとDockerコンテナを開発環境で使い分ける判断基準
HashiCorp自身もVagrant vs. Dockerの解説で、コンテナは軽く起動が速いこと、そしてBSDなどDockerが扱えないOSが本番の場合はVagrantのほうが本番と近い環境を作れることを挙げています。2つは競合ではなく、隔離する単位が違う道具です。
開発環境のカーネル共有の有無と起動時間・再現範囲を比べる早見表
判断に効く違いは、ゲストがカーネルを持つかどうかに集約されます。
| 観点 | Vagrant＋VirtualBox | Dockerコンテナ |
|---|---|---|
| カーネル | ゲストOSが自前で持つ | ホスト側のLinuxを共有 |
| 起動 | ゲストOSの起動を待つ | プロセスの起動だけで済む |
| 動かせるOS | Windows・BSD・各種Linux | Linuxが中心 |
| 再現できる範囲 | カーネル設定・systemd・ネットワーク構成 | アプリと依存ライブラリ |
| ディスク消費 | 1台ごとにOS全体を持つ | レイヤー共有で小さい |
起動時間とディスクの差は、メンバー全員の端末で毎日積み上がります。再現範囲の差が必要になる案件でなければ、コンテナを選ぶほうが運用は軽くなります。
Vagrantを残すべき案件とコンテナへ寄せるべき案件の線引き
Vagrantを使い続けてよいのは、次のどれかに当てはまる案件です。カーネルモジュールやiptables、systemdのユニットなどOS層の設定を開発・検証する場合。本番がWindows ServerやFreeBSDで、Linuxコンテナでは同じ挙動を再現できない場合。そして、複数台のサーバー構成をネットワークごと手元で組みたい場合です。
反対に、WebアプリやAPIの開発環境として使っているだけなら、コンテナへ寄せます。言語ランタイムとミドルウェアをそろえる目的なら、devcontainer.jsonで開発環境を統一する仕組みのほうが、エディタとの連携も起動速度も上回ります。Apple Silicon機が増えたチームで、amd64前提のboxを使い続けるのも見送るべき構成です。
既存案件のVagrant環境を引き継いでコンテナへ移す手順と失敗例
引き継いだ案件にVagrantfileが残っている場合、最初にやるのはプロビジョニングの中身の棚卸しです。シェルやPlaybookが入れているパッケージ、書き換えている設定ファイル、開いているポートを一覧にし、アプリの実行に要るものとOS管理用のものに分けます。前者だけをDockerfileへ移せば、移行の範囲が見えてきます。
よくある失敗は、config.vm.synced_folderのパーミッションやcronの起動に暗黙に頼っていたのを見落とすことです。コンテナでは同じ動きをしないため、移行後にファイル書き込みや定期処理だけが失敗します。古い環境の構成を読み解く人手が足りない場合は、一創の保守運用・内製化支援で、既存環境の調査から移行後の運用設計までをまとめて相談できます。
よくある質問
Vagrantの導入や既存環境の扱いについて、検索の多い質問に答えます。
Vagrantは無料で使えますか？
Vagrant本体は無料で入手でき、社内の開発環境として使う分に費用はかかりません。2.4.3以降のライセンスはBSL 1.1ですが、組織内での利用は制限の対象外と明記されています。VirtualBoxの本体はGPLv3です。一方、Extension Packは個人利用・教育用のライセンスなので、業務で入れる場合は条件を確認してください。
VagrantとDockerはどちらを使えばよいですか？
アプリケーションの実行環境をそろえる目的ならDockerを選びます。ゲストOSの起動を待たずに済み、ディスクの消費も小さいためです。ゲストOSのカーネル設定を触る、WindowsやBSDのゲストが要る、複数台のサーバー構成を再現したいといった条件があるときだけVagrantを使います。なお、VagrantにはDockerをプロバイダとして扱う機能もあります。
HCP Vagrantが終わると既存のVagrantfileは動かなくなりますか？
手元に取得済みのboxがある端末では、そのまま起動できます。止まるのは、boxをまだ持っていない端末で短縮名のboxを取得するときです。2026年12月31日の運用終了後は取得できなくなるため、それまでにboxを社内の保管先へ移し、config.vm.box_urlで参照する形へ書き換えてください。
Apple Silicon搭載のMacでもVagrantは使えますか？
使えます。Vagrant 2.4.0でアーキテクチャの指定に対応し、VirtualBoxもApple Siliconホスト版を配布しています。ただし動かせるのはarm64のboxで、amd64のboxは起動しません。bentoのarm64版boxはVirtualBox 7.1.6以降が条件です。Vagrantfileにconfig.vm.box_architecture = :autoを書いておくと、Intel機との混在に対応しやすくなります。
Windowsで使うときにHyper-Vと競合しませんか？
Windowsでは、Hyper-Vが有効な状態でVirtualBoxを動かすと、VirtualBoxがHyper-Vの仮想化基盤の上で動作するため速度が落ちる場合があります。WSL 2やDocker Desktopを併用している端末ではHyper-V系の機能が有効になっていることが多いので、VagrantのプロバイダをHyper-Vにそろえる選択も検討してください。Hyper-Vプロバイダは同梱されています。
関連記事
- Docker VMMとは？WSL 2・Apple Virtualizationとの違いと切り替え手順：コンテナ側の開発端末で仮想化層がどう動いているかを確認できます
- docker-composeとは？複数コンテナをymlで定義し一括管理する仕組みを解説：Vagrantの複数台構成をコンテナへ置き換えるときの書き方が分かります
- Dockerの仕組みを図解｜コンテナ隔離・アーキテクチャ・VMとの違いを実機コマンドで確認：カーネル共有という違いを原理から確認できます
- Hyper-Vの有効化と仮想マシン作成手順｜PowerShell操作とWSL2との併存：WindowsでVagrantのプロバイダにHyper-Vを選ぶときの前提になります
- WSLで開発環境を構築する手順｜.wslconfig調整とDocker連携・肥大化の対処：Windows端末で仮想マシンを使わずにLinux環境を用意する選択肢です
