スクラムでベロシティ（1スプリントで消化できる作業量の指標）を測っているチームのなかには、AIコーディングエージェントの登場で見積もりの前提が揺らいでいると感じている方もいるかもしれません。この記事では、開発者がClaude Code for web（ブラウザやスマホアプリから使えるAnthropicのAIコーディングエージェント環境）に対して、ゲームを丸ごと一発生成させた事例をもとに、見積もりと技術的負債の関係を整理します。
題材になっているのは「Raccoon Heist（アライグマ強盗団）」というゲームです。2022年にGPT-3とDALL-Eで作ったコンセプト画像とテキストを、4年後にClaude（開発コード名Fable 5）に渡し「これを3Dゲームとして作って」と指示しただけで、実際に遊べるブラウザゲームが完成しています。開発者は途中で技術選定に一切口を出さず、Three.js（ブラウザで3D描画をするJavaScriptライブラリ）の採用もエージェントが自律的に決めています。
何が起きたのか：指示は1回、判断はエージェント任せ
与えられたプロンプト（AIへの指示文）は、要点を絞ると次の3つでした。1つ目は「静的ファイルを配信できるようindex.htmlを用意すること」。2つ目は「OpenAIの画像生成API（gpt-image-2）をテクスチャ生成に使ってよいこと」。3つ目は「デザインの判断を都度確認せず、自律的に進めること」です。
ここで注目したいのは「Work independently — do not ask me to make any further design decisions（自律的に進めろ、デザイン判断を追加で聞くな）」という一文です。これは人間のマネージャーが新人エンジニアに丸投げするのとは違います。エージェントは技術選定・画像生成・ゲームバランス調整までを、コミット履歴とnotes.mdという作業ログファイルに記録しながら進めています。
作業の可視化のために使われた工夫も実践的です。GitHubリポジトリの設定画面（Settings→Pages）で「Deploy from a branch」を選び、エージェントが作業するブランチを指定するだけで、プッシュから約30秒後にGitHub Pages上で最新の成果物を確認できます。これはCI/CDのプレビュー環境を毎回手動で構築するコストをゼロにする、地味だが効果の大きいテクニックです。
段階的に見る：何が「一発生成」を支えているか
一発生成が成立する条件を分解すると、3つの要素が見えてきます。
1つ目は「曖昧な入力を許容する指示設計」です。渡されたのは詳細仕様書ではなく、4年前のツイート1本と画像2枚だけでした。厳密な要件定義がなくても、エージェントが妥当な解釈で補完しています。
2つ目は「外部APIへのアクセス権限の付与」です。OpenAIの画像生成APIキーを渡すことで、Claude自身が持たない画像生成能力を補っています。これはマイクロサービス構成でチーム外のAPIを呼び出す設計判断に近く、エージェントに「何を任せ、何を外部化するか」という線引きが必要になる点は人間のアーキテクチャ設計と変わりません。
3つ目は「進捗の可視化を仕組み化したこと」です。コミットのたびにnotes.mdへ変更点を追記させる指示により、後から見ても「なぜこの実装になったか」が追える状態になっています。これはコードレビューの代替にはなりませんが、スプリントレビューで説明責任を果たすための材料にはなります。
見積もりとの付き合い方：ベロシティは測れるのか
ここでスクラム運用の観点に戻ります。従来のストーリーポイント見積もりは「人間の実装速度」を前提にしています。ところが一発生成のようなワークフローでは、実装フェーズの所要時間が数十分〜数時間単位まで圧縮される場面があります。これはベロシティという指標そのものの意味を問い直す動きにつながります。
ただし気をつけたいのは、「一発生成できた」という事実と「本番品質に達している」という事実は別だという点です。今回の題材はプロトタイプ的なブラウザゲームであり、認証・決済・複数ユーザーの同時アクセスといった、業務システムで避けて通れない要件は含まれていません。見積もりの土台を変えるべきかどうかは、対象プロダクトの複雑度次第で判断が分かれます。
技術的負債の観点でも整理が必要です。エージェントが自律的に選んだ技術スタックやコミット粒度は、人間のレビュー文化と噛み合わない場合があります。たとえばコミットメッセージが作業ログとして書かれていても、チームの規約に沿ったConventional Commits形式になっていなければ、後からリリースノートを自動生成するCIツールと相性が悪くなることも考えられます。一発生成の速さを評価するときは、「生成にかかった時間」だけでなく「チームのレビュー・保守フローに乗るまでの追加コスト」も合わせて見る必要があります。
今日から確認できること
チームでAIエージェントの活用を検討しているなら、次の点をまず確認してみてください。
- 使っているAIコーディングエージェントが、GitHubブランチへの自動コミット・プッシュに対応しているか（Claude Code for webはブランチ単位で作業ログを残せます）
- プレビュー環境の構築コストがボトルネックになっていないか。GitHub Pagesの「Deploy from a branch」設定は静的サイトなら数分で試せます
- スプリントの見積もり単位が「実装時間」に寄りすぎていないか。設計判断・レビュー・受け入れ確認にかかる時間を分けて計測できているか
- エージェントに自律的な判断を任せる範囲を、あらかじめチームでどこまで許容するか合意できているか
特に3つ目は見落とされがちです。実装が速くなっても、レビューと受け入れ確認の工数は減らないケースが多く、ベロシティの分子だけが変わって分母（レビュー負荷）が変わらない状態になりがちです。
まとめ
Claude Code for webによる一発生成の事例は、実装速度が劇的に変わりうることを具体的に示しています。ただしそれはストーリーポイントの単純な圧縮を意味するのではなく、見積もりの内訳（実装・レビュー・受け入れ確認）を分けて捉え直す機会と考えるのが実務的です。
まず自分のチームで試せることとして、静的サイトやプロトタイプ的な機能を対象に、GitHub Pagesを使ったプレビュー環境の構築を試してみてください。そのうえで、エージェントに委ねる判断範囲とレビュー基準を、次のスプリント計画で一度言語化してみることをおすすめします。