初級では IaC を「インフラをコードで書いて自動構築する考え方」と捉えました。中級では、宣言的 vs 手続き的 の違い、べき等性、そしてコードの履歴管理との相性を見ます。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
これは何をする係？
IaC には大きく2つの書き方があります。
- 宣言的 — 「こうあってほしい」という 最終状態 を書く。どう作るかはツールに任せる
- 手続き的 — 「まずこれ、次にこれ」と 手順 を1つずつ書き並べる
主流は宣言的です。ツールが 現状 と コード（望む状態） を比べ、足りない物を作り・余分を消して、望む状態へ収束 させます。
アニメーション『IaCの宣言的な収束』を開く
この「現状に合わせて必要な分だけ動く」性質から、べき等性（※1）が生まれます。何度実行しても、既に望む状態なら何もせず、ずれていれば直すだけ。だから 安全に繰り返せます。
登場人物メモ:
- ※1 べき等性 — 何度実行しても同じ結果に収束する性質。途中失敗しても再実行で復旧できる
- ※2 プロビジョニング — サーバやネットワークなど、資源そのものを用意すること
- ※3 構成管理 — 用意した資源の中身（設定・パッケージ等）をあるべき状態に保つこと
この部分をもっと深く（上級）
宣言的IaCの心臓は、望む状態へ現実を寄せる調整（reconciliation）です。人は「どうあってほしいか」だけを書き、ツールが差を埋めます。
- plan — コード（望む状態）と現況の記録を突き合わせ、「何を作り・変え・消すか」の差分を先に見せる。適用前に影響を確認できる
- apply — その差分だけを実行し、実状態を望む状態へ寄せる。全部を作り直さない
- この「差分だけ動く」性質がべき等性の正体。既に望む状態なら何もせず、ずれていれば直すだけ
アニメーション『IaCの宣言的な収束』を開く
登場人物メモ:
- ※1 state（状態ファイル） — ツールが把握する「今の構成」の台帳。差分計算の基準
- ※2 ドリフト — コードを通さない手動変更で、コードと現実がずれること
- ※3 プロバイダ — 各サービスのAPIを、宣言的な操作へ翻訳するアダプタ
やさしく言うと（初級）
IaC は、サーバ・ネットワークといった インフラの構成をコードで書き、ツールに 自動で構築させる 考え方です。
料理でたとえると、勘で味付けするのではなく レシピ（※1 設定ファイル）に分量を書き残す イメージ。レシピどおりに作れば、誰が作っても・何度作っても同じ料理になります。
手作業との違いはここです。
- 手作業 — 画面を操作。手順は記憶頼み、人によってばらつく
- IaC — 構成をファイルに記述。そのまま再現 でき、履歴も残る
登場人物メモ:
- ※1 設定ファイル — 望むインフラの構成を書いたコード。これが「レシピ」になる
- ※2 プロビジョニング — コードに従ってサーバ等を実際に用意する工程
仕事の流れ
やさしく言うと（初級）
- 望むインフラの構成を ファイルに書く（サーバ何台・ネットワークはこう…）
- ツールにそのファイルを 読ませる
- ツールが構成を 自動で構築（※2 プロビジョニング）する
- 同じファイルを使えば、別の場所でも 同じ環境が再現 される
ポイントは、作業の中身が 文章として残る こと。次の人はその文章を読めば、何がどう作られているか分かります。
設計の勘所
- 宣言的を基本に — 手順ではなく状態を書く。差分の計算はツールに任せ、人はゴールに集中
- べき等に保つ — 何度流しても壊れない設計にすると、失敗時の再実行が怖くなくなる
- プロビジョニングと構成管理（※2※3）— 資源を「用意する」層と、中身を「あるべきに保つ」層を分けて考える
- 履歴管理との相性 — 構成をコードにすると変更履歴が残り、いつ誰が何を変えたか追える。壊れたら前の版へ戻せる
さらに CI/CD と組み合わせると、構成の変更も 自動でテストして適用 できます。アプリだけでなくインフラも、同じ流れ作業に乗せられるわけです。
この部分をもっと深く（上級）
規模が大きくなると、部品化と作り直す発想が効いてきます。
- モジュール化 — VPC一式やサーバ群など、まとまった構成を再利用できる部品にする。同じ部品から開発用・本番用を差分パラメータだけ変えて量産できる
- 合成 — 小さなモジュールを組み合わせて大きな構成を作る。重複を減らし、変更を1か所に集約できる
- イミュータブルインフラ — 動いているサーバを手で直さず、新しい版を丸ごと作って古い版と入れ替える。Dockerイメージの差し替えと同じ発想で、ドリフトが起きにくく、戻すのも入れ替えるだけ
やさしく言うと（初級）
- 再現できる — 同じコードから同じ環境が何度でも作れる（開発用・本番用をそろえやすい）
- 履歴が残る — 「いつ・誰が・何を変えたか」がコードの変更として追える
- レビューできる — 変更を出す前に、他の人が内容を確認できる
手順が人の記憶から コードへ移る ので、属人化（その人しか分からない状態）が減ります。
⚠️ うまくいかないとき
- 手動変更でのずれ（ドリフト） — 画面で直すとコードと現実が食い違い、次の適用で上書きされる
- 削除の巻き添え — 宣言から外した資源が消える。消してよい物か確認が要る
- 状態の取り違え — ツールが持つ「今の状態」の記録が壊れると、差分計算を誤る
- 秘密情報の混入 — 鍵やパスワードをコードに直書きすると、履歴に残って漏れる
このうちドリフトは、コード（望む状態）と実際のクラウド（実状態）を突き合わせれば見つかります。plan が差分（追加／変更／削除）を洗い出し、apply で望む状態へ戻します。
アニメーション『ドリフト検出（コードと現実のズレ）』を開く
この部分をもっと深く（上級）
- 手動変更によるドリフト — 画面で直すとstateと食い違い、次のapplyで意図せず上書きされる
- stateの破損・取り違え — 現況の台帳が壊れると差分計算を誤り、実在する物を作り直したり二重化する
- 削除の巻き添え — 宣言から外した資源が消える。planで消える対象を必ず確認する
- 秘密のstate流出 — 平文の秘密を含んだstateを不用意に共有・コミットして漏らす
やさしく言うと（初級）
- 手で直してずれる — コードを通さず画面で直すと、コードと現実が食い違う
- コードのミスが全体に波及 — 間違ったまま流すと、全環境に同じ間違いが広がる
- 消す操作も自動 — 「消す」もコードどおり実行されるので、書き間違いに注意
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. IaCでいう「べき等性」とはどういう性質？
問2. 宣言的なIaCの特徴として正しいのは？
問3. 「まずこれ、次にこれ」と手順を1つずつ書き並べる書き方を何と呼ぶ？
問4. サーバやネットワークなど「資源そのものを用意すること」を指すのはどれ？
問5. 構成をコード（IaC）にして履歴管理に置く利点として正しいのは？
問6. 宣言的IaCで「宣言から外した資源」はどうなる？
問7. 画面から手で直してコードと現実が食い違うことを、カタカナで何と呼ぶか答えてください。
問8. 「どうあってほしいか（最終状態）」を書き、どう作るかはツールに任せる書き方を何と呼ぶか、最後が「的」で終わる語で答えてください。