MCPでmicroCMSのブログを構築する — AIエージェントに任せられた範囲、任せられなかった範囲
加瀬 碧大（取締役副社長 兼 CTO）公開日: 最終更新: 
- microCMS
- MCP
- Claude Code
- Next.js
このテックブログのコンテンツ基盤は、AIエージェント（Claude Code）と microCMS MCPサーバーを使って組み立てました。結論は次のとおりです。
自動化できた範囲: スキーマ定義の作成、コンテンツとメディアの投入、アプリケーション側の実装。
人の操作が必要だった範囲: APIとフィールドの新規作成、Webhook設定、APIキーの権限設定。
この線引きはMCPサーバーが提供するツールを見れば着手前に分かります。先に把握しておくと、一番時間のかかる工程で足を止めずに済みます。
MCPでできること・できないこと
microCMS MCPサーバーが提供するツールを実際に展開して確認したところ、担当範囲は次のように分かれていました。
MCPでできる
既存スキーマの参照
コンテンツの作成・更新・削除
メディアのアップロード
下書きの作成
管理画面でしかできない
APIとフィールドの新規作成
Webhookの設定
APIキーの権限設定
コンテンツの並び替え
スキーマを作成するツールは無く、Management API にも該当するエンドポイントがありません。つまりCMSの器そのものを用意する工程には、現状どうしても人の操作が入ります。裏を返せば、器さえできれば設計・入稿・実装はAIに任せられます。器の用意まで自動化できると思って計画を立てると、そこで手が止まります。
設計で効いた判断
分類と著者は独立APIに切り出す
カテゴリをセレクトフィールドではなく別APIにし、バッジの配色もCMS側のセレクトで持たせました。カテゴリを増やすときにコードを触らなくて済みます。
docs/microcms-schemas/blog-categories.json
{
"fieldId": "tone",
"name": "配色",
"kind": "select",
"required": true,
"selectItems": [
{ "value": "primary" },
{ "value": "yellow" },
{ "value": "aqua" },
{ "value": "navy" }
]
}著者も同様に独立APIにしました。判断の根拠は2つです。ひとつは事実として、著者名と役職は検索エンジンが評価する情報（E-E-A-T）に含まれること。もうひとつは運用上の判断で、記事ごとに肩書きを書くと表記ゆれが構造的に発生するため、一箇所で直せる形にしたいということです。
記事内のフィールドで持つ選択肢もあります。API枠を消費せず、著者が1〜2人のうちは手数も変わりません。人数が増えるか、肩書きが変わる見込みがあるなら独立APIにしておくと後が楽です。
本文はブロックの積み上げにする
本文を単一のリッチエディタにせず、繰り返しフィールド＋カスタムフィールドで組み立てる方式にしました。見出し・段落・コード・画像・FAQなどをブロックとして積みます。
- 描画を完全に制御できる（HTMLをパースして推測する処理が要らない）
- 見出しブロックから目次とページ内アンカーを機械的に作れる
- FAQブロックをそのままFAQPage構造化データに変換できる
- コードブロックの言語が構造化されているので、ビルド時にハイライトできる
AI検索に引用されるかどうかは、文章の中身だけでなく構造から機械的に意味を取り出せるかに左右されます。ブロック方式はその土台になります。
実際に踏んだ3つのエラー
1. selectItems.id の形式
スキーマのインポートが「selectItems.id の形式が誤っています」で弾かれ続けました。既存APIをManagement APIで取得すると bcf026 のような6文字のIDが入っていたので同じ形式で作ったのですが、これが原因でした。
2. PUT は新規作成専用
コンテンツIDを指定した PUT は作成専用で、既存コンテンツには使えません。スクリプトを再実行できるようにするなら、409相当のエラーを見て PATCH に切り替える必要があります。
{"message":"Content is already exists. If you want update, please use PATCH request."}3. 画像フィールドはURL文字列
Write APIで画像フィールドに値を入れるときは、レスポンスと同じ { url, width, height } の形ではなくURLの文字列を渡します。オブジェクトだと 'avatar' has unexpected data type. になります。
APIのレスポンス形式と、書き込み時に受け付ける形式は同じとは限らない。
ビルド時取得でハマる前に対処したこと
このサイトは Next.js の output: 'export' による完全静的構成で、コンテンツはビルド時に全件取得します。ここで注意が要るのは、next build がプリレンダリングをCPU数分の別プロセスで並列に行うことです。
各ページから素直にAPIを呼ぶと、同じリクエストがワーカー数だけ同時に飛びます。転送量が跳ねるうえ、同時接続が集中して接続断（ECONNRESET）でビルドが落ちます。対処は、ビルド前に直列で1回ずつ取得してキャッシュに置き、ビルド中のワーカーはそれを読むだけにすることです。
package.json
"build": "node --env-file-if-exists=.env.local scripts/fetch-cms.mts && next build && node scripts/generate-llms.mts"これでAPI呼び出しは1ビルドあたりエンドポイントごとに1回に収まります。
よくある質問
Q. microCMS MCPサーバーでAPI（スキーマ）を作れますか？
執筆時点（2026年9月・microcms-mcp-server 0.11.0）では作れませんでした。MCPサーバーが持つのは参照系（microcms_get_api_list / microcms_get_api_info）とコンテンツ・メディアの操作で、スキーマを作成・変更するツールは同梱されていません。Management APIにも該当エンドポイントが見当たらず、APIとフィールドの作成は管理画面から行いました。今後提供される可能性はあるので、最新の状況は公式ドキュメントでご確認ください。
Q. Webhookの設定もAIに任せられますか？
執筆時点では、WebhookとAPIキーの権限設定はいずれも管理画面からの操作が必要でした。ただし設定値そのものはAI側で用意できます。イベント名・対象リポジトリ・通知タイミングを一覧にしておけば、管理画面での作業は転記だけで済みます。
なおWebhookはAPI単位の設定なので、記事・カテゴリ・著者のように複数APIに分けた場合は、そのすべてに設定しないと反映漏れが起きます。設定漏れはチェックリストにして潰すのが確実です。
Q. スキーマ定義はどこに置くべきですか？
リポジトリに置くことを勧めます。管理画面のインポートが読み込めるJSONをそのまま docs/ 配下に置いておけば、設計ドキュメントと実際のスキーマが乖離しませんし、環境を作り直すときにも再利用できます。
参考
microCMS公式: データ転送量を削減するhelp.microcms.ioまとめ
- MCPに任せられるのはコンテンツとメディアの操作。スキーマ・Webhook・キー権限は管理画面
- 自動化できない工程は「スキーマJSONを生成してインポートさせる」形にすると最小化できる
- 既存APIから取得したスキーマをそのまま入力に使い回さない（IDの形式が古いことがある）
- 静的サイトのビルド時取得は、必ずビルド前に1回だけ取得してキャッシュする
