Portfolio課題を言葉にして、Webというカタチに変える──
そんな仕事をしています。

microCMS公式MCPをCodexで使う方法|記事取得・下書き作成・更新を検証

microCMS公式のリモートMCPをCodexへ接続し、このサイトで管理している記事の取得から、検証用記事の下書き作成・更新まで試しました。

結論として、microCMS MCPをCodexへ設定すると、自然言語の指示でAPI情報や記事を取得できます。書き込み権限があれば、記事の下書き作成と更新も可能です。

今回、実際に確認できた内容は次のとおりです。

  • microCMS内のAPI一覧を取得できた
  • コラムAPIの必須項目やカスタムフィールドを取得できた
  • 最新の公開記事を3件取得できた
  • 検証専用の記事を下書きとして作成できた
  • 作成した下書きだけを更新できた

今回は安全性を確認するため、最初は読み取り操作だけに限定しています。書き込みの検証では公開禁止と明記した専用記事を使い、既存記事の変更、公開、削除は行っていません。

この記事では、CodexからmicroCMS公式MCPへ接続する設定、実際に使った指示、取得できた情報、下書き作成・更新の結果を順番に紹介します。

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

blogscategories

読み取り検証

API一覧、フィールド構成、最新記事3件の取得

書き込み検証

検証用記事の下書き作成と、その下書きの更新

行っていない操作

既存記事の変更、公開、削除

読み取りと書き込みを一度に許可せず、操作範囲を分けました。最初にコンテンツモデルを確認してから下書きを作成したことで、必須フィールドやカテゴリーの指定を推測せずに済みました。

CodexへmicroCMS公式MCPを設定する

接続には、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

リスト形式

カテゴリ

categories

リスト形式

続けてblogsのスキーマを取得すると、記事の作成に必要なフィールドも確認できました。

フィールド

種類

必須

用途

title

テキスト

必須

記事タイトル

slug

テキスト

必須・重複不可

URLに使用するスラッグ

publishDate

日付

必須

投稿日

eyecatch

画像

任意

アイキャッチ画像

categories

複数コンテンツ参照

必須

categories APIとの関連付け

contentrepeat

繰り返し

任意

リッチエディタまたはHTMLによる本文

content

テキストエリア

任意

記事の抜粋

contentrepeatでは、リッチエディタ用のricheditorと、HTML入力用のhtmlという2種類のカスタムフィールドが使われていました。

最新記事3件として取得できたのは、次の記事です。

  1. 「GPT SitesのSSGサイトでページ遷移が白くなる原因|vinextのRSC配信を修正した記録」
  2. 「AI時代の記事執筆・更新・改善フロー|AIエージェントとCMSを連携した実運用」
  3. 「CodexとGoogle Antigravityを実務で比較|構成はCodex、デザインはAntigravity」

ここまでの操作では、microCMS内のデータを変更していません。

検証専用の記事を下書きとして作成した

読み取り操作を確認したあと、書き込み検証用の記事を1件だけ作成しました。

記事タイトルには「検証用・公開禁止」と明記し、通常の記事と見分けられる状態にしています。カテゴリーは、実在するmicroCMSカテゴリーを指定しました。

同じ操作を試す場合は、作成対象と禁止する操作を一緒に指定します。

blogs APIに検証用記事を1件、下書きとして作成してください。

- タイトルの先頭に「検証用・公開禁止」と付ける
- 既存記事は変更しない
- 公開しない
- 削除しない

今回設定した主な内容は次のとおりです。

フィールド

設定内容

タイトル

[検証用・公開禁止] microCMS MCP動作確認

スラッグ

検証日時を含む重複しない文字列

投稿日

検証日時

カテゴリー

microCMS

本文

下書き作成の確認用本文

公開状態

下書き

下書き作成を実行すると、新しいコンテンツIDが返り、microCMS上に検証用記事が作成されました。公開記事を作成するツールは使用していません。

この検証で重要だったのは、先にAPIスキーマとカテゴリーIDを取得したことです。必須項目を確認せずに本文だけを渡すのではなく、現在のコンテンツモデルに合わせたデータを指定できました。

作成した下書きだけを更新した

次に、作成した検証用記事と同じコンテンツIDを指定し、下書き専用の更新操作を実行しました。

更新時も、対象と公開状態を明示します。

先ほど作成した検証用下書きだけを更新してください。

- タイトル、抜粋、本文を更新する
- 下書き状態を維持する
- 既存記事は変更しない
- 公開・削除は行わない

更新した内容は、タイトル、抜粋、本文です。タイトルには「更新確認済み」を追加し、本文も下書き作成後に更新したことが分かる内容へ変更しました。

更新処理でも作成時と同じコンテンツIDが返り、対象の下書きを更新できました。公開中の記事へ反映する更新操作や、公開状態を変更する操作は行っていません。

更新後、通常の公開コンテンツ一覧に対象IDを指定して取得したところ、結果は0件でした。検証用記事は公開コンテンツとして取得されず、下書きのままです。

これで、CodexからmicroCMS公式MCPを通じて、次の一連の操作を確認できました。

  1. API一覧を取得する
  2. 記事APIのフィールド構成を取得する
  3. 既存の公開記事を取得する
  4. 新しい記事を下書きとして作成する
  5. 作成した下書きだけを更新する

作成・更新・公開は別の操作として扱う

microCMS公式MCPでは、下書き作成、公開記事の作成、下書きだけの更新、公開状態の変更、削除が別のツールとして用意されています。

そのため、記事運用では「microCMSへ反映して」という一つの指示へすべての操作をまとめず、許可する範囲を具体的に指定した方が安全です。

私の運用では、次のように操作を分けます。

  • 接続確認では、取得だけを許可する
  • 新規記事は、明示的な指示がない限り下書きとして作成する
  • 更新対象は、コンテンツIDまたは記事タイトルで特定する
  • 公開中の記事を変更する場合は、対象と変更内容を確認する
  • 公開、公開状態の変更、削除は、それぞれ個別の指示がある場合だけ行う

microCMS側のAPIキー権限だけでなく、Codex側で利用可能なMCPツールも必要な範囲へ絞れます。取得だけを行う環境では、作成・更新・削除のツールを無効にする方法も有効です。

今回のAPIキーでは、記事の取得、下書き作成、下書き更新は実行できました。一方、マネジメントAPIによるコンテンツメタデータの取得はForbiddenとなり、その操作は許可されていませんでした。MCPへ接続しただけですべての操作が可能になるわけではなく、実行範囲はAPIキーの権限に従います。

実際に使って分かったこと

自然言語の指示でも、現在のコンテンツモデルに合わせて操作できる

今回のblogs APIには、必須の日付やカテゴリー、繰り返しフィールド内のカスタムフィールドがあります。

Codexから先にAPIスキーマを取得することで、現在のフィールド構成に合わせて下書きデータを組み立てられました。コンテンツモデルを別の資料へ転記してAIへ渡す必要がなく、microCMS側の変更も確認しやすくなります。

操作の可否はAPIキーの権限で制御できる

読み取り権限だけのAPIキーでは、書き込みツールを実行できません。下書き作成や更新を行う場合も、必要な権限だけを付けた専用キーを用意できます。

AIへの文章上の指示だけに頼らず、microCMS側の権限でも操作範囲を制限できる点は、実運用で重要です。

「下書き」と「公開」を分けると運用へ組み込みやすい

Codexで原稿を作成したあと、microCMSへ下書きとして反映し、管理画面やプレビューで内容を確認してから公開できます。

記事の執筆からCMSへの転記までを短縮しつつ、公開判断は人が行う運用にできます。私が進めている記事制作全体の考え方は、AIエージェントとCMSを連携した記事運用でも紹介しています。

公開後のサイト反映は今回の検証範囲に含めていない

このサイトはmicroCMSのコンテンツを取得して静的に生成しています。今回は検証用記事を公開していないため、Webhookや再ビルドによるサイト反映までは確認していません。

下書き作成・更新と、公開後のWebサイトへの反映は別の工程です。このサイトをmicroCMSとNext.jsのSSG構成へ移行した際の実装でも、記事公開後にWebhookでCloudflare Pagesのビルドを実行しています。

公開した記事がサイトへ反映されない場合の確認方法は、別の記事で扱います。

よくある質問

CodexからmicroCMSへ記事を入稿できますか?

できます。microCMS MCPをCodexへ接続し、必要な書き込み権限を持つAPIキーを設定すれば、記事の作成と更新を指示できます。

今回の検証では、専用記事を下書きとして作成し、その下書きだけを更新しました。

下書きを作成すると、そのまま公開されますか?

下書き作成用の操作では公開されません。microCMS MCPでは、下書き作成と公開記事の作成、公開状態の変更が別の操作として用意されています。

公開を避けたい場合は、指示の中でも「下書きとして作成」「公開しない」と明記します。

microCMS MCPを使うためにNode.jsは必要ですか?

今回使用した公式リモート版のmicroCMS MCPでは、ローカルでMCPサーバーを起動する必要はありません。Codexへ接続先URLとAPIキーを設定して利用します。

Node.jsが必要なのは、OSS版のmicroCMS MCP Serverをローカルで起動する場合です。

Codexから既存記事も更新できますか?

必要な権限があれば更新できます。誤更新を防ぐため、記事タイトルだけに頼らずコンテンツIDで対象を特定し、下書きだけを更新するのか、公開中の記事へ反映するのかも指定します。

microCMS公式MCPは記事運用の転記作業を減らせる

今回の検証では、CodexからmicroCMS公式MCPへ接続し、API一覧、記事のフィールド構成、最新記事を取得できました。さらに、専用記事を下書きとして作成し、その下書きだけを更新できました。

単に記事本文を生成するだけでなく、既存記事や現在のコンテンツモデルを確認したうえで、microCMSへ下書きとして反映できます。執筆後に管理画面へ移動し、タイトル、抜粋、カテゴリー、本文を一つずつ転記する作業を減らせます。

一方で、既存記事の更新や公開、削除まで同じ権限で無条件に任せる必要はありません。AI操作専用のAPIキーを用意し、microCMS側の権限とCodex側のツールを必要な範囲に絞ることで、操作範囲を管理できます。

私の環境では、まず読み取りだけで接続を確認し、その後に検証専用の記事で下書き作成と更新を試しました。今後の記事運用でも、原稿作成と下書き反映まではCodexで進め、公開は内容と表示を確認してから行う形にします。

#
執筆者 | 西條輝
1995年生まれ。
Web業界は8年目です。それ以前は、実製品の品質管理などを5年ほど担当していました。
生成AIの進歩で「作ること自体のハードル」は下がったからこそ、現場の課題を丁寧に言葉にし、Webというカタチに落とし込むことが、これからますます重要になると感じています。
X(Twitter)
お問い合わせはこちら

Related Blog