Infrastructure from Code（IfC）本番運用の現実：生存フレームワーク比較と段階的移行戦略

この記事でわかること

• Infrastructure from Code（IfC）が2026年現在どのような淘汰を経て、どのフレームワークが生き残っているか
• Nitric・Encore・SST v3・Modal・Shuttle・Amptの6ツールを「本番運用視点」で比較した選定基準
• IaCConf 2025で「IfCは失敗した」と評された理由と、それでもIfCが再評価されている背景
• 既存Terraform資産を捨てずにIfCを段階的に導入する3つの移行パターン
• AI時代にIfCが持つ構造的優位性と、導入判断のための意思決定フレームワーク

対象読者

• 想定読者: IaCの運用経験がある中級者のインフラエンジニア・バックエンド開発者
• 必要な前提知識:
  • TerraformまたはAWS CDKの基本操作（terraform plan/apply の経験）
  • TypeScriptまたはGoの基礎文法
  • AWSやGCPの基本サービス（Lambda、Cloud Run、S3など）の概念理解
• MLEの方へ: IfCはMLパイプラインのインフラ自動化にも直結します。特にModalはGPUワークロード向けIfCとして注目されています

関連記事: IfCの概念や基本的なアプローチ分類（SDK型・アノテーション型・新言語型）については「Infrastructure from Code（IfC）でクラウド構築を自動化する実践ガイド」で解説しています。本記事はその続編として、本番運用・移行戦略・2026年のエコシステム成熟度に焦点を当てます。

結論・成果

2026年6月時点で、IfCエコシステムは初期の7ツールから実質6ツールに淘汰され、「IaCを置き換える」という当初の野心から**「IaCと共存するハイブリッドアプローチ」へと現実的に進化しています。生き残ったフレームワークのうち、Encore.tsはExpress.js比でスループット9倍**（121,005 req/s vs 15,707 req/s）、P99レイテンシ80%削減（2.3ms vs 11.9ms）をベンチマークで報告しており、IfCの「パフォーマンスを犠牲にしない抽象化」が実証されつつあります。

一方で、IaCConf 2025ではMomentoのAllen Heltonが「IfCは失敗した」と講演しており、コンプライアンス要件への対応や開発者の制御権放棄への抵抗が課題として残ります。本記事では、この「期待と現実のギャップ」を具体的なデータとともに整理し、段階的な導入判断を支援します。

IfCエコシステムの現在地を把握する

「IfCは失敗した」――IaCConf 2025の問題提起

2025年5月に開催されたIaCConf 2025（登録2,800名超、ライブ参加1,300名以上）で、MomentoのエコシステムエンジニアであるAllen Heltonが「Infrastructure from Code: What Happened and What's Next」と題した講演を行いました。

Heltonの主張は明快です。IfCが当初約束した「アプリケーションコードを書くだけでインフラが自動構築される」というビジョンは、以下の2つの構造的問題により実現しなかったというものです。

1. 開発者が制御を手放せない問題

IaCツール（Terraform、CDKなど）を使い慣れたエンジニアにとって、インフラの構成を「フレームワークに任せる」ことは、デバッグ時のブラックボックス化を意味します。本番環境で障害が起きたとき、「なぜこのLambdaにこのIAMポリシーが付与されているのか」を追跡できないリスクは、運用チームにとって受け入れがたいものでした。

2. コンプライアンス要件との衝突

金融・医療・公共セクターなど規制の厳しい業界では、インフラ定義がデプロイ前に正式なレビューと承認を経る必要があります。アプリケーションコードとインフラコードが分離されていることは、このコンテキストでは「バグ」ではなく**「機能」**です。セキュリティチームとコンプライアンスチームが独立して変更をレビューできる境界線が必要だからです。

注意: Heltonの「失敗した」という評価は、IfCというカテゴリ全体への包括的な判断であり、個別フレームワーク（Nitric、Encoreなど）の技術的成果を否定するものではありません。実際にHelton自身も、IfCベンチマーク記事で「クラウド開発の将来はIfC的なアプローチになる」と述べています。

エコシステムの淘汰マップ

2024年にNitricが公開したState of Infrastructure from Codeでは、IfCツールを4つのアプローチに分類しています。2026年時点での生存状況を整理しましょう。

アプローチ	ツール	2026年ステータス	特徴
コード分析型	Klotho	開発停止・アーカイブ	アノテーションから推論、Pulumiテンプレート生成
言語SDK型	Nitric	v1.27.6（活発）	マルチ言語、マルチクラウド、カスタムプロバイダー
言語SDK型	Encore	活発（Go/TS）	Rustランタイム、9倍スループット、AWS/GCP
新言語型	Wing	v0.85（未GA）	AWS CDK作者開発、独自言語+TS SDK
プラットフォーム型	Ampt	活発	Node.js 22、Next.js/Remix対応
プラットフォーム型	Modal	Series B $87M	Python/GPU特化、OpenAI Agents SDK統合
プラットフォーム型	Shuttle	活発	Rust専用、アノテーションベース
IaCハイブリッド型	SST v3	安定版（Ion）	Pulumi + Terraform、AWS中心

よくある間違い: 「IfCツールはすべて同じ思想で動いている」と考えがちですが、実際にはAmptのような「すべてお任せ」型からNitricのような「自分のIaCツールと組み合わせる」型まで、制御レベルが大きく異なります。この違いを理解せずに導入すると、チームの期待とツールの提供価値がミスマッチします。

生存フレームワーク6ツールを本番運用視点で比較する

比較の軸：5つの評価基準

本番運用で重要になる5つの観点で比較します。Allen HeltonのIfCベンチマークの評価軸を参考に、本番運用に必要な要素を加えました。

Nitric：マルチクラウド＋カスタマイズの本命

Nitricはオーストラリア発のオープンソースIfCフレームワークで、マルチクラウド対応とカスタムプロバイダーが特徴です。

本番運用で評価できる点:

• プロバイダーシステム: AWS、GCP、Azureに加え、Kubernetes上へのデプロイにも対応。プロバイダーはPulumiまたはTerraformで実装されており、内部でどのリソースが作られるか追跡できます
• カスタムプロバイダー: 既存プロバイダーの拡張、または完全に新規のプロバイダーをGoで作成可能。組織固有のセキュリティポリシーやネーミング規則を埋め込めます
• 言語サポート: TypeScript、Python、Go、Java、Dartに対応

// Nitric: APIとデータベースの宣言（TypeScript）
import { api, bucket, kv } from "@nitric/sdk";

const mainApi = api("orders");
const orderStore = kv("orders").allow("get", "set", "delete");
const receiptsBucket = bucket("receipts").allow("write");

mainApi.post("/orders", async (ctx) => {
  const order = ctx.req.json();
  const orderId = crypto.randomUUID();

  await orderStore.set(orderId, {
    ...order,
    status: "pending",
    createdAt: new Date().toISOString(),
  });

  return ctx.res.json({ orderId, status: "pending" });
});

このコードから、Nitricは以下を自動推論します。

• API Gateway（REST APIエンドポイント）
• KVストア（DynamoDB / Firestore / Azure CosmosDB）
• オブジェクトストレージ（S3 / Cloud Storage / Azure Blob）
• 必要なIAMポリシー（最小権限の原則に基づく）

制約条件:

Nitricのプロバイダーが生成するリソース構成は、プロバイダーの実装に依存します。AWSプロバイダーではLambda + API Gatewayが使われますが、「ECS + ALBに変更したい」場合はカスタムプロバイダーの作成が必要です。この自由度はメリットですが、カスタムプロバイダーの保守コストは自チームが負担する点に注意してください。

Encore：パフォーマンス重視のTypeScript/Goバックエンド

Encoreはスウェーデン発のバックエンドフレームワークで、Rustで書かれた独自ランタイムにより高いパフォーマンスを実現しています。

ベンチマークデータ（Encore公式ベンチマーク、150並行ワーカー × 10秒、ohaによる負荷テスト）:

フレームワーク	リクエスト/秒（バリデーションなし）	リクエスト/秒（スキーマバリデーション付き）
Encore.ts	121,005	107,018
Bun	101,611	33,772
Elysia	82,617	35,124
Hono	71,202	33,150
Fastify	62,207	48,397
Express	15,707	11,878

特筆すべきは、スキーマバリデーション付きの場合にEncore.tsの優位性がさらに拡大する点です。Express（Zod使用）が11,878 req/sまで低下するのに対し、Encore.tsは107,018 req/sを維持しています。これはEncore.tsがTypeScriptの型定義をビルド時にパースし、Rustランタイム側でバリデーションを実行するアーキテクチャによるものです。

// Encore.ts: サービス定義とインフラ宣言
import { api } from "encore.dev/api";
import { SQLDatabase } from "encore.dev/storage/sqldb";

const db = new SQLDatabase("orders", {
  migrations: "./migrations",
});

interface CreateOrderRequest {
  productId: string;
  quantity: number;
  userId: string;
}

interface CreateOrderResponse {
  orderId: string;
  status: string;
}

export const createOrder = api(
  { expose: true, method: "POST", path: "/orders" },
  async (req: CreateOrderRequest): Promise<CreateOrderResponse> => {
    const row = await db.exec`
      INSERT INTO orders (product_id, quantity, user_id, status)
      VALUES (${req.productId}, ${req.quantity}, ${req.userId}, 'pending')
      RETURNING id
    `;
    return { orderId: row.id, status: "pending" };
  }
);

new SQLDatabase("orders") と書くだけで、ローカル開発時にはPostgreSQLが自動起動し、AWS/GCPへのデプロイ時にはRDS/Cloud SQLが自動プロビジョニングされます。

トレードオフ:

Encore.tsのパフォーマンスは魅力的ですが、Rustランタイムへの依存はデバッグの難易度を上げます。Node.jsのイベントループとは別にRust側のイベントループが動作するため、パフォーマンス問題が発生した際に「Node.js側の問題かRustランタイム側の問題か」の切り分けが必要になります。また、対応クラウドはAWSとGCPの2つで、Azureはサポートされていません。

SST v3（Ion）：IaCからIfCへの架け橋

SST v3は、従来のAWS CDK + CloudFormationベースからPulumi + Terraformベースに完全移行したフレームワークです。純粋なIfCというよりも、IaCとIfCの中間に位置するハイブリッドツールと捉えるのが適切です。

// sst.config.ts: SST v3の設定例
export default $config({
  app(input) {
    return {
      name: "my-app",
      removal: input.stage === "production" ? "retain" : "remove",
      home: "aws",
    };
  },
  async run() {
    const bucket = new sst.aws.Bucket("Uploads");
    const api = new sst.aws.Function("Api", {
      handler: "src/api.handler",
      link: [bucket],
      url: true,
    });
    return { api: api.url };
  },
});

IaCエンジニアに馴染みやすい理由:

• sst.config.tsはTypeScriptで書かれたインフラ定義ファイルであり、CDKやPulumiの経験者には直感的
• Pulumiを内部で使うため、デプロイ結果はPulumiダッシュボードで追跡可能
• Terraformプロバイダーを通じてAWS以外のリソース（Cloudflare、Vercel、Stripeなど）も宣言可能

制約条件:

SST v3はAWSを前提としたフレームワークであり、GCPやAzureへのデプロイには対応していません。また、Pulumiの状態管理バックエンド（Pulumi CloudまたはS3セルフホスト）が必要です。NitricやEncoreのようにアプリケーションコードからインフラを「推論」するのではなく、インフラを明示的に「宣言」する点で、従来のIaCに近い操作感です。

Modal・Shuttle・Ampt：ドメイン特化型IfC

残りの3ツールは、特定のユースケースに特化したIfCプラットフォームです。

ツール	特化領域	言語	クラウド	特徴
Modal	GPU/MLワークロード	Python	AWS（内部）	サブ秒コールドスタート、scale-to-zero、$87M Series B調達
Shuttle	Rustバックエンド	Rust	AWS（内部）	#[shuttle_runtime::main]アノテーション、Axum/Actix対応
Ampt	Node.jsフルスタック	JavaScript/TS	AWS（内部）	Next.js/Remix/Astro対応、WebSocket対応

MLエンジニアへの補足: Modalは2026年4月にOpenAI Agents SDKの公式実行環境に統合されました。Pythonデコレータでコンテナ環境とGPUスペックを宣言するだけで、インフラ管理ゼロでモデル推論をデプロイできます。

# Modal: GPUワークロードの宣言例
import modal

app = modal.App("inference-service")
image = modal.Image.debian_slim().pip_install("torch", "transformers")

@app.function(gpu="A100", image=image, timeout=300)
def run_inference(prompt: str) -> str:
    from transformers import pipeline
    pipe = pipeline("text-generation", model="meta-llama/Llama-3-8B")
    return pipe(prompt, max_new_tokens=256)[0]["generated_text"]

ハマりポイント: Modal・Shuttle・Amptはいずれもプラットフォーム型であり、インフラが完全に抽象化されています。これは開発速度を高めますが、「VPC内のプライベートサブネットにデプロイしたい」「特定のセキュリティグループを適用したい」といった細かな制御が難しくなります。規制の厳しい環境では、NitricやSST v3のほうが適しています。

既存Terraformからの段階的移行パターンを設計する

なぜ「全面移行」は失敗するのか

IfC導入の最大の失敗パターンは、既存のTerraform資産を一度に捨てようとすることです。HeltonがIaCConf 2025で指摘したように、開発者は制御を手放すことに強い抵抗を感じます。これは技術的な問題ではなく、組織的・心理的な問題です。

以下の3つの移行パターンを、組織の成熟度に応じて選択してください。

パターン1: サイドカー導入（リスク: 低）

既存のTerraform管理インフラはそのまま維持し、新規マイクロサービスのみIfCで構築します。

実装例（Nitricカスタムプロバイダーで既存VPCを参照）:

Nitricのカスタムプロバイダーを使えば、既存TerraformのVPC IDやサブネットIDをパラメータとして渡し、新規サービスをそのネットワーク内にデプロイできます。

# nitric.yaml: 既存インフラとの接続設定
name: new-order-service
providers:
  aws:
    config:
      vpc-id: ${EXISTING_VPC_ID}
      subnet-ids:
        - ${PRIVATE_SUBNET_1}
        - ${PRIVATE_SUBNET_2}

この手法が適するケース: チームがIfCを試してみたいが、既存インフラへのリスクは取りたくない場合。新規サービスの構築時間を50〜80%削減できるとNitricのドキュメントは報告しています。

パターン2: レイヤー分離（リスク: 中）

インフラをベースレイヤー（VPC、IAM、データベース）とアプリケーションレイヤー（API、関数、ストレージ）に分離し、アプリケーションレイヤーのみIfCに移行します。

レイヤー	管理ツール	理由
ネットワーク（VPC、サブネット）	Terraform	セキュリティレビューが必要、変更頻度が低い
IAM（ロール、ポリシー）	Terraform	コンプライアンス要件、監査証跡が必要
データベース（RDS、DynamoDB）	Terraform	ライフサイクルがアプリより長い
API・関数・キュー	IfC（Nitric/Encore）	変更頻度が高い、開発者が直接触る
オブジェクトストレージ	IfC（Nitric/Encore）	アプリケーションロジックと密結合

なぜこの分離か: ベースレイヤーは変更頻度が低く、セキュリティ・コンプライアンスの審査が必要です。一方、アプリケーションレイヤーは開発者が頻繁に変更し、デプロイ速度が重要です。この「変更頻度」と「ガバナンス要件」の軸で分離することで、IfCの開発速度とIaCの制御性を両立できます。

パターン3: 段階的フル移行（リスク: 高）

SST v3を活用し、既存のCloudFormation/Terraformリソースを段階的にsst.config.tsに取り込みます。SST v3はPulumiとTerraformプロバイダーを内部で使用するため、既存のTerraformステートとの共存が比較的容易です。

この手法が適するケース: AWS単一クラウドで、チーム全体がTypeScriptに習熟しており、IaCの二重管理コストを完全に排除したい場合。ただし、SST v3はAWS専用であり、マルチクラウド要件がある場合はパターン1または2を選択してください。

制約: SST v3のPulumiステートとTerraformステートは別管理です。既存Terraformリソースを「インポート」するには、Pulumiのimport機能を使って1リソースずつ取り込む必要があります。数百リソースの大規模環境では、移行工数が非常に大きくなります。

AI時代にIfCが再評価される構造的理由を理解する

2コードベース問題とAIコード生成

Encoreの分析記事が指摘するように、IaCの最大の課題の1つは2コードベース問題（Two-Codebase Friction）です。アプリケーションコードとインフラコードを別リポジトリで管理する運用は、人間の開発では許容可能でしたが、AIコード生成の時代には深刻なボトルネックになります。

構造的な問題:

1. AIの生成速度とのギャップ: GitHub CopilotやClaude Codeなどのツールがアプリケーションコードを高速に生成しても、対応するTerraformの変更は人間が手動で書く必要がある
2. コンテキストの分断: AIエージェントがアプリケーションの要件（「このエンドポイントにはPostgreSQLが必要」）を理解していても、それをTerraformのHCLに変換するには別のコンテキストが必要
3. デプロイパイプラインの非対称性: アプリケーションのCI/CDは数分で完了するが、Terraformのplan/applyは変更セットのレビューと承認を挟むため数十分〜数時間かかる

IfCはこの問題を構造的に解消します。new SQLDatabase("orders") というアプリケーションコード内の宣言が、そのままインフラのプロビジョニング指示になるため、AIが生成したコードがそのままデプロイ可能なアーティファクトになります。

Heltonが提唱する次世代アプローチ

Allen HeltonはIaCConf 2025の講演で、IfCの次に来るものとしてAIドリブンのアダプティブインフラを提唱しました。現在の使用パターンをAIが分析し、コスト・レイテンシ・耐障害性のバランスをリアルタイムで最適化するアプローチです。

これは現時点ではビジョン段階ですが、その前提として「アプリケーションのインフラ要件がコードから読み取れる」状態、つまりIfCの基盤が必要です。IfCは「ゴール」ではなく、AIドリブンインフラへの**「中間ステップ」**として再評価されています。

IfC導入の意思決定フレームワーク

最後に、自チームでIfCを導入すべきかどうかを判断するためのフレームワークを示します。

判断基準	Nitric	Encore	SST v3	Modal	Shuttle	Ampt
マルチクラウド	AWS/GCP/Azure/K8s	AWS/GCP	AWSのみ	内部管理	内部管理	内部管理
既存IaCとの共存	Terraform/Pulumi連携	限定的	Pulumi統合	非対応	非対応	非対応
パフォーマンス	クラウドネイティブ依存	Rustランタイムで高速	Lambda依存	GPU最適化	Rust最適化	サーバーレス依存
カスタマイズ性	カスタムプロバイダー	限定的	CDK相当	デコレータ範囲	アノテーション範囲	SDK範囲
運用可視性	Pulumi/Terraformダッシュボード	組み込みトレーシング	Pulumiダッシュボード	Modalダッシュボード	Shuttleコンソール	Amptコンソール
学習コスト	中（SDK + プロバイダー理解）	中（独自API）	低（CDK経験者なら）	低（Pythonデコレータ）	低（Rustマクロ）	低（Express互換）

まとめと次のステップ

まとめ:

• IfCエコシステムは淘汰期を経て、Nitric・Encore・SST v3・Modal・Shuttle・Amptの6ツールに収束しました。Klothoはアーカイブ済み、Wingは未GAで停滞しています
• IaCConf 2025で「IfCは失敗した」と評価されたのは、カテゴリ全体としてIaCを置き換えるという当初の野心が実現しなかったためです。個別フレームワークは技術的に成熟を続けています
• 現実的なアプローチは**IaCとの共存（ハイブリッド）**であり、「ベースレイヤーはTerraform、アプリケーションレイヤーはIfC」というレイヤー分離が有効です
• AI時代には「2コードベース問題」の解消手段としてIfCの価値が再浮上しており、AIドリブンインフラへの中間ステップとして位置づけられています

次にやるべきこと:

1. 小さく始める: 新規マイクロサービス1つをNitricまたはEncoreで構築し、既存インフラへの影響なしでIfCを体験する
2. 自チームの制約を棚卸しする: マルチクラウド要件、コンプライアンス要件、チームの言語スキルを整理し、上記の意思決定フレームワークで候補を絞る
3. エスケープハッチを確認する: 選んだIfCツールが「合わなかった」場合に、生成されたIaC（Terraform/Pulumi）をそのまま引き継げるか確認する。Nitricはこの点で優位性があります

参考

• Infrastructure from Code (IfC) - 公式定義サイト
• Infrastructure From Code: What Went Wrong - The New Stack
• Infrastructure from Code: What Happened and What's Next - IaCConf 2025 (YouTube)
• Is Infrastructure as Code Dead? IaC vs Infrastructure from Code - Encore
• State of Infrastructure from Code 2024 - Nitric
• The Current State of Infrastructure From Code (Benchmark) - Allen Helton
• Encore.ts — 9x faster than Express.js (Benchmark)
• Nitric Providers Documentation
• SST v3 (Ion) 公式ブログ
• Encore vs SST - Which Backend Platform to Choose in 2026
• Modal - High-performance AI infrastructure
• Shuttle - Build Backends Fast (Rust)
• Ampt - The most efficient way to get things done in the cloud
• Gartner Hype Cycle for Platform Engineering, 2024
• GitHub - allenheltondev/infrastructure-from-code-benchmark

---

注意: この記事はAI（Claude Code）により自動生成されました。内容の正確性については複数の情報源で検証していますが、実際の利用時は公式ドキュメントもご確認ください。