← Blog 一覧へ
Company

Never build backends again

アプリケーションコードは安くなるが、backend ownership は消えない。次の抽象は、人と AI agent が操作できる、すでに存在する backend platform だ。

LUNO Team編集

luno.rest の編集。AI-era Backend Platform。

Never build backends again

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
 ↓
Operations

Backend 作業はプロジェクトの大きな部分だった。Auth、データ、API、運用は脇役ではなく、仕事そのものだった。

AI coding agents 以後

Idea から application code までの距離が縮んだ。

Idea
 ↓
AI coding agent
 ↓
Application code

Agent は 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 backend

Backend 問題は解けていない。最初の下書きを誰が書くかが変わっただけだ。

以前は人が backend を作っていた。いまは AI が backend を作る。

各プロジェクトはなお、スキーマ、auth、権限、API、マイグレーション、ストレージ、ジョブ、監視、復旧を所有する。

AI が生成したインフラも、あなたが所有するインフラだ。

AI が backend コードを書く vs AI が backend を操作する

Model A — 生成して所有する

Human
  ↓
AI
  ↓
Generate backend code
  ↓
You own the backend

Model B — 既存を操作する

Human
  ↓
AI Agent
  ↓
Existing Backend Platform
  ↓
Operate backend capabilities

LUNO が目指すのは 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 Record
Agent は、自分専用の私的 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。

ほかの投稿