あれから実際にデータを取り始めた。そして、いきなり2つの壁にぶつかった。ただ、ぶつかったおかげで、設計の考え方がぐっと見えてきた。今回はその記録だ。
Contents
壁① 使いたいデータが、今は手に入らない
当初、自分が乗る路線のデータを使うつもりだった。ところが調べてみると、その鉄道会社のリアルタイムデータはあるコンテストの開催期間中しか公開されていないと分かった。今は取得できない。
ここで開発を止めることもできた。でも考え方を変えた。「狙っている路線は最終目的地として取っておき、いま作る場所だけ変える」という発想だ。通年で公開されている別路線（地下鉄）のデータなら、今すぐ取れる。仕組みさえ作っておけば、本命のデータが解禁されたときに差し替えればいい。
「データがないから無理」ではなく「取れるデータで先に仕組みを作る」。これは前回学んだ「環境が整ってから始めない」と、同じ発想だった。
壁② AIに全部やらせようとしていた
最初の設計では「混雑の予測も、その説明も、全部AIにやらせよう」と考えていた。だが、ここで立ち止まった。
AI（大規模言語モデル）は、文章を作るのは得意だが、数値の計算は得意ではない。混み具合のような数字をAIに当てずっぽうで出させるのは、筋が悪い。
そこで役割を分けた。
- 混雑の数値 → 普通の計算式（待ち行列の理論）で出す
- 結果の説明 → その数字を、AIが分かりやすい文章にする
「何をAIにやらせて、何を普通のコードでやるか」。この線引きこそ、AI活用の一番の肝なのだと思う。AIは万能の魔法ではなく、得意な仕事を任せる相棒だ。
計算モデルが、初めて動いた
そして先日、混雑を見積もる計算モデルが初めて動いた。
たとえば「電車の間隔が普段の2.5倍に空けば、ホームで待つ人数もおよそ2.5倍になる」といった数字が、現実の感覚と合う形で出てきた。地味な出力だが、頭の中の「こうなるはず」という構想が、初めて「動く数式」になった瞬間だった。
派手な完成にはほど遠い。だが、データを取り、計算が回り、数字が出る。この一連がつながったことが、今回の一番の収穫だ。
この2週間で学んだこと
2つだ。1つは 「取れるデータで先に作る」。本命を待つ間に、仕組みは作れる。もう1つは 「AIと普通のコードの役割を分ける」。全部AIに丸投げしないことが、かえって精度につながる。
次は、この計算結果をもとに「待つべきか、乗るべきか」を判断するロジックを作っていきたい。
Python / ODPT API / 待ち行列モデル / Claude API
このブログでは、ローカルLLM・Aider・個人開発の試行錯誤をそのまま記録しています。
