歩きやすさスコア（ウォーカビリティ）の計算方法と使い方

歩きやすさスコアが答えるのは 1 つの問いです。この玄関から徒歩圏内に、日常生活がどれだけ収まっているか。スーパー、薬局、学校、公園、そして食事ができる場所。それらを 0 から 100 のスケールの数値ひとつに圧縮するため、不動産ポータル、移住向けサイト、AI アシスタントのいずれもがこの指標を採用しています。

この数値は表示しやすく、そして正確に出す価値があります。同じ都市の 2 つの住所が、まったく違う地区にあることは珍しくないからです。この記事では方法を説明したうえで、実データに適用します。MapAtlas POI API を使って 20 のヨーロッパ都市にある 40 の住所で歩きやすさ指数を算出しました。その結果は、このスコアが都市ではなく住所に属することを示しています。

歩きやすさスコアが測っているもの

歩きやすさスコアは近接性の指標です。1 つの座標から徒歩で到達できる日常の目的地を数え、必要度と距離に応じて重み付けします。

この定義から 3 つの帰結が導かれます。3 つとも、スコアを掲載する場所には必ず書いておく価値があります。

これは都市ではなく住所の属性です。 3 km 離れた 2 つの住戸は 30 ポイント以上違うことが普通にあります。これは主張ではなくデータで示せるようになりました。

存在は測りますが、質は測りません。 スコアは 300 m 先にスーパーがあることは分かりますが、品揃えが良いか、価格が高いか、日曜に閉まっているかは分かりません。

距離は測りますが、労力は測りません。 平坦な 1 km も上り坂の 1 km も同じ 1 km として数えます。地形、横断箇所、歩道の質は計算の完全に外側にあります。

これらは手法の欠陥ではなく、1 つの数値が背負える範囲の境界です。

歩きやすさスコアの計算手順

どの実装も、結局は同じ 3 ステップに落ち着きます。

ステップ 1: 住所を座標に解決する

まず住所をジオコーディングして緯度と経度にします。このマッチ精度が、以降すべての処理の上限を決めます。建物単位のマッチなら起点は建物そのものに乗りますが、郵便番号単位のマッチだと数百 m ずれることがあり、徒歩のスケールでは答えが変わります。

ジオコーダーがマッチ精度のフィールドを返すなら、それを使ってください。街路レベルより粗い精度から計算したスコアには、概算であることを明記します。

ステップ 2: 徒歩圏の中にあるものを集める

次に、何を徒歩距離とみなすかを決めます。選択肢は 2 つあり、この選択は見た目以上に効いてきます。

半径は座標から 1 km 以内のすべてを取ります。速く、安く、再現できますが、道路ネットワークを完全に無視します。橋のない川の向こう側 400 m にある店も、隣にあるのと同じように数えられてしまいます。

isochrone は、実際の経路を 15 分歩いて本当に到達できるポリゴンの中身を取ります。1 リクエストあたりのコストは高くなりますが、その代わりに川、線路、高速道路、行き止まりを正しく扱えます。

下の指数では半径 1 km を使っています。公開するベンチマークは、検証したい人が誰でも再現できる必要があるからです。物件ページのライブ機能には isochrone を使ってください。

ステップ 3: カテゴリごとにカーブで採点し、重み付けする

最後に、件数をスコアに変換します。生の件数はここでは使えません。レストランが 40 軒ある地区が 10 軒の地区より 4 倍歩きやすいわけではありませんし、1 軒目のスーパーは 20 軒目よりはるかに重要です。そこで各カテゴリを収穫逓減のカーブで採点します。

// One category, scored 0..1. `target` is the count that earns full marks.
const componentScore = (count, target) =>
  Math.min(1, Math.log(1 + count) / Math.log(1 + target));

// Weighted sum across categories gives the headline 0..100 number.
const score = components.reduce(
  (total, c) => total + componentScore(counts[c.key], c.target) * c.weight,
  0,
);

仕事をしているのは対数です。0 軒から 1 軒になると構成要素のスコアは大きく動き、30 軒から 31 軒ではほとんど動きません。これは人が地区を体感する感覚におおむね一致します。

そのうえで重みを適用します。以下が私たちの重みと、それぞれの理由です。

重みは事実ではなく判断なので、確認して調整できるように私たちの値を公開しています。ファミリー向けポータルなら学校の重みを上げるでしょうし、学生向けの賃貸サイトなら代わりに交通と飲食を上げるでしょう。重みを公開しておくことが、他社のプロダクトの中でも数値を再現可能にします。

良いスコアの目安

スコアはバンドに当てはめて読むと、行動につなげやすくなります。このバンドは下のヨーロッパのサンプルで較正しているため、中ほどの数値は実在のヨーロッパの地区を表しています。

このバンドが表すのは住所周辺の施設の供給量であって、そこまで歩く体験ではない点に注意してください。

MapAtlas Walk Index: ヨーロッパ 20 都市

20 のヨーロッパ都市それぞれで 2 つの住所にこの手法を適用しました。中心の広場と、5 から 8 km ほど外側にある郊外の住宅地区です。件数はすべて MapAtlas POI API の半径 1 km から取得し、2026 年 7 月 28 日に採取しました。

順位よりも、2 つの点の間の差のほうがはるかに重要です。中心部の住所は平均 94、同じ都市の郊外の住宅地の住所は平均 73 でした。青い点が上限に張り付いているのは、ヨーロッパの都心がほぼ構造的に高密度だからです。本当のばらつきを担っているのは緑の点です。

この表からは 3 つの発見が際立ちます。

ローマはサンプル中で内部の差が最も大きく、53 ポイントあります。 Piazza Venezia は 93、まだ十分に市内である Ponte Mammolo は 40 です。その郊外側の座標から 1 km 以内で API が見つけたのはスーパー 4 軒、飲食店 19 軒、緑地 6 か所でした。中心部ではそれぞれ 85、1129、149 です。

郊外の住所が上回った唯一の都市がワルシャワです。 Ursynów が 84 で、旧市街の 82 を上回りました。Ursynów は計画的に整備された住宅地区で、食料品店、学校、クリニック、公園が設計段階から組み込まれているからです。歴史的な中心地であることと、1 週間を過ごしやすい場所であることは別です。

バルセロナとアテネはほとんど落ちません。 差は 2 ポイントと 7 ポイントです。どちらの都市も中層の連続した高密度が、観光の中心部を越えて施設の供給を支えています。

都市の平均値が誤った数字である理由

1 つの都市を分解すると、仕組みがはっきり見えます。

すべての構成要素が同時に落ちています。食料品は 93 から 34、飲食は 96 から 41、学校は 93 から 39 へと下がります。これは 1 つのカテゴリが欠けたせいで、ほかは同等の地区が引き下げられたのではありません。種類の違う場所なのです。

ポータルがこの 2 つの住所をどちらもローマ、歩きやすさ 93 と表示したらどうなるか考えてみてください。郊外の住戸を見に行く購入希望者は都心を期待して現地に着き、内見が物件情報を訂正することになります。各物件自身の座標からスコアを計算すればこのギャップを避けられますし、ページの残りの情報を信頼してもらう理由にもなります。

このスコアで分からないこと

数値と一緒に公開する価値のある制約が 4 つあります。

存在は質ではありません。 1 km 以内のレストラン 6 軒は、それが優れていようとひどかろうと同じスコアになります。スコアが測るのは入手可能性だけだからです。

平坦も急坂も同じスコアです。 近接性の計算に地形は見えないため、リスボンやチューリッヒのような都市ではスコアが楽観的に読めてしまいます。

データの網羅度は国によって差があります。 私たちのデータセットは交通ノードを記録しますが採点には使いません。停留所レベルのタグ付け密度が国ごとに違いすぎ、公平に比較できないからです。チューリッヒがその理由を示しています。Paradeplatz から 1 km 以内でクエリが返した交通ノードは 1 件だけでした。これはスイスの路面電車についての事実ではなく、タグ付けの産物です。これを採点すれば自信ありげに間違った数値が出るので、除外して理由を説明することにしました。

スナップショットはトレンドではありません。 これらの数値は 2026 年 7 月 28 日時点のもので、施設は開店も閉店もします。算出したスコアには必ず日付を添えて公開してください。

物件情報に歩きやすさスコアを追加する方法

購入希望者は、物件について尋ねる前に周辺環境について尋ねます。その問いにページ上で答える物件情報は訪問者を引き留めます。検索エンジンに移動して他所で答えを探させずに済むからです。

実装は 4 ステップに落ち着きます。

1. 物件の住所は取り込み時に一度だけジオコーディングし、座標をマッチ精度と一緒に保存します。ページ表示のたびにジオコーディングしないでください。
2. その座標の徒歩圏を取得します。 15 分の歩行者 isochrone を取り、その中の施設件数を数えます。
3. 自社の重みを適用し、結果をキャッシュします。地区が変わるのは日単位ではなく月単位なので、月次か四半期ごとの更新で十分です。
4. 数値と根拠の両方を表示します。 スコア、構成要素の内訳、そしてその裏にある実在の店舗名や施設名を出してください。

この最後のステップにはもう 1 つの効果があります。ある住所の周りに何があるかを尋ねられたとき、AI 検索エンジンは実在の場所を名前で列挙したブロックなら引用できますが、数値だけでは引用する材料がありません。ブロックを構造化データでマークアップすれば、機械可読にもなります。

{
  "@context": "https://schema.org",
  "@type": "Residence",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Via dei Fori Imperiali 1",
    "addressLocality": "Rome",
    "addressCountry": "IT"
  },
  "additionalProperty": {
    "@type": "PropertyValue",
    "name": "Walkability score",
    "value": 93,
    "maxValue": 100,
    "measurementTechnique": "Weighted amenity density within a 15 minute walking isochrone",
    "valueReference": "Computed 2026-07-28"
  },
  "amenityFeature": [
    { "@type": "LocationFeatureSpecification", "name": "Supermarkets within a 15 minute walk", "value": 12 },
    { "@type": "LocationFeatureSpecification", "name": "Primary schools within a 15 minute walk", "value": 4 }
  ]
}

ここでは 2 つのフィールドが出所を担っています。measurementTechnique は数値の作り方を示し、算出日は値と一緒に流通します。回答エンジンはその両方を、あいまいさなしにそのまま伝えられます。

このスコアが使われる場所

利用面はおおむね商業的価値の順に 3 つあります。物件情報では、スコアが周辺環境の問いにページ上で直接答えます。移住や賃貸の検索では、ユーザーは建物で絞り込む前にライフスタイルで絞り込みます。そして AI アシスタントは、このエリアは歩きやすいかという問いに、物件ページへ誘導せずに答えるケースが増えています。

3 つ目の変化が最も速く進んでいます。日付を明示し、手法と裏付けとなる場所の名前を添えて公開したスコアは、回答エンジンに引用できる具体的な材料を与えます。

元になるデータについては、GeoEnrich API が座標周辺の施設件数と場所の名称を 1 回の呼び出しで返し、Isochrone API がその件数を数える徒歩圏を生成します。採点の重みは自社プロダクト側に置いてください。そこでこそ、自分たちの読者が何を重視するかを反映できます。

まとめ

歩きやすさスコアは、1 つの座標の近くにある日常の目的地を、重み付きかつ距離減衰で数えたものです。住所をジオコーディングし、その徒歩圏の中身を集め、カテゴリごとにカーブで採点して自社の重みを適用します。

都市単位ではなく住所単位で計算してください。20 都市のサンプルでは中心部が平均 94、郊外が平均 73 で、ローマ 1 都市の中だけで 53 ポイントの開きがありました。

そして手法を数値と一緒に公開します。重み、徒歩圏の取り方、採取日、そしてこのスコアが意図的に測っていないものです。