この記事は概念解説記事です。 Infrastructure from Code（IfC） は、「アプリのコードを書くと、必要なインフラがそこから自動生成される」という考え方です。 2026年6月にAWSが公式フレームワーク AWS Blocks をPreview公開したことで、いったん失速していたこの概念が再び注目を集めています。 本稿は2026年6月21日（JST）時点で、一次情報をもとにIfCの定義・IaCとの違い・4つの実装方式・主要フレームワークの盛衰・利点と限界を整理します。
Terraformを書いたことがある人なら、「アプリのコードとは別に、インフラ定義をもう一式書く」面倒さを知っているはずです。 IfCはその二重作業をなくし、アプリのコードを唯一の真実（single source of truth）にしよう という発想から生まれました。 ただし、この「魔法」には光と影があります。本稿では両方を扱います。
- ・IfCはアプリのコードからインフラを推論・生成するパラダイム。IaC（インフラを人が書く）の次の抽象として提案された。
- ・抽象度のスペクトラムではIaCとPaaSのあいだ。「IaCより書かず、PaaSより制御できる」中間点を狙う。
- ・実装は4分類：SDK型（Nitric/Ampt）・アノテーション型（Klotho）・ハイブリッド型（Encore/Shuttle）・新言語型（Winglang）。
- ・2022〜2024年に乱立したが多くが失速。Nitric・Encoreは健在で、2026年のAWS Blocks登場が「復権」の契機に。
- ・最大の弱点は抽象の漏れとロックイン。「複雑さは消えず、置き場所が移るだけ」を理解して使う。
IfCは「インフラ運用をどう自動化するか」というより大きな潮流の一部です。ノーコードからコードまでの自動化ツール全体像は AI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方 にまとめてあるので、IfCがどの位置に収まるかを俯瞰したい場合はあわせて読むと整理しやすくなります。
1. Infrastructure from Codeとは — コードがインフラを決める
IfC（Infrastructure from Code）を一言で言うと、「アプリケーションのコードから、必要なインフラを自動的に生成する」 アプローチです。 IfCの情報を集約するコミュニティサイト infrastructurefromcode.com は、IfCを次のように定義しています。
Infrastructure-from-Code（IfC）は、ソフトウェアアプリケーションのソースコードを理解することから、クラウドリソースの作成・構成・管理を自動化するプロセスである。明示的な記述を必要としない。
「明示的な記述を必要としない」——ここがIaCとの決定的な分かれ目です。 StackGenの解説も同様に、IfCを「アプリコード・既存のstateファイル・デプロイ仕様・クラウド環境など多様なソースから、インフラの生成を自動化する」ものと位置づけています。 インフラ構成をゼロから書く必要をなくし、アプリのビジネス意図に合わせてインフラを仕立てる のがIfCのねらいです。
用語としての「Infrastructure from Code」が広く使われ始めたのは2022〜2023年頃で、Klothoの「State of Infrastructure-from-Code」シリーズや前述のコミュニティサイトを通じてカテゴリ名として定着しました。 特定の一人が発明したというより、複数のスタートアップとコミュニティが同時多発的に同じ方向を志向する中で、共通言語として固まった 経緯があります。
具体例で考えると分かりやすくなります。 IaCなら、あなたは「DynamoDBテーブルを1つ作り、Lambdaに読み書き権限を付け……」とインフラ側を明示的に記述します。 IfCなら、あなたはアプリのコードで「キーバリューストアにデータを入れる」と書くだけ。 ツールがそのコードを解析し、裏で必要なテーブルや権限を生成 します。
つまり、IaCが「インフラを書く」のに対し、IfCは 「アプリを書けば、インフラが付いてくる」。 インフラとアプリのコードが一体化し、二重管理から解放される——これがIfCの核心的な約束です。
・IaC（Infrastructure as Code）：インフラ構成を人がコードで書く（Terraform / CloudFormation / CDK）。
・IfC（Infrastructure from Code）：インフラ構成をアプリのコードから生成する（Encore / Nitric / AWS Blocks 等）。
「as」と「from」の一語違いだが、インフラ定義を誰が書くかが根本的に違う。
2. IaCとの違い、PaaSとの違い — 抽象度のスペクトラム
IfCの立ち位置は、抽象度の物差しの上に置くと正確に理解できます。
左から右へ、抽象度が上がるにつれて「自分で書く量」は減り、「細かく制御できる自由度」も減っていきます。
・手動運用：コンソールやSSHで都度操作する。再現性が低い
・IaaS：VMやネットワークを借りる。OSから上は自分で構築
・IaC：Terraform/CDKでインフラを明示的にコード化する。再現性は高いが、記述量は多い
・IfC：アプリのコードからインフラを生成する。記述量は減るが、生成ロジックはツールに委ねる
・PaaS：インフラを完全に隠す（Herokuなど）。手軽だが、枠の外には出られない
IaCとの違い は、記述の方向です。 IaCは「インフラ→アプリ」の順で、まずインフラを定義してからアプリを載せます。 IfCは「アプリ→インフラ」の順で、アプリを書くとインフラが導出されます。
PaaSとの違い は、制御を取り戻せるかどうかです。 PaaSはインフラをブラックボックスにして見せませんが、IfCの多くは生成物が自分のクラウドアカウント上の実インフラ（CDK/CloudFormation等）であり、必要なら低レベル設定に降りられるエスケープハッチ を持ちます。 この「抽象の壁が薄く、いつでも下に潜れる」点が、PaaSとIfCを分ける決定的な差です。
代表的なツールを、この物差しの上に並べると立ち位置がはっきりします。 Terraformは純粋なIaC、Nitric・Klotho・Winglangは方式こそ違えど「アプリのコードからインフラを生成する」IfCです。
| ツール | 分類 | インフラは誰が書くか | 主な対応言語 | 生成物 / プロビジョナ |
|---|---|---|---|---|
| Terraform | IaC | 人が明示的に記述（HCL） | HCL | 各種クラウドプロバイダ |
| SST | IaC寄り（境界） | 人がCDK上の高レベル構文で記述 | TypeScript | CloudFormation（AWS） |
| Nitric | IfC（SDK型） | アプリのコードから生成 | Python / TS / Go / C# | Pulumi（AWS / GCP / Azure） |
| Klotho | IfC（アノテーション型） | 注釈で要件を宣言 | JS / Python / Go | IaC（Terraform等）を生成 |
| Winglang | IfC（新言語型） | 専用言語で記述→生成 | JSにコンパイル | Terraform / CDK 等 |
ここで注意したいのが SST の位置です。 SSTはAWS CDKの上に立つ高レベルフレームワークで、TypeScriptで書けて生産性は高いのですが、Encoreの比較記事が指摘するとおり 本質はまだIaC寄り です。 たとえば「DBを1つ足す」ときに、SST（やTerraform・CDK・Pulumi）では アプリ側とインフラ側の2箇所を変更 しますが、EncoreやNitricのような本格的IfCでは アプリのコードを1箇所直すだけ（1 PR・1レビュー・1デプロイ）で済みます。 「TypeScriptで書ける＝IfC」ではなく、インフラ定義を人がまだ書いているかどうか が、IaCとIfCを分ける本当の線引きです。
3. IfCの4分類 — SDK型・アノテーション型・ハイブリッド型・新言語型
IfCツールは「どうやってコードからインフラを読み取るか」で4つに大別できます（Klotho/Nitricの分類に準拠）。
| 方式 | 仕組み | 代表ツール | 主な対応言語 |
|---|---|---|---|
| SDK型 | 専用SDKの使われ方をデプロイ時に解析し、インフラを生成 | Nitric / Ampt | Python・TS・Go・C#（Nitric） |
| アノテーション型 | コードに注釈を付けてインフラ要件を宣言。ロジックとインフラを分離 | Klotho | JS・Python・Go |
| ハイブリッド型 | フレームワーク内でアノテーションを使う。両者の中間 | Encore / Shuttle | Go（Encore）/ Rust（Shuttle） |
| 新言語型 | クラウド記述専用の新言語を導入。デプロイ時/実行時を区別 | Winglang / Darklang | JSにコンパイル（Wing） |
それぞれにトレードオフがあります。
SDK型 は導入が簡単な反面、インフラ生成がSDKの機能範囲に縛られます。 新しいクラウド機能が出ても、SDKが対応するまで使えない——「常に一歩遅れる」構造的な弱点があります。
アノテーション型 は、アプリのロジックとインフラ要件を分離できるのが利点です。 テンプレートに依存せず、コードに「ここはキャッシュが要る」といった印を付けていく感覚で書けます。
新言語型 のWinglangは思想が独特です。 「既存のプログラミング言語はクラウドアプリを記述するには不十分だ」という主張のもと、デプロイ時に実行されるコード（preflight）と、実行時に動くコード（inflight）を言語レベルで区別 します。 クラウド特有の「ビルド時と実行時の二相性」を言語に組み込んだ、野心的なアプローチでした。
IfCツールがどうコードからインフラを導くか、流れを図にすると次のようになります。
どの方式でも、出口は同じ「インフラの生成」です。 違いは入口——コードのどこからインフラ要件を読み取るか にあります。
4. 盛衰とAWS Blocksによる復権 — 失速から最大手の参入へ
IfCは2022〜2023年にかけて大きな期待を集め、多数のスタートアップが参入しました。 しかし現実は厳しく、多くが市場の牽引に失敗 しました。
Nitricの「State of IfC」やThe New Stackの振り返り記事によれば、状況はおおむね次のとおりです。
・Winglang（Wing）：新言語という野心的アプローチだったが、開発が停止・縮小
・Klotho：アノテーション型の代表格だったが、方針転換
・Ampt（旧Serverless Cloud）：ピボットまたはメンテナンスモード寄りに
・Nitric：現在も活発に開発が続く数少ない生き残り
・Encore：同じく健在で、Go中心に支持を集める
The New Stackはこの流れを 「Infrastructure From Code: What Went Wrong（何が間違っていたか）」 という記事タイトルで総括しています。 なぜ失速したのか。理由は複合的ですが、要点は次のように整理できます。
・抽象の漏れ：単純なアプリは楽になるが、複雑な要件になると結局インフラの中身を理解する必要が出る。
・新言語・新SDKの学習コスト：「学ばなくていい」はずが、ツール固有の作法を学ぶ羽目になる。
・ロックイン懸念：独自抽象に乗るほど、他基盤への移行が難しくなる。
・市場教育の難しさ：IaCに慣れたチームに「書かない」価値を伝えるのは想像以上に難しかった。
重要なのは、IfCという概念が否定されたわけではない ことです。 躓いたのは主に「単独スタートアップが新言語や独自SDKで市場を作ろうとした」進め方であり、コンセプト自体は生き続けました。 そして2026年、状況を変える出来事が起きます。
AWS Blocksが示す「IfCの復権」
2026年6月16日、AWSが公式のIfCフレームワーク「AWS Blocks」をPreview公開 しました。
オープンソース（aws-devtools-labs/aws-blocks）のTypeScriptフレームワークで、最大手クラウドベンダーが自らIfCに乗り出したことは、このカテゴリにとって大きな転機です。
AWS Blocksの分かりやすさは、1行のコードの振る舞いに集約されています。
new KVStore(scope, 'todos')
この同じ1行が、ローカル開発ではメモリ実装、デプロイ時はDynamoDBテーブル、LambdaランタイムではAWS SDK呼び出しへと、コードを書き換えずに姿を変えます。 まさに「アプリを書けばインフラが付いてくる」というIfCの理念そのものです。
Previewの時点で、公式ドキュメントによれば 約20個のBlock が用意され、アプリに必要な部品を幅広くカバーします。
・データベース：Postgres（Aurora）・DynamoDB
・認証：Cognito
・AIエージェント / ナレッジベース：Bedrock
・ファイル保存：S3 ／ メール送信：SES
・リアルタイムメッセージング・バックグラウンドジョブ・スケジュール実行
開発体験も特徴的です。
npm run dev を叩けば、AWSアカウント無しで Postgres・認証・リアルタイム通信・ファイル保存が動くアプリがローカルで立ち上がり、同じコードをそのままLambda・DynamoDB・Aurora・Bedrockへデプロイできます。
料金はBlocks自体には追加課金がなく、実際に消費したAWSサービスの分だけ を支払う形です。
過去のIfCスタートアップと違うのは、生成物が AWS標準のCDK/CloudFormation である点、そして いつでもCDKに降りて細かく制御できる 点です。 独自言語を覚える必要がなく、TypeScriptで書け、抽象の壁が薄い。 かつてのIfCが躓いた「学習コスト」「ロックイン」「抽象の漏れ」に、ベンダー公式の体力で正面から答えにいった構図と言えます。
AWS Blocksそのものの機能・他ツールとの違いは AWS Blocks徹底解説｜ローカルで動かしAWSへそのままデプロイ、LocalStack系との違い で詳しく扱っているので、IfCの具体例としてどう動くのかを見たい場合はあわせて確認してください。
ただし、AWS BlocksもまだPreviewです。 「IfCが完全に復権した」と断じるのは早く、最大手の参入で再び土俵に上がった、という段階が正確な見立てです。
5. 利点と限界 — 抽象の漏れ・ロックイン・「魔法」の代償
IfCを採用するかどうかは、利点と限界を天秤にかけて決めるべきです。
利点 は明快です。
・インフラ定義の二重管理が消え、アプリのコードが唯一の真実になる
・ボイラープレートが減り、開発速度が上がる
・型安全がアプリからインフラまで一貫し、設定ミスを早期に検出できる
・ローカルファースト開発と相性が良く、クラウドアカウント無しで試せる実装もある
・アプリ開発者（やAIエージェント）の学習コストを下げられる
一方、限界 は抽象化の本質に根ざしています。 ジョエル・スポルスキの有名な言葉、「すべての非自明な抽象は漏れる（All non-trivial abstractions are leaky）」 はIfCにも当てはまります。
内部の複雑さは、予期しない形で表に漏れ出す。そのとき開発者は、抽象とその下のシステムの両方を理解しなければならなくなる。
具体的には、次のような壁にぶつかります。
・抽象の漏れ：単純なケースは楽だが、高度なIAM条件やネットワーク境界を表現しようとすると抽象が破綻する
・見せかけのマルチクラウド：「どのクラウドでも動く」とうたっても、実態は各SDKの継ぎ接ぎで、if (cloud === "aws") のような分岐は真の抽象化ではない
・複雑さは消えない：高レベルの抽象は複雑さを除去するのではなく、置き場所を移すだけ
・コストとパフォーマンス：スタックを「魔法の箱」として扱うと、コスト最適化や性能チューニングで詰まる
つまりIfCは、抽象の下を理解する気がある人にとっての時短ツール であって、インフラを完全に忘れるための道具ではありません。 この一線を理解しているかどうかが、採用の成否を分けます。
6. AIエージェント時代のIfC — なぜ今あらためて注目か
IfCが2026年に再評価されている背景には、AIエージェントによるコード生成の普及 があります。
IaCの記述は定型的で、AIが書くのが得意な領域です。 しかし「AIがTerraformを大量に書ける」ようになると、今度は そのコードの正しさを人間がレビューする負荷 が問題になります。 ここでIfCの発想が効いてきます。
AWS Blocksは AIエージェントがコードを書く前提で設計 されており、フレームワーク自体に正しい書き方が組み込まれています。 これは「人間の学習コストだけでなく、エージェントが間違えるコストも下げる」という設計思想です。 高レベルで型安全なIfCの部品は、人にもエージェントにも 「踏み外しにくいガードレール」 として働きます。
・IaC＋AI：AIが大量のインフラコードを書く → レビュー負荷とミスのリスクが増える
・IfC＋AI：そもそもインフラ記述を減らし、安全な部品の上でAIに書かせる → ミスの余地が構造的に小さい
「IaCはもう古いのか」という議論も出ていますが、現実的な見立ては 共存 です。 細かい制御が要る基盤はIaCで、アプリに付随するインフラはIfCで——という棲み分けが、AIエージェント時代の落としどころになりつつあります。
7. IfCを採用するかの判断基準
ここまでを踏まえ、IfCを実プロジェクトに入れるかどうかの判断軸を整理します。 過去のIfCが躓いた教訓は、そのまま 選定チェックリスト になります。
| 観点 | 確認すること | 地雷サイン |
|---|---|---|
| エスケープハッチ | 抽象で足りないとき、低レベル（CDK/Terraform等）に降りられるか | 抽象の外に出る手段が無い |
| 生成物の標準性 | 出力が標準のIaC/CloudFormation等で、ツールを外しても残るか | 独自フォーマットだけで完結 |
| 継続性 | 開発が活発か。バックに体力のある主体がいるか | コミット停滞・単独スタートアップ依存 |
| 言語・学習コスト | 既存言語で書けるか。新言語の習得が必要か | 独自言語の習得が前提 |
| マルチクラウドの実態 | 「対応」が本物か、SDKの継ぎ接ぎか | 分岐だらけで実質単一クラウド |
この5項目で言えば、AWS Blocks は「エスケープハッチあり（CDKに降りられる）」「生成物が標準（CloudFormation）」「バックがAWS」「TypeScriptで書ける」という点で、過去のIfCの弱点をかなり潰しています。 裏を返せば、これらを満たさないIfCツールは——どれだけデモが魔法的でも——本番投入は慎重になるべき、ということです。
導入のしかたも段階的が安全です。
・まず一部から：新規の小さなサービスや社内ツールでIfCを試し、いきなり基幹に入れない
・抜け道を事前に確認：低レベル設定が必要になる典型ケースで、ちゃんと降りられるか先に検証する
・IaCと併用前提で設計：ネットワーク・IAMの土台はIaC、アプリ付随リソースはIfC、と最初から役割を分ける
IfCの採否は「魔法がすごいか」ではなく、「魔法が解けたときに自分で何とかできるか」で決める。降りられる抽象なら攻めてよく、降りられない抽象は避けるのが鉄則。
まとめ
Infrastructure from Code（IfC）は、「アプリのコードを書くと、必要なインフラがそこから生成される」 パラダイムでした。
確認できた事実を整理すると、次のようになります。
・IfCはIaC（インフラを人が書く）の次の抽象として提案され、抽象度ではIaCとPaaSのあいだに位置する
・実装は4分類（SDK型・アノテーション型・ハイブリッド型・新言語型）。Nitric・Encoreが代表的な生き残り
・2022〜2024年に乱立したが多くが失速。原因は抽象の漏れ・学習コスト・ロックイン・市場教育の難しさ
・2026年のAWS Blocks（Preview）登場で、最大手の参入により再び注目を集めている
・最大の限界は「抽象の漏れ」。複雑さは消えず置き場所が移るだけ、という性質の理解が前提
IfCは「インフラを忘れるための魔法」ではなく、抽象の下を理解する気がある人のための時短。採用するなら、抽象の壁が薄くいつでも低レベルに降りられる実装（AWS BlocksのようにCDKへ抜けられるもの）を選ぶのが安全。AIエージェント時代には「細かい基盤はIaC、アプリ付随のインフラはIfC」の共存が現実解になる。まずは概念実証として、ローカルで試せるIfC実装から触ってみるのがおすすめ。
配信メモ
X投稿フック案（120〜200文字、3案）
- “Infrastructure as Code” の次は “Infrastructure from Code”。IaCはインフラを人が書く、IfCはアプリのコードからインフラが生成される。Terraformの二重作業をなくす発想。2022年に乱立→失速したけど、AWS Blocksの登場で復権中。4分類と盛衰を整理した。
- IfC（Infrastructure from Code）が躓いた理由は明確。「抽象は漏れる」から。単純なアプリは楽でも、複雑なIAMやネットワークになると結局中身を理解する羽目に。複雑さは消えない、置き場所が移るだけ。それでもAIエージェント時代に再評価される理由とは。
- IfCの抽象度スペクトラム：手動→IaaS→IaC→IfC→PaaS。IfCは「IaCより書かず、PaaSより制御できる」中間点。AWS Blocksが面白いのは、抽象の壁が薄くていつでもCDKに降りられること。図で整理👇
はてブ用CTA
DevOps/インフラ向け。IaCとの違い・主要フレームワークの盛衰・AWS Blocksの位置づけを一気に把握できる概念解説。
内部リンク提案（公開後にこの記事へリンクすべき既存記事）
- /tool/aws-blocks-localstack-alternative/ — IfCの具体例として相互リンク
- /explain/ai-automation-tools-guide-2026/ — 自動化潮流の中の位置づけ
想定検索クエリ（GSCで観測したい）
- Infrastructure from Code とは / IfC IaC 違い
- IfC フレームワーク 比較
- Encore Nitric Winglang
- AWS Blocks IfC –>
2026-10-11 に実測で確かめ直した
本記事の対象リポジトリを 2026-10-11 に clone して、ライセンスの実体・更新状況・規模を測り直した。 紹介文やバッジではなく、リポジトリの中身を直接読んだ値だ。
# ① 浅く clone する
git clone --depth 1 https://github.com/ehsanmok/awesome-infrastructure-from-code /tmp/awesome-infrastructure-from-code
# ② 直近のコミット日を見る → 2024-05-29
git -C /tmp/awesome-infrastructure-from-code log -1 --format=%ad --date=short
# ③ ライセンスの実体と規模を見る → Creative Commons / 5 ファイル
head -3 /tmp/awesome-infrastructure-from-code/LICENSE* 2>/dev/null; git -C /tmp/awesome-infrastructure-from-code ls-files | wc -l
③が肝心で、ライセンスは Creative Commonsだった。バッジや README の記述ではなく LICENSE ファイルの中身を読んでいる。
| 確認項目 | 2026-10-11 の実測 | 確認方法 |
|---|---|---|
| ライセンス | Creative Commons | head -3 LICENSE* でファイル本文を読む |
| 直近コミット | 2024-05-29（865日前） | git log -1 --date=short |
| 規模 | 追跡ファイル 5 本 | git ls-files \| wc -l |
参照ソース
・ehsanmok/awesome-infrastructure-from-code（GitHub） — 本記事が 2026-10-11 に測り直した対象
・LICENSE — ライセンスの実体（手順③で読んだファイル）
・What is Infrastructure from Code? IaC vs. IfC, Explained（StackGen）
・State of Infrastructure-from-Code 2023（Klotho）
・State of Infrastructure from Code 2024（Nitric）
・Infrastructure From Code: What Went Wrong（The New Stack）
・Infrastructure from Code（IfC）コミュニティサイト
・What is AWS Blocks?（AWS公式ドキュメント）
・aws-devtools-labs/aws-blocks（GitHub）
・AWS Launches Blocks, a TypeScript Framework for AI Agents（InfoQ）
・Encore vs Terraform vs AWS CDK vs Pulumi vs SST（Encore）
