ボートレースAI開発日記⑰|AWSへの移行準備が前進!それでも本番へ移さない理由

ボートレースAI開発日記17、AWSへの移行準備。S3からEC2へのファイル転送とボートレースのイメージ ボートレースAI開発

ボートレースAIの開発を続けています。

前回は、AIが予想した記録は増えているものの、レース結果の確認やブログへの自動連携には、まだ課題が残っていることを紹介しました。

今回は、AIの予想そのものではなく、AIを動かす環境について、新しい進展がありました。

これまでMacを中心に進めてきた開発を、クラウド上でも行えるようにするための準備です。

10月29日には、AWSというクラウドサービスを使った検証で、一つの工程に成功しました。

ただし、まだAIがAWS上で自動予想を始めたわけではありません。

なぜクラウドへ移そうとしているのか、今回どこまでできたのか、そしてなぜ本番移行を急がないのか。今回は、その途中経過を紹介します。

前回の記事:ボートレースAI開発日記⑯

AIの開発環境を見直すことにしました

ボートレースAIは、レース情報を収集し、予想を作り、購入するか見送るかを判断する仕組みです。

開発を始めたころは、一つずつ機能を作り、実際に動くかを確かめることが中心でした。

その後、自動実行や予想結果の記録、レース後の評価、ブログとの連携など、少しずつできることが増えてきました。

しかし、開発が進むほど管理するものも増えていきます。プログラム、データベース、バックアップ、検証用ファイルなどです。

さらに、新しい機能を試すときには、現在の運用環境を間違って変更してしまわないようにする必要があります。

そこで進めているのが、AWSへの移行準備です。

AWSを使えば、クラウド上にLinuxサーバーを用意し、Macとは別の環境で開発や検証を進められるようになります。

もちろん、クラウドに移せばすべて解決するわけではありません。新しいサーバーでも、これまでのAIが正しく動くことを確認しなければなりません。

そのため、まずは現在の正式な環境と切り離した場所で、検証を始めています。

10月29日、AWSへのファイル受け渡しに成功

今回、進展があったのは、AWSのサーバーへ必要なファイルを受け渡す工程です。

AWSには、ファイルを保管する「S3」と、仮想サーバーを動かす「EC2」というサービスがあります。

今回の検証では、S3に用意したファイルを、EC2内の隔離された保管場所へ受け渡しました。そして、転送したファイルに問題がないかを確認しました。

ファイルの照合には、SHA-256という仕組みを使っています。簡単にいえば、転送前後のファイルが同じ内容かどうかを確認する方法です。

今回の検証では、対象ファイルがすべて一致し、予定にないファイルもありませんでした。

単にファイルをコピーするだけなら、難しい作業には見えないかもしれません。

しかし、AIの開発では、データやプログラムが知らないうちに変わってしまうと、正しい検証ができなくなります。

そのため、「転送できた」だけではなく、「正しく転送できた」と確認できたことが、今回の成果です。

確認した内容 結果
ファイル受領 20ファイル成功
照合対象ファイル 19件すべて一致
想定外のファイル 0件
ファイルの整合性 PASS
検証工程「G3-6」 PASS

成功したのに、まだ本番へ移せません

ここで気になるのが、「ファイルを受け渡せたなら、もうAWSで動かせるのでは?」ということです。

実際には、まだそこまでは進んでいません。

今回成功したのは、あくまでファイルの受領と内容の確認です。

AWS上でAIの予想を実行できるかどうかは、別の検証が必要です。

毎日のレース情報を正しく取得できるのか。決められた時間に予想処理が動くのか。判断や結果を安全に保存できるのか。途中で失敗した場合に、データを壊さず停止できるのか。

こうした確認を省略することはできません。

これまでの開発でも、実行タイミングのずれや公式データの公開遅延など、実際に動かしてみて初めて分かった問題がありました。

クラウドへ移す場合も同じです。

今回の成功は本番移行の完了ではなく、その準備の一段階です。

焦って切り替えるより、問題が起きたときに原因を追える状態で進めたいと考えています。

ファイルを調べてみると、別の課題も見つかりました

AWS移行の準備では、現在のMacにあるファイルの調査も進めています。

10月25日の調査では、移行対象として確認したデータが合計約22.69GiBありました。

そのうち、AIの実行環境に関連する領域が約20.62GiB。さらに、その大部分をバックアップが占めていました。

バックアップは大切ですが、過去のバックアップをすべて新しいサーバーへ持っていけばよいわけではありません。

また、プログラムが自動的に作り直せるファイルもあります。一方で、絶対に失ってはいけない正式データや、開発時の元ファイルもあります。

これらを区別せずに移してしまうと、どれが正しいファイルなのか分からなくなる可能性があります。

さらに、管理対象に入っていないファイルや、引き継ぎに必要な文書にも、確認が残っています。

ブログ側のデータも含めて、何を正式な保存対象とするのか整理が必要です。

現在は、こうした問題を残したまま、強引に移行することは避けています。

AIの予想成績はどうなった?

ここで、前回の予想運用についても触れておきます。

10月17日時点では、正式な予想・判断の記録が29件、そのうち結果確認済みが22件、確認待ちが7件でした。

しかし、10月30日時点の最新の稼働状況や正式KPIは、今回の開発報告では確認できていません。

したがって、前回の記事の数字を現在の成績として扱うことはできません。

また、10月12日・18日・19日の下関12Rについては、3件の公式結果確認と保存承認をまとめた既存の証跡が見つかっていないという報告もあります。

ただし、それぞれのレースで公式結果を確認したか、保存が承認されたか、データベースへ保存されたかは、個別に確認する必要があります。

確認できていない内容を、完了したことにするわけにはいきません。

今回のAWS検証が成功したことと、AIの予想成績が改善したことは、まったく別の話です。

失敗や保留も、そのまま記録していきます

AIの開発をしていると、思いどおりに進まないこともあります。

これまでも、検証で問題が見つかり、次の工程へ進めずに止めたことがありました。

開発記録では、こうした状態を「HOLD(保留)」や「NO-GO(進行不可)」として残しています。

うまくいかなかった作業も、なぜ止めたのかが分かれば、次の改善につながります。

逆に、成功したことだけを記録していると、後から同じ問題にぶつかるかもしれません。

今回のAWS移行準備でも、確認が終わっていないものは、そのまま未確認として扱っています。

時間がかかっても、正しく動く仕組みを作るためには必要な工程だと考えています。

次はAWS上でAIを動かすための準備

今回、AWSへのファイル受け渡しは一つの検証工程をクリアしました。

しかし、本番への移行には、まだ複数の課題が残っています。

まずは必要なプログラムやデータを整理し、移行対象を明確にすること。

そして、現在の正式な環境へ影響を与えずに、Linux上で安全に検証できるようにすることです。

並行して、未確認の予想結果やブログ連携の問題も整理していきます。

AIの予想精度を高めることはもちろん大切です。

でも、毎日安定して動き、正しい記録を残せる仕組みがなければ、長く検証を続けることはできません。

今回のAWS検証成功は、そのための小さな一歩です。

次回も、実際に進んだ作業と、そこで見つかった問題を紹介していきます。

※この記事は、2026年10月25日・29日の開発検証記録と、10月30日付の開発報告をもとにしています。記載した過去の正式Forward件数は当時の確認値であり、10月30日時点の最新KPIではありません。

コメント

タイトルとURLをコピーしました