予約導線を構造化データで宣言する、機械に扉の位置を教える書き方とは

• Facebook
• X(旧:Twitter)
• はてブ
• LINE

予約ページの場所は、構造化データの中で「予約という行動」と「その入口のURL」を結び付けて示せます。患者さんが画面で使う予約先と同じ場所を指し、入口が変わったら宣言も更新するのが基本です。

ただし、予約先を書くだけでAIが予約を代行したり、来院数が増えたりする保証はありません。まず整える対象は、機械が参照できる予約先の情報です。

この記事では、予約の入口を構造化データで示す記述例と、外部サイトや複数の入口を使う際の選び方を解説しています。

構造化データで予約先までの関係を示す

予約先のURLは、医院の紹介ページのURLと区別して持たせます。「どの医院の、何をするための入口か」がつながると、単なるリンクよりも用途を明示できます。

医院の住所に当たるURLと予約先の違い

医院の紹介ページを示すURLは、所在地や診療内容を読むための場所です。予約先のURLは、患者さんが予約を始めるために開く場所なので、同じ医院に関係する情報でも用途が異なります。

たとえば、トップページに予約ボタンがあっても、そのページのURL自体を予約先として扱うと入口の指定が遠回りになります。ボタンの移動先が予約開始ページなら、宣言でもその移動先を候補にします。

見た目の分かりやすさと宣言内容をそろえるため、患者さんが画面の予約ボタンから目的の入口へ進めるかも点検します。

行動の種類と移動先を組み合わせる

構造化データの共通語彙である スキーマ・オルグ では、potentialAction(実行できる行動)で対象と行動を結び付けられます。ReserveAction(予約の行動型)と、移動先を示す target(行動の入口)を組み合わせるのが記述の候補です。定義はスキーマ・オルグの「行動を関連付ける項目」と「予約の行動型」に示されています。

実装では、医院を表す既存の情報に予約の行動を関連付け、その中へ実際の入口を記します。医院と無関係な場所にURLだけを足すより、何の予約先なのかを保った形で管理できます。

入口の宣言と予約成立は別の情報

予約の入口を公開する段階では、誰かの予約が成立した事実はまだ存在しません。日時を選び終えた結果や個人の予約番号を混ぜると、一般向けの案内に個別の予約情報が入り込んでしまいます。

公開用の宣言に必要なのは、これから予約する患者さんが共通して使う入口です。特定の患者さんの氏名や予約済みの日時を埋めず、予約開始前の状態に対応するURLを選びます。

記述例では予約の行動とURLを分けます

記述の中心は、予約を表す型と、その行動の移動先です。既存の医院情報へ追加する部分として読むと、制作会社との間で変更箇所を共有しやすくなります。

予約先を直接書く基本の形

次の表は、既存の医院情報に加える予約の宣言部分を、項目と値の対応で示したものです。実装時は、これらをJSON-LD(項目名と値で情報の関係を表す記法)で記述し、移動先に実在の予約先URLを指定します。

名称を示す name(行動名)には、移動先の用途に合う短い言葉を入れます。「診療予約」と書いた先が資料請求だけの画面なら、名称と実際にできる行動が食い違います。

URLの文字列には、ホームページ全体の住所ではなく予約開始ページの住所を入れましょう。医院を表す既存の情報との接続は維持し、予約部分だけが別の医院の案内にならない形で追加します。

入口をひとまとまりの情報として書く形

入口をURLだけでなく項目のまとまりとして表すには、EntryPoint(行動を始める接続先)を使う書き方もあります。その中の urlTemplate(URLの組み立て方)に固定の予約先を記す場合の対応を、次の表に示します。項目の意味はスキーマ・オルグの接続先の定義に対応しています。

単純な入口なら、直接URLを書く形とこの形のうち、既存のデータの持ち方に合う片方を採用すると、変更時に直す場所を増やさずに済みます。

項目を増やす前に確定させる値

実際の予約先がまだ決まっていない段階で、想像したURLや仮の画面名を公開するのは避けます。先に確定させるのは、患者さんに案内する行動名と、その行動を始められる公開URLです。

• 予約の名称 … 画面に表示する用途と一致する言葉
• 公開用URL … 共通して使える予約開始ページの住所
• 対象となる医院 … 移動先で予約を受け付ける医院

また、予約を説明するページと実際に予約を始めるページが別なら、どちらを入口として採用したかを記録しておきます。担当者によって違うURLを入れる事態を防ぐための、変更時にも使える共有情報です。

外部サイトでも構造化データの指し先は同じか？

外部の予約サービスを使っていても、予約の行動と入口を結び付ける基本は同じです。変更するのは入口のURLであり、医院の公式サイトの住所は維持します。

公式サイトと外部予約先の書き分け

患者さんが医院の情報を読む場所は公式サイトのまま、予約だけを外部サービスで受け付ける構成にできます。この場合は医院の紹介先を残し、予約の行動に結び付けた移動先へ外部URLを指定します。

外部サービスの運営会社と、実際に診療を受ける医院は別の主体です。外部URLを使うからといって医院名を予約サービス名へ替えず、どの医院への予約なのかが分かる関係を保ちます。

サービスのトップではなく医院別の入口

外部サービスで多数の医院を扱っているなら、自院の予約開始画面を開ける共通URLが候補になります。サービスのトップページを指定すると、患者さんがもう一度医院名を探す場所を予約先として渡す形になるためです。

ただし、予約サービス側が医院別の直接リンクを提供していないときは、URLを推測して作らず、継続利用できる案内先をサービス側へ確認する必要があります。検索後に一時的に表示された住所を、そのまま公開用と決めつけない扱いが安全です。

医院別ページのURLに付いた識別用の文字列は入口を正しく開くために必要な場合があるので、短く見せる目的だけで削らず、提供された公開用URLを使います。

個人専用のURLを宣言に混ぜない

予約サービスには、ログイン後の画面や予約内容の変更画面など、利用者ごとに異なる入口もあります。構造化データとして広く公開する予約先には、特定の患者さんだけが使う住所ではなく一般向けの開始URLを選びます。

「予約に使ったURL」という記憶だけでは、共通の入口と個人の画面を区別できません。予約番号や一時的な認証情報を含む住所なら公開先に使わず、サービスが案内する通常の入口へ戻って指定します。

複数の予約導線から主な入口を選ぶ

入口が複数あるときは、利用対象が同じかどうかで整理します。同じ予約を始める入口なら案内先を集約し、対象が違う入口なら違いが分かる名称を添える方針が適しています。

初診と再診で入口が分かれる場合

初めて受診する患者さんと、受診歴のある患者さんで予約先が異なる場合は、両者を無条件に同じ入口として並べず、共通の案内画面で初診と再診を選べる構成なら、その画面を主な入口にできます。

直接の入口を別々に示す必要がある場合は、予約の行動名にも対象の違いを反映させます。「初診の診療予約」「再診の診療予約」のように区別すると、同じ「予約」が複数並ぶ状態より意図を説明しやすくなります。

名前に書いた条件が機械による振り分けに使われるかは不確かなため、対象を選ぶための案内は患者さんが開く画面にも残しておきます。

同じ予約先への別リンクはまとめる

スマートフォン向けのボタンとパソコン向けのボタンがあっても、どちらも同じ予約画面へ進むなら、入口を別物として増やす理由は乏しくなります。見た目の設置場所ではなく、到着先と受け付ける予約の内容で整理します。

入口の数を増やすほど予約情報が豊かになるわけではなく、同じ対象へ異なる住所を残すと変更対象も増えます。通常の受診で共通して使うURLを軸にすれば、古い入口が取り残される余地を減らせます。

並び順だけに優先順位を託さない

予約の行動を複数記述しても、先頭の項目が必ず優先されるという前提では設計しません。主に案内したい入口があるなら、名称や画面上の案内を含めて、その入口を選んだ理由が分かる状態にします。

たとえば、初診も再診も受け付ける入口と特定の予約枠だけを受け付ける入口なら、通常の受診の案内には前者が候補です。対象の異なる専用枠を主な予約先にすると、一般の患者さんへ適さない入口を渡しかねません。

主な入口を決める基準は、掲載したいページではなく、予約する患者さんが利用条件に合う受付へ進めるかです。

予約先の変更に備えた構造化データの更新箇所

予約サービスの変更時には、画面のボタンだけでなく宣言したURLも更新対象になります。通常の案内先が切り替わる時期に合わせ、古い予約先を残さない管理が必要です。

URLの差し替えと行動名の変更を分ける

同じ診療予約を新しいサービスへ移すだけなら、予約の行動名は保ち、入口のURLを差し替える整理ができます。受付対象も変わるなら、移動先だけでなく初診や再診などの名称も一緒に見直します。

たとえば、再診専用だった入口が初診も受け付けるようになった場合、古い「再診予約」の名称を残すと受付範囲を狭く伝えます。住所の変更と対象の変更を別々に記録しておけば、文字列の差し替えだけで終わる誤りを避けられます。

古い入口を残す期間には理由が必要

旧サービスが開ける間でも、新規の予約を受け付けていないなら、これから予約する人の主な入口として残す理由はありません。予約済みの患者さんが内容を確認するために残す画面と、新しく予約を始める画面は分けて扱います。

一方、切り替え期間中に新旧の両方で受付を続けるなら、対象や受付の分担が分かる案内が必要です。単にURLを2つ並べて公開するだけでは、どちらを使うべきかという判断が患者さん側に残ります。

通常の予約先が新サービスに一本化された時点で、宣言も新しい入口へ寄せる方針を決めておきます。

更新の担当と切り替え日を共有する

予約サービスの管理者とホームページの管理者が異なる場合は、入口の変更が宣言の更新まで届く連絡先を決めます。変更内容を知っている人と実際に書き換える人の間で、URLと反映日を共有する必要があるためです。

• 変更する入口 … 現在のURLと新しいURLの対
• 切り替え時期 … 新しい予約先を案内し始める日
• 更新する担当 … 画面のリンクと宣言を変更する窓口
• 受付対象 … 初診や再診など変更に伴う条件

また、制作会社への連絡には「予約先を変更」の一言だけでなく、公開用の入口として採用した住所を添えます。サービス名だけの連絡では、医院別の予約画面と共通のトップページを取り違える余地が残ります。

実装の依頼は入口の合意から始めます

先に決めるのは、どの予約先を患者さんに案内するかです。採用するURLと対象が合意できれば、構造化データへ反映する依頼も具体的になります。

予約先を決めた理由を短く残す

主な入口を選ぶ理由は、「初診も再診もこの画面から始める」のように利用対象との関係で残すと、候補が増えたときにも同じ基準で選び直せます。

外部サービスを使う場合も、医院別の公開入口として提供されたURLだと分かる記録が役立ちます。担当者の記憶に頼らず、次に予約先が変わるときも採用した理由を引き継げます。

依頼文には行動名とURLをそろえる

制作会社への依頼では、医院の公式サイトの住所を変えたいのか、予約の行動の移動先だけを変えたいのかを明記します。「既存の医院情報に診療予約の行動を関連付け、指定した公開URLを入口にする」という書き方なら、目的と変更対象をそろえられます。

初診と再診で入口が違う場合は、対象ごとの名称と住所を対にして渡しましょう。共通の案内画面を主にする方針なら、その画面を採用する旨も加えると、実装側が独自に優先順位を決める状況を避けられます。

引き継ぎには、行動名と公開URLの対応表で住所と用途を残し、次の担当者が入口を選び直す際の判断材料にします。

AI経由の集患と実装の完了を分ける

予約の入口を構造化データで示す作業は、公開する情報の意味を整える取り組みです。実装が終わっただけで、AIからの紹介や予約が増えたと評価するのは早計です。

予約したいのに入口が分からない状況は、受診を考える患者さんにとって負担になります。その負担を減らす方向で案内先をそろえつつ、機械がどう利用するかについては、宣言した事実と実際の利用を分けて捉える姿勢が大切です。

依頼内容は「AIに必ず予約させる」ではなく、「現在利用できる予約の入口を、医院との関係が分かる形で公開する」と定めます。変更後も同じ入口を案内し続けられる管理まで含めると、実装の目的が曖昧になる事態を避けられます。

よくある質問

• Facebook
• X(旧:Twitter)
• はてブ
• LINE