きっかけ
Claude Code触ってみたいな〜と思いながら触れていなかったので、
- Claude CodeでAIコーディングやってみるぞ
- 「Claude CodeってWordPressのカスタムブロック作れるの？」という興味
から、マイブームKiroと一緒に並走型で進めてみることにしました。
このブログを書き始めてから公開まで結構時間が経ってるのでうろ覚えなところがある＋Kiroは割と出たばっかりのプレビュー版の頃です。
前準備
導入するMCP
今回の開発に限って必須レベルのやつです。
私はKiroにもClaude Codeにも突っ込んであります。
ドキュメント系のMCPはマジで良いです！！！！
「これどうやって使うんだっけ？」の壁打ちから、「これ実装するには何使うんだっけ？」もサポートしてくれるので、欠かせない存在になりつつあります。
とは言え、毎回絶対使うという訳でもなければClaude Codeで言うところのuserレベルではいらないかな、という感じなので、Projectで突っ込むのが良いかと思います。
pre-PRDをChatGPT o3と壁打ちする
最初からKiroで壁打ちしてもよかったんですが、
- ちょくちょくリトライさせられるのにイラッとする
- Claudeはレートリミットで沈黙
という事情があり、ChatGPTのo3モデルと壁打ちしました。
最終的に作ったのは「カバーブロックにモバイル・タブレット用のフォーカルポイントを追加する」という機能になりましたが、実はこの方針自体最初から決まっていた訳ではありませんでした。
最初は「カバーブロックが、PCとスマホでフォーカスする位置が違うからどう作るのがいいかな？」というところから始まっています。
なので、最初は専用のカスタムブロック作るしかないのかなぁ………と思いながらのスタートです。
- 該当箇所のデザインのキャプチャと一緒に、デザインでPCとSPの違いについて補足（今回であれば、ちょっと画像のフォーカス位置違う、とか）
- デザイン上の画像は固定ではなく、いろんな画像を使う想定をする
- 範囲を明確にする
- ここを明確にしておかなかったので、最初にカバーブロック上に配置したテキストのサイズだったり角丸だったりと、読み取れる情報を全部書いたオーバースペックな仕様書が出てきました
個人的にこういう壁打ちは結構好きです。「あ、確かにここ仕様に足した方がいいかも」だったり、「ああ、ここは情報を渡す時点でもうちょっと整理した方がよかったんだな」という反省ポイントも出たりします。
- 画像は固定ではない
- フォーカスしたい位置もバラバラ
- 高さは一緒
とか、色々情報を整理した結果、提案された方法はこちら。
既存ブロック再利用か？完全カスタムか？
選択肢 できること 足りないかも 実装コスト Cover ブロック（core/cover）をそのまま使う - 背景画像＋InnerBlocks（見出しなど）- フォーカスポイント UI あり- オーバーレイ色・角丸・min-height 設定可 - アスペクト比別 (PC/SP) 固定が弱い- 編集画面 UI を最小限にしたい場合は冗長 0 Cover ブロックの「ブロックバリエーション」 - core/cover をベースに初期設定をプリセット- Inspector コントロールをカスタム（不要項目を隠す） - レスポンシブ用カスタム CSS は theme 側で追加要 低 完全カスタム“HeroBackground”ブロック - 編集UIを完全に絞り込み- PC/SP 用別画像など独自属性- 自動 <picture> 出力 - 自前ですべて実装 中〜高 迷ったら「Cover のバリエーション」がおすすめ
- フォーカスポイント UI がタダ乗りできる
- 見出し／段落をそのまま InnerBlocks で入れられる
- 不要項目（固定背景・カラム配置 など）を supports: { __experimentalHideControls: [...] } で隠せる
フォーカスしたい位置が画像を変えても同じであればバリエーションで十分。
ただ、今回は完全に位置を自由に変えたい。
この辺りで、ふとEnable Responsive Imageのことが頭に浮かんで、「カバーブロックにメディアクエリ別にフォーカスポイント追加するってできないのかな？」と思い、o3にも「ジャストアイデアなんだけど」と前置きした上でできるかどうか聞いてみました。
ぜんぜんイケる。
やり方は 「Enable Responsive Image が “画像をメディアクエリごとに切り替える” のと同じ構造を、object-position用のCSS変数に置き換える」 だけ。ポイントはHTMLは1枚の<img>のままにして、CSS側でブレークポイントごとにフォーカスポイント（≒object-position）を上書きすることだよ。
あとはそれっぽいコードをずらずら書いてくれたので、pre-PRDとしてマークダウンファイルにまとめてもらい、まずはプロトタイプを作ってみることに。ちなみにプラグイン名もo3に候補出してもらいました。（こういうのセンスがない）
作ってもらったpre-PRDはこちらです。
このpre-PRDを参照しながら、Kiroが実装計画を立てます。
Kiroと一緒に要件定義・設計書・実装計画を作る
まずは要件定義書を作ります。仕様を詳しくチャットで詰めながらできたのがこちら
要件定義書ができたら、次に設計書をつくるフェーズに入ります。
ちょこちょこサンプルコードが書かれるので、Claude Codeは結構引っ張られる感じがあるので、WordPressハンドブックのMCPを使ってちゃんと最新の記述になっているか確認した方がよいです。
次に実装計画を作ります。作成した要件定義書と設計書をもとに、Kiroが生成します。
よくよく見るとTDDなのに 8. テスト環境の基盤設定 とか後の方でやってるので結構ツッコミどころがあります。8とか書いてあるけど普通に最初に済ませたので完了チェックは割とすぐつけました。
実装自体はClaude Codeとやるので、作成したこれら3つのファイルを共通言語にしておきます。
要件定義書、設計書、実装計画は以下のファイルのことです。
各資料を参照するように指示をした時は、以下のファイルの内容を参照して下さい。
- `.kiro/specs/cover-responsive-focal/requirements.md` - 要件定義書
- `.kiro/specs/cover-responsive-focal/design.md` - 設計書
- `.kiro/specs/cover-responsive-focal/tasks.md` - 実装計画
厳守すること: タスクを実行する時は、設計書を常に確認すること。
これで、「実装計画からxxxを進めて」と指示すると、ちゃんと実装計画のファイルを見に行ってくれます。
今回は単一のディレクトリだったのでこれで済んでますが、同じディレクトリ内で複数存在する場合はちゃんとどの要件定義かを明示してあげるか、パスを直接渡してこのファイル見てね、とするのが良いと思います。
Claude Codeと実装
実装計画に沿ってコーディングを進めていきます。
ポイントはちゃんとWordPressハンドブックを参照させながら進めること。じゃないと、結構自分で型定義始めたり回りくどいコードになったりして軌道修正が大変です。
この辺はカスタムスラッシュコマンドで必ずハンドブックを参照させるように、 /wphandbook 実装計画の3.1 カバーブロック属性拡張の実装を進めて とか作ってもよかったかもしれません。
wordpress-handbook MCPを使って、最新の記述を確認すること。
最近は毎回これ打つの面倒だなと思ったら割とコマンドにしてます。CLAUDE.mdに指示書いても割と無視されるので………。
具体的に調整したポイントは以下です（すでにうろ覚えですが）
-
BlockEditPropsの型を使わずに独自定義 -
@types/wordpress__block-editorなどの型を使わず独自定義 - WPのコンポーネントで古い記述を使ってエラー
主に型周りの記述を直したので、全然実用できないコードを出されるわけではなかったです。
CodeRabbitでレビュー
今回、CodeRabbitを初めて導入しました。体験としてとってもいいです！
生成したダイアグラムでどういう動きをするのか一目でわかりやすいし、レビューも網羅的に色々見てくれます。
さすがに最新版の記述までは追えてないので、別のプロジェクトでは時々「最新では合ってますよ」とコメント返すことはありましたが、筋違いなレビューをしてくることはなかったように思います。
プロトタイプを共有
そんなこんなでClaude Codeと作ったプラグインを、社内レビューに出しました。
この時点ではフォーカスポイントごとにmin-widthとmax-width、あとどこで切り替えるかの数値を入力できるようになっていたので、「min-widthとmax-widthの数値が共存した場合どっちを優先させるのがいいかな」「これちょっと使いにくいかも、どうしようかな」と悩みながら出したんですが、社内レビューで 「モバイルとタブレットが選べたらそれでよくない？」 と言われて、目から鱗でした。確かに！！！！！！
あと、私がCSSの優先度誤解していてフォーカルポイントの操作自体もかなりややこしくしていたのでそこも修正することに。
動くもの見ながらさらに仕様が詰められるのはいい体験だなと思いました。プロトタイプと言うにはあれこれ直して出すのが遅くなりましたが………（確か着手してから5人日くらいかな）
レビューしてもらってからは結構はやくて、＋2人日くらいで完成しました。なので、トータルだと7人日くらいでの完成です。
完成
このままWordPressのプラグイン新規追加でzipファイルをアップロードしたら使えます。公式ディレクトリには近いうちに審査出します（忘れてた）
実装の裏目的
テストってどんな感じで書いてくの？を知るのが目的でした。
WordPressのブロックのテストの書き方ってどこかにまとまってるわけじゃなく（多分。私が見つけられてないだけかもしれない）、Gutenbergなりテスト書いてる人のリポジトリを見るしかないのです。
~~無理！！！！！~~ちょっと自分の時間がなさすぎて追えないので、ちょっと書いてみてもらいました。
ここでブロックのユニットテストは難しい、と教えてもらっていましたが、どういうポイントが難しいのか実感したかったのもあります。
なので、実は私が作ったカスタムブロックで初めてテストが導入されています🎉
作ってもらってテストを見て、ユニットテストは結構たくさんモック作らないといけないんだな〜とかふむふむ眺めたり、e2eテストってこう書くんだなとか、わかりにくいところをサッとClaudeに聞けるのもよかったです。こういう学習用途としても使えるのがうれしいですね。最近はChatGPTやClaudeも学習モード的なのがついてHAPPY
まとめ
Claude CodeでWordPressのカスタムブロックは作れます！ただし、いわゆるVibe CodingではなくAgentic Codingで並走して作っていく必要がありそうです。
並走型なのでそこまでスピード感は出ないですが、少なくとも私が自分で書くよりは早く完成しました。
- いかに仕様をわかりやすく、具体的に落とし込めているか
- ブロックの仕様をどれくらい理解しているか
対象がカスタムブロックであるかどうかに限らず、AIにコーディングを進めてもらうときに大事なポイントだなぁと思いました。
また直近でカスタムブロックを作る機会がありそうなので、今度はもうちょっとサブエージェントやカスタムスラッシュコマンドも整備しつつ進めたいと思います。
Discussion