2026/07/07
AI × StackPage 自動化・プラットフォーム化ロードマップ

背景

AI × StackPage 自動化・プラットフォーム化ロードマップ

Status: proposal
関連：../platform/stackpage-guidebook.md（§2 できる/できない、§10 宣言vsコード、§11 AI連携）、10_estate_ai_page_builder_spec.md
AI で「page-builder でできない部分（結果依存UI・検証・保存・採番・メール・新部品・複雑非同期）」をどこまで補完・自動化できるか、そしてプラットフォーム/サービス化に向けた段階計画と**各Phaseの受け入れ条件（検証ゲート）**を定義する。

0. テーゼ（設計の背骨）

宣言境界＝安全弁であり堀。 AI の役割を段階的に広げるが、常に次の規律を守る：

  1. Draft-first：AI は下書き/PR のみ生成。自動公開・自動マージしない。
  2. 検証ゲート必須：AI生成物は自動検証（型/lint/schema/build/契約テスト）を通過して初めてレビュー対象。
  3. Human-in-the-loop：金額・PII・認証・トランザクションは人間サインオフ必須。
  4. 既存契約の尊重：新schema/新ランタイム挙動を勝手に発明しない。拡張は語彙（action/datasource/部品）を明示的に増やす形で行う。
AI codegen の価値は「どれだけ自動検証できるか」に比例する。よって本ロードマップの中核は「検証ハーネス」への投資。

1. 補完対象と現実性（3層）

層 内容 AI補完 現実性 主ゲート
L1 宣言配線 既存 endpoint/datasource への binding/__interactions/emit-request 生成 ◎ 既存 schema検証・プレビュー
L2 新部品 React部品＋__schema＋_componentDesc＋default＋登録 生成 ○ §3 契約テスト＋build
L3 複雑ロジック datasource/endpoint/service（保存・検証・採番・メール・Tx） 生成 △〜○ §4 テスト＋人間承認
最短の効き手＝L1の語彙拡張（結果ハンドリング付き emit-request 等）。コード無しでAIの合成範囲が広がる。

2. フェーズ・ロードマップ（受け入れ条件つき）

Phase 1 — AIページビルダー堅牢化（現状の延長）

既存の POST /ghost/api/admin/ai/pages/from-prompt（draft-first, schema/event-only）を運用品質へ。
スコープ

  • ページテンプレート（賃貸/売買/投資/LP）の拡充。
  • マルチテナント（TENANT_UID）での分離。
  • 生成結果の自動検証（schema妥当性・binding整合・プレビュー描画）。
    受け入れ条件（Phase Gate 1）
  • [ ] 生成ページは既存部品・datasource・イベントのみ使用（新schema/新部品0）。
  • [ ] 生成JSONが StackPage スキーマ検証（AJV）を100%通過。
  • [ ] binding キーが対象部品の期待propと一致（自動チェック）。
  • [ ] /pages/view でエラー0・console error 0 で描画（スモーク）。
  • [ ] draft のみ・レビューリンク返却。自動公開なし。
  • [ ] 4テンプレ×代表プロンプトで回帰スイート緑。

Phase 2 — AIコンポーネント・ジェネレータ（L2）

NL仕様から StackPage 規約準拠の新部品を生成 → 検証 → PR。
パイプライン

NL仕様 → AI生成:
packages/business/estate/src/<Name>.tsx
+ Props interface + __schema + _componentDesc + 既定props(サンプル入り)
+ index.ts への登録(EstateComponents / EstateDefaultProps)
→ 検証ゲート(§3) → 合格のみ PR(人間レビュー)

受け入れ条件（Phase Gate 2） = §3 契約テスト全項目＋

  • [ ] yarn --cwd apps/host typecheck / yarn --cwd packages/business/estate build 緑。
  • [ ] __schema が AJV 妥当（format:"textarea" 不使用、画像は x-media-type 等の規約遵守）。
  • [ ] 既定 props に空でないサンプル配列を含む。
  • [ ] 生成部品は新ランタイム契約を追加しない（既存 StackPageRuntimeApi/state/eventのみ）。
  • [ ] 人間レビュー承認後にのみ merge。

Phase 3 — AIロジック/エンドポイント・ジェネレータ（L3）

NL仕様から datasource/host route/Ghost endpoint をテスト付きで生成 → PR。
スコープ例：「Xを保存しYへ通知するendpoint」「Zを返す datasource」。
受け入れ条件（Phase Gate 3）

  • [ ] 生成コードにユニット/統合テストが付随し緑（vitest）。
  • [ ] 公開ルートは許可リスト方式（生 filter/status/key を転送しない）。
  • [ ] 破壊的操作・金額・PII・認証は人間サインオフ必須（PR に警告ラベル）。
  • [ ] メール/外部送信は fire系でも結果記録＋ログ、失敗が保存を壊さない。
  • [ ] typecheck/build:estate/test 緑。自動デプロイなし。

Phase 4 — セルフサーブ・プラットフォーム（サービス化）

マルチテナントのAIサイトビルダーとして事業化。
スコープ

  • テナント分離（データ・部品カタログ・課金）。
  • AI下書きレビュー・承認コンソール（ページ/部品/endpoint を統一UIで承認）。
  • ガードレール監査ログ（誰が何を承認・公開したか）。
    受け入れ条件（Phase Gate 4）
  • [ ] すべてのAI生成物が承認コンソール経由でのみ公開。
  • [ ] テナント間データ/権限の完全分離（テスト）。
  • [ ] 監査ログ・ロールバック。
  • [ ] SLA/コスト（トークン）計測。

3. コンポーネント契約テスト仕様（Phase 2 の中核）

全 StackPage 部品（AI生成/人手問わず）が通す標準ハーネス。これが自動化の土台。
必須項目

  1. 描画（default props）：既定propsでレンダリングし throw しない・console.error 0。
  2. 描画（binding）：datasource相当のサンプル items を注入して一覧描画（properties/slides/items）。
  3. schema妥当性：__schema が AJV で妥当。全 user-editable prop を網羅。禁止事項（format:"textarea"）不使用。画像propは format:"uri"＋x-media-type:"image"。
  4. _componentDesc：存在し t(...) 経由の翻訳キー。
  5. 既定props現実性：配列propは空でなくサンプルレコードを含む。
  6. レスポンシブ：狭幅（例 375px）で overflow せず reflow（スナップショット or レイアウト検査）。
  7. state/event規約：使用するstateキーは規約（ESTATE_STATE_KEYS）、イベントは domain:entity:action。
  8. runtime契約不変：StackPageRuntimeApi 以外の新契約を要求しない。
    実行：vitest にハーネスを追加し、全部品を parametrized で回す（EstateComponents/EstateDefaultProps を総なめ）。

4. AIロジック生成のガードレール仕様（Phase 3）

  • 分類ラベル：生成PRに safe / needs-signoff（金額/PII/認証/破壊的）を自動付与。
  • テスト強制：endpoint生成時はハッピーパス＋失敗系（不正入力・権限・外部失敗）テストを同梱。
  • 公開ルール：公開プロキシは許可リスト・鍵サーバ注入・下書き漏洩防止（既存 properties-public 準拠）。
  • 副作用の非ブロッキング：メール等はトランザクション後・非同期・結果記録（metadata.notifications パターン）。
  • 冪等・再試行：採番はunique＋衝突再生成、再送は回数上限（reference_code/resend の既存パターン）。

5. プラットフォーム/サービス化（提案）

5.1 プロダクト形態

  • 不動産特化 SaaS：物件データ投入/接続 → AI がサイト構築・維持（一覧/詳細/問い合わせ/担当者連携）。
  • ホワイトラベル/マルチテナント：共有部品＋Ghost基盤上に各社サイト（TENANT_UID）。
  • 承認コンソール：AI下書き（ページ/部品/endpoint）のレビュー・承認・公開を一元化。

5.2 勝ち筋（アドバイス）

  • 縦（不動産ドメイン）に集中。物件/担当者/問い合わせ/REINS/検索index/メディア基盤というデータ＆ドメイン資産が堀。AIビルダーは差別化層。
  • 検証ハーネスが競争優位：AIの品質＝自動検証の質。
  • 宣言境界を崩さない：AIは合成、ゲートで担保、人間が承認。
  • 無人で業務ロジックを公開しない：半自動＋人間承認。

5.3 リスクと対策

リスク 対策
AI生成コードの品質/セキュリティ 契約テスト・型/lint/build・PRレビュー・safeラベル
業務ロジック誤り（金額/法務） 人間サインオフ・テスト・下書き限定
保守ドリフト（乱造部品） カタログ審査・重複検出・命名/schema規約
コスト（トークン） テンプレ/キャッシュ・生成範囲の限定・計測

6. 直近の優先順位（着手推奨）

  1. §3 コンポーネント契約テスト・ハーネス（Phase2 の前提、単体で価値大）。
  2. L1 語彙拡張：emit-request＋responseEvent の結果ハンドリング等、コード無しでAI合成範囲を拡大。
  3. AI下書きレビューコンソール（Phase4 土台、Phase1でも有用）。
  4. Phase 2 PoC：NL→部品→検証→PR を1部品で通す。

7. まとめ

  • できない部分は AI で生成できるが、自動公開はしない。宣言境界＋検証ゲート＋人間承認が前提。
  • 新部品・複雑ロジックの AI 生成は今日でも現実的。価値は検証ハーネスに比例。
  • サービス化の芽は十分。縦特化＋データ資産＋検証を武器に、Phase1→4 で段階的に。