@orizm/cli 3.1.0 → 3.3.0-beta.0

package/dist/docs/features/dictionary.md

@@ -0,0 +1,265 @@
+<!-- source: docs/src/app/features/dictionary/page.mdx -->
+
+# 検索辞書
+
+検索辞書を使用すると、社内の俗称や型番の表記ゆれを検索に教え込めます。開発コード「マニ丸」で検索した人に正式名称「全熱交換型換気システム」の記事を返す、といった言い換えを、コンテンツ本文を書き換えずに実現できます。
+
+検索辞書は以下の機能を提供します。
+
+- 同義語による検索クエリの言い換え（表記ゆれ・俗称の吸収）
+- 用語そのものの解説を検索結果に返す
+- プロジェクト全体に効く語彙管理（テーブルごとの設定は不要）
+- エントリを削除せずに一時的に無効化
+
+> [!WARNING]
+> 検索辞書が検索に効くのは [セマンティック検索](./full-text-search.md)
+> を有効にしたプロジェクトで、`mode` に `semantic` または `hybrid`
+> を指定した検索だけです。`mode` を省略した検索（`keyword`）には効きません。
+>
+> セマンティック検索が利用できるかどうかは、プロジェクトの設定に加えてシステム側の設定でも決まります。システム側で有効になっていない環境では、辞書の登録・更新は成功しても検索には反映されません（`semantic` / `hybrid` がエラーになるか、`keyword` と同じ結果に劣化して返ります）。利用中の環境で使えるかは管理者に確認してください。
+>
+
+## ユースケース例
+
+### 社内の俗称・略称で検索できるようにする
+
+製品名や部署名には、正式名称のほかに現場でしか使われない呼び方があります。検索辞書に正式名称を見出し語、俗称を同義語として登録しておくと、どちらで検索しても同じコンテンツに当たります。コンテンツ側に俗称を書き足す必要はありません。
+
+### 型番の表記ゆれを吸収する
+
+`ORZ-1200X` のような型番は、全角で入力される・ハイフンが別の記号になるといった揺れが生まれます。この種の違いは [正規化](#表記の同一視) で自動的に吸収されますが、`ORZ 1200X` のように語の途中に空白が入る表記や、`オリズム1200` のようにまったく別の呼び方は吸収されないため、同義語として登録します。
+
+### 用語集として検索結果に出す
+
+説明を付けて登録したエントリは、それ自体が検索対象になります。編集者が社内用語で検索したときに、コンテンツの一覧と一緒に用語の解説を出せます。
+
+## 前提
+
+検索辞書そのものはプロジェクト単位の語彙で、辞書を登録するためのテーブルごとの設定はありません。ただし辞書が効くのは `semantic` / `hybrid` で検索できるテーブルに対してだけです。`orizm.config.ts` にプロジェクトの `semanticSearch` を宣言し、検索したいテーブルに `enableSearch: true` を付けて `orizm schema push` してください。
+
+```ts copy filename="orizm.config.ts" showLineNumbers {4,8}
+import { defineConfig } from "@orizm/cli/config";
+
+export default defineConfig({
+  semanticSearch: { enabled: true },
+  tables: {
+    blog: {
+      columns: {},
+      enableSearch: true,
+    },
+  },
+});
+```
+
+> [!NOTE]
+> 検索辞書の操作は CMS SDK（および Management API）で行います。Orizm Console /
+> Project Console には検索辞書の画面はありません。
+
+## 2つの効き方
+
+検索辞書は 2 つの経路で検索に作用します。エントリの内容によって、どちらが効くかが変わります。
+
+| 経路                         | 効く条件                                                  | 反映タイミング |
+| ---------------------------- | --------------------------------------------------------- | -------------- |
+| 同義語によるクエリの言い換え | `hybrid` 検索。同義語が 1 つ以上あるエントリ              | 即時           |
+| 用語解説を検索結果に返す     | CMS SDK の `semantic` / `hybrid` 検索。説明があるエントリ | 非同期         |
+
+どちらも `enabled: false` のエントリには効きません。
+
+### 同義語によるクエリの言い換え
+
+`hybrid` で検索すると、クエリの中に辞書の表記が含まれていた場合に、それを同じエントリの別表記へ置き換えた「変種クエリ」が検索に足されます。置き換えは見出し語と同義語の双方向で、見出し語で検索すれば各同義語に、同義語で検索すれば見出し語と他の同義語に置き換わります。
+
+例えば見出し語 `ORZ-1200X`、同義語 `オリズム1200` / `1200X` のエントリがある場合、`オリズム1200 の仕様` というクエリからは `orz-1200x の仕様` と `1200x の仕様` が足されます。
+
+元のクエリは必ず検索対象として残るので、辞書を登録して検索に一致しなくなるコンテンツはありません。ただし順位は変わります。`hybrid` は上位 100 件までの窓で順位を融合して返すため、言い換えで新たに一致したコンテンツが加わるとその分だけ既存のヒットの順位が下がり、一致の多いクエリでは窓から外れて表示されなくなることがあります。
+
+この経路は Consumer SDK の `hybrid` 検索でも同じように効きます。ただしどのエントリが効いたのかは検索結果に現れません。
+
+ベクトル検索側の障害やシステム側の停止でキーワード検索に劣化したリクエストでは、言い換えも効きません（劣化した応答は `keyword` で検索したときと同じ結果になります）。
+
+> [!NOTE]
+> 照合はクエリ文字列に対する部分一致で、単語の区切りは見ません。短い表記を登録すると、それを含む別の語にも言い換えが起きます。
+>
+> 1 つの変種クエリで置き換えるのは 1 エントリの 1 表記だけです。クエリの中の 2
+> 語がどちらも別表記で書かれているコンテンツは拾えないことがあります。
+>
+> 1 回の検索で足される変種クエリは最大 20 件です。また言い換えに使われるのは、同義語を持つ有効なエントリのうち登録が古い順に
+> 5,000 件までで、これを超える分は効きません（説明だけのエントリはこの数に含まれません）。
+>
+
+### 用語解説を検索結果に返す
+
+説明（`description`）を付けたエントリは、それ自体が検索対象になります。CMS SDK で `semantic` または `hybrid` の検索をすると、検索結果に `_dictionary` が付き、クエリに近いものから最大 3 件の用語解説が返ります。
+
+```ts copy
+const result = await cmsClient.tables.blog.search({
+  query: "熱を回収する換気",
+  mode: "hybrid",
+});
+
+console.log(result.contents); // コンテンツのヒット
+console.log(result._dictionary); // 辞書のヒット（最大 3 件）
+```
+
+`_dictionary` の各要素は以下のフィールドを持ちます。
+
+| フィールド    | 説明                                                                                                            |
+| ------------- | --------------------------------------------------------------------------------------------------------------- |
+| `id`          | エントリの ID。`get()` / `update()` / `delete()` にそのまま渡せます                                             |
+| `term`        | 見出し語（登録した表記のまま）                                                                                  |
+| `description` | 説明                                                                                                            |
+| `score`       | クエリと、見出し語・同義語・説明をつないだ文章との近さ。行の `_semantic.score` とは尺度が違うため比較できません |
+
+照合に使われるのは説明だけではありません。見出し語と同義語も同じ文章に含めて突き合わせるため、説明に俗称を書かなくても、俗称で検索したときに当たりやすくなります。
+
+辞書のヒットは `contents` とは別の枠で返り、`totalCount` にも含まれません。ページングもせず、`offset` を動かしても同じ内容が返ります。
+
+辞書のヒットには近さの下限がありません。説明付きの有効なエントリが 3 件以上あるプロジェクトでは、辞書と関係の薄いクエリでも近い順に 3 件が埋まります。そのまま画面に出すと常に 3 件並ぶので、出すかどうかは `score` を見て呼び出し側で決めてください（`score` の目安になる値は埋め込みモデルによって変わるため、決め打ちのしきい値は用意していません）。
+
+`_dictionary` は状態によって 3 通りになります。
+
+- **キーが無い**: `keyword` 検索、キーワード検索への劣化時、有効な説明付きのエントリが 1 つも無いプロジェクト（反映待ちの間を含む）、辞書の検索が一時的に失敗したとき
+- **空配列**: 辞書は引けたが返せるエントリが無かった（通常は起きません）
+- **配列**: ヒットあり
+
+キーの有無は設定だけで決まるものではないため、`_dictionary` は常に省略され得るものとして扱ってください。
+
+> [!WARNING]
+> 辞書のヒットにはグループによる権限のフィルタが掛かりません。特定のグループにだけ見せたい情報は説明に書かないでください。
+>
+> Consumer SDK の検索には `_dictionary`
+> は付きません。辞書エントリには公開・下書きの区別が無いためです。
+>
+
+## 表記の同一視
+
+エントリは見出し語を正規化した値で識別されます。表記が違っても正規化後に同じなら同じエントリで、検索時の照合にも同じ正規化が使われます。
+
+以下の違いは同じ語として扱われます。
+
+- 全角と半角（`ＯＲＺ－１２００Ｘ` = `orz-1200x`）
+- 大文字と小文字
+- 半角カナと全角カナ（`ｵﾘｽﾞﾑ` = `オリズム`）
+- ハイフン・マイナス・ダッシュ類（`ORZ‐1200X` = `ORZ−1200X` = `orz-1200x`）
+- 前後の空白、連続する空白、全角空白
+- 貼り付けで紛れ込む不可視文字（ゼロ幅スペースなど）
+
+長音記号 `ー` はハイフンに畳まないため、`コーヒー` と `コ-ヒ-` は別の語です。
+
+見出し語と同義語は入力した表記のまま保存・返却され、正規化した値は検索の照合にだけ使われます。なお同義語のうち、正規化すると見出し語と同じになるもの・先に指定した同義語と同じになるものは、登録時に取り除かれます。
+
+## 使い方
+
+CMS SDK の `cmsClient.dictionary` から操作します。テーブルの配下ではなくクライアント直下にあります。
+
+辞書の登録・更新・削除には、プロジェクト内のいずれかのテーブルへの書き込み権限が必要です（[権限](./schema/authority.md) でどのテーブルにも書けないロールでは 403 になります）。一覧・取得は認証だけで行えます。
+
+### エントリの登録
+
+`add()` に登録したいエントリの配列を渡します。1 回のリクエストで複数のエントリを登録できます。
+
+```ts copy
+await cmsClient.dictionary.add([
+  {
+    term: "全熱交換型換気システム",
+    synonyms: ["マニ丸", "ロスナイ式"],
+    description: "熱交換素子で温度と湿度を回収しながら換気する第一種換気設備。",
+  },
+]);
+```
+
+`description` と `synonyms` は省略できます。`enabled` を `false` にすると、登録はしても検索には効かない状態で作れます（既定は `true`）。
+
+> [!WARNING]
+> `add()` は、正規化した見出し語が既存のエントリと一致した場合そのエントリを**丸ごと置き換えます**。渡さなかったフィールドは前の値のままにはならず、初期値に戻ります（`synonyms`
+> は `[]`、`description` は `null`、`enabled` は `true`）。
+>
+> 一部のフィールドだけを変えたいときは [`update()`](#エントリの部分更新)
+> を使ってください。
+>
+> 置き換えになるので、同じ一覧を投入し直しても重複したエントリは作られません。ID
+> も変わらないので、`_dictionary` などで受け取った ID
+> は投入し直したあとも使えます。一方、1 回のリクエストに同じ見出し語を 2
+> つ入れることはできません（エラーになります）。
+>
+
+### エントリの一覧取得
+
+`list()` でエントリの一覧を取得します。登録が古い順に返り、`enabled: false` のエントリも含まれます。
+
+```ts copy
+const { contents, totalCount } = await cmsClient.dictionary.list();
+```
+
+`query` で絞り込み、`limit` と `offset` でページングできます。
+
+```ts copy
+await cmsClient.dictionary.list({ query: "換気", limit: 50, offset: 0 });
+```
+
+`query` の当たり方は見出し語と同義語で違います。見出し語は部分一致、同義語は完全一致です。どちらも正規化して突き合わせるので、半角で登録した語を全角で検索できます。正規化して空になる値（空白のみなど）は未指定と同じ扱いで、絞り込みません。
+
+`limit` を指定しない場合は 100 件まで取得されます。
+
+### エントリの取得
+
+`get()` に ID を渡して 1 件を取得します。
+
+```ts copy
+const entry = await cmsClient.dictionary.get(entryId);
+```
+
+### エントリの部分更新
+
+`update()` は渡したフィールドだけを変更します。渡さなかったフィールドは変わりません。
+
+```ts copy
+await cmsClient.dictionary.update(entryId, { synonyms: ["マニ丸", "1200X"] });
+```
+
+`description` に `null` を渡すと説明を消せます。説明が無くなったエントリは検索結果に返らなくなりますが、同義語による言い換えは引き続き効きます。
+
+```ts copy
+await cmsClient.dictionary.update(entryId, { description: null });
+```
+
+一時的に効果を止めたいときは `enabled` を `false` にします。削除せずに両方の経路を止められます。
+
+```ts copy
+await cmsClient.dictionary.update(entryId, { enabled: false });
+```
+
+`term` を変えると、エントリを識別する値も一緒に変わります。変更後の表記が既にある別のエントリと同じになる場合はエラーになります。このとき同義語も組み直されるため、新しい見出し語と同じになる同義語は（`synonyms` を渡していなくても）取り除かれます。
+
+### エントリの削除
+
+`delete()` に ID を渡します。
+
+```ts copy
+await cmsClient.dictionary.delete(entryId);
+```
+
+## 検索への反映タイミング
+
+同義語による言い換えは、登録・更新した直後の検索から効きます。
+
+用語解説の検索対象化（`_dictionary`）は非同期です。エントリを変更すると裏で辞書の索引が作り直され、それが終わってから検索結果に現れます。所要時間は説明付きのエントリの件数によって変わります。無効化・削除で検索結果から消える場合も同じ経路を通ります。
+
+説明付きの有効なエントリが 1 つも無くなると辞書の索引自体が削除され、以降の検索では `_dictionary` が付かなくなります。
+
+## 上限値
+
+| 対象                                  | 上限               |
+| ------------------------------------- | ------------------ |
+| 1 回の `add()` で登録できるエントリ数 | 500 件（1 件以上） |
+| 見出し語・同義語 1 つあたりの文字数   | 200 文字           |
+| 1 エントリの同義語の数                | 50 個              |
+| 説明の文字数                          | 2000 文字          |
+| `list()` の `limit`                   | 500（既定 100）    |
+
+見出し語・同義語・説明には制御文字を含められません（タブ・改行・復帰は除きます。説明は複数行で登録できます。見出し語・同義語では空白に畳まれます）。また空白だけの見出し語・同義語・説明は登録できません。
+
+## 監査ログ
+
+エントリの登録・更新・削除は [監査ログ](./console/audit-logs.md) に記録されます。

package/dist/docs/features/draft.md

@@ -0,0 +1,241 @@
+<!-- source: docs/src/app/features/draft/page.mdx -->
+
+# 下書き管理
+
+下書き管理機能を使用すると、コンテンツを公開前に下書きとして保存し、編集・確認してから公開できます。この機能はコンテンツの品質管理やワークフロー管理に役立ちます。
+
+以下の機能を提供します。
+
+- コンテンツを下書き状態で保存
+- コンテンツの公開ステータスを管理
+- 下書きと公開コンテンツを並行管理
+- 公開、非公開をスケジュール予約
+
+## ユースケース例
+
+### コンテンツの事前作成
+
+下書き管理機能を活用すれば、リリース情報やシステムメンテナンスなどの重要なお知らせを事前に準備し、指定日時に自動公開できます。
+
+### 期間限定コンテンツの管理
+
+下書き管理機能の公開・非公開スケジュール設定を組み合わせることで、季節的なキャンペーンやセール、イベント情報など、特定の期間だけ表示したいコンテンツを効率的に管理できます。
+
+1. 事前に下書きとしてコンテンツを作成
+1. キャンペーン開始日時に自動公開
+1. 終了日時に自動的に非公開
+1. 翌年も使用できるコンテンツは下書き状態で保存し、必要に応じて更新や複製して再利用
+
+### コンテンツの承認ワークフロー
+
+コンテンツ公開前に品質管理のための承認プロセスが必要な場合があります。下書き管理機能を使用すると、コンテンツ制作者とレビュワーが効率的に協働できるワークフローを構築できます。
+
+例えば企業ブログでは、マーケティングチームのライターが記事を下書きとして作成し、編集者や法務担当者がレビューします。修正が必要な場合は下書き状態のままコンテンツを更新できるため、公開サイトに影響を与えることなく何度でも編集可能です。承認が得られたら下書きコンテンツを公開できます。
+
+## 機能の有効化
+
+スキーマで [テーブル](./schema/database.md) ごとに有効化できます。`enableDrafts` プロパティを `true` に設定します。
+
+```ts copy filename="orizm.config.ts" showLineNumbers {7}
+import { defineConfig } from "@orizm/cli/config";
+
+export default defineConfig({
+  tables: {
+    blog: {
+      columns: {},
+      enableDrafts: true,
+    },
+  },
+});
+```
+
+## 予約カラム
+
+下書き管理機能を有効化すると、テーブルに予約カラムが追加されます。
+
+### \_draft
+
+コンテンツがドラフトかどうかを示すフラグです。
+
+`true` の場合は下書き、`false` の場合は公開コンテンツです。
+
+直接書き換えることはできません。
+
+### \_published
+
+コンテンツが公開中かどうかを示すフラグです。
+
+`true` の場合は公開中、`false` の場合は非公開です。公開されていれば下書きデータに対しても `true` になります。
+
+直接書き換えることはできません。
+
+### publishedAt
+
+コンテンツがはじめて公開状態になった日時です。
+
+ISO 8601 形式の文字列で構成されます。（例: `2025-01-01T00:00:00.000Z`）
+
+### scheduledPublishAt
+
+コンテンツを公開する予定の日時です。
+
+ISO 8601 形式の文字列で構成されます。（例: `2025-01-01T00:00:00.000Z`）
+
+このカラムに値を設定すると、指定した日時に自動で公開されます。
+
+### scheduledUnpublishAt
+
+コンテンツを非公開にする予定の日時です。
+
+ISO 8601 形式の文字列で構成されます。（例: `2025-01-01T00:00:00.000Z`）
+
+このカラムに値を設定すると、指定した日時に自動で非公開になります。
+
+## 使い方
+
+SDKを使った下書き管理機能の使い方を説明します。
+
+### コンテンツの作成
+
+コンテンツを作成するにはCMS SDKを使用します。
+
+下書きコンテンツとして作成するには `create()` の第二引数のオブジェクトに `draft: true` を指定します。
+
+```ts copy
+await cmsClient.tables.blog.create(content, { draft: true });
+```
+
+公開コンテンツとして作成するには `create()` の第二引数を省略するか、オブジェクトに `draft: false` を指定します。
+
+```ts copy
+await cmsClient.tables.blog.create(content);
+```
+
+### コンテンツの更新
+
+コンテンツを更新するにはCMS SDKを使用します。
+
+以下のケースでは `update()` の第三引数のオブジェクトに `draft: true` を指定します。
+
+- すでに公開されているコンテンツに下書きを作成したい
+- 下書きコンテンツを更新したい
+
+```ts copy
+await cmsClient.tables.blog.update(id, content, { draft: true });
+```
+
+公開コンテンツを更新するには `update()` の第三引数を省略するか、オブジェクトに `draft: false` を指定します。
+
+```ts copy
+await cmsClient.tables.blog.update(id, content);
+```
+
+> [!NOTE]
+> update()
+> では下書きコンテンツを更新しつつ、公開状態にすることはできません。代わりに、下書きコンテンツに対して
+> `publish()` を使用します。
+
+### 下書きの公開
+
+下書きコンテンツを公開するにはCMS SDKの `publish()` を使用します。
+
+```ts copy
+await cmsClient.tables.blog.publish(id);
+```
+
+第二引数にコンテンツのデータを渡すことで、更新と同時に公開することもできます。
+
+```ts copy
+await cmsClient.tables.blog.publish(id, content);
+```
+
+### コンテンツの非公開化
+
+コンテンツを非公開にするにはCMS SDKの `unpublish()` を使用します。
+
+```ts copy
+await cmsClient.tables.blog.unpublish(id);
+```
+
+### コンテンツの削除
+
+コンテンツを削除するにはCMS SDKを使用します。
+
+下書きコンテンツを削除するには `delete()` の第二引数のオブジェクトに `draft: true` を指定します。
+
+```ts copy
+await cmsClient.tables.blog.delete(id, { draft: true });
+```
+
+コンテンツを完全に削除するには `delete()` の第二引数を省略するか、オブジェクトに `draft: false` を指定します。
+
+```ts copy
+await cmsClient.tables.blog.delete(id);
+```
+
+### コンテンツの取得
+
+コンテンツを取得するにはCMSではCMS SDKを使用します。ConsumerではConsumer SDKを使用します。
+
+#### CMS SDK
+
+CMS SDKでは以下のメソッドで下書きコンテンツの取得が可能です。
+
+- **`get()`**: 第二引数で `draft: true` を指定
+- **`getByUnique()`**: `get()` と同様に第二引数で `draft: true` を指定
+- **`list()`**: 第一引数で `draft: true` を指定
+
+CMS SDKでは特に指定しなくても `draft: true` がデフォルトです。
+
+```ts copy
+await cmsClient.tables.blog.get(id, { draft: true });
+await cmsClient.tables.blog.getByUnique({ slug: "example" }, { draft: true });
+await cmsClient.tables.blog.list({ draft: true });
+```
+
+#### Consumer SDK
+
+Consumer SDKでは以下のメソッドで下書きコンテンツの取得が可能です。
+
+- **`get()`**: 第二引数で `draft: true` を指定
+- **`getByUnique()`**: `get()` と同様に第二引数で `draft: true` を指定
+- **`list()`**: 第一引数で `draft: true` を指定
+
+Consumer SDKで下書きコンテンツを取得するには `draft: true` を指定する必要があります。
+
+```ts copy
+await consumerClient.tables.blog.get(id, { draft: true });
+await consumerClient.tables.blog.getByUnique(
+  { slug: "example" },
+  { draft: true },
+);
+await consumerClient.tables.blog.list({ draft: true });
+```
+
+### 下書きコンテンツの公開予約
+
+下書きコンテンツを公開予約するにはCMS SDKの `update()` で下書きデータに対して、`scheduledPublishAt` に公開予約日時を設定します。
+
+```ts copy
+await cmsClient.tables.blog.update(
+  id,
+  {
+    scheduledPublishAt: "2025-01-01T00:00:00.000Z",
+  },
+  { draft: true },
+);
+```
+
+公開処理が完了すると `scheduledPublishAt` に設定されていた値はクリアされます。
+
+### 公開コンテンツの非公開予約
+
+公開コンテンツを非公開予約するにはCMS SDKの `update()` で公開データに対して、`scheduledUnpublishAt` に非公開予約日時を設定します。
+
+```ts copy
+await cmsClient.tables.blog.update(id, {
+  scheduledUnpublishAt: "2025-01-01T00:00:00.000Z",
+});
+```
+
+非公開処理が完了すると `scheduledUnpublishAt` に設定されていた値はクリアされます。

package/dist/docs/features/form/about.md

@@ -0,0 +1,83 @@
+<!-- source: docs/src/app/features/form/about/page.mdx -->
+
+# フォーム管理の概要
+
+フォーム管理機能を使用すると、WEBサイトにお問い合わせや資料請求などのフォームを簡単に設置できます。フォームの設定やデザインをカスタマイズし、送信されたデータを管理できます。
+
+以下の特徴があります。
+
+- Webサイトにフォームを設置
+- [フォームエディター](./editor.md) で構成を直感的に編集
+- フォームのデザインをカスタマイズ可能
+- フォームから送信されたデータを管理
+
+## 機能の有効化
+
+スキーマで [テーブル](../schema/database.md) ごとに有効化できます。`enableForm` プロパティを `true` に設定します。`formOptions` プロパティでフォームのオプション設定ができます。
+
+```ts copy filename="orizm.config.ts" showLineNumbers {21-34}
+import { defineConfig } from "@orizm/cli/config";
+
+export default defineConfig({
+  tables: {
+    form: {
+      columns: {
+        key: {
+          type: "string",
+          required: true,
+          pattern: "^[0-9a-z-]+$",
+        },
+        displayName: {
+          type: "string",
+          required: true,
+        },
+        body: {
+          type: "json",
+        },
+      },
+      indexes: [{ columns: ["key"], unique: true }],
+      enableForm: true,
+      formOptions: {
+        submissionColumns: {
+          status: {
+            type: "string",
+            pattern: /^(open|in_progress|closed|trashed)$/,
+            default: "open",
+            required: true,
+          },
+          memo: {
+            type: "string",
+          },
+        },
+      },
+    },
+  },
+});
+```
+
+この `form` テーブルには、フォームに関するメタデータを保存します。`key` カラムにはフォームを特定するための一意なキーを設定し、`body` カラムにはフォームの構造をJSON形式で保存します。
+
+### submissionColumns
+
+フォーム機能では、フォームから送信されたデータ（以下、受信データ）も管理できます。これを利用してCMSに受信箱機能を実装できます。
+
+`formOptions.submissionColumns` で受信箱に任意のカラムを追加できます。先の例では、受信データを管理するための `status` と `memo` カラムを追加しています。
+
+- **statusカラム**: 受信データのステータスを保存する
+- **memoカラム**: 受信データに対するメモを保存する
+
+## 予約カラム
+
+フォーム管理機能を有効化すると、テーブルに予約カラムが追加されます。
+
+### formSchema
+
+フォームの項目やバリデーションルールなどのスキーマです。JSON形式で保存されます。
+
+[フォームエディター](./editor.md) と組み合わせて使用します。
+
+## 次のステップ
+
+フォーム管理機能を使うには、フォームエディターを導入する必要があります。次のステップでは、フォームエディターの導入方法と実装方法を説明します。
+
+- [フォームエディター](./editor.md)