プロダクト開発に注力するためのAmplify導入 - ispec inc.

参考になった

会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。

無料登録してアーキテクチャを見る

レビュー投稿日の情報になります

株式会社ispec / 堀雅晴

テックリード / テックリード / 従業員規模: 11名〜50名 / エンジニア組織: 11名〜50名

最終更新日2025/12/09投稿日2025/12/09

ツールの利用規模	ツールの利用開始時期	事業形態
10名以下	2020年4月	B to B

ツールの利用規模	10名以下
ツールの利用開始時期	2020年4月
事業形態	B to B

アーキテクチャ

会員限定コンテンツ無料登録してアーキテクチャを見る

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

AWS Amplify導入以前の2019年頃、弊社ではSPAをNginxで配信、コンテナ化してAmazon ECSへデプロイする構成を採用していました。この構成は柔軟性が高い一方で、以下のような課題を抱えていました。

インフラ構築の工数負荷
開発メンバーが少ない中で、構築そのものもそうですが、Basic認証やHTTPS化といった基本的なセキュリティ設定にも相応の時間とインフラ知識を要し、機能開発や検証サイクルを圧迫していた
CI/CDパイプラインの自前構築
GitHub ActionsやCircleCIなどを用いたビルド・デプロイの自動化を各プロジェクトで個別に設計・実装する必要があった
職種間の認知負荷
インフラエンジニアがフロントエンドのビルドプロセスやフレームワーク固有の設定を理解する必要があり、メンバー間の連携コストが増大していた
インフラコストの肥大化
ECSのランニングコストが、小規模なフロントエンドアプリケーションに対して過剰な負担となっていた

どのような状態を目指していたか

弊社が目指していたのは、フロントエンドエンジニアに限らず、開発メンバーであれば誰でもデプロイや環境設定を完結できる状態でした。具体的には以下の要件を満たすことを理想としていました。

デプロイの簡易化
インフラの専門知識がなくても、GitHubブランチへのプッシュだけでデプロイが完了する仕組み
開発リソースの最適配分
インフラ構築ではなく、機能開発や仮説検証に時間を割ける環境
マルチ環境の即時構築
Development / Staging / Production環境をGitブランチベースで迅速に立ち上げられること
プルリクエストごとのプレビュー環境
コードレビュー時に実際の画面で動作確認ができる環境を自動生成し、レビューの品質と効率を向上させること
コスト最適化
ECS環境よりも低コストで運用できること

比較検討したサービス

Firebase Hosting
Heroku
Netlify

選定理由

当時の弊社は受託でのプロダクト開発が中心であり、クライアントのインフラ環境としてAWSが使用されることが大半を占めていました。そのため、フロントエンドのホスティングもAWSエコシステム内で完結させることで、権限管理の統一、請求の一元化、他のAWSサービスとの連携の容易さといったメリットを享受できる点が、Amplify採用の決め手となりました。

導入の成果

改善したかった課題はどれくらい解決されたか

導入前に挙げていた課題は、すべてクリアすることができました。

どのような成果が得られたか

開発への注力
フロントエンドのインフラ構築から解放され、機能開発やプロダクトに関する議論に時間を投下できるようになった
レビュー品質の向上
プルリクエストごとにプレビュー環境が自動生成されるため、コードレビュー時に実際の画面を確認しながらレビューが可能になり、手戻りの削減とコミュニケーションコストの低減を実現

導入に向けた社内への説明

上長・チームへの説明

導入推進時に受けたフィードバック

社内にAmplify導入を提案した際、以下のような懸念が挙がりました。

抽象化による制御性の低下
デプロイは簡単になる一方で、細かい設定や挙動がマネージドサービスとして隠蔽されており、運用フェーズで対応できない事象が発生するのではないか
スケーラビリティへの不安
プロダクトがスケールした際に、Amplifyの制約がボトルネックとなる可能性はないか

導入決定に至った経緯

これらの懸念に対しては、まず開発環境や小さめのプロジェクトで使用してみて、前述の課題が解消できそうかを確認しました。その上で、メリットとデメリットを整理し、メリットがデメリットを十分に上回ることを説明しました。

また、弊社には「課題やリスクをきちんと把握した上で、新しい技術やサービスの採用に対しては積極的にチャレンジする」というエンジニアリングカルチャーがあり、この風土も導入決定を後押しする要因となりました。

活用方法

よく使う機能

Hosting
Next.js (App Router, Pages Router) をはじめ、React Router (SPA) や、Nuxt.js (SPA) など様々なフロントエンド、フルスタックフレームワークをデプロイしています
ビルド通知
ビルドの完了・失敗をSlackへ通知し、デプロイ状況をチーム全体でリアルタイムに把握できるようにしています
ファイアウォール (AWS WAF統合)
Amplifyコンソールから数クリックでAWS WAFを設定でき、海外からの不審なアクセスや悪意あるリクエストのブロックなど、基本的なセキュリティ対策を容易に実施できます
プレビュー
プルリクエストごとにプレビュー環境が自動構築されURLにアクセスするだけで簡単に実際の画面を確認することができます

※Amplify Gen2などの機能は現時点では未使用

ツールの良い点

運用負荷の軽減
フロントエンドのインフラ構築が大幅に簡素化され、エンジニアが本来注力すべき機能開発やアーキテクチャ設計に時間を割けるようになる
CI/CD設定の容易さ
Gitリポジトリとの連携設定のみでCI/CDパイプラインが自動構築され、amplify.yamlによる柔軟なビルド設定も可能
必要十分な機能セット
フロントエンドアプリケーションのホスティングに求められる機能 (カスタムドメイン、HTTPS、リダイレクト設定、環境変数管理など) が一通り揃っている
コスト効率
特に小〜中規模のプロダクトにおいては、ECS構成と比較して大幅なコスト削減が可能

ツールの課題点

細かい制御に限界がある
マネージドサービスとして抽象化されている部分が多く、運用を続ける中で「Amplifyではできない設定」に遭遇する可能性がある
トラブルシューティングの困難さ
内部の挙動が隠蔽されているため、問題発生時の原因特定に時間を要することがある。実際に、ファイアウォール関連で調査、解消に時間を要した経験があります
(詳細：Amplifyでハマった8KBルール：WAFが静かに拒否する大きなリクエスト)
Amplifyコンソール上でのWAF設定の限界
高度なWAFルールを設定する場合はAWS WAFコンソールでの直接操作が必要になり、一度WAF側で変更を加えるとAmplifyコンソールからの設定変更が不可になる (ファイアウォール機能は完全な抽象化ではなく、AWS WAFのウェブACLが作成・紐付けされる形式)
フレームワーク最新バージョンへの追従の遅れ
Next.jsなどの新バージョン対応がVercelと比較して遅れる傾向がある
サーバーサイド処理のタイムアウト制限
Next.js等のサーバーサイド処理に30秒のタイムアウト制限があり、LLMのストリーミング処理やリトライ処理など、長時間を要するリクエストでタイムアウトが発生するケースがある

ツールを検討されている方へ

インフラをAWSエコシステム内で完結させたいケースや、小〜中規模なプロダクトを安価に素早くデプロイしたいケースでは、Amplifyは有力な選択肢となります。一方で、フレームワークの最新機能をいち早く活用したい場合や、サーバーサイド処理に複雑な要件がある場合は、事前に制約事項を確認することをお勧めします。

今後の展望

現在の弊社では、前述したAmplifyの課題を踏まえ、フロントエンドのホスティング環境をプロダクトの特性に応じて使い分けるアプローチを採用しています。

特にNext.jsでApp RouterやServer Components、Server Actionsを活用するプロジェクトが増えてきており、これらの機能との親和性が高いVercelを利用するケースが増えてきました。また、弊社は現在、医療機関向けのプロダクト開発に事業をフォーカスしており、厳格なセキュリティ要件を満たす必要がある場合は、細かいネットワーク制御やセキュリティ設定が可能なECS Fargateでのセルフホスティングを選択することも増えています。

具体的には、プロトタイプ開発や仮説検証フェーズではVercelを活用して高速にイテレーションを回し、本番運用フェーズや高いセキュリティ要件が求められるプロダクトではECS Fargateでのセルフホスティングへ移行する、という組み合わせが弊社の現在の標準的な構成となりつつあります。

Amplify自体は導入当時の課題を解決してくれた優れたサービスであり、今後も適材適所で活用していく方針です。

株式会社ispec / 堀雅晴

テックリード / テックリード / 従業員規模: 11名〜50名 / エンジニア組織: 11名〜50名