Claude Codeを「答えを出す道具」じゃなく「壁打ち相手」として使い始めた話
最近Claude Codeの使い方が変わってきました。
最初は「コード書いて」「バグ直して」「テスト作って」みたいに、答えを求める使い方ばかりしていたんですが、ある時期から「自分の考えを整理するための相手」として使うほうがうまくいくことに気づいた。道具というより、隣の席にいる同僚に話しかける感じ。
きっかけ
あるAPIの設計で迷っていたとき、最初は「このAPIどう設計すべき？」と聞いた。Claude Codeはそれっぽい設計をすぐ出してくれたんですが、なんかしっくりこない。要件を全部伝えきれていない自分の問題なんですが、出てきた設計に対して「ここが違う」「こっちのほうが」と修正を繰り返すうちに、やりとりがぐちゃぐちゃになった。
で、やり方を変えた。
今こういう状況で、AとBの2案があって、Aはこういう理由で良さそうだけどここが不安、Bはシンプルだけどスケールしなさそう。どう思う？こう聞いたら、返ってきた回答の質が全然違った。自分が見落としていた観点を指摘してくれたり、「Aの不安な部分はこういう方法で回避できるかも」と具体的な提案が出てきたり。
違いは何かと言うと、自分の頭の中を先に整理して渡したこと。
「答えをくれ」モードの限界
Claude Codeに「答えをくれ」と投げると、もちろん答えは返ってくる。でも、いくつか問題がある。
- コンテキストが足りない。 自分の頭の中にある前提条件、過去の経緯、チームの事情。これを全部伝えるのは難しい。結果として「技術的には正しいけどうちの状況には合わない」回答が返ってくる。
- 選択肢が一つに絞られる。 「どう設計すべき？」と聞くと、Claude Codeは一つの設計を提案してくれる。でも本当に欲しいのは「選択肢とトレードオフの整理」だったりする。
- 自分の理解が深まらない。 答えをもらって実装すると、なぜその設計になったのか腹落ちしないまま進むことがある。後から仕様変更が入ったときに「なんでこうなっているんだっけ」となる。
壁打ち相手モードの使い方
最近やっているのは、こんな感じの使い方です。
1. 自分の現状認識を先に書く
今、ユーザー認証の仕組みを変えようとしている。
現状はセッションベースで、JWTに移行するか迷っている。
理由は、マイクロサービス化を進めていて、
サービス間の認証がセッションだと面倒だから。
ただ、JWTのトークン失効の扱いが気になっている。まず自分が何を知っていて、何に迷っているかを言語化する。これだけで思考が半分くらい整理される。Claude Codeに聞く前の段階で、すでに効果がある。
2. 選択肢を並べて意見を求める
A案: 完全JWT化。トークン失効はブラックリスト方式で管理
B案: 認証サーバーだけセッション維持、サービス間は短命JWT
C案: 既存のセッション方式のまま、共有セッションストアを導入
自分はB案が現実的だと思っているんだけど、見落としている問題点はある？「どれがいい？」ではなく「自分はこう思っているけど穴はある？」と聞く。これだとClaude Codeは自分の判断を補強したり、見落としを指摘したりする方向で回答してくれる。
3. 反論を求める
これが地味に一番使える。
B案で進めようと思う。あえてB案のデメリットや、
将来ハマりそうなポイントを挙げてみて。自分が「これでいこう」と決めかけているときこそ、反論が欲しい。同僚に「これで大丈夫かな？」と聞くのと同じ。Claude Codeは遠慮なく問題点を出してくれるので、変に気を使わなくていい。
4. 議論の結果をまとめさせる
ここまでの議論を踏まえて、B案の実装方針を箇条書きで整理して。
考慮すべきリスクも一緒に。壁打ちが終わったら、議論の内容をまとめてもらう。これがそのまま設計メモになる。自分で書くより漏れが少ない。
実際にやってみて気づいたこと
言語化の強制力がすごい
Claude Codeに伝えるために自分の考えを文章にする過程で、「あれ、ここ曖昧だな」「この前提、本当に正しいのか」と気づくことが多い。いわゆるラバーダッキングの上位互換。ラバーダックは聞いてくれるだけだけど、Claude Codeは返事をしてくれる。
「わからない」と言える相手
同僚に「ここがよくわからない」と言うのは、状況によってはちょっと気が引ける。Claude Codeには遠慮なく言える。「そもそもJWTのリフレッシュトークンの仕組みがいまいち理解できていない」みたいなことも気軽に書ける。
議論のログが残る
会話がそのまま思考の記録になる。1週間後に「あのとき何を考えてB案にしたんだっけ」と振り返れる。これは口頭の壁打ちにはない利点。
コードを書かせるのは議論の後
壁打ちで方針が固まってからClaude Codeにコードを書かせると、一発で意図通りのものが出てくる確率がかなり上がる。最初から「コード書いて」だと手戻りが多かったのが、方針を先に揃えておくとスムーズ。
考えてみれば当たり前の話で、人間のエンジニアに仕事を頼むときも、要件が曖昧なまま「よろしく」と投げるより、背景と方針を共有してから頼んだほうがいいものが上がってくる。同じことです。
うまくいかないパターン
もちろん万能ではない。
- 時間がないとき。 壁打ちは時間がかかる。「とにかく今すぐこのバグを直したい」みたいな場面では、素直に「このエラーを直して」と投げたほうが早い。
- 自分に知識がなさすぎるとき。 完全に未知の領域だと、そもそも何を聞けばいいかわからない。この場合はまず「〜について教えて」から始めて、ある程度理解が進んでから壁打ちモードに切り替えるのがいい。
- 答えが一つしかないとき。 「このライブラリのインストール方法は？」みたいな質問に壁打ちは要らない。
よく使うプロンプトのパターン
自分がよく使うフレーズをいくつか。
| 場面 | プロンプト |
|---|---|
| 方針の相談 | AとBで迷っている。自分はAに傾いているけど、Bのほうがいい理由はある？ |
| 見落とし確認 | この設計で進めようと思う。見落としていそうな問題点を挙げて |
| 前提の確認 | 自分の理解が正しいか確認したい。〜という認識であっている？ |
| トレードオフ整理 | この3つの選択肢のトレードオフを整理して |
| 反論 | あえてこの方針に反対するとしたら、どういう理由がある？ |
| まとめ | ここまでの議論を踏まえて、実装方針をまとめて |
共通しているのは、自分の考えを先に出しているところ。白紙の状態で「どうすればいい？」とは聞かない。
所感
Claude Codeって「AIにコードを書かせる道具」だと思われがちなんですが、自分にとっては「考えを整理する相手」としての価値のほうが大きくなってきています。
コードを書くのは最後の工程で、その前の「何を作るか」「なぜそうするか」の整理のほうが、プロジェクト全体の生産性に効いてくる。ここをClaude Codeに手伝ってもらえるのが一番ありがたい。
もちろん、コードを書かせる使い方が間違っているわけではなくて、使い分けの話です。ただ、「AIに聞けば答えが出る」と思っていた頃より、「自分で考えた上でAIに壁打ちする」ほうが結果的に速いし、自分の理解も深まる。答えを求めるんじゃなくて、思考を深めるために使う。この発想の転換が、自分にとってはけっこう大きかった。
ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。
- 選考ではありません
- 履歴書不要
- 技術の話が中心
- 所要時間30分程度
- オンラインOK
