【非エンジニアが挑む】観戦システムを「見られるレベル」まで整備した話

【非エンジニアが挑む】観戦システム整備のビフォーアフターを示すサムネイル

前回の記事はこちらから

Tomoya

ついに、観戦画面が安定して表示されるようになりました!!

しかし、ここで完成というわけではありません。

表示されているだけで満足してしまうシステムでは、誰にも使ってもらえません。

改めて自分の作った画面を眺めてみると、明らかに違和感のある状態になっていることに気づきました。

今回は、これをCursorのAIエージェントを使って修正し、きちんと「見られる」システムに整えていく実践を記事にします。※Cursorメインの内容になっています。

目次

自分なりの仮説を立てる

Tomoya

まず大事にしたのは、見たままを素直に感じることです。

何が自分にとって違和感なのかを観察し、そこから仮説を立てていきます。それをCursorのComposer 2.5に入力し、自分の考えが合っているかを評価してもらう

Tomoya

いわば、上司に相談するようなイメージで進めました。

自分の意見をそのまま投げて、コードの中身と照らし合わせながら調査してもらい、返ってきた仮説をもとにさらに検証・修正していく、という流れです。

実際に感じていたのは

「更新頻度とStockfishの手数が合っていないのでは」

「常に最新の盤面に更新するだけで、1手ごとの表示になっていないのでは」

「エンジン側やシステム側の都合で処理が組まれていて、ユーザー目線になっていないのでは」といったことでした。

違和感というのは、感じてはいてもうまく言葉にしづらいものです。ただ、僕は基本的に「見たまま」をそのまま伝えるようにしています。そのうえで、それが論理的に説明できることなのか、もし見た内容と論理がかみ合わないのであれば、その間に何が起きているのかを推測する、という考え方で進めています。

Cursorにてチェスの動きが速すぎる原因と更新頻度やエンジンの進行速度のズレについて質問・回答しているチャット画面。
ローカル環境でチェス盤の動作不具合が発生した際、更新頻度やエンジン速度のズレが原因であるとAIエージェントが回答している画面です。

Cursor Composer2.5とは?はこちらの記事を参考にしてください



調査して見えてきたこと

調べてもらった結果、単純に「エンジンの進行と表示の更新が合っていない」というだけの話ではありませんでした。

エンジン同士の対局の終わり方にも、そして見た目の作り込みにも、それぞれ問題が潜んでいたのです。

Tomoya

複数の要因が絡み合っていたことに、正直かなり感心しました。

学びになったポイント

問題というのは、1つではなく2つ3つと複雑に重なることで、本質が見えにくくなり、解決までに余計な労力がかかるものです。

今回もまさにそれで、「エンジンと更新のズレ」だけでなく、「エンジン同士の終わり方」や「見た目の仕組み」までが同時に整っていなかったことで、全体がぐちゃっとした印象に見えてしまっていたのだと理解しました。

ここから、修正方針を3つのセクションに分けて実行していきます。

特に3つ目では、自分がユーザーとして観戦する立場だったらどういう状態が見やすいか、というUI・UXについて、あれこれ意見を出しながら調整していきました。


修正方針①:バラバラに見える動きを「1手ずつ」に整える

Cursorからは、以下の3つの改善案が提示されました。

  • 未取得の手をキューに溜めて、速度設定通り1手ずつ再生する
  • 「次局準備中」の状態では、盤面をすぐにリセットしない(次の1手が来るまで維持する)
  • ポーリング(データを取得する)間隔そのものを短くする

このうち、上位2つを優先して修正することで、飛び飛びに見える問題は解消できるとのことだったので、まずそちらから進めました。3つ目のポーリング間隔の短縮は優先度を下げ、それでもまだ物足りなさが残るようであれば実施する、という方針にしています。

この改善案の説明

エンジンと表示の更新をそのままリアルタイムに一致させようとすると、どうしてもエンジン側の速さに引っ張られてしまいます。そこで、間に「キュー(待ち行列)」を挟んで一旦溜めておくことで、表示側はエンジンの速さに引きずられず、自分のペースで1手ずつ見せられるようになる。

この「裏側の処理と、表に見せる部分を分離する」という考え方は、今後の開発全般にも活きる、良い学びになりました。

手のキュー再生や終局後リセット防止などを記載したシステム改善内容一覧
手のキュー再生やUI整理など、観戦システムの動作不具合を解消するための具体的な改善指示項目。

修正方針②:エンジンの「終わり方」を見直す

エンジン同士の対局が、思っていたより引き分けで終わりやすいことも気になっていました。

対局である以上、どちらも負けたくないのは当然ですが、観戦する側からすれば、やはり決着がついてほしいものです。まして今回は、いわば【デモの戦い】のようなものなので、なおさらです。

そこで、以前から設定していたStockfishのContemptの数値を、さらに調整してもらいました(攻撃側80・守り側0)。

これによって、面白さは確実に向上したと思います。ちょっとした隙を突いたり、相手のミスを狙って盤面が一気に動き出す——そんな体験ができれば、より理想に近づけると感じています。ただ一方で、これだけ差をつけたことで、逆に「学びの少ない、力任せなだけの手」を指すようになってしまわないか、という心配も正直あります。

Tomoya

ここは、しばらく動かしながら様子を見ていきたいところです。


修正方針③:見た目を作り込む

勝敗数の強調、チェックメイトの演出、速度切り替えの整理などを、Cursorへの指示に反映させながら、その都度ローカルで確認する、という作業を繰り返して整えていきました。

Tomoya

特に面白いと感じたのが、チェックメイトの演出です!

それまでは、いつチェックメイトになって対局が終わったのかがまったくわからないまま、次の対局に進んでしまっていました。

  • そこでまず、チェックメイトになった瞬間に画面が赤くエフェクト表示されるようにしました。
  • ただ、それでもなかなかチェックメイトそのものが発生しないので、次に「王手」がかかった時点でもエフェクトが入るように追加しています。
チェスの試合でチェック時に赤いエフェクトが発生している様子。
UI調整にて、チェスの試合でチェック時に赤いエフェクトが発生するようにした。

これによって、いつキングを狙った一手が指されたのかが可視化されるようになったのは、大きな進歩だったと思います。

Tomoya

次に、速度についても整理しました。

  • 「速い」を選べば:リアルタイムに近い形で表示され
  • 「遅い」を選べば:自分のペースで1手ずつ送られるので、見ながら自分でも考えてみることができます。

以前は「普通」という選択肢もあったのですが、中途半端だったので削除しました。

今後の課題点:
  • まだ「なぜこの手を選んだのか」までは、エンジンにしかわからない領域である事
  • スピード感が速いので見る方向性の方が強いのが時間をかけて監視していく必要があるなと感じました。
Cursorで手数制限の緩和やチェックメイト時の赤エフェクト表示、勝利数表示の拡大など改善要望が書かれたチャット入力画面のテキスト。
チェスアプリの開発において、手数制限の変更やエフェクト追加などのUI改善要望をCursor AIエージェントに入力している様子です。

実際に修正後、ローカルで動かしてみて感じたこと

Tomoya

最初の状態と比べると、圧倒的に良くなったと感じます。

中でも、裏側で動いているシステムと、表に見せる表示のシステムを分離したことは、大きな意味があったと思います。これによって、表示側をエンジンの都合にそのまま合わせる必要がなくなり、より自由度の高い【注文】ができるようになりました。

まだ、「なぜこの手を選んだのか」を掘り下げて見せる機能や、エンジン同士の対局レベルのバランス(今の設定が本当に理想的な50:50なのか)といった課題は残っています。

Tomoya

ここも、今後違和感を感じるたびに、また修正・更新していきたいと思っています。

次は、これをGitHubに上げて、VPS側でpullし、実際に24時間稼働しているチェスBotに反映していきます。

ChessBrainの初期UI(V1)におけるチェス盤面と観戦インサイト画面
初期バージョン(V1)のChessBrain観戦画面と評価値グラフの表示レイアウト。
ChessBrainのUIバージョン2(V2)における観戦画面と対局スコア表示
バージョン2(V2)に更新されたChessBrainの画面レイアウトとスコア表示機能。

VPSに反映してみる

GitHubへpushし、VPS側でpull・反映し、実際にブラウザで確認してみました。

Tomoya

結果は、無事に問題なく更新を反映できました!

ターミナルでgit pullコマンドを実行し18個のファイル変更と更新ログが表示された画面。
VPSコマンドライン上でGitのリモートリポジトリから最新コードを取得し、更新されたファイル群がログ表示された様子です。

これまでの記事のような、ローカルでは動くのにVPSでは動かない、という事態が今回は起きなかったのは、素直に嬉しかったです。

このまま稼働させたままにしておいて、気が向いた時にチェックして様子を見ていこうと思います。

今の状態を見てみると、攻撃の勝利3,283、守りの勝利3,267と、すでに6,500試合以上の対局が繰り広げられていました。

ChessBrainの盤面と右側サイドバーにある攻撃・守りの勝利数表示パネルが緑色の枠で強調された画面。
「ChessBrain」のWeb画面上で、チェス盤の横に配置された「攻撃の勝利」および「守りの勝利」の数値表示部分を強調した状態です。
Tomoya

これには正直驚きました。ローカルで動かしているだけでは、絶対に体験できない数字です!!

これこそ、VPSで24時間動かし続けることの凄みなのだと実感しました。

24時間稼働のVPSに興味を持った方は、ぜひ一度試してみてください。

何を選べばいいか、どう契約すればいいかについては、以前の記事も参考にしてもらえればと思います。


まとめ

Tomoya

これをやって、ようやく「開発が完了した」と言えるのだと思います。

全体イメージ
Phase
MVP段階

とりあえず作って、安定して公開できる状態にすることをフェーズ1

Phase
整備・調整

今回は表示まわりを整備する、フェーズ2の段階でした。

Phase
運用

これを運用しながら人を集めていくことで、フェーズ3に移行できるのだと感じています。

Tomoya

今回は自分だけのシステムですが、これを実際にビジネスとしてやっていくのであれば、同じような段階を踏んでいくのだろうと思います。

割と楽しみながら、自分のやりたいようにシステムを作り込むことができました。

記事を編集中に再度ブラウザを見てみるとなんと約8000試合ほど戦いを繰り広げていました!

緑の枠線で強調された「攻撃の勝利 3999」と「守りの勝利 3865」のスコア数値表示パネル。
対戦・観戦画面における攻撃と守りの勝利数が数値で表示されたUI要素を拡大して示しています。

Cursorでのバイブコーディングは初心者でも始めやすいので、ぜひ一度触ってみることをおすすめします!

今回はAgent機能だけを使いましたが、Cursorには「Plan機能」という、より網羅的に計画を立ててから修正を進められる機能もあります。「そこまで違和感を感じていないけれど、念のため見てもらいたい」という時でも、AIエージェントが調査した上でしっかりした計画を立ててくれるので、安心して任せられます。

Tomoya

ただ、その計画書に目を通すのは、それはそれで少し疲れますがね。


Tomoya

自分とCursorとの付き合い方、そして実際の修正作業について、今回は記事にしてみました。
何か開発をしている方の参考になれば嬉しいです!

興味を持った方は、ぜひCursorを一度触ってみてください。

以下のリンクから月額プランを契約すると、初月は半額で利用できます。コストが心配な方でも、最初の1か月は最低10ドルから試せるので、気軽に始めやすいと思います(解約も簡単にできます)。

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

前回のおすすめ記事はこちらから

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

【非エンジニアが挑む】観戦システム整備のビフォーアフターを示すサムネイル

この記事が気に入ったら
フォローしてね!

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

始めまして。このブログを運営するTomoyaです。
未経験個人開発者。AI×個人開発(Vibe Cording)で学習して参入してくれる人が増えて広がっていくと良いなと思って始めました。

実際に作成→デプロイ(公開)→運営を行ってそれについての問題や疑問を記録していきます。
また行っていく上で内容(セキュリティ・制限など)にもこだわっていきたいなと思っています。

コメント

コメントする

目次