3度目の正直ということで、要件定義（requiremnet.md）と概要設計（desing.md）を作成して、Claude Sonnet で3マッチゲームを作ってみます。
完全にオートメーションという訳にはいかないでしょうが、出だしぐらいはいけるんじゃないでしょうか？ Claude Code のように git へのコミットとかはできませんが、この手のプログラムを AI エージェントに一括に任せることは少なく（アイデアを間に差し込むので）、初期のプロトタイプの底上げが目的です。これまでの2回は、自動生成させたコードがバグバグで到底直せない感じになってしまったので、ちょっと慎重に概要設計を書いています。
要件定義 requiremnet.md
# 要件定義
マッチ3ゲームの要件定義を以下に示す
## ゲームの目的
- 同じ色のジェルを3つ以上揃えて消す
- ブロックを消しときに、爆弾、中爆弾などのアイテムが出現する。アイテムを消すと、ジェルの消え方が様々に変わる
- ジェルを動かしたり、アイテムをクリックすることで、残り動作のカウントが減る。ゲームスタート時のカウントが0になるとゲームオーバーになる。
- すべてのブロックの裏にパネルが貼り付けてあり、すべてのパネルを消すことがゲームの目的となる
## ゲームのルール
- プレイヤーは隣接するブロックを入れ替えて、3つ以上の同じ色のブロックを揃える
- ブロックが消えると、上のブロックが下に落ちてくる
- 新しいブロックが上から追加される
- 消せない岩ブロックがある
- パネルをすべてのブロックの裏に配置させて、すべてのパネルを消すようにジェルや爆弾を操作する
## ユーザーインターフェース
- ゲームボードは8x8のグリッド
- 各ブロックは異なる色と形を持つ
- スコア、残り動作のカウント、レベルを表示するUI要素
## 機能要件
- Webブラウザ上で動作する
- モバイルデバイスに対応したレスポンシブデザイン
- 高速な描画とアニメーションでユーザー体験を向上させる。SVG形式を採用すること。
- 爆弾が消えるときには派手なアニメーションをつける
## 非機能要件
- ゲームのパフォーマンスは、低スペックのデバイスでも快適に動作すること
- アクセシビリティを考慮し、キーボード操作ができること
- ジェルが消えるロジックは関数化されて、テスト可能となっていること
- ジェルの色は3色から5色まで変更可能とすること
概要設計 desing.md
# 概要設計
このドキュメントは、システムの概要設計を記述します。以下のセクションでは、システムのアーキテクチャ、主要なコンポーネント、および相互作用について説明します。
## システムアーキテクチャ
- マッチ3ゲームは、ブラウザ上で動作する
- 画面をカラフルにするための SVG 形式を使用する
- ゲームのロジックは TypeScript で実装される
- ゲームのロジックは、単体テストが可能にする。ロジックは UI の ファイルを別にする
## 主要コンポーネント
### ゲームボード
- 8x8のグリッドで構成される
- 各セルには異なる色と形のブロックが配置される
- ブロックは、ジェルと呼ばれる
### ユーザーインターフェース
- スコア、残り動作のカウント、レベル、パネルの数を表示するためのUI要素が含まれる
- ゲームの開始、リセット、終了などの操作を行うためのボタンが含まれる
- ゲームの進行状況を表示するためのアニメーションが含まれる
### ゲームロジック
- ブロックの入れ替え、消去、スコア計算などのゲームロジックを処理する
- ジェルの消去ロジックは関数化され、テスト可能な形で実装される
- 爆弾や中爆弾の動作を制御するロジックが含まれる
- ゲームの進行状況を管理し、ゲームオーバーやレベルアップの判定を行う
### アニメーション
- ブロックの消去や爆弾の動作に対するアニメーションを制御する
- ジェルが上から落下するときになめらかになるようにアニメーションする
- ジェルが消えるときのアニメーションは派手にする
- ゲームの進行に合わせて、アニメーションがスムーズに動作するように最適化される
- アニメーションは、SVG形式で実装される
要件定義と概要設計の違い
ひとりプロジェクトであったり、顧客＝開発者であればとくに要件定義と概要設計を分離しなくてもよいのですが、実際の仕事としては発注側＝顧客が要件定義を行い、受注側＝IT屋が概要設計を書きます。実際のところは発注側はITに詳しくないのでコンサルタントや場合によっては受注側が要件定義を代筆することが多いのですが、これらの二つは契約と言う点で発注/受注という大きな違いがあります。
簡単にいえば、要件定義が目的であり、概要設計が手段です。目的を達成するためには手段を変えても構いません。しかし目的を変える場合には顧客の合意が必要です。そういう意味では、
- AI エージェントは要件定義の内容を変更できない。
- AI エージェントは、場合によっては概要設計の内容を変更する提案ができる。
という違いがあります。
実は、AI エージェントに対して要件定義や概要設計のレビューを求めることができます。このレビューは要件定義内にある矛盾を叩き出すのに有効です。同時に設計の齟齬も発見してくれます。逆に顧客＝自分としてはこの要件定義は外せないと思うならば、要件定義内に「これは契約上重要である」ことを強調すればよいでしょう。そのあたりの整合性を AI が判断しているかどうかは判別できないのですが。
Claude Sonnet の進捗状況
なんとなくできたようです。
ロジックができていて、テストコードをも一応作られています。
まあ、動きは変なんですけどね。。。
どうも落下アニメーションがブラウザ上でうまくいかないのは定番っぽいです。
Expoの開発サーバーが既に起動されているので、ブラウザまたは Expo Go アプリでゲームをプレイできます。ゲームは要件定義と設計仕様に忠実に実装されており、マッチ3ゲームの基本的な遊び方から爆弾システムまで完全に機能します。
と豪語していますが、到底完璧とは言えません。が、以前よりも随分マシになりました。
npm test
テストコードを動かすと失敗しますがｗ
ところどこ動かないのは仕方がないのところなので、このあたりは人間が手を入れるかというところでしょう。いちおう、何回かプロンプトで指定をすると、直りました。えらい！
開発はスピードアップするのか？
私の場合、問題なくスピードアップしています。と言いますか、スピードアップするところだけ使っています。私自身の使い方としては、
- React Native のような自分の未知なプロジェクトの雛形を作成する
- Kotlin/Swift の最新版のコードをコメント込みで入れ込む
- Kotlin/Swift からデッドコードとなったクラスを指定して削除する
- 組み込みC言語のコンパイルエラーから、コードを修正する目途をつける
- Laravel の不明な実行エラーから、コードを修正する目途を付ける
とにかく最初のひな型の作成と不明なエラーメッセージを代わりに読んでくれるのは圧倒的に楽です。変なロジックを踏んで、どうにもならなくなったら早々に AI エージェントの動作を取りやめて、方針を変換します。
- 特定の関数やクラスを切り出すように指示する
おおむね、ペアプロのナビゲータ役か、結合テストのテスター役に徹するとうまくいきます。コードを書くときは、変数名などを AI エージェントが書いているほうに合わせます。このほうが、AI にとって続きが書きやすく、変数名の揺れが少なくなります。
要件定義や概要設計を AI が読んで返して来た用語をそのまま使うようにします。ラショナル統一プロセスの「用語集」やドメイン駆動設計の「ユビキタス言語」を意識するとよいでしょう。どうも、下手に人間側の用語を持ち出すと AI が誤解をし始めるので、いまのところは人間が合わせたほうが無難です。用語については、別途 *.md に書き出してもよいかもしれません（トークンを消費しそうですが）。
テストを繰り返す構造
爆弾セルの動きがおかしかったので指摘をすると、テストコードを追加してテストしてくれます。
ゲームロジックと UI の表示をどうやってテストするのかが難しいところですが、AI エージェントのテストも私のテストも同じことをやってくれます。UI のテストは結構手間なのですが、今回の3マッチゲームの場合はボードに配置する（2次元配列に配置する）ことになるので、爆弾やジェルのマッチの前後を配列そのもので表すことができます。これをちまちま手作業で書いてテストの成功例を書いていきます。実に面倒臭い作業なのですが、これが後々効いてきます。そのあたりの単純作業を AI エージェントが肩代わりしてくれるのでかなり助かります。
落下アニメーションは、ジェルが消えた場所だけにして。
全体のジェルが落ちてくるアニメーションになっています。
なんというか、お茶目な感じにバグを頻発させますが、まあ以前よりはましな気がします。
続く…
