Never build backends again
アプリケーションコードは安くなるが、backend ownership は消えない。次の抽象は、人と AI agent が操作できる、すでに存在する backend platform だ。
LUNO Team編集
luno.rest の編集。AI-era Backend Platform。
AI は数分でアプリケーションを組み立てられる。それでも、もう一つの backend を所有すべきだという意味にはならない。
アプリケーションコードを書くコストは下がり続ける。Backend を所有するコストは、下がらない。
そのギャップこそがミッションの理由だ。Never build backends again は、インフラを無視せよというスローガンではない。AI coding agents がソフトウェアのコスト構造を変えたあとでも ownership が残る、という結論だ。
AI coding agents
↓
アプリケーションコードが安くなる
↓
Frontend / CRUD / 統合 / glue
の生成が容易になる
↓
それでもアプリには backend が要る
↓
Auth / data / forms / storage / API / publishing /
permissions / operations / recovery
は残る
↓
AI はこれらを作り直せる
↓
だが作り直しは、なお backend ownership
↓
だから:
Backend は最初から存在するべきAI-era Backend Platform というカテゴリの定義は /blog/what-is-ai-era-backend-platform。この記事の問いは狭い——なぜ案件ごとに同じ backend を作り直し、所有し続けるのか。
AI coding agents 以前
アプリを作ることは、スタックの大部分を自分で作ることだった。
Idea
↓
Frontend
↓
Backend
↓
Database
↓
Auth
↓
API
↓
Deployment
↓
OperationsBackend 作業はプロジェクトの大きな部分だった。Auth、データ、API、運用は脇役ではなく、仕事そのものだった。
AI coding agents 以後
Idea から application code までの距離が縮んだ。
Idea
↓
AI coding agent
↓
Application codeAgent は UI、CRUD、API クライアント、バリデーション、統合コード、ボイラープレート、テスト、設定を、空のリポジトリ時代よりはるかに速く生成する。
Backend は消えなかった。
まともなアプリには、いまも認証、認可、コンテンツ/データモデル、フォーム、ストレージ、Public API、公開、Webhook、ジョブ、Activity、運用が要る。AI は足場を安くした。必要性は消していない。
なぜ AI に backend を作らせればいい、では足りないか
「認証・フォーム・メディア・API 付きのブログを作って」と頼めば、agent はその多くを実装できる。
案件をまたいで繰り返すと、こうなる。
Project A
└─ AI-generated backend
Project B
└─ AI-generated backend
Project C
└─ AI-generated backendBackend 問題は解けていない。最初の下書きを誰が書くかが変わっただけだ。
以前は人が backend を作っていた。いまは AI が backend を作る。
各プロジェクトはなお、スキーマ、auth、権限、API、マイグレーション、ストレージ、ジョブ、監視、復旧を所有する。
AI が生成したインフラも、あなたが所有するインフラだ。
AI が backend コードを書く vs AI が backend を操作する
Model A — 生成して所有する
Human
↓
AI
↓
Generate backend code
↓
You own the backendModel B — 既存を操作する
Human
↓
AI Agent
↓
Existing Backend Platform
↓
Operate backend capabilitiesLUNO が目指すのは Model B だ。
ゴールは、AI が backend を上手に作り直すことではない。作り直し自体を不要にすることだ。
Backend コードから Backend capabilities へ
Backend を「毎回書くコード」ではなく、「アプリが消費する能力」として捉える。
Application
│
├── Authentication
├── Content
├── Forms
├── Media
├── Storage
├── API
├── Publishing
└── Operations
│
▼
Backend Platform認証、コンテンツ、フォーム、メディア、ストレージ、API、公開、運用を、次のランディングページのためにまた発明する必要はない。そのプラットフォーム形状のカテゴリ論は /blog/what-is-ai-era-backend-platform。
CMS だけの話ではない
これは CMS 不要論ではない。Website → CMS は歴史的な枠の一つ。Application → backend platform の方が広い。
Content は backend そのものではない。Backend の一つの capability だ。
Forms、auth、storage、API、publishing は同じシステムに座る。CMS 棚の比較だけでは ownership の問いを外す——カテゴリ対比は /blog/luno-vs-wordpress-contentful。
Backend にはもう一人の操作者:AI
古典的な経路は application → API → backend。AI agent は、同じ正本の上にもう一人の操作者を加える。
Human
↓
Console
Application
↓
REST / API
AI Agent
↓
MCP / SDK / CLI
↓
One Backend
One System of RecordAgent は、自分専用の私的 backend を生成しない。
人、アプリ、agent が一つの system of record を共有する。MCP はその backend とやりとりする手段であり、backend そのものではない。agent 向けの経路は /blog/operate-luno-from-mcp。
API があるだけでは足りない
API はソフトウェアが backend を呼ぶ手段だ。Agent が安全に仕事を終えるには、理解できるスキーマ、予測可能な操作、バリデーション、意味のあるエラー、dry-run、影響情報、権限境界が要る。
Agent が操作できない ownership は糊コードを増やす。共有 ownership のない operability は、backend をまた増やす。
本当のコストは ownership
Backend コードを書くことは序盤のコストにすぎない。継続コストはアップグレード、マイグレーション、セキュリティパッチ、auth/権限変更、バックアップ、監視、スケール、デプロイ、障害対応、復旧だ。
AI は生成コストを下げる。Ownership コストを自動では消さない。
問題は「誰が backend を書けるか」ではない。「誰が所有すべきか」だ。
「Never build backends again」の意味
開発者が backend を考えなくてよくなる、という意味ではない。意味はこうだ。
案件ごとに、同じ backend capabilities を作り直すのをやめる。
認証、認可、コンテンツモデル、フォーム、ストレージ、API、公開、Webhook、ジョブ、Activity、運用は、繰り返し再構築するインフラではなく、消費するインフラになる。
プラットフォームが ownership を置き換えるなら、価格は編集できる人数ではなく、運用するシステムを反映すべきだ。詳細は /blog/pricing-without-seat-tax。
それでも自前 backend を作るべきとき
すべての backend が共有プラットフォームに乗るわけではない。高度に特殊なインフラ、特殊なリアルタイム系、独自の計算負荷、backend 自体がコアプロダクトである場合は、所有が合理的なことがある。
所有がプロダクトそのものなら所有を選べ。単なる繰り返しなら所有を避けよ。
Never build backends again は繰り返しについての規則であり、カスタムシステムが無意味だという主張ではない。
LUNO の位置
LUNO は、案件ごとに作り直さなくてよい backend だ。Content、Forms、Identity、Media / Storage、Public API、Publishing、Webhook、Agent access、Operations がプラットフォームの能力として存在する。
人は Console、AI agent は MCP など、アプリは API。一つの system of record。
価値は、LUNO の機能が多いことではない。組み立てて所有し直さなくてよいことだ。
AI は backend engineer を置き換えない。価値の置き場を変える——同じインフラの書き直しから、システム設計、境界、ビジネスルール、権限、信頼できる運用へ。より多くの時間をアプリケーションに残す。
結論
アプリケーションコードは安くなる
↓
インフラの作り直しの価値は下がる
↓
AI は backend を作り直せる
↓
だが作り直した backend も、所有する backend
↓
より良い抽象は、既存の backend platform
↓
アプリが消費する
人が操作する
Agent が操作する
↓
プロダクトを作る
同じ backend を、もう一度は作らないプロダクトを作れ。同じ backend を、もう一度は作るな。
ミッションの言葉では: Never build backends again.
同じ backend を Console / API / MCP で共有する設計は /blog/console-and-api-same-record。