<geolocation> HTML 要素の導入

Mari Viana

Minh Le

Thomas Steiner

公開日: 2026 年 1 月 13 日

Chrome 144 以降では、新しい <geolocation> HTML 要素を使用できます。この要素は、サイトがユーザーの位置情報データをリクエストする方法に大きな変化をもたらします。スクリプトによってトリガーされる権限プロンプトから、宣言型でユーザー アクション指向のエクスペリエンスに移行します。権限の状態とエラーを処理するために必要なボイラープレート コードが減り、ユーザーの意図をより強く示すことができるため、ブラウザの介入（サイレント ブロックなど）を回避できます。

このリリースは、広範な実環境テストと、ウェブ標準コミュニティとの厳格な議論の結果です。この要素の有用性を理解するには、その開発の経緯と、設計の基盤となったデータを検証することが重要です。

汎用的な <permission> から特定の <geolocation> へ

<geolocation> 要素は、ページ埋め込み 権限制御イニシアティブの最新の進化形です。このイニシアティブでは、当初、汎用的な <permission> 要素として type 属性を持つ提案されました（元の 説明をご覧ください）。type 属性の値（"geolocation"など）によって、リクエストされる権限のタイプが決まります。たとえば、最初の提案には、カメラ、マイク、位置情報などの値が含まれています。

コンセプトの検証

Chrome 126 ～ 143 で、汎用的な <permission> 要素のオリジン トライアルを実施しました。 このトライアルの目的は、専用の インコンテキスト ボタンによってユーザーの信頼と意思決定が向上するという仮説を検証することでした。

このオリジン トライアルの結果は、このコアコンセプトの検証を 裏付けるものでした。

• Zoom は、`<permission>` 要素を使用してユーザーを復旧に導くことで、カメラまたはマイクのキャプチャ エラー（システムレベルのブロッカーなど）が 46.9% 減少したと報告しています。
• Immobiliare.it では、位置情報フローの成功率が 20% 増加しました。
• ZapImóveis は、`<geolocation>` 要素が表示されたときに、ユーザーが「以前にブロックされた」状態から復旧する成功率が 54.4% でした。

設計の再定義

コンセプトは成功しましたが、実装には改善が必要でした。 Apple （Safari/WebKit）や Mozilla （Firefox）などのブラウザ ベンダーからのフィードバックでは、「ワンサイズですべてに対応できる」要素では、独自の機能の動作に関して複雑さが大幅に増すことが示されました。

そのため、汎用的な権限制御から、ターゲットを絞った 機能固有の要素に移行しました（WICG ディスカッションをご覧ください）。<geolocation> 要素は、これらの特殊なコントロールの最初のリリースです。これに続いて、 専用の <usermedia> 要素（カメラと マイクへのアクセス用）も開発しています。これには独自の別個の オリジン トライアルがあります。

権限の状態（許可または拒否）の管理に重点を置いていた元の提案とは異なり、これらの新しい要素はデータ メディエーターとして機能し、ほとんどのユースケースで JavaScript API を直接呼び出す必要性を効果的に置き換えます。

<geolocation> 要素を使用する理由

現在、位置情報フローは Geolocation API に依存しています。この API は、コンテキスト外で発生した場合や、ページ読み込み時に発生した場合に、ユーザーを中断させる可能性のある権限プロンプトをトリガーします。重要なことに、ブラウザの介入により、これらの命令型プロンプトへの依存は実現が難しくなっています。たとえば、ユーザーがプロンプトを 3 回閉じた場合、Chrome は権限リクエストを積極的にブロックし、最初は 1 週間続く一時的なサイレント ブロック を強制します。つまり、プロンプトをトリガーしようとするレガシー コードがサイレントに失敗し、ユーザーは機能が壊れた状態で、機能を有効にする明確な方法がないままになる可能性があります。さらに、標準のプロンプトにはコンテキストが不足していることがよくあります。プロンプトが予期せず表示された場合、ユーザーは反射的に、または誤ってブロックする可能性があります。この決定が、元に戻すのが難しい永続的なブロックを作成することに気づかずに。このコンテキストのギャップは、機能自体ではなく、拒否率が高い主な要因です。

<geolocation> 要素は、 リクエストが厳密にユーザーによって開始されるようにすることで、コンテキストのギャップの問題を解決します。このモデルには、3 つの明確な利点があります。

• 明確な意図とタイミング: [位置情報を使用] ボタンをクリックすることで、ユーザーは特定の瞬間に位置情報を使用する意図を明示的に示します。これは、ユーザーが価値を理解し、積極的に位置情報を使用したいと考えていることを示し、潜在的なブロックを成功したインタラクションに変えます。
• 復旧の簡素化: ユーザーがサイトの閲覧中に位置情報へのアクセスを以前にブロックした場合（誤って、またはコンテキストが不足しているため）、要素をクリックすると、専用の復旧フローがトリガーされます。これにより、ブラウザのサイト設定に深く移動する手間をかけずに、実際に位置情報を使用したいときに位置情報を再度有効にできます。
• 自動更新: 権限がすでに付与されている場合、要素をクリックすると更新ボタンとして機能し、再プロンプトを表示せずに新しいデータをすぐに取得します。

実装

要素を統合するには、JavaScript API よりもボイラープレートが大幅に少なくなります。デベロッパーは、コールバックとエラー状態を手動で管理する代わりに、ページにタグを追加して onlocation イベントをリッスンできます。

<geolocation
  onlocation="handleLocation(event)"
  autolocate
  accuracymode="precise">
</geolocation>

function handleLocation(event) {
  // Directly access the GeolocationPosition object on the element
  if (event.target.position) {
    const { latitude, longitude } = event.target.position.coords;
    console.log("Location retrieved:", latitude, longitude);
  } else if (event.target.error) {
    console.error("Error:", event.target.error.message);
  }
}

主な属性とプロパティ

• autolocate: 要素が読み込まれたときに位置情報の取得を自動的に試みますが、現在の権限ステータスで許可されている場合に限ります（予期しないプロンプトを防ぎます）。
• accuracymode: 標準の enableHighAccuracy オプションに対応する "precise" または "approximate" の値を受け入れます。
• watch: ユーザーの移動に合わせてイベントを 継続的に発生させる watchPosition() に合わせて動作を切り替えます。
• position: DOM 要素の読み取り専用プロパティ。使用可能になると GeolocationPosition オブジェクトを返します。
• error: リクエストが失敗した場合に GeolocationPositionError を返す読み取り専用プロパティ。

スタイリングの制約

ユーザーの信頼を確保し、欺瞞的なデザイン パターンを防ぐため、<geolocation> 要素には、以前の <permission>要素の実験と同様の特定のスタイリング制限が適用されます。ボタンをサイトのテーマに合わせてカスタマイズできますが、ブラウザにはいくつかのガードレールが適用されます。

• 判読性: テキストと背景色のコントラストが十分であるか（通常は 3:1 以上）がチェックされ、権限リクエストが常に読み取れるようにします。また、要素が欺瞞的に透明にならないように、アルファ チャネル（不透明度）を 1 に設定する必要があります。
• サイズと間隔: 要素には、幅、高さ、フォントサイズの最小値と最大値が適用されます。要素が視覚的に隠れたり、他のコンテンツと欺瞞的に重複したりしないように、負のマージンやアウトライン オフセットは無効になっています。
• 視覚的な整合性: 歪み効果は制限されています。たとえば、変換では 2D 変換と比例スケーリングのみがサポートされます。
• CSS 疑似クラス: 要素は、:granted（権限が有効な場合）などの状態ベースのスタイリングをサポートしています。

プログレッシブ エンハンスメント戦略

新しい HTML 要素の標準化は段階的なプロセスであることを理解しています。 ただし、デベロッパーは、他のブラウザのユーザーとの互換性を損なうことなく、今日から <geolocation> 要素を採用できます。

要素は、適切に機能が低下するように設計されています。 <geolocation> 要素をサポートしていないブラウザは、 HTMLUnknownElement として扱います。 重要なのは、ブラウザが要素をサポートしている場合、子要素はレンダリングされないことです。 これにより、サポートされているブラウザとサポートされていないブラウザの両方で、HTML をクリーンに記述できます。

カスタム フォールバック パターン

フォールバック エクスペリエンスを完全に制御する場合は、通常の JavaScript Geolocation API に接続するボタンなどの子要素を使用できます。

<geolocation onlocation="updateMap()">
  <!-- Fallback contents if the element is not supported -->
  <button onclick="navigator.geolocation.getCurrentPosition(updateMap)">
    Use my location
  </button>
</geolocation>

基本的な例で動作を確認してください。

ポリフィル

または、npm からポリフィルをインストールして、通常の JavaScript Geolocation API に基づくカスタム要素 <geo-location>（ダッシュに注意）ですべての <geolocation> を透過的かつ自動的に置き換えることもできます。ブラウザが <geolocation> 要素をサポートしている場合、 ポリフィルは何も行いません。ポリフィルが動作している様子を示す ポリフィル デモをご覧ください。ソース コードは GitHub にあります。

if (!('HTMLGeolocationElement' in window)) {
  await import('https://unpkg.com/geolocation-element-polyfill/index.js');
}

<geolocation onlocation="updateMap()"></geolocation>

機能検出

より複雑なロジックの場合は、インターフェースを使用してサポートをプログラムで検出できます。

if ('HTMLGeolocationElement' in window) {
  // Use modern <geolocation> element logic
} else {
  // Fallback to legacy navigator.geolocation API
}

まとめ

デベロッパーが新しい <geolocation> HTML 要素を使用して、よりパフォーマンスの高い位置情報 再試行シナリオをどのように実装するのか、楽しみにしています。これは、今日のユーザーが実際にウェブを使用する方法に合わせて調整された、機能固有の要素への移行を表しています。

その他の権限のユースケースについては、Chrome 144 以降で the <usermedia> HTML 要素のオリジン トライアルに参加して、カメラとマイクに同じ人間工学的なメリットをもたらすことができます。

関連リンク

• Chrome プラットフォームのステータスの <geolocation> 要素
• Geolocation HTML 要素の説明
• デモページ
• Mozilla の標準化に関する立場
• WebKit の標準化に関する立場

謝辞

このドキュメントは、Andy Paicu、Gilberto Cocchi、Rachel Andrew によってレビューされました。