🤖 AIと1週間でWebポータルを作った記録 — Day 2: パチンコ期待値計算ツールの実装

はじめに — Day 2で「売り物」を作る

Day 1でプロジェクトの骨格ができた。Day 2はこのポータルの存在意義そのものを作る日です。

Gravity Portalの核はパチンコ期待値計算ツール。機種のスペック（大当り確率、ラッシュ継続率、出玉数など）から、任意の回転率・交換率で1回あたりの期待値を算出するツールです。

普段パチンコ店で「この台、打つべきか？」を判断するために使うもので、これがないとGravity Portalは「ただのブログサイト」で終わってしまいます。

---

🎰 計算エンジンの設計 — AIに「期待値の計算式」を教えた

まず自分が持っていたもの

もともとGoogleスプレッドシートで独自の期待値計算シートを運用していました。機種ごとの複数のスペック要素を組み合わせ、任意の条件下での期待値を算出する仕組みです。このスプレッドシートの計算ロジックをAntigravityに「TypeScriptで計算エンジンとして実装して」と依頼しました。

AIとの共同設計

最初、AIは「一般的な期待値計算」を提案してきましたが、パチンコ特有の要素（遊タイム、時短中の引き戻し確率、持玉比率による単価差）が考慮されていませんでした。

ここで重要だったのは「自分のドメイン知識をAIに正確に伝える」こと。スプレッドシートの計算式を1つずつ見せながら、AIにTypeScriptで再実装させました。具体的な計算ロジックは有料ツールの核心部分なので公開できませんが、単純な「大当り確率 × 出玉」ではなく、大当り確率・出玉・継続率・遊タイム・交換率・持玉比率といった複数の変数を組み合わせた実戦向けの計算エンジンを構築しています。

教訓: AIは汎用的な計算はできるが、ドメイン固有の知識は人間が持っている。AIに「何を計算すべきか」を正確に伝えないと、見た目は動くが結果が間違っているコードが生成される。

---

📊 1000機種のスペックデータ — スクレイピングv2

データの課題

計算エンジンができても、肝心の機種データがなければ使い物にならない。当初はGoogleスプレッドシートから手動でCSVを読み込んでいましたが、1000機種以上のデータを手動管理するのは限界がありました。

スクレイパーの自動化

Antigravityに「パチンコ機種のスペックデータを自動取得するスクレイパーを作って」と依頼。結果、collect-machines.mjsというスクリプトが完成しました:

• P-WORLD等の公開データから機種スペックを自動取得
• 1064機種のデータをmachines.jsonに格納
• エイリアス検索（1012パターン）で「正式名称がわからなくても見つかる」
• GitHub Actionsで隔週日曜に自動実行

データの肥大化問題

1064機種のJSONファイルは約13MBにまで膨れ上がりました。これがデプロイサイズを圧迫し、後にCloudflare Pagesのファイルサイズ制限（3MiB）に引っかかる原因となります（Day 1参照）。

最終的にはGitHub Pagesに分離し、Vercelのrewrite機能でプロキシする構成に落ち着きました。

---

⚡ Proの限界、Ultraへの移行 — すべての煩わしさからの解放

スクレイピングv2の開発中、ある壁にぶつかりました。Antigravity Proプランのトークン上限です。

スクレイパーは1000以上の機種ページを巡回し、複雑なHTML構造からデータを抽出する必要があります。エッジケースの処理、エラーハンドリング、データの正規化——やり取りが深くなるほど、AIとの会話は長大になっていきました。

そしてまさに佳境というタイミングで、「トークン上限に到達しました」の通知。会話がリセットされ、それまでの文脈がすべて失われる。また最初から説明し直し。この「もどかしさ」は、AIと二人三脚で開発している時に最もストレスを感じる瞬間です。

「もう我慢できない」——そう思った私は、Antigravity Ultraプランに即座に移行しました。

Ultraの効果は劇的でした:

• トークン上限が事実上なくなった — 何時間でも途切れずに開発セッションを続けられる
• コンテキストの深さが段違い — プロジェクト全体の構造を把握した上で、的確な提案をしてくれる
• 複雑なリファクタリングも一発 — 「このファイルとこのファイルの依存関係を整理して」と言うだけで完了

Pro→Ultraの移行は、「制限の中で工夫する開発」から「制限を意識しない開発」への進化でした。日常でちょっとしたストレスだった「トークン残量を気にしながらの会話」がなくなっただけで、開発のリズムが劇的に変わりました。

教訓: 開発ツールへのケチりは最大のコスト増。Proで十分だと思っていたのは、Ultraを使ったことがなかったから。一度体験すると、もう戻れません。

---

🖥️ UIの進化 — iframeからReactへ

Phase 1: iframe統合

最初は既存の静的HTML/JavaScript版の計算ツールをiframeで埋め込む方式を採用しました。理由は単純で「既に動いているものを最速で統合したかった」から。

しかし、iframe方式には問題がありました:

• レスポンシブ対応が困難（スマホでの表示崩れ）
• 認証情報の受け渡しが面倒
• SEO的にiframe内のコンテンツは評価されない

Phase 3: サーバーサイドAPI + Reactコンポーネント化

最終的にAntigravityと一緒にフルReactコンポーネント化を実施:

• 計算ロジックを/api/calculateのサーバーサイドAPIに移行
• UIをReactコンポーネントとして再実装
• Clerk認証 + Stripe決済チェックをAPIレベルで統合
• 計算結果のコピー＆シェア機能を追加

この移行はDay 2だけでは終わらず、Day 3〜4にかけて段階的に進めましたが、最終的な姿はDay 2の設計で決まっていました。

---

🔍 機種検索UI — 「あいまい検索」の実装

1000以上の機種からユーザーが目的の台を見つけるために、あいまい検索（fuzzy search）を実装しました。

トークン分割検索

例えば「大工 源さん」で検索すると、「大工の源さん超韋駄天」がヒットする。入力文字列をスペースでトークン分割し、全トークンが機種名に含まれていればマッチとする方式です。

エイリアス対応

パチンコ機種は正式名称が長く、ユーザーが略称で検索することが多い:

• 「エヴァ」→ 「CRヱヴァンゲリヲン〜始まりの福音〜」
• 「まどマギ」→ 「SLOT劇場版魔法少女まどか☆マギカ」

スクレイパーで取得した機種名から自動的にエイリアスを生成し、検索対象に含めることで、1012パターンのエイリアスで直感的な検索を実現しました。

---

📊 Day 2のまとめ

---

💡 Day 2の学び

1. 「売り物」を最初に作ることの重要性

認証やデザインは後からでも変えられますが、プロダクトの核となる機能が弱ければ何も始まらない。Day 2で計算エンジンを最優先で実装した判断は正解でした。

2. AIに「ドメイン知識」を伝える技術

パチンコの期待値計算は一般的なプログラミング知識だけでは実装できません。スプレッドシートの計算式を1つずつ見せ、「この値はこういう意味で、こう計算する」と丁寧に伝えることで、AIは正確なコードを生成してくれました。AIは実装の天才だが、ドメインの専門家ではない。

3. データの肥大化は早めに対処

13MBのJSONファイルがデプロイを妨げる事態に。データとコードの分離（GitHub Pages + Vercel rewrite）は最初から設計に入れておくべきでした。

---

📌 シリーズ予定

• Day 1: 構想とNext.jsセットアップ
• Day 2: パチンコ期待値計算ツールの実装 ← 今ここ
• Day 3: ブログ機能と収益化（Stripe + 広告）
• Day 4: AIの記憶の限界 — コンテキストウィンドウとの戦い
• Day 5: AIが暴走した日 — ルール違反と信頼の再構築

次回 Day 3 では、Stripe決済の導入と広告設置。「¥580/月」の値段設定に至るまでの思考過程も公開します。お楽しみに！