「6プロダクト同時開発」と聞くと、無謀に思えるかもしれません。実際、私も最初は不安でした。でも、2ヶ月やってみて分かったのは、仕組みさえ作れば意外となんとかなるということです。
ただし、これが実現できている最大の理由は Claude Code との協業 です。PMとして企画・設計・判断に集中し、実装はAIに依頼する。この開発スタイルがなければ、6プロダクトの同時運用は不可能だったと思います。
この記事では、PMとAIの協業で実践している6プロダクト並行開発の運用方法を、開発日記に残した記録をもとに共有します。
現在運用中のプロダクト
2026年2月時点で、以下の6プロダクトを並行して開発・運用しています。
| プロダクト | 概要 | ステータス |
|---|---|---|
| CancelNavi | サブスク解約ナビ | リリース済み |
| Wakulier | フリーランス向け依頼管理 | Beta版 |
| IdeaSpool | アイデア管理ツール | リリース済み |
| BandBridge | ミュージシャンマッチング | 開発中 |
| 自治会DX | 自治会業務デジタル化 | 開発中 |
| ZERONOVA LAB | ポートフォリオサイト | リリース済み |
すべて異なるドメインですが、技術スタックは共通(Next.js + Supabase)にしています。
原則:完璧主義を捨てる
最初に言っておくと、6プロダクトを「完璧に」運用することは不可能です。
CancelNaviをリリースした2025年12月18日の開発日記にこう書いています:
情報がまだ少ない状態でリリースするか、もっと情報を集めてからリリースするか。「完璧を目指すより、まずリリースして改善していく」方針を選択。
サブスク解約情報というサービスの性質上、情報の網羅性は重要です。でも、全サービスの解約情報を揃えてからリリースしようとしたら、いつまでもリリースできない。だから「ユーザーからの報告で情報を集める仕組み」を組み込んで、不完全な状態でリリースしました。
この日の日記には「情報系サービスは、最初から完璧を目指すとリリースできなくなる」とも書きました。今でもこの判断は正しかったと思っています。
仕組み1:1日で骨格を作り切る
複数プロダクトを並行開発するコツは、最初の1日で骨格を作り切ることです。
Wakulierを始めた2025年12月27日の開発日記を見返すと、1日でこれだけ実装しています:
- Next.js + Supabase プロジェクトセットアップ
- データベーススキーマ、RLSポリシー
- Google OAuth 認証
- クライアント管理、依頼フォーム、履歴ページ
- Googleカレンダー連携(空き時間取得、予定登録)
- 権限モデル(owner/member/guest)
これだけの量を1日で実装できるのは、Claude Code に実装を依頼しているからです。PMとして「フリーランスが依頼管理に必要な機能」を洗い出し、優先順位をつけて、AIに伝える。出てきた実装をレビューして修正を依頼する。このサイクルを1日繰り返すと、驚くほどの量が形になります。
翌日以降は改善に集中できるので、モチベーションを維持しやすくなります。
BandBridgeも同様に、2026年1月7日の1日でマッチングサービスの基本機能(プロフィール、バンド管理、検索、スカウト、リアルタイムチャット)をClaude Codeで構築しました。
なぜ1日で作れるかというと、技術スタックを統一していることと、AIに実装を任せてPMの判断に集中しているからです。
仕組み2:技術スタックの統一
6プロダクトすべてで同じ技術スタックを使っています。
- フロントエンド: Next.js 16 (App Router)
- バックエンド: Supabase (PostgreSQL, Auth, Storage, Realtime)
- スタイリング: Tailwind CSS v4
- ホスティング: Vercel
BandBridgeの開発日記にはこう書きました:
Supabaseは PostgreSQL + Auth + Storage + Realtime がオールインワン。個人開発でバックエンド工数を最小化できる。
実際、認証やファイルアップロードのような「毎回必要だけど面倒な機能」を一から作る必要がないので、ビジネスロジックに集中できます。
RLS first 設計
Wakulierの開発で「RLS first」というアプローチを確立しました。これもAIとの対話から生まれた設計判断です。
Zeronova
Wakulier では依頼データにクライアントごとのアクセス制御が必要になる。APIルートで毎回チェックするのは漏れが怖い。Claude CodeRLS(Row Level Security)をデータベース層で設定しておけば、APIルートでの認可チェックが不要になります。「デフォルト拒否」で設計し、必要な権限だけ付与するのが安全です。Zeronova
それならAPIルートがシンプルになるし、新しいエンドポイントを追加しても認可漏れのリスクが減る。RLS first でいこう。
開発日記にもこう書いています:
「RLS first」で設計すると、APIルートの実装がシンプルになる
この設計パターンを BandBridge でもそのまま適用して、セキュリティを担保しつつ開発速度を上げられました。一度AIと確立したパターンは、次のプロダクトでも再利用できる。これが技術スタック統一の副次的なメリットです。
仕組み3:開発日記の自動集約
6つのリポジトリに分散した開発日記を、毎日自動で1箇所に集約する仕組みを作りました。
2026年2月1日の開発日記には、この機能を作った経緯が書いてあります:
各プロダクトリポジトリで日記を書きつつ、ZERONOVA LABに一元集約したい。手動コピーは面倒なので自動化。
Claude Code で GitHub Actions ワークフローを構築しました。最初は「差分同期」と「全件同期」で迷いましたが、開発日記ファイルは軽量なので全件同期で十分と判断。実行時間は13秒程度です。
ただ、最初の実行でエラーが発生しました:
初回実行時にエラー発生(exit code 128: git clone failed)。原因: checkout ステップで REPO_ACCESS_TOKEN を使用していたが、このトークンは他リポジトリへの Read-only 権限のみで、zeronova-lab への write 権限がなかった。
これは GITHUB_TOKEN とカスタム PAT の使い分けを理解していなかったためです。checkout にはデフォルトの GITHUB_TOKEN、他リポジトリの clone にはカスタム PAT を使うことで解決しました。詳細な実装方法はGitHub Actionsで複数リポジトリの開発日記を自動集約する方法で解説しています。
仕組み4:週次レビューの自動化
開発日記が溜まってくると、どの日記に何が書いてあるか把握しづらくなります。
そこで、週次レビューも自動化しました。毎週日曜日に GitHub Actions が実行され、新しい開発日記があれば Issue を自動作成します。Issue には各日記の「記事ネタメモ」セクションが一覧表示されるので、ブログ記事にできそうなネタを見落とさずにキャッチできます。
失敗談:AIタグ付けの一貫性問題
うまくいかなかったこともあります。IdeaSpoolでAIタグ付け機能をClaude Codeで実装したとき、最初は自由にタグを生成させていました。
2026年1月19日の開発日記:
「React」「リアクト」「react.js」が混在して困った。
同じ概念に異なる表記のタグが付くと、フィルタリングが機能しなくなります。
解決策として、既存タグをプロンプトに渡して再利用を促すようにしました。また、日本語タグを強制する(英語タグ生成を禁止する)ルールも追加しました。
AI のプロンプトは「禁止」より「推奨」の方が効果的
これも日記に書いた学びです。
実際の1週間のスケジュール
参考までに、ある週のスケジュールを共有します。
| 曜日 | プロダクト | 作業内容 |
|---|---|---|
| 月 | Wakulier | 請求書機能の実装 |
| 火 | Wakulier | 請求書機能の続き、テスト |
| 水 | IdeaSpool | フレームワーク分析機能 |
| 木 | IdeaSpool | バグ修正、UI調整 |
| 金 | ZERONOVA LAB | ブログ記事執筆 |
| 土 | BandBridge | マッチング機能の設計 |
| 日 | 全体 | 週次レビュー、翌週の計画 |
基本的に2-3日連続で同じプロダクトに集中します。毎日プロダクトを切り替えるとコンテキストスイッチのコストが高くなるためです。
まとめ
個人開発で6プロダクトを同時運用するためのポイント:
- AIと協業する: PMとして判断に集中し、実装はClaude Codeに任せる
- 完璧主義を捨てる: 不完全でもリリースして改善する
- 1日で骨格を作る: AIとの協業で翌日から改善に集中できる
- 技術スタックを統一: AIとの間でパターンを再利用できる
- RLS first 設計: セキュリティをデータベース層で担保
- 開発日記を自動集約: 全プロダクトの状況を把握
- 週次レビューを自動化: 記事ネタを見落とさない
「6プロダクトなんて無理」と思うかもしれませんが、AIとの協業と仕組みさえ作れば意外となんとかなります。PMとしての判断力と、AIの実装力を組み合わせる。大事なのは、自分の役割を「全部やる人」から「判断する人」に切り替えることだと思っています。
Zeronova(ゼロノバ)
Product Manager / AI-Native Builder
Web/IT業界19年以上・20以上のWebサービスを担当したPdM。東証プライム上場企業の子会社代表として事業経営を経験。現在はAIを駆使して企画から実装まで完結させる個人開発を実践中。