☁️

【30歳からのIaC】AWS手動構築ハンズオン後の初めてのTerraform

に公開
AWS
IaC
ハンズオン
tech

はじめに

こんにちは。普段は医薬品工場で品質保証（QA）の業務をしています。
先日、AWSでの3層構成を手動で構築し、その内容をZennにまとめました。

次のステップとして、「インフラの再現性を高め、設定漏れというヒューマンエラーを排除する」という、品質保証に直結するTerraformの世界に挑戦することにしました。

しかし、プログラミング授業（Python）との環境競合や、Windows特有のバイナリ選択、認証エラーなど、最初の設定だけでいくつもの壁にぶつかりました。

この記事では、未経験者がTerraformを触り始めて最初に経験したエラーと、その原因究明のプロセスを残します。

1. 最初の壁：自分のPCのスペックとバイナリの選択

Terraformの公式サイトからWindows用のバイナリをダウンロードしようとした際、386、amd64、ARM64 という選択肢が現れ、さっそく手が止まりました。

QAの業務でも、機器の型番を確認して適合するものを選ぶのが鉄則です。自身のPCのバージョン情報を確認したところ、CPUは 「AMD Ryzen 7 8840HSw」 でした。

  • 386: 32bit用（古い）
  • ARM64: MacのMシリーズや一部の特殊なWindows用
  • amd64: 一般的な64bit Windows用（RyzenやIntel）

以上の仕様を調べ、自分のPCに適合する 「amd64」 を選択。C:\terraform に配置し、環境変数（Path）に登録を行いました。

2. 第2の壁：VS Codeのターミナルが別環境に占有されている

VS Codeを開いたところ、ターミナルが大学の授業で使っているPythonの環境のままになっていました。
別の製造ラインで異なる製品を製造してはいけないのと同様に、インフラ構築でも専用の「クリーンな作業場所」が必要であることを理解しました。

cd C:\Users\〇〇\Desktop
mkdir terraform-study
cd terraform-study

専用のディレクトリを作成し、VS Codeでフォルダーを開き直して、「PowerShell」に切り替えることで、論理的に隔離されたTerraform専用の開発環境を整えました。

3. 第3の壁：No valid credential sources found

main.tf を作成し、terraform initまでは成功したものの、続く terraform plan で最初のエラーに遭遇しました。

Error: No valid credential sources found

これは、「設計図（main.tf）は問題ないが、AWSに入るための 「認証情報」 をTerraformに渡し忘れている」というエラーでした。

解決のためにターミナルで aws configure を実行しようとしましたが、今度は「aws コマンドが認識されません」というエラーが発生。そもそもPCに AWS CLI を導入していないことが原因でした。

是正処置（CAPA）

  1. AWS公式から Windows用の AWSCLIV2.msi をダウンロードしてインストール。
  2. 反映するためにVS Codeを再起動。
  3. aws configure を実行し、AWSコンソールで発行した「アクセスキーID」と「シークレットアクセスキー」を登録。

このプロセスを経て、ようやくPCとAWSの間のアクセスが可能になりました。

4. 初めてのIaC

認証が通ったあと、ついに自動構築を実践しました。

main.tf
# 計画の妥当性を確認。まさに製造前バリデーション
terraform plan
Plan: 5 to add, 0 to change, 0 to destroy.

# 本番実行
terraform apply
Apply complete! Resources: 5 added, 0 changed, 0 destroyed.

AWSのマネジメントコンソールを確認すると、コードに記述した通りの名前とCIDRを持ったVPCが作成されており、4つのサブネットがヒューマンエラーゼロで簡単に構築できました！
さらに驚いたのは、片付けの手軽さです。

terraform destroy

手動でインフラを消す際に経験した「依存関係でサブネットが消せない」といった事象をすべて自動処理し、コマンド一つで安全に削除してくれました。

まとめ：QA視点とIaCの親和性

今回、手動でのインフラ構築を経験したあとにTerraformを触ってみて、単に「構築を楽にするための時短ツール」ではないことを理解しました。

その本質は、 「標準作業手順（SOP）の実行を完全に自動化し、人間の介在をなくすことで、ヒューマンエラーのリスクを極限まで低減する仕組み」 であるということです。

現職の医薬品品質保証（QA）の現場で培ったリスク管理の考え方と、Terraformの仕組みは驚くほどリンクしています。

1. 「ダブルチェック」から「構造的なポカヨケ」へ

医薬品の製造でもインフラの手動運用でも、どれだけ優秀な人間が注意深く作業し、どれだけ厳重にダブルチェックを重ねても、「手順の読み飛ばし」や「設定画面での押し間違い」といったヒューマンエラー（逸脱・システム障害）をゼロにすることはできません。

Terraformは、main.tf という「標準化された手順書」を機械に読み込ませることで、人間特有の「勘違い」や「集中力の低下」を完全に排除できます。誰が、いつ、何回実行しても、寸分違わぬ全く同じ成果物を出力する。この 「ミスが物理的に起きない構造（ポカヨケ）」 を作るアプローチは、QAが理想とするリスク低減の究極形です。

2. QA視点で紐解くTerraformのライフサイクル

ツールの挙動を厳密にQAの「バリデーション（適格性評価）」の概念に当てはめると、綺麗に整理できることが分かりました。

  • main.tf の記述 ＝ DQ（設計適格性評価）
    • 要件を満たす設計をコードとして定義・レビューする段階。
  • terraform init ＝ 原材料・資材の受入検査
    • 製造（構築）を始める前に、承認済みのメーカーから正しい仕様の材料（AWSプロバイダー）が届いているかを確認し、環境内に搬入する工程。
  • terraform validate ＝ IQ（設備据付適格性評価）
    • 設計図通りに、材料（コード構文や引数）が正しく組み立てられ、配置されているかを静的に検証する。
  • terraform plan ＝ OQ（運転適格性評価）
    • 実際のAWS環境と動的に通信し、この変更命令を流し込んだ際に「エラーなく正常に動作するか」を本番実行前にシミュレーション（妥当性確認）する。
  • terraform apply ＝ PQ（性能適格性評価）と実製造
    • 検証済みの手順を自動実行してインフラを稼働させ、システム全体が意図したパフォーマンスを発揮し、品質基準を満たした成果物が安定して出力されるかを検証する。

おわりに：QAの経験はインフラにそのまま活きる

「ドキュメント（コード）の正確性にこだわり、実行フェーズから不確実性を排除して品質を担保する」というQAの資質は、現代のインフラエンジニアに求められるIaCのスキルと一致すると感じました。

今回は初めてのTerraformということで、VPC構築のみを実践しましたが、今後は「EC2インスタンスを含めた3層構成のコード化」へ挑戦し、さらに信頼性の高いインフラ構築を目指していきます！

Discussion