デプロイ設計を先にやっておいて本当に良かったこと｜AIタロットサイト開発で感じた重要性
公開日：2026年6月25日 11時00分
機能開発より先に考えたこと
AIタロットサイトを開発すると決めたとき、最初に考えたのは画面やAI機能ではありませんでした。
まず設計したのは、
デプロイの仕組み
です。
新しいサービスを作ると、
毎日のように修正や機能追加が発生します。
そのたびに手作業でサーバーへログインし、
Dockerイメージを作成し、
コンテナを再起動していたら、とても開発に集中できません。
だからこそ、開発初期の段階でCI/CD（継続的インテグレーション・継続的デリバリー）の仕組みを整えることにしました。
結果として、この判断は大正解だったと感じています。
GitへPushするだけで本番反映
現在のAIタロットサイトでは、
GitへPushするだけで、本番環境まで自動でデプロイされます。
全体の流れは次のようになっています。
GitLab
↓
Webhook
↓
AWS Lambda
↓
S3（Source）
↓
CodeBuild（Dockerイメージ作成）
↓
S3（Artifact）
↓
CodeBuild（ECRへPush）
↓
Amazon ECR
↓
Amazon ECS（ローリングアップデート）
一見すると少し複雑に見えるかもしれません。
しかし、それぞれの役割を分けたことで、柔軟性の高いデプロイ環境を作ることができました。
Webhookを採用して良かった理由
今回の構成で特に良かったと思っているのが、
Webhookを起点にしたこと
です。
GitLabではPushイベントをWebhookとして送信できます。
そのWebhookをAWS Lambdaで受け取り、
以降の処理を開始しています。
つまり、
GitLab専用の仕組みではありません。
Webhookを送信できるGitサービスであれば、
ほぼ同じ構成を利用できます。
例えば、
- GitLab
- Backlog Git
- GitHub
- Bitbucket
などでも考え方は変わりません。
もし将来リポジトリ管理サービスを変更したとしても、
Webhookの送信先を変更するだけで対応できます。
特定のサービスに依存しない設計にできたことは、大きなメリットでした。
Lambdaを入口にした理由
Webhookを直接CodeBuildへ送る方法もあります。
しかし今回はLambdaを挟みました。
理由はシンプルです。
Lambdaを入口にしておけば、
後から処理を自由に追加できるからです。
例えば、
- ブランチ判定
- 開発環境・本番環境の振り分け
- Slack通知
- デプロイログ保存
なども簡単に追加できます。
Lambdaは「デプロイの受付窓口」のような役割になっています。
将来の拡張性を考えると、この構成にして良かったと感じています。
S3を経由するメリット
ソースコードは一度S3へ保存しています。
これにも理由があります。
CodeBuildはS3を入力ソースとして扱えるため、
Gitサービスとの結合を弱くできます。
さらに、
ソースコードがS3へ保存されたこと自体をイベントとして利用できます。
AWSではS3イベントが非常に使いやすいため、
サービス同士を自然につなげられるようになりました。
ビルド処理を分離した理由
Dockerイメージを作る処理と、
ECRへPushする処理は別のCodeBuildにしています。
一つにまとめることもできます。
しかし、
役割を分離したことで、
どこで失敗したのかが分かりやすくなりました。
例えば、
Dockerビルドだけ失敗したのか。
ECRへのPushだけ失敗したのか。
ログを見るだけですぐ判断できます。
運用してみると、この違いは意外と大きいものでした。
ローリングアップデートの安心感
一番恩恵を感じているのは、
ECSのローリングアップデートです。
以前のように、
サーバーを止めて更新する必要はありません。
新しいコンテナが起動し、
正常に動作していることを確認してから、
古いコンテナが停止します。
つまり、
利用者がサービスを使っている最中でも、
サイトを停止することなく更新できます。
これは24時間利用できるAIタロットサイトにとって、とても重要な仕組みです。
問題が起きても戻しやすい
ローリングアップデートには、
もう一つ大きなメリットがあります。
それは、
元のバージョンへ戻しやすいこと
です。
もし更新後に問題が見つかった場合でも、
前回のDockerイメージを指定すれば、
以前の状態へ戻せます。
手作業でファイルをコピーし直したり、
サーバーへログインしたりする必要はありません。
「すぐ戻せる」
という安心感は、
新しい機能を追加するときの心理的な負担を大きく減らしてくれました。
開発スピードが変わった
このデプロイ環境を作ったことで、
開発の流れはとてもシンプルになりました。
コードを書く
↓
GitへPush
↓
数分後には本番反映
これだけです。
デプロイ作業を意識しなくてよくなったことで、
機能開発そのものに集中できるようになりました。
小さな改善も気軽にリリースできるため、
結果としてサービス全体の改善スピードも上がっています。
最初に設計して正解だった
正直に言うと、
開発初期は
「まず機能を作った方が早いのでは？」
とも思いました。
しかし今振り返ると、
最初にCI/CDを整備したからこそ、
ここまでスムーズに開発を続けられたのだと思います。
サービスは公開して終わりではありません。
公開してからの改善の方が圧倒的に多くなります。
だからこそ、
更新しやすい仕組みを先に作っておくことが重要でした。
おわりに
AIタロットサイトでは、
GitへPushするだけで、
AWS上の本番環境まで自動でデプロイされる仕組みを構築しました。
Webhookを起点としたことでGitサービスに依存しない柔軟な構成になり、
ECSのローリングアップデートによってサービスを止めることなく更新できるようになりました。
派手な機能ではありません。
しかし、
こうした土台があるからこそ、
新しいAI機能やサービス改善にも安心して取り組めています。
開発を続けるほど、
「デプロイ設計を最初にやっておいて本当に良かった」
と実感しています。