現役iOSエンジニアが、 スクショ地獄から解放されたくて AIと3日でSaaSを作った話

こんにちは、ZOZOTOWNでiOSアプリエンジニアをしている@tsuzuki817です。

普段は大規模なアプリ開発に携わっていますが、個人開発でアプリを世界展開しようとした際、「ある作業」の絶望的な面倒くささに心が折れそうになりました。

そう、「多言語対応スクリーンショットの作成」です。

「エンジニアなら、この単純作業は自動化すべきだ」

その一心で、AI（Gemini 3 Pro）を活用したローカライゼーションSaaS ScreenNative を、AI（Claude Code）とのペアプログラミングで開発しました。

今回は、その開発手法や、技術的にこだわった「堅牢なアーキテクチャ」について裏側を公開します。

なぜ作ったのか？：iOSエンジニアにしか分からない「痛み」

アプリをグローバル展開するには、App Store Connectに各言語ごとのスクリーンショットを入稿する必要があります。しかし、これを真面目にやろうとすると地獄を見ます。

地獄のスクショ作成フロー

1. xcrun simctl でシミュレータの言語をドイツ語に変える
2. アプリをビルドして起動
3. 必要な画面まで遷移してスクショを撮る
4. 「文字が長すぎてボタンから溢れてる！」 → Auto Layoutの制約を調整し直し
5. これを英語、フランス語、中国語...と10言語分繰り返す
6. さらに端末サイズ（6.9インチ、6.5インチ...）ごとに繰り返す

「これ、人間がやる仕事じゃないな」 と思いました。

ScreenNativeが解決すること

既存のスクショを1枚アップロードするだけで、AIが「UIの文脈（ボタンや余白）」を理解し、レイアウトを崩さずにテキストだけをネイティブ品質で翻訳・置換します。

開発体制：私(CTO) × AI(リードエンジニア)

今回の開発は、「私がCTO兼PMとして仕様を決め、AI（Claude Code）がリードエンジニアとして実装する」 という体制で行いました。

単にコードを書かせるだけでなく、アーキテクチャ設計からAIと壁打ちを行いました。

実際のやり取り例

私: 「Stripeの決済とクレジット消費をAtomicにやりたい。Firestoreの設計はどうすべき？」

AI: 「users コレクションとは別に creditTransactions で監査ログを残し、runTransaction で整合性を保ちましょう」

このように、「仕様 → 実装」のサイクルを極限まで高速化することで、実質3日間で決済機能付きのSaaSをデプロイまで持っていくことができました。

技術スタックとアーキテクチャ

「個人開発だから」という妥協はせず、企業が導入できるレベルのセキュリティと拡張性を目指しました。

カテゴリ	技術
Frontend	Next.js 15 (App Router), Tailwind CSS, shadcn/ui
Backend	Firebase Cloud Functions Gen 2 (Node.js)
Database	Cloud Firestore
Storage	Cloud Storage for Firebase
AI Model	Google Gemini 3 Pro (gemini-3-pro-image-preview)
Payment	Stripe (Checkout & Webhooks)

システム連携フロー

Next.jsのAPI Routesをゲートウェイとし、実際の処理はセキュアなバックエンド（Admin SDK）で行う構成です。

┌─────────────────┐    ID Token    ┌─────────────────┐
│  Client/Next.js │ ─────────────▶ │   API Routes    │
└─────────────────┘                └─────────────────┘
                                          │
                    ┌─────────────────────┼─────────────────────┐
                    │                     │                     │
                    ▼                     ▼                     ▼
            ┌─────────────┐       ┌─────────────┐       ┌─────────────┐
            │  Firestore  │       │ Gemini API  │       │   Stripe    │
            │  (Admin SDK)│       │             │       │             │
            └─────────────┘       └─────────────┘       └─────────────┘
                    │                                          │
                    │              Webhook                     │
                    │ ◀────────────────────────────────────────┘
                    ▼
            ┌─────────────────────────────┐
            │  Cloud Functions (Gen 2)   │
            │  - Transaction処理         │
            └─────────────────────────────┘

技術的なこだわりポイント

1. セキュリティ最優先のゼロトラスト設計

「クライアント（ブラウザ）は信用しない」を徹底しました。

Firestore Security Rules

ユーザーによる users コレクションへの書き込みは一切禁止（allow write: if false）。クレジットの消費やプラン変更は、必ずサーバーサイドの API Routes 経由で、Admin SDK を用いて行います。

マジックバイト検証

画像アップロード時、拡張子だけでなくバイナリの先頭（マジックナンバー）を検証し、偽装ファイルを弾く実装を導入しています。

2. 冪等性を担保した決済システム

StripeからのWebhookは、ネットワークエラーなどで複数回届く可能性があります。

そこで、stripeWebhooks コレクションでイベントIDを管理し、「一度処理した決済イベントは二度処理しない（冪等性）」 ロジックを実装しました。

また、クレジット消費時も Firestore Transaction を使用し、「生成成功」と「クレジット減算」が完全に同期するようにしています。

冪等性とは？
同じ操作を何度実行しても、結果が変わらないこと。例えば「100円引く」を2回実行しても、実際には1回分しか引かれないようにする仕組みです。

3. 型安全性とDX (Developer Experience)

開発効率を高めるため、「Single Source of Truth（信頼できる唯一の情報源）」 を徹底しました。

定数からの型導出

「対応言語リスト」や「プラン定義」を定数として定義し、そこから TypeScript の型 (LanguageCode, PlanId) を自動生成 (typeof ...)。これにより、プランを追加した際に修正が必要な箇所が型エラーとして即座に判明します。

Zodによる二重バリデーション

APIのリクエストボディ検証に Zod を採用。TypeScriptの型定義とランタイムのバリデーションを同期させています。

まとめ

ScreenNativeは、「iOSエンジニアが、自分の欲しいものをガチで作った」 プロダクトです。

• アラビア語などのRTL（右から左）レイアウト対応
• ステータスバー（9:41 / 100%）のクリーンアップ推奨
• デバイスフレームの自動合成

など、アプリ開発者ならではの「こだわり」を詰め込みました。

Total Source Files: 83 files（約8,000行）

---

ScreenNative - App Store Screenshot Localization AI

初期2枚無料で試せます。
面倒なスクショ作成業務から解放されたい開発者の皆さん、ぜひ使ってみてください！

👉 ScreenNative

---

最後まで読んでいただき、ありがとうございました。
「スクショ地獄」から解放される開発者が一人でも増えれば、これ以上の喜びはありません。