Terraform入門：AWSとConoHa VPSのインフラをコード化する最初の一歩

VPS・サーバー選定初級
TerraformIaCAWSConoHaVPS

本記事はアフィリエイト広告（A8.net）を含みます。価格・仕様は2026年7月時点の目安です。最新は各公式サイトでご確認ください。

TL;DR

  • Terraform（テラフォーム）とは、サーバーやネットワークなどのインフラを設定ファイル（コード）で定義し、その通りに構築・変更・削除できるツール。手順書に沿ってポチポチ作業する代わりに、「あるべき状態」をファイルに書いて反映する。
  • 基本の流れは3コマンドだけ：terraform init（初期化）→ terraform plan（変更内容の確認）→ terraform apply（実際に反映）。
  • AWSは公式のTerraformプロバイダが充実しており、EC2インスタンス1台なら20行程度のコードで作れる。
  • ConoHa VPSも2026年7月時点でGMOインターネット公式のTerraformプロバイダ（gmo-internet/conohavps）がRegistryに公開されている。ただし現在Beta版で、対応はConoHa VPS Ver.3.0のみ、データソース（値を検索する仕組み）はまだ未提供という制約がある。
  • つまずきやすいのは「tfstateの管理」と「認証情報の扱い」。ここを雑にすると事故につながるので、後半で具体的に整理する。

Terraformとは何か

Terraform（テラフォーム）とは、HashiCorp社が開発している IaC（Infrastructure as Code）ツールで、「インフラの設定をコードで書き、そのコード通りにクラウド上のリソースを作る・変更する・消す」ことができる。

「インフラをコードにする」というのがピンとこない人向けに言うと、これまでの「管理画面を開いて、ポチポチ設定してサーバーを立てる」という作業を、「この構成で1台作って」という指示書（コード）に置き換えるイメージだ。指示書はGitで履歴管理でき、同じコードを流せば同じ環境を何度でも再現できる。

Terraformの設定ファイルは HCL（HashiCorp Configuration Language） という専用の記法で書く。JSONに近いが、コメント（#）が書けたり人間が読みやすいよう工夫された言語だ。ファイルの拡張子は .tf。

Terraformは「宣言型」のツールで、「どういう手順で作るか」ではなく「最終的にどういう状態であってほしいか」を書く。実際にどう作るかの手順（API呼び出しの順番など）はTerraform側が考えてくれる。

対応先はAWS・Azure・Google Cloudのような大手クラウドだけでなく、Cloudflareや国内VPSまで「プロバイダ」という形で追加されていく仕組みになっている。プロバイダとは、Terraformと各サービスのAPIをつなぐ翻訳機のようなものだと考えればいい。

インストールしてみる

Macなら Homebrew 経由が公式にも案内されている方法だ。

brew tap hashicorp/tap
brew install hashicorp/tap/terraform

Ubuntu/Debian系のLinuxでは、公式リポジトリを登録してからaptで入れる。

wget -O - https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install terraform

インストール後は必ずバージョンを確認する。

terraform version

2026年7月時点の最新安定版は v1.15.6（2026年6月10日リリース）系列。v1.16 は執筆時点でまだアルファ版のため、通常利用では安定版の1.15系を使えばよい。バージョンはHashiCorpのGitHub Releasesで随時更新されるので、記事の数字を鵜呑みにせず自分の環境で確認する癖をつけておくといい。

基本ワークフロー：init → plan → apply

Terraformを使う作業は、どんな対象（AWSでもConoHaでも）でもこの3ステップに集約される。

コマンド何をするか
terraform initそのディレクトリで使うプロバイダ（AWS用・ConoHa用など）をダウンロードし、作業ディレクトリを初期化する。.tfファイルを新規に書いた・プロバイダを追加した、というときに実行する
terraform plan今書いてあるコードと、実際のクラウド上の状態を比較し、「何が追加/変更/削除されるか」を事前に表示する。まだ何も実行されない
terraform applyplanの内容を確認したうえで、実際にクラウド上にリソースを作成・変更する
terraform destroyコードに書かれたリソースをまとめて削除する。検証環境の片付けに使う

補助的に、書式を整える terraform fmt と、構文エラーをチェックする terraform validate もよく使う。

「plan」を毎回見る意味は？ applyでいきなり反映すると、意図しないリソースが消えたり、想定より多くのインスタンスが増えたりする事故が起こり得る。planは「これから起きることの見積書」なので、内容を読んでからapplyする習慣をつけておくと安全。

AWSで最小構成を書いてみる

AWSはhashicorp/awsという公式プロバイダがTerraform Registryで提供されている。2026年7月時点でメジャーバージョンは6系（6.0が正式GA後、6.5x系まで更新が進んでいる）。

まずmain.tfにプロバイダの宣言とAWSリージョンを書く。

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

provider "aws" {
  region = "ap-northeast-1"
}

version = "~> 6.0" は「6.0以上、7.0未満の範囲で最新を使う」という意味の記法。プロバイダは頻繁に更新されるため、範囲を指定しておくと事故なく最新のマイナーアップデートを取り込める。

次に、EC2インスタンスを1台作る最小構成を書く。AMI（サーバーの元になるイメージ）はハードコードせず、dataブロックで「最新のUbuntuイメージ」を検索して使う書き方が公式ドキュメントでも推奨されている。

data "aws_ami" "ubuntu" {
  most_recent = true

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-*"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }

  owners = ["099720109477"] # Canonical公式アカウント
}

resource "aws_instance" "example" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"

  tags = {
    Name = "infradb-example"
  }
}

data "aws_ami" "ubuntu" は「新しくリソースを作る」のではなく「既存の情報を検索してくる」ためのブロック。ここで見つけたAMIのIDを、下のresource "aws_instance"（実際に作るEC2インスタンス）がdata.aws_ami.ubuntu.idという形で参照している。このinit → plan → applyの順で流せば、東京リージョンにt3.microのUbuntuサーバーが1台立ち上がる。

認証情報（アクセスキー）はこのファイルには書かない。次の「よくあるつまずき」で扱う。

ConoHa VPSでの実務例

ConoHa VPSについては、2026年7月時点でGMOインターネット公式がgmo-internet/conohavpsというTerraformプロバイダをRegistryで公開している。存在自体は確認できたが、公式リポジトリに明記されている通り現在Beta版であり、次の制約がある。

  • 対応は ConoHa VPS Ver.3.0のみ（Ver.2.0では使えない）
  • データソース未提供：AWSのaws_amiのような「検索して値を取ってくる」仕組みがまだなく、フレーバーID（サーバースペックのUUID）やイメージID（OSイメージのUUID）はConoHaのAPIドキュメントから自分で調べて直接書く必要がある
  • 「本番投入前に十分な検証を」と公式README上で明記されている

前提として、ConoHaのコントロールパネルでAPIユーザーを作成し、そのユーザーID・パスワード・テナントIDを控えておく必要がある（管理画面のログイン情報とは別物）。

terraform {
  required_providers {
    conohavps = {
      source = "gmo-internet/conohavps"
    }
  }
}

# identity_endpoint / password / region / tenant_id / user_id は
# 環境変数(CONOHAVPS_USER_ID など)で渡せば、ここには書かなくてよい
provider "conohavps" {}

resource "conohavps_keypair" "main" {
  name       = "infradb-key"
  public_key = "ssh-rsa AAAA...ここに自分のSSH公開鍵..."
}

resource "conohavps_securitygroup" "main" {
  name        = "infradb-sg"
  description = "Terraform managed"
}

resource "conohavps_volume" "main" {
  name        = "infradb-boot-volume"
  size        = 100
  image_ref   = "884c1899-fefe-40bd-aab8-1001b1d9c895" # ConoHa API で調べたイメージUUIDに置き換える
  volume_type = "c3j1-ds02-boot"
}

resource "conohavps_instance" "main" {
  instance_name_tag = "infradb-server"
  flavor_id         = "f2a77529-1815-43a2-bc14-1f3f6b09079c" # ConoHa API で調べたフレーバーUUIDに置き換える
  key_name          = conohavps_keypair.main.name
  power_state       = "ACTIVE"

  block_device = [
    {
      uuid = conohavps_volume.main.id
    }
  ]

  security_group = [
    {
      name = conohavps_securitygroup.main.name
    }
  ]
}

キーペア・セキュリティグループ・ボリュームを先に作り、最後にそれらをconohavps_instanceが参照してサーバーを組み立てる構成になっている。AWSの例とちがい「イメージやスペックを名前で探す」手段がまだないため、UUIDを直書きする手間が残る点はBeta版らしい制約として理解しておきたい。

そもそもAWSとConoHa VPSのどちらを選ぶべきかで迷う場合は、法人のサーバー選び方で用途別の判断軸を整理しているので参考にしてほしい。

よくあるつまずき

tfstateの扱い

Terraformはapplyを実行するたびに、「今どんなリソースがどんな状態で存在するか」をterraform.tfstateというファイルに記録する。このファイルにはインスタンスIDやIPアドレス、場合によってはパスワードなどの機微情報が平文で入るため、以下は最低限守っておきたい。

  • .gitignoreに *.tfstate *.tfstate.backup .terraform/ を必ず入れ、Gitに載せない
  • 1人開発ならローカル管理でもいいが、チームで使うなら S3 + ロック機構のようなリモートバックエンドに切り替える
  • tfstateを紛失すると「Terraformがどのリソースを管理しているか分からなくなる」状態に陥り、復旧が難しくなる

このtfstateの管理不備は、中小企業のIaC導入がPoCで止まる典型的な原因の一つでもある。より詳しい失敗パターンはIaC導入の壁：中小企業が脱落する3つのポイントで扱っているので、チーム展開を考えている場合は合わせて読んでおくといい。

認証情報の管理

.tfファイルにAWSのアクセスキーやConoHaのパスワードを直書きするのは避ける。どちらのプロバイダも環境変数での指定に対応している。

  • AWS: AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY / AWS_DEFAULT_REGION
  • ConoHa VPS: CONOHAVPS_USER_ID / CONOHAVPS_PASSWORD / CONOHAVPS_TENANT_ID / CONOHAVPS_REGION / CONOHAVPS_IDENTITY_ENDPOINT

コード上はproviderブロックを空にしておき、実行環境側で環境変数をセットする形にすれば、誤ってGitにキーを含めてしまう事故を防げる。

CI/CDでterraform applyまで自動化したい場合は、GitHub ActionsのSecretsに認証情報を格納して参照する構成になる。具体的なYAMLの書き方はGitHub Actionsでインフラ変更を自動化するで解説している。

まとめ

Terraformは「手作業の手順書」を「コードで書いた設計図」に置き換える仕組みで、覚えることはinit → plan → applyのワークフローとHCLの基本構文だけだ。AWSは公式プロバイダが成熟しており、最小構成なら20行程度で動くコードが書ける。ConoHa VPSも2026年7月時点で公式のBetaプロバイダが存在するが、データソース未提供という制約があるため、UUIDの調査など一手間かかる状態だと理解した上で使うのが実務的な判断になる。

最初の一歩としては、まずAWSの無料利用枠かConoHaの時間課金プランで、この記事のコードをそのままapplyしてみて、destroyまで一通り動かしてみるのがおすすめだ。tfstateと認証情報さえ雑に扱わなければ、事故らずに感覚をつかめるはずだ。

関連サービス

ConoHa VPS

関連記事

VPS・サーバー選定VPS vs クラウド：月額3万円以下の中小企業に最適なインフラコスト構成VPS・サーバー選定ConoHa VPS vs さくらのVPS 2026年版：法人ユースで選ぶならどっちかVPS・サーバー選定Xserver VPS vs ConoHa VPS：ゲームサーバー以外での実務比較
記事一覧に戻る