自転車ルートを事前に把握する — route-planner の設計判断

長距離の自転車ルートを走る前に、距離と斜度の合計をどれだけ正確に把握できるかは、計画の質を決定します。「全長 80 km、累積標高 600 m」と「全長 80 km、累積標高 1500 m」では、必要な装備、補給計画、所要時間、訓練の組み立てが根本的に変わります。けれども既存の地図サービスや GPS デバイスは、走った後に「結果」を見せることには熱心でも、走る前に「計画」を組み立てる体験には冷たい設計が多いといえるでしょう。

本サイトの既掲記事 ツールとオーケストレーターを分ける で論じた 単一責務 の原則を、自転車という工学の外の分野に適用した実例として、route-planner² の設計判断をはっきり言葉にしてみます。本ツールは perspective-corrector と並ぶ、個人用ソフトウェア・エコシステム の第 1 層の事例研究です。

設計判断 1 ── 単一責務は「走る前の把握」に閉じる

最初の判断は、隣接機能をどこで切るか、でした。自転車関連ソフトウェアと隣り合うのは:

• 走行ログ (Strava、Garmin Connect)
• 地図閲覧 (Google Maps、ヤマレコ)
• ナビゲーション (走行中のターンバイターン案内)
• トレーニング管理 (パワー、心拍、TSS)
• SNS / コミュニティ機能 (記録共有、ランキング)

route-planner はこれらの すべてを目的にしません ── 責務は 「走る前にルートの距離と斜度を把握する」 という一点に閉じます。走行中・走行後の機能は他ツール (Garmin、Strava 等) に任せ、本ツールは事前計画の質を最大化することに集中する、という判断です。

この境界を引くことで、操作画面も実装も計画作業に最適化されます。区間選択、斜度色分け、縦軸を二本持つグラフ ── どれも「事前の理解を深める」という単一目的に揃った設計です。本サイトの既掲記事 偉大なプログラマは優秀なプログラマのコードを利用する で扱った再利用の原則 ── 自分が書かないものは他者の優秀な実装に任せる ── がそのまま日々の運用に反映されています。

設計判断 2 ── 標高データに国土地理院 5m メッシュ DEM を選ぶ

標高データの選択肢は複数あります:

データソース	解像度	カバー範囲	課金
国土地理院 5m メッシュ DEM	5 m × 5 m	日本国内	無料
Google Elevation API	約 30 m	全世界	有料 (リクエスト課金)
SRTM (NASA)	約 30 m	北緯 60° 〜 南緯 56°	無料
ALOS World 3D	30 m	全世界	一部商用課金

日本国内の自転車ルート計画に限定すれば、国土地理院 5m メッシュ DEM が圧倒的に高精度 です。30 m 解像度では橋・トンネル・短い登坂が標高プロファイル上で潰れてしまいますが、5 m 解像度なら道路の起伏が忠実に追えます。

国土地理院は無料で API を提供しており³、「囲い込みに加担しない」という方針 にも整合します。商用 API の従量課金が継続的な負担になることを、利用者に転嫁せずに済む構造です。本サイトの既掲記事 腐らない資産を設計する で論じた、プラットフォーム税を払わない設計 がそのまま実装に現れています。

設計判断 3 ── ルート計算は OpenRouteService に乗る

地点間のルート計算アルゴリズム ── 道路ネットワークから最適経路を探索する処理 ── を自前実装するのは現実的でありません。OpenStreetMap のデータベースに対する Dijkstra / A* 系の経路探索を、自転車向けのコスト関数 (車道、自転車道、歩道、勾配、距離) で適切に走らせる、というのは大規模な計算基盤を要求する処理です。

OpenRouteService⁴ は OpenStreetMap データに基づき、自転車向けの設定一式 (cycling-regular / cycling-road / cycling-mountain / cycling-electric) を含む経路探索を API として提供します。本ツールはこの API に乗ることで、自前実装ゼロでルート計算機能を獲得 しています。

設計判断としては、

• 書かない: ルート計算は自前実装しない、OpenRouteService に依存
• 形式の標準化: GeoJSON で受け渡し、可搬性を確保
• 依存の明示化: API キーの設定を初回起動時の必須の手順として明示し、利用者に依存先を意識させる

書かない設計の典型例で、Eric Raymond の再利用の原則⁵ をそのまま日常の運用に翻訳した形です。

設計判断 4 ── ファイル入出力で既存標準を尊重する

ルートデータの入出力形式は、既存のサイクリング・GIS エコシステムで定着している形式を そのまま採用 しています。

用途	形式	採用理由
内部保存	JSON	言語非依存、git と相性がよい、可読
GPS デバイスからのインポート	GPX	Garmin / Wahoo / 各種スマホアプリの事実上の標準
Google Earth からのインポート	KMZ / KML	観光ルート計画で広く使われる
ルート探索 API レスポンス	GeoJSON	OpenStreetMap エコシステムの標準

新しいフォーマットを発明していない、という点が重要です。本サイトの既掲記事 記録を標準化する で論じた 「個別ツールが標準を発明するのではなく、既存の標準を尊重して繋ぐ」 という規律が、地理情報の領域でも適用されています。GPX をサポートする限り、Garmin Edge、Wahoo Bolt、Strava、ヤマレコ、その他あらゆる自転車向けツールから来るデータを受け入れ、出すこともできる構造になっています。

設計判断 5 ── 斜度色分けで視覚的負荷を下げる

斜度を数値で表示するだけでは、計画作業として不十分です。「最大 12% の登坂」と書かれても、それが全体ルート上のどこにあって、何 km 続くのかが瞬時に把握できないと、計画は具体化しません。

route-planner は地図上に 斜度別カラーマップ を採用しました。

• 青 → 緑 → 黄 → 赤 のグラデーションで斜度を可視化
• 平地は青、緩い登り (~3%) は緑、中程度 (3–7%) は黄、急坂 (7%+) は赤
• 地図を眺めるだけで「赤い区間が何箇所、どの位置にあるか」が把握できる

これは認知負荷を下げる画面設計の判断です。数値での表示が「読み解く」作業を要求するのに対し、色分けは 直感的な認識 に置き換える ── 本サイトの既掲記事 思考と作業を分離する で論じた、思考の側に注意を集中させる道具設計 の具体例だといえるでしょう。計画立案のうち「斜度を解釈する」労働を自動化することで、書き手は「どの装備が要るか」「どこで休むか」という上位の判断に集中できる構造です。

設計判断 6 ── 区間選択で部分最適化を可能にする

長距離ルートは均一ではなく、区間ごとに性格が異なります。「全長 80 km のルートのうち、最後の 15 km が累積標高 400 m を含む」という構造は、全体平均では見えてこない情報です。

本ツールは 標高グラフ上でドラッグして区間を選択する 操作を提供します。

• 選択した区間の距離・累積標高・平均斜度が即座に表示される
• 地図上では選択区間が赤くハイライトされる
• 「最後の登りはどこから始まるか」「補給ポイントを置くなら何 km 地点が良いか」という具体的な計画判断に直結

これは perspective-corrector の「拡大鏡」と類似の、精密な操作を可能にする画面上の仕掛け です。ツールを「全体を見せる」だけでなく「部分にズームインさせる」ことに使えると、計画の解像度が一段上がります。

設計判断 7 ── 橋・トンネルの異常標高補正

5m メッシュ DEM は地表面の標高を返すため、橋やトンネル区間で異常値が発生 します。橋の上を走っているのに、DEM は橋の下の川面の標高を返す ── これが累積標高の計算に直接影響します。

route-planner はこれを 自動的に検出・平滑化 する後処理を実装しました。

• 連続する 2 点間で異常な標高変化 (例: 50 m 以上の急変) があれば、橋・トンネル候補と判定
• 前後の標高をスムーズに補間し、累積標高に反映しない

この補正はその分野の知識 (5m DEM の限界) を理解した上での その場しのぎの調整 ですが、結果として実走行に近い累積標高値が得られます。完璧な汎用解はないものの、自転車という分野での実用上の補正、という線引きが意識的にされています。

---

ここから少し、route-planner を本サイトの既掲記事との接続で読み直してみたいと思います。

本ツールの設計判断は、本サイトで論じてきた複数の主張の 工学の外の分野への適用例 だといえるでしょう。

• 決定論的にではなく、相対的に で宣言した態度 ── 道具を「正解の手順」にせず、媒介する範囲を明示し、状況に応じて意味を確認しなおす ── が自転車という分野で具体化される。「走る前の把握」という単一責務に閉じることは、このツールが媒介する範囲 (= 走行前の計画) を明示することに他ならない。そして設計を進める過程で「自分が本当に欲しかったのは『走る前に距離と斜度の合計を正確に把握すること』だ」と言葉になっていった ── 区間選択の画面を作り、斜度のカラーマップを作り、橋・トンネル補正を作るうちに目的の輪郭が定まる。目的は事後的に立ち上がる という差延の構造そのものである¹
• ツールとオーケストレーターを分ける の 単一責務 が、自転車という分野で「走る前の把握」に閉じる形で実装される
• 偉大なプログラマは優秀なプログラマのコードを利用する の 書かない設計 が、ルート計算 (OpenRouteService)、地図描画 (Leaflet)、グラフ (pyqtgraph)、標高データ (国土地理院) を組み合わせる形で実装される
• 記録を標準化する の 段階間の取り決めの尊重 が、GPX / KML / KMZ / GeoJSON / JSON という地理情報の領域の既存形式の採用として実装される
• 腐らない資産を設計する の 囲い込みに加担しない設計 が、無料で長期安定な国土地理院 / OpenStreetMap / OpenRouteService への依存として実装される ── これは媒介物 (地図・標高データ・経路探索) を自分の制御下に保ち、他者の料金体系や規約変更に縛られないための判断でもある

perspective-corrector が会議スライド補正という分野で同じ原則を実装したのと並べると、方法論は分野を選ばない ことが視覚化できる、と整理することができるでしょう。

オンライン講座の文脈で見れば、自転車は技術者以外も含む幅広い受講者層を惹きつける素材です ── 「自転車のルート計画ツールを自分で設計してみる」という入り口で、UNIX 哲学・書かない設計・標準化原則の実装経験を提供できる、という構造が成立します。本ツールは、技術的に閉じた話ではなく、生活の実用問題に方法論を適用する事例研究 として、教材的価値が大きいといえるでしょう。

参考文献