AIコーディングエージェントを使えば、プログラミング経験が浅くてもWebアプリやモバイルアプリを形にできるようになりました。
一方で、AIへ技術選定まで任せると、複数の言語、認証サービス、キャッシュ、メッセージキュー、マイクロサービスなどが一度に提案されることがあります。どれも間違いとは限りませんが、構成要素が増えるほど、障害時に確認する場所と学ぶことも増えます。
この記事では、AI駆動開発を始める人が迷いにくいように、次の方針で技術スタックを一つに絞ります。
- 最初はTypeScriptへ統一する
- 広く利用され、情報を探しやすい技術を選ぶ
- ローカルだけでなく本番運用まで考える
- 最初から全部盛りにしない
- 性能上の問題が確認されてから構成を増やす
特定の要件に対する唯一の正解ではありません。「明確な理由がなければ、まずここから始める」という基準です。
最初に結論
| 分野 | 採用する技術 |
|---|---|
| バージョン管理 | Git／GitHub |
| 開発環境 | Linux、macOS、またはWSL2 |
| 共通言語 | TypeScript |
| Web | Next.js |
| Web UI | Tailwind CSS |
| モバイル | Expo／React Native |
| モバイルUI | React Native StyleSheet、必要ならNativeWind |
| API | Hono |
| 認証 | Better Auth |
| ORM／DBマイグレーション | Drizzle ORM／Drizzle Kit |
| データベース | PostgreSQL |
| 単体・結合テスト | Vitest |
| E2Eテスト | Playwright |
| 実行環境 | Docker |
| CI/CD | GitHub Actions |
| 本番環境 | Cloud Run＋Cloud SQL |
| ファイル保存 | 必要になったらCloud Storage |
全体像は次のようになります。
Web: Next.js + Tailwind CSS
Mobile: Expo + React Native
│
▼
Hono + Better Auth
│
Drizzle ORM
│
PostgreSQL
本番: Cloud Run + Cloud SQL
1. 最初にGitを使う
AI駆動開発では、Gitは後から覚える付加機能ではありません。AIが変更した内容を確認し、問題があれば戻すための安全装置です。
最低限、次の流れは最初から使います。
git status
git diff
git add <確認したファイル>
git commit -m "変更内容を短く書く"
git push
AIへ作業を依頼する前にもコミットしておくと、変更前後を比較しやすくなります。
GitHubへ保存する際は、次のファイルをコミットしないようにします。
.env- APIキー
- DBのパスワード
- 秘密鍵
- 本番データやバックアップ
秘密情報を一度コミットすると、現在のファイルから消してもGit履歴には残ります。誤って登録した場合は、最初にその認証情報を失効・再発行します。
2. 開発環境はLinuxへ近づける
本番環境の多くはLinuxです。Windowsを使用する場合はWSL2を利用すると、パス、権限、シェル、改行コードなどの差を減らせます。
OSの操作をすべて暗記する必要はありませんが、次の操作は理解しておくとAIの作業結果を確認しやすくなります。
- 現在のディレクトリとファイルを確認する
- ファイルの権限を確認する
- プロセスとポートを確認する
- ログを読む
- 環境変数を設定する
- コマンドの終了コードを確認する
AIが提示したコマンド、とくに削除、権限変更、外部スクリプトの実行は、意味と対象を確認してから実行します。
3. 言語はTypeScriptへ統一する
最初からフロントエンドをTypeScript、APIをGo、バッチをPythonのように分けると、言語ごとの依存管理、テスト、デプロイ、エラー処理を覚える必要があります。
この記事では、Web、モバイル、APIをTypeScriptへ統一します。
一つの言語へ寄せる利点は次のとおりです。
- Web、モバイル、APIで型を共有しやすい
- AIへ渡す前提知識が減る
- エラーの読み方やテスト方法を揃えられる
- リポジトリ全体を人が追いやすい
- デプロイ方法を共通化しやすい
GoやPythonが悪いわけではありません。CPU負荷の高い処理、大量の並行処理、機械学習など、採用する理由が生まれてから追加すれば十分です。
4. WebはNext.js＋Tailwind CSS
WebアプリにはNext.jsを使います。画面とサーバー側の処理を一つのプロジェクトから始められるため、小規模なアプリで境界を増やさずに済みます。
CSSにはTailwind CSSを使います。AIが比較的一貫した形でUIを生成しやすく、スタイルの適用箇所も追跡しやすいからです。
ただし、最初からUIコンポーネントライブラリを何種類も混ぜないようにします。デザインシステムが必要になった段階で、一つを選んで追加します。
5. モバイルはExpo＋React Native
iOS／AndroidアプリにはExpoとReact Nativeを使います。Webと同じTypeScriptを使いながら、カメラ、通知、SecureStore、ディープリンクなどのモバイル機能を利用できます。
スタイルは、最初はReact Native標準のStyleSheetでも十分です。Webと書き方を揃えたい場合はNativeWindを検討します。
Expo
└─ React Native
├─ TypeScript
├─ Expo Router
└─ SecureStore
Web用のTailwind CSSを、そのままReact Nativeへ適用できるわけではない点には注意が必要です。
6. APIはHono
APIにはHonoを使います。Web標準のRequestとResponseを利用し、Node.jsなど複数の実行環境へ配置できます。
Next.jsとは別にAPIが必要になる代表例は、ExpoアプリとWebアプリで同じAPIを共有する場合です。
Next.js ─┐
├─ Hono API ─ PostgreSQL
Expo ────┘
Hono RPCを利用すれば、サーバー側で定義したAPIの型をクライアント側でも利用できます。ただし、型共有だけを理由に内部実装までクライアントへ公開しないようにします。入力値の検証と権限確認は必ずサーバー側でも行います。
7. 認証はBetter Authへ任せる
ログイン、パスワード保存、セッション、OAuth、Cookieを独自実装するのは避け、Better Authを利用します。
Better AuthとHonoは、Web標準のAPIを使って直接接続できます。
import { Hono } from "hono";
import { auth } from "./auth";
const app = new Hono();
app.all("/api/auth/*", (c) => auth.handler(c.req.raw));
公式ドキュメント: Better AuthのHono統合
Expo向けの公式プラグインもあり、セッション情報をSecureStoreへ保存し、GoogleやAppleなどのソーシャルログインで必要になるディープリンクを扱えます。
公式ドキュメント: Better AuthのExpo統合
認証と認可は別
Better Authを導入しても、利用者がどのデータを操作できるかはアプリ側で実装します。
認証: この利用者は誰か
認可: この利用者が、このデータを操作してよいか
画面から管理者ボタンを隠すだけでは認可になりません。APIごとにセッションと権限を確認します。
JWTを自作しない
JWTはログイン機能そのものではなく、署名された情報を受け渡すための形式です。JWTを採用しても、次の問題が自動的に解決するわけではありません。
- パスワードの安全な保存
- トークンの失効
- Refresh Tokenの保管とローテーション
- 端末紛失時の対応
- 署名鍵の管理と更新
- CSRFやXSSへの対策
- ログアウト後の扱い
初心者が独自のJWT認証を作らず、まずBetter Authのセッション管理を利用します。外部サービス連携などでJWTが必要になった場合も、実績のあるライブラリや標準機能へ任せます。
8. DBはPostgreSQL、ORMはDrizzle
構造化データにはPostgreSQLを使います。ユーザー、権限、注文、顧客情報など、関連性と整合性が重要なデータに適しています。
ORMにはDrizzle ORM、マイグレーションツールにはDrizzle Kitを使います。TypeScriptで定義したスキーマからSQLマイグレーションを生成し、内容を確認してGitで管理します。
TypeScriptのスキーマ
↓
マイグレーションを生成・確認
↓
PostgreSQLへ適用
AIが生成したマイグレーションも、そのまま本番へ適用しません。テーブル削除、列の型変更、NOT NULL追加、インデックス作成などが既存データへ与える影響を確認します。
適用済みのマイグレーションを書き換えず、修正は新しいマイグレーションとして追加します。
開発中にスキーマを直接同期する方法もありますが、本番環境では変更履歴が残るマイグレーションファイルを生成し、レビューしてから適用する運用を基本にします。
9. テストはVitest＋Playwright
AIはテストコードも生成できますが、テストが存在することと、必要な仕様を検証できていることは別です。
Vitestでは、関数、入力値検証、権限判定などを確認します。Playwrightでは、利用者が実際に行う重要な操作を確認します。
最低限、次の種類を含めます。
- 正常系
- 未入力と不正な形式
- 境界値
- 未認証
- 権限不足
- 他人のIDを指定したアクセス
- DBや外部APIが失敗した場合
「テストを追加して」だけではなく、守りたい仕様を具体的にAIへ渡すことが重要です。
10. Dockerで実行環境を固定する
本番環境にはDockerコンテナとして配置します。開発者のPCにだけ入っているパッケージや設定へ依存する状態を避けられます。
ただし、Dockerを使えば安全になるわけではありません。
- rootユーザーで実行しない
- 不要なファイルをイメージへ含めない
-
.envや秘密鍵をコピーしない - バージョンを固定する
- 依存パッケージの脆弱性を確認する
- コンテナ内へ永続データを保存しない
本番用イメージはGitHub Actionsでビルドし、テストに成功したコミットだけをデプロイします。GCPとの認証には、長期間有効なサービスアカウントキーではなく、Workload Identity Federationのような短期認証を利用します。
11. 本番はCloud Run＋Cloud SQLから始める
最初のインフラ構成は、Cloud RunとCloud SQLだけで十分です。
利用者
↓ HTTPS
Cloud Run
↓
Cloud SQL for PostgreSQL
Cloud Runはコンテナの起動、置き換え、負荷に応じたスケーリングを管理します。Cloud SQLはPostgreSQLのバックアップ、更新、監視などを管理します。
最初から高可用構成が必須とは限りません。停止時間をどこまで許容できるか、失われて困るデータは何かを確認し、必要ならCloud SQLを高可用構成にします。
ステージング環境の費用を抑えたい場合
まだ利用者のいない開発版を動かすステージング環境では、Cloud Run＋Cloud SQLの固定費を高いと感じることもあります。その場合は、Vultrなどの低価格なクラウドVMを1台借り、アプリとPostgreSQLを同居させる方法も選択肢の一つです。
開発者
↓ HTTPS
クラウドVM
├─ アプリケーション
└─ PostgreSQL
例えばメモリ4GBのVMなら月額約20ドルから構築でき、ステージングではマネージドDBを別に契約せずに済みます。Vercel Pro（月額20ドルから）とSupabase Pro（月額25ドルから）を組み合わせる構成は合計月額45ドルからになるため、ステージング環境の固定費だけを比べると、Vultrへ同居させる方法が最も安価です。
これはあくまで開発・確認用のステージング環境を比較したもので、本番環境の可用性や運用費を含む比較ではありません。実際の料金は、選択するプラン、リージョン、転送量、バックアップなどのオプションによって変わります。また、Vultr構成ではサーバーを管理する作業も必要です。
小さく始められる一方で、OSとPostgreSQLの更新、バックアップ、監視、障害対応は自分で行う必要があります。DBポートをインターネットへ直接公開せず、本番データや重要な個人情報を安易に入れないようにします。
サービスを正式公開するときは、そのVMを継続して運用するのか、Cloud Run＋Cloud SQLなどのマネージド環境へ移すのかを改めて判断します。開発初期からDockerとマイグレーションを使っておけば、後から環境を移しやすくなります。
アップロードファイルはCloud Storage
Cloud Runのコンテナは作り直されます。アップロードされた画像やPDFをコンテナ内だけへ保存すると、新しいインスタンスへ置き換わった際に失われます。
ファイル保存が必要になった場合だけCloud Storageを追加します。
構造化データ PostgreSQL
画像・PDF Cloud Storage
秘密情報 Secret Manager
ログ Cloud Logging
12. CDNとValkeyは最初から入れない
CDNを追加する時期
モバイル向けのJSON API、認証後の画面、利用者ごとに内容が変わるレスポンスは、CDNでキャッシュしにくい場合があります。
CDNは次の問題が確認されてから検討します。
- 画像や大きな静的ファイルの配信が多い
- 遠い地域からの表示が遅い
- 同じ公開コンテンツへのアクセスが多い
- Cloud Runへの転送量や負荷を減らしたい
Cloud RunへCloud CDNを組み合わせる場合は、外部Application Load BalancerとServerless NEGも必要になります。設定と料金が増えるため、使う理由ができてから追加します。
公式ドキュメント: Cloud CDNの設定概要
Valkeyを追加する時期
Better Authのセッションや通常の検索結果は、最初はPostgreSQLで管理できます。
Valkeyは次の用途が明確になってから追加します。
- 同じDBクエリが大量に発生している
- 複数インスタンスでレート制限を共有する
- 短時間だけ保持するデータが大量にある
- ジョブキューが必要になった
- PostgreSQLが実測上のボトルネックになった
Cloud RunからマネージドValkeyへ接続するには、ネットワーク設定も必要です。最初から追加すると、データの整合性、キャッシュ失効、障害時の挙動という新しい問題も増えます。
13. 早く公開したい場合の代替構成
ここまでCloud Run＋Cloud SQLを基準にしましたが、すべてのアプリに同じ構成を強制する必要はありません。短期間での公開を優先する場合は、Vercel、Supabase、Cloudflare Workersも有力です。
| 重視すること | 構成例 |
|---|---|
| 構成の分かりやすさと移行性 | Cloud Run＋Cloud SQL＋Better Auth |
| Next.jsを最短で公開 | Vercel Pro＋Supabase Pro |
| Hono APIを低コストで配信 | Cloudflare Workers＋PostgreSQL |
Vercel＋Supabase
Next.jsを短期間で公開し、認証やDBの管理も減らしたい場合は、VercelとSupabaseを組み合わせられます。
Next.js Vercel Pro
認証・DB Supabase Pro
VercelのHobbyプランは個人・非商用向けです。業務や商用サービスではPro以上を選びます。
Supabase Authは、Freeプランで月50,000 MAU、Proプランで月100,000 MAUが含まれます。これは登録者数ではなく、その請求期間中にログインまたはトークンを更新した利用者数です。Proでは100,000 MAUを超えた分が従量課金されます。
構築は速くなりますが、認証データ、DB、Storage、Realtimeなどをまとめて採用するほどSupabaseへの依存は強くなります。将来の移行方法と、利用者増加時の料金も確認して選びます。
Cloudflare Workers
HonoはCloudflare Workersと相性がよく、APIを世界各地へ低コストで配置できます。Workers Paidは最低月額$5で、月1,000万リクエストと一定量のCPU時間を含みます。静的アセットへのリクエストは無料です。
Expo／Web
↓
Hono＋Better Auth
Cloudflare Workers
↓
PostgreSQL
PostgreSQLへ接続する場合は、接続先DBの場所と遅延を確認します。Cloudflare Hyperdriveを使うと、Cloud SQL、SupabaseなどのPostgreSQL／MySQLへの接続をプールできます。
Next.jsもWorkersへ配置できますが、実行環境はNode.jsそのものではありません。Cloudflareは新規のNext.jsアプリにvinextを案内していますが、現時点ではベータです。Next.jsの機能や依存パッケージに互換性の差がないか、公開前に確認します。
Next.jsをほぼそのまま配置したい初心者にはVercel、Hono APIを中心に構築する場合はWorkers、コンテナとして実行環境を揃えたい場合はCloud Run、という分け方が分かりやすいでしょう。
14. 段階的に増やす
最初から最終形を作ろうとせず、必要性を確認しながら増やします。
第1段階
Cloud Run＋Cloud SQL
第2段階
アップロードが必要ならCloud Storage
第3段階
静的配信が増えたらCDN
第4段階
DB負荷を計測し、必要ならValkey
第5段階
可用性要件に応じてDBのHA化・複数リージョン化
15. AIへ最初に渡す技術方針
リポジトリのREADMEや開発ルールへ、採用技術と禁止事項を書いておきます。
このプロジェクトでは次の技術を使用します。
- 言語: TypeScript
- Web: Next.js
- Mobile: Expo / React Native
- API: Hono
- Auth: Better Auth
- ORM / Migration: Drizzle ORM / Drizzle Kit
- Database: PostgreSQL
- Test: Vitest / Playwright
- Production: Docker / Cloud Run / Cloud SQL
次のルールを守ってください。
- 新しい言語、フレームワーク、DB、認証方式を無断で追加しない
- JWT認証を独自実装しない
- APIでは入力値、認証、認可をサーバー側で確認する
- 秘密情報をコード、ログ、テストデータへ含めない
- DB変更はマイグレーションとして作成する
- コンテナ内へ永続データを保存しない
- CDN、Valkey、メッセージキューは必要性を説明してから追加する
- 変更後に型チェック、Lint、テストを実行する
- 関係のないファイルを変更しない
AIに自由な技術選定を毎回させるのではなく、変更する場合は理由、利点、運用負担、代替案を提示させます。
16. この構成を使わない方がよい場合
この構成も万能ではありません。
- CPU負荷の高い処理が中心
- 厳しいリアルタイム要件がある
- オフライン中心のモバイルアプリ
- 大量の動画変換や機械学習処理
- 既存のJava、.NET、Goなどの資産がある
- 顧客からクラウドや言語を指定されている
- 法令や社内規程による固有の要件がある
この場合は、要件、既存資産、運用できる人、予算を基に選び直します。
まとめ
AI駆動開発では、技術を増やすことより、採用した技術の役割と境界を人が理解できることが重要です。
最初は、Git、TypeScript、Next.jsまたはExpo、Hono、Better Auth、Drizzle ORM、PostgreSQL、Docker、Cloud Run、Cloud SQLで十分です。
Cloud Storage、CDN、Valkey、別言語、マイクロサービスは、実際の要件や計測結果から必要になった時点で追加します。
最初から将来のすべてを解決する構成ではなく、問題が起きたときに安全に変更できる構成を選ぶことが、AI駆動開発で迷いにくくするための基本方針です。