自社Webサイトのスキーマと内部発信の下地を整える実装

この記事は、タヨリヤデザイン株式会社が行っているAIとWeb構造に関する検証過程の「観測結果の要約」です。

個別の生成AI出力や生ログは公開せず、複数の観測から得られた傾向と構造差のみを整理しています。

前回の記事では、ステージ0〜2として「読める状態」を先に成立させ、未実装を固定することで因果を観測可能にする準備工程を整理しました。

今回はその続きとして、ステージ3（構造とスキーマ整備）と、ステージ4（内部発信＝ブログ実装）の実装内容を記録します。

考え方としては、情報参照がされやすい機能を備えていくというものです。

前回ステージと今回の位置づけ

ステージ0〜2は、観測を成立させるための最低限の公式条件を作り出すことが目標でした。

そのため、スキーマ・FAQ・ブログ・外部統合をあえて入れずに固定し、後続ステージでの差分の説明を可能にしています。

今回は、ステージ3とステージ4として以下のフェーズを扱うことで、内部から公式発信の参照性を高めていきます。

  • スキーマ整備と導線の補強で、意味の骨格と公式性を固める
  • ブログを実装し、Webサイト内部で発信と記録が回り始める状態をつくる
ステージ３～４構成・実装スケジュール
ステージ 期間 目的
ステージ3 21日間 構造とスキーマ整備：FAQと基本スキーマで参照構造を作る
ステージ4 24日間 内部発信完結：ブログで内部完結度を上げる

ステージ3 構造とスキーマ整備

ステージ3で対応したこと

ステージ3は、Webサイトが最低限「読める」状態から、参照されやすい「構造の器（スキーマとページ階層の明示）」を作る工程です。

ここでやるのは、見た目の改善ではなく、意味の置き場所を明示すること。

「会社情報」「よくある質問」といったコンテンツとその導線が、検索にもAIにも分かる形に整理していきます。

  • 基本スキーマ実装
  • パンくずリストの追加
  • 支援診断の実装と問い合わせへの連携
  • FAQのカスタムポスト設置（静的記述 → システム記載へ置換）

ステージ3で実装したコンテンツ

よくある質問（FAQ）は、ステージ2までは静的記述によって支援事業のコンテンツに表示していました。

Wordpressの機能を利用し、カスタムポストとカスタムタクソノミーで動的制御へと変更していきます。

また支援事業への導線を強化するため、簡易的な支援診断を設置。

これは、１０個の設問を用意し、そのうち５個以上に回答することで、タヨリヤデザインの提供する4つの支援ラインへの適性を提案するシステムを実装します。

  • よくある質問
  • 支援診断

ステージ3の状態

ステージ3の状態の一部をスクリーンショットとコードボックスに記録します。

コンテンツの状態のほか、スキーマを実装したことから、リッチリザルト構造なども確認します。

トップページ

ステージ3では、Organization／Person／WebSite／WebPage を @graph で統合し、法人・代表者・Webサイト・各ページの関係を構造として定義しました。

掲載しているスクリーンショットは、トップページに実装した基本スキーマ（Organization／ProfessionalService）が検索エンジンにどのように解釈されているかを確認するためのものです。

リッチリザルトテストでは、telephone および priceRange が未設定として表示されていますが、これらは任意項目であり、構造エラーや検索上の必須要件には該当しません。

本工程で見ているのは内容評価ではなく、構造が正しく認識されているかどうかになります。

ステージ3 トップページ（リッチリザルト確認画面）
ステージ3 トップページ リッチリザルト確認画面
json 
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": [
        "Organization",
        "ProfessionalService"
      ],
      "@id": "https://tayoriya.co.jp/#organization",
      "name": "タヨリヤデザイン株式会社",
      "legalName": "タヨリヤデザイン株式会社",
      "identifier": {
        "@type": "PropertyValue",
        "propertyID": "法人番号",
        "value": "9130001068651"
      },
      "url": "https://tayoriya.co.jp/",
      "description": "Web設計・構築・運用支援を行う京都のWeb制作会社。",
      "foundingDate": "2021",
      "address": {
        "@type": "PostalAddress",
        "postalCode": "600-8449",
        "addressRegion": "京都府",
        "addressLocality": "京都市下京区",
        "streetAddress": "新町通松原下る富永町107-1",
        "addressCountry": "JP"
      },
      "areaServed": "JP",
      "founder": {
        "@id": "https://tayoriya.co.jp/#representative"
      }
    },
    {
      "@type": "Person",
      "@id": "https://tayoriya.co.jp/#representative",
      "name": "丸山 剛史",
      "jobTitle": "代表",
      "worksFor": {
        "@id": "https://tayoriya.co.jp/#organization"
      }
    },
    {
      "@type": "WebSite",
      "@id": "https://tayoriya.co.jp/#website",
      "url": "https://tayoriya.co.jp/",
      "name": "タヨリヤデザイン株式会社"
    },
    {
      "@type": "WebPage",
      "@id": "https://tayoriya.co.jp/#webpage",
      "url": "https://tayoriya.co.jp/",
      "name": "タヨリヤデザイン株式会社",
      "isPartOf": {
        "@id": "https://tayoriya.co.jp/#website"
      },
      "about": {
        "@id": "https://tayoriya.co.jp/#organization"
      }
    }
  ]
}

パンくずリスト（当社についてページ）

パンくずリストは、ユーザーに現在地を示すUIであると同時に、ページ階層を機械的に伝える構造要素です。

掲載しているスクリーンショットは、BreadcrumbListが構造化データとして正しく解釈されている状態を確認するためのものです。

ステージ3 当社についてページ （パンくずリスト反映後の表示状態とリッチリザルト確認画面）
ステージ3 当社についてページ パンくずリスト反映後の表示状態とリッチリザルト確認画面
json 
       {
            "@type": "BreadcrumbList",
            "@id": "https://tayoriya.co.jp/about/#breadcrumb",
            "itemListElement": [
                {
                    "@type": "ListItem",
                    "position": 1,
                    "name": "ホーム",
                    "item": "https://tayoriya.co.jp/"
                },
                {
                    "@type": "ListItem",
                    "position": 2,
                    "name": "当社について",
                    "item": "https://tayoriya.co.jp/about/"
                }
            ]
}

支援診断ページ

支援診断は、営業導線としてではなく、Webサイト内部の情報関係を整理・接続するための構造要素として実装しています。

スクリーンショットは、「質問 → 分類 → 各支援ページ」という関係がページ構造として成立している状態を示すものです。

ステージ3支援診断ページ（反映後の表示状態）
ステージ4 支援診断ページ 反映後の表示状態

よくある質問ページ

FAQPageスキーマ実装後の構造確認画面です。

本工程では、Q&Aが単なるテキストではなく、「Question」「Answer」という構造として認識されているかを確認しています。

生成AIがFAQ由来の情報を参照するかどうかは、この構造化が前提条件になります。

ステージ3 よくある質問ページ（反映後の表示状態とリッチリザルト確認画面）
ステージ3 よくある質問ページ 反映後の表示状態とリッチリザルト確認画面
json 
{
  "@type": "FAQPage",
  "@id": "https://tayoriya.co.jp/faq/#faq",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Webを「経営資産」に変えるとは、具体的にどういう意味ですか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Webを経営資産として扱うとは..."
      }
    }
  ]
}

計測ツールの状態

ステージ2から設計そのものは変えていませんが、スキーマ追加やメニューリンクの増加により、若干の数値変動が見られます。

構造を増やしている以上、多少の変化は想定内です。

ここではスコアの上下ではなく、致命的な悪化が起きていないことを確認しています。

ステージ3 Core Web Vitals 計測結果
ステージ3 Core Web Vitals 計測結果

ステージ4 内部発信完結

ステージ4で対応したこと

ステージ4は、Webサイト内部だけで、AIと人の両方に対して「語れるだけの材料が揃っている状態」を完成させる工程です。

ステージ3で作った「構造の器（スキーマとページ階層の明示）」に、一次情報としてのブログ稼働による情報蓄積をさせていきます。

これは外部統合（ステージ5）で連携した際に、迷わずに強い結びつきを持たせることができると想定した施策でもあります。

  • ブログシステムの実装（記事投稿・アーカイブ・テンプレート整備）
  • 記事構造（見出し、要約、著者・更新・タグ運用）の方針を固定
  • ブログ用スキーマの導入

ステージ4で実装したコンテンツ

  • ブログ

ステージ4の状態

ステージ4においても、状態の一部をスクリーンショットとコードボックスに記録します。

ブログ一覧と投稿記事の状態、リッチリザルト構造も確認します。

ブログページ

ブログ一覧ページが、パンくず・記事構造・Organizationとの関係を保ったまま成立している状態を確認しています。

内部発信がWebサイト全体の構造から切り離されず、一部として機能しているかを見るための工程です。

ステージ4では、ブログ一覧を「CollectionPage」として定義し、記事群を「ItemList」として構造化します。

これは単なる文章の集まりではなく、参照可能な「記事集合」として扱える状態に変換する意味があります。

ステージ4 ブログページ（反映後の表示状態とリッチリザルト確認画面）
ステージ4 ブログページ 反映後の表示状態とリッチリザルト確認画面
json 
{
  "@type": ["WebPage", "CollectionPage"],
  "@id": "https://tayoriya.co.jp/blog/#webpage",
  "url": "https://tayoriya.co.jp/blog/",
  "name": "ブログ",
  "description": "Web設計・AI検索・情報構造に関する観測ログをまとめたブログ一覧です。",
  "breadcrumb": {
    "@id": "https://tayoriya.co.jp/blog/#breadcrumb"
  },
  "mainEntity": {
    "@id": "https://tayoriya.co.jp/blog/#itemlist"
  }
}
json 
{
  "@type": "ItemList",
  "@id": "https://tayoriya.co.jp/blog/#itemlist",
  "name": "ブログ記事一覧",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "url": "https://tayoriya.co.jp/blog/why-130days-stage-definition/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "url": "https://tayoriya.co.jp/blog/why-public-observation-rule/"
    }
  ]
}

ブログ下層ページ（記事ページ）

ブログ記事が単体ページとして成立し、見出し構造・公開日・更新日・導線が整理されている状態を確認しています。

ステージ4では、記事を BlogPosting として構造化し、著者・公開日・更新日・発行主体を明示します。

これにより、記事は単なるテキストではなく、AIと検索エンジンの双方が参照可能な「一次情報単位」として扱われる期待が生まれます。

リッチリザルトテストでは、Article／BlogPosting スキーマが正しく解釈されていることを検証し、記事単体テンプレートとしての計測結果も記録しています。

ステージ4 ブログ投稿記事ページ（記事名 自社Webサイトを読める状態にするまでの実装）
ステージ4 ブログ投稿記事ページ 自社Webサイトを読める状態にするまでの実装
ステージ4 ブログ投稿記事ページ （自社Webサイトを読める状態にするまでの実装のリッチリザルト確認画面）
ステージ4 ブログ投稿記事ページ 自社Webサイトを読める状態にするまでの実装のリッチリザルト確認画面
json 
{
  "@type": "BlogPosting",
  "@id": "https://tayoriya.co.jp/blog/implementation-stage0-2-history/#blog-posting",
  "headline": "自社Webサイトを読める状態にするまでの実装",
  "description": "自社Webサイト構築におけるステージ0〜2の実装記録。",
  "datePublished": "2026-02-04T08:48:18+09:00",
  "dateModified": "2026-02-04T18:37:37+09:00",
  "author": {
    "@type": "Person",
    "@id": "https://tayoriya.co.jp/#representative",
    "name": "丸山 剛史"
  },
  "publisher": {
    "@id": "https://tayoriya.co.jp/#organization"
  },
  "mainEntityOfPage": {
    "@id": "https://tayoriya.co.jp/blog/implementation-stage0-2-history/#webpage"
  },
  "inLanguage": "ja",
  "image": "https://tayoriya.co.jp/ogp.jpg"
}

計測ツールの状態

ブログ機能実装後の計測結果です。

トップページには大きな変更はなく、致命的な性能低下は見られません。

一方で、ブログ記事単体テンプレートの計測では、本文構造や BlogPosting スキーマを含んだ状態での挙動を確認しています。

ステージ4 Core Web Vitals 計測結果
ステージ4 Core Web Vitals 計測結果
ステージ4 ブログ投稿記事ページ Core Web Vitals 計測結果 （自社Webサイトを読める状態にするまでの実装）
ステージ4 ブログ投稿記事ページ Core Web Vitals 計測結果

次に進むための固定と意味

ステージ3と4で行ったことは、派手な施策ではありません。

しかし、AI検索・生成AIが参照する時代においては、目に見えない構造こそが企業理解を決定づけます。

  • 公式情報がページとして存在し、意味が構造として示されている
  • FAQと支援導線がシステムとして回る
  • ブログが稼働し、公開可能な形で記録が蓄積できる
  • Webサイト内部だけで、一定の説明責任を果たせる状態になった

ステージ5での実装と施策

次のステージ5では、外部チャネルに情報を置いて段階的に接続し、タヨリヤデザインという情報概念の塊を、ひとつのまとまりとして完成させていきます。

ただし外部メディアを単に増やすことではなく、分散した情報への整合を行うことが大事になります。