AI-friendly benchmark: CRUD 管理画面

このページは、同じ CRUD 管理画面要件を SPA 構成と Marionette 構成で比較するための、小さく繰り返し可能なベンチマーク定義です。

題材

ベンチマーク対象は、顧客注文を管理する業務管理画面です。レコードのテーブル表示、ステータスによるテーブルフィルタ、ワークフロー操作のフォーム送信、操作後に影響範囲だけを更新する振る舞いを含めます。

  • CRUD 形式のレコード一覧と詳細画面への遷移。
  • ActiveReviewBlocked などのステータスによるテーブルフィルタ。
  • ログインや行単位のワークフロー操作を行うフォーム送信。
  • SPA の状態ツリー全体を組み直すのではなく、対象領域だけを差し替える部分更新。

比較軸

実測 token 数がない段階では、token 削減率は記載しません。まずは、AI が揃えて理解する必要のある文脈量に影響する構造的な差分を比較します。

比較軸 典型的な SPA 実装 Marionette 実装 将来の実測項目
変更ファイル数 クライアントルート / コンポーネント、クライアント状態、API クライアント、サーバールート、バリデーション、テストに分かれやすい。 UI 描画、Action 処理、状態更新を Marionette アプリに近い Go ファイルへ集約しやすい。 同じ要件を各サンプルブランチで実装し、touch したファイル数を数える。
使用言語数 UI は TypeScript/JSX、API とバリデーションはバックエンド言語、という組み合わせになりやすい。 UI、Action、State は主に Go。ブラウザ側の部分更新は htmx 属性で表す。 実装とレビューに必要な言語を列挙する。
API schema の有無 フロントエンド / バックエンド間で、明示的な API schema や重複した request/response 型が必要になりやすい。 サーバー描画 fragment のワークフローでは、プロダクトとして追加しない限り、別個の JSON API schema は必須ではない。 OpenAPI、生成クライアント、重複 DTO がサンプルに含まれるかを記録する。
AI に説明する概念数 ルートコンポーネント、クライアント状態、API 契約、loading/error 状態、楽観的更新または cache invalidation、サーバーハンドラ、バリデーション、レスポンス変換。 Page / component rendering、ActionForm、server action、共有 Go state、htmx target/swap、返却する fragment。 AI が安全に変更できる最小の prompt/context bundle を作り、含まれる概念を数える。

比較手順

  1. Marionette 側は既存の admin sample、cmd/admin-sample から始める。
  2. 同じ見た目と要件を持つ SPA サンプルを作る。テーブルフィルタ、行アクションフォーム、詳細ルート、バリデーション / エラー表示、部分的な UI 更新に相当する振る舞いを揃える。
  3. 両方のサンプルへ同一の変更依頼を適用する。例: 新しい Paused ステータスを追加し、フィルタ可能にし、ステータス変更後に confirmation flash を表示する。
  4. 各実装について、変更ファイル数、実装言語、API schema に関わる成果物、AI prompt に含めた概念リストを記録する。
  5. 両方の実行で prompt / completion token 数を取得した後にだけ、実測 token 数を追加する。実測なしに token 削減率は公開しない。

現在の Marionette サンプルとの対応

既存の admin sample は、Marionette 側の比較対象をすでに含んでいます。orders/filter は選択ステータスを更新して main content fragment を返し、orders/toggle-status はワークフロー状態を変更して同じ対象領域を返します。

行アクションフォームは #main-contentouterHTML で差し替え、テーブルは Go の状態から描画されます。この構造を、同等の SPA の state / update 経路と比較します。