LLMOツールで作った記事の公開前チェック｜本文・画像・JSON-LDを照合する実務手順

LLMOツールで作った記事は、本文が完成した時点と、CMSへ保存できた時点、公開ページを確認できた時点を分けて管理します。公開前には検索意図、事実と根拠、本文と画像、構造化データ、表示と保存状態を確認し、残る作業を担当者へ引き継ぎます。

生成記事の確認では、文章の読みやすさだけを見ても十分とは限りません。原稿では正しかった表がCMSで崩れたり、追加JSON-LDだけが古いまま残ったり、アイキャッチを本文画像と取り違えたりすることがあります。本記事では、ツールやCMSを問わず使える確認の順序と、公開担当へ渡す確認シートを整理します。

原稿完成・CMS保存・公開確認を分けて管理する

原稿完成は、本文、画像、メタ情報などの必要な材料が準備できた状態です。CMS保存は、指定した編集画面にその材料が保存され、開き直して確認できた状態です。公開確認は、公開操作後に読者が見るページの内容やリンクを確認した状態です。それぞれに必要な証拠は異なります。

例えば「画像作成済み」は、CMSの画像として使えることを意味しません。ローカルファイルだけにあるのか、アップロードしたのか、記事へ配置したのか、読者向け表示を確認したのかを分けます。画像のURLが存在することと、正しい記事に正しい画像が表示されることも別です。

この表は本記事の管理上の区分です。CMSに同じ名称のステータスがあるとは限りません。編集システムの状態と、チームの確認状態を対応させて記録します。「下書き保存まで」という依頼なら、その範囲の確認を終え、公開操作をしたかのように報告しないことが大切です。

記事を見る前に、既存記事との役割を確かめる

最初に、この記事を読む人の疑問と、読んだ後にできることを一文で書きます。「AIOツールの記事を増やす」だけでは、確認の基準になりません。「試用結果をどう評価するか決める」「対象AIの採否を整理する」など、読者の判断を明確にします。

次に、公開記事、予約記事、下書きと検索意図を照合します。タイトルの単語が違っていても、同じ読者に同じ比較表を見せて同じ結論へ導くなら、既存記事への追加で済む可能性があります。新しい記事として残す理由は、見出しの言い換え以外で説明できるようにします。

公開一覧だけを見ていると、予約中や未公開の記事との重複を見落とすことがあります。記事台帳には、公開URLだけでなく編集URLや状態も残します。既存記事を整理する場合は、統合やURL変更による影響を別に検討し、チェック作業のついでに削除しないようにします。

内容の量も、検索意図を満たすために判断します。文字数が目標に届いていても、同じ注意点を繰り返しているなら改善が必要です。Googleは生成AI検索向けのガイドでも、ページの量そのものより読者に役立つ独自の内容を重視しています。Google Search Centralのガイド

生成記事を確認する5ステップ

図：原稿完成、CMS保存、公開確認を分け、次の担当へ確認結果と残作業を渡します。

1. 検索意図と既存記事を照合する

想定読者、解決する疑問、記事から得られる判断材料を確認します。公開・予約・下書きの既存記事と役割を比べ、新規記事として必要な内容になっているか確かめます。

見出しだけでなく、本文の表や結論まで見ます。既存記事を読んだ人に追加で何を渡せるかを説明し、比較条件、記録様式、具体的な確認手順などを示します。無理に新規記事へ分けるより、既存記事の不足を補う方が自然な場合もあります。

2. 事実・根拠・適用条件を確認する

製品機能、料金、数値、引用した説明を一次情報と照合します。確認日と適用条件を残し、観測した事実、運用上の提案、架空の例を区別します。

「対応している」という一文でも、対象プラン、地域、追加契約の有無を確認します。根拠のページを開いたことだけでチェックを終えず、その文章を支える記述があるかを見ます。確認できない内容は削る、限定する、確認待ちとして残すなど、公開前に扱いを決めます。

3. 本文・表・画像の内容を整合させる

本文の結論、表の条件、図の順序、画像内の数値と日本語を照合します。重要な情報を画像だけに置かず、適切なaltと必要なキャプションを用意します。

図が五つの手順なら本文の段階と順序をそろえます。図を短くするために省いた条件は、キャプションや近くの文章で補います。装飾としてのアイキャッチと、理解を助ける本文図解では役割が違うため、同じ画像を機械的に使い回す必要はありません。

4. CMSの表示とJSON-LDを確認する

タイトル、要約、見出し、表、リンク、FAQ、画像の配置を確認します。CMSが自動で出力する構造化データと追加欄の内容を照合し、本文と一致する必要な項目だけを残します。

本文を直した後は、FAQやJSON-LDに古い説明が残っていないか見ます。コピーしたスラッグや他記事のURLが混ざっていないかも確認対象です。入力したJSONの構文が正しくても、公開ページで意図どおりに出力されるかは別の確認になります。

5. 下書きを保存し、確認結果を引き継ぐ

指定された状態で保存し、編集画面を開き直して本文・画像・メタ情報が残っていることを確認します。編集URL、確認日、完了した項目、残る作業と担当を記録します。

保存操作の直後にメッセージが出たことだけで終えず、実際に保存された内容を確認します。公開前の下書きで確認できない項目は「未確認」と明記します。公開担当は、その記録から実際の公開ページで確認すべき内容を把握できます。

事実確認は、主張と根拠を一対一で見る

生成記事では、正しい一般論の中へ確認できない細部が混ざることがあります。例えば、ある機能の存在は公式ページに書かれていても、全プランで使えるか、回数制限がないかまでは書かれていないことがあります。根拠より広い範囲へ言い切っていないか確認します。

料金を含めるなら、金額だけでなく税、契約期間、初期費用、オプションなど、記事の比較に必要な条件をそろえます。異なる通貨や契約期間を単純に並べて安い順とする場合は、比較条件が崩れていないかを見ます。今回の記事で料金比較が不要なら、関係のない金額を増やさない方が更新負担を抑えられます。

架空の計算例には、結果のすぐ近くに例であることを記載します。ページ末尾だけに小さく断りを入れると、表や図が単独で共有されたときに実績と誤解される可能性があります。計算式、分母、単位をそろえ、画像に同じ数字を入れた場合も再計算します。

実体験として書く文章には、実際の確認記録が必要です。「検証したところ」「導入企業では」といった言葉を、読みやすくするために付け足さないようにします。自社の製品を紹介する場合は運営者の立場が分かるようにし、第三者の中立評価であるかのように見せないことも確認します。

アイキャッチと本文画像を別々に確認する

アイキャッチは、一覧やシェア時に記事の主題を伝える役割があります。本文図解は、読者が手順や関係を理解するためのものです。アイキャッチだけが設定されていても、本文の指定箇所へ図解が入ったことにはなりません。それぞれの表示場所で確認します。

生成画像は日本語、数字、矢印、順序を目視で確認します。文章としては自然でも図では矢印が逆、表の見出しが入れ替わる、数字だけ旧版ということがあります。画像内に実在サービスのロゴに似た装飾が不要に入った場合は、内容上必要か確認し、誤認を招くものは調整します。

本文画像のaltは、画像が伝える内容を短く説明します。「LLMOツールおすすめ比較人気」のようなキーワードの羅列では、図の意味が伝わりません。Googleの画像ガイドでも、関連する文章の近くへ配置し、文脈に合う説明をaltへ書くことが案内されています。画像SEOの公式ガイド

スマートフォンでも、図の文字が読めるか確認します。大きな図を縮小して表示する場合は、図の要点を本文で説明し、必要なら細かすぎる図を分けます。ファイルの重さ、読み込み、余白、表との位置関係も合わせて見ると、画像が記事を読む妨げになっていないか判断できます。

追加JSON-LDは、本文と自動出力の両方に照らす

追加JSON-LDの欄があるからといって、あらゆる型を入れる必要はありません。手順ならHowTo、項目の一覧なら内容に合うItemListなど、ページに実際に存在する情報から考えます。型を選ぶ前に、何の情報を記述したいのかを文章で説明できるようにします。

HowToは、順序のある手順で結果へ進む内容を表す型です。本文に存在する手順名と説明を用い、確認していない所要時間、費用、成功率を付け足しません。技術的な定義はHowToの公式仕様で確認できます。型に合わない内容を、評価されそうという理由で変形する必要はありません。

CMSが記事情報、パンくず、FAQを自動生成する場合は、その出力を確認して追加欄と重ねないようにします。自動出力の仕組みはCMSごとに異なるため、別サイトで使ったJSONをそのまま転記しません。FAQの回答を修正したのに、追加欄の古いFAQだけが残ると、表示との不一致につながります。

Googleの構造化データ方針では、読者に表示されない内容や誤解を招く情報を記述しないことが求められています。本文の製品条件とJSON-LDの条件が一致するかを確認します。構造化データの一般的な方針

確認は、JSONの構文、型やプロパティ、本文との整合、実際の出力という順で分けます。構文の検証を通過しても、Googleで特定の表示が出たり、AIが引用したりすることを保証するものではありません。使う検証ツールの対象範囲も確認し、対象外の型を検出しないことと、JSONが壊れていることを区別します。

タイトル・URL・内部リンクを照合する

記事のタイトルは、本文で答えている内容と一致させます。「完全対応」「必ず改善」のように本文が証明していない言葉を追加すると、読者の期待がずれます。検索結果向けのタイトルを短くする際も、記事の中心となる判断や対象読者が失われていないか確認します。

Googleはタイトルについて、簡潔で内容が分かる表現や、ページごとに異なる説明を推奨しています。検索結果のタイトルは設定どおりに必ず表示されるわけではありませんが、まず自分が設定する情報を正確にします。タイトルリンクの公式ガイド

スラッグ、編集URL、公開予定URLは用途が違うため、台帳の欄を分けます。公開本文の内部リンクに管理画面のURLやローカルファイルのパスが残っていないか確認します。リンクの表示文が正しくても、飛び先が別の記事ということがあるため、実際に開いて照合します。

正規URLを設定している場合は、他の記事やテスト環境を指していないか確認します。Googleはcanonical指定に絶対URLを使うことを推奨しています。URLの統合や変更を伴う場合は、記事入力とは別にサイト担当者と確認します。正規URLに関する公式ガイド

公開担当へ渡す確認シート

確認シートでは、合否だけでなく証拠と残作業を書きます。「確認済み」とあるのに何を見たか分からないと、次の担当が同じ確認を繰り返すことになります。次の表は、担当者が交代するチーム向けの項目例です。

例えば、原稿と画像がそろっていてもCMSへ接続できなければ、「原稿準備完了、CMS未保存」と記録します。記事の編集URLを取得できない状態を「入稿済み」に含めないことが、作業の取りこぼしを防ぎます。接続が戻ったら、同じ原稿から再開し、既存記事がないか確認してから保存します。

画像だけが未反映の場合も、本文まで再作成する必要はありません。アップロード結果を確認し、成功したファイルを再利用して不足部分を反映します。記事の一部が完了しているときほど、完了した項目と未完了の項目を細かく残すことが役立ちます。

下書きで確認できる範囲と、公開後に確かめる範囲

下書きの編集画面では、入力内容と保存状態を確認できます。読者向けプレビューがある場合は、見出し、表、画像、リンクの表示も確認します。ただし、実際の公開URLの応答や検索エンジンからの取得条件まで確認したことにはなりません。

公開後に確認する項目は、担当とともに残します。ページが正しいURLで開くか、公開日時が意図どおりか、画像やリンクが動くか、必要な構造化データが出力されるかを確認します。検索への掲載やAI回答での言及は別の観測なので、公開作業の完了と混同しないようにします。

LLMOチェキのサービス説明では、記事制作や図解、メタ情報の生成が案内されています。生成を使う場合も、最後に自社の条件に合うか確認する担当を置きます。ツールに必要な機能を整理する際は、LLMO対策に必要な機能の比較記事も参考にできます。制作から確認までを一つの担当表にすると、作った記事を次の工程へ渡しやすくなります。