AI-friendly architecture

Marionette が AI-friendly なのは、AI が再構築すべき設計文脈を減らせるためです。UI、Action、State を Go-first なひとつの文脈に寄せ、ブラウザ側の部分更新は htmx が担います。

誇張したトークン削減率ではなく、文脈の圧縮

Marionette は、根拠の薄い「トークンを何％削減」といった表現ではなく、構造的な説明量の削減を重視します。UI、サーバー側の振る舞い、状態遷移が Go-oriented な流れにまとまるため、AI に説明すべき部品が少なくなります。

SPA クライアント、API 契約、サーバーハンドラ、重複する状態モデルをそれぞれ説明する代わりに、プロダクト上の振る舞いと、それを描画・処理する Go コードを中心に会話できます。

管理画面や社内ツールでは、アクションを追加する、テーブルを更新する、チャートをフィルタする、権限に応じて操作を制御する、といった具体的なワークフロー変更が頻繁に起きます。Marionette はそれらを Go に近づけ、関連する文脈をまとめます。

AI と一緒に実装するときも、複数のフロントエンド / バックエンドプロジェクトの連携を毎回説明するのではなく、ひとつの実装言語とサーバー側の実行モデルを前提にできます。実際のワークフロー変更に入る前の設計説明を短くできます。

Marionette は、業務 UI で AI が理解すべき要素を Go の近くに集めます。ユーザーに何が見えるのか、どの操作を実行できるのか、その結果として状態がどう変わるのかを、同じ流れで追いやすくします。

フロントエンドとバックエンドの境界が増えるほど、チームと AI が理解すべき契約も増えます。リクエスト、レスポンス、クライアント状態、楽観的更新、バリデーション、エラー表示などを別々に追う必要が出ます。

Marionette はすべての境界をなくすわけではありませんが、典型的な管理画面や業務画面で必要な境界を減らします。その結果、レビューや AI への依頼をクロススタックな配管ではなく、業務フローに集中させやすくなります。

htmx により、Marionette は小さなブラウザ側インタラクションモデルを持てます。サーバーは変更された部分の HTML を返し、ブラウザはその部分だけを差し替えます。

これにより、フル SPA 構成を強制せずにインタラクティブな体験を作れます。AI 支援開発で重要なのは、保証されたトークン削減率ではありません。サーバーで描画されるコンポーネントと、それを生み出すアクションを同じ文脈で推論しやすいことです。

Marionette はアプリケーションロジックを Go 側に寄せ、ブラウザ側の部分更新は htmx が担います。そのため、典型的な管理画面や業務画面のコアアプリに TypeScript ビルドチェーンや SPA 前提のフロントエンドツールチェーンは必要ありません。

これは Go-first の方針であり、クライアント JS を完全排除するという意味ではありません。overlay など既存の共有ヘルパーは表示上の振る舞いを支えるために残る場合があります。一方で、プロダクトのワークフロー、状態遷移、バリデーションは主に Go ハンドラ側に寄せます。

新規 .ts / .tsx ファイルの扱いは UI architecture policy を参照してください。

同じ CRUD 管理画面要件を SPA 構成と Marionette 構成で比較する簡易ベンチマークページを追加しました。実測 token 数がない段階では、token 削減率は記載しません。