はじめに
Android開発からWebシステム（React / AWS / API）に入ると、「なんか動きが違う」「どこで何が動いてるんだ？」という違和感を感じる場面が多くあります。
この記事では、そんなAndroid → Web の移行期に自分がハマった勘違いを、Webシステム全体の流れに沿って整理します。同じ道を歩く人の地雷回避に役立てれば嬉しいです。
全体像（まずここを押さえる）
- SPA（CSR）: Browser → S3（JS取得）→ Browser → API
- SSR: Browser → SSRサーバー → API
💡 「どこで何が動くか」がWeb理解のすべての起点
1. 実行場所は1つじゃない
Androidの前提
- UI / ロジック / 状態管理はすべて端末のみで動く
Webの現実
| 方式 | 実行場所 |
|---|---|
| SPA（CSR） | ブラウザのみ |
| SSR | サーバー → ブラウザ |
| SSG | ビルド時 → ブラウザ |
Androidでは「コードはすべて端末で動く」が当たり前なので、サーバーとブラウザで同じReactコードが動くという感覚が最初はピンきません。
💡 「このコードはどこで動く？」を常に意識する必要がある
2. HTMLは最初から完成していない（SPA）
SPA（CSR）の流れ
-
index.htmlはほぼ空（<div id="root"></div>のみ） - HTMLの実体はブラウザがJSで組み立てる
Androidで言うと、レイアウトXMLが空で、KotlinコードがすべてのビューをaddView()で動的生成しているようなイメージです。
💡 HTML = 器。中身はJSが動的に作る
3. SSRではHTMLは「サーバーで作られる」
- 初回表示でデータが入った状態のHTMLが返ってくる
- ブラウザは受け取ったHTMLを「表示するだけ」（初期レンダリングが速い）
💡 SPAとSSRは「HTMLを誰が作るか」が根本的に違う
4. Reactはフロント専用ではない
| 方式 | Reactが動く場所 |
|---|---|
| SPA（CSR） | ブラウザのみ |
| SSR | サーバー + ブラウザの両方 |
| SSG | ビルド時 + ブラウザの両方 |
Androidでは「UIコードはクライアント（端末）専用」ですが、ReactはNode.js環境があればサーバー上でも動きます。
💡 React = 実行環境を選ばないUIロジック
5. Hydration（ハイドレーション）とは何か
SSRで最初に戸惑うのがこれです。
| フェーズ | 状態 |
|---|---|
| SSR直後 | HTMLが表示されるが、ボタンを押しても何も起きない |
| Hydration後 | ReactがDOMと結合し、インタラクティブに動作する |
事故りやすい原因
- サーバーとブラウザでHTMLの内容が不一致（hydration mismatch エラー）
-
windowやlocalStorageをSSR時に使用してしまう（サーバー上には存在しない） -
new Date()やMath.random()など実行タイミングで値が変わるものの使用
💡 「表示はできるが操作できない」という一瞬があることを知っておく
6. SPAならNext.jsは必須ではない
Next.jsが必要だと思い込みがちですが、用途によってはSPA（Vite + React）の方がシンプルで最適です。
SPAの王道構成
React + TypeScript
Vite（開発サーバー・バンドラー）
S3 + CloudFront（ホスティング）
API（別途）
特徴:
- SSR / Hydrationなし → シンプルで安定
- インフラもS3 + CloudFrontだけ → 運用が楽
💡 業務Web・管理画面ならSPA構成が王道
7. Next.jsのファイルベースルーティングはSPAでも再現できる
Next.jsを使うとファイル構造がそのままURLになる体験が快適で、SPAに戻ると「自分でルーティング書くの？」となりがちです。
Next.js（App Router）のファイルベースルーティング
app/
devices/
page.tsx → /devices
devices/[id]/
page.tsx → /devices/123
SPAでも vite-plugin-pages で同様の体験が得られる
src/pages/
index.tsx → /
devices/
index.tsx → /devices
[id].tsx → /devices/123
vite-plugin-pages はファイル構造から自動的にReact Routerの設定を生成してくれます。
💡 Nextの開発体験 + SPAのシンプルさ、両方取れる
8. フロント・BFF・APIの責務を分ける
| 層 | 責務 |
|---|---|
| フロント | 表示・操作 |
| BFF（Backend for Frontend） | 複数APIの集約・UI向けデータ整形 |
| 業務API | 業務ロジック・バリデーション・永続化 |
Androidでも「UI層がビジネスロジックを持つな」というのは同じ考え方です。
💡 業務判断（バリデーション・権限チェック等）は必ずバックエンドで行う
まとめ
| ポイント | 一言で |
|---|---|
| 実行場所 | ブラウザ / サーバー / ビルド時 に分かれる |
| HTML生成 | SPAはブラウザ、SSRはサーバー |
| React | ブラウザ専用ではない |
| SSRの難しさ | Hydrationの仕組みを理解すると解ける |
| 業務Webの構成 | SPAが王道（Next.js必須ではない） |
Androidの経験はWebでも武器になる
AndroidエンジニアがWeb開発で感じる「違和感」は、理解が進んでいるサインです。
- ライフサイクル意識 → コンポーネントのマウント・アンマウントに活きる
- 状態管理の経験 → ReactのuseState / useReducerが直感的に理解できる
- 非同期思考 → PromiseやasyncをCoroutinesの感覚で扱える
「違和感を持てた」その時点で、すでに半歩先に進んでいます。
同じように Android → Web に来た人の地雷回避になれば嬉しいです。