AI時代の Backend Platform とは？

AI-era Backend Platform は、Headless CMS の言い換えでも、「AI が backend を生成する製品」でもありません。アプリケーションコードのコストは下がったのに、backend ownership のコストは下がらない——その構造差を扱うカテゴリです。

アプリコードを書くコストは下がり続ける。Backend を所有するコストは、下がらない。

そのギャップこそがカテゴリの存在理由であり、LUNO のポジショニングが Backend Platform for the AI Era である理由です。

ソフトウェアのスタックは変わった

AI coding agent は、チームが頼む仕事を変えた。「こんなサイトを作って」が、以前はフロント・糊コード・backend 組み立ての数週間を意味した。いま agent は UI、API 接続、CRUD、バリデーション、SDK、ボイラープレート、デプロイ設定の多くを短時間でドラフトする。

スタックが消えたわけではない。ボトルネックが動いた。アプリ構築は安くなり、耐久する backend 層の所有は安くなっていない。

AI はアプリケーションコードを安くする

Agent はフロント、API 統合、CRUD、バリデーション、SDK、ボイラープレート、デプロイ設定など、アプリケーション面のコストを潰す。

それでも本番で真である必要のあるものは残る。認証と Identity、認可、データ／コンテンツモデル、フォーム、ファイルストレージ、Public API、公開、Webhook、ジョブ、可観測性、監査／Activity、本番ガバナンス、復旧。

AI はソフトウェアを作るコストを下げる。信頼できる backend の必要性は消さない。

それでも backend ownership は高い

Backend ownership は「ハンドラを一度書けば終わり」ではない。スキーマのドリフト、権限ミス、壊れた公開経路、孤立したストレージ、黙って落ちるジョブ、リリースをまたいだ auth・コンテンツ・フォーム・API の一貫性のコストだ。

アプリコードが安くなるほど、案件ごとにその所有レイヤを作り直す習慣が高くつく。UI ではない。所有の問題のプロダクト言語は /blog/never-build-backends-again を参照。

なぜ AI に backend を作らせればいい、では足りないか

自然な反論は「このサイト用の backend を作って」と agent に言えばいい、だ。認証、スキーマ、API、フォーム、ストレージ、権限、公開、ジョブ、監視まで生成できる。

次の案件でもまた生成する。生成されたスタックは、レビュー・パッチ・運用判断を要する。足場の時間を、永久の再構築に換えただけだ。

Backend を消したのではない。毎回 AI に作り直せと頼んでいるだけだ。

続くミッションは「より良い backend を生成する」ではない。Never build backends again — 耐久するプラットフォームを残し、agent に操作させることだ。

Backend primitives から Backend Platform へ

BaaS 系は多くの場合、database / authentication / storage / functions などの primitives を出す。それは重要だが、agent が仕事を完遂するための backend surface と同じではない。

AI-era Backend Platform は仕事から始まる。人と agent が、案件ごとにベンダーを組み立て直さず、コンテンツ・フォーム・Identity・ストレージ・API・公開・自動化・運用を含む一つの SoR を必要とする、という前提だ。

機能戦争ではなくカテゴリ比較。Installed CMS、エンタープライズ Headless、backend primitives は最適化する仕事が違う。三点整理は /blog/luno-vs-wordpress-contentful。

CMS は能力であり、カテゴリではない

Headless CMS の中心は Content。API、Webhook、ローカライズ、メディア、編集フローはその周りに付く。

AI-era Backend Platform の中心は Backend capabilities。Content はその集合の中に、Forms / Identity / Storage / API / Publishing / Automation / Operations と並ぶ。

CMS は API 付きのコンテンツシステム。AI-era Backend Platform はコンテンツを含む backend システム。

プラットフォームを CMS と呼ぶと階層が潰れる。Content は不可欠だが、カテゴリ名ではない。

Backend は agent が操作できる必要がある

プログラマブルだけでは足りない。Agent は発見し、理解し、安全に変更し、第二の真実源を作らずに人へ戻せる backend を必要とする。

MCP は重要な agent 向け interface だ。カテゴリの定義そのものではない。AI-era Backend Platform は agent が操作できるように設計され、MCP / CLI / SDK / REST はその面にすぎない。agent 経路は /blog/operate-luno-from-mcp。

Backend はプログラマブルなだけではない。Agent が操作可能である。

API があるだけでは agent-operable ではない

多くの backend は API を持つ。それでも agent が仕事を完遂できるとは限らない。Discoverability、明示スキーマ、予測可能な操作、バリデーション、意味のあるエラー、冪等性、dry-run、影響情報、復旧可能性、権限境界が要る。

API はソフトウェアが backend を呼ぶ手段。Agent-ready な backend は、agent が理解し、操作し、安全に変更できる。

一つの backend、三つの surface

人は Console。Agent は MCP / CLI / SDK。アプリは REST。interface は違う。backend は分ける必要がない。

                 ┌──────────────┐
                 │    Human     │
                 │   Console    │
                 └──────┬───────┘
                        │
                 ┌──────▼───────┐
                 │    Backend   │
                 │ system of    │
                 │ record       │
                 └──────▲───────┘
                        │
              ┌─────────┴─────────┐
        ┌─────┴─────┐       ┌─────┴─────┐
        │ AI Agent  │       │ Application│
        │ MCP/SDK   │       │ REST/API   │
        └───────────┘       └───────────┘

Same Agent. Same MCP. Different authority boundary.

中心は一つの system of record。権限は surface と役割で変わる。データとスキーマは「agent 用」「人用」に分岐しない。

Agent の権限と本番安全

AI-era Backend Platform は「agent にもっと権限を」ではない。明示的な authority architecture を持つ、能力のある backend だ。認証、認可、人の承認、change plan、dry-run、verification、activity、復旧。

Intent
  ↓
Change Plan
  ↓
Human Approval
  ↓
Execute
  ↓
Observe
  ↓
Recover

Agent には、すべての実験を本番変更にせず、実行・観測・再試行・検査できる場所が必要になる。制御面の詳細は /blog/agent-autonomy-without-production-authority。この記事が要るのはカテゴリ要件だけ——agent 操作と本番安全を同時に成立させること。

AI-era Backend Platform の評価基準

機能数ではなく、カテゴリ適合を見る。

最後の軸が決定的だ。案件ごとに auth・コンテンツ・フォーム・公開経路を作り直すなら、カテゴリではなく部品だ。

そうではないもの

Headless CMS ではない

Content は能力であり、カテゴリではない。

BaaS のチェックリストではない

database / auth / storage API の集合が、そのまま agent 完遂向けの backend platform とは限らない。

AI コードジェネレータではない

ゴールは「AI が backend を生成する」ではない。ゴールは、backend がすでに存在し、AI がそれを操作できることだ。

LUNO の位置

LUNO はこのモデルに沿って作られている。人は Console、AI agent は MCP、アプリは REST、開発者は CLI / SDK——すべて同じ backend に接続する。

その backend に Content、Forms、Media / Storage、Public API、Publishing、Webhook、Agent operations、Governance がある。製品ラインは Backend Platform for the AI Era。CMS とフォームは内部の能力だ。

LUNO は、AI にもう一つの backend を生成させようとはしない。AI が操作できる backend を提供する。

結論

ソフトウェア構築のコストは下がる
        ↓
Backend ownership は消えない
        ↓
AI で backend を作り直すのも、やはり作り直し
        ↓
Backend は最初から存在するべき
        ↓
Agent が理解し操作できるべき
        ↓
人・Agent・アプリが同じ SoR を共有する
        ↓
それが AI-era Backend Platform

AI がソフトウェア構築を安くした。だからこそ、案件ごとに backend を作り直すのが間違ったデフォルトになった。Backend を残す。Agent が操作できるようにする。人とアプリと一つの SoR を共有する。

Never build backends again.

続くビジネスモデルの問い — なぜ席数ではなく backend を料金単位にするか — は /blog/pricing-without-seat-tax。