宣言的インフラストラクチャの根本的な不可能性：なぜIaCは常に不完全であり続けるのか

Infrastructure as Codeの数学的および哲学的限界についての深掘り

はじめに：約束と現実

Infrastructure as Code（IaC）は、複雑なシステムを単純な宣言的マニフェストで記述できる世界を私たちに約束しました。私たちが望むものを書き記しさえすれば、クラウドがそれを実現してくれる、と。Terraformはテラフォーミングし、CloudFormationはクラウドを形成し、Kubernetesはあらゆるプラットフォームでシームレスにオーケストレーションを行う、と。

しかし、本番環境でIaCを扱ったことのある人なら誰でも、汚い秘密を知っています：現実は私たちの宣言よりも無慈悲なほど複雑であり、時間は決して元には戻らないということです。

この記事では、なぜ宣言的インフラストラクチャ管理が、どのツールも克服できない根本的な数学的限界に直面するのか、そしてこれらの制約を理解することが、特に現代のアプリケーション中心のインフラストラクチャアプローチの文脈において、私たちをより良いエンジニアにする方法を探ります。

DocumentDBパラドックス：不可能性のケーススタディ

すべてのインフラエンジニアが直面したことのある、この一見単純なシナリオを考えてみましょう。

CloudFormationを使用して、t4g.mediumインスタンスでDocumentDBクラスターをデプロイする
後に、パフォーマンスの危機に際して、パフォーマンス向上のためにインスタンスをr6g.largeに手動でアップグレードする
今、CloudFormationテンプレートを更新して現実を反映させ、「Infrastructure as Code」の実践を維持したいと考えている

次に起こることは、宣言的IaCの根本的な欠陥を明らかにします。

// 元のテンプレート
instanceType: new ec2.InstanceType("t4g.medium")

// 現実に合わせるための更新されたテンプレート
instanceType: new ec2.InstanceType("r6g.large")

CloudFormationはこの変更を見て、ドリフトを「修正」するためにインスタンスを置換する必要があると判断します。しかし、置換しようとしているインスタンスはもはや存在しません—あなたはすでに手動でそれを置き換えてしまったのです。CloudFormationは今や幻のリソースを追跡しており、現実が先へ進んでいる間に、意図された状態のパラレルワールドに生きています。

あなたは不可能な状況に陥っています。

❌ テンプレートを更新できない - CloudFormationは存在しないリソースを置換しようとする
❌ 新しいリソースをインポートできない - 複数の論理IDを同じ物理リソースにマッピングすることはできない
❌ 削除して再作成できない - 他のリソースがそのデータベースに依存している
❌ そのままにしておけない - CloudFormationは継続的にドリフトを「修正」しようとする

これはCloudFormationのバグではありません。動的で時間に依存する現実をモデル化しようとする宣言的システムの根本的な限界です。

CDKの安全チェック：不可能性の自認

DocumentDBパラドックスは、人間の介入がツールには理解できない状態を作り出す手動ドリフトの問題を例示しています。しかし、さらに一般的なシナリオが同じ限界を明らかにします：初期デプロイの失敗です。

すべてのクラウドエンジニアが通過儀礼として経験する、この一連のイベントを考えてみましょう。

cdk deployを実行して新しいスタックを作成する。
一時的なネットワークエラー、忘れていたIAM権限、無効なパラメータなど、さまざまな理由でデプロイが途中で失敗する。
AWS CloudFormationは処理を続行できず、スタックをCREATE_FAILED状態にする。これは白紙の状態ではなく、部分的に作成されたリソースの厄介な集合体である破損した状態です。
コード内の根本的な問題を修正し、自信を持って再びcdk deployを実行する。

成功する代わりに、あなたは厳しい停止に直面します。

❌ MyStack failed: _ToolkitError: Stack is in a paused fail state (CREATE_FAILED)
and change includes a replacement which cannot be deployed...
terminal (TTY) is not attached so we are unable to get a confirmation from the user

このエラーはバグではありません。AWS CDKが明示的に自身の限界を認めているのです。ツールはあなたにこう告げています。

「私の現実の『宣言』がCREATE_FAILEDであることを見ています。世界の実際の状態は壊れていて矛盾しています。あなたの新しいコードは、私に破壊的な置換を実行するように要求していますが、私は自分の立っている地面を信用できません。自動的に進めるのは危険すぎます。」

なぜ危険なのでしょうか？なぜならCDKは盲目的に置換を試み、再び失敗してスタックをさらに破損した状態にし、クリーンアップをはるかに困難にする可能性があるからです。これは、壊れた土台の上で大規模な操作を行うことは大惨事の元であるというプログラム的な認識です。

この安全チェックは、この記事の主題を証明する組み込みの「緊急脱出口」です。宣言的モデルは失敗しました。ツール自体が、マニフェストと現実のギャップが、自らが越えられない深淵になったことを認識しています。それは停止を余儀なくされ、宣言的モデルが再び有用になるほど単純な状態に現実をリセットするために、手動での、帯域外の人間による介入（AWSコンソールにログインして失敗したスタックを削除すること）を要求します。

ツール自体があなたに告げているのです：私の宣言的な力は、蓄積された、失敗した歴史の前では適用不可能だ、と。

カスタム名付きリソースの罠：アイデンティティが不変になるとき

別の一般的なシナリオが、同じ不可能性の異なる側面を明らかにします—カスタム名付きリソースの罠です。

UPDATE_FAILED | AWS::CloudFront::KeyValueStore | basicAuthus-west-2/solo-dev-auth
CloudFormation cannot update a stack when a custom-named resource requires replacing.
Rename soloinfragarybasicAuthuswest2solodevauth93819E8D and update the stack again.

このエラーは、宣言的システムにおける根本的な矛盾を露呈します：アイデンティティ vs 可変性。何が起こったかというと：

カスタム名（自動生成ではない）を持つCloudFront KeyValueStoreを作成した
後に、CloudFormationがリソースを置換する必要がある変更を加えた
CloudFormationは、カスタム名付きリソースを置換できないことを発見した。なぜなら：
- まず古いリソースを削除する必要がある
- しかし、古いリソースがなくなるまで、同じ名前で新しいリソースを作成できない
- これにより、その名前が存在しない短い瞬間が生まれる
- その正確な名前に依存する他のリソースは、移行中に壊れてしまう

CloudFormationは本質的にこう言っています：

「あなたはこのリソースを宣言的に管理するように私に頼みましたが、同時に置換を不可能にする固定のアイデンティティも与えました。私は、あなたの安定したアイデンティティと宣言的な可変性という両方の願望を両立させることはできません。これらは数学的に互換性のない要件です。」

CloudFormationが提案する「解決策」—リソースを手動で名前変更すること—は、この記事の要点を証明しています：宣言的システムが処理できない矛盾を解決するためには、宣言的モデルの外に出て、手動の、命令的なアクションを実行しなければならないということです。

これはCloudFormationの限界ではありません。それは論理的な不可能性です。以下のことを同時に保証することはできません：

（依存関係のための）安定した、予測可能なリソース名
（更新のための）シームレスなリソース置換
（可用性のための）ゼロダウンタイムの移行
（再現性のための）宣言的な管理

何かが犠牲にならなければならず、そうなったとき、宣言的モデルは崩壊し、矛盾を解決するために人間の介入が必要になります。

情報理論の問題

中心的な問題は、宣言と現実の間の情報の非対称性です—これは、どのIaCツールよりも根深い問題です。

私たちが宣言するもの（単純）

apiVersion: v1
kind: Pod
spec:
  containers:
  - name: app
    image: nginx:1.20
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"

実際に存在するもの（複雑）

{
  "metadata": {
    "uid": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
    "creationTimestamp": "2024-01-15T10:30:00Z",
    "resourceVersion": "12345678",
    "generation": 3,
    "managedFields": [/* 200行以上のフィールド管理履歴 */]
  },
  "status": {
    "phase": "Running",
    "hostIP": "10.0.1.45",
    "podIP": "172.16.0.23",
    "startTime": "2024-01-15T10:30:15Z",
    "containerStatuses": [{
      "containerID": "containerd://abc123...",
      "imageID": "sha256:def456...",
      "lastState": { "terminated": { "exitCode": 0, "reason": "Completed" }},
      "restartCount": 2,
      "ready": true,
      "started": true
    }],
    "qosClass": "Burstable",
    "conditions": [
      { "type": "Initialized", "status": "True", "lastTransitionTime": "2024-01-15T10:30:10Z" },
      { "type": "Ready", "status": "True", "lastTransitionTime": "2024-01-15T10:30:20Z" },
      { "type": "ContainersReady", "status": "True", "lastTransitionTime": "2024-01-15T10:30:20Z" },
      { "type": "PodScheduled", "status": "True", "lastTransitionTime": "2024-01-15T10:30:05Z" }
    ]
    // ... リソース履歴、ネットワーク状態、パフォーマンスメトリクス、
    // セキュリティコンテキスト、ランタイム決定を追跡する数百のフィールド
  }
}

根本的な問題：1000以上の複雑なランタイム状態のフィールドを、20の宣言的な意図のフィールドに、大規模な情報損失なしに圧縮することはできません。これは私たちのツールの限界ではありません—それは、交響曲をすべての音楽情報を保持したまま単一の音符に圧縮しようとするような、数学的な不可能性です。

ロングテール効果：システム複雑性の80/20ルール

私が「ロングテール効果」と呼ぶものは、実際のシステムの複雑さがべき乗則分布に従う様子を説明しています。

システム状態の20%は簡単に宣言できる（イメージ、レプリカ数、基本設定）
システム状態の80%は、ランタイムの振る舞い、プラットフォームの決定、および歴史的なイベントから出現する

この80%には以下が含まれます：

作成タイムスタンプ - 宣言できず、観察のみ可能
リソースバージョン - 運用履歴を通じてプラットフォームによって生成される
パフォーマンスメトリクス - 実際の使用を通じて時間とともに蓄積される
ネットワーク割り当て - 可用性に基づいてプラットフォーム固有に割り当てられる
セキュリティパッチ - 脆弱性データベースに基づいて自動的に適用される
再起動履歴 - 運用イベントと障害モードの結果
サービス間関係 - 実際のトラフィックパターンと依存関係から出現する
リソース使用パターン - 時間の経過とともにアプリケーションの振る舞いから学習される
プラットフォーム固有の最適化 - ワークロードの特性に基づいてクラウドプロバイダーによって適用される

シュレーディンガーの構成問題

すべての本番システムで発生する、この量子状態のパラドックスを考えてみましょう。

// この宣言はどうあるべきか？
engineVersion: "4.0.0"  // 元の宣言されたバージョン
engineVersion: "4.0.1"  // 自動パッチ後に実際に実行されているバージョン
engineVersion: "4.0.2"  // セキュリティチームが手動でアップグレードしたバージョン

3つの値はすべて、あなたの視点とシステムを観察する時点によって、同時に「正しい」とも「間違っている」とも言えます。宣言的モデルは、多次元の現実の中で単一の真実の源を仮定するため、この時間的な複雑さを捉えることができません。

TerraformのStateファイル：不可能性への記念碑

Terraformのstateファイルは、宣言的な意図とランタイムの現実の間のギャップを埋めるための最も洗練された試みの一つを代表しています。しかし、それはこの橋がなぜ決して完成しないのかを完璧に示しています。

Stateファイルのパラドックス

# stateファイルは現実を知っていると主張する
terraform show
# しかし現実は独立して変化している
aws ec2 describe-instances

# 今や「真実」には3つのバージョンがある：
# 1. .tfファイルで宣言されているもの
# 2. stateファイルに記録されているもの
# 3. AWSに実際に存在するもの

stateファイルは、Terraformが現実の「シャドウコピー」を維持しようとする試みですが、以下の理由により、永遠に同期が取れない運命にあります。

クラウドプロバイダーが決定を下す - Terraformの制御外で
他のツールがリソースを変更する - Terraformが追跡できない方法で
手動変更が発生する - インシデントや運用作業中に
時間が経過する - そしてシステムは独立して進化する

Stateリフレッシュの幻想

terraform refreshを実行すると、現実と同期していると思うかもしれませんが、実際には次のことを行っています。

ある時点での現実をサンプリングする
それをTerraformの限られたデータモデルに投影する
スキーマに合わない情報を失う
リフレッシュが完了した瞬間に新たなギャップを生み出す

stateファイルは、書かれた瞬間に歴史的な遺物となります—すでに先へ進んでしまったシステムの写真です。

なぜ「インポート」は根本的に欠陥があるのか

ほとんどのIaCツールは、既存のリソースを管理下に置くための解決策として「インポート」機能を提供しています。

terraform import aws_instance.web i-1234567890abcdef0
kubectl apply -f pod.yaml  # 既存のPodに対して

しかし、インポートは解決不可能な数学的問題を解決しようとしています—成果物から意図をリバースエンジニアリングすることです。

リバースエンジニアリングの誤謬

インポートはこの変換を試みます：

複雑なランタイム状態 → 単純な宣言

これは、シェフに完成した料理からレシピをリバースエンジニアリングするように頼むこと、あるいは考古学者に遺跡から古代の建設者の正確な思考を決定するように頼むことと同じです。これは数学的に以下と同等です：

コンパイル済みバイナリ → 元のソースコード + 開発者の意図
MP3ファイル → 元のスタジオ録音 + 芸術的ビジョン
焼かれたケーキ → レシピ + シェフの技術 + 材料の出所
分散システム → 元のアーキテクチャ + すべての歴史的決定

情報は不可逆的に失われました。 意図から成果物への圧縮は非可逆的であり、どんなに洗練されたツールを使っても、保存されなかったものを回復することはできません。

インポートドリフトサイクル

インポートプロセス中に実際に起こることは次のとおりです：

インポートはリソースIDを論理名にマッピングする
現在観測されている状態に基づいて、構成の90%を推測する
宣言不可能なランタイム状態（タイムスタンプ、生成されたID、計算値）を無視する
実際の作成パラメータと一致しないかもしれないデフォルトを仮定する
次のプランがこれらの仮定に基づいてすべてを「修正」したくならないことを期待する

避けられない結果：

terraform plan
# Plan: 0 to add, 47 to change, 0 to destroy

# 予期しない変更：
# ~ aws_instance.web
#   + monitoring                 = true -> false  # AWSのデフォルト vs Terraformのデフォルト
#   + ebs_optimized             = true -> null    # AWSは推測したが、Terraformはしなかった
#   + instance_initiated_shutdown_behavior = "stop" -> "terminate"  # 異なる仮定

あなたは1つのリソースのインポートに成功し、他の47個を壊しました—ツールが悪いからではなく、問題が根本的に不可能だからです。

Kubernetesのクロスプラットフォームという嘘

Kubernetesの約束は「一度書けば、どこでも実行できる」でした—すべてのプラットフォームで同一に動作する単一のYAMLマニフェスト。これはおそらく、宣言的抽象化の最も野心的な試みを代表しており、その限界は、プラットフォームに依存しない宣言の不可能性に関するより深い真実を明らかにします。

プラットフォームの現実：同じYAML、異なる宇宙

同じKubernetesマニフェストが、プラットフォームによって根本的に異なる結果を生み出します：

AWS EKS

apiVersion: v1
kind: Service
spec:
  type: LoadBalancer
# 結果：AWS固有の宇宙を持つApplication Load Balancer：
# - Route53統合（AWS DNSエコシステム）
# - ACM証明書自動化（AWS PKI）
# - VPCネイティブネットワーキング（AWSネットワーキングモデル）
# - CloudWatchロギング統合（AWS可観測性）
# - ELBヘルスチェック（AWS固有のアルゴリズム）
# - セキュリティグループ統合（AWSファイアウォールモデル）

Google GKE

apiVersion: v1
kind: Service  
spec:
  type: LoadBalancer
# 結果：GCP固有の宇宙を持つGoogle Cloud Load Balancer：
# - Cloud DNS統合（Google DNSエコシステム）
# - Googleマネージド証明書（Google PKI）
# - VPCネイティブネットワーキング（Googleネットワーキングモデル）
# - Cloud Logging統合（Google可観測性）
# - Googleヘルスチェック（Google固有のアルゴリズム）
# - ファイアウォールルール統合（Googleファイアウォールモデル）

Azure AKS

apiVersion: v1
kind: Service
spec:
  type: LoadBalancer  
# 結果：Azure固有の宇宙を持つAzure Load Balancer：
# - Azure DNS統合（Microsoft DNSエコシステム）
# - Key Vault証明書統合（Microsoft PKI）
# - Azure CNIネットワーキング（Microsoftネットワーキングモデル）
# - Azure Monitor統合（Microsoft可観測性）
# - Azureヘルスプローブ（Microsoft固有のアルゴリズム）
# - ネットワークセキュリティグループ統合（Microsoftファイアウォールモデル）

プラットフォーム補完問題

各プラットフォームは、Kubernetesが宣言せずに残した「空白」を埋めなければならず、これらの空白が実際のシステム挙動の大部分を構成します：

ネットワーキング実装 - CNIプラグインはパフォーマンス、セキュリティモデル、デバッグ能力が劇的に異なる
ストレージクラス - 完全にプラットフォーム固有で、異なるIOPS、耐久性、一貫性保証を持つ
セキュリティポリシー - 異なるRBAC統合、IDプロバイダー、コンプライアンスフレームワーク
モニタリングとロギング - 互換性のないデータモデルとクエリ言語を持つプラットフォームネイティブのソリューション
証明書管理 - 異なる信頼チェーンと更新プロセスを持つクラウドプロバイダーによって異なる
ロードバランサーの挙動 - 異なるアルゴリズム、ヘルスチェックメカニズム、フェイルオーバー戦略
自動スケーリングの決定 - プラットフォーム固有のメトリクス、アルゴリズム、リソース割り当て戦略

「ポータブルな」Kubernetesマニフェストは氷山の一角にすぎません—おそらく実際のシステム定義の10%程度です。残りの90%は、Kubernetes YAMLで宣言できないプラットフォーム固有の実装によって決定され、真のポータビリティを美しくも不可能な夢にしています。

ONDEMANDENVの応答：アプリケーション中心の契約を受け入れる

従来のIaCがマニフェストと現実のギャップに苦しむ一方で、ONDEMANDENVのようなプラットフォームは異なるアプローチを取ります：ギャップと戦うのではなく、それを受け入れるのです。

設定より契約

インフラストラクチャのあらゆる側面を宣言しようとする代わりに、ONDEMANDENVは契約に焦点を当てます—インフラストラクチャをどのように設定すべきかではなく、アプリケーションが何を必要とするかについての明示的な合意です：

// 従来のIaC：すべてを宣言しようとする
const database = new rds.DatabaseInstance(this, 'DB', {
  instanceType: ec2.InstanceType.of(ec2.InstanceClass.T3, ec2.InstanceSize.MICRO),
  engine: rds.DatabaseInstanceEngine.postgres({
    version: rds.PostgresEngineVersion.VER_13_7
  }),
  allocatedStorage: 20,
  storageEncrypted: true,
  backupRetention: cdk.Duration.days(7),
  // ... あらゆる詳細を捉えようとする50以上のパラメータ
});

// ONDEMANDENV契約：意図と境界を宣言する
export const DatabaseContract = {
  needs: {
    storage: { type: 'relational', consistency: 'strong' },
    performance: { tier: 'standard', scaling: 'vertical' },
    backup: { retention: '7d', pointInTime: true },
    security: { encryption: 'at-rest', access: 'private' }
  },
  provides: {
    endpoint: { type: 'postgresql', version: '^13.0' },
    schema: { migrations: './db/migrations' }
  }
}

アプリケーション中心の環境

ONDEMANDENVは、デプロイの基本単位はインフラストラクチャではなく、そのコンテキストを持つアプリケーションであることを認識しています。インフラストラクチャの状態を完全に宣言しようとするのではなく、以下に焦点を当てます：

コンテキストの境界 - このアプリケーションが機能するために何が必要か？
契約の履行 - 現在の制約の中でこれらのニーズをどのように満たすことができるか？
環境のバージョニング - 時間の経過とともにアプリケーションコンテキストの進化をどのように追跡できるか？
分離の保証 - 環境が互いに干渉しないことをどのように保証できるか？

このアプローチは、インフラストラクチャには常に宣言不可能な要素が含まれることを認めつつも、これらの実装の詳細に関係なく、アプリケーションが確実にデプロイおよびテストできることを保証します。

人間との並行性：認知の限界とメンタルモデル

この限界は、人間が複雑さを理解し、乗り越える方法を反映しています。私たちは利用可能な情報のほんの一部しか知覚し、処理することができません：

観測可能な現実 vs 実際の現実

人間の情報処理のボトルネックは、なぜ宣言的システムが同様の制約に直面するかを明らかにします：

人間の感覚入力：毎秒約1100万ビット
意識的な処理：毎秒約40ビット
宇宙の情報内容：約10^120ビット
インフラシステムの状態：毎秒約10^9ビット（そして増加中）

私たちは複雑さを乗り越えるために、単純化されたメンタルモデルを作成します：

現実：無限の複雑さと絶え間ない変化
メンタルモデル：単純化された、静的な抽象化
行動：不完全で時代遅れの情報に基づく
結果：しばしば期待と異なる

人間が現実を完全に理解できず、単純化されたモデルで操作しなければならないように、IaCは複雑なシステムを完全に宣言できず、不完全な抽象化で作業しなければなりません。

インフラにおける地図と領土問題

私たちのインフラマニフェストは地図のようなものです—ナビゲーションに役立つ有用な抽象化ですが、根本的には領土の不完全な表現です：

地図	領土	インフラの並行性
道路を示す	交通、天候、工事は示さない	リソースは示すが、ランタイムの挙動は示さない
静的なスナップショット	動的で変化する現実	固定された宣言 vs 進化するシステム
単純化された記号	複雑な物理的現実	YAML/JSON vs 実際のクラウドプロバイダーの内部
限られたスケール	無限の詳細が利用可能	選択されたフィールド vs 完全なシステム状態

地図とマニフェストはどちらも、詳細を省略するからこそ価値がありますが、私たちがその限界を忘れ、モデルを現実と間違えたとき、どちらも危険になります。

哲学的含意：決定論 vs 創発

決定論的な仮定

宣言的IaCは、根本的に決定論的な世界観の上に構築されています：

同じ入力 → 同じ出力（常に）
同じマニフェスト → 同じインフラ（常に）
同じ宣言 → 同じランタイム挙動（常に）

これは、複雑なシステムは単に複雑なだけであり、十分な仕様があれば完全な予測可能性を達成できると仮定しています。

創発的な現実

しかし、複雑なシステムは、その構成要素からは予測できない創発的な挙動を示します：

同じ入力 → 異なる出力（コンテキスト、タイミング、履歴による）
同じマニフェスト → 異なるインフラ（プラットフォーム、時間、運用履歴による）
同じ宣言 → 異なる挙動（トラフィックパターン、セキュリティアップデート、ネットワーク状況による）

インフラにおける創発の例：

データベースのパフォーマンスは、データ分散、クエリパターン、ハードウェアの摩耗に依存する
ネットワーク遅延は、ルーティング決定、輻輳、地理的要因によって変動する
セキュリティ体制は、脆弱性の発見とパッチのデプロイによって変化する
自動スケーリングの挙動は、学習された使用パターンとプラットフォームのアルゴリズムに適応する
サービスメッシュのルーティングは、観測された障害パターンとパフォーマンスメトリクスに基づいて進化する

今日デプロイされたデータベースクラスターは、先月デプロイされた「同じ」クラスターとは異なる挙動をします。たとえマニフェストが同一であっても、なぜなら：

セキュリティパッチがリリースされ、適用された
ネットワークトポロジが他のワークロードとともに進化した
パフォーマンス特性が使用パターンとともに変化した
プラットフォームのアルゴリズムが運用データから学習した
コンプライアンス要件が変化した

時間の矢：なぜ再宣言は失敗するのか

おそらく最も根本的なことは、時間は不可逆であるということです。一度システムが：

インシデント中に手動で変更された
自動パッチ適用プロセスを経験した
実際のワークロードの下でパフォーマンスのボトルネックを経験した
セキュリティスキャンによって変更された

…となると、それは二度と元の宣言された状態に戻ることはできません。履歴を消すことはできません。terraform applyを再実行しても、過去に起こった創発的な学習、エントロピーの蓄積、または手動による介入を消去することはできません。

これは、複雑なシステムが、その履歴、環境、および相互作用の産物であるためです。マニフェストは単なる意図の声明であり、システムが時間とともに進化する豊かで複雑な物語ではありません。

結論：不可能性を受け入れる

IaCと宣言的インフラは強力なツールですが、それらは魔法ではありません。それらは、時間、エントロピー、および創発的複雑さという現実の根本的な力によって制約されています。

この不可能性を認識することは、敗北主義ではありません。それは解放です。それは私たちを次のことから解放します：

完璧な宣言という幻想を追い求めること
マニフェストと現実のギャップと絶えず戦うこと
すべての詳細をコードで捉えようとすること

代わりに、私たちは以下に焦点を当てることができます：

アプリケーション中心の契約：アプリケーションが何を必要とするかを定義し、プラットフォームに詳細を処理させる。
回復力のある実践：システムが失敗することを期待し、迅速に回復するためのツールを構築する。
観測可能性：単一の真実の源を宣言しようとするのではなく、システムの実際の状態を理解することに投資する。
創発を受け入れる：システムが時間とともに学習し、適応することを可能にするアーキテクチャを設計する。

真に効果的なインフラ管理は、現実をマニフェストに強制しようとすることからではなく、マニフェストが常に不完全であることを認め、そのギャップを管理するための堅牢なシステムを構築することから生まれます。それは、私たちがコントロールできない力をコントロールしようとするのをやめ、代わりに、私たちがナビゲートしなければならない複雑で動的な現実の中で、回復力があり、適応性があり、観測可能なシステムを構築することに集中するときです。

究極的には、IaCの目標は、現実の完璧なレプリカを作成することではなく、アプリケーションのニーズとインフラの能力との間に、信頼でき、再現可能で、進化可能な契約を作成することです。その契約を受け入れることが、前進する道です。

</rewritten_file>