PROMPT LIBRARY

構造化データ・技術(発展)

Organization/Person・FAQPage・Article・Product/Offer・HowTo・Review・BreadcrumbListなどschema.org型別の構造化データ生成と、sitemap点検・CDN制御・エラー診断など、既存の技術監査を発展させた周辺タスクをカバーするプロンプト集。

10 PROMPTS

Organization/Person schema生成(sameAs付き・エンティティ確立版)(発展版)

既存の汎用的な「構造化データ生成」に対し、本プロンプトはOrganization・Personに絞り、sameAsによる外部プロフィール(Wikipedia・Wikidata・公式SNS)との紐づけまで踏み込んで生成したいときに使う。 【注意】生成後は必ずリッチリザルトテスト等の検証ツールで構文エラーがないか確認すること。経歴・実績は事実確認済みのものだけを含める。

【使用AI】ChatGPTまたはClaude

あなたはエンティティ確立の観点からOrganization/Person構造化データを設計する担当です。以下の情報をもとに、schema.org準拠のJSON-LDを生成してください。

# 会社情報
- 会社名: 【自社名】
- 対象URL: 【対象URL】
- 所在地・設立年・代表者名: 【わかる範囲で貼り付け、不明な項目は空欄にせず「未記載」と指定】
- 公式SNS・Wikipedia・Wikidata等のURL(あれば): 【箇条書きで貼り付け】
- 代表者・キーパーソンの氏名・役職・経歴(事実ベース): 【箇条書きで貼り付け】

# 出力してほしいこと
1. Organizationスキーマ(name・url・logo・sameAsを含む)
2. 代表者・キーパーソンごとのPersonスキーマ(name・jobTitle・worksForでOrganizationと紐づけ)
3. sameAsに入れるURLの優先順位(Wikidata→Wikipedia→主要SNSの順)を解説つきで提示する
4. 貼り付けられていない情報(未記載指定の項目)はコード内にコメントで「要確認」と記載する

貼り付けていない事実(未確認の実績・肩書等)を新たに作成しないでください。生成したコードの構文に誤りがないか、閉じ忘れ等を自己点検した結果も一言添えてください。

FAQPage schema生成(既存原稿から自動抽出)(発展版)

既存の技術監査カテゴリのFAQPage生成は質問を手入力する前提だったのに対し、本プロンプトは既にある記事本文からQ&Aを抽出してそのままJSON-LD化したいときに使う。 【注意】2023年8月以降、Googleの通常検索結果でのFAQリッチリザルト表示は一般サイトでは縮小されているとされる(※要一次情報確認)。本スキーマの主目的はAIの理解支援であり、検索結果の見た目が変わることを期待しない。

【使用AI】ChatGPTまたはClaude

あなたはFAQPage構造化データの実装担当です。以下の記事本文から質問と回答のペアを抽出し、JSON-LDを生成してください。

# 元記事
【FAQ化したい記事の本文をそのまま貼り付ける】

# 作業してほしいこと
1. 記事本文の中で「質問とその回答」として成立している箇所を5〜8個抽出する
2. 抽出した質問文・回答文だけを使い、新しい情報を追加せずにFAQPageのJSON-LDを生成する
3. 回答(acceptedAnswer)は元記事の該当箇所を要約する形にし、元の意味を変えないようにする
4. 生成したコードの構文を自己点検した結果を一言添える

元記事にない事実・数値を新たに作成しないでください。

Article/BlogPosting schema生成

記事ページに著者・公開日・更新日を含むArticle構造化データを実装したいときに使う。 【注意】dateModifiedは実際に本文を更新した日付を入れること。見た目上の再公開日と実際の更新内容が一致するよう運用ルールを決めておく。

【使用AI】ChatGPTまたはClaude

あなたはArticle構造化データの実装担当です。以下の情報をもとにJSON-LDを生成してください。

# 記事情報
- 記事タイトル: 【記事テーマ】
- 対象URL: 【対象URL】
- 著者名・著者プロフィールページURL: 【貼り付け、不明なら「未記載」】
- 公開日・更新日: 【YYYY-MM-DD形式で貼り付け】
- 発行者(会社名)・ロゴURL: 【自社名】/【貼り付け】
- 記事の要約(1〜2文): 【貼り付け】

# 出力してほしいこと
1. Article(またはBlogPosting)のJSON-LDコード(headline・author・datePublished・dateModified・publisher・image・descriptionを含む)
2. headlineが長すぎる場合(目安110文字程度)は短縮案を提示する
3. authorをPersonオブジェクトとして構造化し、単なる文字列にしない
4. 貼り付けられていない項目はコード内にコメントで「要確認」と記載する

貼り付けていない事実を新たに作成しないでください。

Product/Offer schema生成(EC・サービス販売向け)

商品・有料サービスの価格情報をAIが正確に読み取れるようにするため、Product/Offerの構造化データを実装したいときに使う。 【注意】価格は変更頻度が高いため、実際の販売価格とコード内の価格が乖離しないよう、更新フローを決めておくこと。

【使用AI】ChatGPTまたはClaude

あなたはProduct/Offer構造化データの実装担当です。以下の情報をもとにJSON-LDを生成してください。

# 商品・サービス情報
- 商品/サービス名: 【貼り付け】
- ブランド名: 【自社名】
- 価格・通貨: 【貼り付け(例: 98000円、税込/税抜を明記)】
- 在庫状況: 【在庫あり/在庫なし/受注生産等】
- 対象URL: 【対象URL】

# 出力してほしいこと
1. Product(brand・nameを含む)とOffer(price・priceCurrency・availability・urlを含む)のJSON-LDコード
2. priceCurrencyはISO 4217形式(日本円ならJPY)で出力する
3. price・priceCurrency・availabilityの3点が揃っているか自己点検した結果を一言添える
4. 税込/税抜の区別が原稿から読み取れない場合は、コード生成前に確認を促すコメントを添える

貼り付けられていない価格・在庫情報を推測で埋めないでください。

HowTo schema生成

手順解説記事にHowTo構造化データを実装し、ステップごとにAIが読み取れる形にしたいときに使う。 【注意】手順の正確性(順序・所要時間)は実務担当者が確認したものを使うこと。実際と異なる手順を構造化データに載せない。

【使用AI】ChatGPTまたはClaude

あなたはHowTo構造化データの実装担当です。以下の手順情報をもとにJSON-LDを生成してください。

# 手順情報
- タイトル: 【記事テーマ】(例:〇〇の設定方法)
- 全体の所要時間: 【貼り付け、不明なら「未記載」】
- 手順(ステップ名と説明を1行ずつ): 【箇条書きで貼り付け】

# 出力してほしいこと
1. HowToのJSON-LDコード(name・step(HowToStep)の配列を含む)
2. 各ステップにposition(順番)を明記する
3. 貼り付けられていない所要時間・準備物は無理に埋めず、該当プロパティを省略するか「要確認」コメントを入れる
4. 生成したコードの構文を自己点検した結果を一言添える

貼り付けられていない手順を新たに作成しないでください。

Review/AggregateRating schema生成

実際に集まったレビュー・評価をAIが正確に読み取れる形で構造化データにしたいときに使う。 【注意】実在しないレビューの記載・レビュー評価の操作は景品表示法(ステルスマーケティング規制等)に抵触するおそれがある。実データのみを使用し、投稿者の許諾・匿名化方針も確認すること。

【使用AI】ChatGPTまたはClaude

あなたはReview/AggregateRating構造化データの実装担当です。以下の実データをもとにJSON-LDを生成してください。

# レビューデータ(実際に集まったものだけを貼り付ける)
- 対象商品/サービス名: 【貼り付け】
- 平均評価・評価数・満点の基準(5点満点等): 【貼り付け】
- 個別レビュー例(あれば、投稿者名または「利用者A」等の表記・評価・コメント): 【箇条書きで貼り付け】

# 出力してほしいこと
1. AggregateRating(ratingValue・reviewCount・bestRatingを含む)のJSON-LDコード
2. 個別レビューがある場合はReviewオブジェクトとして併記する
3. 貼り付けられた評価数・平均点をそのまま使い、水増し・改変をしない
4. 実際には存在しないレビューを創作しない、という自己点検の一言を添える

貼り付けられていないレビューデータを推測で作成しないでください。

BreadcrumbList・サイト内構造化データ生成

サイトの階層構造をAIに正しく伝えるため、パンくずリストの構造化データを実装したいときに使う。 【注意】サイト構造そのものの見直しが必要な場合は、構造化データだけでなく実際のナビゲーション・内部リンク設計も合わせて確認すること。

【使用AI】ChatGPTまたはClaude

あなたはBreadcrumbList構造化データの実装担当です。以下のサイト階層情報をもとにJSON-LDを生成してください。

# サイト階層情報
- 対象ページのURLと、トップページからのカテゴリ階層(例:トップ>サービス>〇〇サービス>対象ページ): 【貼り付け】

# 出力してほしいこと
1. BreadcrumbListのJSON-LDコード(各階層にposition・name・itemを含む)
2. 階層の抜け漏れ(例:カテゴリページへのリンクが欠けている等)があれば指摘する
3. 生成したコードの構文を自己点検した結果を一言添える

貼り付けられていない階層構造を推測で補わないでください。

sitemap.xml点検・lastmod整合性チェック

サイトマップのlastmod(最終更新日)が実際の更新日と一致しているかを点検したいときに使う。 【注意】sitemap.xmlは検索順位に直接影響する要素ではないとされるが、更新頻度の把握材料として使われる可能性があるため正確性を保つこと。

【使用AI】ChatGPTまたはClaude

あなたはsitemap.xmlの点検担当です。以下の情報を確認してください。

# 点検対象
- sitemap.xmlの中身(該当部分): 【対象URL】/sitemap.xml の中身、または該当箇所を貼り付ける
- 実際にページ本文を更新した日付(わかる範囲): 【URLごとに実際の更新日を貼り付け】

# 確認してほしいこと
1. sitemap.xml内のlastmodの日付と、実際の更新日が一致しているか(貼り付けた範囲で)
2. lastmodが「サイトマップの再生成日時」になっていて、内容更新と無関係に毎回変わっていないか
3. W3C Datetime形式(例: 2026-07-20)で正しく記述されているか
4. 一致していない・形式が不正なURLがあれば一覧化する

貼り付けられていないURLについては判定しないでください。

CDN/AIクローラー制御設計(Cloudflare等)

Cloudflare等のCDNでAIクローラーを許可・課金・ブロックのどれにするかの方針を、事業判断として整理したいときに使う。 【注意】CDN側の設定変更は正規のクローラー・ユーザーのアクセスにも影響し得るため、変更前後でアクセス状況を必ず監視すること。最終決定は技術担当と経営層で合意のうえ行う。

【使用AI】ChatGPTまたはClaude

あなたはCDN側でのAIクローラー制御方針を整理する担当です。以下の情報をもとに、方針案を作成してください。

# 前提情報
- 事業の性質(独自コンテンツ・調査データを多く持つメディア型か、サービス紹介中心のコーポレートサイトか等): 【貼り付け】
- AI検索での見え方について優先したいこと(引用機会を増やしたいか、学習データへの利用は避けたいか等): 【貼り付け】
- 現在のCDN/WAF利用状況(Cloudflare利用の有無等): 【貼り付け】

# 整理してほしいこと
1. 学習用クローラー(GPTBot・ClaudeBot等)と検索・索引用クローラー(OAI-SearchBot・PerplexityBot等)を分けて、それぞれ「許可/課金/ブロック」のどれを推奨するか、理由とともに提案する
2. 画像変換・重量級APIエンドポイント等、無制限にクロールされるとコスト増になりやすい箇所への注意点を挙げる
3. 一度決めた方針を半年に1度見直すべき理由を1文で添える

「これが唯一の正解」という断定は避け、事業判断としての選択肢を提示する形にしてください。

構造化データエラー診断・修正提案

検証ツールで構造化データのエラー・警告が出た際に、原因の見当をつけ修正方針を整理したいときに使う。 【注意】修正案は必ず実際の検証ツール(リッチリザルトテスト等)で再確認してから本番反映すること。AIの推測だけで本番環境に適用しない。

【使用AI】ChatGPTまたはClaude

あなたは構造化データのエラー診断担当です。以下の情報をもとに、エラーの原因と修正方針を整理してください。

# エラー情報
- 検証ツールで表示されたエラー・警告メッセージ: 【そのまま貼り付け】
- 該当ページの構造化データコード: 【該当するJSON-LDをそのまま貼り付け】

# 診断してほしいこと
1. エラーメッセージが示している問題箇所を特定する
2. 一般的な原因(必須プロパティの欠落、型の誤り、値の形式ミス等)のうち、貼り付けられたコードに該当しそうなものを指摘する
3. 修正案となるコードを提示する(元のコードの構造は保ちつつ、該当箇所のみ修正する)
4. 修正後、再度検証ツールでの確認が必要である旨を明記する

貼り付けられていない情報(サイト全体の構成等)を前提にした診断はしないでください。