@orizm/cli 3.1.0 → 3.3.0-beta.0

package/dist/docs/features/webhook/revalidate-nextjs.md

@@ -0,0 +1,185 @@
+<!-- source: docs/src/app/features/webhook/revalidate-nextjs/page.mdx -->
+
+# Next.js でキャッシュを再検証する
+
+Webhook と Next.js の `revalidateTag()` を組み合わせて、更新されたコンテンツのキャッシュだけを失効させる構成を説明します。
+
+時間ベースの再検証では、更新がなくても再取得が走り、逆に更新直後は次の再検証まで古い内容が表示されます。Webhook で失効させると、更新があったコンテンツだけを対象にできます。
+
+このページは Next.js 16 の App Router を前提としています。
+
+## 仕組み
+
+1. 編集者が CMS でコンテンツを公開する
+2. Orizm が設定された URL に POST リクエストを送る
+3. Route Handler がペイロードから失効させるキャッシュタグを決定する
+4. `revalidateTag()` でそのタグを失効させる
+5. 次のリクエストで最新のコンテンツが取得される
+
+## キャッシュタグを設計する
+
+一覧ページ用の「テーブル単位のタグ」と、詳細ページ用の「コンテンツ単位のタグ」の2種類があれば、ほとんどのサイトで足ります。
+
+```ts copy filename="src/lib/revalidate-tag.ts"
+import type { OrizmClient } from "@repo/orizm/consumer";
+
+export function generateTag(
+  tableName: keyof OrizmClient["tables"],
+  resourceId?: string,
+): string {
+  return resourceId ? `${tableName}:${resourceId}` : tableName;
+}
+```
+
+テーブル名を `keyof OrizmClient["tables"]` で受け取ることで、存在しないテーブル名を渡すとコンパイルエラーになります。
+
+## コンテンツ取得にタグを付ける
+
+Consumer SDK の各メソッドは最後の引数で `RequestInit` を受け取ります。ここで `next.tags` を指定すると、その取得結果にキャッシュタグが付きます。
+
+```ts copy filename="src/features/blog/get-blog-list.ts"
+import { serverSideCmsClient } from "@/lib/orizm-client";
+import { generateTag } from "@/lib/revalidate-tag";
+
+export function getBlogList() {
+  return serverSideCmsClient.tables.blog.list(
+    { order: { publishedAt: "desc" } },
+    { next: { tags: [generateTag("blog")] } },
+  );
+}
+```
+
+詳細ページにはコンテンツ単位のタグだけを付けます。失効させる側で必要なタグをまとめて渡すため、取得側は1つのタグで済みます。
+
+```ts copy filename="src/features/blog/detail/id/get-blog-single.ts"
+import { serverSideCmsClient } from "@/lib/orizm-client";
+import { generateTag } from "@/lib/revalidate-tag";
+
+export function getBlogSingle(id: string) {
+  return serverSideCmsClient.tables.blog.get(
+    id,
+    { include: { category: true } },
+    { next: { tags: [generateTag("blog", id)] } },
+  );
+}
+```
+
+`RequestInit` の指定方法は [コンテンツの取得](../consumer-sdk/fetch-contents.md) を参照してください。
+
+## Route Handler を実装する
+
+Webhook を受け取るエンドポイントを作ります。ペイロードの型 `WebhookPayload` は `orizm codegen consumer` が生成します。`table` をキーにした判別可能なユニオンなので、`switch` で分岐すると `content` の型がそのテーブルの型に絞られます。
+
+送信元の確認には [署名の検証](../webhook.md#署名の検証) を使います。`jwksUrl` に設定する値は後述の [エンドポイントを保護する](#エンドポイントを保護する) を参照してください。
+
+```ts copy filename="src/app/api/revalidate/route.ts"
+import type { WebhookPayload } from "@repo/orizm/consumer";
+import { createWebhookVerifier } from "@orizm/consumer-sdk/webhook";
+import { revalidateTag } from "next/cache";
+import { type NextRequest, NextResponse } from "next/server";
+import { generateTag } from "@/lib/revalidate-tag";
+import { env } from "@/env";
+
+// リクエストごとに作り直すと JWKS のキャッシュが効かないため、モジュールスコープに置く
+const verifier = createWebhookVerifier<WebhookPayload>({
+  jwksUrl: env.ORIZM_WEBHOOK_JWKS_URL,
+  // インスタンスが使い捨てられてもキャッシュが効くよう、JWKS の取得を Data Cache に載せる
+  fetchOptions: { next: { revalidate: 300 } },
+});
+
+export const POST = async (request: NextRequest): Promise<Response> => {
+  const result = await verifier.verifyRequest(request);
+
+  if (!result.valid) {
+    return NextResponse.json({ error: result.reason }, { status: 401 });
+  }
+
+  const revalidateTags = await getRevalidateTags(result.body);
+
+  for (const tag of revalidateTags) {
+    revalidateTag(tag, "max");
+  }
+
+  return NextResponse.json({ revalidated: revalidateTags });
+};
+
+const getRevalidateTags = async (
+  payload: WebhookPayload,
+): Promise<string[]> => {
+  switch (payload.table) {
+    case "blog": {
+      return [generateTag("blog"), generateTag("blog", payload.content.id)];
+    }
+    // ...
+    default: {
+      assertNever(payload);
+    }
+  }
+};
+
+function assertNever(x: never): never {
+  throw new Error(`Unexpected payload: ${JSON.stringify(x)}`);
+}
+```
+
+実装時の注意は4点です。
+
+- `verifyRequest` は署名検証のために body を読み切るため、呼び出したあとに `request.json()` を呼ぶことはできません。ペイロードは `result.body` から取得します
+- JWKS が取得できないときは `WebhookJwksFetchError` が throw されます。捕捉せずに Next.js に 500 を返させれば、Orizm が再送します。ただし JWKS URL が 404 を返す場合は設定間違いなので、`reason` が `jwks-not-found` の検証失敗として返ります
+- 配信は5秒でタイムアウトします。タグを組むために参照先を引く必要がある場合も、軽量な取得1回程度に留めてください
+- 同じイベントが複数回届くことがあります。`revalidateTag()` は何度呼んでも問題ありませんが、それ以外の副作用を行う場合は重複実行を考慮してください
+
+配信の詳細は [配信の仕様](../webhook.md#配信の仕様) を参照してください。
+
+## エンドポイントを保護する
+
+このエンドポイントは公開 URL に置くため、Orizm 以外からのリクエストを拒否する必要があります。Orizm はリクエストに Ed25519 署名を付与するため、[署名の検証](../webhook.md#署名の検証)で送信元を確認します。
+
+検証に使う JWKS の URL は、Orizm コンソールの Webhook 詳細画面に表示されます。
+
+この URL が返すのは公開鍵だけなので、秘密の値として扱う必要はありません。ソースコードに直接書いても構いませんし、環境ごとに Webhook を分けていて URL が変わる場合は、環境変数にしておくと扱いやすくなります。
+
+```sh copy filename="apps/consumer/.env.local"
+ORIZM_WEBHOOK_JWKS_URL=<コンソールに表示される JWKS URL>
+```
+
+署名の検証に失敗して401を返すと、その通知はリトライされずに失われます。設定を直したあとは、改めてコンテンツを更新して配信を発生させてください。
+
+## Orizm に Webhook を登録する
+
+エンドポイントを用意したら、Orizm 側に通知先として登録します。開発者コンソールでの手順は [設定方法](../webhook.md#設定方法) を参照してください。
+
+CLI からも登録できます。
+
+```sh copy
+orizm webhook create --name "revalidate" \
+  --url https://example.com/api/revalidate \
+  --table-event blog:content.create \
+  --table-event blog:content.update \
+  --table-event blog:content.delete
+```
+
+購読するテーブルとイベントは、サイトの表示に使っているものだけに絞ります。どの編集操作でどのイベントが届くかは [編集操作とイベントの対応](../webhook.md#編集操作とイベントの対応) を参照してください。
+
+あとからスキーマにテーブルを追加してサイトの表示に使う場合は、Table Events への追加も必要です。追加を忘れると、そのテーブルの更新は通知されません。
+
+## デプロイ時の注意
+
+- **Basic 認証やアクセス制限から除外する。** Next.js 16 の `proxy.ts` (Next.js 15 以前の `middleware.ts`) で Basic 認証をかけている場合、`matcher` から `/api/revalidate` を除外してください
+- **Vercel の Deployment Protection を確認する。** 保護が有効な環境では外部からの POST が拒否されます。保護をバイパスする設定を行うか、本番環境のみに Webhook を登録してください
+
+## うまく動かないとき
+
+**再検証されない**
+
+- 開発サーバーではキャッシュの挙動が本番と異なります。デプロイした環境で確認してください
+- 取得側に `next.tags` を付け忘れていないか確認してください。タグが付いていないキャッシュは `revalidateTag()` の対象になりません
+- Route Handler が返した `revalidated` に意図したタグが含まれているか、ログで確認してください
+- `revalidateTag()` の第2引数に `"max"` を指定している場合、そのページが次に表示されるまで再取得は始まりません
+- 予約公開・予約非公開を使っている場合、指定した時刻から最大1分ほど遅れて通知されます
+
+**401が返る**
+
+- `ORIZM_WEBHOOK_JWKS_URL` が、通知を受け取りたい Webhook の JWKS URL と一致しているか確認してください。JWKS は Webhook ごとに異なるため、別の Webhook の URL では検証に失敗します
+- `verifyRequest` より先に `request.json()` などで body を読んでいないか確認してください
+- Basic 認証やアクセス制限がエンドポイントに掛かっていないか確認してください

package/dist/docs/features/webhook.md

@@ -0,0 +1,295 @@
+<!-- source: docs/src/app/features/webhook/page.mdx -->
+
+# Webhook
+
+Webhook機能を使用すると、コンテンツの作成、更新、削除が行われた際に、指定したURLに通知を送信できます。これにより、外部システムやサービスとの連携が可能です。
+
+## 機能
+
+- コンテンツの作成、更新、削除を通知
+- テーブルごとに通知するイベントを指定
+- カスタムリクエストヘッダーに対応
+- 配信失敗時の自動リトライ
+- Ed25519 署名による送信元の検証
+
+## 設定方法
+
+Orizmコンソールのプロジェクト設定からWebhookを設定できます。
+
+コマンドラインから設定する場合は [webhook コマンド](./cli/commands/webhook.md) を参照してください。
+
+### プロジェクト設定を開く
+
+![プロジェクト設定を開く](./webhook-access-project-settings.png)
+
+### Webhook設定を開く
+
+![Webhook設定を開く](./webhook-access-webhooks.png)
+
+### Webhookの作成をクリック
+
+![Webhookの作成をクリック](./webhook-create-new.png)
+
+### Webhookの作成
+
+![Webhookの作成](./webhook-create.png)
+
+| プロパティ名 | 概要                                              |
+| ------------ | ------------------------------------------------- |
+| Name         | コンソール上の表示用です                          |
+| URL          | 指定したURLにPOSTリクエストでイベントを通知します |
+
+### テーブルとイベントを選択
+
+Table Events で通知を受け取るテーブルとイベントを選択します。
+
+- `Add Table Event` をクリックするとテーブルを追加します
+- `Add All Tables` をクリックすると全てのテーブルを追加します
+
+特定のイベント通知が不要な場合は、チェックボックスを解除することで通知を無効にできます。
+
+`Save` をクリックすると設定が保存されます。
+
+![テーブルとイベントを選択](./webhook-select-table-and-event.png)
+
+### カスタムリクエストヘッダー
+
+Custom Request Headers で必要に応じて、HTTPリクエストに任意のヘッダーを追加できます。
+
+![カスタムHTTPヘッダー](./webhook-custom-headers.png)
+
+## サポートしているイベント
+
+| イベント名       | 説明                         |
+| ---------------- | ---------------------------- |
+| `content.create` | コンテンツが新規作成された時 |
+| `content.update` | コンテンツが更新された時     |
+| `content.delete` | コンテンツが削除された時     |
+
+### 編集操作とイベントの対応
+
+公開や非公開には専用のイベントがなく、いずれも`content.update`として通知されます。
+
+| 編集操作             | 通知されるイベント | `old` |
+| -------------------- | ------------------ | ----- |
+| コンテンツの作成     | `content.create`   | なし  |
+| コンテンツの更新     | `content.update`   | あり  |
+| コンテンツの公開     | `content.update`   | なし  |
+| コンテンツの非公開   | `content.update`   | なし  |
+| コンテンツの削除     | `content.delete`   | なし  |
+| 予約公開・予約非公開 | `content.update`   | なし  |
+
+予約公開・予約非公開は1分ごとに実行対象を確認するため、指定した時刻から最大1分ほど遅れて通知されます。
+
+## Webhookペイロード
+
+Webhookがトリガーされると、指定したURLにPOSTリクエストで以下のようなJSON形式のデータが送信されます。
+
+```json
+{
+  "event": "content.create",
+  "timestamp": "2025-01-01T00:00:00.000Z",
+  "project": "projectName",
+  "table": "tableName",
+  "content": {
+    "id": "xxxxxxxx"
+    ...
+  }
+}
+```
+
+### event
+
+トリガーされたイベントの名前です。[サポートしているイベント](#サポートしているイベント) のイベント名が入ります。
+
+### timestamp
+
+イベントの発生時刻です。
+
+ISO 8601形式で表現されます。（例: `2025-01-01T00:00:00.000Z`）
+
+### project
+
+イベントが発生したプロジェクト名です。
+
+### table
+
+イベントが発生したテーブル名です。
+
+### content
+
+イベントが発生した際のコンテンツです。
+
+### old
+
+イベントが発生した際の変更前のコンテンツです。
+
+コンテンツの更新の場合のみ存在します。
+
+## 配信の仕様
+
+| 項目               | 仕様                                                                                                                                                                                            |
+| ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| HTTPメソッド       | `POST`                                                                                                                                                                                          |
+| リクエストヘッダー | `Content-Type: application/json`、`User-Agent: superx-webhook`、[署名ヘッダー](#署名の検証)（`webhook-id`、`webhook-timestamp`、`webhook-signature`）、および設定したカスタムリクエストヘッダー |
+| タイムアウト       | 5秒                                                                                                                                                                                             |
+| 成功の判定         | ステータスコードが2xx                                                                                                                                                                           |
+| リトライする失敗   | タイムアウト、ネットワークエラー、5xxのレスポンス                                                                                                                                               |
+| リトライしない失敗 | 4xxのレスポンス                                                                                                                                                                                 |
+| 試行回数           | 初回を含めて最大10回                                                                                                                                                                            |
+| リトライの間隔     | 指数バックオフ（1秒から始まり、失敗するたびに倍になります）                                                                                                                                     |
+
+- 通知先が複数設定されている場合、宛先ごとに独立して配信とリトライを行います。失敗した宛先だけが再送されます
+- リトライ中に設定を変更しても、進行中の配信には反映されません
+- リトライが発生すると、あとに発生したイベントが先に届くことがあります。またタイムアウトしたリクエストが受信側では処理されていた場合、同じイベントが複数回届きます
+
+受信側は、同じイベントを複数回受け取っても問題のない実装にしてください。
+
+## 署名の検証
+
+Orizm は Webhook の POST リクエストに [Standard Webhooks](https://www.standardwebhooks.com/) 準拠の Ed25519 署名を付与します。受信側で署名を検証すると、リクエストが自分の登録したその Webhook 設定に由来することを暗号学的に確認できます。
+
+### 署名ヘッダー
+
+| ヘッダー            | 説明                                                                                |
+| ------------------- | ----------------------------------------------------------------------------------- |
+| `webhook-id`        | 配信ごとに一意な ID。リトライしても同じ値のため、受信側の冪等性キーとして使えます   |
+| `webhook-timestamp` | 送信試行時刻（Unix 秒）。リトライごとに新しい値になります                           |
+| `webhook-signature` | `v1a,<base64>` 形式の署名。**スペース区切りで複数の署名が併記されることがあります** |
+
+署名ヘッダーはカスタムリクエストヘッダーでは上書きできません。
+
+### 公開鍵の取得
+
+検証に使う公開鍵は、Webhook ごとの JWKS エンドポイントで配布されます。URL は Orizm コンソールの Webhook 詳細画面に表示されます。
+
+鍵は自動的にローテーションされます。公開鍵をコードや設定ファイルにコピーして固定せず、必ず JWKS エンドポイントから取得してください。
+
+- JWKS のレスポンスは 5 分〜24 時間を目安にキャッシュしてください
+- 手持ちのどの鍵でも検証に失敗したときは、JWKS を再取得してから一度だけ再試行してください（鍵のローテーション直後に古いキャッシュを使っているケースに対応できます）。再取得には 30 秒程度の最短間隔を設けてください
+- ローテーションの移行中は、新旧 2 つの鍵による 2 つの署名が届きます。**署名が 1 つである前提の実装は、ローテーションのたびに壊れます**
+
+### 検証の手順
+
+1. `webhook-timestamp` が現在時刻から許容窓（推奨 ±5 分）以内であることを確認します。超えていたら拒否します（リプレイ対策）
+2. `webhook-id`、`webhook-timestamp`、リクエストボディを `.` で連結した文字列 `{webhook-id}.{webhook-timestamp}.{body}` を署名対象とします
+3. `webhook-signature` をスペースで分割し、`v1a,` に続く base64 の署名のいずれかが、JWKS 内のいずれかの鍵で Ed25519 検証に通れば成功です
+
+署名は **JSON パース前の raw body** に対して行われます。パースした値を再シリアライズするとバイト列が一致しないことがあるため、必ず受信したそのままのボディ文字列で検証してください。
+
+### レスポンスコードの指針
+
+| 状況                                     | 返すべきステータス                         |
+| ---------------------------------------- | ------------------------------------------ |
+| 署名の検証の結果、リクエストが不正       | `401`（Orizm は 4xx に対して再送しません） |
+| JWKS URL が誤っているなど設定に起因する  | `4xx`（再送しても解決しません）            |
+| JWKS が取得できないなどの一時障害        | `5xx`（Orizm が再送します）                |
+
+### SDK で検証する
+
+`@orizm/cms-sdk/webhook` または `@orizm/consumer-sdk/webhook` の `createWebhookVerifier` を使うと、JWKS の取得とキャッシュ、複数署名のパース、タイムスタンプの検証までをまとめて行えます。Web Crypto API と `fetch` だけで実装されているため、Cloudflare Workers や Vercel Edge などの Node.js 以外のランタイムでも動作します。
+
+`verifyRequest` に受信した `Request` を渡すと、raw body の取り出しから検証、ペイロードのパースまでを行います。検証に成功した場合だけ `body` からペイロードを取得できます。ペイロードの型 `WebhookPayload` は `orizm codegen consumer` が生成します。
+
+```ts copy filename="src/app/api/webhook/route.ts"
+import type { WebhookPayload } from "@repo/orizm/consumer";
+import { createWebhookVerifier } from "@orizm/consumer-sdk/webhook";
+
+// リクエストごとに作り直すと JWKS のキャッシュが効かないため、モジュールスコープに置く
+const verifier = createWebhookVerifier<WebhookPayload>({
+  jwksUrl: "<コンソールに表示される JWKS URL>",
+});
+
+export const POST = async (request: Request): Promise<Response> => {
+  const result = await verifier.verifyRequest(request);
+
+  if (!result.valid) {
+    return Response.json({ error: result.reason }, { status: 401 });
+  }
+
+  // result.body は検証済みのペイロード
+  console.log(result.body.event, result.body.table);
+  return Response.json({ ok: true });
+};
+```
+
+`verifyRequest` は署名検証のために body を読み切るため、呼び出したあとに `request.json()` や `request.text()` を呼ぶことはできません。ペイロードは `result.body` から取得してください。
+
+JWKS が取得できないときは `WebhookJwksFetchError` が throw されます。署名の真偽を判定できていない一時障害なので、そのまま throw させてフレームワークに 5xx を返させるのが適切です（Orizm が再送します）。捕捉して独自のレスポンスを返す場合も、401 ではなく 5xx を返してください。
+
+ただし JWKS URL が 404 を返した場合は、URL の設定間違いであって再送では解決しないため、throw ではなく `reason` が `jwks-not-found` の検証失敗として返ります。`result.reason` をログに出しておくと、署名が不正だったのか URL の設定が誤っているのかを切り分けられます。
+
+#### JWKS の取得をランタイムのキャッシュに載せる
+
+verifier は取得した JWKS をメモリ上にキャッシュしますが、サーバーレス環境ではインスタンスが使い捨てられるためキャッシュが効かないことがあります。`fetchOptions` に渡した値は JWKS 取得の `fetch` にそのまま渡るので、Next.js の Data Cache などに載せられます。
+
+```ts copy filename="src/app/api/webhook/route.ts"
+const verifier = createWebhookVerifier<WebhookPayload>({
+  jwksUrl: "<コンソールに表示される JWKS URL>",
+  fetchOptions: { next: { revalidate: 300 } },
+});
+```
+
+鍵は自動ローテーションされるため、`cache: "force-cache"` や `next: { revalidate: false }` のような無期限キャッシュは指定しないでください。JWKS が更新されず、ローテーション後に検証が通らなくなります。
+
+Express や素の `node:http` のように `Request` を組み立てられない環境では、raw body 文字列とヘッダーを渡す `verifyPayload` を使います。
+
+```ts copy filename="src/webhook.ts"
+// express.raw({ type: "application/json" }) などで生のボディを受け取っておく
+const result = await verifier.verifyPayload(
+  req.body.toString("utf8"),
+  req.headers,
+);
+```
+
+### SDK を使わずに検証する
+
+依存を追加せず、Web Crypto API だけで検証する例です。
+
+```ts copy filename="verify-webhook.ts"
+export async function verifyWebhook(
+  jwksUrl: string,
+  payload: string,
+  headers: Headers,
+): Promise<boolean> {
+  const id = headers.get("webhook-id");
+  const timestamp = headers.get("webhook-timestamp");
+  const signatureHeader = headers.get("webhook-signature");
+  if (id === null || timestamp === null || signatureHeader === null) {
+    return false;
+  }
+
+  // リプレイ対策: 許容窓 ±5 分
+  const skew = Math.abs(Date.now() / 1000 - Number(timestamp));
+  if (!Number.isFinite(skew) || skew > 300) {
+    return false;
+  }
+
+  // 実際には 5 分〜24 時間を目安にキャッシュする
+  const jwks = await fetch(jwksUrl).then((res) => res.json());
+  const publicKeys = await Promise.all(
+    jwks.keys.map((jwk) =>
+      crypto.subtle.importKey("jwk", jwk, "Ed25519", false, ["verify"]),
+    ),
+  );
+
+  const content = new TextEncoder().encode(`${id}.${timestamp}.${payload}`);
+  const signatures = signatureHeader
+    .split(" ")
+    .filter((entry) => entry.startsWith("v1a,"))
+    .map((entry) =>
+      Uint8Array.from(atob(entry.slice(4)), (char) => char.charCodeAt(0)),
+    );
+
+  for (const key of publicKeys) {
+    for (const signature of signatures) {
+      if (await crypto.subtle.verify("Ed25519", key, signature, content)) {
+        return true;
+      }
+    }
+  }
+  return false;
+}
+```
+
+呼び出し側では、JSON パース前の raw body（例: Next.js の Route Handler では `await request.text()`、Express では `express.raw()` や `express.json({ verify })` で保持した生のボディ）を `payload` に渡してください。

package/dist/docs/get-started/add-model-starter.md

@@ -0,0 +1,124 @@
+<!-- source: docs/src/app/get-started/add-model-starter/page.mdx -->
+
+# モデルを追加する
+
+## はじめに
+
+このチュートリアルでは、 Orizm のスターターキットに新たなモデル Job（採用情報）を追加し、CMSで管理しつつ、公開サイトで表示するまでの流れを解説します。
+
+スターターキットにはすでに固定ページ・お知らせ・ブログなどのモデルが含まれていますが、新たにJobモデルを追加することで、Orizmのテーブル機能を理解し、独自のデータ構造を組み込む方法を学びます。
+
+## モデルの定義
+
+はじめに必要なカラムを設計します。ここではJobは以下のカラムを持つモデルとして定義します。
+
+| カラム名      | 型       | 説明             |
+| ------------- | -------- | ---------------- |
+| `title`       | `string` | 求人のタイトル   |
+| `description` | `string` | 求人の詳細情報   |
+| `order`       | `number` | 表示順を制御する |
+
+## モデルの作成
+
+スターターキットのコードを編集してモデルを追加します。次のコードをコピーして `packages/orizm/orizm.config.ts` の `tables` プロパティに追加して保存します。
+
+```ts copy
+// 採用情報テーブル
+job: {
+  columns: {
+    // 職種
+    title: {
+      type: "string",
+      required: true,
+    },
+    // 業務内容
+    description: {
+      type: "string",
+      required: true,
+    },
+    // 掲載順
+    order: {
+      type: "number",
+      required: true,
+    },
+  },
+}
+```
+
+このスキーマを適用するために、次のコマンドを実行してデータベースを更新します。
+
+```sh
+pnpm run orizm:push
+```
+
+うまくいけば、Orizm console にテーブルが追加されていることが確認できます。
+
+![Job テーブル](./job-table.png)
+
+また、テーブルを消したいときは、先ほど追加したTypeScriptのスキーマを削除し、再度 `orizm:push` を実行してください。本番プロジェクトでこのような破壊的変更を望まない場合、削除保護機能を使うことができます。
+
+## CMS での管理
+
+CMSでこの新しいモデルを管理するページを追加していきます。
+
+以下に、大まかな変更箇所を示します。
+
+### packages/model にvalibotスキーマを追加する
+
+スターターキットでは Valibot を使って型システムの補強やバリデーションを行っています。
+Orizm のコード生成コマンドでは Valibotに依存しない型定義しか生成していないため、このレイヤーで型の補強しています。
+
+### packages/apps/cms に CRUDページを追加する
+
+スターターキットにすでに存在するモデルを参考にして、新しいモデルのCRUDページを作成していきます。
+
+#### Server Action の追加
+
+スターターキットでは `src/**/actions.ts` というファイルに Server Action を定義しています。
+ここでは、 Orizm CMS SDK を使ってリモートのOrizmプロジェクトと通信するコードが存在します。
+
+#### コンポーネントの追加
+
+スターターキットでは `src/features` というディレクトリに、モデル固有のコンポーネントを配置しています。
+例えば、作成フォーム、編集フォームといったコンポーネントがここに配置されます。
+この階層のコンポーネントは、 CMS SDK を使ってデータを読み込んだり、前のステップで定義した Server Action を呼び出してデータを更新します。
+
+#### ページの追加
+
+スターターキットは App Router を使っています。 `src/app` ディレクトリにファイルを配置することで、ページのRoutingを定義できます。
+
+## 公開サイト(Consumer)に表示
+
+スターターキットの公開サイト(Consumer) は `apps/consumer` ディレクトリにある Next.js アプリケーションです。
+
+シンプルな例として、Jobモデルを一覧表示するには、以下のような `page.tsx` ファイルを作成し、appディレクトリに配置します。
+
+```tsx
+import { serverSideCmsClient } from "@/lib/orizm-client";
+
+export default async function Page() {
+  const res = await serverSideCmsClient.tables.job.list({
+    limit: 10,
+    order: { order: "asc" },
+  });
+  const jobs = res.contents;
+
+  return (
+    <div>
+      {jobs.map((job) => (
+        <div key={job.id}>
+          <h2>{job.title}</h2>
+          <p>{job.description}</p>
+        </div>
+      ))}
+    </div>
+  );
+}
+```
+
+スターターキットでは、CMSと同様に `src/features` ディレクトリにモデル固有のコンポーネントや通信ロジックをまとめて配置することで、コードの再利用性を高めています。
+
+# まとめ
+
+ここまでで、独自のモデルを定義して追加する際の大まかな流れを解説しました。
+さらにカスタマイズする場合、Orizm のテーブル機能のリファレンスも参考にしてください。