全てを捨てる決断

本日は 2026年11月2日。バイブコーディング時代の書き始めの日である。

前回の丸亀ボート観戦の続きで、オープニングは高松で食べたうどんの話をしようと考えていたのだが、うどんは写真のみにしておく。実は今朝、僕はサイトのバグFIXを久々に行ったのである。午前7時、レース情報のスクレイピングで本家から403が返り、156レース中123レースの情報が取得できず、多くの場で予想が表示されない問題が発生した。

これまでにも天候などの直前情報、オッズ情報の取得で同じ403が発生したことがあるが、僕は都度リトライコードを組み込むなどの対応を行ってきた。しかし、これまでレース情報取得には問題がなかったため、リトライコードの組み込みを見落としていたのだ。

ただ一言、

「すべてのスクレイピング関連コードには、データ取得に問題が発生した場合のリトライ処理を組み込むこと。」

と言えていれば、今朝の問題は発生しなかっただろう。

どのコーディングAIを使うにしても事前にこのようなルールを決めて教えておくことで、朝の貴重な時間を無駄にすることがなくなる。

ただ、正直に話すと、僕は都度問題が発生したときに問題を分析し修正するほうが性に合っている。無駄なコードが少なくなるし、システムにも愛着が湧く。時間を費やして起こりうる事を想像し、可能なかぎり予見して、準備して作業を進めるやり方もあるだろう（そのように開発しなければならないシステムはもちろんある）。だが、そもそも抜け漏れは絶対ある。

問題をすぐにリカバリできる開発環境を作ること。そして、やりたいことがすぐに実現できること。それが優先だ。さて、システム再構築の話に入る。

---

2025年の年末

本業も再就職して1年が過ぎ、僕は落ち着いてダイアナボートの現状を分析できるようになる。Episode.8でも書いたが、作り直しを決断した要因は大きく2つある。

• 手動でのコード更新・管理が煩雑になり、改善・研究活動に手間がかかりすぎる
• 運用コストがかかりすぎ（月 $170〜180 前後）、リターンもないのに！

本業でもAIコーディングの活用が進み、プロトタイプの作成にも慣れてきた。当時よく使っていた Claude Code をそのまま採用し、正月休みに予想サイト再構築の計画を実行したのだ。

計画

再構築の計画にあたり僕が先に決めたことは多くはない。

• クラウド環境は AWS のまま: 蓄積したデータが移行しやすいだろうから
• GitHub 上でコードも設定もすべて管理する: 旧システムでは AWS Step Functions、EventBridge などの定義が変更管理されていなかった
• Spec Kit※1 を使う: 言葉ですべてをAIに指示する上で、非機能要求の漏れが少なくなりそうだ
• 学習モデルはコスト優先で選択する: ジャケ買いはしない。精度が同じなら PyTorch 系にこだわる必要はない
• Claude Code でのメンテナンスを前提: 手動では各AWSコンポーネントの設定は行わない。デプロイを含め手動設定を皆無にする

旧 Lambda・テーブルは捨て、スクレイピングは書き直し、約51万件のデータは再利用する。

とにかく重要なのは、モデルの改善作業、つまり新しい予想のアイデアをすぐに取り入れることができること。そしてコスト削減である。

正月休みの主なタスク

移行が終わった 1月10日までの16日間で99コミット。コミットがあったのはそのうち9日で、12月30日から1月4日までの正月の6日間は一度もコミットしておらず、僕ものんびりと過ごしていたのだろう。

Spec Kit

Spec Kit とは、GitHub がオープンソースで公開している仕様駆動開発（Spec-Driven Development）のためのツールキットである。コーディングAIにいきなりコードを書かせるのではなく、まず「何を・なぜ作るか」を仕様書に書く。そこから設計、タスクの分解と段階を踏んで実装に入る、という作法を AI に仕込む道具だ。

面白いのは、段階ごとに AI のほうから足りない情報を補う質問が返ってくることである。「過去データの保持期間は？」「予測結果の表示形式は？」と聞かれ、答えるたびに仕様書・設計書・タスク表が Markdown で積み上がっていく。仕様書のひな形には成功基準や想定外のケースを書く欄もある。

言われたことしかやらない AI と、言い忘れる僕。その隙間を埋めてくれるツールと言えるだろう。

2026年11月時点

ただ、この1年で状況はずいぶん変わっている。Claude Code には「プランモード」※2があり、コードに触る前に AI が調べて計画を立て、人が承認してから実装に入る。

GitHub Copilot にも 2026年1月にプランモード※3が入り、Cursor※4 や OpenAI の Codex※5 にも同じような機能がある。AWS の Kiro※6 に至っては、要件・設計・タスクを書く流れそのものが開発環境に組み込まれている。

つまり Spec Kit が仕込んでいた「書いてから作る」作法は、もはやコーディングAIの標準装備になりつつある。実際、サイトの再構築後は、新しい機能やアイデアの追加には主にプランモードを利用している。

最初の仕様

ダイアナボートのような予想サイトやアプリなどを AI を使って構築してみたいという方にとっては、最初に僕が何を Claude Code に（Spec Kit のコマンドを通じて）伝えたのかを知りたいと思うだろう。初回の原文が記録されていたのでそのまま記載しておく。

2025-12-27 16:51 /speckit.specify に貼り付けた原文

・ボートレース学習データ収集機能
- https://www.boatrace.jp/ から、当日のレース開催情報（全24場のうち開催予定のレース）を早朝に取得
- 当日の各レース結果をレース後随時取得
- 取得した各レース結果データをデータベース（AWS DynamoDB）に格納
- 格納データ：各レースの出走表、オッズ、直前情報、レース結果

・ボートレース結果予想MLモデルの学習機能
- 格納された AWS DynamoDB テーブルの過去レース結果情報を Feature Engineering して表データとして AWS S3 に格納
- 複数の表データ分類モデルを構築し比較が行える構成とするが、最初は以下の1モデルを利用
- STEP-1
    - S3 上のFEデータを利用して、CatBoost（class_weights） モデル + macro-F1 指標で学習
    - 30クラス分類（ボートレース６枠の2連単）を行い、さらに 6 クラス分類（3着目を予想）して3連単を予想する
- STEP-2 （後日）
    - レーサー毎の調子の上向き下向きを予想して、CatBoost への入力データとする
    - レーサーの開催試合内でのレース状況（通常レースは開催試合毎に数日にわたり実施され、その総合得点で優勝を争う）、例えばすでに最終レースに進むことが決まったレーサーは無理はしない？など様々な実験をしたい。
- 学習の頻度は毎日夜間バッチで行う

・ボートレース結果予想機能
- 学習したモデルを利用して、当日開催の各レースの予想を DynamoDB に出力する
- フロントエンドで DynamoDB 上の予想結果を表示
- フロントエンドでは随時レース結果が確認できる
- フロントエンドでは過去の的中率などが確認できる
- フロントエンドのデザインは、既存サイトのUIデザインを再利用する

・その他の一時的な機能
- 過去のレース結果データを保持した旧DynamoDBテーブルからの新DynamoDBテーブルへのデータ移行

・利用できるリソース
- データをクローリングする Lambda 関数のサンプルコードが存在
- 過去データを保持している DynamoDB Table
- 既存サイトで利用しているフロントエンド実装

上記 specify コマンドでは主にシステムで実現したい機能を説明している。このコマンドがメインパートではあるが、再構築初日と2日目あたりに僕が何を行っていたかも細かく紹介しておこう。

Claude Code とのやりとりの記録

12月26日（金）: 相談と準備、そして constitution

12月27日（土）: specify から implement まで一晩で

これだけで、一旦は画面までは実装できていたようだ（もちろん、いろいろな微調整は続く）。フロントエンドに関していえば、完全なスクラッチではなく既存のコードを流用している部分があると考えられる。

履歴からみえる状況

会話の履歴を辿ってみると、12月26日に再構築を始める前に、僕はある程度のリサーチを行っていたことがうかがえる。例えば以下のポイントである。

• 初期学習モデルを CatBoost※7 と指定している
• クラスの重み付けを利用する意思があった（手組み時代に付けないほうが良いとわかっていたのに謎である。今も使っていない。）
• なぜか、macro-F1 指標を指定している（今は多クラスの AUC / log loss）

残念ながら、これらの詳細な記録は残っていなかった。おそらくローカルマシンでの実験やコストを重視した調査から導いたものだと考えられる。

まとめ

本エピソードでは、コーディングAIを利用したバックエンド・フロントエンドを含めたサイト全体の再構築のさわり、最初の2日間について詳細に履歴を辿ってみた。次回以降のエピソードでは残りの初期再構築タスク、既存データの移行と AWS DynamoDB テーブルの再設計について見ていきたい。

つづく。