microCMSの記事が反映されない原因|Webhookと再ビルドを実測
VIEW →
microCMS公式のリモートMCPをCodexへ接続し、このサイトで管理している記事の取得から、検証用記事の下書き作成・更新まで試しました。
結論として、microCMS MCPをCodexへ設定すると、自然言語の指示でAPI情報や記事を取得できます。書き込み権限があれば、記事の下書き作成と更新も可能です。
今回、実際に確認できた内容は次のとおりです。
今回は安全性を確認するため、最初は読み取り操作だけに限定しています。書き込みの検証では公開禁止と明記した専用記事を使い、既存記事の変更、公開、削除は行っていません。
この記事では、CodexからmicroCMS公式MCPへ接続する設定、実際に使った指示、取得できた情報、下書き作成・更新の結果を順番に紹介します。
microCMSは2026年8月24日、公式のリモートMCPサーバーを公開しました。
MCPは、CodexなどのAIクライアントから外部サービスの情報や機能を利用するための仕組みです。microCMS公式MCPを接続すると、AIとの会話を通じてコンテンツやAPI情報を取得し、権限に応じて記事の作成や更新も行えます。
以前からOSS版のmicroCMS MCP Serverは提供されていましたが、現在の公式リモート版とは接続方法が異なります。
名称 | 実行場所 | 主な違い |
|---|---|---|
microCMS MCP | microCMSがホスティング | 接続先URLとAPIキーを設定して利用する |
microCMS MCP Server | 利用者のローカル環境 | Node.jsでMCPサーバーを起動する |
今回使用したのは、microCMSがホスティングする「microCMS MCP」です。利用者側でサーバーを起動・運用する必要はありません。
執筆時点ではベータ版です。利用できる機能や設定は変わることがあるため、導入時にはmicroCMS MCPの公式ドキュメントも確認してください。
今回の環境は次のとおりです。
項目 | 内容 |
|---|---|
検証日 | 2026年8月29日 |
MCPクライアント | Codex |
接続先 | microCMS公式リモートMCP |
対象サイト | saijo-web.com |
対象API |
|
読み取り検証 | API一覧、フィールド構成、最新記事3件の取得 |
書き込み検証 | 検証用記事の下書き作成と、その下書きの更新 |
行っていない操作 | 既存記事の変更、公開、削除 |
読み取りと書き込みを一度に許可せず、操作範囲を分けました。最初にコンテンツモデルを確認してから下書きを作成したことで、必須フィールドやカテゴリーの指定を推測せずに済みました。
接続には、microCMSのサービスIDとAPIキーが必要です。
APIキーは、Webサイト本体で使用しているものを流用せず、AI操作専用として分ける方が管理しやすくなります。microCMSの公式ドキュメントでも、AI操作専用のAPIキーを作り、必要な操作だけを許可する方法が推奨されています。
Codexのユーザー設定は~/.codex/config.tomlに記述します。APIキーを設定ファイルへ直接書かない場合は、Codexが対応しているbearer_token_env_varを使用できます。
[mcp_servers.microcms]
url = "https://mcp.microcms.io/mcp/YOUR_SERVICE_ID"
bearer_token_env_var = "MICROCMS_API_KEY"
YOUR_SERVICE_IDは、接続するmicroCMSサービスのIDへ置き換えます。MICROCMS_API_KEYには、Codexを起動する環境から参照できる環境変数名を指定します。
microCMSの公式ドキュメントには、http_headersへBearer形式のAPIキーを設定する例も掲載されています。どちらの方法でも、実際のAPIキーをGit管理しているファイル、記事本文、画面共有用の画像へ含めないようにします。
Codex側のMCP設定項目は、OpenAIのCodex設定リファレンスで確認できます。
接続後、最初にCodexへ次のように指示しました。
microCMSとの接続確認をしてください。
1. 利用可能なAPI一覧を取得
2. コラムAPIのフィールド構成を取得
3. 最新記事を3件取得
この段階では、作成・更新・公開・削除は禁止です。
「接続を確認して」だけで終わらせず、許可する読み取り操作と禁止する書き込み操作を同時に指定しています。
実行結果として、microCMS内に次の2つのリスト形式APIがあることを取得できました。
API名 | エンドポイント | 形式 |
|---|---|---|
コラム |
| リスト形式 |
カテゴリ |
| リスト形式 |
続けてblogsのスキーマを取得すると、記事の作成に必要なフィールドも確認できました。
フィールド | 種類 | 必須 | 用途 |
|---|---|---|---|
| テキスト | 必須 | 記事タイトル |
| テキスト | 必須・重複不可 | URLに使用するスラッグ |
| 日付 | 必須 | 投稿日 |
| 画像 | 任意 | アイキャッチ画像 |
| 複数コンテンツ参照 | 必須 |
|
| 繰り返し | 任意 | リッチエディタまたはHTMLによる本文 |
| テキストエリア | 任意 | 記事の抜粋 |
contentrepeatでは、リッチエディタ用のricheditorと、HTML入力用のhtmlという2種類のカスタムフィールドが使われていました。
最新記事3件として取得できたのは、次の記事です。
ここまでの操作では、microCMS内のデータを変更していません。
読み取り操作を確認したあと、書き込み検証用の記事を1件だけ作成しました。
記事タイトルには「検証用・公開禁止」と明記し、通常の記事と見分けられる状態にしています。カテゴリーは、実在するmicroCMSカテゴリーを指定しました。
同じ操作を試す場合は、作成対象と禁止する操作を一緒に指定します。
blogs APIに検証用記事を1件、下書きとして作成してください。
- タイトルの先頭に「検証用・公開禁止」と付ける
- 既存記事は変更しない
- 公開しない
- 削除しない
今回設定した主な内容は次のとおりです。
フィールド | 設定内容 |
|---|---|
タイトル |
|
スラッグ | 検証日時を含む重複しない文字列 |
投稿日 | 検証日時 |
カテゴリー |
|
本文 | 下書き作成の確認用本文 |
公開状態 | 下書き |
下書き作成を実行すると、新しいコンテンツIDが返り、microCMS上に検証用記事が作成されました。公開記事を作成するツールは使用していません。
この検証で重要だったのは、先にAPIスキーマとカテゴリーIDを取得したことです。必須項目を確認せずに本文だけを渡すのではなく、現在のコンテンツモデルに合わせたデータを指定できました。
次に、作成した検証用記事と同じコンテンツIDを指定し、下書き専用の更新操作を実行しました。
更新時も、対象と公開状態を明示します。
先ほど作成した検証用下書きだけを更新してください。
- タイトル、抜粋、本文を更新する
- 下書き状態を維持する
- 既存記事は変更しない
- 公開・削除は行わない
更新した内容は、タイトル、抜粋、本文です。タイトルには「更新確認済み」を追加し、本文も下書き作成後に更新したことが分かる内容へ変更しました。
更新処理でも作成時と同じコンテンツIDが返り、対象の下書きを更新できました。公開中の記事へ反映する更新操作や、公開状態を変更する操作は行っていません。
更新後、通常の公開コンテンツ一覧に対象IDを指定して取得したところ、結果は0件でした。検証用記事は公開コンテンツとして取得されず、下書きのままです。
これで、CodexからmicroCMS公式MCPを通じて、次の一連の操作を確認できました。
microCMS公式MCPでは、下書き作成、公開記事の作成、下書きだけの更新、公開状態の変更、削除が別のツールとして用意されています。
そのため、記事運用では「microCMSへ反映して」という一つの指示へすべての操作をまとめず、許可する範囲を具体的に指定した方が安全です。
私の運用では、次のように操作を分けます。
microCMS側のAPIキー権限だけでなく、Codex側で利用可能なMCPツールも必要な範囲へ絞れます。取得だけを行う環境では、作成・更新・削除のツールを無効にする方法も有効です。
今回のAPIキーでは、記事の取得、下書き作成、下書き更新は実行できました。一方、マネジメントAPIによるコンテンツメタデータの取得はForbiddenとなり、その操作は許可されていませんでした。MCPへ接続しただけですべての操作が可能になるわけではなく、実行範囲はAPIキーの権限に従います。
今回のblogs APIには、必須の日付やカテゴリー、繰り返しフィールド内のカスタムフィールドがあります。
Codexから先にAPIスキーマを取得することで、現在のフィールド構成に合わせて下書きデータを組み立てられました。コンテンツモデルを別の資料へ転記してAIへ渡す必要がなく、microCMS側の変更も確認しやすくなります。
読み取り権限だけのAPIキーでは、書き込みツールを実行できません。下書き作成や更新を行う場合も、必要な権限だけを付けた専用キーを用意できます。
AIへの文章上の指示だけに頼らず、microCMS側の権限でも操作範囲を制限できる点は、実運用で重要です。
Codexで原稿を作成したあと、microCMSへ下書きとして反映し、管理画面やプレビューで内容を確認してから公開できます。
記事の執筆からCMSへの転記までを短縮しつつ、公開判断は人が行う運用にできます。私が進めている記事制作全体の考え方は、AIエージェントとCMSを連携した記事運用でも紹介しています。
このサイトはmicroCMSのコンテンツを取得して静的に生成しています。今回は検証用記事を公開していないため、Webhookや再ビルドによるサイト反映までは確認していません。
下書き作成・更新と、公開後のWebサイトへの反映は別の工程です。このサイトをmicroCMSとNext.jsのSSG構成へ移行した際の実装でも、記事公開後にWebhookでCloudflare Pagesのビルドを実行しています。
公開した記事がサイトへ反映されない場合の確認方法は、別の記事で扱います。
できます。microCMS MCPをCodexへ接続し、必要な書き込み権限を持つAPIキーを設定すれば、記事の作成と更新を指示できます。
今回の検証では、専用記事を下書きとして作成し、その下書きだけを更新しました。
下書き作成用の操作では公開されません。microCMS MCPでは、下書き作成と公開記事の作成、公開状態の変更が別の操作として用意されています。
公開を避けたい場合は、指示の中でも「下書きとして作成」「公開しない」と明記します。
今回使用した公式リモート版のmicroCMS MCPでは、ローカルでMCPサーバーを起動する必要はありません。Codexへ接続先URLとAPIキーを設定して利用します。
Node.jsが必要なのは、OSS版のmicroCMS MCP Serverをローカルで起動する場合です。
必要な権限があれば更新できます。誤更新を防ぐため、記事タイトルだけに頼らずコンテンツIDで対象を特定し、下書きだけを更新するのか、公開中の記事へ反映するのかも指定します。
今回の検証では、CodexからmicroCMS公式MCPへ接続し、API一覧、記事のフィールド構成、最新記事を取得できました。さらに、専用記事を下書きとして作成し、その下書きだけを更新できました。
単に記事本文を生成するだけでなく、既存記事や現在のコンテンツモデルを確認したうえで、microCMSへ下書きとして反映できます。執筆後に管理画面へ移動し、タイトル、抜粋、カテゴリー、本文を一つずつ転記する作業を減らせます。
一方で、既存記事の更新や公開、削除まで同じ権限で無条件に任せる必要はありません。AI操作専用のAPIキーを用意し、microCMS側の権限とCodex側のツールを必要な範囲に絞ることで、操作範囲を管理できます。
私の環境では、まず読み取りだけで接続を確認し、その後に検証専用の記事で下書き作成と更新を試しました。今後の記事運用でも、原稿作成と下書き反映まではCodexで進め、公開は内容と表示を確認してから行う形にします。
