PR-074 会社の基本情報がAIに正しく伝わっているか自信がない——Organization/Person schemaで会社を正しく認識させる方法
こんな悩みはありませんか?
会社概要ページを作ってはいるものの、「会社名」「代表者名」「所在地」といった基本情報が、AIにとって"読み取りやすい形"になっているかは別問題です。文章として書かれているだけでは、AIがどれが会社名でどれが代表者名かを機械的に確実に認識できるとは限りません。「うちの会社は、AIにとって実体(エンティティ)としてちゃんと認識されているのだろうか」という不安に、明確に答える手段がないまま放置されがちです。
この記事でできるようになること
会社名・所在地・代表者情報などの事実と、公式SNS・Wikipedia等の外部プロフィールURLをAIに渡すことで、Organization・Personのschema.org準拠JSON-LD(sameAsによる外部プロフィール紐づけ込み)の下書きを生成できるようになります。
使うプロンプト
入力に必要な素材
- 会社名、対象URL
- 所在地・設立年・代表者名(わかる範囲)
- 公式SNS・Wikipedia・Wikidata等のURL(あれば)
- 代表者・キーパーソンの氏名・役職・経歴(事実ベース)
【Claude推奨・ChatGPTでも実行可】
# 役割
あなたはエンティティ確立の観点からOrganization/Person構造化データを設計する担当です。「AIにとって実体として認識されているか」という不安に応えるため、会社・代表者の基本情報を機械的に読み取れる形へ変換する作業を専門にしており、読み手は会社概要ページの改修を担当するWeb担当者です。
# 入力素材の確認
以下の情報が貼り付けられている前提で作業してください。
- 会社名、対象URL
- 所在地・設立年・代表者名(わかる範囲)
- 公式SNS・Wikipedia・Wikidata等のURL(あれば)
- 代表者・キーパーソンの氏名・役職・経歴(事実ベース)
会社名または対象URLが貼り付けられていない場合は、生成に進まず「会社名・対象URLが確認できません。2項目を埋めて貼り付け直してください」とだけ回答し、そこで処理を止めてください。その他の項目が「未記載」でも作業は継続してください。
# 会社情報
- 会社名: 【自社名】
- 対象URL: 【対象URL】
- 所在地・設立年・代表者名: 【わかる範囲で貼り付け、不明な項目は空欄にせず「未記載」と指定】
- 公式SNS・Wikipedia・Wikidata等のURL(あれば): 【箇条書きで貼り付け】
- 代表者・キーパーソンの氏名・役職・経歴(事実ベース): 【箇条書きで貼り付け】
# 分析・作業手順
1. 貼り付けられた会社情報をOrganizationスキーマの各プロパティ(name・url・logo等)に割り当てる
2. 代表者・キーパーソンごとにPersonスキーマを作成し、worksForプロパティでOrganizationと紐づける
3. 公式SNS・Wikipedia・Wikidata等のURLを、sameAsに入れる優先順位(Wikidata→Wikipedia→主要SNSの順)に沿って並べる
4. 「未記載」指定の項目を洗い出し、コード内にコメントで「要確認」と記載する
5. 生成したコードの構文(括弧・カンマの対応)を自己点検する
# 出力してほしいこと
1. Organizationスキーマ(name・url・logo・sameAsを含む)
2. 代表者・キーパーソンごとのPersonスキーマ(name・jobTitle・worksForでOrganizationと紐づけ)
3. sameAsに入れるURLの優先順位(Wikidata→Wikipedia→主要SNSの順)を解説つきで提示する
4. 貼り付けられていない情報(未記載指定の項目)はコード内にコメントで「要確認」と記載する
# 出力形式
1. 完成したJSON-LDコード
2. sameAsに含めたURLの一覧と優先順位の根拠
3. 3行以内の要約(生成したPersonスキーマの人数/「要確認」の項目数/次に行うべき検証ツールでの確認)
貼り付けていない事実(未確認の実績・肩書等)を新たに作成しないでください。生成したコードの構文に誤りがないか、閉じ忘れ等を自己点検した結果も一言添えてください。
# 品質ガード
- sameAsに入れるURLは、貼り付けられたものだけを使い、それらしいURLを推測で追加しない
- 経歴・実績は事実確認済みのものだけを使い、「それらしく」補完しない
- 設置前に、sameAsのURLが現在も公式に運用されているかを人間が確認する前提であることを明記する実行手順
- 会社の基本情報(所在地・設立年・代表者名)と、公式に運用しているSNS・登録済みのWikipedia/Wikidataページ(あれば)を手元に整理する
- Claudeにプレースホルダを実際の情報に置き換えてプロンプトを実行する
- 生成されたコードをGoogleのリッチリザルトテストとSchema Markup Validatorの両方で構文チェックする
- sameAsに含めたURLを1つずつ実際にクリックし、本当に自社の公式アカウント・公式ページであるかを確認する(似た名前の別法人・なりすましアカウントを誤って含めていないか)
- 検証が済んだコードのみを会社概要ページに設置する
結果の読み解き方
- sameAsは「このURLも同一の実体(会社・人物)を指している」とAIに伝える重要な項目です。1つでも誤ったURL(無関係な同名アカウント等)が混ざると、AIが会社を誤認識するリスクの原因になり得ます。
- 「要確認」コメントが多く残るコードは、事実確認が未了である証拠です。件数が多い場合は、無理に全項目を埋めようとせず、確認できた範囲から段階的に実装してください。
注意点
- 経歴・実績はすべて事実確認済みのものだけを含めてください。未確認の経歴を「それらしく」補完しないよう、AIの出力を必ず精査してください。
- 危険な間違い例: sameAsに、社員個人のプライベートSNSアカウントや、退職済みの元代表者のアカウントをそのまま残してしまうケースがあります。設置前に「現在も公式に運用されているか」を必ず確認してください。
- 生成後は必ずリッチリザルトテスト等の検証ツールで構文エラーがないか確認してください。AIの自己点検コメントだけを信用して未検証のまま公開しないでください。
関連レッスン・関連パターン
- レッスン III-B3 Organization・Personを実装する・IV-C4 Wikipedia・Wikidataとの関係を理解する(sameAsに何を・どの優先順位で入れるべきかの考え方を理解してから実装すると精度が上がります)
- 関連パターン: PR-068 JSON-LDをゼロから生成する方法(他ページ種別への応用)・PR-081 構造化データのエラーを診断し修正する方法(設置後にエラーが出た場合)
確認テスト
選択肢をクリックすると、その場で正誤と解説が表示されます。
Q1. sameAsに、退職済みの元代表者のアカウントや社員個人のプライベートSNSをそのまま残してよい。
正しくは、設置前に「現在も公式に運用されているか」を必ず確認し、不要なものは含めないようにする必要がある。
Q2. sameAsに入れるURLの推奨される優先順位はどれか。
記事はWikidata→Wikipedia→主要SNSの順で解説つきに提示するとしている。
Q3. 「要確認」コメントが多く残るコードへの対応として適切なのはどれか。
「要確認」が多い場合は無理に全項目を埋めようとせず、確認できた範囲から段階的に実装するよう勧められている。
よくある質問
Q. 生成後は検証ツールでのチェックを省略できますか?
できません。必ずリッチリザルトテスト等で構文エラーがないか確認してから公開する必要があります。
Q. sameAsに含めるURLは自分でクリックして確認すべきですか?
はい。なりすましアカウントや別法人の誤混入がないかを実際にクリックして確認する必要があります。
Q. PersonスキーマはOrganizationとどう紐づけますか?
worksForプロパティを使ってOrganizationと紐づけます。