🗾
codexに全投げして、北海道ドライブスポットレコメンダーを作った話
(本文は、ChatGPTが出力したものを一部加筆したものです)
「現在地から入力した時間(分)または距離(km)で到達可能な市を抽出 → 市を選ぶと観光スポットを表示 → その場でGoogleマップの車ルートに遷移」を体験できる構成です。
やろうと思った経緯
- 北海道に移住して土地勘がないもので、ブログなどを見て行きたいなと思って調べても遠いわ!となることが多いので、現在地から時間や距離を指定することで、その範囲内から探すことが出来ないかと思ったのがきっかけ。
- あと今、codexがアツい!というのを見たので、実際2900円で上限はあれど使い放題なのは良いなと思った。(claude codeのmaxプランは高すぎる)
やってみた感想
- トークンによる従量課金ではなく、上限はあれど使い放題なのはプロンプト内容を気にせず使用できるのは良い(2日間で100回ぐらいやりとりしたが上限に当たることはなかった)
- ここ数年でAIによるコーディングの成長は凄まじいもので、自分が大学生の時にあったら、コンピュータの原理なんぞそっちのけで使って、大学卒業していたかもしれない。
- 使う技術スタックの選定とかは人間がある程度考える必要があるにせよ、ChatGPTにまかせて決めることも可能だと思う。
- 個人開発や軽いデモを見せる程度なら、スピード感を持って作成出来るので相性が良いと感じた。(作業時間は大体5-6時間程度)
- 一方、業務で使うとなると中身がブラックボックス化しやすいので、アウトプットへのレビューやコーディングルールの策定といった知識や経験がより求められるのではないだろうか。
- レビューせずに作ったが、中身を見てみると、変数名がイケてなかったりしてて直したいなーと感じる箇所はあった
- 少なくともコーディングは人間がやるものではなくなると思うが、プログラミングを用いてモノを作るという手法はなくならないと思う。
- プログラマの役割がAIに指示出しやレビューする現場監督的な感じになるんじゃないだろうか
サイトの概要
- 左ペインで「時間/距離のプリセットまたは手入力」「現在地(住所表示)」を設定し、「おすすめを表示」をクリック
- 右ペインには「到達可能な市」のボタンが並ぶ(一覧は出さず、市ボタンのみ)
- 市ボタンを押すと、その市のスポット一覧が表示される(別の市を押すと上書き)
- 各スポットの「Google マップで開く」は、現在地→スポットの「車」ルート(driving)で外部タブを開く
デモ動画
- デモ動画はこちら
コード
技術スタック
- フロントエンド
- Next.js 15(App Router)、React 19、TypeScript 5
- Tailwind CSS v4
- 地図・外部API
- Google Places API(Autocomplete, Nearby, Details, Photos)
- Google Distance Matrix API(時間/距離の到達判定)
- Google Geocoding API(現在地の住所表示)
- Google Maps Directions URL(外部タブで車ルート表示)
- HERE Isoline Routing API v8(到達圏ポリゴン算出・サーバ側)
- ジオ演算
- Turf.js(booleanIntersects, centroid, pointOnFeature など)
サイトの仕様
- 入力(左ペイン)
- モード: 時間(分)/ 距離(km)
- プリセット: 時間 30/60/120 分、距離 20/50/150 km(数値手入力可)
- 出発地: ブラウザのGeolocationで現在地の住所を自動表示
- 到達可能な市の抽出
- 出発地からの到達時間/距離で判定(Distance Matrix)
- 許容帯(入力値から以下範囲で絞り込み)
- 距離: ±10km
- 時間: ±15分
- 市の代表点(locality)を候補化し、重複はスポットの住所を優先して排除
- 市ごとの中心は「市役所」を優先(searchTextで city_hall、なければ city_hall/local_government_office のNearby)
- スポットの抽出
- 市役所を中心に半径10kmで Places Nearby(types: tourist_attraction 等)
- 重複は place_id で uniq
- 住所の市一致優先: formattedAddress に選択市が含まれる候補を先頭へ
- 表示
- 市名ボタンのみ表示(スポット一覧は出さない)
- 押下でスポット一覧を表示
- 「Google マップで開く」= Directions URL(driving, origin=現在地, destination=スポット座標)
- API(主なもの)
- GET
/api/isochrone- Input:
lat,lon,time(分)XORdistance(km) - 処理: HERE Isoline → 北海道の行政界(GeoJSON)と交差 → 交差市 + 代表点
- Cache/Quota: あり
- Output:
{ iso: FeatureCollection, cities: [...] }
- Input:
- POST
/api/nearby- Input:
cityId,center(lat,lon),types[],cityName - 処理: Places Nearby(10km, FieldMask最小)→ 重複統合 + 市一致優先
- Cache/Quota: あり、429/5xxは1回だけ再試行
- Output:
{ cityId, results: [...] }
- Input:
- 既存の補助API: Autocomplete, Search, Details, Photo, Geocode など
- GET
開発のやりとりハイライト、困ったこと
- google map apiでは、時間や距離から到達可能な範囲を絞り込めるのが最大60分だったので、別APIの使用を検討する必要があった
- その時に、ChatGPTに代用可能なAPIはないかと聞いて、HERE APIを紹介されたのは結構助かった
- 次に、到達可能な市を抽出できたとしても、どの地点を中心に周囲のスポットを検索するのか決める必要があり、仕方なく市役所を中心とした。
- 仮に市役所が辺鄙な場所にあった場合、スポットが見つからないことが起こりうる
- 市の発展度で重み付けされているようなデータやAPI機能はないのだろうか
- Google Map APIは、GCPの予算設定により無料枠を超えないようにすることが出来るが、HERE APIは、そういった設定が出来ないため、下手をするとお金を請求される恐怖があった。(月2500リクエストまでは無料なので、そう超えることはないが)
今後やっていきたいこと(やる気があれば)
- データ/地図
- google mapに遷移させるのではなく、同サイト内で完結出来ないか
- リスト表示ではなく、マップ上にピン留めするような視覚的な形で実装が出来ないか
- 検索品質
- スポット表示のチューニング(混雑・季節性・レビューなど)
- カテゴリ分け、絞り込み検索
- チェックイン機能
- 実際に訪れたら記録として残せるように
- AIバスガイド?
- それはもはやカーナビやん
ーーーーーーここからは個人的なご意見ーーーーーーー
- 一部のインターネット驚き屋や情報商材屋が、プログラマは死ぬ。という言説を見かけるが、AIが一人でに、要件定義、開発、レビュー、修正というサイクルが回せるのであれば、確かになくなるのかもしれないが、それは大分先の話と思う。
- 常々疑問に思っているのだが、なぜ一部の人間はAIという言葉を聞くと、なんでもやってくれるドラえもん的なものを想像するのだろうか。(みんな汎用AI好きよね)
- 人間が作り出したモノである以上、欠陥はあると考えるのが自然で、だからこそ最終意思決定や責任は人間に持たせるべきであり、便利ツールの一種と考えるのが妥当というのが一個人の主観。
- 例えるならAIは犬みたいもんで、散歩してたら勝手にどっか行きそうになるので、リードをつけて人間に主導権を持たせるとするのが良いんじゃないかと思ったりしてます。
拝読いただきありがとうございました。
Discussion