①:ローカルPCでのチェスシステムを改良しGithubにリポジトリ登録、そしてVPSと連携。
②:pm2での常駐化も完了し、ポートも開放し、ブラウザで観戦画面が表示された。
ここまでは、前回の記事で書いた通り、一通りは間違いなく達成できました。
前回の記事

しかし、確信を持ってブラウザとログを見比べた瞬間、違和感を覚えました。
「なんかおかしい……」という感覚の正体は、このログの中にありました。

症状:一瞬で対局が終わり続ける
ログを流し見してすぐに気づいたのは、明らかに同じ内容のログが延々と続いていることでした。
ブラウザ側でも、1手指されたと思った次の瞬間には、盤面がリセットされて次の対局が始まっている——これが際限なく繰り返されていました。
Tomoyaサーバーは動いている。でも、何かが明らかにおかしい。
この状態を放置するわけにはいかないので、Cursorを使って原因を調査していくことにしました。
違和感に気づく:d2d4もc2c4も、本来は合法な手のはず
最初に疑ったのは、準備段階で用意していた「オープニングテンプレートをランダムに選ばせることで、対局ごとに展開を変える」という仕組みの部分でした。
ただ、そのオープニングの手を実際に見返してみても、パッと見た限りでは、ポーンを2マス進めるだけの、ごく普通の合法な手にしか見えません。
「コードを目で追っただけでは気づけない不具合がある」ということ自体が、今回の1つの気づきであり、学びでした。
Cursorエージェントへの調査依頼
ここで、Cursorのエージェントに調査を依頼することにしました。
ブラウザで見えている現象・症状と、実際のエラーログをそのままプロンプトに入力し、原因の調査と修正をお願いします。

Tomoya使用したモデルは、Cursor独自のモデルであるComposer 2.5です。
これ以降、コーディングの依頼やデバッグは基本的にこのモデルにお願いしていくつもりです。
ここで大事だと感じたのは、依頼の仕方です。
ただ「エラーやバグを調査して直してください」とだけ伝えても、AIの性能が高ければ直してくれることはあります。ですが実際には、AI側も「何を直せばいいのか」を手探りで探すところから始めることになり、遠回りになりがちです。
非エンジニアの自分には、「このファイルの、このコードを修正してください」と具体的にピンポイントで指示するだけのスキルはありません。それは現実的ではないと割り切っています。
ただし、自分の目で見たもの・実際に起きた現象を、ありのまま伝えることならできます。
「ブラウザで1手指した直後に、すぐ引き分け判定になって次の対局が始まってしまう」「ログにはこう表示されている」
こうした具体的な状況をそのまま伝えるだけで、AIはその内容を汲み取り、関係しそうなファイルを絞り込みながら調査を進めてくれます。
結果として、ピンポイントで原因にたどり着きやすくなるのだと実感しました。
今のAIモデルは非常に優秀なので、こちらの言葉遣いや言語がきれいに整っている必要はほとんどありません。多少つたない日本語で状況を伝えても、意図を汲み取って理解してくれることがほとんどです。
「なんかおかしいな」と思ったら、変に整理しすぎず、見たまま・感じたままをAIエージェントに伝えてみることを、非エンジニアの一人としておすすめしたいです。
以下のリンクから始めると、初回1か月分が割引価格でCursorを利用できます。1か月使ってみて合わなければ、すぐに解約できる気軽さも魅力だと感じています。
原因判明:黒番なのに、白番の手を指そうとしていた
TomoyaComposer 2.5からの報告で、原因が判明しました!!
defense_openings(守り側=黒番用に用意していたオープニングのリスト)に、本来は白番用の手がそのまま入ってしまっていた、というデータの誤りでした。
具体的には、こういう流れで問題が起きていました。
- 白番の対局開始時、
attack_openings(攻撃側用のリスト)から手が選ばれる → これは白番の手なので、正常に指せる - 続く黒番のタイミングで、
defense_openingsから手が選ばれる → しかしその中身は、c2c4やd2d4のような白の駒を動かす手だった d2d4という指し手は「d2にある駒を、d4に動かす」という意味です。- ところが対局開始時点で、d2にいるのは白のポーンです。
- 黒番の手として、この指し方を適用しようとすると、盤面上に矛盾が生じ、合法手として認められません
- 結果、「非法手をスキップ」という判定になり、1手も進まないまま対局が終了、「引き分け」として処理される
- これが対局のたびに繰り返され、延々とループしていた
つまり、盤面の判定ロジック自体は正しく機能していました。悪かったのは、自分たちが用意した【データ】の方だったのです。

プログラムが間違えたのではなく、人間が渡した情報が間違っていた——AIを使った開発では意外とよくあるパターンなのだと知り、これも大きな学びになりました。
Tomoya変更後は、これらが削除され、主に黒番の防御・応答の動きへ置き換えてローカルで確認しました。
なぜ気づけなかったのか・反省点
今振り返ると、機能を追加した時点で「白は必ず先手、黒は必ず後手」という前提を、自分の中で明確に固定しきれていなかったのが問題だったと思います。
もしくは、「白が先手の場合はこのテンプレート」「黒が先手の場合はこちらのテンプレート」というように、先手・後手それぞれに対応したオープニングのリストを、最初から用意しておくべきでした。
バグが起きないよう、事前にもっと踏み込んで設計を詰めておけば、今回のような事態は防げたはずです。とはいえ、実際に動かして、目で見てみないと気づけないことばかりなのも事実です。おかしいと感じた瞬間にすぐ違和感をキャッチし、迷わず調査に進めたことは、今回の中でも一つの成果だったと思っています。

修正して動作確認
修正内容はシンプルで、defense_openingsの中身を、黒の駒が実際に動かせる合法な手(e7e5やd7d5など)に差し替えるというものでした。ローカルのPC環境で修正を確認したところ、今度はきちんと対局がスタートし、進んでいくことを確認できました。
あとはこれをGitHubに上げて、VPS側でgit pullし、差分を反映させれば、晴れてVPS上で24時間動くチェスBotの完成——のはずでした。。。

まとめ・次回予告
修正したファイルをGitHubに上げ、VPS側にアップデートを反映させる作業自体は、スムーズに進みました。ところが、いざブラウザを開いてみると
今度はページそのものが表示されません。npm run buildが、なぜか失敗している……。
1つのバグを解決した安堵も束の間、まったく別の問題が静かに紛れ込んでいたことに、この時点ではまだ気づいていませんでした。次回は、このもう1つのトラブルシューティングについて書いていきます。
「白のオープニング手順」を登録していた状態から、「黒が採用する防御・応答の手順」を登録する状態へ変えた修正。

Cursorを使ってバイブコーディングを試してみて
以下のリンクから始めると、初回1か月分が割引価格でCursorを利用できます。1か月使ってみて合わなければ、すぐに解約できる気軽さも魅力だと感じています。

他のVPSは「さくらインターネットから!」

前回の記事はこちらから



VPSを使った24時間稼働システムを作成した記事はこちら



コメント
コメント一覧 (1件)
[…] 【非エンジニアが挑む】「非法手をスキップ」の無限ループ|正しい指し… […]