本記事の概要
本記事ではスタートアップのIoTシステム開発で私がAWS Amplifyを選定した理由を記載しています。
- システム全体の設計
- プラットフォームの選定
- AWS Amplifyで困ったこと
- 振り返り
システム全体の設計
スタートアップとしてメインサービスとなるシステム開発が決まり、まず初めにシステムアーキテクチャの検討が必要となります。
アーキテクチャの選定はプロジェクトの成否を直結させます。特に1人目のソフトウェアエンジニア兼PMという多忙なポジションでは、バックエンドやフロントエンドも含めた開発において「どこに自分のリソース（時間）を集中させるか」が大きな課題でした。
今回のプロダクトはハードウェア（HW）とソフトウェア（SW）が連動するIoTシステムです。全体設計を行うにあたり、私はシステムを以下の3つのレイヤーに分けて考えました。
- エッジデバイス（HW）：データを収集・送信する物理デバイス。
- データ集約・通信：デバイスからの通信を受け付け、セキュアに処理するバックエンド。
- アプリケーション：ユーザーがデータを閲覧・操作するためのUI（Next.jsなど）。
この設計において最も重視したのは、「検証フェーズ（MVP）において、どこに最も運用コストを割くか」を見極めることでした。
スタートアップの初期段階では、インフラのパッチ当てや複雑なサーバー管理にリソースを割くべきではないと判断しました。そもそもこれまでの私のスキルとして難しい部分でもありました。
すべてのレイヤーにおいて「マネージドサービスを最大活用し、自分たちで運用するサーバーをゼロにする（サーバーレス）」という思想でアーキテクチャを決定しました。
プラットフォームの選定
上記のアプリケーションおよびデータ集約レイヤーを支えるプラットフォームとして、私はAWS Amplifyを軸に据える意思決定をしました。
選定した理由は以下の3点です。
インフラ管理（運用保守）負荷の低減
サーバーのプロビジョニングやスケーリングの設計をAWS側へ任せて、コアシステム（機能開発）に集中できる環境を構築することを目的としました。
CI/CDパイプラインの構築
AWS AmplifyではGitHubのリポジトリと連携するだけで、フロントエンドからバックエンドまでのビルド・デプロイ環境が自動生成されます。これにより、開発初期に環境構築で時間がかかってしまうことの回避を目指します。
属人化リスクの低い仕組みの担保
私が頑張ってインフラ知識を習得してインフラをくみ上げたところで、チームが拡大した際に「インフラ専任」が必要になり、スイッチングコストが発生します。
Amplifyを軸にすることで、インフラがブラックボックス化せず、後続のメンバーへの引き継ぎコストを最小化できると考えました。
AWS Amplifyで困ったこと
Amplifyはすべてのプロジェクトにおける万能の解決策ではありません。自動生成されるがゆえの「ブラックボックス化」という弱点や制約も存在します。
実際、私が開発を進める中で、「画面上の設定選択肢には明示的に出てこないにもかかわらず、裏側の初期設定と連動して『API Key』が自動発行・有効化されてしまう」という挙動に直面しました。
本番環境に耐えうる厳格なセキュリティ要件を満たすために、この意図せず連動して設定されてしまう項目を特定し、CloudFormation等の依存関係を紐解いて解消する作業には、一定の試行錯誤と時間を要しました。
利便性の裏にあるこうした「ブラックボックスな自動設定」を正確にコントロールするスキルが、運用フェーズでは求められます。
振り返り
成果
初期段階では、AWS Amplify自体の仕様理解や様々なトラブルシューティングに一定の時間を投資する必要がありました。
※あるあるですが誤って環境を削除してしまったこともありました。
しかし、開発が一度軌道に乗ってからは、この投資がリターンを生み出しました。インフラの運用保守やCI/CDの監視に割く時間がほぼ「ゼロ」になったことで、私自身のリソースに余裕が生まれました。
浮いた時間を使って、私はIoT開発において最もカオスになりがちな「ハードウェア（HW）課題のディスパッチ（交通整理）」や、「社外関係者とのコミュニケーション」に全力を注ぐことができました。もし初期に自前で複雑なインフラを構築していたら、私は日々のインフラの火消しに追われ、プロジェクトの本質的な課題に向き合う時間はなかったと思います。
教訓
- 技術選定は現在のリソースと求められるビジネスに合わせて選定する
- 初期コストの投資により後続工程に大きな影響を与える
- ローコード・ノーコード開発でも基礎を理解することが重要