100日間アプリを作り続けるチャレンジをしてる。(現在進行中)
【Day54】とにかく派手なオセロを作った。仕様はGeminiで、エフェクトはClaudeという棲み分けがよかった。#LLMでバックエンド100日チャレンジ#100DaysOfCode pic.twitter.com/vWQSFqcAVm
— riddle@MIXI (@riddle_tec) 2025年6月7日
【Day37】CHIP-8 という昔の仮想マシンのエミュレーターを作ってゲームを動かしてみた。その界隈ではシンプルさで有名らしいのだが、gemini2.5だけではうまくいかず o3 も強力しなんとか動かすところまでいったのは感慨深い。#LLMでバックエンド100日チャレンジ#100DaysOfCode pic.twitter.com/I8G0aP4pMk
— riddle@MIXI (@riddle_tec) 2025年5月20日
Xで毎日流してる。
今まで作ったもの一覧はここ
今回はそんなチャレンジを通じて見つけた 「うまくいかなかったこと」 を紹介する。
※Cursor を使ってるので Cursor ベースの困りごと
めちゃくちゃ細かく指示をした
初日は勝手が分かってなかったので Go でAPIサーバを作り、NextJS でフロントエンドをいく構成を考えていた。 一般的なアプリのように OpenAPI Schema を作り、ogen で Go のハンドラーを作成。
クリーンアーキテクチャに寄せて usecase / domain / repositoryを作る。また sqlc でDTOやクエリを管理。テストは ginkgo を使う。フロントは最新の React を使い React Hooks で状態管理、CSS は tailwind CSS を使うことという感じでしっかりと規定した。
その結果全然うまくいかなかった。
上記の構成は自分が新規でプロダクト作るときに選ぶかなーというある程度理にかなった構成だったのだが、LLMにとってはさまざまなことを実施しなければならず非常に複雑だった様子。例えば API を作る際に
- OpenAPI のスキーマを作成
- ogen でハンドラーファイルをつくる
- ハンドラーを正しく実装
- DB スキーマを作成し go generate
- sqlc にクエリを書いてコード生成
- それを組み合わせて usecase / repository を作成
という流れだ。色々やらせすぎじゃないか?という意見はごもっともなのだが、過去の人間の開発ではとてもうまく行っていた。だから同じ感覚でやろうとしたらてんでダメだった。
これが初日につくった TODO アプリ。しょぼい、しょぼすぎる。
これにこりて、次の日からは NextJS + Prisma + SQLite + TailwindCSS
だけにした。
そうしたら早いこと早いこと。次の日からこの構成にした。
※ちなみにいまは Prisma も使わず雑にクエリ叩いてる
複雑すぎるものの開発
100日チャレンジでは何度も完成ができず失敗したものがある。
- 【失敗】100日チャレンジ day19 (OIDC/OAuthのIDaaS基盤)
- 【失敗】100日チャレンジ day39 (Kubernetes Manifest Language Server)
- 【失敗】100日チャレンジ day42(自作OS)
自分の知見のなさ放っておくと、これらの失敗の共通点は複雑だということ。またテストがしづらいということ。もちろんやり方によってはうまくテストできるのだろうが、当時はそこにあまり頭が働かなかった。
このとき使っていたのは Gemini2.5 Pro。他の日はうまくいっただけに、この失敗は限界を感じた瞬間だった。(TCP/IP や RDBMS は作れていたので、これらはダメなのかーという感じだった)
しかし Claude Sonnet 4 の登場によりこれらは作れるようになるのである。(進化スピードが早い)
長いコードの修正
現在私が使っているルールでは以下のルールを入れている。
`edit_file` 効果的な利用ガイドライン 大規模ファイル (> 300-400行目安) や複雑な変更 (複数箇所、広範囲リファクタリング) で `edit_file` が失敗することがあります。以下を試してください: 1. **スコープ限定:** 指示は「関数 `X` を修正」「構造体 `Y` を変更」のように具体的に限定する。 2. **変更量削減:** 複数の変更は、関連性の高い1-2個ずつ複数回の `edit_file` に分割する。 3. **適切なコンテキスト:** 変更箇所の特定に必要な最小限の周辺コード (`// ... existing code ...` の前後) を含める。 4. **(根本対策) ファイル分割:** 可能であれば、ファイルをより小さく機能的に分割する。
これは400行を超えるコードを修正させると コードの編集がうまくいかず最終的に人力でやる羽目になるから である。そのためあらかじめコードの行数を予測させてファイルを分割させると言った手法を使っていた。
これは Gemini2.5pro のロングコンテキストの場合でも発生していたので、他の LLM ではよりクリティカルな問題かもしれない。またチャットが一定以上長くなった場合は、新規のチャットを開き続きから作業をさせるという方式で誤魔化していた。
とにかく止まる
これに関しては今のところ解決策がない。 Cursor なんとかしてくれ〜〜。
修正に失敗しすぎてコードベースを壊す
AI Agent が暴走しだして指示してないことをしだしたり、うごいていたコードを壊すことがまあまあある。 ということでうちでは定期的に AI Agent をリセットしている(New Tab してるだけ)
このとき、直前の作業をやらせたいので PROGRESS.md
というファイルを作り進捗を管理させている。
`# Day 65 - WebGL CPU対戦ババ抜きゲーム 開発進捗 ## 開発工程 Progress ### ✅ Step 1/10: プロジェクト初期化 - [x] templateからプロジェクトコピー - [x] package.json の name フィールド更新 - [x] README.md 更新(アプリケーション設計) - [x] PROGRESS.md 作成 - [x] 基本レイアウト確認 **完了日**: 2024/12/XX **学習ポイント**: プロジェクト構成、設計ドキュメント作成 --- ### ✅ Step 2/10: Three.js環境構築 - [x] Three.js、React Three Fiber、drei をインストール - [x] 基本3Dシーン設定(カメラ、ライト、レンダラー) - [x] テーブル環境構築(3D空間配置) - [x] 動作確認(基本3D表示) **完了日**: 2024/12/XX **学習ポイント**: WebGL、Three.js基礎、3D座標系、Canvas設定 --- ### ✅ Step 3/10: ババ抜きコアロジック実装 - [x] カードデータ構造設計(スート、数字、ジョーカー) - [x] デッキ生成・シャッフル機能 - [x] 手札管理機能 - [x] ペア判定・除去ロジック - [x] ゲームフロー制御 - [x] 基本テスト実装 **完了日**: 2024/12/XX **学習ポイント**: ゲームロジック設計、データ構造、TypeScript型安全性 --- ### ✅ Step 4/10: 3Dカード表示システム - [x] カード3Dジオメトリ作成 - [x] カードテクスチャ・マテリアル - [x] 手札配置システム(4方向配置) - [x] カード表示・非表示制御(裏向きカード実装) - [x] ホバー・選択エフェクト - [x] プレイヤー手札統合 - [x] UI表示修正(邪魔な背景削除) **完了日**: 2024/12/12 **学習ポイント**: 3Dジオメトリ、Three.js コンポーネント、空間配置、アニメーション、条件付きレンダリング --- ### 🔄 Step 5/10: AIシステム実装 - [ ] AI基底クラス設計 - [ ] やさしいAI(ランダム選択) - [ ] ふつうAI(基本戦略) - [ ] つよいAI(高度戦略・確率計算) - [ ] AI思考シミュレーション **予定学習ポイント**: ゲームAI、確率計算、戦略アルゴリズム --- ### ⏳ Step 6/10: ゲーム進行制御 - [ ] ターン管理システム - [ ] ゲーム状態遷移 - [ ] プレイヤー順序制御 - [ ] 勝敗判定システム **予定学習ポイント**: 状態管理、ゲームフロー制御 --- ### ⏳ Step 7/10: プレイヤーUI実装 - [ ] 手札選択UI - [ ] ゲーム状況表示(ターン、手札数等) - [ ] 操作ガイド表示 - [ ] 難易度選択UI **予定学習ポイント**: React統合、ユーザーインタラクション --- ### ⏳ Step 8/10: アニメーション・演出 - [ ] カード配布アニメーション - [ ] カード選択ハイライト - [ ] カード受け渡しアニメーション - [ ] ペア消去エフェクト - [ ] パーティクルシステム **予定学習ポイント**: 3Dアニメーション、パフォーマンス最適化 --- ### ⏳ Step 9/10: E2Eテスト・デバッグ - [ ] 各AI難易度での動作確認 - [ ] エッジケースのテスト - [ ] パフォーマンス最適化 - [ ] Playwrightでの自動テスト **予定学習ポイント**: テスト設計、パフォーマンス分析 --- ### ⏳ Step 10/10: ドキュメント更新 - [ ] README最終更新 - [ ] .cursor/rules/knowledge.md更新 - [ ] コードコメント整理 - [ ] 最終デバッグ・クリーンアップ **予定学習ポイント**: ドキュメンテーション、プロジェクト総括 --- ## 技術的な課題・学び ### WebGL / Three.js - 3D数学(ベクトル、行列、座標変換) - レンダリングパフォーマンス - メモリ管理 ### ゲーム開発 - リアルタイム状態管理 - アニメーションタイミング - AI思考アルゴリズム ### React 統合 - Three.js と React の組み合わせ - 3D インタラクション - パフォーマンス最適化 --- **目標**: フロントエンド技術だけで本格的な3Dゲーム体験を実現し、WebGLの可能性を最大限活用する
各ステップごとにテストを実施させ成功したらコミットし次に進むようにしているので、なにかおかしなことをしだしたら即 git reset --hard
をして戻し AI Agent を初期化し作業の続きを実施させている
さいごに
いずれも実際にやってみないとわからない問題。ただこれはそのうち解消されるだろう。なのであんまり気にする必要はないが、現在地を知る意味ではいいんじゃないだろうか。