結論
Claude Codeのサブエージェントは、メインの会話とは別のコンテキストで動く作業担当のAIで、並列で複数動かすこともできる。日本語の仕様書だけ渡して動体視力テストのゲームを作らせたら、約13分で750行が完成し、検収でのバグはゼロだった。1本目のゲームで見つけたバグの再発防止と「統計値を捏造しない」ルールを仕様書に最初から織り込んだことが決め手で、機能の使いこなしより仕様書の質が結果を分ける。失敗の記録は、次の発注書の材料になる。
13分で1本完成、検収バグゼロ。ただし手柄は仕様書にある
先に結論から。Claude Codeのサブエージェント——メインの会話とは別のコンテキストで動く「作業担当のAI」——に日本語の仕様書だけを渡して、ブラウザで遊べるミニゲームを1本丸ごと作らせた。かかった時間は約13分。新規2ファイルと既存3ファイルの変更、あわせて750行。型チェック(tsc)もビルドも一発で通り、公開前の検収で見つかったバグはゼロ。その日のうちに公開した。
約1ヶ月前、同じ体制で作った1本目のゲームでは、検収で本物のバグが1件見つかっている。今回ゼロになったのは、AIが急に賢くなったからではないと思う。1本目の失敗を、今回は仕様書に最初から織り込んだからだ。サブエージェントという機能の解説記事は、もう世の中にある。だからこの記事は解説ではなく、コードを書かない私がこの機能をどう使い、仕様書に何を書いたら結果がどう変わったか、の実録にする。
Claude Codeのサブエージェントとは?
サブエージェントは、開発ツール型AI「Claude Code」の機能のひとつで、メインの会話とは別のコンテキストで動く作業担当のAIだ。私のたとえで言えば「別の部屋で働いてもらう同僚」。窓口のAIと相談している会話はそのまま汚さずに、重たい作業だけを別の部屋へ運んで任せられる。部屋は同時にいくつも開ける、つまり並列で複数動かせる。
私はコードを書けない。だからClaude Codeを窓口(現場監督役)に据えて、実装や執筆のような実作業はサブエージェントに委譲する体制で回している。窓口の会話が作業ログで埋まらないので、こちらは相談と判断に集中できる。
ひとつ癖がある。サブエージェントからは、メインの会話の履歴が見えない。「さっき話したアレ」が通じない相手なのだ。依頼文は初対面の人に渡すつもりで、前提から完成条件まで自己完結で書く必要がある。この依頼文——つまり仕様書——が、今回の主役になる。
今回作らせたもの——動体視力テスト
題材は動体視力テストにした。画面を横切って流れる3桁の数字を読み取り、通り過ぎたあとに4択から選んで答える。全10ラウンドで、進むほど数字が速くなり、最後のレベルは最初の4.4倍速。タップだけで完走できて、無料・登録不要。記録は端末の中にだけ残る。
題材は思いつきではなく、今回もキーワード調査から決めた。「動体視力 テスト」には執筆時点の実測で月3,600回の検索がある。それに、約1ヶ月前に公開した反射神経テストが検索結果に顔を出し始めていて、客層がそっくり重なる。2本を相互リンクでつなげば、小さな「テストゲームのコーナー」になるという算段だ。1本目の顛末は反射神経テストの実録に書いた。
サブエージェントの使い方——仕様書に何を書いたか
仕様書は日本語で、画面の流れを時系列で書いた。ここまでは1本目と同じ。今回変えたのは、「してほしくないこと」を過去の失敗から2つ、先回りして書いたことだ。
1つ目は、1本目のバグの再発防止。反射神経テストでは、同じ瞬間に入力が2発届くと1回のタップが二重に記録されるバグが、公開直前のレビューで見つかった。原因は、ゲームの状態の記録を書き換えるタイミングが、画面の描き直しまで遅れる作りだったこと。今回は修正後の作り——状態の記録はその場で即座に書き換える——を、最初から仕様書で指定した。
2つ目は、データの捏造禁止。「年齢別の平均」のような実在の統計を勝手に作ってゲームの判定に使わないこと。判定はあくまでゲーム内の自前基準で、そのことを画面にも明記すること。AIは頼めば、それらしい数字をいくらでも生成できてしまう。作らせない線引きは、発注する側の仕事だと思っている。
ほかにも「タブを切り替えて戻ってきたとき、ゲームが不正に速くなっていないこと」といった動きの注意を添えた。効いたのは量ではなく、過去の失敗が入っているかどうかだ。1本目の検収でバグを1件踏んだ経験が、そのまま2本目の発注書の材料になった。
結果——13分で750行、1本目との差分
委譲からおよそ13分後、サブエージェントは作業を終えて戻ってきた。新規2ファイル、既存3ファイルの変更、計750行。tsc もビルドも一発で通っていた。それだけではない。サブエージェント自身が実際のブラウザでゲームを起動して、10ラウンドを完走するテスト、二重タップへの耐性確認、端末内への記録保存の確認まで済ませたうえで、結果を報告書にまとめて戻してきた。
私の検収は、禁止語や文字化けの機械チェック、実際の画面の確認、コードレビューという流れでやった。1本目で出た型のバグを重点的に疑って、ゼロ。2本を並べるとこうなる。
- 1本目(反射神経テスト)——実装35分、検収でバグ1件発見、修正して公開
- 2本目(動体視力テスト)——実装13分、検収バグゼロ、同日公開
進歩の中身は「失敗の記録を仕様書に還元した」で説明がつく。失敗はログに残しておくと、次の発注書になる。
仕様の穴を、サブエージェントが自分で埋めてきた
とはいえ、私の仕様書は完璧ではなかった。結果画面に出す「クリアレベル」を、私は「連続正解の最高到達点」としか書いていなかったのだ。この一文は2通りに読める。レベル1から正解し続けて届いた最高レベルなのか。それとも、途中のどこかでの最長連続なのか。
サブエージェントは前者を選び、しかも理由つきで報告してきた。いわく、途中の最長連続と解釈すると、最後のレベル10だけたまたま正解した人が「クリアレベル10」になってしまい破綻する。だからレベル1からの連続とし、その定義文を結果画面にも明記した——。
この判断は正しい。仕様の曖昧なところで手を止めて聞き返すのでもなく、黙って適当に決めるのでもなく、筋の通る解釈を選んで根拠ごと返す。優秀な人間の作業者と同じ動きだ。
仕様書に書いていない気の利いた仕事もあった。4択の間違い選択肢が、ただのランダムな数字ではない。「1桁だけ±1」「2つの桁を入れ替え」など、見間違えやすい数字をわざと混ぜて作ってある。動体視力テストの4択としては、この意地悪さこそが体験の質だ。
検収のつまずき——見えていない画面では、ゲームは止まる
順調に見えるだろうが、検収ではひとつつまずいた。私は検収のとき、ブラウザを自動操作してゲームを一通り遊ばせる。ところが今回は、スタートを押しても選択肢が永遠に出てこない。スクリーンショットまで失敗する。
原因はゲームではなく、観測する側にあった。このゲームは requestAnimationFrame という画面描画の仕組みで数字を流している。ブラウザは省エネのため、画面に表示されていないウィンドウではこの仕組みを止める。検収に使っていたブラウザのペインが非表示だったせいで、ゲームそのものが行儀よく一時停止していたのだ。
自動テストは諦めて、コードレビューに切り替えた。ゲーム本体の526行を頭から通しで精読して、二重判定のガード、4択に正解が必ず含まれる作り、ボタン連打への保険、画面を離れるときの後片付け——読んで確かめられる健全性を全部確かめた。最後は自分のPCでプレイして仕上げにした。
1本目の記事で「疑うべきは自分の観測手段」と書いたが、今回もまた観測手段に足をすくわれたことになる。動きのあるゲームの検収は、見えている画面でやる。これは仕様書ではなく、検収の手順書に入る教訓だ。
並列の実例——この記事も、別のサブエージェントが書いている
サブエージェントは並列で複数動かせる、と先に書いた。ここで白状すると、いまあなたが読んでいるこの記事の下書きも、ゲームを実装したのとは別のサブエージェントが書いたものだ。窓口の私は、制作過程のログと事実関係のメモを渡して、上がってきた下書きを検収して直す。ゲームで使った体制を、そのまま記事にも使っている。
実装と執筆で担当を分けるのは、1つの会話に両方をやらせるとコンテキストが混ざるからだ。ゲームのコードを書いた流れのまま記事を書かせると、実装者の目線の文章になりやすいと感じている。担当を分ければ、記事担当は読者側の目線から始められる。窓口を1つにして作業者を分けるこの考え方は、Claude CodeとCodexの併用実録に書いた分業とも地続きだ。
AIへの頼み方を学びたい人へ
サブエージェントの成果は、渡す仕様書の質でほぼ決まる——今回の実感だ。私は失敗しながら仕様の書き方を覚えてきたが、体系立てて学ぶなら、実務目線の講座から入る道もある。どのAIと組むにしても、「何をどう頼み、何をどう疑うか」は使い回しの利く技術だと思う。
まとめ: サブエージェントの結果は、仕様書の質で決まる
Claude Codeのサブエージェントは、メインの会話とは別のコンテキストで動く作業担当のAIだ。仕様書だけ渡してミニゲームを1本作らせたら、13分で750行が上がり、検収でのバグはゼロ。1本目でバグを踏んだ経験を仕様書に織り込んだことが、その差を作った。機能の使いこなしより、失敗の記録を次の発注書に変える運用のほうが結果に効く。
出来上がったゲームはこちら。流れる数字がちゃんと読めるか、腕試しにどうぞ。記録は端末の中にだけ残り、外部には送られない。
このサイトでは、AIだけで何かを作って公開するまでの過程を制作記録として残している。1本目のゲームでバグを見つけた顛末は反射神経テストの実録に、窓口と作業者を分ける体制の全体像はClaude CodeとCodexの併用実録にある。
本記事にはアフィリエイト広告を含む場合があります。商品リンクから購入されると、運営費の一部になることがあります。
よくある質問
Claude Codeのサブエージェントとは何ですか?
Claude Codeのメインの会話とは別のコンテキストで動く、作業担当のAIです。窓口のAIとの相談はそのままに、実装や執筆のような重い作業だけを切り出して任せられます。並列で複数動かすこともできます。注意点は、サブエージェントからはメインの会話の履歴が見えないこと。依頼文は初対面の相手に渡すつもりで、前提から完成条件まで自己完結で書く必要があります。
Claude Codeのサブエージェントの使い方は?特別な設定が要りますか?
私は特別な設定なしで使っています。窓口のClaude Codeとの会話で仕様を固めて、「この仕様書でサブエージェントに作らせて」と日本語で頼むだけです。コツは設定より依頼文の中身で、画面の流れ、してほしくないこと、完成の条件(型チェックやブラウザでの動作確認まで)を1通に書き切ると、途中の聞き返しなしで完走してくれます。
サブエージェントは並列で複数動かせますか?
動かせます。実例を挙げると、この記事の下書き自体、ゲームを実装したのとは別のサブエージェントが書いたものです。実装と執筆のように性質の違う作業を別々の担当に分けると、1つの会話に全部詰め込むより結果が安定すると感じています。ただし成果物の検収は窓口で1本にまとめて、任せきりにはしていません。
サブエージェントに任せるのにおすすめの作業はありますか?
私のおすすめは、成果物と完成条件をはっきり書ける作業です。今回のようなゲーム1本の実装、記事の下書き、手順の決まった調査あたりは相性がよいです。逆に、要件がまだ固まっていない相談やアイデア出しは、履歴を共有できるメインの会話でやるほうが向いています。切り分けの目安は「仕様書を1通で書き切れるか」だと思っています。
サブエージェントにゲームを作らせるには、仕様書に何を書けばいいですか?
私が今回書いたのは4種類です。画面の流れ(時系列)、してほしくないこと(過去に踏んだバグの再発防止と、実在しない統計データの捏造禁止)、動きの注意(タブを切り替えても挙動が壊れないこと)、完成の条件(型チェック・ビルド・実ブラウザでの完走テスト)。とくに効いたのは過去の失敗の織り込みで、1本目で出た型のバグが2本目ではゼロになりました。
制作記録を受け取る
新しい制作ログ、道具レビュー、失敗メモを Substack でも整理していきます。
Substackで読む1min Quiz
あなたが作るべきアプリ、1分で診断できます
記事を読んで「自分も何か作ってみたい」と思ったら、まず5つの質問に答えてみてください。いまのあなたに向いたアプリの型と、最初の一歩がわかります。約1分・無料です。