共有スキーマと契約の一元化
ドメインモデルを Zod スキーマとして一度定義すれば、TypeScript 型、バリデーション、BFF ルート、バックエンドハンドラー、API 契約が生成されます。アプリケーションが大きくなっても定義がずれません。
SwallowKitスキーマ駆動 scaffolding
共有 Zod スキーマを中心に、Next.js フロントエンド・BFF・Azure Functions バックエンド・インフラ構成の整合性を保ちます。
Skip to content
なぜ SwallowKit か
フルスタックアプリケーションでは、同じドメインモデルがフロントエンドフォーム、クライアントバリデーション、BFF 型、バックエンド DTO、API 契約、データベースエンティティ、インフラ構成にわたって繰り返されます。プロジェクトが大きくなるほど、これらの定義はずれていきます。
AI はコードをすばやく生成できますが、レイヤー間の整合性を自動で維持してはくれません。フレームワークは複雑さを隠せますが、本番アプリケーションには開発者が読み変更できる明示的なアーキテクチャが必要です。
SwallowKit は共有 Zod スキーマを中心に置き、その周辺のアプリケーション構造を生成することでこの問題に対処します。ランタイムフレームワークではなく scaffolding ツールです。生成されたコードは読み、編集し、置き換えられます。
次のステップ
- はじめる — プロジェクトを作成し、最初の CRUD フローを生成する
- 基本概念 — スキーマ中心のアーキテクチャを理解する
- Scaffold ガイド — CRUD 生成の詳細
- Azure へのデプロイ — Bicep でプロビジョニングとデプロイ
- AI / MCP ガイド — コーディングエージェント向けの機械可読インターフェース