AIを設計の壁打ち相手にする｜問いの立て方の型

「この設計で進めていいのか、相談できる相手がいない」。 ひとりで設計を任されたとき、あるいはレビューしてくれる先輩が忙しいとき。決めるのは自分で、でも判断材料が足りない——そんな夕方、ありますよね。

そういうとき、AIは設計の壁打ち相手になります。 ただ、いきなり「どう設計すればいいですか」と聞くと、もっともらしい一案がすらすら返ってきて、それで終わりがちです。一見よさそうなので、つい鵜呑みにしたくなる。でも、それは相談ではなく、ただ答えを写しているだけかもしれません。

この記事は、AIを「答えをくれる人」ではなく「一緒に考えてくれる人」として使うための、問いの立て方の話です。設計の正解をもらうのではなく、自分の判断の精度を上げるための使い方を、一緒に見ていきましょう。

結論：設計の壁打ちでは、①前提と制約を先に渡す → ②いきなり最適解でなく複数案を出させる → ③各案のトレードオフを言わせる → ④自分の案に反論させる → ⑤最後は自分で決める、の順で問いを立てます。AIに決めてもらうのではなく、見落としと選択肢を洗い出す相手として使うのがコツ。最終判断は必ず自分に残します。

設計に「唯一の正解」はめったにありません。 だからこそ、答えを1つもらうより、選択肢とその理由を並べてもらう方が、ずっと役に立ちます。

「どう設計すればいい？」がうまくいかない理由

AIは、聞かれたことに「ありそうな答えを1つ」返すのが得意です。 だから「どう設計すればいい？」と漠然と聞くと、世間でよくある構成を、自信ありげに1つ提示します。それが悪いわけではありません。ただ、そこには次のような落とし穴があります。

• 前提を渡していないので、あなたのプロジェクトの事情に合っているとは限らない
• 一案しか出ないので、他にどんな選択肢があったのかが見えない
• トレードオフが言語化されないので、なぜその案なのかの理由が残らない
• もっともらしいので、疑う前に受け入れてしまう

設計でいちばん怖いのは、間違った案を選ぶことより、選択肢を検討しないまま進むことです。後から「他のやり方もあったのでは」と気づいても、もう作り込んだ後だと戻すのが大変になります。

壁打ちの目的は、答えをもらうことではありません。 自分が見落としていた選択肢と、判断の理由を、表に出すことです。そのために、問いの立て方を少し変えます。

壁打ちの全体像：5つのステップ

先に流れを出します。この順番で問いを重ねると、AIが「答える人」から「一緒に考える人」に変わります。

ポイントは、順番です。 前提を渡す前に案を聞くと、ずれた案が返ります。案を1つに絞る前に反論させると、思い込みに気づけます。1つずつ見ていきましょう。

なお、この流れはチャットでの言葉のやりとりだけでも回りますが、Claude Code・Cursor・GitHub Copilot のような CLI／エージェント型の道具を使うと、案を口頭で比べるだけでなく、既存のコードを読ませて前提を補ったり、気になる案だけ小さな試作を作らせて差分で確かめながら壁打ちできます。手を動かして確かめられる分、トレードオフが実感として見えやすくなります。それでも、後で触れるとおり決めるのは自分という線引きは変わりません。

ステップ1：前提と制約を先に渡す

最初にするのは、質問ではなく状況の共有です。 あなたの頭の中にある事情を、AIは知りません。それを渡さないまま案を求めると、教科書的だけど現場に合わない答えになります。

渡すと良いこと：

• 何を作るのか（解決したい困りごと、使う人、規模感）
• 技術的な制約（言語・フレームワーク・既存の構成・使えるインフラ）
• 組織的な制約（チームの人数とスキル、運用体制、納期、予算）
• 譲れない条件と、こだわらない条件（性能優先か、保守性優先か、早さ優先か）

むずかしく考えず、3行くらいで十分です。シーン別に、こう書けば渡せる、という記入例を挙げておきます。

• 社内ツール：「作るのも直すのも自分ひとりの小さな社内ツール。半年後に自分が読んでも分かることが最優先。凝った作りより、直しやすさ重視」
• 顧客向けWeb：「外部の人が使うWebサービス。チーム3〜4人で運用。納期は決まっている。落ちないこと・直しやすさを優先、目新しさは後回し」
• データ移行：「既存データを新しい仕組みへ移す一度きりの作業。途中で失敗しても元に戻せること、移行漏れに気づけることが最優先」

こう渡すだけで、AIは過剰に凝った構成や、的外れな前提の案を避けやすくなります。 制約は、案の自由度を狭めるものではなく、現実に合った案に絞り込むための枠です。

ステップ2：いきなり最適解でなく「複数案」を出させる

前提を渡したら、「最適な案を1つ」ではなく「考えられる案を3つ」と頼みます。 これだけで、得られる情報がぐっと増えます。

聞き方の例：

この要件で考えられる設計案を、性質の違うものを3つ挙げてください。
それぞれについて、ざっくりの構成と、向いている状況を一言で。
まだ良し悪しの判断はしなくて大丈夫です。

「性質の違うものを」と添えるのがコツです。 そう言わないと、似たような案が3つ並ぶことがあります。「シンプル重視」「拡張性重視」「早く作れる重視」のように、軸の違う案を出してもらうと、選択肢の幅が見えてきます。

忙しい日は、3案も比べる時間がないこともあります。 そんなときは、無理に3つ並べなくて大丈夫です。迷っている軸が1つに絞れているなら、「Aでいくか、Bでいくか」の2案の対比でも十分機能します。たとえば「自前で持つか、外部サービスに任せるか」のように、対立する2つを並べて得失を比べるだけでも、なんとなく決めるより一段はっきりします。案の数より、性質の違うものを並べることが大事です。

この段階では、まだ選ばなくて大丈夫です。 まずは「こういう道もあるのか」を並べる。それが、後で自分が決めるときの材料になります。

ステップ3：各案のトレードオフを言わせる

案が並んだら、次は「それぞれ、何を得て何を捨てるのか」を言葉にしてもらいます。 設計の判断は、たいてい「どれが正しいか」ではなく「何を優先するか」です。だから、各案のトレードオフが見えると、自分の状況に照らして選べるようになります。

聞き方の例：

3案それぞれについて、次を表で整理してください。
- 強み（何が楽になるか）
- 弱み（何が苦しくなるか）
- 特に効いてくる場面（どんな状況でこの案が有利か）
- 採用したとき、後で変えにくくなる点

特に効くのが、最後の「後で変えにくくなる点」です。 設計の怖さは、いまの正しさより「後から戻せるか」にあります。データの持ち方や外部との境界など、一度決めると引き返しにくい部分を先に教えてもらうと、慎重に決めるべき所と、後で直せばいい所の区別がつきます。エージェント型の道具を使っているなら、ここで迷う部分だけ小さな試作を作らせて、手元の差分で「本当に変えにくいのか」を確かめてみると、机上の比較が一段はっきりします。

ここまで来ると、AIの出力は「答え」ではなく「判断材料の一覧」になっています。 これが壁打ちの核心です。

ステップ4：自分が傾いた案に「反論」させる

だいたいの場合、ここで自分の中に「これかな」という案が見えてきます。 そうしたら、その案をわざと否定する役をAIにやってもらいます。

聞き方の例：

私はA案で進めようと思っています。
あえて反対の立場で、この案の弱点・見落とし・後で困りそうな点を挙げてください。
「半年後に後悔するとしたら、どこが原因か」という観点でお願いします。

人は、一度「これだ」と思うと、それを支える理由ばかり集めてしまいます。 だから、自分では気づきにくい弱点を、AIにわざと探させる。これは「AIに見落としを洗わせる」使い方の、設計版です。

ここで出てきた反論を、全部受け入れる必要はありません。 「それは今回は問題にならない」「それは許容できる」と、自分で判断して取捨選択する。反論に納得できる答えを自分で持てたなら、その案への自信は本物になります。

うまく答えられない弱点が出たら、それは立ち止まるべきサインです。そこで止まらず、次のどちらかに進みます。前提の置き方が甘かったなら、①に戻って前提・制約を書き直す（規模や優先順位を見直すと、弱点が消えることもあります）。事実があやふやで判断できないなら、一次情報（公式情報や自社の実データ）を当たって確かめる。詰め直してからもう一度反論させると、今度は答えられることが多いはずです。

ステップ5：最後は自分で決める

そして、いちばん大事なステップです。 ここまでAIと壁打ちしてきても、決めるのは自分です。

AIは、前提から漏れた事情を知りません。チームの空気も、過去の失敗も、来期の計画も知りません。だから最終判断は、それらを知っているあなたにしかできません。 AIの役割は、選択肢を広げ、理由を言語化し、見落としを突くことまで。そこから先の「で、うちはどうするか」は、人の仕事です。

これは責任の話でもあります。 設計を決めたのが自分だと言えるからこそ、後で問題が起きても、なぜそう決めたかを説明でき、立て直せます。AIに決めてもらった設計は、つまずいたときに拠り所がありません。壁打ちはするけれど、判断は手放さない。この線引きが、AIを安全に使う土台になります。

ありがちな落とし穴と、その回避

壁打ちでつまずきやすい所を、先に潰しておきます。

• 前提を渡さず案を聞く：教科書的でずれた案が返る。まず状況の共有から。
• 一案で満足する：最初の答えに飛びつかず、「他には？」を必ず一度挟む。
• トレードオフを聞かない：理由が残らないと、後で人に説明できない。各案の得失を言葉にしてもらう。
• 反論を入れない：賛成意見だけ集めると、思い込みが固まる。自分の案をあえて否定させる。
• AIの一般論を、自社の事実として扱う：AIは具体的な最新仕様や自社の数字を知りません。前提に関わる事実は、自分で一次情報を確認する。
• 決定をAIに委ねる：壁打ちと意思決定は別物。決めた理由を自分の言葉で言える状態にしておく。

落とし穴のほとんどは、「AIに答えてもらおう」とした瞬間に生まれます。 「AIと一緒に考える」に意識を変えるだけで、多くは避けられます。

明日からやること（小さく始める3つ）

いきなり全部やろうとせず、まずこの3つから。

1. 次に設計で迷ったら、前提を3行書いてから相談する：作るもの・制約・優先順位。これだけで案の質が変わります。
2. 「最適な案」ではなく「違う案を3つ」と聞く：選択肢を並べる癖がつきます。
3. 傾いた案を、一度AIに否定させる：「半年後に後悔するなら、どこが原因か」と聞くだけ。

この3つだけでも、ひとりで設計を抱える夜が、少し心強くなります。

コピーして使う「壁打ちテンプレ」

新しい設計を相談するとき、上から順に問いを重ねてください。一度に全部でなく、迷っている所から使えば十分です。

# 設計の壁打ち

## ① 前提・制約（最初に渡す）
- 作るもの・使う人・規模：
- 技術的な制約（言語・既存構成・インフラ）：
- 組織的な制約（人数・スキル・納期・予算）：
- 優先したいこと / こだわらないこと：

## ② 複数案（次に頼む）
「この前提で、性質の違う設計案を3つ。構成と向いている状況を一言で。
 まだ良し悪しの判断はしないでください。」

## ③ トレードオフ
「3案それぞれの 強み / 弱み / 特に有利な場面 / 後で変えにくくなる点 を表で。」

## ④ 反論
「私は◯案で進めようと思います。あえて反対の立場で、弱点と見落とし、
 半年後に後悔するとしたらどこが原因か、を挙げてください。」

## ⑤ 自分で決める
- 採用した案：
- その理由（自分の言葉で）：
- 受け入れた弱点 / 許容した理由：

壁打ち前後のチェックリスト

相談を始める前と、決める前に、さっと確認します。全部に○が要るわけではなく、関係する所だけで十分です。時間がない日は、太字の2つ——「前提を言葉にした」「決めた理由を自分の言葉で言える」——だけ押さえれば及第。残りは余裕があるときの確認項目だと思ってください。

相談を始める前

• 前提（作るもの・制約・優先順位）を言葉にしたか
• AIに事実確認まで委ねていないか（最新仕様・自社の数字は自分で確認）

案を検討するとき

• 一案で満足せず、複数案を並べたか
• 各案のトレードオフ（得るもの・捨てるもの）を聞いたか
• 「後で変えにくくなる点」を確認したか

決める前

• 傾いた案を、一度AIに否定させたか
• 反論に対して、自分なりの答えを持てたか
• 「なぜこの案にしたか」を自分の言葉で言えるか

最後に

設計をひとりで任されるのは、心細いものです。 相談相手がいない、レビューが回ってこない、決めるのは自分。その状況は、簡単には変わらないかもしれません。

でも、答えを写すためでなく、一緒に考える相手としてAIを使えば、ひとりで抱えていた設計に、もうひとつの視点が加わります。

5つ全部でなくても、今日ひとつ「他にどんな案がある？」と聞けたなら、それはもう、ひとりで決めきる重さを少し軽くする一歩です。 壁打ちで設計を固めたら、書く前に渡す前提も整えておくと、実装がぐっと楽になります。その型はAIにコードを書かせる前に渡す前提と制約に、書いた後に見る型はAI生成コードのレビュー・検証チェックリストにまとめました。考える・書く・見る。この3つがそろうと、AIとの開発はずいぶん落ち着きます。

関連用語

• プロンプト
• LLM
• ハルシネーション