1. 食い違いが起きやすいのは、要約・約束・日付
本文を直した後にタイトルだけが残る、AIが説明文に強い表現を足す、別の記事の日付を流用する。こうした食い違いは、本文だけを読み直しても見落とします。
| 確認する場所 | 食い違いの例 |
|---|---|
| タイトルと主見出し | 本文は確認手順なのに「検索順位を上げる方法」と書く |
| 説明文 | 本文に測定結果がないのに「クリック率が改善する」と約束する |
| JSON-LDの内容 | 本文にない実績・評価・質問と回答を追加する |
| 公開日・更新日 | 下書き日を公開日にする、情報確認日を更新日にする |
説明文は、HTMLの meta description に設定するページの要約です。JSON-LDは、記事名や日付などを検索エンジンに伝える構造化データの記述形式です。本文とは別に管理されることがあるため、同じ記事を説明しているかを確かめます。
Googleの生成AIコンテンツの指針は、公開前の手動確認を本文だけでなく、タイトル・説明文・構造化データなどにも適用するよう案内しています。構造化データの一般的な指針も、読者に表示されない内容や誤解を招く内容をマークアップしないことを求めています。
AI検索対策全体の考え方はGEO/AEOの基本、hirostaが進めたサイトの情報整理は自社HPの実践記事で扱います。ここでは、記事を公開する直前の照合に絞ります。
2. 本文を基準に、項目ごとの根拠を並べる
手順1：公開する本文の版を揃える
照合する担当者と、公開候補の本文を決めます。管理画面の原稿とプレビューが違う版では、確認結果を使えません。本文の事実や出典が未確認なら、まず一次資料と照合し、確定できない主張は保留します。本文との一致だけでは、本文そのものの誤りは見つかりません。
次に、設定画面や記事データからタイトル・説明文を取り出し、プレビューまたは生成HTMLから実際に出力される値を読みます。CMSの自動補完や共通テンプレートがある場合は、入力欄だけで確定しないようにします。
手順2：タイトル・説明文・見出し・JSON-LDを突き合わせる
以下は照合記録の作り方の提案です。項目ごとに「出力される値」「本文の根拠」「一致・修正・保留と理由」を残します。根拠欄は「本文全体」で済ませず、該当見出しや段落を書きます。
| 並べる項目 | 本文と照合すること |
|---|---|
| HTMLのtitleと主見出し | 読者・対象作業・分かることが同じか |
| meta description | 要約した手順や条件が本文にあるか |
| 本文の各見出し | 見出しで約束した説明が直下にあるか |
| Articleのheadline・description | 表示タイトルと本文の要約に対応するか |
| 著者・発行者・ページURL | 実際の表示・運営主体・対象ページと一致するか |
| FAQなどの追加データ | 質問と回答が読者にも表示され、同じ内容か |
タイトルの文字列をすべて同一にすることだけが目的ではありません。サイト名を末尾に付ける場合や、検索向けに短くする場合でも、本文と同じ対象・範囲を示せているかを確認します。hirostaのタイトル基準も、タイトルだけで何をして何が分かるかを伝え、本文にない約束をしないことです。
Googleのタイトルリンクの指針は、ページを具体的かつ簡潔に表すタイトルを勧めています。説明文の指針も、ページごとの内容を正確に要約することを案内しています。
手順3：数字・約束・対象条件を探す
タイトルと説明文にある数字、固有名詞、「必ず」「すべて」「自動で完了」といった言葉を拾います。その根拠や条件を本文で示せなければ、削るか表現を直します。AIが作った言葉に合わせて、本文へ未確認の実績を足してはいけません。
たとえば、本文が人による照合を説明しているのに、説明文が「AIだけで公開前チェックが完了」となっていたら、「AIの下書きを人が本文と照合する手順」に修正します。これは説明用の例であり、実際のAI出力や顧客の失敗事例ではありません。
本文側でも、提案する手順と実施済みの確認を分けます。「この方法で成果が出た」と書くには別の根拠が必要で、項目が一致したことを効果の証拠にはしません。
公開記録を使い、主張が成り立つ範囲を判定する
根拠が見つかったら、その記録の実行モード・対象・確認結果で、主張まで言えるかを確かめてください。ここでは、調達ナビの公開デモ事例の「2つの実行モード」「検証で確かめた結果」「検証の確認条件・根拠」と、関連記事の「公開デモの記録から分かること」を材料に、主張ごとに根拠を対応付ける方法を提案します。
2026年10月13日に、これらの記事・事例を照合しました。両ページは2026年10月12日に確認した公開READMEの記録に基づいています。今回はREADMEの現行版でも根拠となる条件を照合しましたが、デモやAPIの再実行はしていません。以下は公開記録に対する今回の分析であり、主張欄は判定を説明するための文例です。公開ページに誤りがあったという報告ではありません。
| 主張 | 根拠の箇所 | 実行モード | 対象 | 確認結果 | 判定 |
|---|---|---|---|---|---|
| APIキー不要のブラウザ実演が動く | 事例「2つの実行モード」 | ブラウザ実演 | デモ内の架空サイト | APIキー不要で固定ルールによる操作と記載。今回の動作確認はしていない | そのまま使える：公開記録上の実演の説明として。AIの性能を示す主張にはしない |
| APIキー不要でAIが仕入先を比べた | 事例「2つの実行モード」 | ブラウザ実演と「Jevで判断」を混同 | デモ内の架空サイト | APIキー不要なのは固定ルールの実演。「Jevで判断」は有料APIを使う | 使えない：APIキー不要の実演をAIの実行結果にはできない |
| AIで仕入先の条件確認を完了した | 事例「検証で確かめた結果」「検証の確認条件・根拠」、関連記事「公開デモの記録から分かること」 | Jevで判断（jev-1.13.0） | デモ内の架空の仕入先10社 | 温度センサー20個・7日後までの条件で、検索・詳細確認・条件収集を40操作で完了した記録 | 条件を足せば使える：AIを使い、デモ内の架空サイトで指定条件の確認を完了した、と範囲を残す |
| 実際の仕入先サイトで比較作業の時間を減らせる | 事例「検証で扱った課題・制約」「補足」、関連記事「公開デモの記録から分かること」 | Jevで判断の記録を実運用へ広げた主張 | 記録は架空サイト。主張は実サイト | 実サイトには追加対応が必要。削減時間は未計測 | 使えない：この記録では効果を判断できないため、効果の主張は保留 |
同じデモの記録でも、実演とAIの実行を混ぜると、固定ルールの動作をAIの成果に変えてしまいます。架空サイトで確認できたことを実サイトへ広げるには、対象サイトでの確認が別に必要です。また、操作を完了した記録だけでは、人の照合や修正を含む比較作業の時間が減ったとは言えません。実行モード、対象、確認結果を分けることで、使える主張と保留する主張が変わります。仕組みや役割分担の詳細は調達ナビの解説記事へ進んでください。
タイトル・説明文・本文・JSON-LDに同じ言い過ぎの文面が入れば、項目同士の一致確認は通っても、根拠の範囲を越える主張が残ります。短い説明文でも「固定ルールの実演」「架空サイト」「削減時間は未計測」など、その主張の成立範囲を決める条件を省かないことが必要です。
次は説明文を直すための文例です。実際の公開ページの誤りや、実際のAI出力ではありません。
| 言い過ぎの文例 | 直した文例 |
|---|---|
| APIキー不要のAIが仕入先を比較し、調達業務を効率化します。 | APIキー不要の固定ルールによるブラウザ実演です。対象はデモ内の架空サイトで、AIの性能や業務の削減時間を示すものではありません。 |
| AIが実際の仕入先の比較を40操作で完了し、作業時間を減らしました。 | 公開記録では、Jevを使い、デモ内の架空10社で温度センサー20個・7日後までの条件確認を40操作で完了しています。実サイトでの削減時間は未計測です。 |
この分析から、照合記録には本文の該当箇所だけでなく、根拠の実行条件と「何を確認していないか」も残すことを提案します。条件を短くして意味が変わるなら、強い主張を使わず、記録が示す範囲まで表現を戻してください。
手順4：公開日・更新日・確認日を分ける
GoogleのArticleの説明では、datePublished は最初の公開日時、dateModified は最後の変更日時です。日付を指定するなら、表示と実際の履歴に合わせます。時刻も管理するサイトではタイムゾーンも揃えましょう。
hirostaでは、公開日・本文を実質的に改修した日・情報源を確認した日を別に管理しています。公開日が未確定の新記事は公開日を省略し、公開履歴と本番反映を確認した後に補います。確認しただけの日を、本文の更新日にはしません。
| hirostaの記事データ | 表示・Articleへの出力 |
|---|---|
| publishedAt | 公開日、datePublished |
| updatedAt | 更新日、dateModified。未設定なら公開日を使用 |
| lastCheckedAt | 情報確認日。dateModifiedの代わりにしない |
該当する公開日・更新日がなければ、Articleの日付項目も省略されます。これは自社サイトの運用であり、すべてのCMSが同じ仕組みとは限りません。
手順5：生成されたHTMLで、修正後の値を読み直す
hirostaでは、記事冒頭の設定データから記事テンプレートを通して、title を表示タイトルとArticleの headline に、seo.description をmetaとArticleの description に出力しています。HTMLの title は seo.title、パンくずは画面と構造化データで共通の設定を使います。2026年10月11日に実装と保守資料で確認した対応です。
同じ元データを使っていても、その文面が本文と合うかは人の確認が必要です。修正後のHTMLで、タイトル・説明文・JSON-LDを読み、表示された本文・見出し・日付と再度照合します。本文にFAQがある場合も、出力された質問と回答を確認します。
3. 文法の検証と、内容の照合を別々に記録する
JSONとして読めること、検索機能が求める項目を満たすこと、本文の内容が正しいことは、それぞれ別の確認です。
| 確認の種類 | 分かること・分からないこと |
|---|---|
| JSONの文法 | 括弧・引用符などの誤り。本文との一致は判断できない |
| 構造化データの検証 | 対応する型や項目の技術的な問題。主張の根拠まで保証しない |
| 人による内容の照合 | 本文の根拠、条件、表示、日付との一致。検索での表示を保証しない |
構造化データの技術的な確認には、Googleが案内するリッチリザルトテストを使えます。対象の型に対応するGoogleの資料と合わせ、エラーと任意項目の警告を区別してください。公開前のコードを使う場合は、認証情報・個人情報・非公開データを外部ツールへ送らないよう、送信してよい範囲を先に確認します。
検証結果には対象の版、確認した日、エラー・警告、修正内容を記録します。内容の照合結果は別に残し、根拠不明の約束や日付があれば、ツールが通っても公開を保留します。この記事では確認方法を説明しており、外部ツールへコードを送信して検証した結果ではありません。
4. 公開後は、本番ページの出力と表示を確かめる
公開したら、開発用のプレビューではなく対象の本番URLを開き、本文・見出し・日付・リンクと、HTMLのタイトル・説明文・JSON-LDを確認します。古い版が配信されていれば、公開処理やキャッシュの状況を担当者に確認します。
公開前の照合記録と同じ項目を使い、確認日と公開した版を追記します。公開日が未確定だった場合は、公開履歴と反映を照合してから補い、補完後の表示と構造化データも確認します。
Googleの検索結果のタイトルリンクは、タイトルや見出しなどから自動的に作られます。スニペットも主に本文から生成され、検索内容によって変わり、説明文が採用されるとは限りません。検索結果が設定どおりでない場合は、まず本文との矛盾や古い情報がないかを見直し、違う表示だけを設定の失敗と決めつけないようにします。
5. この照合で分かることの限界
本文と設定が一致していても、本文自体に誤りがあれば残ります。事実の根拠は一次資料で別に確かめ、対象条件や資料の版が変わったときは該当箇所を見直します。根拠を照合する考え方はAI下書きと一次資料の確認も参考にしてください。
構造化データの検証に通ることは、リッチリザルトの表示や検索順位の改善を保証しません。本記事では順位・表示回数・クリック率の効果を測定していません。自社について確認したのは記事データと出力の対応・保守ルールで、提案した全工程が継続運用されているという実績を示すものではありません。
まず公開候補の一記事で、タイトル・説明文・JSON-LDの値を本文の根拠と並べ、修正と保留を記録しましょう。サイト運営でAIと人の役割を分ける実践は自社サイト運営の記事で扱っています。