841-biborokuWebフロントエンドの備忘録

microCMS MCP×Claudeで実現。AIによるメタディスクリプション自動生成とPATCH更新の実践ログ

MCPmicroCMSClaudeAI

microCMS公式のMCP（Model Context Protocol）サーバーを活用し、既存記事の再編集にトライしました。

以前は新規記事の入稿を試しましたが今回は、メタディスクリプションをAIに生成させ、直接microCMSへ書き込む仕組みを構築した記録です。

試した環境

  • Claude Desktop Claude Sonnet 4.6
  • microCMS（Hobbyプラン）

なぜディスクリプションを再編集しようと思ったか

このブログではNext.js側でデフォルト設定として「タイトル＋固定文」を結合してディスクリプションを動的生成し、microCMSのフィールドでユニーク設定できるようにしています。

せっかく作ったフィールドも使っていない...

ふと気になった

📝ブログカードの見た目

記事内でリッチエディタの埋め込み（ブログカード）を使ったとき、タイトルと説明文に同じテキストが並んでしまう。

🚀MCPの練習

既存記事の再編集（PATCH）を試すのに、ディスクリプションはちょうどよかった。

▲ ブログカード表示のイメージ

1. microCMS側の設定

1-1. API権限の設定

API設定からPATCH権限を有効にします。

設定しないと読み取りはできても書き込みでエラーになります。

1-2. フィールドの確認

過去に作成していたメタディスクリプションのフィールドをそのまま利用します。

2. Claudeでの実行プロセス

※事前にmicroCMS公式の「microCMSのMCPサーバーをリリースしました」記事を参考にmicroCMS MCP Serverの設定をしておきます。

2-1. AIへの指示

microCMSの以下条件の記事の内容を確認し記事ページに設定するメタディスクリプションを考え、要約した内容を該当記事の指定フィールドに入稿・登録してください。

## 対象コンテンツAPI
{対象コンテンツAPIを記載}

## 条件
- ステータスが公開中のみを対象
- 要約する文章は80～100文字

## 要約するためのAPIスキーマ
- フィールドIDが{FIELD_ID}に登録されている本文情報

## 要約したディスクリプションの登録先
- フィールドIDが{FIELD_ID}に登録してください。

## 流れ
- まずは、試しに１つ対応してください。
- 確認したあとに問題なければ残りの要約を依頼します。

2-2. Claudeの自動稼働と提案

指示を受けると、ClaudeはMCP経由でスキーマと公開記事を確認。内容を読み取って以下のような案を出してくれました。

メタディスクリプション案（80〜100文字）：
「Astro v5のContent Layer APIを使った記事詳細ページの実装手順を解説。getStaticPathsやgetCollectionでデータを取得し、Zodの型定義を再利用してシンプルに実装する方法をまとめます。」

2-3. microCMSへの書き込み

内容を確認して問題なければ実行！

microcms_patch_contentが実行され、管理画面側で正しくテキストが登録されていることが確認できました。

3. 残り記事の更新

あえて「1件ずつ」選んだ理由

最初のテストが成功したあと、残りの全記事（約50件）も実行するように指示しました。

ここでうまくいかず...

最初は一括処理で失敗

まとめて処理させようとすると、複雑なスクリプトを組もうとして途中で止まったり、APIの制限でエラーが出たりと、かえって時間がかかってしまいました。

1件ずつの繰り返しへ変更

指示を「1件ずつ内容を確認し、生成・書き込みを繰り返して」と変更。

結果

Claudeが microcms_patch_content を淡々と繰り返し、途中で止まることもなく約50件の記事が10〜15分ほどで完走。

4. 文章校正

確認する前にAIによるセルフ校正チェックを挟みます。

4-1. 校正ルールの提示

いきなり校正チェック～修正を実行せず、どのような基準でチェックすべきかをClaudeに提示させました。

👉提案された内容

  • ネガティブワード — 「つらい」「失敗」「苦労」「問題」「エラー」「悩み」など、読者に不安や苦労を想起させる表現
  • 自信のなさを示す表現 — 「〜してみた」「〜試した」など、権威性・信頼性を下げる可能性のある表現（ただしブログの性質上許容範囲もある）
  • 曖昧・冗長な表現 — 「〜をまとめた備忘録です」の繰り返しによる単調さ
  • 読者メリットが不明瞭 — 何が得られるか伝わらない説明文
  • 日本語の不自然さ — 助詞の誤り、文末の不統一、句読点の問題など

4-2. 校正後の修正PATCH

どこをどのように修正するかを提示してくれます。

内容を確認し、提示された箇所を再度PATCHで上書き修正してもらいます。

完成です。

つまづきポイント

👿PUTとPATCHの使い分け

前回、新規記事の入稿を試した際はPUTを使っていました。

今回もPUT権限でいいだろうと実行したところ、Claude（MCP）側は「部分更新」と判断してPATCHでリクエストを送信していたので権限不足ではじかれてしまいました🫠

自動でPUTで実行して書き込みはできたのですが、全フィールドのデータを上書きするので本文が空になってしまう危険も。

編集ならPATCH一択

今回のような部分更新なら安全で低負荷のPATCHが最適です。

👿一括もいいけど1件ずつの繰り返し

最初は全件まとめてやってと指示しましたが、何度か途中で中断するはめに。

複雑なスクリプトを組もうとして環境依存（pip等）の問題にぶつかっていたとのこと。

一向に進まないので、1件ずつPATCHを叩くように変更したところ最後まで止まらず実行されました😀

Claudeに何があったのか質問してみた💭

  • 環境依存の壁
    • Pythonスクリプトの実行に pip install が必要で、ネットワーク制限などの環境トラブルに弱かった。
  • 不透明な中間工程
    • 「テキスト抽出 → 生成 → ファイル保存 → 読み込み → 登録」と工程が多く、どこで失敗したかの切り分けが困難だった。
  • リトライの負荷
    • 処理が途中で止まると、どこまで進んだかの管理ができず、最初からやり直す必要があった。
  • ツールへの依存
    • 「自動化ツールを作る」こと自体が目的化し、本来の「APIを叩いて更新する」というシンプルなゴールを複雑にしていた。

👿あくまでも自動生成

生成されたテキストを確認していたところ「設定手順と呪った点をまとめます」と。呪った...！👀

自分で確認する前にまずはAIで校正チェックと修正をしてから確認するフローに変えました。

microCMSの履歴はどうなる？

MCP経由で編集した場合、管理画面の履歴はどうなるのか確認してみました。

最終更新

通常はアカウント名が出ますが、MCP経由（API）の場合は「API」と記録されます。

過去の編集履歴

編集履歴にも更新者が「API」として残っていることを確認できました。

※次に保存されたタイミングで現在のデータが履歴に残るので、MCPで書き換えた直後のログは、次に更新（保存）を行った際に一つ前の履歴として確認できるようになります。

ブログカードの見え方

これまではタイトルと説明文に同じテキストが並んでいましたが、要約が入ることでブログカードの情報の密度が上がり、パッと見の印象がぐっと良くなりました👍

まとめ

今回はディスクリプションということで、文脈の作り込みよりも要約の自動化に重きを置きましたが、タイトルや本文から要点をまとめてくれて、運用の負担が軽減されました。

長らく空欄のままだったディスクリプションのフィールドも、ようやく日の目を見ることができてうれしい限りです✨

今回のように既存記事に対するアクションを実践してみて、記事内容を理解させた上でのタグ付けや、アイキャッチ画像の自動生成なども現実的だと感じました。

シェア

Category