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