Claudeでシステム設計面接を練習する — 見積りと深掘りまで通す手順

システム設計面接の練習は、面接官役を固定し、進行を要件確認から深掘りまで4段に決めておくと回しやすくなります。Claudeでは、Projectsの指示欄に進行ルールを書き、構成図をArtifactsに描かせる形で、その環境を作れます。

設計面接の練習が難しいのは、答えが1つに決まらないからです。独学で設計例を読んでも、「その場で聞き返す」「数字を置いて見積る」「指摘されて構成を直す」という動きは身につきません。壁打ち相手がいれば解決しますが、相手の時間は限られます。この記事では、指示欄に書く文面、1問ごとの進め方、図の更新のさせ方、講評の頼み方を順に説明します。

職種を問わない模擬面接の基本はClaudeを面接官役にして模擬面接を練習する方法にあります。ここでは設計面接に固有の進行に絞ります。

面接官役をProjectsの指示欄に固定する

練習の土台は、練習専用のプロジェクトです。プロジェクトには独自のチャット履歴とナレッジベースがあり、指示欄に書いた内容はそのプロジェクト内のすべてのチャットに効きます。設計面接の進行ルールをここに置けば、毎回の冒頭で貼り直す手間が消えます。

作り方は短く済みます。サイドバーのProjectsから「+ New Project」を選び、名前を付けます。作成後に「Set project instructions」から指示を書き、「Save instructions」で保存します。プロジェクトはFreeプランを含む全ユーザーが使え、Freeの上限は5つです。

指示欄の文面は、たとえば次の形にします。

あなたはシステム設計面接の面接官です。私は候補者として答えます。
進行は次の4段階を順に踏みます。
1. 要件確認: 問題文は短く出し、私が質問するまで補足しない
2. 概算: QPS・保存容量・帯域を私に置かせ、前提の根拠を聞く
3. 構成: 私が出した構成に対し、図の更新を促す
4. 深掘り: ボトルネックや障害時の挙動を1回に1問だけ聞く
ルール:
- 質問は常に1つだけ。私が答えるまで次に進まない
- 私が前提を置かずに数字を出したら、根拠を聞き返す
- 正解は先に言わない。ヒントは私が求めたときだけ
- 最後に私が「講評」と書いたら、評価観点に沿って採点する

この文面は私の例で、決まった書式があるわけではありません。効かせたいのは「問題文を短く出す」「補足は聞かれてから」の2点です。面接官役が最初から要件を全部並べると、要件確認という最初の段階が練習になりません。

指示欄に書いた内容は、そのプロジェクトのチャットすべてに適用されます。一方で、プロジェクト内のチャット同士は、情報がナレッジベースに追加されない限り文脈を共有しません。前回の練習で出た弱点を次回に持ち込みたいなら、講評の要点をナレッジに足すか、メモリに頼ることになります。

4段を1問ずつ進める

進行は、チャットで「問題をください」と送ったところから始まります。ここでは短い題材として、URL短縮サービスを例にします。面接官役が問題文を一行で出し、候補者がそこから質問を重ねていく流れです。

概算は前提を言葉にしてから計算する

概算の段階で練習したいのは、計算力ではなく前提の置き方です。たとえば、次のような置き方をします。

• 新規URLは月1億件。1か月を約260万秒として、書き込みは毎秒約40件
• 読み取りは書き込みの100倍と仮定して、毎秒約4,000件
• 1件あたり500バイトで5年保存すると、1億件×12か月×5年×500バイトで約3TB

この3行のうち、面接官役に突いてほしいのは「100倍」と「500バイト」の根拠です。数字そのものは練習用の仮定で、現実のサービスの値ではありません。指示欄に「前提なしの数字には根拠を聞く」と書いておくと、この聞き返しが入ります。

計算を間違えたときは、面接官役が先に答えを言わないようにしてあります。間違いに気づかず進めてしまっても、講評の段階で見積りの桁を点検させれば拾えます。

構成図をArtifactsに描かせて更新させる

構成の段階では、文章だけで説明するよりも、図を挟んだほうが指摘が具体的になります。Artifactsは、会話の横に開く別ウィンドウで、ドキュメント・図・フローチャートなどを作る機能です。Claudeは、中身がまとまりのある内容で、あとで編集や再利用をしそうなときにArtifactを作ります。目安として、15行を超えるものが対象です。

図を描かせる依頼は、たとえば次のように送ります。

ここまでの私の構成を、図としてArtifactにまとめてください。
ボックスは、クライアント・API・アプリ層・キャッシュ・DBに分けます。
この後、質問に答えるたびにこの図を更新してください。

その後の深掘りで構成が変わったら、同じ依頼を繰り返す必要はありません。「キャッシュを分散させる前提に直して」と書けば、Claudeが図を直します。図を直すのは候補者側のやり取りなので、面接官役の進行ルールとは別に、「図の更新は私が指示したときだけ」と指示欄に書いておくと、面接官役が勝手に答えを描き足すことを防げます。

使う前に確かめておく設定が1つあります。Artifactsには、設定のCapabilitiesで「Cloud code execution and file creation」(新しい設定画面では「Create and edit files」)をオンにしておく必要があります。オフのままだとArtifactを作れません。Team・Enterpriseでは、組織設定のCapabilitiesで管理されます。

ドキュメント形式のArtifactなら、直したい箇所をハイライトして「Edit with Claude」を押し、依頼を書く方法もあります。文章で「3つ目の箇所を」と説明する手間が省けます。

練習の途中で別の構成案を試したくなったら、前のメッセージを編集します。編集すると、別のArtifactを持つ別バージョンのチャットが分かれ、前の作業は失われません。キャッシュ有りと無しの2案を比較する練習に向いています。

深掘りを1問ずつ受ける

深掘りの段階では、ボトルネックと障害時の挙動が中心になります。指示欄で「1回に1問」と決めてあれば、面接官役は一問ずつ聞いてきます。たとえば、次のような問いの流れが想定できます。

深掘りの問いは、概算で置いた前提に紐づけると練習になります。「保存期間を延ばしたら」という問いは、概算の3行をもう一度見直させます。

深掘りで詰まったときのために、「ヒントを求める」と決めた合図を指示欄に1つ作っておきます。たとえば「ヒント」と書いたら、答えを言わずに考える方向だけを示す、という約束です。合図を決めないと、面接官役が詰まった様子を察して親切に答えを説明し始めることがあります。

ここまで通してみて、アプリとDBのどちらが先に詰まるかの考え方に不安があれば、負荷試験の結果をアプリとDBに切り分ける手順が実務側の補強になります。

講評は見積りの根拠とトレードオフで頼む

深掘りを数問終えたら、「講評」と書いて採点に入ります。観点を決めずに頼むと総評で終わりやすいので、指示欄に評価観点を書いておきます。

「トレードオフの言語化」は、設計面接でも指摘されやすい観点です。「キャッシュを置きます」で終わらず、「整合性が遅れる代わりに読み取りが速くなる」と対比の形で言えているかを見てもらいます。

講評の依頼文は次のようにします。

講評をお願いします。評価観点は要件確認・見積りの根拠・トレードオフの言語化・深掘りへの対応の4つです。
各観点を5段階で採点し、理由を1〜2文で書いてください。
最後に、次の練習で最優先に直す点を1つだけ挙げてください。

「1つだけ」と絞るのは、複数の改善点を並べられても次の練習で意識できないためです。採点の数値は練習用の目安で、実際の面接の合否とは関係しません。

題材を変えて繰り返す

同じ題材を何度も解くと、構成が暗記になります。題材を変えるときは、指示欄を触らずに、チャットの冒頭で「次の問題をください」と送れば十分です。題材の候補には、通知配信、チャットアプリ、ログ収集、レート制限などがあります。題材が変わると、読み取りと書き込みの比率や、整合性への要求が変わります。この違いが、前提の置き方を鍛えます。

設計の枠組みを手元で使い込みたいときは、Claude Codeのsystem-designスキルで、要件からトレードオフまでを5段で詰める使い方もあります。面接練習の面接官役ではなく、実務の設計文書を出させる使い方です。

Projectsそのものの使い方を押さえるにはClaude ProjectsとArtifactsの使い方が出発点になります。

つまずきやすい点

質問が一度に複数出る: 「質問は常に1つだけ」を指示欄に書いていないと、概算と構成を一度に聞かれます。1回に1問と決めると、答えの質を点検しやすくなります。

図が会話と食い違う: 構成を言葉で変えたのに図を更新し忘れることがあります。深掘りの1問ごとに「図も更新して」と添えるか、各段階の終わりに図と答えを突き合わせます。

数字の正解を求めてしまう: 概算には正解がありません。「根拠のある仮定を置けたか」で見る前提を、指示欄の評価観点に書いておきます。

別チャットに前回の内容が出てこない: プロジェクト内のチャットは、ナレッジに追加した内容以外は共有されません。前回の講評を次に活かすなら、講評の要点をナレッジに足します。

まとめ

設計面接の練習は、進行ルールを指示欄に、構成図をArtifactsに、評価観点を講評の依頼文に、と役割を分けると回しやすくなります。最初の練習は、題材を1つに決め、要件確認だけを丁寧に通すところから始める形が現実的です。慣れたら、概算の前提を毎回変えて、同じ構成がどこで崩れるかを見ていきます。