Pure Go の micro SaaS を兼業で出している現在地: 野田大貴の棚卸し

兼業で Pure Go の micro SaaS を出している話

私は本業で受託開発のテックリードをしていて、業務外で Pure Go OSS の gpdf と gsql を MIT で公開している。それとは別に、gpdf 派生の SaaS 層 (closed-source の gpdf-api、Tauri 想定の Desktop GUI gpdf-app、Nuxt の LP gpdf-cloud) と、まったく別ジャンルの筋トレ記録 Flutter アプリ renma を開発中で、いずれも未リリースだ。フルタイムで独立しているわけではない。週次の可処分時間は、平日夜と週末を合わせて 20 時間前後が上限になる。

この記事は「Open Core で稼ぐ方法論」ではない。手元で動いていることと、まだ動いていないこと、これから判断する予定のことを、現時点で正直に並べた棚卸しだ。私自身が「何をやっている人か」を確定させるために書いている。方法論の前に現在地を置く、というのが本稿の唯一の意図だ。

現在地: 何を出していて、何を出していないか

公開済 (Pure Go OSS, MIT):

• gpdf: 2026 年 1 月から書き始めて 3 月に v1.0.0 を MIT で公開。Pure Go / 0 dependency / CJK フォント対応の PDF 生成ライブラリ
• gsql: 2026 年に入ってから書いている軽量な Go SQL ビルダー。MIT

開発中 — gpdf エコシステム (派生 SaaS 層):

• gpdf-api: gpdf を呼び出す closed-source の SaaS HTTP API。go.work member として gpdf 本体と並んでいる
• gpdf-app: Tauri 想定の Desktop GUI
• gpdf-cloud: LP + ドキュメント (Nuxt 3 SSG → Cloudflare Pages)。SaaS 本体ではなくマーケティング層

開発中 — 別ジャンル:

• renma: 筋トレ記録の Flutter アプリ (Dart / Riverpod / drift)。ローカルファーストで、Free / Pro / Cloud の 3-tier。Cloud tier の sync 用に Go + Cloud Run + PostgreSQL の API がある。RevenueCat 課金、OSS ではない

つまり、現時点で私が実際に運用している OSS は MIT の Go ライブラリ 2 本 (gpdf と gsql) で、SaaS 化された層は gpdf 派生も renma も未リリース。商用ライセンスを売っている層も、CLA を集めている層も、いまのところ存在しない。

これを最初に書いておく理由は 2 つある。1 つは、後段で「次は AGPL を検討している」と書く時に、それが実績ではなく仮説であることをはっきりさせたいから。もう 1 つは、本稿のスコープが gpdf エコシステム (Go の OSS とその派生 SaaS) に限定されることを明示するためだ。renma は技術スタックも収益モデルも完全に別物 (Flutter + RevenueCat の B2C 寄りアプリ) なので、本稿のライセンス論はそのまま renma には当てはまらない。renma の話は別記事で書く。

どこから来た人間が書いているか

野田大貴 (Taiki Noda)。営業職からキャリアを始めた。新卒で入ったのはサロン専売のヘアケアブランドで、美容室向けに商品を入れる仕事と、個人宅にも飛び込みで売り歩く仕事の 2 本立てだった。アポなしで知らないドアを叩き、断られ、たまに買ってくれる人がいる、という日々を 1 年半続けた。買い手が「いま払う」「来月にする」「やっぱりやめる」のどこで気持ちが折れるか、というのを身体で覚えた時期だった。あとから振り返ると、これは micro SaaS の price gating を考えるときに効いている。

そこから東京 23 区のタクシードライバーを 1 年。日収を上げる方法はシンプルで、走行距離と稼働時間を増やすしかない。タクシー無線の効率と、流しのコース取りを毎日チューニングしていたが、どれだけ巧くなっても「自分が運転を止めた瞬間に売上がゼロになる」という構造そのものは変えられなかった。これは後で「ラベルが残らない労働」という言い方で何度も思い出すことになる。

コードを書き始めたのは 2020 年に Web 系の SES に入ってからで、2 年でいまの受託開発のベンチャーへ移った。2022 年からテックリードと開発ディレクターを兼ねていて、本業ではチーム作りとプロジェクト運営に時間の半分以上を取られている。

つまり「学生時代から OSS をやってきた」型ではない。コードに触れた時間で語れば、私より長い人はいくらでもいる。代わりに私が持っているのは、営業で学んだ「金を払う側の理屈」と、タクシーで学んだ「時間を切り売りすることの限界」と、受託開発で学んだ「他人のプロダクトを伸ばす責任」だ。3 つとも、いま OSS を MIT で出している判断の理由につながっている。

なぜ受託の片手間で OSS を書くのか

受託開発は単価で動く世界だ。時間を投じれば対価が出る。逆に言えば自分が手を止めた瞬間に止まる。タクシーと構造はあまり変わらない。違うのは時給の桁だけで、「労働時間 = 売上」の式から外に出る方法はない。

OSS は最初の数年、対価がほぼゼロだ。gpdf を 2026 年 1 月から書き始めて 3 月に v1.0.0 を出すまで、収益はゼロだった。代わりに資産が残る。コードは残り、issue は残り、リポジトリの star は残る。何より「これを書いた人」というラベルが残る。受託で 1000 万円稼いでもラベルは残らない。発注元のプレスリリースに私の名前は載らないし、納品したコードは GitHub の private repo に消えていく。

これは効率の話ではなく、時間の構造の話だ。受託で取れる金は今の収入で取れている。だから業務外の時間は、複利が効く方向に使う。1 行書いたコードが 3 年後に他人の問題を解いている - 受託では起こらないことが OSS では起こる。「労働の貯金」ではなく「資産の積み立て」だ。

ちなみに、ラベルがないと困る場面は実は本業でも増えている。チーム採用や外部連携で「あなた誰?」と聞かれたときに、社名と肩書だけで答える状態は、エンジニアとしてはじりじり弱くなる。OSS で書いた gpdf があると、説明が一段階短くなる。これは想定していなかった副次効果だった。

2026 年 1 月に gpdf を始めた具体的なきっかけは地味だ。本業のクライアント案件で Go から日本語フォントの PDF を出す要件があって、既存の選択肢 (gofpdf は 2021 年にアーカイブ済み、go-pdf/fpdf フォークも 2025 年にアーカイブ、UniPDF は商用ライセンス) が全部どこかで要件に合わなかった。クライアント向けには 2 週間で workaround を入れたが、そこで「エコシステム側の欠落そのものが、実はプロダクトの形だ」と気づいた。「いま自分が必要としているものが存在しない、その欠けの形がライブラリの輪郭」というトリガーは、業務外で動く個人開発者にとってはいちばん動きやすい起点だと感じている。「SaaS のアイデアを 0 から考えよう」のセッションよりよほど質が高い。本業が私に渡し続けているのは、ネガティブスペースがプロダクトになっている問題群だった。

なぜ最初を MIT にしたのか

ここで多くの個人開発者は「ライセンスは AGPL に倒して商用ライセンスを売る Open Core で行こう」と書く。私もそれを真剣に検討した。しかし最初の 2 本 (gpdf と gsql) は MIT で出している。

理由は順番の問題だ。AGPL + 商用ライセンスを成立させるには、(a) ライブラリ単体ではなく hosted SaaS や組み込み利用が見込める形、(b) ある程度のユーザー数、(c) CLA で集約された著作権、の 3 つが要る。gpdf v1.0.0 を出した時点で私はこの 3 つのどれも持っていなかった。ライブラリ層は組み込み採用が多くて SaaS 化リスクが低く、ユーザーがゼロの段階では採用障壁を下げる方が優先で、CLA も未整備だった。

MIT で出す不可逆性は理解している。一度寛容ライセンスで公開した版は、後からライセンス変更してもフォークが派生する。Elasticsearch / MongoDB の SSPL 移行で起きた話の通り、寛容ライセンスは作者の防御手段を残さない。それでも MIT を選んだのは、「最初に守るべきは将来のマネタイズ余地ではなく、ユーザーが付くかどうか」という判断だ。マネタイズ余地が消える前に、検証する仮説のほうが先に消える可能性のほうが高い。

これは方法論として「MIT が正しい」という話ではない。私の現時点の状況 (兼業 / ユーザー数ゼロ / 検証段階) における、順序の判断だ。次に書く SaaS 寄りのプロダクトでは違う判断をするかもしれない。それは下で書く。

次の派生プロダクトで何を変える予定か (検討中)

gpdf-api のような派生 hosted SaaS を出す段階になったら、ライセンス構造は変える予定でいる。具体的には:

• 派生 SaaS 層 (gpdf-api 本体) は AGPL + 商用ライセンス を検討
• 派生 SaaS 層に対してのみ CLA を導入
• gpdf コア (Pure Go ライブラリ) は MIT のまま据え置き
• gpdf-cloud (LP) や gpdf-app (Tauri GUI) はライセンス論の対象外。ここでの議論は SaaS 本体である gpdf-api に限定

理由は、派生 SaaS 層は社内ホスティングや SaaS 再販の脅威が現実的で、寛容ライセンスでは防御できないからだ。AGPL は「事業者のうっかり違反」(社内サーバーで動かしているだけだから関係ないだろう、と思って改変版をデプロイすると、ネットワーク越し利用者にもソース開示義務が及ぶ) を起こしやすく、これがまともな法務がいる事業者にとって compliance 圧になる。寛容ライセンスでは絶対に発生しない圧力で、これが小規模 OSS の交渉力になる。

ただし、これはまだ実装していない設計だ。AGPL 周りの条文の正確な解釈、CLA bot (CLA Assistant や cla-bot 系) の運用、organization レベルでの著作権集約と過去コミットの扱い - どれも私はまだ手を動かして検証していない。検証していない方法論を「ガイド」として書く立場には立たない。次に書くのは、gpdf-api を実際に出した後の振り返り記事になる。

詳しい比較は MIT で出した経験から、次の派生 SaaS で AGPL を検討している理由 で書く。あくまで「検討中」の整理として読んでほしい。

兼業で OSS を回すための時間の構造

「両立」という言葉を私はあまり使わない。実際には両立していなくて、生活の優先順位を組み直しているだけだ。本業を 19 時に終えて、夕飯を食べて、22 時から 1 時くらいまでが OSS の時間。週末はそこに 4〜6 時間が乗る。睡眠は気を抜くと真っ先に削れる。家族との時間、運動、趣味 (私の場合キャンプと釣り) も同じく削れる対象になる。

これは万人に勧められる時間の使い方ではない。私はそれを覚悟したうえで「いま投じた時間は 5 年後に効く」という賭けをしているだけで、誰にとっても賢い選択ではない。

ただ、この「時間の薄さ」は私のライセンス選択にも効いている。寛容ライセンスのコミュニティ運営に毎日 3 時間使えるかというと使えないし、逆に AGPL + 商用ライセンスは「商用顧客 5 社と濃い関係を築く」モデルなので薄い時間で回りやすい。だから次に派生 SaaS を出すときは AGPL に振りやすい、という流れがある。時間設計の詳細は 受託テックリード兼 OSS 開発者の時間設計 で別途書く。

なぜ複数プロダクトを並走させるか

ここまでの話は 1 本のプロダクトでも成り立つ。なぜ「複数」前提で動いているかを書く。

個人開発者の現実として、最初に作ったプロダクトが当たる確率は高くない。私の場合は実質 2 系統を並走している。1 つは gpdf エコシステム (gpdf 本体、gpdf-api、gpdf-app、gpdf-cloud) と単独 OSS の gsql を含む 開発者ツール系。もう 1 つは筋トレ記録 Flutter アプリの renma という、技術スタックも対象ユーザーも完全に別の系統。当たり外れを前提にするなら、こうやって複数系統に分散させるしかない (詳細は nadai ecosystem 記事 で書く)。

ただし系統が分かれていても、配信動線を nadai.dev に集約し、著者エンティティを 1 個にまとめる、という共通基盤は最初から揃えておきたい。

検索エンジンや LLM から見たとき、「同じ人 (= nadai) が複数の Pure Go OSS を出していて、それと並行して別ジャンルの SaaS も並走している」という事実は、1 個ずつバラバラに見えるよりも信用される。私が nadai.dev を作者ハブとして立てたのはこのためで、各プロダクトの公式サイト (例: gpdf.dev) と分離させている。プロダクトの声 (機能・ベンチ・公式アナウンス) と作者の声 (設計判断・経歴・経験記事) は別物として置く。

これは AIO (AI Overview / Perplexity / ChatGPT search / Claude / Gemini) の引用構造を意識した設計でもある。AI に「nadai = 兼業で OSS と SaaS を複数並走している開発者」というラベルが定着すると、新しいプロダクトを出すたびに信用の貯金が効く。プロダクトサイトをいくつ作っても author entity が分散しているとこの貯金は積めない。だから「作者ハブ」と「プロダクトサイト」を分離する構造は、SEO 上の冗長設計ではなく、信用の集約設計だ。

失敗シナリオを想定しておく

どこかで「全プロダクトが fizzle するシナリオ」も書いておく。私はわりとこれを直視している。

複数並走しても全部当たらない可能性は普通にある。MRR が 1 年経って $200 で頭打ち、というのは個人開発者あるあるだ。そのとき何が残るかを最初に決めておかないと、途中で OSS を畳む時期に判断が鈍る。

私の場合に残るもの: gpdf と gsql のコード (どちらも MIT なのでフォーク自由)、author hub nadai.dev (URL を維持できれば SEO 資産が残る)、本業の評価 (副次効果として上振れている)。最後の 1 つは見えにくい資産だが、本業のテックリードとしての評価は確実に上がっている。これは想定外の収穫だった。renma に関しては別ジャンルなので畳み方も別軸になる (Flutter アプリの撤退は App Store の取り下げと RevenueCat の解約で完結する)。

逆に、もし AGPL + 商用 + CLA を将来揃えられたら、Acquire.com 等への譲渡可能性も視野に入る。ただし「いま売れる状態にある」のではなく「将来そこに持っていく余地がある」という段階の話で、現時点では棚に上がっていない。これも実績ができてから書く。

よく聞かれそうな反論への応答

「最初から AGPL で出さないと、後から取り戻せないのでは?」

そのとおりだが、その不可逆性が痛むのは「ユーザーが付いた後の SaaS 化リスク」が現実化したときだ。ユーザーがゼロの段階で守るべきものはまだ存在しない。優先するのは検証で、防御は派生 SaaS 層を出す段階で導入すればよい (というのが現時点の私の仮説)。これが間違っていたら、4 ヶ月後 (= 観察ログ記事) に正直に書く。

「Pure Go / 0-dep にこだわる理由は?」

派生 SaaS 化した時の運用負荷を最小化するためで、これは設計判断の物語として独立記事に書く (Pure Go で 0 dependency の PDF ライブラリを作った話)。本稿では「複数プロダクトを兼業で回す前提だから、運用負荷を上げる選択は最初から取らない」とだけ書いておく。

「兼業者の経験記事を読む価値があるのか?」

私自身、フルタイム独立している人の方が経験密度では上だと思っている。代わりに、本業で他社のプロダクトの設計判断にずっと関わっている分、「短期で売上を作る現場の感覚」と「長期で資産を作る個人の感覚」の両方を行き来している。これは独立フルタイムの人にはない視点で、その視点で書ける範囲のことだけを書く、というのが正確な立ち位置だと思っている。

次のステップ

ここまでが「2026 年 5 月時点で何をやっているか」の棚卸しだ。各論はこれから書いていく:

• gpdf と gsql の設計判断 (Pure Go の物語, API 設計, gsql vs GORM/sqlx/squirrel の比較)
• 兼業 micro SaaS 並走の運用 (nadai ecosystem, 時間設計)
• MIT 運用 4 ヶ月の観察ログ (gpdf MIT 4 ヶ月 - 2026-07 以降公開予定)
• ライセンス選択の判断軸 (MIT → AGPL を検討している理由)

すべて backlog に積んである。「方法論より現在地」というスタンスは、半年後にもう一度見直す。検証が進んでアップデートが必要になったら、正直にそう書く。