そのインフラ、次世代 IaC Pulumi を使って TypeScript で書いてみませんか？
TL;DR
- あなたがクラウドインフラに馴染みがないからといって、クラウドプロバイダのコンソール画面からボタンぽちぽちして本番インフラは作らないで。複数環境を用意する場合、管理・運用コストが大変なことになります。
- インフラ構成の管理方法として、CloudFormation、Terraform や CDK 等の IaC が使われますが、独自言語を学ぶ必要やベンダロックの問題があるため、非インフラエンジニアにとってハードルが高いという問題があります。
- 次世代 IaC Pulumi を使えば、慣れた TypeScript でインフラ構成を「ソースコード」として表現できます。クライアントもサーバーも TypeScript なら知識を共有できるので認知負荷が下がり、ソースコードは再利用可能になります。
- サーバレスサービスを利用したアーキテクチャを採用する場合、ローカル開発環境のために Docker イメージ等でその環境を完全にシミュレートすることは困難になるため、あえてコンテナ技術を採用せず開発フェーズから、Pulumi コードを積極的に整備することで本番と同様の環境を開発環境として利用します。
- typescript + pulumi を学ぶための本を書きました
コンソール画面からボタンぽちぽちしてインフラを作らないで 😭
AWS (Amazon Web Service) や GCP (Google Cloud Platform) 、Azure をはじめとする、クラウドインフラストラクチャの登場により、各クラウドプロバイダーのコンソールから GUI を利用して、仮想マシンや DB などのインフラリソースを作成・削除ができるような素晴らしい時代になりました。
一方、そのような操作を手動で簡易に設定できるようになってしまったがために、人為的ミス・属人化・再現性の低さ等の問題が 2000 年代中盤頃顕在化し始め、そのような問題を解決するための管理ツールとして、Terraform（2010年）や CloudFormation (2011年) のような IaC (Infrastructure as Code)と呼ばれる技術が登場しました。
IaC のおかげで、複数のクラウド環境があっても、コマンド一発で構成を再現できるようになりました。
この IaC によって人為的ミス・属人化・再現性の低さのミスは完全に無くなったでしょうか？
Firefly の 2025 年の調査では、何百人もの専門家に IaC の活用についてアンケートをとったところ約 89% が IaC を利用していることが報告されています。
一方で、全てのインフラに IaC が使われているか？のカバレッジの割合は、たったの 6% にとどまっています。
しかしながら、ここから著者の私見にはなりますが、この調査は大企業をはじめとする、クラウドインフラに精通した IT の業界リーダーたちが多く占めているバイアスのかかった調査であって、個人・零細や中小企業でクラウドにシフトしようとしている人たちにとっては、まだまだ普及率が低いと感じられます。また、IaC が導入できている彼らでさえ、IaC カバレッジは 6% にとどまっている背景があります。
そして、その普及を妨げているのは皮肉にも各クラウドプロバイダのコンソールの直感的使いやすさや Vercel や Supabase などの PaaS の登場ではないかと思います。
IaC とは？ その採用ハードル
IaC (Infrastructure as Code) は、先述したようにインフラ構成をコードとして記述し、自動化・管理する手法です。
具体的な AWS クラウドインフラで利用可能な IaC ツールとしては、次の4つが知られています。
| ツール名 | 特徴・強み | 記述方式 | サポート範囲 | 主な用途・ユースケース |
|---|---|---|---|---|
| Terraform （OpenTofu） | マルチクラウド対応。宣言的。拡張性・移植性高い。デファクトスタンダード。 | HCL（独自言語） | AWS, Azure, GCP, 他多数 | ベンダーロックイン回避、統合管理 |
| AWS CloudFormation | AWS公式。AWSサービスとの親和性・機能網羅性高い | YAML/JSON | AWSのみ | AWS専用の大規模インフラ管理 |
| AWS CDK | プログラミング言語で記述可能。抽象化レベル高い | TypeScript・Python,・Java,・C#・Go など | AWS中心（他クラウドも一部対応） | 開発者向け、コードで柔軟なインフラ定義 |
| Pulumi | プログラミング言語で記述可能。マルチクラウド対応 | TypeScript, Python, Go, C#, Java | AWS, Azure, GCP, 他多数 | ベンダーロックイン回避・コードベースでの高度な自動化・統合管理 |
より詳しい、IaC 選定の比較検討については下記書籍に譲ります。（少々情報が古い点には注意が必要です。）
Firefly の 2025 年の調査で 現在の IaC 使用率の約6割を占めるのが Terraform であり、IaC のデファクトスタンダードであることが確認できます。
Firefly の 2025 年の調査より画像を引用
同調査で IaC 導入における主なハードルについては、次のような理由が挙げられています。
- 知識豊富なエンジニアリングリソースの不足
- ツールの断片化、複雑さ、および/またはコスト
- IaC カバレッジの欠如（既存およびレガシー リソースの場合）
この結果について理由をより具体的に分析すると、特に個人・零細や中小企業では、インフラ専任として「知識豊富なエンジニア」を確保するのは難しいですし、CloudFormation や HCL のような独自記法を採用しなければならないことや、CloudFormation (CDK)が AWS へのベンダーロックインになってしまうことが、「ツールの断片化、複雑さ、および/またはコスト」に該当すると考えられます。
小規模開発におけるエンジニアは IaC を学ぶ余裕がない
以上の分析から、個人・零細や中小企業 などの小規模開発において IaC を導入できないのは、下記のようなことが要因であると思われます。
- クラウドプロバイダーの管理コンソールの GUI が優れていたり、PaaS のユーザー体験が良いことによる IaC まで至らない現状維持バイアス
- CloudFormation や HCL の独自記法の習得コスト
- 小規模開発におけるエンジニアは、顧客折衝やマーケティング、経理についても考えなければならず、そもそもエンジニアリングに集中できていない
- インフラに特化した優秀なエンジニアを雇うことが難しい
- 請負開発の場合、こちらからクラウドプロバイダを選択できないことがあるため、特定のクラウドベンダーに対して、多くのコストを割けない
このような要因を考慮しつつ、IaC を導入するにはどうすれば良いでしょうか？
その方法は、「認知負荷・学習負荷」をできる限り下げ、マルチクラウドが可能な潰しの効く IaC を採用することです。それが、Pulumi です。
Pulumi を選ぶ理由
Pulumi は Firefly の 2025 年の調査では、現在の採用率は約 10% 程度であるものの、Docker や Unity、NVIDIA などの有名企業でも採用されている 次世代 IaC です。
その唯一の特徴は次の4点を兼ね備えていることです。
- TypeScript・Python,・Java,・C#・Go などの汎用言語でインフラを記述できること
- 複数のクラウドプロバイダーを利用なこと
- Apache-2.0 licenseであるため、Terraform と比較して法務リスクが低いこと
- Slack や Discord などのチャットツールや GitHub や GitLab のコードホスティングプラットフォームなどのプロバイダーも対応し、IaC を超えたプラットフォームソースコードの実現
あなたが、TypeScript ネイティブなエンジニアの場合、インフラをある種のフレームワークを学ぶような感覚で学習し、ソースコードとして読むことができるため他の IaC を採用する場合に比べ「認知負荷・学習負荷」を下げることができます。（AWS Amplify もそのような気質がありますが、インフラとアプリケーションコードが密結合になりやすく、インフラの拡張性も、CloudFormation のエコシステムに縛られてしまうという制約があります。）
サーバーレス技術の採用を前提とし、Dockerfile や compose.yaml の代わりに Pulumi を書く提案
現代の Web アプリ開発において、ローカル環境での、バックエンド（API サーバーや DB）開発は Docker コンテナ上に構築されることが主流になっていると思いますが、アプリ開発エンジニアにとって Dockerfile や compose.yaml を整備する作業も負担になっているのではないでしょうか？ （Shell や YAML 本当は書きたくないと思ってません？）
また、コンピューティング環境が本番とは異なるため、非機能要件については、クラウド上のステージングや QA 環境で結局検証しなければならないなどの問題も考えられます。
このような問題を回避するための発想の転換として、金銭的コストが低く・インフラの管理の責任レイヤーの少ない AWS Lambda 等のサーバーレス技術を採用する前提とすることで、Dockerfile や compose.yaml の整備にかけていた時間を Pulumi を書くことに変え、ローカル開発環境をクラウド環境に移行することはできないでしょうか？
クライアント・サーバー・インフラを全て TypeScript で開発
Web アプリ開発においては、クライアントの開発が TypeScript 一強であることを考慮して、TypeScript で. クライアント・サーバー・インフラを書くという提案をしたいと思います。全てのレイヤーが TypeScript で完結するという新しい体験です。
これは、AWS CDK ですでに実現できていましたが、CDK は AWS へのベンダーロックインの問題が残っていました。Pulumi ではそのような心配はありません。（そのようなユーザーについても、Pulumi は CDK 互換の記述が可能な機能を提供しています。）
また、前述のサーバーレス技術の採用を併せることで、レイヤー間の疎結合性やインフラの自由度を担保しつつ、フルスタックフレームワーク的な力強さをもつようになるため、新しい開発体験が得られるのではないかと思います。
じゃあどうやって学べばいいんだよ！ つ 本を書きました
というわけで、本記事コンテストで扱う量ではなくなってしまったので TypeScript で Pulumi を学ぶための本を作成しました。
本書では、比較的新しい AWS サーバーレスサービスを利用した構成を扱っていますので、Pulumi に興味がなくとも読んでいただけると嬉しいです。
ソースコードについても GitHub リポジトリ上で公開しています。
また、Cognito など実際の開発で、重要となるインフラのようなトピックが執筆途中の章もあるため、ご支援を頂けると励みになります。
Discussion