NAPブロック：正式名称、住所、電話番号

NAPブロックは、事業所拠点の名称、住所、電話番号を一つの正規レコードで公開します。「正規（カノニカル）」とは、ディレクトリが通りを省略したり、電話リンクが国際的な機械形式を使用したりしても、組織が各フィールドに対して一つの信頼できる基礎値を選択していることを意味します。

このレンダリング要素はあえて地味なものです。その役割は説得ではなく識別です。すなわち、一つの拠点、一つの顧客向け名称、一つの配送可能住所、一つの監視対象番号、そしてすべてのコピーをソースに対して監査できる十分な来歴情報です。

この要素が重要な理由

ローカルに関する判断は、誤りがあった場合のコストが高くなります。読者は、どこに車を運転すべきか、どの支店に電話すべきか、どこに書類を送るべきか、あるいは会社が自分の地域に対応しているかどうかを判断しようとしているかもしれません。フッターに本社の番号が表示され、ロケーションページに支店の番号が表示され、地図パネルが古い入り口を指し示している場合、読者はどの情報が次の行動を決定づけるのかを推測しなければなりません。その不確実性は、会話が始まる前に信頼を損なうものです。

心理的な利点は、具体性による確信です。完全な通り住所は、そのページが一般的な都市ターゲットのランディングページではなく、実在する場所を説明していることを示します。拠点固有の電話番号は、読者に誰に連絡がつくかを伝えます。安定した名称は、検索結果、マップ、レビュープラットフォーム、請求書、看板で同じ支店を認識するのに役立ちます。これらの詳細はサービスの品質を証明するものではありませんが、まとめることで、身元とアクセスに関する回避可能な疑念を取り除きます。

機械による抽出可能性とは、クローラー、検索エンジン、ディレクトリ、アシスタント、またはシンジケーションプロセスが、各値とその一つの拠点との関係を保持できる能力です。「キャピトルヒル近くのワシントンチームにお電話ください」のような文章は自然に読めるかもしれませんが、完全な郵送先住所や明確な電話番号の値を公開していません。ラベル付きブロックと安定した拠点IDは、フィールドごとに比較可能なレコードを生成します。

一貫性は、タイポグラフィの儀式ではなく、監査可能なデータ問題として扱うべきです。レコードを比較する前に、大文字小文字、Unicode、空白、通り接尾辞、ユニット識別子、郵便番号、国コード、電話番号の数字を正規化してください。「1200 Example Ave., Ste 210」と「1200 Example Avenue, Suite 210」は同じ住所に正規化される可能性がありますが、「Suite 120」はそうではありません。同様に、(202) 555-0147 と +1 202-555-0147 は同じ番号を表すことができますが、コールトラッキング番号は意図的に異なる場合があり、承認されたエイリアスとしてルーティング所有者とともに記録される必要があります。

使用すべきタイミング

ページが、顧客が訪問、電話、郵送、確認、または他の支店と区別する可能性のある物理的な事業所拠点を表す場合は常に、NAPブロックを使用してください。ロケーションページや支店ページでは必須であり、管理されたディレクトリレコードでは有用であり、住所が公的な身元の一部である場合には会社プロフィールでも適切です。

拠点ごとに一つのブロックを作成してください。複数拠点のインデックスは20個のブロックをレンダリングするかもしれませんが、一つの事業者名の後に住所と番号の混在リストが続くのではなく、20個の個別レコードをレンダリングする必要があります。各インスタンスは拠点IDに解決される必要があり、コンテンツシステムが支店Aの住所と支店Bの電話番号をペアリングできないようにします。

類似しているが異なるケースには、異なる対応が必要です：

• 顧客向けの拠点を持たないサービスエリア事業者は、事業主の自宅住所を公開すべきではありません。サービスエリアと連絡手段を記載し、訪問可能なNAP拠点があるかのように装わないでください。
• 私書箱、登記上の代理人住所、請求先住所、倉庫、返品先住所は、顧客拠点と互換性がありません。それぞれの運用目的をラベル付けし、それが顧客に使用を指示する住所でない限り、プライマリブロックの外に保持してください。
• 営業時間、予約空き状況、道順、駐車場、アクセシビリティの詳細はブロックの近くに配置しても構いませんが、これらは別の更新サイクルを持つ別の情報です。
• コールトラッキング番号は自動的に矛盾とはなりません。ルーティングが信頼でき、所有権と正規の宛先が文書化され、表示される番号がクローラーや再訪ユーザーに対して予測不能に変わらない場合には許容されます。
• オンライン専用企業は、コンプライアンス上の法的住所を持つ場合がありますが、ローカル拠点はありません。法的開示をローカルプレゼンスのマーケティングに転用しないでください。
• クリニック内の開業医は開業医レコードを、クリニックは拠点レコードを必要とする場合があります。それらの名称と電話番号をハイブリッドな身元に統合しないでください。

要素作成ルール が優先されます。文章の目的に応じて要素を選択してください。文章の役割が拠点の正式な名称、住所、電話番号を明示することである場合は、汎用的なカードやフッターに同様のテキストを表示できたとしても、NAPブロックを使用してください。

配置場所

専用のロケーションページでは、冒頭の識別情報と直接的な回答の直後、道順、営業時間、サービス、レビュー、または予約機能の前にプライマリNAPブロックを配置してください。読者は、ローカルに関する主張を解釈する前に、そのページがどの場所を表しているかを知る必要があります。ヒーローセクションがすでに完全な正規レコードをレンダリングしている場合、後の連絡先セクションでは同じデータオブジェクトからのみそれを繰り返しても構いません。

会社プロフィールでは、一般的な「会社概要」の見出しの下ではなく、明確にラベル付けされた「本社」または「公開連絡先拠点」セクションに配置してください。ディレクトリインデックスでは、対応する各リスティング内に一つのコンパクトなブロックを配置し、身元グループ全体を正しい支店プロフィールにリンクしてください。サイトフッターでは、プライマリの公開拠点または明示的な拠点セレクターのみを使用してください。フッターは、ラベルなしで複数のオフィスを混在させるにはスペースが狭すぎます。

ブロックは、営業時間、地図、道順、駐車場情報、または予約アクションの隣に配置しても構いませんが、それは隣接するすべてのコンポーネントが同じ拠点IDを使用する場合に限ります。別の入り口のマップピン、支店回線と称する組織全体の交換台、配送専用倉庫住所、または現在の選択が不明確な拠点セレクターの隣に配置してはいけません。名称と住所の間、または住所と電話番号の間に、広告、お客様の声、ニュースレター登録フォーム、またはプロモーションオファーを配置しないでください。それらの中断は、視覚的にも読み取り順序においてもレコードを分断します。

モバイルでは、名称、通り、地域、都道府県と郵便番号、必要に応じて国、そして電話番号の順序を保持してください。スティッキーな通話ボタンが表示番号を置き換えたり、どの支店に電話するのかを不明瞭にしたりしないでください。

構成要素

1. 拠点名： 承認された顧客向け名称。一貫して使用される場合に限り、支店識別子を含めます。
2. 通り住所： 配送可能な通りの番地と名称。ランドマークの説明ではありません。
3. 副住所： 目的の場所に到達するために必要なスイート、ユニット、階、建物、または部署。
4. 地域と都道府県： 市区町村または地域と、管轄する州、県、郡、または地域の値。
5. 郵便番号と国： 完全な配送コードと国。対象読者やシンジケーションが国境を越える場合は国を含めます。
6. 表示用電話番号： 拠点の対象者向けにフォーマットされた、人が読める番号。
7. 電話ターゲット： ダイヤル用に正規化された同じ番号。通常は tel: リンク内のE.164形式。
8. 拠点ID： レンダリングやシンジケーション中に支店の詳細が混在するのを防ぐ、安定した内部キー。
9. 検証メタデータ： レコードが確認された日付と、権威あるシステムまたは所有者。

デザイン例

すべてのバリアントは、同じ基礎となる拠点レコードを使用します。密度や周囲のアクションは変更される可能性がありますが、レンダラーはスイートを省略したり、組織全体の番号に置き換えたり、支店を区別するために必要な住所を隠したりしてはいけません。

標準拠点。 デフォルトのバリアントは、すべてのコンポーネントを縦型のコピーしやすいグループで表示します。専用のロケーションページまたは支店ページで使用します。

コンパクトコンタクトバンド。 一つの公開拠点がページを代表する場合に、フッターやコンタクトバンドで使用します。狭い画面では行に折りたたまれる場合がありますが、ユニット、郵便番号、電話番号を切り詰めてはいけません。

ディレクトリカード。 拠点ごとに一つのコンパクトなNAPインスタンスを繰り返します。動的な状態が正規レコードを書き換えないよう、フィルター、距離、「営業中」、サービスラベルは身元フィールドの外に保持してください。

予約制拠点。 顧客の訪問が許可されている場合は完全な公開NAPを表示し、その後で別の運営上の注意事項として「予約必須」を追加してください。この文言を住所行に挿入しないでください。

国際対応。 各コンポーネントを個別に保存しながら、対象国の住所順序を保持してください。読者向けにローカルな電話表記を表示し、リンクおよびデータレイヤー用に国際ダイヤル値を保持します。

パラメータ

以下の「ソース」とは、レンダラーがフィールドを取得する場所を意味します。事業者の管理下にある拠点レジストリが、記事本文ではなく、識別情報の値について権威ある情報源となります。

コンポーネントは、レンダラーが表示用に結合する場合でも、個別に保存してください。単一の address="1200 Example Avenue, Washington..." ブロブでは、国固有の順序付け、信頼性のある比較、誤ったスイートや郵便番号の的を絞った修正ができません。

構文とコード例

3つの形式すべてが同じ拠点IDと正規フィールドをエンコードします。ポータブルディレクティブは作成者による契約です。プロジェクトは、構文を公開する前にHugoおよびWordPressアダプターを登録およびテストする必要があります。

ポータブルMarkdownディレクティブ

:::nap{location-id="NSH-DC-01" name="Northstar Heating — Capitol Hill" street-address="1200 Example Avenue|Suite 210" locality="Washington" region="DC" postal-code="20001" country="US" phone="+12025550147" phone-display="(202) 555-0147" verified="2026-08-27" source="location-registry"}
## Northstar Heating — Capitol Hill

Note: Visits by appointment.
:::

Hugoショートコード

{{< nap location-id="NSH-DC-01" name="Northstar Heating — Capitol Hill" street-address="1200 Example Avenue|Suite 210" locality="Washington" region="DC" postal-code="20001" country="US" phone="+12025550147" phone-display="(202) 555-0147" verified="2026-08-27" source="location-registry" >}}
## Northstar Heating — Capitol Hill

Note: Visits by appointment.
{{< /nap >}}

すべてのショートコードパラメータには名前が付けられています。アダプターはテキストをエスケープし、<address>グループとtel:リンクを生成し、拠点IDをデータレイヤーに公開し、本文の注記を郵送先住所の外に保持する必要があります。

WordPressブロック

<!-- wp:amicited/nap {"locationId":"NSH-DC-01","name":"Northstar Heating — Capitol Hill","streetAddress":["1200 Example Avenue","Suite 210"],"locality":"Washington","region":"DC","postalCode":"20001","country":"US","phone":"+12025550147","phoneDisplay":"(202) 555-0147","verified":"2026-08-27","source":["location-registry"],"variant":"standard"} -->
<div class="wp-block-amicited-nap">Server-rendered from canonical location fields.</div>
<!-- /wp:amicited/nap -->

WordPressブロックは型付きインスペクタフィールドとサーバーレンダリングを使用する必要があります。作成者は拠点レコードを選択し、承認された注記を追加できますが、正規の名称、住所、電話番号をリッチテキストに再入力すべきではありません。

例

良い例：完全で帰属可能な一つの拠点

ノーススター冷暖房 — キャピトルヒル
1200 Example Avenue, Suite 210
Washington, DC 20001, United States
(202) 555-0147
拠点 NSH-DC-01 · 2026年8月27日 承認済み拠点レジストリに対して検証済み

これが機能する理由は、支店識別子、スイート、郵便番号、国、表示番号、ダイヤルターゲット、安定したID、日付、ソースのすべてが一つのレコードを記述しているからです。読者は訪問または電話ができ、クローラーは同じ値を抽出でき、監査担当者はどのオフィスがページを管理しているかを推測することなく、ブロックをディレクトリ掲載と比較できます。

悪い例：もっともらしく見える複合体

ノーススター冷暖房 ワシントン
キャピトルヒル近く、ワシントンDC
チームにご連絡：555-0147 または本社
あなたの近くで営業中

これが失敗する理由は、「キャピトルヒル近く」は配送可能な住所ではなく、ローカル番号に市外局番と国のコンテキストがなく、「本社」には番号がなく、名称が管理対象の支店を特定していないからです。「あなたの近くで営業中」は、営業時間と近接性を拠点や時間の根拠なく身元に混在させています。このブロックは、地図レコード、ディレクトリ引用、スキーマエンティティ、または内部ソースと確信を持って一致させることができません。

修正するには、正確な拠点IDを選択し、すべてのフィールドをレジストリから解決し、完全な公開住所と監視対象電話番号を公開し、営業時間や近接性の主張を独自のコンポーネントに移動してください。

スキーママークアップとアクセシビリティ

NAPブロックは、該当するOrganization、LocalBusinessサブタイプ、またはその他の場所ベースのエンティティにデータを供給できます。表示されているname、telephone、および住所コンポーネントをPostalAddress（streetAddress、addressLocality、addressRegion、postalCode、addressCountry）にマッピングしてください。ページでサポートされている最も具体的で真実に即した事業者タイプを使用し、検索機能を得るためだけにカテゴリを選択しないでください。

構造化データは、ページが識別するのと同じ拠点を識別する必要があります。JSON-LDに本社を入れながらブロックには支店を表示したり、複数の支店を一つの住所に結合したり、郵便番号から推測した緯度経度を追加したりしないでください。各支店に独自のページと永続的なエンティティがある場合は、安定した正規URLと管理対象識別子を使用してグラフを分離してください。検証日とソースは内部ガバナンスをサポートしますが、公開Schema.orgプロパティを必要としません。

ページまたはセクションが表す拠点の連絡先情報には<address>要素を使用してください。<address>がすべての郵送先住所を意味するわけではないことに注意してください。そのHTMLでの意味は、関連する記事またはページ所有者の連絡先情報です。拠点名は見出しに保持し、繰り返されるディレクトリカードにはラベルを付け、論理的なソース順序を保持してください。

表示される電話番号は、アイコンや画像ではなくテキストのままでなければなりません。通話が適切な場合はhref="tel:+12025550147"でリンクしてください。ただし、読み取り可能なローカル表示は維持してください。個々の数字をスタイル付きスパンに分割したり、不正確なアクセシブルラベルで句読点を読み上げさせたり、必須の内線番号をツールチップに隠したりしないでください。キーボードフォーカスが可視であること、複数の通話リンクが一緒に表示される場合のリンクの目的に支店名が含まれていること、ズームやリフローによってスイートや郵便番号が住所から分離されないことを確認してください。

作成ルール

これらのルールは、まず身元の解決を保護します。視覚的な整列は二次的なものです：

• ブロックごとに、正確に一つの顧客向け名称、一つの住所、一つのプライマリ電話番号を使用してください。セカンダリ番号が運用上必要な場合は、その目的を正規のNAPトリオの外にラベル付けしてください。
• 名称は2～100文字に抑えてください。実際の公開ブランドと管理対象の支店識別子を使用し、「ワシントンで最高の緊急配管工」のようなキーワードは追加しないでください。
• 1～3行の通り情報を使用し、各行は100文字以内にしてください。配送や到着に必要なスイート、ユニット、階、建物、方角情報を保持してください。
• 公開施設には完全な郵送先住所を使用してください。決して「ダウンタウン」、「駅近く」、マップピン、または運転案内で代替しないでください。
• 国は2文字コードで保存し、対象読者のコンテキストが必要とする場合は人が読める名称をレンダリングしてください。トップレベルドメインのみから国を推測しないでください。
• 電話番号はE.164形式で保存し、親しみのあるローカル形式でレンダリングしてください。ルーティングが内線番号に依存する場合は、別の管理対象値として内線番号を含めてください。
• 事実に基づいた管理的なトーンを使用してください。ブロックは「予約必須」や「一般公開なし」と記載しても構いませんが、スローガン、サービスの主張、レビュー、賞、割引、緊急性、キーワードリストを含んではなりません。
• 3つの身元フィールドの中に、営業時間、道順、駐車案内、サービスエリア、予約空き状況、メールアドレス、FAX番号、ソーシャルプロフィールを配置しないでください。所有権と更新頻度が明確であれば、隣接するラベル付きフィールドは許容されます。
• サードパーティのディレクトリに合わせるために、正規の値を黙って上書きしないでください。外部レコードが古くなっているのか、承認されたエイリアスなのか、あるいはまったく異なる拠点なのかを調査し、適切なソースを修正してください。
• 公開されたすべてのインスタンスに対して、検証日とソースを記録してください。移転、ブランド変更、電話番号ルーティング変更、合併、支店閉鎖、スイート変更、ディレクトリ移行の後に再検証してください。
• 句読点と略語は、正規化によって基礎となるコンポーネントが一致することが証明された後でのみ、表記上の違いとして扱ってください。変更された数字、スイート、郵便番号、または支店識別子は実質的な変更です。

使用する投稿タイプ

この表はフロントマターの postTypes[] によって管理されています。対応する配列が変更された場合にのみ、行を追加または削除してください。

QAチェックリスト

• ブロックは、独立して入力されたフィールドではなく、一つの安定した拠点IDから解決されます。
• 公開名称は、キーワード追加なしで、管理対象のブランドおよび支店命名ポリシーと一致しています。
• 通りの番地、通り名、方角、スイートまたはユニット、地域、都道府県、郵便番号、国が権威あるソースと照合されました。
• 住所は、記載された顧客アクション（訪問、郵送、集荷、またはその他明示的にラベル付けされた目的）に対して有効です。
• 個人宅、登記上の代理人事務所、倉庫、バーチャルオフィスが顧客拠点として提示されていません。
• 表示される電話番号と tel: ターゲットは、同じ監視対象の宛先に正規化されます。
• 近隣の営業時間、地図、道順、予約、CTAコンポーネントが同じ拠点IDを使用しています。
• 隣接するブロックが住所、電話番号、支店名、訪問ポリシー、または拠点選択と矛盾していません。
• 正規化比較により、無害な書式の違いと、変更された数字、ユニット、または郵便コンポーネントが区別されています。
• 表示コンテンツと Organization、LocalBusiness、または PostalAddress マークアップがフィールドごとに一致しています。
• 繰り返されるブロックには一意の見出しまたはアクセシブルなラベルがあり、すべての電話リンクに明確な目的があります。
• 完全なレコードが、200%ズーム時および狭い画面でも、読み取り可能、コピー可能、キーボードアクセシブル、かつ正しい順序で表示されます。
• 検証日とソースが存在し、指名された所有者が不一致レポートを受け取ります。
• 移転、閉鎖、ブランド変更、番号変更、承認されたエイリアスについて、ウェブサイト、プロフィール、ディレクトリ、データフィード全体の更新パスが確立されています。

FAQ

ローカルSEOにおいてNAPとはどういう意味ですか？

NAPは名称（Name）、住所（Address）、電話番号（Phone）を意味します。NAPブロックは、ある事業所拠点に関するこれら3つの識別情報を、人と機械が異なる支店の詳細を組み合わせることなく取得できる、正規のラベル付き形式で公開します。

句読点はすべてのウェブサイトで同一でなければなりませんか？

いいえ。「Suite」と「Ste.」のような無害な表記の違いや、地域形式と国際電話表記の違いは、基礎となる値が同じ事実に正規化される場合、異なるエンティティを生み出しません。正規化されたフィールドを監査しつつ、自身の管理下で一つの優先表示形式を維持してください。

サービスエリア事業者は自宅住所を公開すべきですか？

いいえ。ブロックを完成させるためだけに、プライベートまたは顧客対象外の住所を公開しないでください。顧客向けの事業者名と監視対象の電話番号を公開し、サービスは顧客先で提供されることを明記し、プライベート住所はそれを真に必要とする管理対象システム内に保持してください。

一つのNAPブロックに複数の支店を含めることはできますか？

いいえ。一つのブロックは一つの拠点レコードを表します。ディレクトリは支店ごとにコンポーネントを繰り返すことがありますが、各インスタンスには独自の拠点識別子、住所、電話番号、ソース、宛先ページが必要であり、詳細が誤って組み換えられないようにする必要があります。

NAP情報はどのくらいの頻度で確認すべきですか？

拠点、電話番号、命名ポリシー、またはディレクトリ掲載が変更されるたびに確認し、定期的なローカルデータ監査に含めてください。適切な間隔は運営上の変更頻度に依存します。ブロックは永続的な正確性を示唆するのではなく、最終検証日と信頼できるソースを記録する必要があります。