アーティスト・個人開発者の廣川政樹です。Claude Code を毎日使うようになって変わったことのひとつに、「設計を考える時間が、ひとりの作業ではなくなった」というものがあります。コードを書かせる相手としてではなく、自分の設計判断をぶつけて反応を返してもらう相手として使うようになってから、作るものの質が明らかに変わりました。
ただ、そのためには質問の作法を意識する必要があります。漠然と「どう設計したらいいですか」と聞いても、Claude Code は当たり障りのない一般論を返してきます。それは Claude Code が悪いのではなく、私が「考える材料」を渡せていないからです。
「設計を任せる」と「設計を一緒に考える」は違う
Claude Code を使い始めた頃、私は無意識のうちに「Claude に設計を任せる」モードで会話していました。「ユーザー認証を実装したい」「課金フローを設計してほしい」と投げて、返ってきた構成をほぼそのまま採用します。これは効率的に見えますが、危険な使い方です。
何が危険かというと、自分の中に判断軸が育たないことです。Claude Code が出した設計は、もっともらしく見えても、私が運営しているプロジェクトの文脈にチューニングされていません。たとえば「Cloudflare Workers + OpenNext で動かす」「個人運営なので運用負荷は最小化したい」「課金は Stripe Checkout で完結させたい」といった制約は、明示的に伝えなければ反映されません。
これに気づいてから、私は意識して「設計を一緒に考える」モードに切り替えました。具体的には、Claude Code に答えを出させるのではなく、自分が考えた設計に対して反対意見を出してもらうことに使い方を変えたのです。スパーリングです。相手は強ければ強いほどいい。
漠然とした要件を投げた日のこと
具体的な失敗から話を始めさせてください。半年ほど前、Dolice Labs の課金まわりを再設計しようとした時のことです。私は「Stripe で記事単体購入とサブスクの両方を扱える設計を考えてほしい」と Claude Code に投げました。
返ってきたのは、「webhooks を中心に据えた一般的な構成」でした。新規実装としては正しいのですが、私の運営状況を見ると不要な複雑さが入っていました。私は Cloudflare Workers の制約上、長時間処理を避けたかったし、個人運営なのでイベント駆動の障害ポイントを増やしたくなかったのです。
その時に学んだのは、「私が答えを持っていない質問は、Claude Code も筋のいい答えを返してくれない」ということでした。Claude Code は対話相手であって、占い師ではありません。私が前提を持っていないと、Claude Code は最も平均的な答えを返すしかなくなります。
その後、設計を考える時の流れを変えました。まず自分で30分ほど考えてラフな案を3つくらい紙に書き出します。そのうえで「この3つを比較してほしい。それぞれの最大の弱点はどこにあるか」と聞く。これだけで対話の質が変わりました。
質問の最初の3行で、対話の質はほぼ決まる
実感として、設計対話の質は最初のメッセージの最初の3行でほぼ決まります。具体的には次の3つを書くと、Claude Code が返してくる内容の解像度が劇的に上がります。
1行目: 何を作っているか（プロジェクト全体の文脈） 2行目: 今ぶつかっている具体的な選択肢 3行目: 自分が現時点で傾いている案と、迷っている理由
たとえば前述の課金設計の話なら、こう書き直します。
Cloudflare Workers 上で動く個人運営のブログサイトに、Stripe Checkout で記事単体購入（¥250）と月額サブスク（¥580）の両方を載せたい。 今迷っているのは、購入権限の保存先を (a) Cloudflare KV だけにするか、(b) Cookie にも冗長化するか、です。 私は (b) に傾いていますが、Cookie 改ざんのリスクと KV ダウン時の挙動のバランスをどう取るべきか確信が持てません。
このレベルまで前提を書くと、Claude Code は一般論ではなく、私の状況に対する具体的な反論や代替案を返してきます。とくに「あなたが (b) に傾いている理由は理解しましたが、その判断は KV のダウン頻度を過大評価していませんか」のような形で、自分が見落としている前提を突いてくれます。これがスパーリングです。
「比較できる選択肢」を引き出す問いの形
私がよく使う質問パターンをいくつか共有します。どれも「比較できる選択肢」を引き出すための型です。
A案とB案の最大の違いは、3年後どちらが運用負荷を下げるかという点で考えるとどう評価できますか。
私はA案で進めようとしていますが、A案を選んだ場合に半年以内に後悔する可能性が高いポイントを3つ挙げてください。
このアーキテクチャを「個人運営・週末開発・障害対応は1人」という制約で評価し直すと、どこに変更が必要ですか。
ポイントは、評価軸を私が決めることです。「運用負荷」「半年後の後悔」「個人運営」など、判断軸そのものを質問に埋め込むと、Claude Code はその軸でしか答えられなくなります。これは制約ではなく、対話を有意義にするための仕掛けです。
逆に「どっちがいいですか」と聞くと、Claude Code は無難に両方の良いところを並べて終わります。それは対話ではなく整理です。
AIに同意されないことを前提にする
スパーリングの最大の効用は、自分が見えていない論点を Claude Code が突いてくることにあります。だから私は、Claude Code が私の案に同意したら少し疑うようになりました。
「いいアイデアですね、A案で進めましょう」と返ってきた時は、こう聞き直します。
A案について、私が見落としている弱点があるとすればどこですか。少なくとも2つ、辛口で挙げてください。
「辛口で」というキーワードを入れると、Claude Code は遠慮なく弱点を指摘してくれます。私が運営している4サイトの設計判断のうち、いくつかはこの「辛口モード」で覆りました。とくに、自分が美しいと感じていた抽象化が、実際には個人運営の保守コストを上げるだけだと気づいた時は、収穫が大きかったです。
ここで重要なのは、Claude Code に判断を委ねることではありません。指摘を受けて、もう一度自分で考え直すことです。Claude Code の指摘が的外れに感じたなら、その理由を言語化することで、自分の判断軸が一段はっきりします。同意されないことを恐れず、むしろ歓迎する姿勢が、設計対話を本当のスパーリングに変えます。
設計対話の記録を CLAUDE.md に蓄積する
Claude Code との設計対話で気づいた点は、その場で消費するのはもったいないです。私は重要なやり取りを CLAUDE.md または _documents/ 以下のメモに残すようにしています。
具体的には次のようなフォーマットで記録します。
## 2026-04-15 — 課金フローの設計判断
### 検討した選択肢
- A: KV のみで権限管理
- B: KV + Cookie 二重化
- C: D1 にユーザーテーブルを持つ
### 採用した案
B（KV + Cookie 二重化）
### 採用理由
個人運営で KV の SLA に依存しすぎたくない。
Cookie 改ざんは Stripe verify-session で検証時に弾けるため、
ユーザー体験の劣化リスクが KV ダウン時より低いと判断。
### Claude Code からの指摘で気づいたこと
- Cookie には購入スラッグのリストを蓄積する必要がある
（単発ではなく追記型の構造を持たせる）
- KV ダウン時の deny by default を必ず守るこれを蓄積していくと、半年後に同じ判断を見直す時に、過去の自分の判断軸を再構築できます。Claude Code はセッションをまたいだ記憶を持たないので、判断の歴史を残すのは私の役目です。逆に言えば、CLAUDE.md を厚くしておくと、新しいセッションを始めた時にもスパーリングの精度が上がります。
スパーリングを習慣にすると、何が変わるか
最後に、この使い方を半年ほど続けて何が変わったかを書きます。
ひとつは、設計のスピードと納得感が両立するようになりました。ひとりで考えると堂々巡りに陥りやすい場面で、Claude Code との対話を1ラウンド入れることで、判断が一段早く着地します。それでいて、判断は最終的に私が下しているので、後から「なぜこれを選んだのか」を説明できます。
もうひとつは、自分の判断軸が言語化される頻度が増えました。Claude Code に説明するために前提を書き出すと、その過程で「自分は何を大事にしているのか」がはっきりします。これは設計だけでなく、サイトの方向性やプロダクトの価値設計にも効いてきます。個人開発者にとって、自分の判断軸を持つことはアウトプットの質を底上げする土台です。
そして3つ目は、「AIに頼っている」という感覚が薄れたことです。スパーリング相手として使っているので、判断は常に私のものです。Claude Code はその判断を磨いてくれる存在で、置き換えるものではありません。この距離感に落ち着いてから、ツールに振り回されずに使い続けられるようになりました。
Claude Lab では、Claude Code を「自分の作業を加速する相棒」として深く使い込むためのプレミアム記事を継続して公開しています。今回の記事のような「対話の作法」「長期運用」「個人開発者ならではの設計判断」といったテーマを、より具体的なケーススタディと共にメンバーシップで読めます。広告のないクリーンな読書環境と、サイト運営費（Cloudflare・Stripe・各種ドメイン）への支援を兼ねていただければ嬉しいです。記事末尾のメンバーシップ案内から、ご支援を検討いただけると励みになります。