MANIARUの記事制作を続けるうちに、作業は本文を書くだけでは終わらなくなりました。
既存記事との重複を確認し、カテゴリー内の番号を決め、アイキャッチを用意する。SEOの説明文と内部リンクを整え、公開後はPCとスマートフォンで表示を確認する。どれか一つが抜けると、記事の内容が完成していても公開作業としては不十分です。
そこで現在は、執筆から公開後の確認、完了報告までを一つの工程として扱っています。この記事では、MANIARUで実際に増えていった確認項目と、それらを繰り返せる公開フローへ整理した過程をまとめます。
記事を書く以外の作業が増えてきた
最初は、テーマを決めて本文を書き、WordPressへ投稿すれば記事制作は完了すると考えていました。
しかしCATEGORY記事が増えると、既存記事との役割分担、カテゴリー内の通し番号、アイキャッチの形式、内部リンクなど、記事同士を揃えるための判断が必要になりました。
公開後に初めて気づくこともありました。Featured imageが設定されていない記事があり、画像の有無を公開完了条件へ加えました。1200×630で作った画像も、一覧側の表示比率が合っていないと文字やMロゴが切れます。画像ファイルが正しいだけではなく、実際の表示まで見る必要がありました。
こうした経験から、記事制作を「本文を書く作業」ではなく、「一定の状態で公開する工程」として考えるようになりました。
公開までを一つの工程として考える
現在の流れは、次のように整理しています。
- 実体験から記事テーマを選ぶ
- 名前と既存記事との重複を確認する
- 事実や現在の実装を必要な範囲で確認する
- 本文を書く
- カテゴリー、番号、slugを決める
- 1200×630のアイキャッチを作る
- SEO meta、内部リンク、Featured image、OGPを設定する
- 必要な確認を経て公開する
- PCとモバイル、記事一覧を確認する
- 実際に変更した内容を報告する
すべてを自動化したわけではありません。Workには指示に沿った確認、執筆、WordPress操作を任せますが、公開操作ではシステムが求める確認を省きません。公開後の見え方も、実際のページを開いて判断します。
ChatGPT、Work、共通ルールの役割分担は、ChatGPT＋Work＋共通ルールでWordPress制作フローを作ってみたで扱いました。今回は、その流れで記事を作るときに、何を確認して公開品質を揃えるかへ焦点を移します。
最初に名前と重複を確認する
本文を書く前に確認するのが、指示書の名前と記事テーマです。
指示書番号、カテゴリー、記事番号、主題が一致しているかを先に見ます。過去の指示をコピーして作ると、別の記事名や番号が残る可能性があります。重い調査やWordPress操作へ進む前なら、不一致が見つかっても影響を小さくできます。
名前が合っていたら、今回と直接関係する既存記事だけを確認します。サイト全体を毎回調べ直すのではなく、同じカテゴリーや近いテーマを必要な範囲で見ます。
この事前確認を入れた経緯は、AIに作業を任せる前に確認する。名前チェックと重複チェックを入れてみたにまとめています。公開工程では、この確認を執筆前の入口として使っています。
実体験と事実を確認してから書く
MANIARUの記事は、実際に試したことを記録する方針です。そのため、構成に合いそうな失敗や効果を後から作ることはしません。
実装記事なら現在のコードや表示を確認します。運用の記事なら、実際に使っているルールや直近の投稿結果を確認します。確認できない契約内容、当時の操作、発生していないエラーなどは書かず、分からない部分は省きます。
ここで重要なのは、調査量を増やすことではありません。今回の主題を裏付ける事実だけを集め、記事に必要のない設定や過去記事まで探索を広げないようにしています。
アイキャッチにも共通ルールを作る
CATEGORY記事のアイキャッチは、1200×630を基準にしています。左上にはカテゴリー内の通し番号を2桁で表示し、カテゴリー名、テーマを示す短い文字、内容を表す図、公式Mロゴを配置します。
番号はサイト全体の投稿数や指示書番号ではありません。AI、WEB、CODE、BUILDなど、それぞれのカテゴリー内で01、02、03と進めます。実際に番号の基準が揃っていなかったため、既存記事を確認してカテゴリー内番号へ統一しました。
画像の大きさだけで完了とはしません。一覧表示では左右や上下が切れる可能性があるため、番号、主要な文字、Mロゴを安全領域へ置きます。公式Mロゴは既存の透明背景素材を使い、似た形を作り直しません。
一覧で実際に起きた見切れと表示比率の調整は、WordPressの記事一覧でアイキャッチが切れる。表示比率を1200×630に合わせてみたで記録しています。この経験から、画像制作と一覧表示の確認を同じ工程へ入れました。
SEO・内部リンク・OGPまで公開工程に含める
本文が完成したら、短く意味の分かる英数字slugを設定し、SEO SIMPLE PACKの個別meta descriptionへ記事内容を自然にまとめます。検索キーワードを並べるのではなく、その記事で何を扱うかが分かる文章にします。
内部リンクは、読者が次に確認すると理解しやすい記事だけに絞ります。テーマが少し似ているだけの記事を大量につなぐのではなく、今回の前提、詳しい実例、役割の異なる関連技術など、関係を説明できるリンクを選びます。
Featured imageを設定し、その画像が記事ページとOGPで使われていることも確認します。本文、検索結果向けの説明、記事一覧、SNSで共有されたときの画像まで含めて、一つの記事の公開状態だと考えています。
PCとモバイルで確認する
公開後は、公開URLを開いてタイトル、本文、見出し、画像、内部リンクを確認します。
PCで問題がなくても、スマートフォンではタイトルの折り返し、画像の縮小、目次の表示、横スクロールなどが変わります。そのため、PCとモバイルの両方を見ます。CATEGORY記事では、記事単体に加えてカテゴリー一覧も開き、番号、文字、Mロゴが切れていないか確認します。
確認の目的は、サイト全体を毎回点検することではありません。今回追加した記事が、既存の表示ルールの中で問題なく読めることを確かめるためです。
「投稿しない」という判断も工程に入れる
公開工程を作ると、決めた記事を必ず投稿することが目的になりがちです。しかし重複チェックの結果、独立した内容にならないなら、投稿しない方がよい場合があります。
指示書019では、H2/H3と目次リンクの対応をCODE #03候補として調べました。実装は確認できましたが、既存のCODE #02とWEBの目次記事で扱っている範囲との重複が強く、独立記事としては公開しませんでした。
記事数を増やすより、既存記事と何が違うのかを説明できることを優先します。重複なら止める判断も、公開品質を揃える工程の一部です。
完了報告までを一つのサイクルにする
公開確認が終わったら、タイトル、URL、slug、カテゴリー、meta description、使用画像などをまとめます。依頼した範囲以外を変更していないことや、問題・保留事項があるかも記録します。
完了報告は作業後の付け足しではありません。WordPress上で何を変更したか、公開状態をどこまで確認したかを残し、次の作業で同じことを推測し直さないための記録です。
テーマ選定から完了報告までを一つのサイクルにすると、書く、整える、公開する、確認するという流れを毎回同じ基準で進められます。
まとめ
MANIARUでは、WordPressの記事制作を執筆だけで区切らず、名前と重複の確認、事実確認、アイキャッチ、SEO、内部リンク、Featured imageとOGP、PC・モバイル確認、完了報告までを一つの公開工程へ整理しました。
確認項目が増えたのは、手順を複雑にするためではありません。実際に見つかった抜けや表示上の問題を、次の記事で繰り返さないためです。
記事を公開する判断と、重複のため公開しない判断。その両方を工程へ含めることで、記事数ではなく、MANIARUとして残す意味があるかを基準に制作を続けられるようになりました。