ミリ知らでWebアプリをAI × IaCで公開してみた

はじめに

本記事は、AWSをほとんど触ったことがなかった私が、
WebアプリをAWS上で公開するまでにやったことを振り返った記録です。

いわゆる「最新・最強のアーキテクチャ紹介」でもなければ、
「この構成がベストプラクティスです」という話でもありません。

AWS未経験、Webアプリ開発歴もまだ浅い状態から、

• どう学習を進めたのか
• どうやって設計に落とし込んだのか

そのプロセスを中心に書いています。

AIエージェントも活用していますが、
「AIがすごいから一瞬でできた」という話ではありません。
AIをどう使えば前に進めるか、その一例になればと思います。

背景

これまでの自身の主な開発分野は組み込み系で、
Webアプリ開発の経験は浅く、正真正銘「Webアプリ1年生」です。
AWSについても、「S3？」「ECS？」「何の略？」というレベルで、
ほぼ「ミリ知ら」状態でした。

そんな中、社内WGで「Webアプリを外部に公開する」こととなり、

「Web開発において避けては通れないが、ミリ知ら…。
　しかし、リスクなし、全てを自分で試せて、適度なプレッシャーもある、
　こんな機会はそうそうない…！」

と葛藤の末、飛びつきました。

学習と設計編

学習方針を決める

最初に考えたのは、「どうやって学ぶか」です。

AWSのようなマネージドサービスは情報の鮮度が高いです。
そのため、一次情報である公式ドキュメントは網羅的で正確ですが、とにかく量が膨大...
最初からすべてを理解しようとすると、確実に詰みます。

そこで決めた方針はシンプルで、

• マネージドサービス中心で理解する
• 全部は理解しない
• 必要になったところから深掘る

というものでした。

「今このアプリを公開するために必要なこと」にフォーカスし、
余計な枝葉は意識的に切るようにしました。

NotebookLMを使ったDeep Research

学習の軸として使ったのが NotebookLM です。
ちょうど Google One の年末セールもあり、
試してみるにはいいタイミングでした。

NotebookLMに公式ドキュメントを読み込ませることで、

• 各サービスの概要から具体的な利用ケースの解説
• サービス毎の役割と関連性の説明
• 「最新の推奨構成だとどうなる？」といった仮定の問いへの回答

が比較的高い精度で返してくれるようになっていると感じました。

マネージドサービスは更新も早いため、
二次情報よりも公式リファレンスを軸にできるのは大きなメリットでした。

最初の壁打ち

最初に投げた問いは、とても雑でした。

SPA + FastAPI のWebアプリをAWSで公開するときに、必要なマネージドサービスは？

返ってきた回答には、知らない単語が大量に含まれており、
「S3、CloudFront、ALB、ECS、VPC...」
名前は聞いたことがあるものもありましたが、ほぼ初見でした。

ここで意識していたのは、役割を理解することでした。

• これは何を解決するためのサービスなのか
• どこに責務があるのか
• 他のサービスとどういう関係にあるのか

ひたすらその観点で質問を投げ続けました。

壁打ちループで理解を積み上げる

一つの回答をもらうと、必ず次の疑問が出てきます。

• なぜALBが必要なのか？
• CloudFrontとALBの違いは？
• ECSはEC2と何が違うのか？
• VPCの中で何が起きているのか？

その疑問をまたNotebookLMに投げる。
すると、さらに新しい概念が出てくる。

学習するうえで当たり前の光景ですが、
この「質問する → 理解する → 新しい疑問が生まれる」のループを
AIエージェントを活用することで、かなりの速度で回すことが出来ました。

そして、この段階では、まだAWSコンソールもほとんど触っていません。
また、AIの回答が常に正しいとは限らない、という前提は一旦横に置き、
「少しくらい間違っていてもいい」と割り切り、
あくまで「自身の理解を整理すること」に集中していました。

アーキテクチャ設計に着手する

ある程度サービスの役割が見えてきたところで、
手を動かす前にアーキテクチャを描き始めました。

図にしてみると、どうしても「わかっていないこと」が浮き彫りになります。

• ネットワークの境界はどうなる？
• VPC(プライベート)内のECSからECRにどうやってアクセスする？
• CloudFrontとALBを介しての認証フローは？

そうして、またNotebookLMに戻ることになります。

設計図を前提に、

• ここでの通信ルートはどうなる？
• この構成における認証認可のシーケンスは？
• セキュリティやコストの面で問題はあるか？

といった壁打ちを行い、理解を深めたうえで設計へ反映していきます。

この往復は、一見大変にも思えますが、
自分の頭の中の地図がどんどん区画整理されていくことに快感を覚え始めます。

最終的に落ち着いたアーキテクチャ

何度か往復しつつ、有識者にも意見を伺った
最終的に落ち着いたアーキテクチャがこちらです。

初期の構成図から、RDSへの接続ルートや認証のシーケンスなど、
自身の中でも解像度が上がり、綺麗に整理できました。
（細かいエンドポイント等はテキストベースの設計に落としています）

今見ると、正直かなり「ありふれた構成」です。

ただ、このとき感じたのは、
「あ、ありふれて見えるレベルまで理解できるようになったんだ」ということでした。

数日前までは、SNSで流れてくるアーキテクチャ図も、
白黒(よくわからない)アイコンに見えていましたが、まさに色付き始めた瞬間でした。

設計を言語化することの重要性

構成図だけでなく、その設計をテキストでも言語化しました。

• なぜこのサービスを使うのか
• どこまでを責務とするのか
• 何を前提としているのか

これを先に詰めておいたことが、後工程で非常に効いてきます。

構築時のミスを減らせるだけでなく、
AIにレビューやチェックをさせるときの 「判断軸」としても機能しました。

構築編

構築方針

構築は手作業で行うと、
「再現性がない」「AIとの相性が悪い」ので IaC が前提です。

CDKなども触ってみたい気持ちもありましたが、
汎用性と情報量の多さを考えてTerraformにしました。

基本方針は、以下で進めました。

• AIエージェントにコードを書かせる
• 自分はレビューと実行を行う

全体の基盤構築の流れ

アーキテクチャ設計をインプットに、
全体の基盤構築の流れを先に決めました。

• foundation (VPC/RDS/EC2(Bastion))
• dns-bootstrap (ドメイン作成)
• application (CloudFront/S3/ALB/ECS)

という大きな流れです。
（実は一部のfoundationの座組はすでに組まれているものもありました。）

なお、細かい設定やサービスごとの説明は、本記事では割愛します。

構築は爆速で終わった

構築途中で、コンテキストが肥大し、誤った構成で作ってしまうこともありました。
それでも以下のおかげで、その都度修正を行えて、爆速で構築できました。

• 設計という指針があった
• 設計をAIが理解できる形で残していた

誤ってタスクの途中でプロセスを破棄してしまったときも、
設計を渡して「これを目指していて、今はこの状態」と言えば、スムーズに再開できました。
また、Issueを「短期記憶」代わりに使用していたことも効果があったと思います。

設計を軸にしたAI活用

設計は、構築後も活躍しました。

• AWS各サービスの設定状態チェック
• Terraformのoutputを元にしたデプロイスクリプト生成
• ECSのタスクイベントやログ解析

これらをAIに任せる際も、「正しい状態」は設計で定義されています。
AIだけではどうしても場当たり的な対応となり、手戻りが多く発生していたと思います。
設計、IaC、AIが揃って初めて、このスピード感とその後の保守への効果が出ると感じました。

いわゆる、ノリで作る「バイブコーティング」だけでは手が届かない、
スペック駆動開発 の効果を実感できました。

おわりに

ミリ知らでも公開できた

AWSを触ったことがなかった自分でも、
Webアプリを公開するところまで辿り着けました。

振り返ると、これまでのアプローチと何ら変わりはなく、

• 解らなければ調べる
• トライアンドエラー

を繰り返しているだけですが、AIによってそのサイクルが爆速になったのだと実感しました。

AI時代の学び方について

「これが知りたい」という明確な目的がある学習サイクルにおいて、
AIエージェントは非常に強力だと実感しました。

なお、出てきたものの良し悪しを判断するのはやはり人間なので、
判断できなければ、判断できるようにまた学ぶ必要があります。

そして、その学習自体にも、AIは活用していけるのだなと。
だからこそ、思考を整理し、言語化しておくことが、
より重要になったと感じています。