スキーマをAIと会話して作る ― 既存の構造を理解した上で提案する
平原 典彦 — Tesseraを開発しているエンジニア。ヘッドレスCMSとAI連携に関心があります。
「記事に著者とタグを足したい」——そう話しかけるだけで、コンテンツモデル（スキーマ）ができる。Tesseraのスキーマ生成AIは、汎用のAI下書き生成とは狙いが違います。AIがこのCMSの構造そのもの（既存のコンテンツタイプ・制約・依存関係）を理解した上で、スキーマを提案・調整するためのものです。
会話でスキーマを組み立てる
やることは、作りたいものを日本語で伝えるだけです。
自然言語の指示から、AIがフィールド構成を提案。追加される項目が「差分」で示される。
指示を受けたAIは、フィールドの型（テキスト・日付・参照…）を判断し、必須/任意まで決めて変更案を差分として提示します。上の例では、カテゴリを既存の category コンテンツタイプへの参照にし、複数件管理される想定なので単体型（singleton）にはしない——といった判断まで、根拠つきで説明します。
そして重要なのが、右側の**「既存のスキーマ・コンテンツへの影響はありません」**という一文。提案の時点で、その変更が既存の型やデータに波及しないかを分析しています。
汎用の「AIでスキーマ生成」と何が違うのか
いま、AIでコンテンツモデルの雛形を作れるCMSは他にもあります。ではTesseraの何が違うのか。既存のスキーマを読んだ上で提案することです。
まっさらな状態にスキーマを1つ生成するだけなら、AIは得意です。難しいのはその先——すでに複数のコンテンツタイプがあり、参照で絡み合っている状態に、新しい変更を安全に足すことです。ここでAIが既存構造を理解していないと、名前がぶつかったり、参照先が壊れたりします。
実際のワークスペースは、こうして複数のコンテンツタイプが積み重なっている。この文脈を踏まえて提案できるかどうかが差になる。
「それ、もう存在します」と言えるAI
たとえば、すでに blogPost があるのに「ブログ記事を作って」と頼むと、Tesseraのスキーマ生成AIはこう返します。
既存の blogPost との衝突を検知し、「既存を編集するのか、別名で新規作成するのか」を確認してくる。
言われたとおりにスキーマを吐き出すのではなく、「それはもうあります。どうしますか？」と立ち止まる。この、既存構造との衝突検出・整合性チェックこそが、汎用のAI生成では埋めにくい部分だと考えています。
承認するまで、何も変わらない
もう1つの柱が、提案と反映の分離です。AIの提案は、どれだけもっともらしくても即座には反映されません。
- 送られた定義はバリデーション（予約語・整合性・既存スキーマとの衝突）を通り、
- 承認待ち（pending）としてステージングされ、
- 人間が差分を確認して承認するまで反映されない
だからAIにスキーマをいじらせても壊れません。「AIに任せる」と「勝手に変わる」は違う、というのがTesseraの設計です。
料金は「使った分だけ」
スキーマ生成チャットのAI利用は、1リクエスト＝1クレジットとして可視化しています（画面にも直近の推定コストが出ます）。読み取り系（GraphQL・MCP）は無料でフル開放。AIを使う部分だけ、透明な従量課金にしています。
まとめ
- 自然言語でスキーマを提案・調整できる。フィールドの型・必須・参照まで判断する
- 汎用のAI生成との差は、既存のスキーマを理解した上で提案すること（衝突検知・整合性チェック）
- 提案は差分で示され、承認するまで反映されない（AIに任せても壊れない）
- AI利用は1リクエスト＝1クレジットの透明な従量課金
「AIがCMSの構造を理解する」——Tesseraのコンセプトが一番はっきり出るのが、このスキーマ生成です。まっさらから作るときも、既存に足すときも、構造を分かっているAIと会話しながら組み立てられます。