観光ルート最適化で「理論上の最短」が現地で破綻する3つの理由

観光ルート最適化サイトの開発者が踏み抜いた3つの罠は、最適化問題一般における根本的な教訓になる。一つ目が、「日ごとの分量を揃える」という人間的な直感の落とし穴だ。3日の旅なら、各日の負荷を均等にしようと考えるのは自然だ。だが実装してみると、総移動時間は253分になる。一方、移動時間だけを最小化すると200分。53分の差だ。揃えようとしたために、地理を無視した不自然な配分が強制される。アルゴリズムに人間的な気遣いを入れると、かえって結果が悪くなるのだ。

二つ目が、距離と時間の関係だ。直線距離に係数をかけるという初期の近似では、市内速度18km/hで計算していた。実際に空港移動を試すと、3倍の時間がかかる。長距離になるほど優等列車や高速道路の割合が上がるからだ。距離に応じて実効速度を連続的に変えることで、精度は大きく改善された。だがここからが本題である。このアルゴリズムは方向のある誤差を持つ。「仙台駅から松島は約40分（実際）なのに77分と出す」「那覇から美ら海水族館は約2時間（実際）なのに77分と出す」という具合に。鉄道が発達した区間では長く、船や山を挟む区間では短く出る。誤差がランダムではなく偏っているので、「同じ基準で計算しているから比較には使える」とは言えない。開発者は、この誤差の表そのものをユーザーに見せている。精度を上げるのではなく、ユーザーが判断できる状態にした。

三つ目は地名から座標への変換だ。「京都 法隆寺」で東京の法龍寺が返ってくる。「京都 錦市場」で北京の市場が返ってくる。最も悪い例が「金沢 武家屋敷跡」で大分県570km先の同名施設が返ってくることだ。名前が完全一致するので検査を素通りし、570kmなので外れ値検査も素通りする。結果、旅程の宿泊エリアが岡山県美作市に置かれ、総移動時間15時間43分の旅程が出ていたわけだ。検査を3段構えにして対応したが、根本的には「地名データベースの限界」である。ここで開発者が気づいたのは、「正しい答え」と「使える答え」は別物だということだ。数学的に最短でも、現地では成立しない。だからこそ、限界を隠さずに出す。アルゴリズムが強くなるほど、モデルに入っていないものが目立つようになる。その時点で、精度を上げることより、ユーザーが判断できる情報設計に切り替える方が、結果として信頼を得られる。最適化問題に取り組む中小企業のシステム部門には、強い示唆がある。理論値と現実のズレは必ず出る。その時に「精度を上げる」という工程地獄に陥るのではなく、「どこまで行けるか、どこまで行けないか」を可視化する方が、ユーザー満足度も実装の負担も良くなる可能性が高い。