「自分が知らない領域の機能を設計する」という場面が、エンジニアには思ったより多い。
マーケティングの知識がないまま、広告計測機能を設計することになった。自社CRMとモニターサイトへの流入データを突合して、AI分析まで乗せる構成だ。CRAやCRPといった指標も、設計しながら初めて調べた。
チームに相談できる相手はいない。外部に頼む余裕もない。こういうとき、Claude Codeが「壁打ち相手」であり「先生」になる。
知らない領域で設計するとき
ドメイン知識がない状態で設計をはじめると、詰まり方が普通と違う。「どう実装するか」ではなく「何を作るべきか」からわからない。
広告計測の設計では、まずマーケティングの概念を教えてもらいながら設計の選択肢を整理するところから始めた。
自社CRMと広告媒体の流入データを紐付けて、
申込単価（CRA）・完了単価（CRP）を自動算出したい。
複数媒体のCSVフォーマットが違う。集計ロジックはどこに置くべきか。
最終的にAIで改善アクションを出力したい。
何から設計を始めればいいか整理してほしい。返ってくるのは「何を作るべきか」の地図だ。選択肢の列挙ではなく、「今の状況ではここから始めるのが合理的」という順序の提案。
壁打ちの流れ
設計の相談は、一問一答より「対話を重ねる」方が価値が出る。
最初の質問で全体像を掴んで、次の質問で「じゃあこの部分はどう設計するか」を深堀りする。
広告計測では：
- 媒体別CSVパーサーをどう設計するか（Factory/Strategyパターンの提案）
- 集計処理をどこで走らせるか（バックエンド vs フロントエンド）
- AIへ渡すトークンをどう最小化するか（SQLライクなプリ集計の提案）
- レスポンスの型をどう固定するか（Gemini SDKのresponseSchemaの使い方）
この4ステップを壁打ちで整理したことで、「なんとなく作り始めた」ではなく「理由を説明できる設計」になった。
「答えをもらう」ではなく「思考が整理される」
Claude Codeとの壁打ちで感じることは、「正解を教えてもらう」というより「自分の思考が整理される」感覚に近い。
プロンプトを書く過程で「あ、ここで自分は何を判断しようとしているか」が明確になる。迷っている理由が言語化できれば、半分は解決している。
solo-techlead-ai-survival の記事にも書いたが、一人で設計の責任を持っているとき、「自分の頭の中以上のことができない」という限界がある。AIが壁打ち相手になることで、その限界の天井が少し上がる。
壁打ちを効果的にするコツ
前提をたっぷり書く
技術スタック・チーム規模・制約条件をできるだけ詳しく書く。コンテキストが多いほど、回答の質が変わる。
自分の仮説を先に書く
「選択肢A・B・Cがある」だけでなく「自分はAが良いと思っているが、この懸念がある」と書くことで、懸念点にピンポイントで応じてもらえる。
CLAUDE.mdにプロジェクトコンテキストを書いておく
# プロジェクト概要
- 医療系スタートアップのCRMシステム
- NestJS + TypeORM + PostgreSQL
- チーム: エンジニア3名（うち2名は未経験から育成中）
- 制約: 規制医療情報を扱うため、外部サービスへのデータ送信に注意毎回同じ前提を書かなくて済む。
「思考の劣化」には気をつける
一つ、使い続けて感じたリスクがある。
壁打ちが便利すぎると「自分で考えること」をサボるようになる。「Claude Codeに聞けばいい」という癖がつくと、設計力そのものが育たなくなる。
「まず10〜15分は自分で考える」「自分の仮説を持ってから相談する」というルールを自分に設けている。思考補助ツールであって、思考代替ツールではない。
関連記事: