Packer on Ubuntu — AWSカスタムAMIを自動ビルドするIaCの実践

「EC2 を新しく立てるたびに毎回 apt update からやり直し…」そんな経験がある方に向けて書いた記事です。Packer を使えば、Nginx や Python 環境があらかじめ入った「自分専用のカスタム AMI」を Ubuntu から自動ビルドできます。次回から EC2 を起動すれば5秒でセットアップ済みの環境が使えるようになります。

本記事では Ubuntu 24.04 LTS に Packer v1.15.4 を実際にインストールし、HCL テンプレートの書き方・packer validate による構文チェック・packer init によるプラグイン取得まで実行結果をそのまま掲載します。

目次

1. Packer とは何か — なぜ AMI を自動ビルドするのか
2. Ubuntu 24.04 に Packer をインストールする
3. HCL テンプレートの書き方
4. packer init — amazon プラグインをインストールする
5. packer validate — 構文チェックで事前にエラーを潰す
6. packer build — AMI ビルドの実行
7. SSH 鍵の生成と設定
8. よくあるエラーと解決策
9. まとめ

Packer とは何か — なぜ AMI を自動ビルドするのか

Packer は HashiCorp が開発するオープンソースのイメージビルドツールです。「マシンイメージを コードで定義し、自動で作る」のが目的で、Terraform と並んで IaC（Infrastructure as Code）の代表的なツールです。

AWS の AMI（Amazon Machine Image）は EC2 インスタンスの起動テンプレートです。カスタム AMI があれば次のようなことができます。

• 新しい EC2 インスタンスが 起動した瞬間から Nginx や Docker が使える
• Auto Scaling グループで使うとスケールアウト後の初期化が不要
• ステージング / 本番の環境差異をゼロにしたイミュータブルインフラが実現できる

Packer の動作は「一時 EC2 インスタンスを起動 → シェルスクリプトでソフトを入れる → AMI を作ってインスタンスを削除」という流れです。Terraform で言う “apply” のようなもので、実行が終わると AMI ID だけが残り、ビルド用インスタンスは自動的に消えます。

Ubuntu 24.04 に Packer をインストールする

HashiCorp は公式 apt リポジトリを提供しています。apt install packer だけで最新版が入ります。

手順1：HashiCorp apt リポジトリを追加する

lsb_release -cs は Ubuntu のコードネーム（24.04 なら noble）を返します。HashiCorp のリポジトリはコードネームごとにパッケージを管理しているため、この書き方にしておくと Ubuntu 22.04 / 24.04 のどちらでも動きます。

手順2：Packer をインストールする

Packer v1.15.4 と表示されれば成功です（2026年6月14日時点の最新版）。/usr/bin/packer にインストールされます。

正直、最初は「なんで AMI を自動ビルドするツールをわざわざ入れるの？」と思っていました。でも実際に使ってみると、毎回ゼロから apt install する手間が一切なくなるのでかなり快適です。

HCL テンプレートの書き方

Packer v1.7 以降は HCL2（HashiCorp Configuration Language 2）がデフォルトの記法です。拡張子は .pkr.hcl で、Terraform の書き方に似ています。

HCL テンプレートは大きく4つのブロックで構成されます。

• packer ブロック：使用するプラグインのバージョン制約を書く
• variable ブロック：テンプレート内で使う変数を定義（リージョンやインスタンスタイプなど）
• source ブロック：どの AMI を元にどの設定でビルドするかを指定
• build ブロック：source を参照し、provisioner でソフトをインストール

以下が実際に動く最小限の HCL テンプレートです。ファイル名は ubuntu-nginx.pkr.hcl として保存してください。

①主要設定項目の解説

owners = ["099720109477"] の指定は セキュリティ上非常に重要です。Canonical 公式のアカウント ID を指定しないと、悪意のある第三者が公開した偽 AMI を引いてしまうリスクがあります。ここだけは省略しないでください。

packer init — amazon プラグインをインストールする

packer build を実行する前に、テンプレートで指定したプラグインを取得する必要があります。packer init がその役割を担います。

実際に実行すると packer-plugin-amazon v1.8.1 が ~/.config/packer/plugins/ 以下にダウンロードされます（2026年6月14日実測）。SHA256 チェックサムも自動で検証されるため、改ざんされたプラグインが入る心配はありません。

packer validate — 構文チェックで事前にエラーを潰す

HCL テンプレートを書いたら、packer build の前に必ず packer validate を実行しましょう。これがPackerを使う上でとても便利な点で、AWS クレデンシャルなしで構文エラーをローカルで確認できます。

①構文のみチェック（推奨：クレデンシャル不要）

-syntax-only フラグを付けると AWS に接続せず HCL の構文だけを検証します。「Syntax-only check passed. Everything looks okay.」が返れば構文エラーなしです（2026年6月14日実測）。

②フォーマットチェック（可読性の統一）

packer fmt は Terraform の terraform fmt と同じ役割で、インデントや空行を自動で整形します。チームで使う場合は CI に組み込んでおくと手動整形の手間がなくなります。

③テンプレート構造を確認する（packer inspect）

packer inspect はテンプレートで定義された変数・ビルド名・source・provisioner の一覧を表示します。これも AWS 接続不要で実行できます（2026年6月14日実測）。

packer build — AMI ビルドの実行

構文チェックが通ったら、いよいよ packer build で AMI を作成します。これには AWS クレデンシャル（AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY）と、EC2・AMI を操作できる IAM 権限が必要です。

①必要な IAM ポリシー

Packer が EC2 インスタンスを起動・停止・AMI 登録するためには、以下の IAM アクションが最低限必要です。

②クレデンシャルを設定してビルドを実行

ビルドには約8〜15分かかります。完了すると AMI ID（例：ami-0123456789abcdef0）が出力され、東京リージョンの AMI カタログに登録されます。このとき ビルドに使った EC2 インスタンスは自動的に削除されます。

SSH 鍵の生成と設定

Packer はビルド中に EC2 インスタンスへ SSH 接続して provisioner を実行します。デフォルトでは Packer が一時的な SSH キーペアを自動生成します。独自の鍵を使いたい場合は事前に ssh-keygen で生成しておきます。

-t ed25519 は RSA-4096 より短い鍵長でも同等のセキュリティを持ちます。-N '' でパスフレーズなし（ビルドスクリプトから自動実行するため）。

HCL テンプレートに独自鍵を指定する場合は source ブロックに ssh_private_key_file = "~/.ssh/packer_ami_key" を追加します。ただし一時鍵（デフォルト）のままで大抵の用途は問題ありません。

よくあるエラーと解決策

①Error: No valid credential sources found

原因：AWS クレデンシャルが設定されていない。

対処：export AWS_ACCESS_KEY_ID="..." と export AWS_SECRET_ACCESS_KEY="..." を設定する。あるいは aws configure で ~/.aws/credentials に書き込む。

②Error: Timeout waiting for SSH

原因：セキュリティグループでポート 22 の inbound が許可されていないか、VPC の設定に問題がある。

対処：デフォルト VPC を使っている場合は多くの場合自動で解決します。カスタム VPC の場合は source ブロックに vpc_id と subnet_id、associate_public_ip_address = true を追加してください。

③Error: AMI Name: … already exists

原因：ami_name の {{timestamp}} を使っていない場合、同じ名前の AMI が重複する。

対処：ami_name = "custom-ubuntu-24.04-{{timestamp}}" の形式にすれば毎回ユニークな名前が自動で付く。古い AMI は定期的に削除すること。

④Plugin not found: github.com/hashicorp/amazon

原因：packer init を実行していない。

対処：packer init ubuntu-nginx.pkr.hcl を実行してプラグインをダウンロードする。インターネット接続が必要。

まとめ

Packer on Ubuntu で AWS カスタム AMI を自動ビルドする手順をまとめます。

• HashiCorp apt リポジトリ経由で apt install packer → Packer v1.15.4 がインストールされる（2026年6月14日実測）
• HCL テンプレート（.pkr.hcl）に packer・variable・source・build の4ブロックを書く
• packer init で packer-plugin-amazon v1.8.1 を自動インストール（実測確認済み）
• packer validate -syntax-only は AWS クレデンシャル不要でローカル構文チェックができる
• packer build を実行すると一時 EC2 が自動起動 → provisioner 実行 → AMI 登録 → インスタンス削除の全自動ビルドが完了する
• ビルド所要時間は目安で8〜15分（インスタンスタイプと provisioner の量による）

Packer を Terraform と組み合わせると、「Packer で AMI ビルド → Terraform でその AMI を使った EC2 を定義」という完全な IaC パイプラインが作れます。まずは本記事の HCL テンプレートを手元で packer validate してみてください。

VPS で Packer をデプロイして CI/CD パイプラインと組み合わせる場合は、東京リージョンとの遅延が少ない VPS を選ぶと体感速度が上がります。

VPS 選びで迷ったら、実測ベンチマークを比較した記事も参考にしてください。