開発ど素人がCodexで西洋占星術Webサービスに挑戦してみた
今回は、久しぶりにAIの話です。OpenAIのコーディングエージェント「Codex」のデスクトップアプリを初めて使ってみました。
せっかく試すなら、単純なサンプルではなく、Webアプリ開発初心者には少し複雑で、ちょっと背伸びが必要なお題にしたい。
趣味でたまに西洋占星術のホロスコープを読んでいるのですが、これをWebサービス化してみたらどうだろう？
やりたいことは、ざっくりこうです。
- 出生年月日、出生時刻を入力する
- 出生地は市区町村単位で入力する
- ホロスコープを生成する
- 天体、サイン、ハウス、アスペクトをそれぞれ表で出す
- さらに8000字程度の解説も出す
- それらをPDFでダウンロードできるとなお良し
自分で言っておいて、だいぶ複雑そうな気が…。
でも調べていくと、占星術データのAPIとして「Prokerala」が使えそうだと分かりました。
天体位置やハウス、アスペクトの計算はProkeralaに任せられる。日本語の長文解説はOpenAIの大規模言語モデル（LLM）で生成できそう。画面やPDF、データの持ち方は自前で設計する。
ここから、Codexとの作業が始まりました。
まずはCodexのインストールから
最初にやったのは、Codexデスクトップ版のインストールです。それからGitを設定し、プロジェクトを作成。
ここでもう、普段あまり開発環境を触っていない身としては、なかなかの緊張感があります。
ターミナルが出てくる。Gitの設定が出てくる。.env.localとか、tsconfigとか、見慣れないファイルが増えていく。
…これは本当に自分が進めて大丈夫なやつなのか？（不安）
ただ、Codexはそこを一つずつ説明してくれます。
「今このファイルを確認します」「ここにAPIを作ります」「この設定はデプロイ時に必要です」「このエラーは依存関係が原因です」という感じで、作業のたびに現在地を教えてくれる。
普通のチャットAIにコードを貼って相談するのとは違い、Codexは同じプロジェクトフォルダの中で一緒に作業している感覚があります。README、仕様書、既存コード、設定ファイルを読みに行き、必要な修正を提案し、実際にファイルを変えてくれる。
「あ、これは回答するAIというより、作業するAIなんだ」とあらためて強く感じました。
壁打ちしながら、仕様書ができていく
最初の要望はかなり大雑把でした。人間同士の制作でもそうですが、はじめのアイデアはだいたいが「ふんわり」しているものです。
Codexと壁打ちしてよかったのは、このふわっとした要望が少しずつ仕様に変わっていったことです。最終的に、仕様書はMarkdownで残しました。
今回決めた主な方針は、こんな感じです。
- サービス本体はCORESERVERに置く
- 占星術データはProkerala APIから取得する
- 解説文の日本語生成にはOpenAIのLLMを使う
- 出生地データは市区町村レベルで持つ
- データベースには外部PostgreSQLが必要なのでNeonを使う
- APIのデプロイにはRenderを使う
- デザインの方向性はDESIGN.mdを読ませて反映する
- PDF生成はProkeralaのPDF APIに頼らず、最終的には自前で実装する
ざっくり言えば、ユーザーが触る画面はCORESERVER、裏側のAPIはRender、データベースはNeonに置き、そこからProkeralaとOpenAIのAPIを呼び出す構成です。
PDFダウンロードまで最初からすべて実装すると、開発範囲がかなり大きくなります。そこで、必要最低限の機能を備えた試作版、いわゆるMVPでは、まずブラウザの印刷機能で保存できるレポート画面を作ることにしました。
こういう線引きをCodexと相談しながら決めていけるのが、かなり助かりました。
「占いAI」ではなく、役割分担を作る
ホロスコープサービスと聞くとAIが占い結果を全部書くようにも思えますが、そこは最初に分けました。
天体位置、ハウス、アスペクトなどの計算はProkeralaに任せる。自前で天文暦やハウス計算を実装しない。一方で、ユーザーが見る画面、日本語の説明文、表の見せ方、注意書き、印刷レイアウトは自前で作る。
日本語解説も、「いい感じに占って」とAIに丸投げするわけではありません。Prokeralaから取得した構造化データをもとに、章ごとに文章を生成する設計にしました。
さらに、医療、法律、投資、重大な人生判断の助言はしない。不安を煽らない。断定しすぎない。出生時刻不明の場合は、ハウスやASC、MC、月、アスペクトの解釈を参考値として扱う。
AIに自由に書かせるほど便利そうに見えますが、サービスに入れるなら、自由すぎるのはかえって収拾がつかなくなりますし、運用的にも危険です。
Codexを使う前は、AIコーディングはもっと「コードを書いてもらう」話だと思っていました。でも実際には、こうした役割分担や注意事項を仕様に落とす作業こそが最も重要であると感じました。
地味に難しかった出生地検索とデータベース
作っていて現実に引き戻されたのが、出生地入力です。例えばユーザーが「東京都渋谷区」と入力したとして、それをそのまま外部APIに渡していいのか。
表記ゆれはどうする？緯度経度はどこで確定する？
そこで、MVPでは日本国内の市区町村に限定するとともに、市区町村マスタから候補を検索して、選択された候補の緯度経度を使う設計にしました。つまり、ただのテキストボックスではなく、検索して選ぶ形です。
さらに、生成したレポートや市区町村データを扱うには外部データベースも必要になりますが、ここで出てきたのがNeonです。
今回の構成ではCORESERVER内のデータベースをそのまま利用できず、「外部PostgreSQLが必要です」と言われたときは、正直また一段ハードルが上がった感じがしました。
それでも、Codexがテーブル設計や接続設定、環境変数、外部サービスが使えない場合の代替処理について説明してくれるので、分からないなりに進められます。
分からないことが出るたびに聞く。Codexが説明する。それを見ながら、また次に進む。この繰り返しでした。
ターミナル、めちゃめちゃ使う
今回いちばん「開発してる感」があったのは、ターミナルです。
インストール、ビルド、起動、Git、データベース確認、デプロイ確認。何かするたびにターミナルが出てきます。
正直、開発ど素人からすると、黒い画面に謎の文字列が流れるだけで身構えます。
でもCodexは、必要なコマンドを実行し、結果を読んで、次に何をするか説明してくれます。なので、エラーが出ても「詰んだ…」とはなりません。
むしろそこからがCodexの出番で、ログを読んで原因を探し、設定ファイルや依存関係を直していきます。
ラベル位置、要約文の切れ方、星座アイコン、Renderのビルド設定、APIキー未設定時の代替表示など、細かい修正を現在のファイル構成を見ながら進めてくれるのはかなり助かりました。
ただし便利なぶん、Codexの利用枠はゴリゴリ削られていきます！！
壁打ちして、調べて、実装して、確認して、また直す。このサイクルが速いぶん、複雑な作業や長いセッションでは利用枠の消費も大きくなります。
「便利だけれど、何でも投げ続けると恐ろしい勢いで減る」という学びがありました。（クレジットを買い足しました…。）
DESIGN.mdを読ませると、見た目の話もできる
コードだけでなく、デザイン面でもCodexを使いました。今回はDESIGN.mdを読ませて、画面の雰囲気を合わせています。
紙に近いアイボリーの背景色、明朝体寄りの本文、角丸を抑えたフォームや表、線と余白で見せるレポート風の画面。
このあたりは、前回まで書いていた「文字」や「組版」の話ともつながります。AIにコードを書いてもらっても、最後に見るのは人間です。画面の見やすさや文章の可読性は、AIが書いたかどうかに関係なく人間が判断するものです。
フォームが出て、出生地を検索できて、チャートと表が表示される。仕様書やコードで見ていたものが、急に「触れるもの」になった瞬間は、かなりテンションが上がりました。
まとめ：初めてでも、少し難しいくらいのMVPが面白いし学びも多い
Codexは、答えてくれるAIというより作業するAI。ファイルを読み、変更し、動かし、失敗したら原因を探し、最後に何を変更したか説明する。この流れは、通常の制作現場の作業にかなり近いものです。
AIコーディングという言葉だけを聞くと、「人間の代わりにコードを書くもの」という印象があります。でも、実際に使ってみると、少し違いました。
Codexは、人間の曖昧な考えを、動くものへ近づける道具です。そして、その過程で「まだ決めていなかったこと」を見つける道具でもあります。
もちろん、動いたからといって、そのまま公開できるわけではありません。何を作るのか。何を今は作らないのか。外部サービスに何を任せるのか。入力されたデータをどう扱うのか。どの状態なら公開してよいのか。最後に判断するのは、やはり人間です。
Webアプリ開発初心者が少し背伸びしたお題で試すには、かなり面白く、学びの多い体験でした。