ChatGPT SitesはどこまでノーコードでWebアプリ開発できるのか。思い立ったら5分で作ってアプリを公開できてしまう。WEBデザインスキルが不足していた私や皆さん、もはやそこが問題ではありません。

ChatGPT chatでゲームを開発のプロンプト作成、workで流し込み

例えばマインスイーパーを公開したい、カウンター設置したい、一般公開したいと大雑把、雑にゲームの内容/仕様をchat機能でSites用のプロンプト生成させる。その後にworkで実行すると上限制限をなるべく回避できる。

肌感覚ではGPT-6 Astraはリソース消費が激しい。Sol 軽、Terra 軽〜中でworkで動かして不具合が起きないかはchatで壁打ちしてworkで利用するモデルは極力性能を落としたほうがChatGPTのwork/codexリソース消費5時間上限/1週間制限に到達しにくいことも判明している。

1日で作ったゲーム(スライム対戦以外は実際に動くのでプレーしてみてね😆)

オセロ(オセロは登録商標だからリバーシという名前にしようとChatGPTより提案があったのでそうしているがゲーム自体はオセロそのものなのですが)
https://reversi-play.mnoda1979.chatgpt.site/

将棋(やや処理が複雑なので不具合防止のためAstraで作成させても良いかもしれないがSolでも動きました)
https://shogi-play.mnoda1979.chatgpt.site/

マインスイーパー(Windowsの歴史知っている人は)
https://minesweeper-classic-game.mnoda1979.chatgpt.site/

バカラ
https://baccarat-table.mnoda1979.chatgpt.site/

ルーレット
https://european-roulette.mnoda1979.chatgpt.site/

スライム系バトル(キャラが全然似てない💦ドラクエのような対戦動作ままならず放棄するかもしれませぬ)
https://slime-battle-arena.mnoda1979.chatgpt.site/

遭遇した不具合例(新たな修正プロンプトをchatで生成させworkで投入して解決)

リバーシ(オセロ)の初期画面/盤面表示がおかしい

一般公開なのにログイン権限を求められた

アクセス/実行回数カウンターが0のままでカウントアップされない

など

ChatGPT Sites 開発事例集

2026/9/17更新:こちらの記事内容も対象とする開発事例集をまとめました。
https://first-success-development-portfolio.mnoda1979.chatgpt.site/

生成で使ったプロンプト例(自動生成)

@Sites

既存のMinesweeper / マインスイーパーSiteに、以下の2種類の全体累計カウンターを追加してください。

これは既存Siteへの差分改修です。
新規Siteを作成しないでください。

既存のゲームロジック、難易度、盤面、デザイン、スマートフォン対応等を壊さず、カウンター機能に必要な箇所のみ変更してください。

1. Access Count / アクセス数

一般公開されているMinesweeperページが正常に表示された時点で、全体のAccess Countを1増加させてください。

これはブラウザ単位のlocalStorageによる個人カウンターではなく、全ユーザーで共有されるSite全体の累計アクセス数としてください。

可能な限りSitesで利用可能な永続ストレージまたはサーバー側の永続化機能を使用してください。

ページキャッシュだけに依存するカウンターにはしないでください。

同一ページ表示中のReact等による再レンダリングで重複加算されないようにしてください。

通常の1回のページロードにつき原則1回だけ加算してください。

2. Games Played / ゲーム実行回数

Minesweeperの新しいゲームが実際に開始された回数を、全ユーザー共通の累計として記録してください。

以下の場合に1回加算してください。

・初回ゲーム開始
・New Game / 新しいゲームによる再開始
・難易度を変更して新しい盤面でゲームを開始した場合

単なるマスのクリック、旗の設置、ゲームクリア、ゲームオーバー、画面再描画では加算しないでください。

1ゲームにつき1回だけ加算してください。

3. 表示

ゲーム画面の邪魔にならない場所に、

ACCESS / アクセス数: 1,234
GAMES PLAYED / ゲーム実行回数: 567

のように表示してください。

数値には可能であれば3桁区切りを使用してください。

スマートフォンでもゲーム盤を圧迫しない小さな情報表示としてください。

既存デザインを大きく変更しないでください。

4. 同時アクセス対策

複数ユーザーが同時にアクセスまたはゲーム開始した場合でも、可能な限りカウントを失わない方式にしてください。

可能であれば単純な

現在値を取得 → +1 → 保存

ではなく、atomic increment相当の安全な更新方式を使用してください。

5. 障害時

カウンター取得・更新に一時的な問題が発生しても、Minesweeper本体は正常にプレイできるようにしてください。

カウンター機能の障害によってゲーム開始をブロックしないでください。

取得できない場合は「–」等を表示して構いません。

6. 既存機能を変更しない

以下は変更しないでください。

・Minesweeperのゲームルール
・地雷配置
・最初のクリックの安全処理
・旗
・タイマー
・勝敗判定
・Beginner / Intermediate / Expert
・ベストタイム
・PC操作
・スマートフォン操作

不要なリファクタリングを行わないでください。

7. 動作確認

変更後、

・ページアクセスでAccess Countが1増える
・同一ロード内で重複加算されない
・新しいゲーム開始でGames Playedが1増える
・New GameでGames Playedが1増える
・通常のマス操作ではGames Playedが増えない
・ゲーム本体が従来通り正常に動作する
・PC、スマートフォン双方で表示が崩れない

ことを確認してください。

問題がなければ既存の一般公開Siteへ本番反映してください。

@Sites

新規Siteとして、一般公開でブラウザから遊べる完成版の「Reversi / リバーシ」を作成してください。

既存Siteの変更ではなく、新しいSiteとして作成してください。

このSiteの最優先事項は、過剰にデザインを作り込むことではなく、

・リバーシのルールが正確であること
・CPU対戦が正常に動作すること
・Easy / Normal / Hard / Expert の4段階を選択できること
・対局途中でもCPU難易度を変更できること
・PC、スマートフォンの双方で安定して遊べること
・一般公開サイトとしてログイン不要ですぐ遊べること

です。

外部API、外部データベース、ユーザー登録、ログイン、課金機能は不要です。

ゲーム処理およびCPU思考処理は、可能な限りブラウザ内で完結させてください。

⸻

1. 公開仕様

一般公開Siteとして作成してください。

閲覧・ゲームプレイにChatGPTログインその他のログインを要求しないでください。

公開URLへアクセスしたユーザーが、そのまますぐにゲームを開始できるようにしてください。

完成後、基本動作を確認して問題がなければ本番公開してください。

⸻

2. ゲーム名

サイトのメインタイトル：

Reversi
リバーシ

「Othello / オセロ」ではなく、「Reversi / リバーシ」という名称を使用してください。

独自のシンプルなデザインとしてください。

⸻

3. 基本ルール

標準的なリバーシのルールを正確に実装してください。

盤面：

8 × 8

石：

Black / 黒
White / 白

初期配置は盤面中央4マスに、

白 黒
黒 白

となる標準配置にしてください。

黒が先手です。

⸻

4. 石を置くルール

自分の石を置いたとき、

縦
横
斜め

の8方向について、相手の石を1個以上連続して挟み、その先に自分の石が存在する場合のみ合法手としてください。

合法手を打った場合、挟まれた相手の石をすべて自分の色へ反転してください。

複数方向で同時に挟んだ場合は、該当するすべての方向の石を反転してください。

合法手でないマスには石を置けないようにしてください。

⸻

5. 合法手表示

現在のプレイヤーが石を置けるマスを視覚的に分かるようにしてください。

例えば小さな点や薄いマーカーを表示してください。

ただし盤面が見づらくならないシンプルな表示としてください。

CPUの手番中には、プレイヤーが盤面を操作できないようにしてください。

⸻

6. 対戦モード

以下の2種類を用意してください。

Player vs CPU

人間対CPUです。

初期設定はこちらにしてください。

Player vs Player

同じ端末を使った2人対戦です。

Player vs Playerの場合、CPU難易度設定は無効または非表示にしてください。

⸻

7. プレイヤーの色

Player vs CPUでは、

Black / 黒
White / 白

を選択できるようにしてください。

初期設定は、

Player = Black / 黒
CPU = White / 白

としてください。

PlayerがWhiteを選択した場合は、ゲーム開始後にCPUがBlackとして先手を打ってください。

⸻

8. CPU難易度

Player vs CPUでは以下の4段階からCPUレベルを選択できるようにしてください。

Easy
Normal
Hard
Expert

初期設定は Normal としてください。

⸻

9. Easy

Easyでは初心者が勝ちやすいCPUにしてください。

基本的には合法手の中からランダムまたはランダム性の高い方法で着手してください。

ただしCPUが不正な場所へ石を置くことは絶対にないようにしてください。

⸻

10. Normal

Normalでは簡易的な盤面評価を使用してください。

最低限、

・角
・辺
・現在の石数
・合法手数（Mobility）

などを考慮してください。

特に角は高く評価してください。

角の隣など、相手に角を取られやすくする危険な着手は低く評価してください。

Normalは深い探索を必要とせず、短時間で応答することを優先してください。

⸻

11. Hard

HardではMinimaxまたはNegamax等のゲーム木探索を使用し、Alpha-Beta pruning（αβ枝刈り）を実装してください。

Normalより複数手先を探索してください。

評価関数では最低限、

・Corners / 角
・Edges / 辺
・Mobility / 合法手数
・Disc difference / 石数差
・Frontier discs
・危険な角周辺マス

などを考慮してください。

単純に現在の石数だけで判断するCPUにはしないでください。

ブラウザが長時間停止しない範囲で探索してください。

⸻

12. Expert

Expertは4段階の中で最も強いCPUとしてください。

Hardより深い探索を行ってください。

MinimaxまたはNegamax + Alpha-Beta pruningを基本としてください。

評価関数では、

・Corners
・Corner closeness
・Edges
・Mobility
・Potential Mobility
・Frontier discs
・Disc difference
・Stable discs またはそれに準じた安定性評価
・ゲーム進行段階

など、リバーシで重要な要素を複合的に考慮してください。

序盤・中盤・終盤で評価項目の重みを変更して構いません。

終盤で空きマスが十分少なくなった場合は、可能な範囲で終局まで探索し、最終的な勝敗または石差を評価してください。

ただし最優先はブラウザをフリーズさせないことです。

必要であれば、

・探索深度制限
・思考時間制限
・反復深化
・Transposition Table
・Move Ordering

等を使用してください。

Expertだからといって無制限探索は行わないでください。

⸻

13. CPU思考中表示

CPUが計算している間は、

CPU thinking…
CPU思考中…

などを表示してください。

CPU思考中にユーザーが連続操作して盤面状態を壊せないようにしてください。

可能であればCPU着手まで短い自然な待ち時間を設けても構いませんが、不要に長く待たせないでください。

⸻

14. 対局途中の難易度変更

重要な仕様です。

Player vs CPUでは、ゲーム開始後・対局途中でも、

Easy
Normal
Hard
Expert

を自由に変更できるようにしてください。

難易度を変更しても、

・盤面
・現在の石
・現在の手番
・黒石数
・白石数
・ゲーム状態

をリセットしないでください。

変更された難易度は、次回以降のCPU着手から適用してください。

例えば、

Easy → Expert
Expert → Normal
Normal → Hard

のような変更を対局途中で可能にしてください。

難易度変更だけではNew Gameを実行しないでください。

⸻

15. パス処理

現在のプレイヤーに合法手が1つもない場合は、自動的にPASSとしてください。

画面上に、

PASS
置ける場所がないためパスしました

等を短時間または明確に表示してください。

一方のプレイヤーだけが置けない場合、ゲーム終了にはせず相手へ手番を移してください。

⸻

16. ゲーム終了条件

以下の場合にゲーム終了としてください。

・盤面64マスがすべて埋まった
または
・BlackとWhiteの双方に合法手がなくなった

ゲーム終了後、

Blackの石数
Whiteの石数

を集計してください。

黒が多ければ、

BLACK WINS

白が多ければ、

WHITE WINS

同数なら、

DRAW

と表示してください。

日本語も併記してください。

ゲーム終了後は盤面へ新しい石を置けないようにしてください。

⸻

17. 石数表示

ゲーム画面上部または盤面付近に常時、

BLACK ● XX
WHITE ○ XX

のように現在の石数を表示してください。

石を置いて反転するたびに即座に更新してください。

現在どちらの手番なのかも明確に表示してください。

例：

YOUR TURN
あなたの番

CPU TURN
CPUの番

BLACK TURN
黒の番

WHITE TURN
白の番

⸻

18. New Game

New Game / 新しいゲーム

ボタンを設置してください。

押した場合、

・盤面
・石配置
・手番
・ゲーム終了状態
・PASS状態

を初期化して、新しいゲームを開始してください。

現在選択している、

・対戦モード
・CPU難易度
・Playerの色

については、その設定を使用して新しいゲームを開始してください。

⸻

19. Undo

Player vs CPUの場合に限り、

Undo / 一手戻す

機能を用意してください。

基本的には、

直前のPlayerの着手と、それに対するCPUの着手

をセットで戻し、再びPlayerが考えられる状態へ戻してください。

CPUがまだ着手していない場合などでも盤面状態が壊れないようにしてください。

ゲーム終了直後でも、可能であればUndoできるようにしてください。

Player vs Playerの場合は、直前の1手を戻す仕様でも構いません。

Undo実装によってゲーム本体が不安定になる場合は、ゲームロジックの安定性を優先してください。

⸻

20. スマートフォン対応

PC、スマートフォン、タブレットに対応してください。

8×8盤面は可能な限り画面幅に収めてください。

スマートフォンでは横スクロールを必要としない設計を優先してください。

各マスはタップしやすいサイズにしてください。

スマートフォンでは、

タップ → 石を置く

というシンプルな操作にしてください。

ドラッグ操作は不要です。

⸻

21. デザイン

クラシックなボードゲームとして分かりやすいデザインにしてください。

盤面は緑系などリバーシ盤として自然な色調で構いません。

石は黒・白を明確に区別してください。

以下を重視してください。

・盤面が最も目立つ
・合法手が分かる
・現在の手番が分かる
・黒白の石数が分かる
・CPU難易度が分かる
・スマートフォンでも操作しやすい
・過剰なアニメーションを使用しない
・不要な装飾を増やさない

石が反転するときに軽いアニメーションを付けても構いませんが、ゲームロジックや操作性を優先してください。

⸻

22. データ保存

外部データベースは使用しないでください。

可能であればブラウザのlocalStorage等を利用して、

・Player勝利数
・CPU勝利数
・Draw数

程度の簡単な戦績を保存して構いません。

ただし、この機能はゲーム本体より優先度を下げてください。

⸻

23. 不要な機能

以下は実装しないでください。

・ChatGPTログイン
・Microsoft OAuth
・ユーザー登録
・外部データベース
・外部API
・オンライン対人戦
・チャット
・ランキングサーバー
・課金
・広告
・SNS機能
・不要な管理画面

一般ユーザーが公開URLへアクセスして、すぐ遊べることを優先してください。

⸻

24. ゲームロジック上の重要事項

以下について特に不具合がないようにしてください。

・8方向の合法手判定が正しい
・盤面端で範囲外アクセスしない
・複数方向の石を同時に正しく反転する
・合法手以外には置けない
・PASS判定が正しい
・連続PASSで正しく終局する
・CPUが必ず合法手を選択する
・CPU手番中にPlayerが操作できない
・PlayerがWhiteの場合、CPU Blackが正しく先手を打つ
・途中でCPU難易度を変更しても盤面がリセットされない
・難易度変更後の次回CPU着手から新しいレベルが適用される
・ゲーム終了後に着手できない
・New Gameで以前の盤面状態が残らない
・Undoで盤面状態が破損しない
・CPU処理が重複実行されない
・CPU思考中にNew Game等を実行しても古いCPU計算結果が新しい盤面へ適用されない

非同期処理を使用する場合は、古いゲームに対するCPU計算結果が新しいゲームへ反映されないよう、ゲームIDやキャンセル相当の仕組みを設けてください。

⸻

25. CPU性能と安定性

HardおよびExpertの探索処理によってブラウザが長時間フリーズしないようにしてください。

CPU強度よりもサイト全体が正常に操作できることを優先してください。

Expertについても現実的な探索上限を設定してください。

PCより処理能力の低いスマートフォンでも使用可能な範囲にしてください。

必要であれば探索処理を分割する、Web Worker相当の方法を利用する、探索深度や時間を制御する等の対策をしてください。

ただし構成を必要以上に複雑にしないでください。

⸻

26. 実装優先順位

以下の順番で完成させてください。

1. 8×8盤面
2. 初期配置
3. 合法手判定
4. 石の反転処理
5. 手番管理
6. PASS
7. 終局判定
8. Player vs Player
9. Player vs CPU
10. Easy
11. Normal
12. Hard
13. Expert
14. 対局途中のCPU難易度変更
15. Playerの黒白選択
16. New Game
17. Undo
18. スマートフォン対応
19. 戦績保存
20. デザイン調整

見た目を作り込んでゲーム本体が未完成になることを避けてください。

ゲームロジックとCPU対戦を完成させることを最優先してください。

⸻

27. 動作確認

実装後、最低限以下を確認してください。

・初期配置が正しい
・Blackが先手
・合法手のみ着手可能
・縦、横、斜めの反転が正しい
・複数方向の同時反転が正しい
・合法手がない場合にPASSする
・双方に合法手がなくなれば終局する
・最終石数が正しく計算される
・Easy CPUが正常に着手する
・Normal CPUが正常に着手する
・Hard CPUが正常に着手する
・Expert CPUが正常に着手する
・CPUが不正な手を打たない
・Easy → Expertへ対局途中で変更できる
・Expert → Easyへ対局途中で変更できる
・難易度変更時に盤面がリセットされない
・Player Blackで正常に開始できる
・Player WhiteでCPU Blackが先手を打つ
・New Gameが正常
・Undoが正常
・スマートフォン相当の画面幅でも盤面を操作できる

大規模な網羅的テストや不要なリファクタリングは行わないでください。

不具合が見つかった場合、その不具合に必要な箇所だけ修正してください。

⸻

28. 完了条件

「画面だけ完成している」状態ではなく、実際に最後まで対局できる完成状態にしてください。

特に、

Player vs CPU
Easy / Normal / Hard / Expert
対局途中の難易度変更

の3点は必須機能です。

利用可能な作業時間や実行枠が限られる場合は、デザインや付加機能よりゲーム本体を優先してください。

実装完了後に基本的なゲームプレイを実際に確認してください。

問題があれば必要最小限の修正を行ってください。

問題がなければ、ログイン不要の一般公開Siteとして本番公開してください。

@Sites

新規Siteとして、一般公開でブラウザから遊べる完成版の

Shogi
将棋

を作成してください。

既存Siteの変更ではなく、新しいSiteとして作成してください。

最優先事項は、

・日本将棋として正しいルール
・9×9盤
・すべての駒の正しい移動
・駒取り
・持ち駒
・駒打ち
・成り
・王手
・詰み
・二歩等の反則手防止
・人間 vs CPU
・人間 vs 人間
・CPU Easy / Normal / Hard / Expert
・対局途中でCPU難易度変更可能
・PC / スマートフォン対応
・全ユーザー共通の正確なACCESS / GAMES PLAYED累計カウンター
・ログイン不要
・一般公開
・最後まで実際に対局可能

です。

見た目の作り込みよりも、

「合法手判定が正しく、通常の将棋を最初から最後まで対局できること」

を最優先してください。

⸻

1. 公開仕様

ログイン不要の一般公開Siteとしてください。

公開URLへアクセスしたユーザーがすぐに対局できるようにしてください。

対局ロジックおよびCPU思考は、可能な限りブラウザ側で実行してください。

CPUの着手を決めるために毎手ChatGPTや外部生成AI APIへ問い合わせる方式にはしないでください。

外部AI API、課金API等は使用しないでください。

⸻

2. 盤面

標準的な日本将棋の

9列 × 9段

の81マスとしてください。

初期配置を正式な将棋ルール通りにしてください。

先手が最初に指します。

盤面には日本語の将棋駒を分かりやすく表示してください。

先手と後手の駒の向きが明確に分かるようにしてください。

⸻

3. 駒

以下をすべて正しく実装してください。

王将 / 玉将
飛車
角行
金将
銀将
桂馬
香車
歩兵

さらに成駒：

龍王
龍馬
成銀
成桂
成香
と金

を正しく実装してください。

各駒の移動可能方向・距離を正式な将棋ルール通りにしてください。

飛車、角、香車等の長距離駒は、他の駒を飛び越えられないようにしてください。

桂馬のみ通常の駒とは異なる跳躍移動として正しく処理してください。

⸻

4. 駒取り

相手の駒が存在するマスへ合法的に移動した場合、その駒を取って自分の持ち駒へ追加してください。

成駒を取った場合は成る前の駒へ戻して持ち駒にしてください。

例：

と金を取る
→ 歩として持ち駒へ追加

龍王を取る
→ 飛車として追加

龍馬を取る
→ 角として追加

としてください。

⸻

5. 持ち駒

先手・後手それぞれの持ち駒を盤面付近に表示してください。

同一種類を複数持っている場合は、

歩 × 3

等、枚数が明確に分かるようにしてください。

持ち駒を選択して盤上の合法的な空きマスへ打てるようにしてください。

⸻

6. 駒打ち

持ち駒は空いている合法マスへ打てるようにしてください。

ただし将棋の駒打ちに関する禁止事項を正しく実装してください。

最低限、

・二歩
・行き所のない駒
・打ち歩詰め

を禁止してください。

⸻

7. 二歩

同じ筋に自分の「成っていない歩」が既に存在する場合、その筋へ新しい歩を打てないようにしてください。

と金は二歩判定上の歩として数えないでください。

不正な歩打ちはUI上でも選択できないようにしてください。

⸻

8. 行き所のない駒

駒を打った直後に合法的な次の移動先が存在しなくなる以下の駒打ちを禁止してください。

歩：
相手側最終段へ打てない

香車：
相手側最終段へ打てない

桂馬：
相手側最終段およびその1段手前へ打てない

同様に、盤上の駒を「成らず」に移動すると行き所がなくなる場合は、正式ルールに従って強制的に成る必要がある状態として処理してください。

⸻

9. 成り

敵陣3段を成りゾーンとして正しく扱ってください。

駒が、

・成りゾーンへ入る
・成りゾーン内で移動する
・成りゾーンから出る

等、正式ルール上成ることが可能な手について、

成る
成らない

をユーザーが選択できるようにしてください。

ただし、歩・香・桂等で「成らなければ次の合法手が存在しない」場合は強制成りとしてください。

王将 / 玉将
金将

は成れません。

持ち駒を打った瞬間に成ることはできません。

⸻

10. 王手

王将 / 玉将が相手駒に攻撃されている状態を正しく検出してください。

王手の場合、

CHECK / 王手

と明確に表示してください。

自分の王が王手されている状態で、その王手を解消しない手は合法手として認めないでください。

⸻

11. 自殺手禁止

自分の着手後に自分の王将 / 玉将が相手の攻撃範囲内に残る手は禁止してください。

これは、

・通常の駒移動
・王の移動
・駒取り
・持ち駒を打つ

すべてについて適用してください。

単純な駒の移動可能範囲と「合法手」を明確に区別してください。

⸻

12. 打ち歩詰め

歩を持ち駒から打つことによって相手玉を即座に詰ませる「打ち歩詰め」を禁止してください。

単に歩を打って王手をかけること自体は禁止しないでください。

「歩打ちによる王手」と「打ち歩詰め」を正しく区別してください。

この判定について重点的にテストしてください。

⸻

13. 詰み

王手状態で合法的な回避手が一つも存在しない場合、

CHECKMATE / 詰み

として対局終了してください。

王手回避について、

・王が逃げる
・王手している駒を取る
・他の駒で王手駒を取る
・合駒する
・持ち駒を打って合駒する

等の合法的な回避手をすべて考慮してください。

単純に王の逃げ道だけを確認して詰み判定しないでください。

⸻

14. 投了

Resign / 投了

ボタンを用意してください。

確認後に投了して対局終了としてください。

CPUも、明白な詰みが確定した場合等は必要に応じて投了可能として構いませんが、必須ではありません。

⸻

15. 千日手等

可能であれば局面履歴を保持し、正式な将棋ルールに沿った千日手を検出してください。

ただし初期実装では、

・基本合法手
・王手
・詰み
・成り
・持ち駒
・二歩
・打ち歩詰め

の正確性を優先してください。

複雑な特殊終局処理を追加することで基本対局を壊さないでください。

⸻

16. Game Mode

以下を用意してください。

Player vs CPU
Player vs Player

デフォルト：

Player vs CPU

としてください。

Player vs Playerは同一端末上で交互に指すローカル対局で構いません。

オンライン対戦は不要です。

⸻

17. Player Side

Player vs CPUでは、

Black / 先手
White / 後手

を選択できるようにしてください。

デフォルト：

Black / 先手

としてください。

ユーザーが後手を選択した場合は、対局開始後CPUが先手として自動的に初手を指してください。

⸻

18. CPU Level

CPU難易度：

Easy
Normal
Hard
Expert

の4段階を用意してください。

デフォルト：

Normal

としてください。

CPUの思考処理はブラウザ側で完結させ、対局中の各着手ごとにChatGPT等の生成AIを呼び出さないでください。

⸻

19. Easy CPU

Easyは合法手の中からランダム性を強くした選択を行ってください。

ただし必ず合法手だけを指してください。

Easyだからといって、

・王手放置
・二歩
・不正な駒打ち
・自殺手

等を行ってはいけません。

⸻

20. Normal CPU

Normalは基本的な局面評価を使用してください。

最低限、

・駒の価値
・駒得 / 駒損
・王手
・駒取り
・成り
・玉の安全性
・持ち駒
・盤上の位置

等を評価してください。

浅めのMinimax / Negamax + Alpha-Beta pruning等を使用して構いません。

初心者が楽しめる程度の強さを目標にしてください。

⸻

21. Hard CPU

HardはNormalより深い探索を行ってください。

評価関数には可能な範囲で、

・Material
・King Safety
・Mobility
・Piece Activity
・Promotion
・Captured Pieces
・Threats
・Checks
・Pawn Structure
・Piece Position

等を含めてください。

MinimaxまたはNegamax + Alpha-Beta pruningを使用してください。

Move Ordering等で探索効率を改善してください。

⸻

22. Expert CPU

Expertは、このSiteのブラウザ環境で現実的な範囲において最も強いCPUとしてください。

可能であれば、

・Iterative Deepening
・Alpha-Beta pruning
・Move Ordering
・Transposition Table
・Quiescence Search
・局面段階に応じた評価
・詰み探索の強化

等を使用してください。

ただしCPU強化のためにゲーム本体の安定性を犠牲にしないでください。

Expertの目標は「ブラウザ内で実用的に可能な範囲で強いCPU」であり、プロ棋士級や専用将棋エンジン級を保証する必要はありません。

⸻

23. CPU思考時間

CPU思考中は、

CPU THINKING…
CPU思考中…

と表示してください。

CPU思考中はユーザーが盤面操作できないようにしてください。

CPU探索には適切な時間制限を設け、ブラウザが長時間フリーズしないようにしてください。

特にスマートフォンではCPU負荷に注意してください。

可能であればWeb Worker等を使用し、CPU思考中もUIが固まらない設計にしてください。

⸻

24. 対局途中のCPU難易度変更

重要です。

CPU Levelは対局途中でも、

Easy
Normal
Hard
Expert

を自由に変更できるようにしてください。

難易度変更によって、

・盤面
・持ち駒
・手番
・棋譜
・対局状態

をリセットしないでください。

変更したCPU Levelは次回のCPU着手から適用してください。

CPU思考中の難易度変更については、現在の探索を安全にキャンセルして新しいLevelで再探索するか、次回着手から適用する等、一貫した安全な処理にしてください。

⸻

25. 合法手表示

ユーザーが自分の駒を選択した場合、その駒の合法的な移動先だけを視覚的に表示してください。

持ち駒を選択した場合も、合法的に打てるマスだけを表示してください。

単純な移動可能マスではなく、

「その手を指した後、自分の王が王手されない」

ことまで確認した最終的な合法手だけを表示してください。

⸻

26. Undo / 待った

Undo / 待った

を実装してください。

Player vs CPUでは、原則としてユーザーの直前手とCPUの直前手を1組として戻し、ユーザーが再び指せる局面へ戻してください。

Player vs Playerでは1手ずつ戻してください。

Undoによって、

・盤面
・持ち駒
・成り状態
・手番
・棋譜
・王手状態

が完全に元へ戻るようにしてください。

⸻

27. New Game

New Game / 新しい対局

ボタンを用意してください。

新しい対局を開始する場合は確認を表示して構いません。

新規対局では盤面・持ち駒・棋譜等を初期化してください。

Game Mode
Player Side
CPU Level

等の選択値は保持して構いません。

⸻

28. 棋譜

対局中の着手履歴を保持してください。

最低限、ユーザーが何手目まで進んでいるか分かるようにしてください。

可能であれば標準的な日本将棋の棋譜表記に近い形式で、

▲7六歩
△3四歩

等を表示してください。

ただし棋譜表記の高度な曖昧性解消より、ゲームロジックの正確性を優先してください。

⸻

29. 状態表示

常時、

・現在の手番
・先手 / 後手
・CPU Level
・王手状態
・持ち駒
・手数

が分かるようにしてください。

対局終了時には、

Black Wins / 先手勝ち
White Wins / 後手勝ち
Draw / 引き分け

等を明確に表示してください。

⸻

30. ACCESS / アクセス数

全ユーザー共通の累計ACCESSカウンターを実装してください。

公開ページが正常に表示された場合、原則として1ページロードにつき1回だけACCESSをincrementしてください。

React等の再レンダリングで重複加算しないでください。

localStorage
sessionStorage
React state
JavaScript変数

だけをACCESSの正本にしてはいけません。

Sitesで利用可能な共有永続ストレージ／サーバー側永続化機能を実際に使用してください。

別ブラウザ・別端末・別ユーザーでも同じ累計値を参照できるようにしてください。

⸻

31. GAMES PLAYED / 対局実行回数

全ユーザー共通の累計GAMES PLAYEDを実装してください。

新しい対局が実際に開始された時点で1増加させてください。

以下の場合は+1：

・初回の新規対局開始
・New Gameによる新規対局
・Game Mode変更によって新しい対局を開始した場合
・Player Side変更によって新しい対局を開始した場合

以下の場合は増加させない：

・1手指す
・CPUが指す
・駒を取る
・成る
・王手
・Undo
・投了
・詰み
・CPU Levelの途中変更
・棋譜表示
・React等による再レンダリング

1対局 = +1

を厳守してください。

⸻

32. カウンター永続化

ACCESS / GAMES PLAYEDについて、画面上に初期値0を表示するだけの実装は禁止します。

必ず、

・共有永続ストレージの確認または作成
・初期レコード生成
・read
・increment
・write
・更新後の最新値取得
・UI反映

まで実際に動作させてください。

可能であればatomic increment相当を使用し、複数ユーザーが同時にアクセス・対局開始しても更新値が失われないようにしてください。

カウンターレコードが存在しない場合は0から初期化し、その後incrementしてください。

エラーを単純に0へ変換して不具合を隠す実装は禁止します。

読み取り不能時は、

ACCESS: –
GAMES PLAYED: –

として構いません。

カウンター障害が発生しても将棋本体は対局可能にしてください。

もし現在のSites環境では全ユーザー共通の永続カウンターを技術的に実装できない場合、見せかけの0固定カウンターを作らず、その技術的制約を明確に報告してください。

⸻

33. カウンター表示

ゲームを邪魔しない位置へ、

ACCESS / アクセス数: 1,234
GAMES PLAYED / 対局数: 567

のように表示してください。

3桁区切りを使用してください。

PC / スマートフォン双方で確認できるようにしてください。

⸻

34. スマートフォン対応

スマートフォンを重要な対象としてください。

9×9盤全体を基本的に画面幅へ収めてください。

駒をタップして選択し、移動先をタップして着手できるようにしてください。

ドラッグ操作を必須にしないでください。

持ち駒もタップ操作で選択できるようにしてください。

成り選択もスマートフォンで簡単に操作できるようにしてください。

盤面のマスや駒が小さすぎて操作不能にならないよう調整してください。

⸻

35. デザイン

日本将棋らしい、シンプルで落ち着いたデザインにしてください。

・木製をイメージした将棋盤
・五角形に近い将棋駒
・日本語の駒文字

等を使用して構いません。

ただし画像素材に依存しすぎず、CSS / HTML / SVG等で安定して表示できる方法を優先してください。

先手と後手の駒の向きを明確にしてください。

⸻

36. CPU非同期処理の安全性

重要です。

CPU思考中に、

・New Game
・Undo
・Game Mode変更
・Player Side変更
・CPU Level変更

等が行われた場合、古い局面について計算していたCPUの着手結果を現在の盤面へ適用してはいけません。

gameId
positionId
AbortController
Worker termination

等、適切な方法で古い探索結果を無効化してください。

「New Gameした後、前の対局のCPUが突然着手する」

ようなRace Conditionを絶対に発生させないでください。

⸻

37. 実装優先順位

時間や実装量に制約がある場合、以下の順番を厳守してください。

1. 9×9盤と正式初期配置
2. 全駒の移動
3. 駒取り
4. 持ち駒
5. 駒打ち
6. 成り
7. 王手・自殺手禁止
8. 二歩・行き所のない駒
9. 打ち歩詰め
10. 詰み
11. Player vs Player
12. Player vs CPU
13. Easy / Normal CPU
14. Hard CPU
15. Expert CPU
16. Undo
17. 棋譜
18. ACCESS / GAMES PLAYED永続カウンター
19. スマートフォン最適化
20. 見た目の追加装飾

広範囲へ未完成の実装を行うより、基本ルールを完成させてから次へ進んでください。

⸻

38. ルールテスト

公開前に最低限、以下を実際にテストしてください。

・81マスである
・正式初期配置である
・先手が最初
・歩が正しく動く
・香が正しく動く
・桂が正しく動く
・銀が正しく動く
・金が正しく動く
・角が正しく動く
・飛車が正しく動く
・王 / 玉が正しく動く
・飛車 / 角 / 香が駒を飛び越えない
・桂は正しく跳躍できる
・駒を取ると持ち駒になる
・成駒を取ると元の駒になる
・持ち駒を打てる
・二歩を禁止する
・歩 / 香の最終段への不正な駒打ちを禁止する
・桂の不正な駒打ちを禁止する
・成りが正しく動作する
・強制成りが正しく動作する
・持ち駒を打った瞬間には成れない
・王手を検出する
・王手を放置する手を禁止する
・自分の王を王手状態にする手を禁止する
・打ち歩詰めを禁止する
・単なる歩打ち王手は許可する
・合法的な合駒が可能
・合法手がない王手状態を詰みと判定する
・投了で終了する
・Undoで盤面・持ち駒・成り状態まで正しく戻る
・CPUが反則手を指さない
・CPU Levelを途中変更しても盤面がリセットされない
・古いCPU探索結果が新しい対局へ混入しない

⸻

39. カウンター実動作テスト

カウンターはコード確認だけで完了としないでください。

実際に、

1. 現在のACCESSを確認
2. ページを新規ロード
3. ACCESSが+1されたことを確認
4. 現在のGAMES PLAYEDを確認
5. 新規対局を開始
6. GAMES PLAYEDが+1されたことを確認
7. 1手指す
8. GAMES PLAYEDが増えないことを確認
9. CPU Levelを変更
10. GAMES PLAYEDが増えないことを確認
11. New Game
12. GAMES PLAYEDが+1されたことを確認
13. ページを再ロード
14. ACCESS / GAMES PLAYEDが0へ戻らず保持されていることを確認

してください。

可能であれば別セッション相当からも同じ共有値を確認してください。

⸻

40. 不要機能

初期版では以下は不要です。

・オンライン対戦
・ユーザー登録
・ChatGPTログイン
・チャット
・ランキング
・課金
・広告
・外部AI API
・SNS機能

⸻

41. 完了条件

単に将棋盤が表示されるだけでは完成ではありません。

実際に、

「初期局面から合法手だけを使用して、持ち駒・駒打ち・成り・王手・詰みを含め、最後まで対局できる」

状態を完成条件としてください。

CPUについてもEasy / Normal / Hard / Expertすべてが実際に着手でき、どの難易度でも反則手を指さないことを優先してください。

ACCESS / GAMES PLAYEDについても、単なるUIではなく全ユーザー共通の永続値として実際にincrementされることを確認してください。

機能完成後にPC / スマートフォン双方で主要操作を確認してください。

問題がなければログイン不要の一般公開Siteとして本番公開してください。

@Sites

新規Siteとして、一般公開でブラウザから遊べる完成版の

European Roulette
ヨーロピアン・ルーレット

を作成してください。

既存Siteの変更ではなく、新しいSiteとして作成してください。

最優先事項は、

・European Rouletteとして正しいゲームルール
・0～36のEuropean Wheel
・各種ベットと正確な配当
・仮想残高をいつでも任意額へ変更可能
・PC / スマートフォン対応
・全ユーザー共通の正確なACCESS / PLAYS累計カウンター
・一般公開、ログイン不要
・実際に最後までプレイ可能

です。

現金、暗号資産、購入可能なチップ、換金可能ポイント、課金、外部ギャンブルサイトへの接続等は一切実装しないでください。

ゲーム内の資金は娯楽用の仮想残高のみです。

⸻

1. 公開仕様

ログイン不要の一般公開Siteとしてください。

公開URLへアクセスしたユーザーがすぐ遊べるようにしてください。

外部APIは原則不要です。

ゲームロジックは可能な限りブラウザ内で完結させてください。

⸻

2. Roulette仕様

European Rouletteのみ実装してください。

数字：

0～36

合計37ポケットです。

00は存在しません。

European Rouletteの標準的なホイール順序を使用してください。

0はGreen、それ以外は標準的なRed / Black配置としてください。

結果判定とベッティングテーブル上の数字・色を必ず一致させてください。

⸻

3. Roulette Wheel

画面上部にEuropean Roulette Wheelを表示してください。

0～36の37ポケットをホイール上に配置してください。

SPIN時には、

・ホイール回転
・ボール回転
・徐々に減速
・最終的に当選番号へ停止

するような自然なアニメーションを実装してください。

ただしゲーム結果をCSSアニメーションの位置から推測して決定しないでください。

内部ロジックで当選番号を先に正しく決定し、その結果へアニメーションを着地させてください。

アニメーションが失敗してもゲーム結果や残高計算が壊れないよう、ゲームロジックと表示演出を分離してください。

⸻

4. 乱数

当選番号は公平なランダム選択としてください。

可能であればブラウザで利用可能な暗号学的に安全な乱数源を使用してください。

0～36の37数字が均等確率になるようにしてください。

過去結果によって次回確率を変更しないでください。

Hot / Cold等を表示する場合でも、それによって次回抽選確率を変更しないでください。

⸻

5. Betting Table

European Rouletteとして分かりやすいベッティングテーブルを表示してください。

最低限以下に対応してください。

Inside Bets：

・Straight Up
・Split
・Street
・Corner

Outside Bets：

・Red / Black
・Odd / Even
・1–18 / 19–36
・1st 12 / 2nd 12 / 3rd 12
・1st Column / 2nd Column / 3rd Column

可能であればSix Lineも実装してください。

各ベットについてEuropean Rouletteの標準的な配当を正しく実装してください。

0が出た場合のOutside Betの処理もEuropean Rouletteの通常ルールに従ってください。

En Prison / La Partage等の追加ルールは初期実装では不要です。

⸻

6. 仮想チップ

仮想チップを用意してください。

例：

1
5
10
25
100
500

ユーザーがチップを選択してベッティングテーブル上へ置けるようにしてください。

同一箇所へ複数回置けるようにしてください。

複数種類のベットへ同時に賭けられるようにしてください。

現在の

TOTAL BET / 合計ベット

を常時表示してください。

Clear Bets / ベットをクリア

ボタンを用意してください。

可能であれば、

Repeat Bet / 前回と同じベット

も実装してください。

⸻

7. 仮想残高

重要な仕様です。

初期仮想残高を例えば10,000としてください。

画面上に、

BALANCE / 仮想残高

を常時表示してください。

さらに、

Set Balance / 残高設定

機能を用意してください。

ユーザーはゲーム中いつでも仮想残高を任意の金額へ変更できるようにしてください。

例えば、

100
1,000
10,000
100,000
1,000,000

等、任意の非負整数を入力可能にしてください。

設定変更前に確認操作を入れても構いません。

残高変更はゲーム内の仮想資金を変更するだけであり、実際のお金とは一切関係ありません。

仮想残高の購入・換金・送金・他ユーザーへの移転機能は実装しないでください。

入力値を検証し、負数、NaN、Infinity、不正文字列等によってゲーム状態が壊れないようにしてください。

SPIN処理中は残高変更を禁止または安全に処理してください。

⸻

8. 精算

SPIN開始時にベット内容を確定してください。

SPIN中にベット内容を変更できないようにしてください。

結果確定後、

・当選番号
・Red / Black / Green
・Odd / Even
・Low / High
・各ベットの勝敗
・今回の純損益
・更新後の仮想残高

を正しく計算してください。

複数ベットがある場合も合計精算額が正しくなるようにしてください。

残高不足のベットは受け付けないでください。

⸻

9. 履歴

直近の当選番号を表示してください。

最低でも直近10～20回程度を確認できるようにしてください。

Red / Black / Greenも視覚的に分かるようにしてください。

可能であれば、

・Red回数
・Black回数
・Green回数
・Odd / Even
・Hot Numbers
・Cold Numbers

等の簡単な統計も表示して構いません。

ただし、過去結果が将来の当選確率を予測するものではないことが分かるようにしてください。

⸻

10. ACCESS / アクセス数

全ユーザー共通の累計Access Countを実装してください。

公開ページが正常にロードされた場合、原則として1ページロードにつき1回だけincrementしてください。

React等の再レンダリングでは重複加算しないでください。

localStorage、sessionStorage、React state、JavaScript変数だけを正本にしてはいけません。

Sitesで利用可能な共有永続ストレージ／サーバー側永続化機能を実際に使用してください。

別ブラウザ、別端末、別ユーザーでも同じ累計値を参照できるようにしてください。

⸻

11. PLAYS / プレイ数

全ユーザー共通の累計Play Countを実装してください。

SPINボタンを押しただけではなく、有効なベットが存在し、実際に1回のRoulette抽選が開始された時点でPLAYSを1増加させてください。

1 SPIN = 1 PLAY

です。

複数箇所へベットしても1回のSPINなら+1だけです。

以下では増加させないでください。

・ベット配置
・ベット削除
・残高変更
・履歴表示
・ページ内再描画
・アニメーション再描画

⸻

12. カウンター永続化の最重要要件

ACCESSとPLAYSについて、UIだけ作って初期値0を表示する実装は禁止します。

必ず、

・共有永続ストレージの作成／確認
・初期レコード生成
・read
・increment
・write
・更新後の値の取得
・UIへの反映

まで実際に動作させてください。

可能であればatomic increment相当を使用し、同時アクセスによる更新消失を防いでください。

カウンターレコードが存在しない場合は0から正常に初期化してincrementしてください。

エラー発生時に単純に0を返して不具合を隠す実装は禁止します。

取得不能の場合、UIは「–」として構いません。

カウンター障害が発生してもRoulette本体はプレイ可能にしてください。

もし現在のSites環境では全ユーザー共通の永続カウンターを技術的に実装できない場合、見せかけの0固定カウンターを作らず、その制約を明確に報告してください。

⸻

13. カウンター表示

ゲームを邪魔しない位置に、

ACCESS / アクセス数: 1,234
PLAYS / プレイ数: 567

のように表示してください。

3桁区切りを使用してください。

PC / スマートフォン双方で表示してください。

⸻

14. スマートフォン

スマートフォンで実際に遊べることを重視してください。

・チップ選択
・ベット
・SPIN
・Clear Bets
・残高設定

をタップ操作だけで実行できるようにしてください。

ベッティングテーブルが小さすぎて数字を押せない状態にしないでください。

必要ならベッティングテーブル部分だけ横スクロール可能として構いません。

⸻

15. デザイン

European Casinoを連想できる上品でシンプルなデザインにしてください。

Roulette WheelとBetting Tableを主役にしてください。

過剰な装飾より視認性と操作性を優先してください。

⸻

16. 不要機能

実装しないもの：

・ユーザー登録
・ChatGPTログイン
・現金
・暗号資産
・チップ購入
・換金
・送金
・課金
・広告
・外部カジノへのリンク
・オンライン対人賭博

⸻

17. 動作確認

最低限、実際に以下を確認してください。

・0～36のみ抽選される
・00が存在しない
・Red / Blackが正しい
・各ベット判定が正しい
・配当が正しい
・複数ベットの精算が正しい
・仮想残高が正しく増減する
・任意の仮想残高へ変更できる
・SPIN中に状態が破損しない
・ACCESSが実アクセスで+1される
・PLAYSが実SPINで+1される
・再ロードしてもカウンターが0へ戻らない
・通常操作でPLAYSが重複加算されない
・スマートフォンでプレイできる

カウンターについては、コードが存在するだけではなく実際の値が増えるところまで確認してください。

問題がなければログイン不要の一般公開Siteとして本番公開してください。

@Sites

新規Siteとして、一般公開でブラウザから遊べる完成版の

Baccarat
バカラ

を作成してください。

既存Siteの変更ではなく、新しいSiteとして作成してください。

最優先事項は、

・標準的なPunto Bancoルールを正確に実装
・8-deck Shoe
・Player / Banker / Tie
・Third Card Ruleの完全自動判定
・Banker commission
・仮想残高をいつでも任意額へ変更可能
・勝敗履歴
・PC / スマートフォン対応
・全ユーザー共通の正確なACCESS / PLAYS累計カウンター
・一般公開、ログイン不要

です。

実際のお金、購入可能なチップ、換金可能ポイント、暗号資産、課金等は一切使用しないでください。

娯楽用の仮想残高だけを使用してください。

⸻

1. 公開仕様

ログイン不要の一般公開Siteとしてください。

公開URLへアクセスしたユーザーがすぐに遊べるようにしてください。

ゲームロジックは可能な限りブラウザ内で完結させてください。

⸻

2. Baccaratルール

一般的なCasino Baccarat / Punto Bancoとして実装してください。

Bet対象：

PLAYER
BANKER
TIE

Player / Bankerはユーザー自身を意味するものではなく、バカラ上のHand名称として扱ってください。

⸻

3. Card Point

カード点数：

A = 1
2～9 = 額面
10 / J / Q / K = 0

Handの合計が10以上の場合、下一桁だけを使用してください。

例：

7 + 8 = 15 → 5
9 + 7 + 8 = 24 → 4

常に0～9として判定してください。

⸻

4. Shoe

8デック＝416枚のカードからなるShoeを生成してください。

Shoe開始時に適切にシャッフルしてください。

使用したカードはShoeから除外し、次のHandでは再利用しないでください。

単純に毎Handカードを独立乱数生成する方式にはしないでください。

Shoe内の残りカード枚数を管理してください。

残りカードが安全なゲーム進行に不足する一定水準へ達したら、新しい8-deck Shoeを自動生成・シャッフルしてください。

新しいShoeへ切り替わったことを簡潔に表示して構いません。

⸻

5. Initial Deal

標準的な順序で、

Player
Banker
Player
Banker

へ2枚ずつ配ってください。

カードを視覚的に表示してください。

⸻

6. Natural

最初の2枚の合計がPlayerまたはBankerのいずれかで8または9の場合、Naturalとして標準ルールに従ってThird Cardを引かず勝敗判定してください。

Natural 8
Natural 9

が分かる表示にして構いません。

⸻

7. Third Card Rule

最重要です。

PlayerとBankerのThird Card Ruleを標準的なPunto Bancoルールに従って完全に実装してください。

Player：

0～5 → Draw
6～7 → Stand
8～9 → Natural

を基本としてください。

Bankerについては、Banker自身の2枚合計とPlayerのThird Cardの値に基づく標準的なThird Card Tableを正確に実装してください。

BankerのThird Cardをユーザー判断にはしないでください。

すべてルールに基づいて自動処理してください。

この部分について重点的にテストしてください。

⸻

8. 勝敗

最終Hand Valueを比較し、

Player > Banker → PLAYER WIN
Banker > Player → BANKER WIN
同点 → TIE

としてください。

PlayerとBanker双方の最終点数を表示してください。

⸻

9. 配当

標準的なCommission Baccaratとして、

PLAYER：
1:1

BANKER：
1:1から5% commission

TIE：
8:1

を初期設定としてください。

Tie発生時、Player / Bankerへの通常BetはPushとして元Betを返却する標準的な方式としてください。

精算ロジックは内部的に一貫した方式で実装し、元本返却と純利益を二重計算しないでください。

⸻

10. 仮想チップ

例えば、

1
5
10
25
100
500

の仮想チップを用意してください。

PLAYER
BANKER
TIE

へタップしてBetできるようにしてください。

複数箇所への同時Betを許可して構いません。

TOTAL BET / 合計ベット

を表示してください。

Clear Bets / ベットをクリア

を用意してください。

可能であればRepeat Betも追加してください。

⸻

11. 仮想残高

初期仮想残高を例えば10,000としてください。

BALANCE / 仮想残高

を常時表示してください。

Set Balance / 残高設定

機能を設置してください。

ユーザーはいつでも、

100
1,000
10,000
100,000
1,000,000

等の任意の非負整数へ仮想残高を変更できるようにしてください。

ゲーム進行中・カード配布中は変更を禁止するか、安全に処理してください。

入力値を検証し、

・負数
・NaN
・Infinity
・不正文字列
・極端すぎる値

によってゲーム状態が壊れないようにしてください。

残高設定は娯楽用の仮想資金変更だけです。

現金購入、換金、送金、他ユーザーへの移転は一切実装しないでください。

⸻

12. DEAL

有効なBetがある場合のみDEAL可能としてください。

DEAL開始後、

・Betを確定
・カード配布
・Natural判定
・Third Card Rule
・最終点数
・勝敗
・配当
・仮想残高更新

まで自動的に処理してください。

DEAL中にボタン連打して複数ゲームが同時実行されないようにしてください。

⸻

13. Roadmap / 履歴

最低限、過去の結果を

P = Player
B = Banker
T = Tie

として表示してください。

可能であれば一般的なBaccarat Roadmapのうち、

・Bead Plate / 珠盤
・Big Road / 大路

を実装してください。

Roadmap表示がゲームロジックを複雑化させすぎる場合は、まず勝敗履歴を確実に完成させてください。

⸻

14. Shoe情報

現在のShoeについて、

CARDS REMAINING / 残りカード

を表示してください。

必要であれば、

NEW SHOE / 新しいシュー

ボタンを用意して、ユーザーが任意に新しい8-deck Shoeへリセットできるようにして構いません。

New Shoeは新しいHandとしてPLAYSを増加させないでください。

⸻

15. ACCESS / アクセス数

全ユーザー共通の累計Access Countを実装してください。

公開ページが正常にロードされた場合、1ページロードにつき原則1回だけincrementしてください。

React等の再レンダリングでは重複加算しないでください。

localStorage、sessionStorage、React state、JavaScript変数だけを正本にしてはいけません。

Sitesで利用可能な共有永続ストレージ／サーバー側永続化機能を実際に使用してください。

別ブラウザ、別端末、別ユーザーでも同じ累計値を表示してください。

⸻

16. PLAYS / プレイ数

全ユーザー共通の累計Play Countを実装してください。

有効なBetが存在し、DEALを開始して1Handが実際に開始された時点でPLAYSを1増加させてください。

1 Hand = 1 PLAY

です。

Player / Banker / Tieへ複数Betしていても1Handなら+1だけです。

以下では増加させないでください。

・Bet配置
・Bet削除
・残高変更
・New Shoe
・履歴表示
・カードアニメーション再描画

⸻

17. カウンター永続化の最重要要件

ACCESSとPLAYSについて、画面上に0を表示するだけの実装は禁止します。

必ず、

・共有永続ストレージの作成／確認
・初期レコード生成
・read
・increment
・write
・最新値取得
・UI反映

まで実際に動作させてください。

可能であればatomic increment相当を使用してください。

複数ユーザーが同時アクセスしても更新を可能な限り失わないようにしてください。

レコードが存在しない場合は0で初期化してから正常にincrementしてください。

読み取り・更新エラーを単純に0へ変換して不具合を隠す実装は禁止します。

取得不能時のUIは「–」として構いません。

カウンター障害によってBaccarat本体を停止させないでください。

もし現在のSites環境では全ユーザー共有の永続カウンターを技術的に実現できない場合、見せかけの0固定カウンターを作らず、その技術的制約を明確に報告してください。

⸻

18. カウンター表示

ゲームを邪魔しない位置へ、

ACCESS / アクセス数: 1,234
PLAYS / プレイ数: 567

のように表示してください。

3桁区切りを使用してください。

PC / スマートフォン双方で表示してください。

⸻

19. スマートフォン対応

スマートフォンで、

・PLAYER Bet
・BANKER Bet
・TIE Bet
・チップ選択
・DEAL
・Clear Bets
・残高設定
・履歴確認

が容易にできるようにしてください。

カードが小さすぎたり、横方向にはみ出したりしないようにしてください。

⸻

20. デザイン

上品なCasino Baccarat Tableをイメージしたデザインとしてください。

PLAYER
BANKER
TIE

を明確に区別してください。

カードとHand Valueを見やすくしてください。

過剰な演出より操作性を優先してください。

カード配布時に軽いアニメーションを使用して構いません。

⸻

21. 不要機能

以下は実装しないでください。

・ユーザー登録
・ChatGPTログイン
・現金
・暗号資産
・チップ購入
・換金
・送金
・課金
・広告
・外部カジノへのリンク
・オンライン対人賭博

⸻

22. ゲームロジック重点テスト

特にThird Card Ruleを重点的に確認してください。

PlayerのThird Card有無と値、それに対するBankerのDraw / Standが標準ルールと一致することを複数パターン確認してください。

さらに、

・Natural 8
・Natural 9
・Player Win
・Banker Win
・Tie
・Banker commission
・Tie時のPlayer / Banker Push
・Shoeから使用カードが減る
・New Shoeで416枚へ戻る
・残高計算

を確認してください。

⸻

23. カウンター実動作テスト

コードを実装しただけでは完了にしないでください。

実際に、

1. ACCESS現在値を確認
2. ページを新規ロード
3. ACCESSが+1されたことを確認
4. BetしてDEAL
5. PLAYSが+1されたことを確認
6. Bet操作だけではPLAYSが増えないことを確認
7. New ShoeでPLAYSが増えないことを確認
8. もう1Hand DEAL
9. PLAYSがさらに+1されることを確認
10. ページ再ロード
11. ACCESS / PLAYSが0へ戻らず保持されることを確認

してください。

可能であれば別セッション相当でも同じ共有値が取得できることを確認してください。

⸻

24. 完了条件

画面だけではなく、最後まで繰り返しプレイできる完成状態にしてください。

特に、

・Third Card Rule
・8-deck Shoe
・精算
・仮想残高変更
・ACCESS永続カウンター
・PLAYS永続カウンター

は必須です。

見た目の細かな調整より、ゲームロジックとカウンターの実動作を優先してください。

実際の動作確認で問題がなければ、ログイン不要の一般公開Siteとして本番公開してください。