Update to microCMS

{
  "description": "WordPress から microCMS へコンテンツを移行するための手順書と品質チェック。構造の洗い出し、microCMS スキーマ設計、メディアのアップロードと URL 置換、リッチエディタ用 HTML 変換、案件ごとの移行スクリプト作成指針、件数・取りこぼし検証、リダイレクト表までを扱う。WordPress から microCMS への移行、WXR / WP REST API / ACF / カスタム投稿タイプ / Gutenberg / ショートコードを microCMS に持っていく話、WordPress コンテンツの一括登録・インポート、WordPress から microCMS への移行の見積もりや事前調査で使用する。フロントエンドの移行・実装は対象外。",
  "included_files": [
    {
      "relative_path": "references/general.md",
      "size_in_bytes": 17449
    },
    {
      "relative_path": "references/microcms.md",
      "size_in_bytes": 23134
    },
    {
      "relative_path": "references/plans.md",
      "size_in_bytes": 6068
    },
    {
      "relative_path": "references/richeditor.md",
      "size_in_bytes": 5624
    },
    {
      "relative_path": "references/scripting.md",
      "size_in_bytes": 6472
    },
    {
      "relative_path": "references/validation.md",
      "size_in_bytes": 11342
    },
    {
      "relative_path": "references/wordpress.md",
      "size_in_bytes": 20559
    }
  ],
  "name": "microcms-wordpress-migration",
  "skill_md_contents": "---\nname: microcms-wordpress-migration\ndescription: WordPress から microCMS へコンテンツを移行するための手順書と品質チェック。構造の洗い出し、microCMS スキーマ設計、メディアのアップロードと URL 置換、リッチエディタ用 HTML 変換、案件ごとの移行スクリプト作成指針、件数・取りこぼし検証、リダイレクト表までを扱う。WordPress から microCMS への移行、WXR / WP REST API / ACF / カスタム投稿タイプ / Gutenberg / ショートコードを microCMS に持っていく話、WordPress コンテンツの一括登録・インポート、WordPress から microCMS への移行の見積もりや事前調査で使用する。フロントエンドの移行・実装は対象外。\n---\n\n# WordPress から microCMS への移行\n\nWordPress から microCMS へコンテンツを移す。**案件ごとに移行スクリプトを書き、毎回同じ手順で検証する。** 全部を自動で変換することは目指さない。目指すのは次の 3 つ。\n\n1. 移行できるもの・できないものを、書き込む前に人が判断できる形で出す\n2. 同じ入力から同じ結果になるスクリプトにして、何度でも流し直せるようにする\n3. 変換できなかったものを 1 件残らず記録して、人が直す作業リストにする\n\n## 対象範囲\n\n扱うのはコンテンツ・メディアの調査、スキーマ設計、変換・登録・検証と引き継ぎ資料の作成まで。WordPress のテーマ、テンプレート、CSS、画面機能の移植や新サイトの実装、リダイレクトの設定・本番切り替えは行わない。本文の意味を保つための HTML 変換と、旧 URL の対応表作成はデータ移行に含む。\n\nフロントエンドの実装も求められた場合は別作業として扱い、Next.js なら `microcms-nextjs` を案内する（https://github.com/microcmsio/skills/tree/main/skills/microcms-nextjs）。未導入なら導入先を案内し、このスキルだけでフロントエンド実装を進めない。Next.js 以外を想定している場合は、フレームワークを勝手に変更しない。\n\n## 読む順番\n\n| いつ | 読むもの |\n|---|---|\n| 最初に必ず | `references/general.md`（全体の流れと、人が判断する場所） |\n| 移行元を調査するとき | `references/wordpress.md`（取り出し方と構造の洗い出し） |\n| スキーマを決めるとき・登録スクリプトを書くとき | `references/microcms.md`（フィールド対応表と API の制約） |\n| スクリプトを作るとき | `references/scripting.md`（入出力・再実行・失敗記録・検証の実装指針） |\n| `plan.md` を人に見せる前 | `references/plans.md`（料金プランの上限との照らし合わせと、超過時の費用） |\n| 本文（HTML）を変換するとき | `references/richeditor.md`（入稿できる HTML と変換表） |\n| 登録後・引き継ぎ前 | `references/validation.md`（品質チェックと報告書の形） |\n\n## 移行スクリプトの作成\n\nサンプルスクリプトは同梱しない。AI は棚卸しと承認済みの対応表に基づき、案件用のスクリプトを `migration/scripts/` に作る。作成時は `references/scripting.md` を読み、移行元固有の取り出しは `wordpress.md`、API 操作は `microcms.md`、本文変換は `richeditor.md` に従う。実行言語や依存パッケージは案件の環境に合わせて選ぶ。\n\n件数が少ない移行なら、利用可能な microCMS の MCP ツールで直接登録してもよい。その場合も ID の付け方、登録の順番、対応表・失敗記録、登録後の検証は同じ手順で行う。\n\n## 作業ディレクトリ\n\n移行を始めたら、プロジェクト内に次の形で作る。\n\n```\nmigration/\n├── plan.md            # 洗い出し結果・構造の対応表・既定の扱い・先に決めてほしいこと（人が承認する）\n├── input/             # 受け取ったファイル（WXR、wp-content/uploads を展開したもの）\n├── raw/               # 移行元から取り出したそのままのデータ（書き出しの警告を含む）\n├── transformed/       # microCMS の形に変換済みの JSON（登録スクリプトの入力）\n├── media-map.json     # 旧 URL → 新 URL の対応表\n├── media-skipped.json # 上げられなかったメディアと理由\n├── logs/              # 変換時の警告、登録前の検査結果、登録結果\n├── scripts/           # この案件用のスクリプト（案件ごとに作成）\n├── redirects.csv      # 旧 URL → 新 URL のリダイレクト表\n└── report.md          # 検証結果、人が直す作業リスト\n```\n\n## 接続情報\n\n認証情報は、会話・ファイル・ログに一度でも書かれると取り消せない。\n\n- **接続情報は `.env` など実行環境の秘密情報管理に設定する**（`.env` は `.gitignore` に入れる）。スクリプトは `MICROCMS_SERVICE_DOMAIN` と `MICROCMS_API_KEY` を環境変数から読み、値をコードに埋め込まない。実行環境に合う読み込み方法とコマンドを案件の `plan.md` に記録する。ローカルデータの変換や通信なしの検証に認証情報は不要。\n- **値を表示しない。** 確認するときは「`MICROCMS_API_KEY`：設定済み／空／未設定」のように、名前と状態だけを報告する。`.env` を `cat` しない。\n- **依頼文やチャットで値を渡されたら、** その値をファイルにもコマンドにも書き写さず、`.env` に入れ直してもらう。会話に残った値は無効にして発行し直すよう勧める。\n- **`plan.md`、`report.md`、`logs/` に値を書かない。** 取り出した `raw/` の著者やコメントにはメールアドレスが入っている。移行に必要なものだけを残す。\n- **WordPress の認証情報は受け取らない**（既定の受け取り方では要らない。`references/wordpress.md` の 0 章）。例外はサーバー上で WP-CLI を動かす場合だけで、SSH の接続は人にしてもらうか、移行用のアカウントを発行してもらい、終わったら無効にしてもらう。管理者のログインパスワードは受け取らない。\n- **microCMS は移行用の API キーを別に発行してもらう。** 必要な権限だけを付け、終わったら削除してもらう。コンテンツ API は GET・PUT・PATCH・DELETE（POST は使わない）。Content API で全件集計する場合は、対象 API の「下書きコンテンツの全取得」「公開終了コンテンツの全取得」も付ける（`references/plans.md`）。マネジメント API はサービス情報・API・コンテンツメタ情報の取得、コンテンツの公開状態の変更、API の作成、メディアのアップロードと削除。公開状態変更の権限は、下書きからの公開と公開中から下書きへの切り替えに使う。\n\n## 人の判断を必ず挟む場所\n\nここはエージェントが勝手に進めない。どれも取り消しにくいか、お金がかかるか、案件の事情でしか決まらない。\n\n0. **事前確認** — 手元の WXR・uploads の調査に API キーや MCP 接続は不要。接続する段階で対象サービスを確認し、書き込み前に MCP の接続先も一致することを確かめる（`general.md` の 0）。MCP が別のサービスにつながっていることがあるので、一致を確かめるまで MCP で書き込まない。\n1. **`plan.md` の承認** — スキーマと対応表を見せて、書き込みを始めてよいか確認する。プランなどの前提が後からわかった・変わったときは、設計を見直して承認を取り直す。\n2. **API を作る直前** — 作る API とフィールドの最終版を見せる。API は作ったあとでマネジメント API では変更・削除できず（管理画面で人に直してもらうしかない）、間違えると作り直しになる。\n3. **プランの上限と費用** — API 数、コンテンツ数、ファイルアップロードなどが契約中のプランに収まるかを、料金ページを取得して確かめ、`plan.md` に書く（`plans.md`）。超える場合は費用と代わりの案を並べ、人が選ぶまで API を作らない。同意なしに追加料金を許可しない。\n4. **本番サービスへの書き込み** — まずテスト用のサービスか、少数（3〜5 件）で試す。全件投入や削除を伴う流し直しは、そのたびに確認する。\n5. **変換できなかったものの扱い** — 消すか、別フィールドに逃がすか、手で直すかは人が決める。\n\n## ID 衝突と流し直し\n\n識別情報は `references/general.md` の「ID の付け方と識別情報」に従って種類ごとに決め、入力 JSON の `identity` と `content` に保存する（形式は `references/scripting.md`）。基本は移行元サイト・データの種類・元 ID。元 ID がない場合は一意性を確認した代替キーを使い、旧 URL は取得できる場合に保存する。同じ移行先 ID が存在しても、採用した照合キーがすべて一致するまで更新しない。PUT の 400 は既存コンテンツの証拠にしない。識別情報のない既存データや、別の移行元と衝突したものは失敗として記録し、別 ID にするか、対応表を確認して採用するかを人に決めてもらう。識別情報を推測で後付けして更新を通さない。\n\n書き込まない事前検査を用意し、ローカル入力の検査と、接続先を読み取る検査を分ける。ローカル検査だけでは接続先の ID 衝突・公開状態・権限は確認できない。スクリプト実行中は管理画面や別プロセスから同じコンテンツを編集しない。本文と公開状態の変更は一括処理ではなく、途中失敗で一部だけ反映されることがある。失敗した ID の本文・状態を確認してから流し直す。\n\n## 最後の報告\n\n作業の終わりには `migration/report.md`（形は `references/validation.md`）を書き、会話では次の 3 つだけを出す。詳細は `report.md` を見てもらう。\n\n1. 状態の 1 行（✅ 完了／⚠️ 要対応あり／❌ 失敗あり）\n2. 結果のまとめの表（種類ごとの移行元・登録済み・失敗・移さない・要対応の件数）\n3. 人がやることの表（優先度順）\n\n件数はログから集計して出す。記憶や見積もりで書かない。\n"
}