
MCP対応ヘッドレスCMSの使い方 ― Claude Code / CursorからCMSを操作する開発フロー
平原 典彦 — Tesseraを開発しているエンジニア。ヘッドレスCMSとAI連携に関心があります。
Claude CodeやCursorで開発していると、「記事もCMSに入れるところまでエージェントにやらせたい」「スキーマの変更も会話で済ませたい」と思う場面が増えてきます。それを実現する仕組みがMCP(Model Context Protocol)対応のヘッドレスCMSです。
この記事では、Tesseraを例に、MCP対応ヘッドレスCMSの接続から、記事投稿・スキーマ変更・巻き戻しまでの実際の開発フローを順に説明します。
先に用語を2つだけ。
- ヘッドレスCMS: 管理画面と表示(フロントエンド)を切り離し、コンテンツをAPIで配信するCMS。Next.jsやAstroで作ったサイトの「記事の置き場」になります
- MCP: AIエージェント(Claude Code・Cursorなど)に「使える道具(ツール)」を渡す共通規格。CMSがMCPに対応していると、エージェントが直接CMSを読み書きできます
MCP対応で何ができるのか
MCP対応CMSと聞くと「AIが記事を書いて投稿する」を思い浮かべますが、それは半分です。Tesseraでは、大きく分けて次の3つがエージェントからできます。
- コンテンツを読む・書く — 一覧・検索・作成・更新・非公開化。画像のアップロードや、下書きのプレビューリンク発行まで
- スキーマ(コンテンツの構造)を変える — 「記事に
featuredフラグを足して」のような変更を、エージェントが提案し、人間が承認して反映する。新しいコンテンツタイプの追加なら即時に作れます - 安全装置を使う — 書き込み前のdry-run、変更履歴の閲覧、任意時点への巻き戻し、既存データとスキーマの整合性チェック
ポイントは2番です。コンテンツの読み書きだけならAPIラッパーでもできますが、スキーマ(構造)の変更までエージェントに開くと、開発の流れが変わります。「管理画面でフィールドを追加してから、コードを書く」が、「エージェントに一言伝えて、承認ボタンを押す」になります。
接続手順(5分で終わります)
1. APIキーを発行する
管理画面の 設定 → APIキー(/settings/api-keys)から「+ APIキーを発行」を選び、スコープを選びます。
- read_only — 読み取り専用。エージェントに参照だけさせたいとき
- read_write — 読み書き。記事投稿やスキーマ変更提案まで任せるとき
read_onlyキーで接続した場合、書き込み系のツールはエージェントのツール一覧に最初から現れません。「書けると思っていたら書けなかった」という誤解をエージェントに起こさせないための設計です。
2. 設定ファイルに貼る
キーを発行すると、そのまま貼れる接続設定が画面に表示されます。Claude Codeなら、プロジェクト直下の .mcp.json にこう書きます。
{
"mcpServers": {
"tessera": {
"type": "http",
"url": "https://tesseracms.com/api/mcp",
"headers": {
"Authorization": "Bearer tsr_live_xxxxxxxx"
}
}
}
}
Cursorも同じ形式で、.cursor/mcp.json に置きます。設定を保存してエージェントを再起動(または再読み込み)すれば接続完了です。
3. 動作確認
エージェントに一言、聞いてみてください。
このワークスペースにあるコンテンツタイプを一覧して
list_content_types が呼ばれて、定義済みのコンテンツタイプ(例: blogPost・author・category)とフィールド構成が返ってくれば接続できています。
実際の開発フロー
ここからは「ブログ記事を1本出す」を例に、エージェントとのやり取りを追います。かっこ内は、裏で呼ばれているMCPツールです。
まず、構造を読ませる
blogPostのフィールドを教えて。直近の記事も3件見せて
エージェントは get_content_type でスキーマを、list_entries で既存記事を読みます。この「構造を先に読む」が効きます。エージェントは必須フィールド・参照関係・スラッグの命名規則を把握した上で、次の作業に入れます。既存記事を探すときは search_entries(フィールド値の部分一致検索)も使えます。
記事を書いて、投稿する
「MCPの接続手順」というテーマで記事を書いて、下書きとして保存して。カテゴリは技術ブログ、著者は平原
エージェントが本文をMarkdownで書き、create_entry で保存します。参照フィールド(著者・カテゴリ)はIDを渡すだけ。アイキャッチなどのmedia型フィールドには、画像のURLをそのまま書けます(サーバー側が取得してアセット化します)。本文中に貼った外部画像も保存時に自動で取り込まれます。
書き込みの前に、エージェントに確認させることもできます。
保存する前に、問題がないかチェックして
preview_entry_write は、実際には保存せずに(dry-run)、スラッグの重複・必須フィールドの欠落・参照先の存在などを検証して返します。更新の場合は、変更前後の差分も返ります。
人間が確認して、公開する
下書きを自分で確認したいときは、プレビューリンクを出させます。
この記事のプレビューリンクを3日間有効で発行して
create_preview_link が、未公開の記事を閲覧できる期限付きURLを返します。問題なければ、
公開して
で update_entry が status: published に切り替えます。公開予約日時を指定することもできます。
スキーマを変える
ここがMCP対応の本領です。
記事に「注目記事」フラグ(featured, boolean)を追加して
エージェントは propose_content_type_change を mode: update で呼びます。すると、変更は即座には反映されず、承認待ち(pending_approval)としてステージングされます。レスポンスには管理画面へのリンク(approvalUrl)と、影響分析(必須化や削除で影響を受ける既存コンテンツの件数)が含まれます。
人間はそのリンクを開いて差分を確認し、承認ボタンを押して初めて反映されます。承認・却下の操作はMCPツールとして提供していないので、エージェントが自分の提案を自分で通すことはできません。
一方、新しいコンテンツタイプを追加する場合(mode: create)は、承認を挟まず即時に作成されます。既存の構造やコンテンツに影響しないためです。「イベント情報を管理するコンテンツタイプを作って」と頼めば、その場で使える状態になります。
1つ知っておくべき挙動があります。update提案を出した直後にエージェントが get_content_type を呼んでも、承認が終わるまで新しいフィールドは見えません。バグではなく、「未承認の変更が反映済みだ」とエージェントが誤認するのを防ぐための仕様です。承認したら改めて読ませてください。
間違えたら、戻す
エージェントが記事を壊してしまったときは、
この記事の変更履歴を見せて。1つ前の状態に戻して
list_entry_revisions で履歴を確認し、rollback_entry で任意のリビジョンへ戻せます。巻き戻しは上書きではなく新しいリビジョンとして記録されるので、「戻した」こと自体も履歴に残ります。
スキーマ側にも revert_content_type_change があり、直近の承認済み変更を打ち消す提案を1手で作れます(これも承認が必要です)。
なぜエージェントに任せられるのか
「AIにCMSを触らせるのは怖い」という感覚は正しいです。Tesseraがエージェントと本番データの間に置いている安全装置を挙げておきます。
- 提案と反映の分離 — スキーマの更新・削除は必ず人間の承認を経る
- 危険な変更は提案自体が通らない — 値の入っていないフィールドを必須化する、データが入っている参照先を付け替える、といった変更は検証で弾かれます(
validation_failed)。コンテンツタイプの削除も、他から参照されていれば承認できません - 書き込み前のdry-run —
preview_entry_writeで「やったら何が起きるか」だけを先に見られる - すべて記録 — どのAPIキー(=どのエージェント)がいつ何を変えたかがリビジョン履歴に残る
- 巻き戻し —
rollback_entryで任意時点へ - コンテンツタイプ単位の権限 — キーはread_writeのまま、特定のコンテンツタイプだけアクセス遮断にできる。遮断されたものを触ろうとすると
permission_deniedが返る
このあたりの設計思想は、AIに"安全に"書かせるCMSで詳しく書いています。
料金と制限
- 読み取り系は無料プランでもフル開放です。まず接続して、エージェントにコンテンツを読ませるところは無料で試せます
- 書き込み系は、濫用防止のため回数ベースのレート制限があります(超過時は
rate_limitedが返ります) - Tessera側でLLMのコストは発生しません。スキーマ定義や記事本文を生成しているのは接続元のエージェント(Claude Code・Cursor側のモデル)で、Tesseraは受け取った内容を検証・保存するだけです。そのためMCP経由の操作にAIクレジットはかかりません
よくある質問
Q. Cursorでも使えますか? 使えます。MCP(HTTP)に対応したエージェントなら接続できます。設定ファイルの置き場所が違うだけです。
Q. 承認もエージェントにやらせたいのですが できません。意図的に、承認・却下はMCPツールとして提供していません。「AIに任せる」と「勝手に変わる」を分けるための線です。
Q. 大きな画像はどうやって上げますか?
upload_asset(Base64)は5MBまでです。それより大きいファイルは、URLから取り込む import_asset_from_url(20MBまで)か、HTTPのメディアAPI(POST /api/assets、curlで直接投入)を使ってください。詳しくはAIエージェントにCMSのメディアを運用させるで。
Q. 既存のコンテンツがスキーマと食い違っていないか確認したい
check_content_consistency が、型の不一致・必須の欠落・unique違反・選択肢外の値・参照切れを検出して、件数とサンプルを返します。
まとめ
- MCP対応ヘッドレスCMSでは、エージェントがコンテンツの読み書きだけでなくスキーマ(構造)の変更までできる
- 接続は、APIキーを発行して
.mcp.jsonに貼るだけ(5分) - 開発フローは「構造を読ませる → 書かせる → dry-runとプレビューで確認 → 公開」。スキーマ変更は「提案 → 人間が承認 → 反映」(新規タイプの追加は即時)
- 間違えても
rollback_entryで戻せる。承認・ガード・履歴・巻き戻しがあるから任せられる - 読み取りは無料でフル開放。MCP経由の操作にTessera側のAIコストはかからない
「管理画面を開いてフィールドを足す」が「エージェントに一言伝える」に変わると、コンテンツまわりの作業がコードを書くのと同じ感覚になります。まずはread_onlyキーで、エージェントにコンテンツを読ませるところから試してみてください。