Claude CodeでSWELLのカスタムブロックを作る話、2026年に入ってかなり現実味が出てきました。
ただ正直なところ、「AIに任せれば終わり」ではなく、SWELLのブログパーツで足りる場面も多いです。
自分はここ、大事な判断ポイントだと思っています。
※この記事には広告を含む場合があります。
正直、いきなり自作ブロックに行く前に一回止まるのが大事です。
まず整理：SWELLで自作ブロックが必要な場面
SWELLには、ふきだし、キャプションボックス、ステップ、ブログパーツなどが最初からそろっています。
だから、CTA(クリックを促すボタンや誘導文)や注意書きの使い回しなら、ブログパーツとブロックパターンで足りることが多いです。
ここを飛ばすと、あとで保守がちょっと面倒なことになります。
| やりたいこと | おすすめの進め方 | 理由 |
|---|---|---|
| 同じ文章テンプレを使い回す | SWELLブログパーツ | 管理画面で直せるのでラクです |
| ふきだしの見た目を少し増やす | 子テーマでブロックスタイル追加 | 本体を触らずに済みます |
| 外部データを表示する | プラグイン化したカスタムブロック | PHPや属性設計が必要です |
| 投稿テンプレを量産する | Claude Code SkillとREST API(外部から記事を投稿する仕組み) | 記事作成の流れに乗せやすいです |
Claude Codeに渡すなら、最初の仕様書が勝負です
Claude Codeはコードを書くのが速いです。
でも、何を作るかがあいまいだと、古いWordPressの書き方や、不要な動的ブロックを出してくることがあります。
個人的には、先に「用途」「入力項目」「表示例」を1枚にまとめるのが好きです。
- ブロック名は自分の名前空間にする
- 入力項目は文字、URL、色などに分ける
- 静的でよいか、PHPで動かすかを先に決める
- SWELL本体ファイルは触らない前提にする
- ローカル環境で試してから本番へ持っていく
「いい感じに作って」だと、あとで自分が泣きます（笑）
自分ならこの5段階で進めます
結論から言うと、いきなり完成形を頼まないほうが安定します。
WordPressのブロックは、block.json(ブロックの設定ファイル)、編集画面、表示側、ビルドの流れが絡みます。
ここは段階を切るほうが、やっぱり安心です。
用途、入力項目、表示例、SWELLで代替できない理由を書きます。
公式の雛形から始めると、Claude Codeの脱線が減ります。
edit、save、renderのどこを触るかを分けて依頼します。
Studio や LocalWP(どちらもパソコン内に練習用のWordPressを立てるツール)で、エディターと表示側を両方見ます。
最後に余白、色、ボタン感をSWELLの既存UIに合わせます。
ネットの声は「速いけど丸投げは怖い」に寄っています
口コミを見ていると、肯定も否定もかなり具体的です。
数十件の声をざっくり分けると、「前半は速い」「最後は人間が見る」「WordPressは歴史が長くてクセがある」という温度感でした。
やはり、現場に近い人ほど慎重になります。
肯定側では、WordPress保守や投稿まわりをClaude Codeでかなり省力化できた、という個人運営者の声が目立ちました。
note / Qiita / Zenn 横断の要約
否定側では、テーマごとのデザイン縛りや古いAPI提案で詰まり、最後は人間の判断が必要だったという声が多めです。
note / 法人テックブログ 横断の要約
中立派は、公式の雛形やWordPress向けスキルを使えば失敗は減るが、丸投げ前提では危ない、という見方でした。
WordPress公式情報と実装者の声の要約
個人的には、この「速いけど見張る」がいちばん現実に近いです。
個人運営でWordPress保守を自動化した話は、かなり胸アツです。
一方で、ここまで行くには作業の分け方が必要です。
反対に、WordPressのテーマ制約でつまずいた体験もあります。
正直、この失敗談は自作ブロック前に読んでおきたいです。
立場別に見ると、温度差はかなり出ます
同じClaude Codeでも、個人ブログ、受託制作、非エンジニアでは見え方が変わります。
ここは大事です。
自分の立場を間違えると、便利な話がそのまま事故のもとになります。
| 立場 | 温度感 | 向いている使い方 |
|---|---|---|
| 個人SWELL運営 | ブログパーツで9割足りるという声 | テンプレ作成、下書き、HTML整形 |
| 個人フリーランス | 保守作業の時短に期待が大きい | 定期作業、確認リスト、軽い修正 |
| 法人受託 | レビュー層なしでは納品しにくい | 雛形作成、テスト、差分確認 |
| WordPress専業 | 設計は人間、実装補助はAI | 属性設計後のコード作成 |
| 非エンジニア | デザイン崩れに気づきにくい | ブログパーツ運用までに留める |
失敗しやすいポイントを先に潰す
AIにGutenberg(WordPress標準のブロックエディター)のブロックを書かせると、似たような詰まり方をします。
たとえば、srcとbuildが増えすぎる、動的ブロックが不要なのにrender.phpを作る、block.jsonの読み込みが変になる、などです。
ちょっと地味ですが、ここを見ないと公開後がしんどいです。
- block.jsonのapiVersionは3を基準に見る
- nameは自分の接頭辞にして、swell系と被せない
- 静的ブロックで足りるならrender.phpを増やさない
- 保存済み記事のブロック復旧表示を確認する
- 本番前にSWELL更新後の表示も見る
「動いた！」で止めると、あとで地味に崩れます。ここ、ほんと大事です。
手書きでカスタムブロックを作る記事も参考になります。
AIに任せる前に、構造だけ知っておくとかなりラクです。
公式情報と体験談はここで確認する
料金、仕様、WordPress側のAI連携は動きが速いです。
記事だけで判断せず、公式情報と実装者の体験談を並べて見たほうが安心です。
※掲載内容は執筆時点の情報をもとにしています。サービス内容・料金・仕様などは変更される場合がありますので、最終的には公式サイト等をご確認ください。
Claude Code Skillsを使った投稿システムの話は、SWELLブログパーツ量産の考え方にも近いです。
自分の運営フローに合わせる発想が、やっぱり好きです。
まとめ：自作より先に、SWELLで足りるかを見る
- CTAや注意書きは、まずSWELLブログパーツで考える
- Claude Codeには、用途と入力項目を決めてから渡す
- 公式のcreate-block雛形から始めると脱線しにくい
- 口コミは「速いけど丸投げは怖い」に寄っている
- 本番投入前にローカル環境とSWELL更新後の表示を見る
個人的には、自作ブロックは最後の札でいいと思っちゃいます。
SWELLは既存機能が強いので、まずはブログパーツとパターンで小さく試します。
それでも足りないときだけ、Claude Codeにカスタムブロックを頼みます。
この順番なら、個人運営でもかなり付き合いやすいです。
