はじめに
生成AIを使った個人アプリを開発していると、どうしても気になるのが「運用コスト」です。
作ること自体は楽しくても、継続できなければ意味がありません。
特に画像生成や配布が関わるサービスでは、ストレージ費用・転送量・サーバ維持費などが現実的な課題になります。
そこで今回は、自分のAI作品サービスの中でも画像生成＋配布を担当している
「Marukuma Drop」側の構成について、できるだけ低コストで続けられる設計を整理してみました。
まだ進行中のプロジェクトですが、現時点での設計メモとして残しておきます。
※本記事で触れている Marukuma Drop は、現在個人開発中のAI作品サービスの名称です。
ポエム・画像・スタンプなどをAI生成し、
静的配信ベースで低コスト運用することをテーマに設計しています。
開発途中のため、構成は今後変更される可能性があります。
現在の構成（ざっくり）
インフラ（Drop / 画像配布系）
Drop側は「生成した作品を安全に配布する」ことが役割なので、
常時サーバを持たずに回せる構成を意識しています。
-
AWS Lambda
→ AI画像生成・圧縮・分割・ZIP作成などの処理を担当。必要なときだけ実行されるため、常時サーバを用意する必要がありません。 -
Amazon S3
→ 生成画像の保存や配布素材の保管を担当。データベースではなくストレージ中心の構成にしています。主な用途：
- raw/：生成直後の原本
- share/：共有用の軽量版や透かし入り画像
- zips/：スタンプ用ZIPなどの配布データ
-
CloudFront（CDN）
→ フロントの静的ページ配信や画像配信を高速化。キャッシュが効くためコストも安定します。 -
Next.js（静的 export）
→ フロントエンドUI。静的サイトとして配信し、サーバレス構成を維持しています。 -
DynamoDB（必要最低限）
→ 利用回数や生成履歴などのトラッキング用途。必須ではありませんが運用管理のために利用しています。
全体として「できるだけ静的に」「必要な処理だけ動かす」という思想で構成しています。
基本方針はシンプルです。
- フロントは静的配信
- 重い処理はオンデマンド実行
- 配布は安全かつ低コストに
この3点を軸に設計しています。
コストを抑えるための工夫
① 静的フロント配信
DropのUI部分はNext.jsを静的exportしてS3＋CloudFrontで配信しています。
この構成にすると、
- Webサーバ維持が不要
- アクセス増加に強い
- CDNキャッシュが効いて転送コストが抑えられる
個人開発でも安心して公開できる構成になります。
② Presigned URLによる配布
生成した画像やZIPは、
**署名付きURL（Presigned URL）**で直接S3から配布しています。
これにより：
- アプリサーバがファイル転送を中継しない
- S3バケットを公開にしなくて済む
- 期限付きアクセスで安全に共有できる
特に画像配布サービスでは、この方式がコストと安全性のバランスが良いと感じています。
③ Lambda中心のオンデマンド処理
画像生成・ZIP化・プレビュー生成などはすべてLambdaで実行しています。
メリット：
- 使った分だけ課金
- アイドル時コストほぼゼロ
- スケールを気にしなくていい
常時稼働サーバを持たないのは、個人開発ではかなり大きいです。
実際のコスト感（参考）
まだ本格運用前ですが、おおよその感覚です。
- Lambda：ほぼ誤差レベル
- S3保存：数十円〜100円/月程度想定
- CDN転送：アクセス次第だが比較的安定
- AI画像生成：回数に依存
画像生成サービスとしては、個人運用でも現実的なラインだと思っています。
この構成にした理由
単純に安くしたいだけではありません。
- 長く続けられること
- 作品を安心して配布できること
- 技術と表現を両立したいこと
この3つを重視しています。
特にDropは「作品を配る場所」なので、
安全性と運用コストのバランスをかなり意識しました。
今後やりたいこと
- 配布リンク管理の改善
- OGP画像の自動生成
- 利用統計の可視化
- Poem / Storiesとの作品統合
まだ模索フェーズなので、このあたりは柔軟に変えていく予定です。
進行中のプロジェクトなので設計は今後も変わると思いますが、
同じようにAI生成物を配布するサービスを作っている方の参考になれば嬉しいです。