nadai ecosystem: 複数 micro SaaS を一人で運営する戦略

オーバーヘッドが 3 倍にならない設計を最初に組む

私は受託テックリードを本業にしながら、業務外で gpdf, gsql, renma の 3 プロダクトを並走させている。週次で OSS と SaaS の開発に使える時間は 20 時間前後で、これは 1 プロダクトに 20 時間を投じる前提では十分だが、3 プロダクトに単純に分けると 1 本あたり 6〜7 時間まで縮む。これでまともな前進を出すのは無理だ。

3 プロダクトを動かしていると言うときに、嘘をつかずに正確に書く。実際の配分は「並走 6〜7 時間 × 3」ではなく「共通基盤 5 時間 + 各プロダクトのコア作業を週単位でローテーションして 12〜15 時間」だ。共通基盤を最初に決めてテンプレ化することで、3 本目を増やしてもオーバーヘッドが 3 倍にならない構造を作っている。

主張は単純で、複数 micro SaaS を一人で並走するなら、プロダクト数に比例してオーバーヘッドが増える前提で組むと 3 本目で詰む。共通化する層と分離する層を最初に決めて、固定オーバーヘッドを定数倍で抑えられる構造にする。本稿はこの構造の現時点の姿を書く。

いまの構成: 2 系統で 3 プロダクト + 1 作者ハブ

正直なところ、3 プロダクトを「並走」と呼ぶには時間配分が偏っていて、現実には gpdf エコシステムが大半の可処分時間を取っている。それでも構造として置いている内訳はこうだ。

系統	プロダクト	技術スタック	状態	対象
開発者ツール	gpdf (本体 + api/app/cloud)	Pure Go + Tauri + Nuxt	gpdf v1.0.0 公開、派生は未リリース	B2B 開発者
開発者ツール	gsql	Pure Go	公開済 (まだ広報前)	B2B 開発者
B2C 寄り	renma	Flutter + Go API + Astro	開発中	B2C 一般ユーザー
作者ハブ	nadai.dev	Nuxt 3 + Cloudflare Pages	構築中	全プロダクトの集約

開発者ツール系 (gpdf エコシステム + gsql) は同じ Pure Go ベースで、ライブラリ層と SaaS 層が縦に積まれる。renma は完全に別系統で、共通点は API 層の言語が Go であることに留まる。

「3 プロダクトのうち 2 つは似ているのに、3 つ目だけ全然別ジャンルなのは設計ミスでは?」と言われたことがある。これは設計ミスではなく、意図した分散だと考えている。理由は後段で書く。

並走で増えるコストの正体は「認知の切り替え」

並走で時間が乗る部分は、各プロダクトのコードを書く時間より、「切り替え」に乗る部分の方がはるかに重い。

具体的には:

• 技術スタックの切り替え: Go (gpdf/gsql) → Dart (renma app) → TypeScript (renma web/nadai.dev) を行ったり来たりすると、1 言語に留まる場合に対して 30 分〜1 時間の暖機が要る。これが 1 日に複数回起きると、可処分時間の 2〜3 割が暖機で消える
• 運用窓口の切り替え: gpdf は GitHub issue が窓口、renma は将来 RevenueCat と App Store Connect、nadai.dev は Cloudflare の analytics。窓口が増えると毎日の確認動作が増える
• 書く声の切り替え: gpdf.dev/blog は B2B 開発者向け (英主)、nadai.dev/blog は作者個人 (日英並立)、renma の web は B2C ユーザー向け (日主)。3 つのトーンを行き来するのは執筆時に地味に負荷が高い

これらは個別に見ると数十分のコストだが、毎日 / 毎週積み上がる。1 本だけなら気にならないが、3 本目で「何のために週末を使ったか思い出せない」という状態になる。これがオーバーヘッドの正体だと感じている。

共通化する層、分離する層

並走の運営でいちばん重要な判断は「何を共通基盤に乗せて、何を切り離すか」だ。これを最初に決めずに走り始めると、後から共通化したい層に各プロダクトの個別事情が積み上がっていて剥がせない、という事態になる。

私の現時点の切り分けはこうだ。

共通化する層 (定数倍に抑える):

• 配信動線の入口 (nadai.dev 作者ハブ)
• 著者エンティティ (Person @id を 1 個に集約)
• 主言語 (Go を主、Dart/TypeScript は必要なところだけ)
• dotfiles と開発環境 (Claude Code 設定、エディタ、CI ベース)
• ドメイン管理 (全プロダクト Cloudflare 集中)
• デプロイ思想 (静的 + Cloudflare Pages、もしくは single binary)

意図的に分離する層 (個別事情を共通化に持ち込まない):

• ライセンス (gpdf/gsql は MIT License、renma は非公開、gpdf-api 派生は AGPL を検討中)
• 課金窓口 (gpdf-api は将来 Stripe、renma は RevenueCat)
• サポートメールアドレス (プロダクトごとに分離)
• ローンチのタイミング (1 本ずつずらして注目を分散させない)
• GitHub 組織 (1 プロダクト = 1 組織。詳細は次節)

ここで「主言語を Go に揃える」は重要な共通化だ。renma の app 層は Flutter なので Dart が要るが、API 層を Go にしたのは「gpdf エコシステムと同じ言語で書ける」を最大化するためで、純粋な技術選定だけなら Node.js でも構わなかった。共通言語を Go にすることで、gpdf を書く脳の状態のまま renma の API も触れる。これは性能や生態系の話ではなく、認知コストの圧縮だと思っている。

集客動線は作者ハブに集約する

複数プロダクトを持っているなら、配信動線を作者ハブに集約するのが最適だと考えている。各プロダクトサイト (gpdf.dev 等) は買い手向けの声で書き、作者個人の声は nadai.dev に集約する。これは単純な SEO 設計ではなく、信用の貯金構造だ。

	プロダクトサイト (gpdf.dev)	作者ハブ (nadai.dev)
主語	プロダクト	作者
検索意図	機能・FAQ・ベンチ・購入検討	設計判断・物語・経歴
言語	英語主	日英並立
例	"How to embed Japanese fonts in gpdf"	現在地の棚卸し / なぜ Pure Go なのか

なぜ集約が効くかというと、AIO (Perplexity / ChatGPT search / Claude / Gemini) が「同一エンティティとして引用する」基準は、同じ Person @id に紐付いた一次ソースの蓄積だからだ。プロダクトサイトをいくつ作っても、author entity が分散しているとこの蓄積は 1 個のプロダクトに閉じる。nadai = 複数 micro SaaS を並走している人 というラベルを 1 箇所に貯めることで、4 本目を出すときに 1 本目から積み上がった信用が効く。

これは机上の理屈ではなく、nadai.dev の JSON-LD でも明示的に組んでいる。Person @id を https://nadai.dev/#person で固定して、各プロダクトの author をそこに参照させる。GitHub 組織 nd-forge は sameAs で紐付ける。これで AI から見たエンティティ階層が一意に確定する。

逆に、author entity が分散している状態は、複数プロダクトを出している割に「点で評価される」状態だ。1 個ずつのプロダクトの star 数や issue 数で判断されることになり、複数並走している事実そのものが信用要素にならない。これはもったいない。

1 GitHub 組織 = 1 プロダクトにする理由

並走の運営で意外と効くのが GitHub 組織の切り分けだ。私は 1 プロダクト = 1 組織 にしている。具体的には:

• nd-forge (作者ハブ組織): 横断ライブラリ・ツール群 (errx, stream 等)
• gpdf-dev: gpdf 本体・LP・周辺ツール
• gsql-dev: gsql 関連
• taiki-nd (個人): 個人実験・dotfiles のみ。業務的なリポジトリは置かない

理由は 3 つある。

1 つ目、売却・譲渡の柔軟性。Acquire.com で OSS を売る場合、組織丸ごと譲渡できると履歴・stars・issues・PR が綺麗に残る。リポジトリ単位の譲渡だと買い手側の手続きが増える。私はまだ売却を視野に入れる段階ではないが、3 年後にどれかが当たって譲渡を考える可能性は十分にある。そのときに組織が分かれていれば判断が単純化する、という時間軸の話だ。

2 つ目、権限分離。コラボレーターや契約者を特定プロダクトのみに招待できる。個人組織に全部入れているとアクセス権限の事故が起きやすい。

3 つ目、エンティティ階層との一致。gpdf.dev ↔ github.com/gpdf-dev で人間も AI も認識しやすい。schema の parentOrganization と GitHub の物理構造が揃うので、ナレッジグラフとして組みやすい。

GitHub Free org は無制限に作れるので、コストはゼロだ。Private repo の Actions 分数や Packages 容量は組織単位で別カウントなので、Open Core 設計 (公開コア + 最小 private) なら無料枠で十分回せる。

組織名 nd-forge をハイフン付きにしているのは、github.com/nd-forge/errx のような Go モジュールパスを変更すると下流ユーザーへの破壊的変更になるためだ。ドメインは nadai.dev (覚えやすさと作者ブランド)、組織名は nd-forge (技術基盤の不変識別子)、と用途を分けている。これらは schema の sameAs / alternateName で紐付けてある。

系統を意図的に分散させる

私の構成で 1 つだけ「効率」では説明できない判断があって、それが renma の存在だ。gpdf エコシステムだけで回せば、技術スタックも顧客像も揃って、認知コストはもっと低い。それでも renma を別系統で持っているのは、リスクの分散だ。

個人開発で 1 系統に賭けると、その系統が当たらなかったときに残るものが少ない。Go の OSS / 開発者ツールという系統は技術的には強いが、市場としては「狭く深い」タイプで当たり外れの分散が大きい。一方 B2C の筋トレアプリは「広く浅い」マーケットで、当たれば中規模、外れても下限がある。性質の違うマーケットに分散させておけば、片方の振れ幅をもう片方が吸収する。

これは「分散投資すれば 2 倍当たる」という話ではない。「片方が 0 になっても、もう 1 系統が残る」という生存設計だと思っている。実際、gpdf 系統が 4 ヶ月で MRR ゼロのまま頭打ちになる可能性は十分ある。そのとき renma 側で別の経験線が積み上がっていれば、判断のオプションが増える。

ただし、分散しすぎると認知コストの方が分散の利得を食う。私の経験則だと一人で持てるのは 2 系統が上限で、3 系統は無理だと感じている (3 つ目を増やすと 1 つ目が枯れる)。私はいま、この上限の手前にいる。3 つ目を増やしたい衝動が来ても、たぶん我慢する。

1 つの実例: gpdf-api を出す段でハブから降りてきた決定

これは抽象論ではなく、最近の具体例で書いておく。

gpdf-api を出すにあたって、課金プランをどう設計するかを 2 週間悩んだ。素の発想だと「Free / Pro / Enterprise の 3 tier」で、これは GitLab モデルから自然に出てくる形だ。一方で renma 側はすでに「Free / Pro / Cloud」の 3-tier を Flutter + RevenueCat で組んでいて、こちらは B2C 寄りなので Cloud tier の意味合いが違う。

ここで「両プロダクトのプラン名を揃えるか、分けるか」という選択が出てきた。揃えると nadai.dev のプロダクトページで横並びにしたときに認知コストが下がる。分けると、各プロダクトの料金表を見比べる人が混乱する可能性がある。

最初は「nadai 全体で Free / Pro / Cloud に揃える」案で書きかけた。揃えれば確かに見た目は綺麗になる。しかし途中で気づいた。Pro という同じ単語が、開発者向け SaaS と B2C アプリで意味する内容が全然違う。B2B の Pro は「商用利用 + 認証 + SLA」、B2C の Pro は「広告非表示 + 高度な計算機能」だ。共通化を優先して名前だけ揃えると、両方のユーザーが期待値とのズレを感じる。

だから揃えなかった。プラン名は各プロダクトの市場慣習に合わせ、揃えるのは「料金表のデザインテンプレート (= プラン名は違うが見た目は揃っている)」までに留めた。あの 2 週間で得たのは、書き出してみると拍子抜けするほど凡庸な学びで、共通化の誘惑は具体例ごとに毎回判定し直すしかない、それだけだった。

ただ、この決定を踏み外さずに済んだのは、最初に「共通化する層」と「分離する層」を切り分けていたからだ。プラン名は分離側 (個別事情に従う) に最初から振っていたので、揃えたくなったときに「ルールに反する」と気づけた。最初の切り分けがなかったら、たぶん揃えていた。

反論への応答

「並走は分散投資ではなく分散疲労の言い換えでは?」

半分そのとおりで、認知コストは確実に増える。だから「3 系統は無理」と書いた。ただし全部 1 系統に賭けるリスクは、認知コストよりも長期的に大きい。1 系統で当たらなかったとき、残るのが 1 つの撤退だけになる。2 系統あれば、片方を畳んでもう片方を続ける、という選択肢が残る。これは投資ではなくオプションの話だ。

「それ、結局 gpdf に時間かかってて renma 動いてないのでは?」

そのとおりで、現時点では gpdf エコシステムが時間の 7〜8 割を取っている。renma は週末に数時間動かす程度の進捗で、これは 2026 年内に出る予定で考えていない。並走を成立させているというより、「並走の構造を組みつつ、いまは 1 つに寄せている」が正確な表現だと思っている。renma の優先度を上げるのは gpdf-api をリリースした後で、それまでは「枯らさない最低限」を維持する方針でいる。

「全部 Go で揃えればもっと共通化できるのでは?」

renma の app 層は Flutter で、これだけは Go で書けない (B2C のスマホアプリで Go single binary はリーチが足りない)。API 層を Go にして共通化したのが現実解だ。「全部 Go」を追求すると別ジャンル分散の利得を失う。共通化と分散はトレードオフで、私は後者を優先した。

次のステップ

ここまでが 2026 年 5 月時点の nadai 運営構造だ。各論はこれから書いていく。

• 現在地の棚卸し (= この記事の前提): Pure Go の micro SaaS を兼業で出している現在地
• 時間設計の詳細: 受託テックリード兼 OSS 開発者の時間設計
• gpdf 設計判断の物語: Pure Go で 0 dependency の PDF ライブラリを作った話
• gsql 設計判断: gsql API 設計: GORM / sqlx / squirrel との差分
• ライセンス選択の判断軸: MIT で出した経験から、次の派生 SaaS で AGPL を検討している理由

「3 系統に増やすかどうか」は半年後にもう一度書き直すかもしれない。3 つ目を増やしたい衝動が来たときに、過去の自分が何を書いていたかを読み返せる場所として、この記事を置いておく。