作る前に設計する
コードを 1 行も書く前に、実際のプロジェクトをパーツに分解する
⏱ 想定 ~7 分
01 · 読む
新しいプロジェクトに取りかかる初心者がやりがちな失敗 —— ターミナルを開いていきなりコードを書き始めることです。
プロは逆です。先に計画を立てます —— たとえ大まかな計画で、あとから変わるとしても。計画するとは、 Claude にお願いする前に 何を作るのか を考える、ということです。
AI と一緒に作業するなら、これはなおさら重要です。明確な計画があると、 Claude Code の出力もぐっと良くなります。「ゲームを作って」と言えば一般的なものが返ってきますが、「ゲーム部屋を管理し、待機中のプレイヤーをマッチングし、各手を検証する server を作って」と言えば、欲しいものがそのまま返ってきます。
ポイントまとめ
- コードを書く前に計画する —— ざっくりした計画でも助かる
- 明確な計画ほど、 AI の生成コードも良くなる
- プロジェクトをレイヤーに分ける：server、 client、通信
- オンラインマッチング付きのリアルタイム・マルチプレイヤー tic-tac-toe ゲームを作ります
02 · 読む
作るのはこれです：リアルタイム・マルチプレイヤー tic-tac-toe ゲーム。見知らぬ 2 人が同じ URL にアクセスするとマッチングされ、その場で対局します。一方のプレイヤーが手を打つと、もう一方の画面にすぐ反映されます。
ゲームを完成させるには 3 つのレイヤーが必要です。Server —— 権威者です。盤面の管理、ルールの適用、プレイヤーのマッチング、勝敗判定をすべて担当します。 Server の判断が常に正しい。プレイヤーは不正できません。なぜなら server がすべての手を検証するからです。
Client —— インターフェースです。プレイヤーがブラウザで見る HTML ページ。盤面を表示し、クリックを受け取り、 server からの更新を画面に反映します。
Communication —— 橋渡しです。 Client と server の間を流れる WebSocket イベント。プレイヤーがマスをクリックすると、 client は「make-move」イベントを送ります。 Server が検証したら、両プレイヤーへ「move-made」を送ります。
ポイントまとめ
- Server がすべてのゲーム状態を管理 —— client を信用しない
- Client は UI を表示し、ユーザー操作を受け取る
- WebSocket イベントが両者の通信レイヤー
- Server が各手を検証 —— 不正防止
03 · ステップ解説
リアルタイムアプリの 3 つのレイヤーを、今回の tic-tac-toe ゲームでそれぞれ何をするか順に見ていきましょう。
1. Server：審判
盤面（ 3x3 マス）を管理し、誰の手番かを追跡し、手を検証し（マスは空？自分の手番？）、勝敗・引き分けを判定し、待機プレイヤーをゲームルームへマッチングします。
2. Client：画面
3x3 の盤面をクリック可能なマスとして表示します。ステータス（「対戦相手を待っています…」「あなたの手番」「勝ち！」）を表示。プレイヤーがクリックしたらイベントを送信し、 server から手が届いたら盤面を更新します。
3. Communication：イベント
Client と server の間の取り決めです。プレイヤーが「Find Game」をクリック —— client は「find-game」を emit。 Server が 2 人をマッチング —— 両者へ「game-start」を emit。プレイヤーがマスをクリック —— client は「make-move」を emit。 Server が検証 —— 両者へ「move-made」を emit。ゲーム終了 —— server が「game-over」を emit。
4. Matchmaking：ロビー
Server 上に待機キューを持ちます。「Find Game」を押したらキューに入る。 2 人目が入ったら、 server がペアをルームに集め、 X と O をランダムに割り当てて対局開始です。
5. Disconnect 処理：きれいに後片付け
対局中にブラウザを閉じられたら、 server は切断を検知して相手に通知します。キュー中に切断された場合は、 server がキューから取り除きます。ゾンビゲームも、立ち往生するプレイヤーも残しません。
04 · コード例
プレイヤー 2 人と server の間で流れるイベントの様子です。よく観察してください —— これがこの先 7 課で実装していく設計図です。
イベントフロー：マッチングからゲーム終了まで
Player A Server Player B
| | |
|--- find-game ---->| |
|<--- waiting ------| |
| |<--- find-game -----|
|<-- game-start ----|--- game-start ---->|
| (you are X) | (you are O) |
| | |
|--- make-move ---->| | (A clicks cell 4)
|<-- move-made -----|--- move-made ----->| (server: valid!)
| | |
| |<--- make-move -----| (B clicks cell 0)
|<-- move-made -----|--- move-made ----->| (server: valid!)
| | |
| ...more moves... |
| | |
|<-- game-over -----|--- game-over ----->| (X wins!)
| (you won!) | (you lost) |
すべての操作が server を経由する点に注目してください。プレイヤー A が直接プレイヤー B に話しかけることは一度もありません。 Server が手を受け取り、検証し、結果を両者にブロードキャストします。これはあらゆるマルチプレイヤーゲームの標準的なアーキテクチャです。
05 · チェックリスト
コードを書く前に、計画を理解できているか確認しましょう。各項目、納得できたらチェックを入れてください。
- Server がすべてのゲーム状態を持つ —— 盤面、誰の手番か、誰が X で誰が O か
- Client はイベント（例：「make-move」）を送り、 server に言われたことを表示するだけ
- Matchmaking が待機中の 2 人を 1 つのゲームルームに組み合わせる
- 各手は server が検証してからプレイヤーに表示される
- プレイヤーが切断したら、 server が後片付けして相手に通知する
06 · クイズ
なぜ server で手を検証すべきで、 client を信用してはいけないのか？
- Server の検証の方が client より速いから
- Client はゲーム状態にアクセスできないから
- プレイヤーが client のコードを書き換えて不正できる —— server だけが唯一の信頼できる権威
- WebSocket は server 側の検証を必須としているから
⚠ 全機能のインタラクティブ体験には JavaScript が必要です。JavaScript を有効にして再読み込みしてください。
※ このサイトは独立した教育プロジェクトで、Anthropic の公式製品ではありません。Claude™ は Anthropic, PBC の商標です。