SaaSは、もう作らなくていい。
導入：SaaS is Dead — 本当に？
「SaaS is Dead」。
2025年後半から、この議論がテック業界を駆け巡った。SaaS市場はグローバルで3,150億ドル超、2032年には1兆ドルに達すると予測されている。しかし、なぜ「死んだ」と言われるのか。
答えはシンプルだ。構造が変わった。
サブスクリプション型のSaaSに依存して、月額課金を払い続ける時代は終わりつつある。代わりに台頭しているのが：
- OSSベースのセルフホスティング
- AI駆動の開発ワークフロー
- Docker一発でデプロイ可能なプロダクト群
つまり、SaaSそのものが死ぬのではない。「SaaSを使う側」から「SaaSを作って自分でホスティングする側」にシフトするのだ。
そして、このシフトを加速させる最大の武器が AIとOSSのリバースエンジニアリング だ。
第1章：なぜOSSをリバースエンジニアリングするのか
SaaSの代替品はすでにOSSの中にある
従来、SNSの予約投稿ツールを使いたければ、Buffer、Hootsuite、Later… 月額$15〜$99のSaaSに契約するしかなかった。
しかし今、Postiz というOSSプロジェクトが存在する。
- 18以上のSNSプラットフォーム対応（X, LinkedIn, Bluesky, Mastodon...）
- AI搭載のコンテンツ生成
- Docker Compose一発でセルフホスト可能
月額ゼロ。しかもコードは全て公開されている。
リバースエンジニアリングの真の価値
ここで大事なのは、「Postizをそのまま使うこと」ではない。Postizの設計思想を学び、自分のプロダクトに応用することだ。
プロダクション品質のOSSを解剖することで得られるものは：
- 本番環境で検証済みのアーキテクチャパターン
- 自分では思いつかない設計判断の理由
- AIに「事例」として食わせるための極上の教材
3番目が、2025年以降の開発において最も重要だ。
第2章：Postizを解剖して見えた設計の美しさ
実際にPostizをリバースエンジニアリングした結果を共有する。
アーキテクチャ概要
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Frontend │───▶│ Backend │───▶│ Workers │
│ (Next.js) │ │ (NestJS) │ │ (Temporal) │
└──────────────┘ └──────┬───────┘ └──────┬───────┘
│ │
┌──────▼───────┐ ┌──────▼───────┐
│ PostgreSQL │ │ Redis │
│ (Prisma) │ │ (Queue) │
└──────────────┘ └──────────────┘
技術スタック:
- フロントエンド: Next.js（React）
- バックエンド: NestJS
- ORM: Prisma + PostgreSQL
- ワークフローエンジン: Temporal
- キュー: Redis
- モニタリング: Sentry
学ぶべき設計判断 3つ
1. 「リクエスト」と「実行」の分離
Postizは、投稿の「予約」と「実行」を完全に分離している：
- ユーザーがフロントエンドで投稿を予約
- バックエンドがPostgreSQLにメタデータを保存
- Temporal/Cronが指定時刻にWorkerをトリガー
- Workerがメディアを取得し、各SNSのAPIを呼ぶ
この分離により、APIが重くなっても予約UIは常に高速。スケーラビリティの教科書的な実装だ。
2. Providerパターンの抽象化
18以上のSNSを一つのインターフェースで扱うために、Providerパターンが使われている。X（Twitter）もLinkedInもMastodonも、同じ IProvider インターフェースを実装するだけ。新しいSNSを追加するとき、コア部分は一切触らなくていい。
3. Docker-Firstの哲学
docker-compose.yml 一つで、フロント・バック・Worker・DB・キューが全て立ち上がる。セルフホスティングの参入障壁を限りなくゼロに近づけている。
第3章：AIに事例を食わせる — 2026年の開発スタイル
ここが本記事の核心だ。
「学習 → 食わせる → 構築」のフレームワーク
従来の開発フロー：
ググる → Stack Overflow → コピペ → 動くまで祈る
2026年の開発フロー：
OSS解剖 → AIに構造を食わせる → パターンを理解させた上で指示 → 高品質なコード生成
この違いは圧倒的だ。
例えば、自分のSNS管理ツールを作りたいとする。AIに「投稿予約機能を作って」と言っても、汎用的なサンプルしか返ってこない。
しかし、Postizのアーキテクチャを分析した結果をコンテキストとして与えた上で「このProviderパターンに従って、Threadsの投稿プロバイダーを実装して」と指示すれば、プロダクション品質のコードが生成される。
実際にやっていること
僕自身、この手法で複数のプロジェクトを並行開発している：
- OpenClaw: パーソナルAIアシスタントプラットフォーム（マルチチャネル対応、WhatsApp〜Slack〜Discord全対応）
- AI Monsters: AIアバターによるSNS自動運用システム（Discord Bot → LLM → X投稿の全自動パイプライン）
どちらもOSSの設計を学び、AIに食わせるところからスタートした。
第4章：コスト管理の現実 — AIモデル選びの難しさ
ここで一つ正直に書いておきたい。
AIを活用した開発のコスト管理は、めちゃくちゃ難しい。
モデル選択のジレンマ
実際の開発で使うAIモデルは、タスクによって最適解が全く違う：
| タスク | 最適なモデル層 | 例 |
|---|---|---|
| コードフォーマット、リネーム | 🟢 軽量（低コスト） | Gemini Flash, Claude Haiku |
| 機能実装、バグ修正 | 🟡 標準（中コスト） | Claude Sonnet, GPT-4o |
| アーキテクチャ設計、リバースエンジニアリング | 🔴 高性能（高コスト） | Claude Opus, o1 |
軽量モデルで済むタスクに高性能モデルを使えば、トークン消費が爆発する。逆に、複雑な設計判断を軽量モデルに任せると、品質がゴミになる。
各APIを直接管理する苦しみ
OpenAI、Anthropic、Google… 各社のAPIを個別に契約・管理するのは地味にキツい：
- APIキーの管理
- レート制限の把握
- 課金の一元管理
- セキュリティの担保
第5章：OpenRouter — AI時代のハブ
ここで注目しているのが OpenRouter だ。
OpenRouterとは
各AIプロバイダーのAPIを一つの統一エンドポイントで利用できるアグリゲータサービス。
あなたのアプリ → OpenRouter → OpenAI / Anthropic / Google / Mistral / ...
何が嬉しいのか
- 統一API: エンドポイント一つで複数モデルにアクセス。プロバイダーごとの差異を吸収
- セキュリティ: 各社のAPIキーをOpenRouterが管理。アプリ側に生のキーを埋め込まなくていい
- BYOK対応: 自前のAPIキーを持ち込むことも可能（100万リクエストまでマークアップなし）
- フォールバック: あるモデルがダウンしても、自動的に代替モデルにルーティング
- 課金の透明性: プロバイダー価格そのまま（マークアップなし）+ プラットフォーム手数料5.5%
OpenClaw × OpenRouter の実験
現在、OpenClawにOpenRouterを統合するテストを進めている。
OpenClawは元々マルチAIモデル対応の設計になっているので、OpenRouterの統一APIとの相性が非常に良い。WhatsAppから質問を投げたらClaude Sonnetが答え、複雑な分析はOpusに自動ルーティングされる——そんなインテリジェントなモデル選択が実現可能だ。
結果を得たら、次の記事で詳しくレポートする予定だ。
まとめ：「SaaS is Dead」時代に生き残る方法
最後にまとめよう。
新しいゲームのルール
- SaaSに課金するのではなく、OSSを学んで自分で構築する
- OSSのリバースエンジニアリング結果をAIに食わせて、開発速度を10x化する
- 自分のインフラにデプロイする
- AIモデルのコスト管理はOpenRouterのようなアグリゲータで一元化する
X ArticlesとImmutable Publishingの可能性
そして、こうした知見を発信する場として――Xの記事機能（X Articles）がうまくハマり始めているなと最近感じる。
技術的な深掘り記事を書ける場が、SNSのリーチと一体化する。
他にはない「本質思考が集まる」場としてのXであってくれると嬉しい。
この記事が参考になったら、Xでシェアしてください。質問やフィードバックはリプライで。