はじめに
個人開発でタスク管理アプリ（Flutter + Hono/Prisma/Supabaseによるバックエンド構成）を作っています。認証機能やカンバンボードなど、複数の機能を1人で設計から実装まで進める中で、Claude Codeを「設計・仕様検討の壁打ち相手」として活用しています。
コードを書いてもらうというより、実装に入る前の設計判断を一緒に整理する使い方が中心です。この記事では、その具体的な進め方と、意識していることをまとめます。
なぜ「壁打ち」として使うのか
1人で開発していると、設計判断の妥当性を確認する相手がいません。
- この設計で後々破綻しないか
- もっとシンプルな方法があるのではないか
- 見落としている考慮漏れがないか
といった疑問を、都度誰かに相談するわけにもいかないため、Claude Codeに設計の方向性を説明し、指摘や別案をもらう、という使い方をしています。
コードを書かせて終わりにするのではなく、なぜその設計にするのかを言語化する過程そのものに価値を感じています。
コードレビューやペアプロとの違い
Claude Codeにはコード生成やレビューを依頼する使い方もありますが、壁打ちはそれとは目的が異なると捉えています。
- コード生成：既に決まった設計を、実装として形にしてもらう
- コードレビュー：書き終えたコードの品質や不具合を指摘してもらう
- 壁打ち：まだ形になっていない設計判断を、言語化しながら整理する
壁打ちは「実装前」の工程に位置していて、ここで設計の方向性を固めてから初めてコード生成やレビューに進む、という順番を意識しています。逆に言うと、壁打ちの段階を飛ばしていきなり実装を依頼すると、自分の中で設計判断の理由が曖昧なまま実装が進んでしまい、後から「なぜこの実装にしたのか」を説明できなくなる、という失敗を何度か経験しました。
実際の進め方
①現状の設計をそのまま説明する
まず、今考えている設計をありのまま伝えます。開発中のアプリの認証まわりを例にすると、次のような形です。
このアプリではaccessTokenとrefreshTokenの2トークン方式で認証を実装しています。
GoRouterのredirectでトークンの有無を見て認証ガードをかけている状態です。
この構成で次にカンバンボード機能を実装しようとしているのですが、
認証状態の設計として何か見落としがないか確認したいです。
最初から「こう直してほしい」と誘導せず、現状をそのまま渡すことで、思い込みに引っ張られない指摘をもらいやすくしています。
②複数の選択肢を出してもらう
設計判断に迷う場面では、1つの答えを求めるのではなく、複数の選択肢とそれぞれのトレードオフを出してもらうようにしています。
カンバンボードのドラッグ&ドロップで並び替えた際の順序管理について、
以下のどちらが良いか、他の選択肢も含めて考えを聞かせてください。
1. 各カードにposition(数値)を持たせて並び替え時に再計算する
2. 連結リストのように前後のカードIDを持たせる
1つの案だけを深掘りするより、選択肢を横に並べて比較した方が、自分の中で意思決定の軸がはっきりします。
③あえて反対の立場で聞いてみる
自分の設計に自信があるときほど、あえて逆の立場から質問することを意識しています。
この設計のデメリットや、将来的に困りそうな点を、
あえて批判的な立場で指摘してください。
肯定的な相槌だけをもらっても設計の粗は見つからないため、意図的に批判的な視点を求めるようにしています。
④出てきた結論を自分の言葉で書き直す
壁打ちで方向性が決まったら、そのまま採用するのではなく、一度自分の言葉で設計メモとして書き直すようにしています。これにより、なぜその設計にしたのかを後から自分でも説明できる状態にしています。
プロンプトの工夫
壁打ちの質は、プロンプトの与え方でかなり変わると感じています。意識しているポイントをいくつか挙げます。
背景・制約条件を先に伝える
いきなり質問だけを投げるのではなく、前提となる制約条件を先に共有するようにしています。
前提条件:
・個人開発でリリース時期の縛りはない
・Flutter + Riverpod + freezedでMVVM構成
・バックエンドはHono/Prisma/Supabase
・利用者は当面自分1人〜数人規模を想定
この前提の上で、カンバンボードの並び替えロジックについて相談したいです。
利用規模やチーム体制などの制約が違うと、妥当な設計判断も変わってきます。前提を共有しないまま相談すると、大規模開発向けの過剰な設計を提案されてしまうことがあったため、規模感を先に伝えることを徹底するようにしました。
「なぜ」を聞く
「どうすればいいか」だけでなく、「なぜそれが良いと考えるか」もあわせて聞くようにしています。
その設計を推奨する理由と、逆にどんな状況ならもう一方の設計を選ぶべきか、
あわせて教えてください。
理由まで含めて聞くことで、単なる作業指示ではなく、判断基準そのものを持ち帰れるようにしています。
一度に多くを聞きすぎない
認証設計とカンバンボード設計をまとめて一度に相談すると、それぞれの論点が浅くなりがちです。1回の壁打ちでは1つのテーマに絞り、深掘りしてから次のテーマに移る、という進め方を意識しています。
開発中のアプリでの活用例
認証ガードの設計
GoRouterのredirectでトークンの有無を見て認証ガードをかける設計について、トークンリフレッシュ中のリダイレクトの挙動や、リフレッシュ失敗時にどこへ遷移させるべきかを整理する際に壁打ちを行いました。「認証切れ」と「通信エラー」を同じ扱いにしていないか、という指摘をきっかけに、状態を分けて設計し直しました。
カンバンボードのデータ構造
カンバンボードの並び替えロジックを検討する際、上述の「position方式」か「連結リスト方式」かで壁打ちを行い、実装のシンプルさとデータ量が少ない個人開発の規模感を踏まえて、position方式を採用することにしました。
状態管理の粒度
hooks_riverpod + freezedを使ったMVVM構成で、1つのViewModelにどこまで責務を持たせるかを検討する際にも活用しています。画面単位で分けるべきか、機能単位で分けるべきか、Feature-firstの構成方針と照らし合わせながら整理しています。
認証まわりのリファクタ判断
当初シングルトークンで実装していた認証を、アクセストークン+リフレッシュトークンの2トークン方式に切り替える際、既存の実装をどこまで作り直すべきかを壁打ちしました。全面的に書き直すか、既存の認証フローを維持したまま段階的に移行するかで悩みましたが、個人開発でユーザー影響が自分だけであることを踏まえ、後方互換を気にせず一気に作り直す方針を選びました。この「後方互換を気にしなくていい規模だからこそ選べる判断」という視点は、壁打ちの中で言語化できたことの一つです。
壁打ちがうまくいかなかったケース
良かった点だけでなく、うまく機能しなかったケースも記録しておきます。
前提条件の共有が不十分だった
前述の「前提条件を先に伝える」を徹底する前は、個人開発の規模感を伝えないまま相談し、大規模チーム開発を前提にした複雑な設計を提案されたことがありました。提案自体は間違っていなくても、自分の状況に合っていなければ意味がないため、前提のすり合わせがどれだけ重要かを実感したきっかけになりました。
「決めてもらう」使い方に寄りすぎた
忙しい時期に、複数の選択肢を吟味せず「どれがいいか決めてください」という聞き方に寄ってしまった時期がありました。その場では効率的に見えても、後から「なぜその設計にしたのか」を自分で説明できず、結局設計メモを書き直す二度手間になりました。壁打ちはあくまで判断材料を整理する場であり、最終判断を委ねる場ではない、と改めて意識するきっかけになりました。
意識していること
最初から答えを求めない
いきなり「どう実装すればいいですか」と聞くと、表面的な実装方法だけが返ってきがちです。まず現状の設計と迷っている点を丁寧に説明することを優先しています。
出てきた案を鵜呑みにしない
複数の案や指摘をもらった後も、最終的にどれを採用するかは自分で判断するようにしています。特に個人開発は自分がすべての意思決定の責任を持つため、Claude Codeの回答はあくまで判断材料の1つという位置づけです。
設計判断の理由を残す
壁打ちの結果をそのままコピーするのではなく、「なぜこの設計にしたのか」を自分の言葉でコメントやドキュメントに残すようにしています。後から見返したときに、判断の経緯を思い出せるようにするためです。
得られた効果
壁打ちを継続的に取り入れるようになってから感じている変化です。
- 設計の説明力が上がった：なぜその設計にしたかを自分の言葉で説明する習慣がついたことで、後から見返したときの理解速度が上がった
- 手戻りが減った：実装前に選択肢を比較する工程を挟むことで、実装後に「やっぱりこっちの方がよかった」と作り直すケースが減った
- 1人開発の孤独感が和らいだ：設計判断を相談できる相手がいない状況でも、一度立ち止まって考えを整理する相手がいることの心理的な支えは大きいと感じています
まとめ
Claude Codeを設計・仕様検討の壁打ち相手として使うことで、1人で開発していても、設計判断を客観的に見直す機会を作れています。特に、
- 現状をそのまま説明してから相談する
- 複数の選択肢とトレードオフを出してもらう
- あえて批判的な視点を求める
- 結論を自分の言葉で書き直す
という進め方を意識することで、コードを生成させる以上の価値を感じています。特に、壁打ちを実装前の工程として明確に切り分けたこと、そしてうまくいかなかったケースから前提共有の重要性を学べたことは、記事にする中で改めて整理できた気づきでした。個人開発を通じて得たこの活用方法が、同じように個人開発や設計判断で悩む方の参考になれば幸いです。