ゲーム開発者のAI活用術：2,165メッセージの記録から見る実戦データ（47日間の記録）
- ゲーム開発者のAI活用術：2,165メッセージの記録から見る実戦データ（47日間の記録）
- Claude Opus 4.5 → 4.6 移行期 - ゲーム開発者が体感した性能、トークン、ワークフローの変化
- AGENTS.mdは本当に役に立つのか？ — コーディングエージェントのコンテキストファイルの有効性を検証した論文分析
- Claudeメモリ無料開放と/simplify、/batch — そしてCLAUDE.mdの隠れたコスト
- WindowsでClaude Codeをインストールする完全ガイド — 実践トラブルシューティング付き
- ゲームプランナーのためのClaude Code完全活用ガイド — 仕様書からバランシングまで
- macOSでClaude Code C# LSPを完全セットアップするガイド — csharp-lsのインストールからトラブルシューティングまで
- C# LSP vs JetBrains MCP トークン効率分析 — Claude Codeで最適なツール選択戦略
- 47日間で305セッション、2,165メッセージ — ゲーム開発者がAIコーディングエージェントを実務に投入したリアルなデータを公開
- Claude Codeを「ペアプログラマー」ではなく「技術分析官」として活用することで、メモリリーク調査やギャップ分析（Gap Analysis）などの調査・分析業務で圧倒的な効率を発揮する
- マルチエージェントチームへの委譲、JetBrains MCP統合などの高度なワークフローの成果と限界をデータでまとめた
はじめに
2026年1月5日、UnityモバイルゲームプロジェクトにClaude Codeを本格導入した。「AIがコードを書いてくれる」というマーケティング的な謳い文句ではなく、実際にプロダクションのコードベースで47日間使用した定量的なデータを共有する。
多くのAI活用記は「便利だった」「凄かった」といった主観的な感想に留まりがちだ。この記事は、Anthropicが提供するClaude Code Insights（実際のセッションログを分析したレポート）に基づき、数字が語るストーリーを紐解いていく。
このポストのすべての数値は、Claude Code Insightsレポート（2月13日版、2月20日版）から直接抽出したものである。
1. 47日間の数字の要約
全体の使用量推移
2つの時点のインサイトレポートを比較すると、使用パターンの変化が明確に見える。
| 指標 | 2/13 (26日目) | 2/20 (33日目) | 増加率 |
|---|---|---|---|
| 総メッセージ数 | 1,246 | 2,165 | +74% |
| セッション数 | 172 | 305 | +77% |
| コード追加行数 | +28,556 | +56,323 | +97% |
| コード削除行数 | -1,792 | -2,729 | +52% |
| 修正ファイル数 | 188 | 396 | +111% |
| 1日平均メッセージ数 | 47.9 | 65.6 | +37% |
わずか7日間でメッセージ数が74%増加した。単に「より多く使った」だけでなく、1日平均のメッセージ数が47.9から65.6に上がったという点が重要だ。ツールに慣れるにつれ、活用密度そのものが高まったのである。
依頼した作業タイプ
| 作業タイプ | 2/13 | 2/20 |
|---|---|---|
| バグ修正 | 5 | 14 |
| コード実装 | 10 | 11 |
| デバッグ | 7 | 10 |
| コード分析 | 7 | 10 |
| 機能実装 | - | 9 |
| コード調査 | 6 | 6 |
初期はコード実装の依頼が多かったが、後半になるにつれてバグ修正とデバッグの比重が大きく増加した。これはプロジェクトが開発段階から安定化段階へと移行する自然な流れを反映している。
2. どこで最も活用されたか
プロジェクト別セッション分布
1
2
3
4
5
Unity Skill Studio Editor Tooling ████████████████████████████████████ 35 sessions
Unity Runtime Bug Fixes & Debugging ████████████████████ 20 sessions
Unity Memory Leak & Crash Investigation ██████████████████ 18 sessions
Technical Documentation & Content Writing ███████████████ 15 sessions
iOS Build & Platform Issues █████ 5 sessions
エディタツール開発が圧倒的1位だ。Unityエディタ用のSkill Studioツールを作りながら、レシピシステム、ドラッグ＆ドロップのグラフビューア、ローカライゼーション、CSVエクスポート、武器比較ツールなど、多様な機能を実装した。単一のセッションで22個のファイルを同時に修正したこともある。
次に多かったのがランタイムバグの修正だ。ボスHPバーのUIタイミングの問題、仮想スクロールセルのonClickリスナーの累積、オブジェクトプールのオーバーフロー戦略、Galaxy A41のフリーズ問題など、実際のモバイルゲームで発生する厄介なバグを追跡した。
最も使用されたツール Top 6
| ツール | 呼び出し回数 | 用途 |
|---|---|---|
| Read | 1,716 | ファイル読み込みとコード分析 |
| Bash | 1,206 | コマンド実行、git履歴調査 |
| JetBrains get_file_text | 1,153 | IDE統合ファイル読み込み |
| JetBrains replace_text | 897 | IDE統合コード修正 |
| Edit | 888 | 直接ファイル編集 |
| JetBrains search_in_files | 870 | プロジェクト全体の検索 |
ここで注目すべき点は、Read (1,716) が Edit (888) のほぼ2倍であることだ。コードを書くことよりも、読むことに遥かに多くの時間を費やしている。これは私がClaude Codeを活用する際のコアパターンに直結している。
3. 核心的な発見：「ペアプログラマー」ではなく「技術分析官」
Claude Code Insightsが分析した私の使用パターンの核心はこれだ：
「あなたは技術チームリードとして行動し、Claudeに対して構造化された調査および実装タスクを正式なレポートと共に割り当て、アプローチが特定の期待から逸脱した場合には決定的な介入を行う。」
私はClaudeを「一緒にコーディングする同僚」としては使わない。構造化された調査・分析業務を委譲し、報告を受けるチームリードとしての役割を担っている。305セッションのうち、コミットはわずか9回だ。ほとんどの時間は、Claudeが数十のファイルを読み、分析し、構造化されたレポートを作成することに費やされている。
このパターンが効果的な理由
1. メモリリーク調査が代表例だ
DOTweenシーケンスのリーク、UniRxの購読解除漏れ、Addressableアセットの破棄、delegate/closureの保持パターンを体系的に調査した。Claudeは数十のファイルを巡回してリーク経路を追跡し、優先度別に構造化されたレポートを作成した。
人間がこの作業を行うと？GameResultLayer一つのライフサイクルを追跡するだけで半日かかる。Claudeは関連ファイル全体を読み、.AddTo()の呼び出し漏れやOnDestroyでのクリーンアップ不足といったクリティカルな問題を一つのセッションで特定した。
2. ギャップ分析（Gap Analysis）を品質ゲートとして活用した
Plan（計画）文書に対する実際の実装の完成度を比較するギャップ分析を繰り返し実行した。少なくとも7つのセッションで同様のパターンを使用：
- Plan文書の読み込み
- コミット/実装ファイル全体の読み込み
- 要件別に Completed / Partial / Missing に分類
- 構造化されたレポートの出力
このワークフローのおかげで、実装漏れを早期に発見することができた。
3. マルチエージェントチームのオーケストレーション
Claude Codeのエージェントチーム機能を活用し、複雑なマルチファイル作業を並列で処理した。4つのタスク領域で22個のファイルを同時に修正したり、DOTween/UniRx/メモリリーク調査を複数のエージェントに同時委譲したりした。
| 指標 | 2/13 | 2/20 |
|---|---|---|
| 並列セッションオーバーラップイベント | 57 | 92 |
| 関与セッション数 | 56 | 111 |
| 全メッセージ中の比重 | 15% | 15% |
4. 成果：数字が語ること
達成率の変化
| 結果 | 2/13 (50セッション) | 2/20 (98セッション) |
|---|---|---|
| 完全達成 (Fully Achieved) | 32 (64%) | 58 (59%) |
| ほぼ達成 (Mostly Achieved) | 7 (14%) | 19 (19%) |
| 部分達成 (Partially Achieved) | 7 (14%) | 15 (15%) |
| 未達成 (Not Achieved) | 2 (4%) | 5 (5%) |
完全達成率が約60%、ほぼ達成まで含めると約78%だ。どんなプログラマーを雇用しても、これだけの数字が出れば十分に生産的と言える。
Claudeが得意なこと
| 能力 | 回数 |
|---|---|
| マルチファイルの同時変更 | 36 |
| 質の高い説明/分析 | 21 |
| デバッグ | 20 |
| 高速で正確な検索 | 10 |
| 正確なコード修正 | 4 |
マルチファイルの変更が圧倒的1位だ。これは人間が行うとミスをしやすい作業である。10個のファイルでenumの値を変更したり、ネームスペースをリファクタリングしたり、ローカライゼーションキーを一括で入れ替えたりする作業において、Claudeは真価を発揮する。
5. 限界：正直な話
データは長所だけを示しているわけではない。Claude Code Insightsの「Where Things Go Wrong」セクションは、かなり率直だ。
摩擦（Friction）タイプの分析
| 摩擦タイプ | 2/13 | 2/20 |
|---|---|---|
| 誤ったアプローチ (Wrong Approach) | 11 | 21 |
| バグのあるコード (Buggy Code) | - | 9 |
| ユーザーによる拒否 (User Rejected) | 6 | 7 |
| 過度な変更 (Excessive Changes) | 2 | 6 |
| 要請の誤解 (Misunderstood) | 3 | 5 |
| 無応答 (Unresponsive) | 3 | 3 |
「誤ったアプローチ」が21件で、最多の摩擦原因となっている。具体的には：
事例 1：コードレビューアーの批判に同調するClaude
オブジェクトプールのオーバーフロー戦略に関するコードレビューアーのコメントを評価するよう求めた。Claudeはレビューアー側に立ち、私のフォールバックロジックに問題があると指摘した。しかし、そのデザインは意図的なものであり、私はClaudeに「そのコードはわざとそのように書いたのだ」と説明しなければならなかった。
AIが、コードを書いた本人よりもそのコードをよく知っていると錯覚する瞬間がある。
事例 2：ボスHPバーのnullリターン値の変更
ボスHPバーの修正中、Claudeがnullリターンの値を 0f から 1f に変更した。このままリリースされていれば、ボスが死んだときにHPが満タンで表示されるというリグレッションが発生していただろう。コードレビューで発見できたから良かったものの、Claudeの最初の修正はしばしば論理的な誤りを含んでいる。
事例 3：クライアントだけでいいのにサーバーまで調査
ゲームの再開（resume）機能の分析を依頼した際、Claudeがサーバーサイドのコードまで調査し始めた。二度も「クライアントだけを見てくれ」とリダイレクトしなければならなかった。明示的なスコープの制約を与えないと、不要な探索に時間を浪費してしまう。
マルチエージェントチームの現実
データの中で最も失望した部分である：
- エージェントがアイドルループに陥り無応答状態になる → 代わりのエージェントを新しく生成する必要がある
- エージェントが生成したコードにネームスペースのインポート漏れがある → 直接コンパイルエラーを報告して修正を依頼する必要がある
- チームリードとしてのステータス報告依頼にエージェントが応答しない → 繰り返しエスカレーションが必要
シングルエージェントセッションの成功率（40件中32件が完全達成）に比べ、マルチエージェントセッションは明らかに不安定だった。現状では、大きなタスクを順次的なサブタスクに分割する方が、並列なエージェントチームよりも安定している。
満足度の変化
| 満足度 | 2/13 | 2/20 |
|---|---|---|
| 挫折 (Frustrated) | 2 | 2 |
| 不満足 (Dissatisfied) | 11 | 19 |
| おおむね満足 (Likely Satisfied) | 56 | 95 |
| 満足 (Satisfied) | 5 | 9 |
おおむね満足以上が83%である。しかし、不満足も19件と少なくない。これがAIツールの現実だ。上手くいくときは本当に凄いが、失敗したときの収拾コストもそれなりにかかる。
6. 使用パターンの深層分析
時間帯別の使用量
1
2
3
4
Morning (06-12) ████████████████████ 564
Afternoon(12-18) █████████████████████████████████████████████ 1,268
Evening (18-24) ████████████ 333
Night (00-06) 0
午後の時間帯に集中的に使用している。深夜のコーディングはない。午前中に方向性を定め、午後にClaudeと集中的に作業するパターンだ。
応答時間の分布
| 区間 | 回数 | 備考 |
|---|---|---|
| 2-10秒 | 102 | 素早い確認/承認 |
| 10-30秒 | 181 | 短い指示 |
| 30秒-1分 | 163 | 結果を確認してフィードバック |
| 1-2分 | 157 | 詳細な検討 |
| 2-5分 | 160 | 深い分析結果の検討 |
| 5-15分 | 162 | 他の作業を並行 |
| 15分以上 | 91 | 長時間の分析待ち |
応答の中央値は81.2秒、平均は292.6秒。10秒以内の応答ではなく、1〜5分台の応答が最も多いことは、Claudeの出力を入念にチェックしてフィードバックを与えるパターンを示している。盲目的に受け入れているわけではないという証拠だ。
言語別の作業分布
| 言語 | ファイル数 | 備考 |
|---|---|---|
| Markdown | 897 | ドキュメント、プラン、ブログ |
| HTML | 136 | Jekyllテンプレート |
| JSON | 61 | 設定ファイル |
| YAML | 33 | Front matter, CI/CD |
| Python | 18 | スクリプト |
| Shell | 9 | 自動化 |
Markdownが圧倒的に多い理由は、技術ドキュメント、Plan文書、ギャップ分析レポートのためだ。実際のUnity C#コードの作業は、JetBrains MCPを通じてIDE内で直接修正するため、別途言語カウントには計上されない。
7. 私のワークフロー：こう使うと効果的だ
47日間の試行錯誤で確立したパターンをまとめる。
パターン 1：調査 → レポート → 実行（3段階の分離）
1
2
3
4
5
6
7
8
9
10
セッション 1：調査および分析（Claudeがコードベース全体を読みレポート作成）
└─ 出力：構造化されたレポート（優先度別の問題リスト）
セッション 2：レポートに基づく実装（特定の課題を修正）
└─ 入力：セッション 1のレポート
└─ 出力：コードの変更 ＋ コンパイル確認
セッション 3：ギャップ分析（Planに対する実装の完成度を検証）
└─ 入力：Plan文書 ＋ 最新のコミット
└─ 出力：Completed/Partial/Missingレポート
一つのセッションで調査から実装まで全てやろうとすると、Claudeが方向性を見失いやすい。役割を明確に分けることが核心だ。
パターン 2：明示的なスコープ制約
1
2
3
4
❌ 「GameResultLayerのメモリリークを分析して」
✅ 「GameResultLayer.csファイルのクライアントコードだけを分析して。
サーバーコードは無視すること。DOTweenのKill()忘れとUniRxのAddTo()
忘れに集中して、P0/P1/P2に分類して」
この一行の差が、不要なサーバーコードの探索にかかる30分を節約する。インサイトデータにおける「Wrong Approach」21件の多くは、スコープを指定しなかったことに起因している。
パターン 3：JetBrains MCP統合の活用
Claude Code ＋ JetBrains IDEをMCP (Model Context Protocol) で繋ぐと：
replace_text_in_file(897回) — IDE内で直接コードを修正get_file_problems(671回) — 修正直後にコンパイルエラーを確認search_in_files(870回) — プロジェクト全体をインデックスベースで検索
ターミナルで grep を使うのとは次元が違う体験だ。IDEのコード分析エンジンをClaudeが直接活用するため、ネームスペースの不足や型不一致などのコンパイルエラーをリアルタイムで検出できる。
8. 今後の方向性：インサイトが提案するもの
Claude Code Insightsは、単なる統計を超えて改善の方向性まで提示してくれる。
自律的なギャップ分析〜実装パイプライン
現在は「ギャップ分析 → 人間がレポートを確認 → 実装セッション開始」という手動の引き継ぎがある。これを一つの自律ワークフローに統合できる：
1
2
コミット分析 → ギャップの特定 → 優先タスクリストの生成
→ エージェントによる自動修正 → コンパイル検証 → 繰り返し
Self-Healing マルチエージェントチーム
エージェントの無応答問題を解決するためのウォッチドッグ（Watchdog）パターン：
- 各エージェントの応答タイムアウトを監視
- 無応答時に自動で予備エージェントを生成
- コンパイル検証をゲートとして使用
継続的メモリリーク・スキャニング・エージェント
10回以上のメモリリーク調査セッションで蓄積されたパターン（DOTweenのKill忘れ、UniRxのAddTo忘れ、OnDestroyでの未処理など）をコード化し、PRごとに自動でスキャンするエージェントを作ることができる。
9. ゲーム開発者への実践的アドバイス
47日間のデータから導き出した実践的なアドバイスだ。
Claude Codeが特に強い領域
- メモリリーク/クラッシュ調査 — 数十のファイルを巡回してリーク経路を追跡する調査作業
- マルチファイルのリファクタリング — enumの変更、ネームスペースの整理、ローカライゼーションキーの一括置換
- ギャップ分析（Gap Analysis） — 計画書に対する実装の完成度を体系的に検証
- コード分析/説明 — 複雑なレガシーコードの動作を把握し、構造化された説明を生成
Claude Codeが弱い領域
- 最初の修正の正確性 — 論理的なエラー、誤った実行順序、エッジケースの考慮不足が頻繁に発生
- マルチエージェントの安定性 — 無応答、アイドルループ、インポート漏れなどの不安定さ
- スコープの判断 — 明示的な制約がないと、不要な領域まで探索して時間を浪費
- ドメインの意図把握 — 意図的なデザイン決定を「バグ」と誤認する場合がある
導入前のチェックリスト
- コードレビューは必須 — Claudeの出力を無検証でマージしてはいけない
- スコープを明示せよ — 「クライアントだけ」「このファイルだけ」「このパターンに集中」など具体的な制約を与える
- 調査・分析業務にまず活用せよ — コードを書くよりも、コードを分析する方がROIが高い
- JetBrains MCP統合を活用せよ — IDEのコード分析エンジンと接続することで、生産性が大幅に向上する
- セッションを役割別に分けよ — 調査 / 実装 / 検証を一つのセッションに詰め込まない
おわりに
2,165件のメッセージ、305件のセッション、56,323行のコード追加。これらの数字が語ることはシンプルだ。AIコーディングエージェントは、すでに実務で有意な生産性を提供しているが、「魔法」ではない。
60%の完全達成率と21件の誤ったアプローチは共存している。Claudeを「コードを書いてくれる魔法使い」ではなく、「体系的に管理すべき有能なジュニア分析官」として見れば、期待値と現実の間のギャップは埋まるだろう。
ゲーム開発におけるAIツールの未来は明るい。ただし、その明るい未来は「AIが勝手にやってくれること」ではなく、「開発者がAIを効果的に指揮する方法を身につけること」にかかっている。
また47日後に、新たなインサイトを共有したい。
このポストに使用されたデータは、Claude Code の Insights 機能から生成されたレポートに基づいています。Claude Codeは、AnthropicによるCLIベースのAIコーディングエージェントです。