【マイレース開発記録(7)】
Flask API設計　　　　　　　　　　　　　　　　　　　　　　

レースの裏側では、何が起きている？

前回までの記事では、

• マイレースを作ろうと思ったきっかけ
• 占星術ロジックの考え方
• フェーズを使って、レースに「リズム」を加える工夫

などについて書いてきました。

今回は少し視点を変えて、
アプリの裏側について書いてみたいと思います。

画面を見ると、うさぎたちが走っていて、
順位が変わったり、メッセージが表示されたりします。

でも、その裏では、

「この人の場合は、今日はどんな結果になるんだろう？」

という計算が行われています。

その計算を担当しているのが、
Flaskで作ったAPIです。

APIという言葉だけ聞くと、少し難しそうですよね。
私も最初から詳しく分かっていたわけではありません。

今回は、

「画面」と「計算する場所」を分けてみよう

というところから始まりました。

レースの結果は、裏側で計算する

マイレースでは、ユーザーがいくつかの情報を入力します。

例えば、

• 生年月日
• 出生時間
• 出生地（都道府県）
• 占いたい日

などです。

これらの情報をもとに、

• 天体の位置
• それぞれのテーマのスピード
• うさぎの順位
• 表示するメッセージ

などを計算します。

この計算を担当するのが、
Pythonで作ったAPIです。

イメージとしては、

画面から情報を送る
↓
サーバーで計算する
↓
計算結果を画面へ返す

という流れです。

最初は、この仕組み自体を
理解するところから始まりました。

「画面」と「計算」を分けてみる

マイレースの画面はJavaScriptで動いています。
一方、天体計算などの複雑な処理はPythonで行います。

そこで、

JavaScript → Pythonへ計算をお願いする

という形にしました。

例えば、

「この生年月日と日時だったら、
今回のレース結果を計算してください」

と、画面側からサーバーへお願いするイメージです。

するとPython側で計算して、

「計算結果はこうなりました」

と返してくれます。

その結果を使って、画面側で

• レースを動かす
• 順位を表示する
• メッセージを表示する

という処理を行います。

こうして、計算するところと見せるところを
分けることにしました。

なぜPythonで計算するの？

大きな理由のひとつは、
天体計算を扱いやすくしたかったからです。

マイレースでは、
Swiss Ephemerisという天体計算のライブラリを使っています。

この部分はPythonで扱うほうが、
自分にとって分かりやすく、実装もしやすいと感じました。

一方で、画面の表示やアニメーションは
JavaScriptが得意です。

そこで、

計算はPython
表示はJavaScript

という役割分担にしました。

それぞれ得意な場所で
仕事をしてもらうようなイメージです。

もうひとつ、分けておきたかった理由

もうひとつ気になっていたのが、
コードが複雑になりすぎないことでした。

もし、

• 画面の表示
• レースのアニメーション
• 天体計算
• 占星術のロジック

を全部ひとつの場所に詰め込んでしまったら、
あとから自分で見たときに、

「これは何の処理だっけ？」

となってしまいそうです。

そこで、
計算に関することはAPIにまとめることにしました。

こうしておけば、画面を変更したときにも、
天体計算の部分まで一緒に直す必要がなくなります。

少しずつですが、
アプリの中を整理していく感覚でした。

将来のことも少し考えてみた

APIという形にしておくと、
あとから別の使い方をすることもできます。

例えば将来的に、

• スマートフォン向けの画面
• 別のWeb画面
• 計算結果を使ったデータ分析

などを作りたくなったときにも、
同じ計算部分を利用できる可能性があります。

つまり、

レースの計算部分を、
ひとつの「サービス」として切り出す

ような考え方です。

このあたりから、単に画面を作るだけではなく、
「この先どう育てていこうかな？」
と考えながら設計するようになりました。

でも、APIを作ったら終わり……ではなかった

ここまで読むと、
「計算する場所を作れば完成！」
と思ってしまいそうですが……

もちろん、そんなに簡単ではありませんでした（笑）。

APIが動くようになると、
今度は別の問題が見えてきました。

例えば、

• 入力されている情報が足りない
• 日付の組み合わせがおかしい
• 想定していないデータが入ってくる

といったケースです。

つまり、

「正しい情報が送られてくるとは限らない」

という問題です。

ここから登場したのが、
バリデーション（入力データのチェック）でした。

そして、この部分が思っていた以上に大変でした。

AIと一緒に設計を整理する

この頃になると、
AIとの対話もかなり役立つようになっていました。

私の場合、いきなりコードを書くよりも、

• 「こういう仕組みにしたい」
• 「ここはPythonに任せたい」
• 「このデータを受け取って、こういう結果を返したい」

と、まず言葉で説明してみます。

すると、

• 処理の順番
• 必要なデータ
• 起こりそうなエラー
• 設計上の気になるところ

などが少しずつ見えてきます。

AIに全部作ってもらうというより、
自分の頭の中にあるものを、一緒に整理してもらう
という感覚に近いです。

「頭の中」から「設計図」へ

開発をしていると、
「こうしたい」という考えはあるのに、
それを頭の中だけで整理するのが難しいことがあります。

特に、処理が複雑になってくると、
「今考えているのはどこの部分だっけ？」
となってしまうこともあります。

そこでAIとの対話を使って、
考えていることを一つずつ言葉にするようにしました。

すると、

• ここは計算の部分
• ここは画面の部分
• ここは入力チェック

というように、少しずつ整理されていきました。

自分にとっては、これがかなり助かりました。

少しずつ「アプリらしく」なってきた

この段階では、まだ完成にはほど遠い状態です。

それでも、

入力する場所がある
↓
サーバーに計算をお願いする
↓
結果が返ってくる
↓
その結果をレースとして表示する

という流れが見えてきました。

それまで頭の中で考えていた仕組みが、
少しずつ実際のアプリの形になってきた感じです。

ここまで来て、
「マイレースは、こういう仕組みで動かしていけばいいんだ」
と、少しずつ実感できるようになりました。

今回の開発で感じたこと

今回のAPI設計で一番印象に残ったのは、

「全部を一度に作らなくてもいい」

ということでした。

最初から完璧な設計を作ろうとすると、
どこから手をつけていいのか分からなくなります。

でも、
「計算するところを分けよう」
「次は入力をチェックしよう」
というように、一つずつ整理していくと、
少しずつ全体が見えてきます。

そして、その整理をAIとの対話で確認しながら進める。
この方法が、今の自分には合っているように感じました。

次回予告

APIができたことで、
マイレースの骨格が少しずつ見えてきました。

ところが、ここで新しい問題が出てきます。

それが、

「入力されたデータ、本当に大丈夫？」

という問題です。

出生地が入っていなかったり、
日付の組み合わせがおかしかったり。

人間なら、
「これ、ちょっと変じゃない？」
と気づくことでも、
コンピューターはそのまま計算しようとしてしまいます。

そこで必要になったのが、
バリデーション（入力チェック）でした。

次回は、

【マイレース開発記録(8)】バリデーション地獄

として、
入力チェックを作っていく中で、
「こんなところまで確認しないといけないのか……」
と悩んだ話を書いていきます。

マイレースが少しずつ、
「考えていたもの」から「実際に動くもの」へ
変わっていく過程を、引き続き記録していきたいと思います。