事の発端

私：「WordPress の記事から4コマ漫画を自動生成するプラグイン作ってるんですよ」

上司：「それ、ニュース記事をスクレイピングして勝手に漫画にしたら面白くね？」

私：「……！」

そんな雑談から3日後、ドメインを取り、2週間後にはWeb版とモバイルアプリ版をほぼ同時にローンチしていました。それが、毎日のニュースを4コマ漫画に変える猫耳キャラのサービス「[にじじじ](https://nijijiji.jp)」です。

しかも本業の合間、ほぼ片手間で。代わりにAI(Claude Code)をフル活用しています。「2週間」という数字の裏側はそういう話です。

「Web版だけ先に出す」「アプリ版は後から」という選択肢もあった中で、なぜ同時ローンチを選び、どう実現したのか。Next.js + Expo というスタックと、AIを実装パートナーにすることで、個人開発レベルの工数に収めるためにやったことを書きます。

なぜ2週間で両方出したかったか

ノリで始めたとはいえ、Web版だけ先に出すという選択もありました。それでも同時ローンチに振り切ったのは、プロダクト設計上の理由が大きかったからです。

にじじじはニュース消費体験を「読む」から「眺める」に変える試みで、想定する利用シーンは通勤中・休憩中・寝る前といったモバイルが圧倒的に強い時間帯。Web版だけだと「ブラウザを開いてURLを打つ」のハードルがあり、習慣化につながりにくい。

一方でWeb版がないとSEOやXからの導線で新規ユーザーに届きません。だから両方必要、しかも検証サイクルを早く回したいから2週間。逆算でスタックが決まります。

採用したスタック

– Web:    Next.js (App Router) + TypeScript

– App:    Expo (React Native) + EAS Build

– 共通:    pnpm workspace でモノレポ化

– AI生成:  Claude API + 内製クローラ

– インフラ: AWS (ECS Fargate + ECR) / 画像配信は CloudFlare R2

– CI/CD:  GitHub Actions

最大の判断は「Web と App でロジックを共有する」 こと。Next.js と Expo は完全に別物ですが、API クライアント・型定義・ドメインロジックは共有可能です。

モノレポ構成 — 共有できるものは徹底的に共有する

packages/
├── crawler/     # Node + TypeScript（ニュースクロール・ECS Task / Cheerio・Puppeteer）
├── generator/   # Node + TypeScript（4コマ生成ワーカー・ECS Task / Gemini API・R2）
├── web/         # Next.js 15 (App Router) + TypeScript + Tailwind CSS + Prisma
├── expo/    # Expo (React Native) + TypeScript + NativeWind（モバイルアプリ）
├── x-poster/    # Node + TypeScript（X(Twitter) 投稿ワーカー・ECS Task）
├── infra/       # AWS CDK + TypeScript（IaC）
├── shared/      # 共通ライブラリ（API クライアント・hooks・types・TypeScript）
└── ui/          # 共通 UI コンポーネント（Tailwind + NativeWind）

ポイントは **UIコンポーネントは共有しない** こと。RNとWebのスタイルシステムは違いすぎて、無理に React Native Web で統一すると逆に遅くなります。「型とロジックは共通、ビューは個別」が現実解でした。

API クライアントの共通化

両アプリから叩く API クライアントは型ごと共通パッケージに置きます。

// packages/api-client/src/manga.ts
export async function fetchTodayManga(): Promise<Manga[]> {
    const res = await fetch(`${API_BASE}/api/manga/today`);
    if (!res.ok) throw new ApiError(res.status);
    return res.json();
}

Web側は `next/cache` で revalidate、App側はSWRでキャッシュ、と呼び出し側で挙動を変えるだけで済みます。

Expo の威力 — アプリ側の工数を1/3にした要因

Expo (EAS Build) を使うと、ネイティブのビルド環境をローカルに用意せずに iOS/Android のバイナリが手に入ります。Xcode を開いて証明書と格闘する時間がゼロ。

OTA アップデートも標準装備なので、JS側の修正はストア審査を通さず即配信できる。個人開発でこのスピード感は反則レベルです。

詰まったところ: 画像配信

4コマ漫画はAI生成画像で、1日約20枚を毎日自動生成します。これを Web と App の両方に高速配信する必要がある。

– CloudFlare R2 に生成画像を保存
– CloudFlare CDN 経由で配信(エグレス無料が地味に効く)

AIを「実装パートナー」にする

冒頭で「片手間」と書きましたが、これはAIの活用前提です。使い分けはざっくりこんな感じ(モデルは基本 Claude Opus):

• Claude Code (Opus): モノレポ初期設計、コード実装全般、Expo まわりのハマりどころ調査、リファクタ
• Claude チャット (Opus): 設計判断の壁打ち、技術選定の比較検討
• Gemini AI (Nanobanana): 漫画生成モデルとして活用
• ChatGPT(image 2.0): キャラクターやバナー画像等素材生成

特に効いたのは 設計判断を声に出して相談する相手がいる こと。個人開発はレビュアー不在になりがちで、「これUIコンポーネントも共通化すべき?」みたいな迷いで半日溶かす、というのがよくあります。AIに前提を投げて30秒で叩き台が返ってくる、それを叩いて決める。この判断のサイクル時間が圧倒的に縮むのが、AIを使う最大の効能でした。

実装そのものより、設計判断の速度が「片手間でも2週間」の正体です。

2週間というのは決して「楽だった」期間ではないですが、スタックの選び方とAIの使い方で、個人開発の物理的な上限は確実に押し上げられる と実感しました。片手間でこれが出せる時代になっているということです。

似たような構成で動かしてみたい方、コメントや X (@nijijiji) でぜひ感想ください。