AIへ「ブログ記事を書いて」と頼むだけでは、公開できる記事にはなりません。文章が自然でも、体験が薄い、リンク先が違う、SWELLで崩れる、スマートフォンではみ出す、といった問題が残るからです。
ナマズノートでは、実際に公開した「SWELLのトップページを固定ページで作る方法」を題材に、テーマ決めからSearch Consoleへの送信までを一つずつ記録しました。
AIに任せたのは、調査結果の整理、見出し案、初稿、修正候補の抽出です。実体験の確定、不要な文章の削除、SWELLの表示確認、公開判断は人が行いました。
完成まで一直線に進んだわけではありません。約49KBのHTMLを作り直し、見本画像の制作メモを誤って画面へ入れ、ヒーローが左へずれ、スマートフォンで画像が消え、完成画像も撮り直しました。この失敗まで残したことで、AIで文章を作るだけでは見えない工程が分かります。
題材にしたのはSWELLのトップページ制作記事
題材にしたのは、2026年8月23日に公開した次の記事です。
この題材を選んだ理由は、作業前の画面、Codexへ渡した指示、失敗したHTML、ブロックエディターへの移行、PC・スマートフォンの確認、公開時刻、Search Consoleの結果まで記録が残っていたからです。
使用感や失敗を思い出だけで補う必要がなく、起きた順番に沿って書けました。
テーマ決めから公開後までを7段階に分けた
作業は10個以上に細分化できますが、実際に手を止めて確認した場所で7段階に分けると迷いにくくなります。
実際に終えた作業から、誰のどの迷いを解決するか決めます。
検索上位の共通点と不足を見て、操作や仕様は公式情報へ戻ります。
成功だけでなく、失敗、修正、数値、確認条件を先に並べます。
読者、目的、事実、禁止事項、必要な見出し、リンク候補をまとめて渡します。
体験していない表現、制作メモ、重複、弱い結論、古い画像を取り除きます。
文章の役割に合うブロックだけを使い、関連記事を読む順番に配置します。
表示、URL、SEO設定を確認して公開し、必要な場合だけURL検査を行います。
1．記事テーマは「終えた作業」から選んだ
先に決めたのはキーワードではなく、ナマズノートで実際に終えた作業です。
2026年8月21日から22日にかけて、トップページを新着記事中心の画面から、初心者が読む順番を選べる7セクション構成へ作り直しました。固定ページ、SWELLブロック、スマートフォン調整で何度もつまずいたため、同じ場所で迷う人へ具体的に伝えられる材料がありました。
検索意図は操作と失敗回避の2つに分けた
「SWELL トップページ 固定ページ 作り方」で探す人が知りたいことを、次の2つに分けました。
| 検索意図 | 必要な答え | 題材記事に入れた内容 |
|---|---|---|
| 固定ページをトップに設定したい | WordPressの設定手順 | 「設定 → 表示設定」の実画面と7手順 |
| SWELLで見やすく作りたい | 使用ブロックと配置 | 投稿リスト、リッチカラム、ステップなど |
| スマホで崩したくない | 確認する幅と修正点 | 1440px、768px、375〜390pxの確認 |
| AIを使って作業したい | AIへ渡す情報と限界 | 実際の指示、失敗、最後に人が直した箇所 |
「おしゃれなトップページの作り方」だけでは範囲が広すぎます。固定ページへ設定したい初心者に絞り、見た目よりも、後からブロックエディターで直せることを優先しました。
2．競合確認では共通点より「残った疑問」を探した
公開されているSWELLブログのトップページと解説ページを、PCとスマートフォンで見比べました。多かったのは、ファーストビュー、おすすめ記事、カテゴリー、プロフィール、フッターを順に置く構成です。
そのまま似せるのではなく、読んだ後も残る疑問を洗い出しました。
- 固定ページへ切り替える前のページはどう残すのか
- カスタムHTMLが長くなったとき、初心者はどこを直すのか
- 見本画像の注釈まで再現されたら、何を削るのか
- SWELLの
alignwideで横長画面だけずれたとき、どう見つけるのか - PCで整った後、スマートフォンでは何を見直すのか
仕様と操作は、競合記事の説明だけで確定しません。固定ページの指定はWordPress公式、SWELL側の表示部品はSWELL公式、実際の崩れ方はナマズノートの公開画面で確認しました。
競合と違う結論を無理に作る必要はありません。実際の失敗と直し方を足す方が、同じ操作で迷う人には役立ちます。
3．AIへ渡す前に自分の体験を並べた
AIへ先に文章を書かせると、足りない体験まで自然な一般論で埋まりやすくなります。今回は、起きたことを短いメモへ先に並べました。
| 起きたこと | 確認できた事実 | 記事で伝える判断 |
|---|---|---|
| 旧HTMLを部分修正しにくい | 1ブロックが約49KBだった | 日常更新は標準ブロックへ戻す |
| 左の「1〜7」が画面へ入った | 見本画像の制作メモも再現された | 公開UIと注釈を分けて指示する |
| 記事カードが16枚同時に見えた | 非選択タブもグリッド表示された | ローカルだけで完成と判断しない |
| ヒーローが左へずれた | 広い画面で約100pxのずれを確認した | PC幅を変えて左右端を測る |
| スマホで画像が消えた | 初回CSSで画像枠と表示順が不足した | スマホを別工程として確認する |
| 完成画像に不備が残った | 左ずれ版と管理バー付き画像が混在した | 修正版の画像ID763へ統一する |
感想を増やすのではなく、「何が起きたか」「どう確認したか」「次はどうするか」をそろえました。これが初稿の土台です。
4．AIへ渡した情報はキーワードだけではない
AIには、読者、検索意図、実体験、禁止事項、必要な内容をまとめて渡しました。実際の入力を短くすると、次の形です。
題材:
SWELLの固定ページで、初心者向けトップページを作り直した記録
読者:
SWELLを使っているが、固定ページの作り方とスマホ調整が分からない初心者
必ず入れる事実:
- 旧HTMLは約49KBで部分編集しにくかった
- 制作メモの「1〜7」まで画面へ入った
- 4タブの16記事が同時表示された
- 1108px以上でヒーローが左へ約100pxずれた
- スマホで画像が消え、配置を修正した
- 旧完成画像を使わず、修正版へ差し替えた
禁止:
- 体験していない成功・失敗を作らない
- 存在しないURLを作らない
- 読者の疑問に答えない制作側の作業説明を本文へ入れない
- AIだけで完成したように書かない
必要な内容:
改修前、完成後、固定ページ設定、使用ブロック、AIへ渡した指示、
PCとスマホの修正、うまくいかなかった部分、改修前後の比較この段階で事実が足りなければ、初稿へ進まず確認します。特に、本人しか分からない感情、料金、作業時間、成果はAIに補わせません。
プロンプトへ何を含め、どこで作業を止めるかは、次の制作記録で詳しく確認できます。
5．見出しを作ってから初稿へ進んだ
先に見出しだけを作り、検索意図と体験メモが入る場所を確認しました。採用した主な見出しは次のとおりです。
- 改修前のトップページで困っていたこと
- 完成後のトップページは7つの基本セクション
- Codexへ渡した指示
- 独立HTMLからブロックエディターへ移した流れ
- 使用したSWELL・Gutenbergブロック
- 固定ページをフロントページに設定する方法
- PC・タブレット・スマートフォンで修正した場所
- Codexだけではうまくいかなかった部分
- 改修前後を比較
見出しを先に見ると、一般的な機能紹介だけの節と、実体験が入る節を分けられます。体験メモの置き場所がない構成なら、本文を書く前に直します。
短い指示から見出しを作る方法は、次の実例から始められます。
6．初稿から人が削除・修正した部分
初稿は完成品ではなく、確認箇所を見つけるための土台として使いました。
特に削ったのは、読者に不要な制作メモです。どの記録を使ったか、どの段階を完成と呼ぶか、どの確認を最後にしたかは、書き手の事情であり、トップページを作りたい人の疑問には答えていません。
| 初稿で気になった部分 | 人が行った修正 |
|---|---|
| 作成手順を外側から説明する表現 | 困った場面から始まる文章へ変更 |
| 一般的な長所だけの説明 | 約49KB、16枚同時表示、約100pxのずれを追加 |
| 失敗が節ごとに散らばっていた | 起きた順番に並べ直した |
| 旧完成画像ID737 | 左右端を直したID763へ差し替え |
| 管理バー付きの画像ID758 | 公開画面だけが見える画像へ差し替え |
| 「5つを紹介する」という案内 | 「安全に作り直した5つの手順」へ変更 |
冒頭も、構成の説明ではなく実際の困りごとから始めました。
改修前のトップページを開くと、最初に目に入るのはABLENETの記事と右側のSWELL広告でした。記事そのものは必要でも、AIとSWELLを扱うブログだと伝わる前に、1本の記事とサイドバーへ視線が流れてしまいます。
この一文は、どのサイトにも当てはまる説明ではありません。改修前の画面と一致し、トップページを変えた理由まで伝えられます。
7．SWELL装飾は文章の役割が決まってから加えた
題材記事は、本文を確定してからSWELL用の装飾へ移しました。使ったのは、キャプションボックス、ステップ、表、画像、コード、関連記事カードです。
装飾の数を増やすのではなく、役割を分けました。
| 文章の役割 | 使用したブロック |
|---|---|
| 最初に全体像を示す | キャプションボックス |
| 固定ページ設定の順番を示す | SWELLステップ |
| 使用ブロックや改修前後を比べる | 表 |
| 実画面を見せる | 画像＋キャプション |
| 実際の指示を区別する | コード |
| 次に読むページを示す | SWELL関連記事カード |
カスタムHTMLを長く書き足す方法は採用しませんでした。WordPressのコードエディターも使わず、ブロック単位で直せる状態を残しています。
SWELLの装飾をどこへ使うか迷った場合は、結論、手順、注意、疑問、次の行動の5つに分けると選びやすくなります。
8．内部リンクは作業順に置いた
内部リンクは、関連しそうな記事を増やすのではなく、読者が次に行う作業へつなぎます。
- AIへ渡す情報を決める段階では、プロンプト設計
- 見出しを作る段階では、記事構成の実例
- 本文を読みやすくする段階では、SWELL装飾
- 公開直前には、WordPress公開前チェック
リンク先のタイトルと投稿IDは、WordPressと公開記事一覧で照合しました。存在しないまとめページや仮URLは使っていません。
9．スマートフォンはPCの縮小版として見なかった
PCで文章と画像が整っていても、スマートフォンでは別の問題が出ました。ヒーロー画像が消え、CTAが横に詰まり、カードの最終行に大きな空きが残ったためです。
確認したのは次の項目です。
- 画面の横スクロールが発生しない
- ヒーローを本文、画像の順で縦に表示する
- CTAを1列の全幅にして押しやすくする
- カード内の文章が窮屈にならない
- 画像とロゴが画面幅から出ない
- トップページ用のCSSが個別記事へ影響しない
- 個別記事のサイドバーが残っている
Gutenbergのモバイル編集プレビューでは本文と画像のはみ出しを確認し、公開したトップページは375〜390px幅でも見直しました。PCだけのスクリーンショットで完成扱いにしなかったことが、画像消失の発見につながりました。
10．公開はURL・SEO設定・画像まで確認してから行った
題材記事は、2026年8月23日21時43分に投稿ID741として公開しました。
- 公開URLが200で開く
- canonicalが公開URLと一致する
- noindexが付いていない
- H1が1件だけ表示される
- descriptionとOGP画像が設定どおり
- 本文画像が読み込まれる
- 主要な内部リンク3件と公式リンク2件が開く
- PC幅で横スクロールが発生しない
公開前の確認項目を上から順に使いたい場合は、次のチェックリストへ進めます。
11．Search Consoleでは登録済み情報とライブURLを分けた
公開直後の2026年8月23日22時57分以降に、Search ConsoleのURL検査を行いました。
最初の表示は「URLがGoogleに登録されていません」「URLがGoogleに認識されていません」でした。公開直後なので、この表示だけで記事の不具合とは判断しません。
ライブURLをテストすると、「URLはGoogleに登録できます」「ページをインデックスに登録可能です」と表示され、有効なパンくずリスト1件も確認できました。その後、インデックス登録をリクエストし、優先クロールキューへ追加されたことを確認しました。
インデックス登録リクエストは、検索結果への掲載や順位を保証する操作ではありません。公開ページが正常に取得できることを確認した後で使います。
AIと人の担当を分けると公開前に戻りやすい
| 工程 | AIに任せたこと | 人が確定したこと |
|---|---|---|
| テーマ・検索意図 | 候補の整理 | 実際に書ける体験がある題材の選択 |
| 競合・公式確認 | 共通点と不足の整理 | 参照先と実画面の確認 |
| 見出し | 並び案の作成 | 読者の疑問と体験が入る順番 |
| 初稿 | 文章のたたき台 | 体験、数値、言い回しの確定 |
| SWELL装飾 | ブロック候補の整理 | 編集画面と公開画面の表示 |
| 内部リンク | 候補の抽出 | 投稿ID、タイトル、URLの照合 |
| 公開 | チェック項目の整理 | 公開操作と公開後の目視確認 |
| Search Console | 結果の意味の整理 | URL検査とリクエストの実行 |
AIが得意なのは、材料を分類し、抜けを見つけ、修正候補を出すことです。画面のずれ、古い画像、本人の感情、公開ボタンを押してよいかまでは、自動で正しく決まりません。
失敗したときに前の工程へ戻れるよう、テーマ、体験メモ、初稿、SWELL装飾、公開確認を分けておく方が安全でした。
次に読む順番
一度に全部を試すより、今いる工程から一つずつ進める方が迷いません。
- AIへ渡す情報と停止条件を決める
- 見出しだけを作り、体験を置く場所を確認する
- 本文を確定してからSWELLで装飾する
- PC・スマートフォン・リンクを確認して公開する
まとめ
AIでブログ記事を作るときに必要なのは、一度で完成させる長い指示より、途中で確認して戻れる工程です。
テーマと検索意図を決め、競合と公式情報を確認し、体験を先に整理する。AIで見出しと初稿を作ったら、人が不要な表現と古い情報を削り、SWELLで役割のある装飾だけを加えます。最後にスマートフォン、公開URL、SEO設定を確認し、必要に応じてSearch Consoleへ送信します。
投稿ID741では、AIだけでは見つけられなかった左ずれと画像消失がありました。公開画面を人が確認したことで、修正前の画像を使わず、実際の完成状態までそろえられました。
最初の1本は、すべてを自動化しようとせず、テーマ、初稿、装飾、公開の4か所で一度止まる方法から始めると進めやすくなります。
SWELLで記事制作を続けたときの使いやすさと、設定で失敗した点まで含めた購入判断は、約1年の使用レビューへ分けています。
コメント