この記事は Claude on SonicGarden の記事です。ソニックガーデンのプログラマが、Claude Codeの活用について書いています。#claude_on_sonicgarden
今年の2月と3月、私は個人趣味開発で $400 と睡眠を溶かして、紙とペンに負けたアプリを作り、開発凍結しました。
急げば急ぐだけ、本当に価値があるかどうかの検証が後回しになるリスクがあります。PO 視点に立った学びでした。
趣味と遊び心と下心
今年の2月、冬季五輪を観戦する頃、趣味でやっているスポーツ用に上達 PDCA 支援アプリが急激に欲しくなったので、「えいやっ」と Claude Code Max 20xプランを契約しました。私は Rails エンジニアですが、この頃、まだ AI コーディングツールをほとんど触ったことがありませんでした。
しかし、ちょうど私のスポーツはオフ期間だったので、シーズンインする1ヶ月半後までに一通りの機能を作り切りたい。そして、自力開発は無謀な規模でした。
リリースしてからのメンテを自力でやればいいやと、血の涙を流して $200 を貢ぎました（とはいえ、公開して収益化すれば開発費くらいはお小遣いとして悠々回収できるだろうと思っておりました。会社として OK かは知らんけど）。
注）上記プランの価格は 2026 年 2 月および 3 月時点のもので、現在は消費税 10% がかかるようになっています。
V1: 夜鍋カタカタ期
夜鍋開始です。Claude Code 契約前にチャットである程度の設計はしていましたが、細かいところをよく考える時間がないまま走り出します。
AIエージェントを使った開発については素人なので、画面にへばり付いてカタカタぽちぽちしました。毎週トークンを使い切りながら完成しました。10 日くらい余ったので、ドメイン取ったり、リファクタさせまくったり、UI 改善したり、Claude Code 先生に「収益化するなら価格設定いくらが適切かな？😙」と相談して皮算用したりしました。楽しかったです。
ある時、「Claude Code 先生、やけに都合いいな？」と気づいたので、文脈を知らない新しい Claude Code を呼んで相談してみました。弊アプリ V2 の開発が開始されました。
V2: PR 読まずマージしまくったらバグだらけで詰む
体力と時間の限界が近づいていたので、V2 は Pull Request をほぼ読まずにガンガンマージしました。
フロントエンドの複雑な条件分岐まわりでバグが多過ぎて詰みました（システムテストは徹底的に書こう）。
もう1ヶ月延長戦、V3 だーー！！！！😡💢💢 💸💸
V3: サブエージェント大量起動のオーケストレーションで完走
いよいよ気力さえも果てそうでした。そこでようやく、巷で流行っている Claude Code の使い方を X とか中心に情報収集したり、Claude 自身に調査させたりして、本格的に自動化を開始します。
設計フェーズに 2 つのスキルをネストして組みました。/design で多角度の初稿を 1 回作り、/design-review-cycle で新鮮な目に何度も叩かせる、という二層構造です。/design-review-cycle にテーマを渡すと /design を使って最後まで完走します。
/design 側は 多角度を一度に集める ための仕組み。競技専門家・心理学・UX・Rails など、視点の異なる人格が並列に動いて、初稿を多面的に潰します。/design-review-cycle 側は 時系列で繰り返し叩く ための仕組み。毎サイクル新しいエージェントを立ち上げ、前のレビューや修正の文脈を一切引き継がせません。同じ設計書を新鮮な目で何度も読ませることで、修正で生まれた新しい歪みを検出します。
役割分担の考え方は 「Claude Codeのサブエージェント並列化で、対象者別のシステム資料を自動生成する」に近いです。
サブエージェントを大量に使うのでトークンは秒で溶けますが、複数観点に渡って、見落としによる偶然の PASS を防げます。プラン 1 本につき 10 サイクル回っていることも珍しくありませんでした。待ち時間が長いので、その間に寝られます。
実戦投入
V3 が概ね出来ました。大きなバグなし。シーズンイン。
レース前後にスマホで入力。動きます。使えます。効果は分かりません。
翌週のレース。動きます。使えます。効果は分かりません。
翌々週の合宿。動きます。使えます。効果は分かりません。
......
動く、使える、効くの 3 段階で、最後の 1 段だけが返ってきませんでした。
このまま使って上手くなれる感覚があまりありませんでした。
紙とペンに引導を渡される
私 🐒「こんな機能モリモリなアプリ作ったんだ。すごいだろ」
趣味友 🦍「ふーん。俺、上達についてそんな複雑に考えてないわ」
🐒「クロえもん、Claude Code でこんなアプリ作ったんだけど、なんかイマイチなんだ」
🐙「なんだい、どこがイマイチなんだい」
🐒「僕がレースで上手くいかない時って、（略）」
🐙「上手くいくかどうかは、動き出す前に次のアクションを明確にイメージできているかどうかに依存してそうだ。そんな時は、紙とペン〜📃🖊️」
🐙「この秘密道具は、次のアクションを明確にイメージするという君の目標をレース前に意識して、レース後にも実際にできたかチェックすることまでできる優れものなんだ」
🐒「わあ、すごい。ありがとうクロえもん！！」
アプリ凍結。さらば我が $200×2 🫡
弊社で「納品のない受託開発」のエンジニアをしながら、ゴリゴリに納品を目指し、スモールスタートせずに盛り盛りで作ろうとした愚かな PO デビューでした。納品ではなく、早く動かして検証を回すのが本業なのにね。
AI に任せられることと、任せられないこと
開発中、私自身の上達に有効なのかどうかの検証がありませんでした。オフシーズンなので（言い訳）。
その代わり、世界中のスポーツ科学や実際のトレーニングメソッドを AI に調査させ、複雑なスポーツ体系を紐解いた「俺が考えた最強の上達アプリ」のはずでした。
なんなら、レビュワーの観点にはっきり、プロダクト戦略の視点を与えていました。
### 0. 方針妥当性（プロダクト戦略の視点）
他の観点に入る前に、**そもそもこの設計の方向性が当アプリにとって正しいか**を問う。
内部品質が完璧でも、方針自体が間違っていれば全てが無駄になる。
- **ミッション適合**: この機能は「世界選手権決勝レベルを目指す成長の加速」に直結するか？成長加速への因果経路を説明できるか？
- **代替アプローチ**: 同じ価値をもっとシンプルに実現する方法はないか？設計の複雑さに見合うだけの価値があるか？
- **ユーザー文脈**: レース会場（疲労・時間制約・スマホ）で使う場面を想像したとき、この設計は自然か？机上の空論になっていないか？
- **既存機能との関係**: 既存機能と重複・競合していないか？既存の仕組みを拡張するほうが良くないか？
- **スコープの妥当性**: やろうとしていることが多すぎないか？逆に足りないか？MVP として適切な範囲か？
- **ユーザーの成長段階**: Stage 0（初心者）〜Stage 2（上級者）の全員に必要か？特定の層にしか刺さらないなら、その層に集中すべきでは？
このプロンプトを PASS した状態で、結果は「MVP として大きすぎ／机上の空論／紙とペンより複雑」でした。チェック項目を書くことと、自分が本当にチェックされることは違う。
実際にレースを走って自分で分析すると、競技はさらに複雑で、完全にシステム化するアイデアが浮かばない程でした。
短期間で出来上がったアプリは、「主要機能は完成し、致命的なバグもなく、一つ一つの機能の価値があると思われる」一方で、「実際に使うと複雑すぎて使いにくく、局所的な効果に絞ったシンプルな紙とペンにすら劣る」ものでした。
Claude Code が爆速にできたのは「動くか／使えるか」までで、本当に有効なシステムなのかどうかは、より人間が頭を使わなければいけません。人間が実際に試してみなければいけません。
2 ヶ月の最後にぶつかったのは Claude Code の使い方ではなく、Plan→Do→Check→Act の Check が抜けたまま走り続けた、私自身の PDCA でした。上達 PDCA 支援アプリを作っていたのに、自分の開発の PDCA は回せていなかった、という間抜けなオチです。
AI に世界レベルの競技専門家人格を与えてレビューさせましたが、それが PASS することと、自分に効くことは別物でした。AI は「専門家ならこう言うだろう」までは速く出せます。実際にこの人間に効くかどうかだけは、人間が使って確かめるしかない。 今はレース前後に A4 1枚のメモを見返すだけです。いつかシステム化したい〜
Discussion