【AIフル活用】認可サーバーを用いたマルチテナントなマルチプロダクト開発への道 〜選定編〜
前回、新たな開発企画がスタートした。
もろもろ要件を考える前に、まずは技術選定しようと思う。
本記事では、バックエンド / フロントエンド / スマホアプリなどの技術スタックと選定理由を、あれこれ記述する。
選定基準
本開発の前身である認可サーバー開発では、バックエンドを複数言語＆複数フレームワークで開発したが、「普通に作っても面白くない」「AI駆動開発の調査」という目的があった。
今回のプロダクト開発は、AI調査は十分に行ったのと早く動いてるのを見たいので、複数言語など余計なことはせずスタックを固定し、「開発速度 / 効率」を最優先にした技術選定を行うことにする。
技術選定
バックエンド
TypeScript / Hono / Drizzle ORM
フロントエンド
React / Next.js / TypeScript / TailwindCSS
スマホアプリ
React Native
選定理由
普段の技術選定ではトレンドだったりパフォーマンスを重視して考えることが多く、フロント / バックなどの各レイヤーは別々の言語にするのが好みで、最近はバックエンドは迷わずGoを選択している。
今回は、開発速度や効率を最優先としてAIと議論した結果、TypeScriptで統一する方向性になった。
まず、Goはコンパイル言語だったことを忘れてた。
開発速度を考えた時に、いちいちコンパイルが走るのは邪魔くさいし、ビルドコストは可能な限り削減したい。
そう考えると、選択肢が TypeScript / Python / Ruby / PHP に絞られる。
PHPは個人的に飽きた、Rubyは動的型付け言語でオワコンだと思ってるので、TypeScript / Python に絞られる。
Pythonも動的型付け言語だけど、フレームワークにFastAPIを選択すれば型ヒントが使えるらしいので、この2つをAIに比較して貰った。
1. TypeScript最大の強みは、バックエンドで定義したバリデーション（Zodなど）や型定義を、フロントエンド（Next.js / React / Flutter等）でそのまま100%流用できる点です。
・APIのレスポンス形式を変えても、フロント側の型エラーが即座に検知されるため、手動での仕様調整やAIへの二重指示が不要になります。
・AIツール（Claude Code等）に「バックエンドAPIの変更に合わせてフロントのUIも修正して」と指示した際の成功率が跳ね上がります。
・Bun や tsx などのモダンな実行環境を使えば、TypeScriptファイルを事前コンパイル・ビルドすることなく、スクリプト言語感覚で即座に実行・Hot Reloadできます。
2. Python（FastAPI等）も開発速度は早いですが、大量のデータ処理や並行アクセスにおいてTypeScript（Node.js / Bun）のV8エンジンや非同期I/O処理のパフォーマンスには及びません。
TypeScriptなら、開発速度を最大化しつつ実用十分なレスポンス速度を保てます。
ということで、AIには TypeScript を激推しされた。
確かに、フロント＆バック連携で型共有できる点は、開発速度や効率を考えるとスムーズな気がするので、バックエンドはTypeScriptに決定！
フレームワークは、認可サーバー開発と同じく、Hono / Drizzle ORM のモダン構成にする。
フロントも同じく React / Next.js / TypeScript / Tailwind CSS とした。
次にスマホなのだが、今時の開発ではFlutterが選ばれると思う。
認可サーバー開発でもFlutterを選択しフルAI実装で5日で完成したが、今回はTypeScript統一にあやかって、敢えて React Nativeを検討してみたくなり、AIに聞いてみた。
最大の利点は、プロダクト全体で言語と思考フレームワークを1つ（TypeScript）に固定できる点です。
Flutterの場合: Dart 言語と Flutter 独自のウィジェットツリー構造が必要になり、Web（React）やバックエンド（Hono）とはコードや知見が分断されます。
React Nativeの場合: バックエンドからWeb、モバイルアプリまで100% TypeScriptで書けるため、AI（Claude CodeやDevin等）に指示を出す際も文脈の切り替えが発生せず、AIの生成精度と開発速度が爆上がりします。
ほほう、、、なるほどね〜🧐
ということで、スマホは React Native に決定！
その他もろもろは、認可サーバー開発から色々と流用するが、AWS Lambda (Go) の流用は気になった。
せっかくTypeScriptで統一してるので、LambdaもTypeScriptの方が良さそうな気がするので、AIに聞いてみた。
「Lambda構成（枠組み・IaC）」は流用しつつ、中身のバックエンドコードは TypeScript (Hono) で書くのが絶対にオススメです！
1. インフラの流用コストゼロ（構成案の横展開）
認可サーバーで作成した Lambda のデプロイ構成、APIGateway設定、環境変数管理、Terraform や CI/CD の枠組みは、そのままコピー＆流用できます。
2. Hono は AWS Lambda 上で超爆速で動く
Hono には hono/aws-lambda という公式アダプターが用意されており、AWS Lambda（Node.js / Bun ランタイム）上でそのまま超軽量・超高速に動作します。
3. TypeScript の最大の強み（Zod / Hono RPC）を100%享受できる
Lambda 上で Hono を動かすことで、スマホアプリ（React Native）やWeb（Next.js）との間で型定義や Zod スキーマを直接共有でき、AI（Claude Code等）による全層一括修正の爆速ループが維持されます。
なるほどー、やっぱりTypeScriptにした方が良いのね🤔
一通りコレでOK、、、あ、、、ウッカリしてた、、、LLM API 選定を忘れてたわ。
これ一番重要だったので、AIに選定して貰う。
へ〜、Claude最強だと思ってたけど、意外にもGemini最強だったのね。
開発パートナーやコード生成（Claude CodeやDevin）として使うときは、確かに Claude 3.5 Sonnet が圧倒的（まさに最強） ですよね！
今回 Gemini（特に 1.5 Flash系）が猛追して評価が高いのは、プロダクトの裏側に組み込む「画像解析（Vision）API」としての特殊な強み があるからなんです。
1. 服の写真認識（Vision）の精度とスピード Googleが長年培ってきた画像検索やマルチモーダルの技術が活きており、服の写真から「ジャケット/シャツ」「色・柄」「素材感」を判別する速度がめちゃくちゃ早いです。
2. 圧倒的なAPIコストの安さ ユーザーがクローゼットの服を20着、30着と連続でパシャパシャ撮影して登録しても、API破産しない圧倒的なコスパ（Claudeの数分の一〜十分の一） を誇ります。
まったく、、、AIによって得意領域が異なるのが困るわ。
色んなAI利用しなきゃだし、AIは💰が掛かるわ、、、
全てを超越した最強AIが、早く登場して欲しいもんだねー😑
まとめ
今回は、今までの技術選定とは視点を変え「開発速度 / 効率」を最優先にしたことで、新たな景色が見えた結果となった😊
技術スタック確定🎉
開発環境
Mac / Docker / IntelliJ IDEA / ngrok / LocalStack / Terraform
ホスティング
AI
Gemini / Claude Code / Notion MCP / NotebookLM / CodeRabbit / Devin
ドキュメント
フロントエンド
React / Next.js / TypeScript / Tailwind CSS
スマホアプリ
バックエンド
ミドルウェア
AWS Lambda (TypeScript / Hono) / MySQL / Redis
LLM API
テスト
アーキテクチャ
フロントエンド / スマホアプリ
Feature-Basedアーキテクチャ ＋ Custom Hooks
バックエンド
DDD + クリーンアーキテクチャ
プロジェクト管理
