SWELLとCodexの相性｜AIと記事を書いて分かった良い点・正直な不満点

2026年7月、止まっていたこのブログを再開したときから、Codexを原稿整理、SWELL用HTML、リンク確認、作業記録に使うようになりました。SWELL自体は約1年使っていますが、Codexと組み合わせた期間は2026年7月以降です。

2026年8月16日時点のナマズノートは公開21記事です。21記事すべてをCodexで一から書いたわけではなく、新規記事、過去記事の修正、公開前検査を含むサイト運用で併用しています。この記事は、その範囲で確認できたことだけをまとめます。

確認項目	今回の前提
確認日	2026年8月16日
WordPress	7.0.4
SWELL	2.18.0
公開記事	21記事
Codex併用開始	2026年7月
主な用途	構成、原稿、SWELL用HTML、検査、作業ログ

最初に困ったのは、見た目では分からない警告だった

2026年7月17日、SWELLの記事装飾を解説する記事を公開するとき、画像に「外部メディア」の警告が出ました。保存された修正前のHTMLでは、画像URLはすでにナマズノートのメディア保存先を指していましたが、画像ブロックにWordPressのメディアIDが入っていませんでした。

修正では、本文画像10点の画像ブロックへメディアIDを付けました。たとえばSWELLのバージョン画像では、画像ブロックにID311、画像要素にwp-image-311というクラスを追加しています。画像URLを変えた修正ではありません。

公開時の記録には「外部メディア」警告を解消し、無効ブロックと修復候補が0件であることを確認したと残っています。見た目だけでなく、WordPressが画像をどのブロックとして扱っているかも確認する必要がありました。

この例は当時の保存HTMLと作業記録で確認したものです。警告が出ていた画面の保存画像は今回確認できていません。また、同じ警告が出るすべてのケースで、メディアIDの追加だけで直ると検証したものではありません。

完成表示と使ったSWELLブロックは、装飾記事で確認できます。

SWELLで記事を読みやすくする方法

この経験から、Codexが作った原稿やHTMLが読みやすくても、次の2つは別の確認だと分かりました。

• 文章とリンクが意図どおりか
• Gutenbergが各要素を正しいブロックとして認識しているか

それでも相性が良いと感じる3つの理由

文章の役割とSWELL装飾を対応させやすい

SWELL公式の機能紹介には、キャプションボックス、ボタン、ステップ、Q&Aなどの専用ブロックが案内されています。選択肢が多いからこそ、私は「結論はポイント」「注意は警告」「手順はステップ」のように役割を先に決めています。

Codexへ装飾を自由に選ばせるのではなく、文章の役割を指定すると、同じ強調が続く状態を減らせました。装飾そのものより、どこで読者に立ち止まってほしいかを先に言葉にできることが便利です。

原稿とWordPress表示を分けて管理できる

ナマズノートでは、Markdown原稿、WordPressへ入れるSWELL用HTML、公開後の確認記録を分けて保存しています。WordPressの下書きだけにすると、どこを直したか分からなくなるためです。

Codexは原稿や差分の整理を担当し、SWELLは読者が見る完成表示を担当します。この分け方にしてから、途中で作業が止まっても、次に何を確かめるかを戻しやすくなりました。

同じ公開前検査を繰り返しやすい

新規記事では、SWELL用HTMLのブロック開始・終了、未展開のプレースホルダー、許可していないブロックをローカルで検査します。その後、WordPressで無効ブロック、PC表示、390px表示、内部リンク、description、canonicalを確認します。

毎回すべてを思い出すのではなく、検査項目をCodexとGitHubへ残せる点は、一人で運営するブログと相性が良いと感じています。

正直な不満点は「確認場所が増えること」

SWELL独自ブロックのHTMLは、そのまま信用できない

段落、見出し、リストなどの標準ブロックは扱いやすい一方、SWELL独自ブロックはコメント、属性、内側のHTMLが組になっています。生成された見た目が似ていても、保存後にブロックとして認識されない可能性があります。

そのため、専用ブロックを使うときは、過去に正常表示できた形式と照合し、ローカル検査とWordPressの両方で確認します。分からない構文を推測で増やすより、標準ブロックへ戻す方が安全な場面もあります。

まとめて入力しても、表示確認は別に必要

WordPress公式のブロックエディター解説にも、投稿全体をHTMLで確認するコードエディターへの切り替えが案内されています。複数ブロックをまとめて入れるには便利ですが、コード画面だけでは完成表示を判断できません。

HTMLをまとめて入れた後は、ビジュアル編集へ戻り、プレビューも確認しています。入力方法を変えても、ブロックの認識や完成表示を確認する工程は残ります。作業時間の短縮率は測っていません。

HTMLだけでは投稿設定が完成しない

本文を入れても、カテゴリ、スラッグ、アイキャッチ、description、OGP、PR表記は別に確認します。記事本文が完成したことで安心すると、設定漏れが起きます。

「Codexが記事を書いたら終わり」ではなく、原稿完成は公開工程の開始地点と考えるようになりました。

現在の役割分担

工程	Codexに任せる	自分で決める・確認する
企画	検索意図と既存記事の整理	実体験として書けるテーマか
原稿	見出し、下書き、重複の整理	体験、感想、未確認事項の線引き
SWELL	ブロック案とHTMLの作成	装飾の必要性、実画面の警告
公開前	リンクや確認項目の洗い出し	PC・390px表示、投稿設定、公開判断
公開後	台帳と作業ログの整理	公開URLと読者から見える完成状態

以前の下書きには「約半年使った実感」と書いていました。しかし、残っている運用記録は2026年7月以降です。もっともらしい期間より、確認できる開始日を優先して書き直しました。この修正自体が、Codexと記事を書くときに人が担う役割の一例です。

今使っている5段階の流れ

AI記事をWordPressで公開する前のチェックリストでは、4つ目以降の実画面確認を詳しくまとめています。記事構成を作る段階で体験と公式情報を分ける方法は、ChatGPTでブログ記事構成を作る手順へ分けています。

この組み合わせが合いやすい人・合いにくい人

合いやすい人

• 原稿、装飾、公開確認を別の工程として扱える
• AIの文章を自分の体験へ直せる
• SWELLのブロック警告とスマホ表示を自分で確認できる
• 修正理由や作業ログを残したい

別の方法も検討したい人

• AIが作った文章を確認せず、そのまま公開したい
• WordPressの投稿設定やプレビューを省略したい
• SWELL独自ブロックを毎回たくさん使いたい
• HTMLやブロック警告を見たくない

SWELL単体の約1年間の使用感や購入前の注意点は、SWELLを約1年使った感想にまとめています。この記事はSWELL自体のレビューではなく、Codexを加えた運用に限定しました。

SWELLをまだ購入していない人は、今のテーマで必要な記事と導線が作れるかを先に確認してみてください。購入するか迷う場合は、SWELLの価格に見合う価値を判断する記事を参考に、繰り返し使う機能と購入を急がなくてよい条件を整理してみてください。

今の結論

SWELLとCodexは、文章の役割をブロックへ落とし込み、同じ公開前検査を繰り返す点では相性が良い組み合わせです。一方、SWELL独自ブロックの認識、投稿設定、PC・スマホ表示はAI任せにできません。

私がこの組み合わせを続けている理由は、公開ボタンまで自動化できるからではなく、原稿と確認記録を残しながら、自分で最終判断できるからです。個人ブログを続けるためのCodex活用術では、この作業を途中から再開するための記録方法を紹介しています。

公式情報

• SWELL公式：SWELLの特徴
• SWELL公式：ブロックエディターで使える専用機能
• WordPress公式：ブロックエディター