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、検査、作業ログ |
結論は「相性は良い。ただし、公開作業が自動で終わるわけではない」です。 Codexは文章と確認項目を整えやすく、SWELLはブロックで役割を見せやすい一方、最後はWordPressの実画面で人が確かめる必要があります。
最初に困ったのは、見た目では分からない警告だった
相性の良さより先に書いておきたい失敗があります。SWELLの記事装飾を解説する記事を作っていたとき、本文画像に「外部メディア」の警告が出ました。
編集画面では画像が普通に見えたため、見た目だけならそのまま進めてしまう状態でした。画像をWordPressのメディアライブラリへ登録し直し、画像ブロックから選び直すと警告は消えました。
この経験から、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段階の流れ
日付、実画面、作業ログで確認できない体験は追加しません。
本文、内部リンク、公式情報、公開前TODOをWordPressへ入れる前に整理します。
ブロックの対応関係と未展開の文字列をローカルで確認します。
ビジュアル編集へ戻し、無効ブロック、カテゴリ、スラッグ、descriptionを見ます。
見出し、表、ボタン、画像のはみ出しを確認してから公開判断します。
AI記事をWordPressで公開する前のチェックリストでは、4つ目以降の実画面確認を詳しくまとめています。記事構成を作る段階で体験と公式情報を分ける方法は、ChatGPTでブログ記事構成を作る手順へ分けています。
この組み合わせが合いやすい人・合いにくい人
合いやすい人
- 原稿、装飾、公開確認を別の工程として扱える
- AIの文章を自分の体験へ直せる
- SWELLのブロック警告とスマホ表示を自分で確認できる
- 修正理由や作業ログを残したい
別の方法も検討したい人
- AIが作った文章を確認せず、そのまま公開したい
- WordPressの投稿設定やプレビューを省略したい
- SWELL独自ブロックを毎回たくさん使いたい
- HTMLやブロック警告を見たくない
SWELL単体の約1年間の使用感や購入前の注意点は、SWELLを約1年使った感想にまとめています。この記事はSWELL自体のレビューではなく、Codexを加えた運用に限定しました。
今の結論
SWELLとCodexは、文章の役割をブロックへ落とし込み、同じ公開前検査を繰り返す点では相性が良い組み合わせです。一方、SWELL独自ブロックの認識、投稿設定、PC・スマホ表示はAI任せにできません。
私がこの組み合わせを続けている理由は、公開ボタンまで自動化できるからではなく、原稿と確認記録を残しながら、自分で最終判断できるからです。個人ブログを続けるためのCodex活用術では、この作業を途中から再開するための記録方法を紹介しています。
コメント