実践振り返り：Claudeを使ったゲーム用ローカルストレージ開発、1ヶ月のVibe Codingの所感

ここ1ヶ月、仕事でClaudeを使った高強度のVibe Coding（AIアシストプログラミング）を深く体験しました（個人プロジェクトではGeminiをずっと使っています）。ちょうど今月は会社から十分なAPI枠が付与されており、手元でゲームの新しいローカルアルバム保存機能の開発を担当していたためです。そこで開発スタイルを転換し、私が全体の要件とアーキテクチャ設計を担当し、Claude Opus 4.6をメインプログラマとしてコアコードを書かせることにしました。

1ヶ月の実践を経て得た最大の所感は、「要件が明確な場合、AIは最高の補助ツールになる。しかし、要件のイテレーションやバグ修正の段階では、人間のエンジニアの経験が依然として不可欠である」ということです。

要件が明確な場合、AIのコード完成度は極めて高い

プロジェクト初期の枠組み作りの段階では、明確な要件の境界さえ提供すれば、AIは期待通りのコードを迅速に出力してくれます。

例えば、ローカルアルバムファイルの完全性を処理する際、データ破損防止機能の実装を要求しました。Claudeはすぐに意図を理解し、SQLiteのWAL（Write-Ahead Logging）モードを完璧に参考にしました。一時ファイルの書き込み、アトミックな置換、クラッシュリカバリのロジックを正確に実装してくれました。この段階では、要件さえ明確であれば、AIは細部をうまく処理し、定型コード（ボイラープレート）を手書きする大量の時間を省いてくれます。

問題修正時、AIの限界が露呈する

しかし、プロジェクトが要件のイテレーションやバグ修正の段階に入ると、Claudeの限界が見えてきました。

AIの最大の弱点は、全体的なアーキテクチャの視点が欠如していることです。論理的な矛盾に遭遇した時のAIの第一反応は、対症療法的な「ツギハギ」です。システム全体の視点から新機能を統合するのではなく、無闇に新しいフラグ（Boolean）を追加したり、新しい if-else 分岐を作ったりしたがります。この時、AIの提案を完全に鵜呑みにすると、コードはあっという間に保守不能に陥ります。

典型的な失敗例：Texture2Dキャッシュの参照カウント

C#側でTexture2Dのキャッシュ参照カウント（Reference Counting）機能を開発している際、典型的な問題に遭遇しました。

この機能は主にアルバムのメモリを管理するためのものです。全体のアーキテクチャとして、Active（アクティブ）とInactive（非アクティブ）の2つのキャッシュ領域を設計しました。参照があればActiveに入れ、参照がなくなればInactiveに移し、いつでも破棄・クリーンアップできるように準備します。

結果として、非同期コールバックとキャッシュ参照の結合部分を処理する際にバグが発生しました。原因は、Claudeが「ページをInactive領域にプッシュしてから、参照をマークする」という誤ったタイミングのロジックを書いたことでした。これにより致命的な競合状態（レースコンディション）が発生します。もし現在の容量がちょうど上限に達していた場合、最初のステップでInactiveにプッシュされた直後にページが破棄されてしまい、その後の参照マークが完全に無効になってしまうのです。

このバグを修正するためにClaudeが出した解決策は、is_early_marked（早期マーク済み）というフラグを追加し、状態変数を増やすことでライフサイクルの問題を強引に回避しようとするものでした。

私はこの提案を即座に却下しました。全体的なライフサイクルの理解に基づき、AIに明確な指示を出し直しました。「Inactiveページの全体チェックとクリーンアップ実行のフェーズを遅延させ、必ず非同期処理による参照マークの『後』に発生するように保証せよ」と。全体的な実行タイミング（時系列）を調整することで、冗長で汚いフラグを一切追加することなく、問題はすっきりと解決しました。

まとめ

今回の経験から、AIはコーディング効率を大幅に向上させる一方で、アーキテクチャ上の隠れた問題を覆い隠しやすいことが証明されました。

もし経験の浅いエンジニアが上記の並行処理のバグに遭遇したら、高確率でClaudeの提案をそのまま採用していたでしょう。そうなれば、フラグや分岐が増え続け、最終的にモジュールは完全に制御不能なスパゲッティコードになってしまいます。Vibe Codingのスタイルでは、具体的な細部を自分で書く必要はありませんが、全体的なアーキテクチャの視点と、クソコードを防ぐための経験は、引き続き人間の開発者が死守しなければなりません。