設計・アーキテクチャで聞かれる8の質問と答え方【技術面接 集中講座 #3】

• 1. なぜ設計の質問はスキルがあっても詰まるのか

• 2. 8問の優先度マップ｜どこから手をつけるか

• 3. 設計・アーキテクチャで聞かれる8の質問

• 4. 設計を語れる人と語れない人の違い

• 5. 設計判断を語れるようになるための準備法

• 6. まとめ

1. なぜ設計の質問はスキルがあっても詰まるのか

設計の質問で詰まるのには、構造的な理由があります。実装の経験と、設計の経験は、イコールではないからです。動くものを作れることと、複数の選択肢から構成を選び取れることは、別の力です。

もう一つの理由は、設計には「唯一の正解」がないことです。要件によって良い設計は変わり、トレードオフの上に成り立ちます。答えが一つに定まらないからこそ、語りにくいのです。だからこそ、就活においては「なぜそう判断したか」を言語化できる人が評価されやすくなります。

2. 8問の優先度マップ｜どこから手をつけるか

最初に「3〜4問を深く語れれば十分」とお伝えしましたが、どの質問から準備すべきか迷う人も多いでしょう。そこで、8問を優先度順に3つに分けて解説します。

頻出・必答ゾーン（まずここから）

質問1（アーキテクチャ全体の構成）、質問2（DBスキーマ設計）、質問3（API設計）の3つです。ほぼ確実に聞かれるため、最低限、ここは深掘りに耐える準備をしておきましょう。

差がつくゾーン（余裕があれば）

質問5（エラーハンドリング設計）と質問7（パフォーマンス設計）です。答えられると評価が一段上がります。計測や対処の実体験があれば、強い武器になります。

上級・任意ゾーン（専門性のアピール）

質問4（ディレクトリ構成・モジュール分割）、質問6（セキュリティ設計）、質問8（拡張性・保守性）です。質問4と質問8はセットで聞かれることもあります。上位層が差別化を狙うゾーンで、語れれば一気に「設計を語れる人」の印象になります。

3. 設計・アーキテクチャで聞かれる8の質問

ここからは8問を順に見ていきます。各質問は、「よくあるNGな回答例」「面接官が見ているポイント」「回答の型」の3つに分けて解説しています。

質問1｜アーキテクチャ全体の構成と、その構成にした理由を教えてください

質問1は、8問全体の総論にあたります。質問2以降が各構成要素の深掘りで、質問1はそれらを束ねる傘のような位置づけです。

■ よくあるNGな回答例

「フロントエンドがNext.js、バックエンドがGo、間をREST APIで繋いでいます」と、構成図の説明から入ってしまいます。「SPAにしているのは画面遷移を高速にするためです」と一見もっともらしい理由を答えても、「なぜサーバーサイドレンダリングではないのか」と掘られると詰まります。「モノリスとマイクロサービスの選択は考えましたか」と聞かれ、選択肢自体を知らないことが露呈することもあるでしょう。構成は説明できても、「他のアーキテクチャと比較して、なぜこの構成にしたのか」が語れていません。

■ 面接官が見ているポイント

見られているのは、「アーキテクチャ選択は、ビジネス要件と非機能要件のトレードオフから導かれる」という基本原則を理解しているかです。SPA vs SSR、モノリス vs マイクロサービス、サーバーレス vs サーバーフルなどの選択は、すべて「何を優先し、何を犠牲にしたか」のトレードオフです。これを言語化できないと、「実装はできるが設計はできない人」と判断される可能性があります。

■ 回答の型

「ビジネス要件→非機能要件（パフォーマンス・拡張性・運用負荷）→候補アーキテクチャ→トレードオフ→採用」の流れで語りましょう。比較対象を必ず提示します。

▼回答イメージ

「ユーザー操作の即時反映が要件で、SEOは不要だった。SSRはFCP/LCPなどの初期描画では有利だが、ハイドレーションのコストや運用負荷が増える。今回はSEOが不要で運用負荷を抑えたかったため、CSR中心のSPAを選択した」

質問2｜DBのスキーマ設計（テーブル分割・正規化・リレーション）を教えてください

■ よくあるNGな回答例

「ユーザーテーブルと投稿テーブルがあって、外部キーで繋いでいます」と、テーブル一覧を読み上げる形で答えてしまいます。「正規化はしました」と答えても、「第3正規形を意識しましたか？」と掘られると詰まります。「データが多くなったらインデックスを貼る予定です」と、事後対応の話で逃げてしまう人もいるでしょう。スキーマは説明できても、「なぜこのテーブル分割にしたのか」「なぜこのリレーションにしたのか」を設計判断として語れていません。

■ 面接官が見ているポイント

見られているのは、「アーキテクチャ選択は、ビジネス要件と非機能要件のトレードオフから導かれる」という基本原則を理解しているかです。モノリス vs マイクロサービス、サーバーレス vs サーバーフル、同期 vs 非同期処理などの選択は、すべて「何を優先し、何を犠牲にしたか」のトレードオフです。これを言語化できないと、「実装はできるが設計はできない人」と判断されてしまいます。

■ 回答の型

「業務要件→エンティティ抽出→リレーション設計→正規化判断→インデックス戦略」の流れで伝えましょう。業務要件からスキーマを導きます。

▼回答イメージ

「ユーザーが複数の投稿を持ち、投稿に複数のコメントがつく。1対多のリレーションが2段になるため、外部キー制約で参照整合性を担保した。正規化では、投稿テーブルにユーザー名まで重複して持たせると user_id→ユーザー名 の推移的従属が生じ、更新時に不整合が起きる。これを避けて user_id のみを保持し、第3正規形を満たした。検索性能のため、一覧の主クエリに合わせて (user_id, 作成日時) の複合インデックスを張った」

質問3｜APIの設計（REST/GraphQL・エンドポイント設計）を教えてください

■ よくあるNGな回答例

「RESTful APIで作りました」「GraphQLを使ってみたかったので」と、選定理由が表面的になってしまいます。「リソース指向で設計しました」と答えても、「ステートレスとは何か」と聞かれると、答えに窮しがちです。エンドポイント設計を聞かれると、「/api/users/:id/posts のような形にしました」とURLのパターンを答えます。ただ、HTTPメソッドの使い分けやステータスコードの設計まで踏み込めない学生が、多いのが実情です。API技術名は答えられても、「設計原則とアプリのユースケースの紐づけ」が語れていません。

■ 面接官が見ているポイント

見られているのは、「API設計は、クライアントとサーバーの契約」だと理解しているかです。RESTfulな設計は単なる慣習ではなく、リソース指向・ステートレス・統一インターフェースといった原則の集合体です。GraphQLは、オーバーフェッチやアンダーフェッチを解決する手段として使われます。設計原則を理解した上で、自分のアプリに当てはめたかが分かれ目になります。

■ 回答の型

「クライアントの要件（必要なデータ・取得頻度）→API方式の選定→エンドポイント設計の原則→個別エンドポイント」の流れで回答しましょう。規模感と要件の両方を語るのがポイントです。

▼回答イメージ

「ダッシュボードで関連データを一括取得したくGraphQLも検討したが、チームが2人で学習コストが高く、エンドポイントも10個以内と小規模だった。そのため、RESTを基本に、必要に応じてリソースをネストする設計に落ち着いた。一括取得が必要な画面は、専用の集約エンドポイントを用意して過剰なラウンドトリップを抑えた」

質問4｜ディレクトリ構成・モジュール分割の方針を教えてください

■ よくあるNGな回答例

「フレームワーク（Next.jsなど）の規約に従って構成しました」と、フレームワーク任せの答えになってしまいます。「コンポーネント・hooks・utilsで分けています」と答えても、「なぜその粒度で分けたのか」と掘られると詰まります。「機能ごとに分ける」と「レイヤーで分ける」の違いを聞かれて、答えられないことも多いものです。構成は説明できても、「分割の判断軸」が語れていません。

■ 面接官が見ているポイント

見られているのは、「コードの組織化は、チーム開発と保守性の基盤」だと理解しているかです。ディレクトリ構成は、単なるファイルの整理ではありません。「依存関係の方向」「責任の分離」「変更時の影響範囲」を規定する設計です。フレームワークが規約で吸収してくれる部分もありますが、任せきりだと規模が大きくなったときに破綻します。「規約に頼れる箇所」と「自分で構造を作る箇所」を理解しているかが大切です。

■ 回答の型

「分割の軸（機能 or レイヤー）→各モジュールの責任→依存関係の方向→採用判断」の流れで回答しましょう。選んだ軸と捨てた軸を明示します。

▼回答イメージ

「小〜中規模のアプリだったので、機能（feature）単位でディレクトリを切った。components/、hooks/、api/ のような技術レイヤー分割は、機能横断の変更が増えるため避けた。featureごとに完結する構成にし、変更の影響を局所化できるよう意識した。複数featureで使う共通部品は shared に切り出し、feature間の直接依存を避けて循環依存を防いだ」

質問5｜エラーハンドリング・例外処理の設計はどうしましたか

■ よくあるNGな回答例

「try-catchで例外をキャッチしています」と、実装レベルの話に逃げてしまいます。「エラーメッセージをユーザーに表示しています」と答えても、「どのエラーを、どこでハンドリングするか」の設計が見えません。「ロギングしています」と答えても、「何をログに残し、何を残さないか」の判断軸を持っていないケースが大半です。try-catchの実装は語れても、「エラーハンドリング戦略」が語れていません。

■ 面接官が見ているポイント

見られているのは、「エラーハンドリングは設計の一部」だと理解しているかです。どのレイヤーで例外をキャッチするか、ユーザーにどう見せるか、ログに何を残すか、リカバリ可能かをどう判断するか。これらは実装の問題ではなく、設計判断です。エラー時の動作を意図的に設計しているかが、分かれ目になります。

■ 回答の型

「エラーの分類（リカバリ可能／不可能・ユーザー起因／システム起因）→各分類のハンドリング方針→ロギング戦略→ユーザーへの表示」の流れで整理して回答しましょう。

▼回答イメージ

「『ユーザーの操作で回復できるか』を軸に分けた。入力・バリデーションのエラーはフォームの近くに即時表示する。認証切れや権限不足（401／403）は再ログインや適切な画面へ誘導する。ユーザー側では回復できないサーバーエラー（5xx相当）は共通エラーページに飛ばし、内部では構造化ログとして記録する設計にした。ログには発生時刻・リクエスト情報・スタックトレースを含め、後から原因を追跡できる形にしている」

質問6｜セキュリティ設計（認可・入力検証・脆弱性対策）は何か行っていますか

前提として、認証ライブラリの選定理由は第2章で扱いました。この質問6では、それを前提にした防御設計、つまり認可・入力検証・脆弱性対策を、どう設計したかに軸足を置きます。

■ よくあるNGな回答例

「認証はFirebase Authenticationで安全です」と、マネージドサービス頼りで答えてしまいます。「SQLインジェクション対策はORMを使っているので大丈夫です」と答えても、「XSS対策は何をしましたか」と掘られると詰まります。「認可と認証の違い」を聞かれて曖昧になるケースも多いのが実情です。個別の対策は語れても、「セキュリティ設計の全体像」が語れていません。

■ 面接官が見ているポイント

見られているのは、「セキュリティは個別対策の積み上げではなく、設計全体に組み込むもの」という理解があるかです。認証（誰か）・認可（何ができるか）・入力検証・出力エスケープ・通信暗号化・秘密情報の管理など、多層防御を意識しているか。一つの対策で安心している人は、実務に出ると危険な脆弱性を埋め込みかねません。

■ 回答の型

「脅威モデル（誰から何を守るか）→多層防御の層（認証／認可／入力検証／出力エスケープ／通信）→各層で実装したこと→残存リスク」の流れで説明しましょう。層ごとに語ると良いでしょう。

▼回答イメージ

「公開Webアプリなので、パブリックな攻撃対象になる。認証はFirebase AuthのIDトークンをAuthorizationヘッダで送る方式を採用した。認可はAPIサーバー側で、リソース取得時にユーザーIDを照合する（他人のIDを指定されても弾けるよう、毎エンドポイントで所有者チェックを徹底した）。入力はZodで、フロントとバックエンドの双方でバリデーションした（フロントは即時のUX向上、バックエンドは最終防御）。出力はReactのデフォルトエスケープでXSSを抑える。ただしdangerouslySetInnerHTMLやURLスキームはエスケープが効かないので個別に注意した。SQLはORMのパラメータ化で値をバインドし、文字列連結を避けた。残存リスクとしては、IDトークンはJSから触れXSS経由で窃取され得るが、トークンが約1時間で失効するため影響窓は限定的。出力エスケープの徹底を一次防御とし、加えて異常検知を継続監視する。認可ロジックの抜け漏れの定期的な見直しも、今後の課題として認識している」

質問7｜パフォーマンス設計（キャッシュ・N+1対策・非同期処理）は、どのようにしていますか

■ よくあるNGな回答例

「キャッシュを使いました」「N+1問題は気にしました」と、用語レベルの一般論で答えてしまいます。「React.memoで最適化しました」「画像を遅延読み込みにしました」と、個別Tipsの羅列になりがちです。「自分のアプリで実際に計測したパフォーマンス問題」を語れる学生は多くありません。知識は語れても、「実測→改善→再計測のサイクル」を経験として語れていません。

■ 面接官が見ているポイント

見られているのは、「パフォーマンス設計は推測ではなく計測」という鉄則を理解しているかです。「キャッシュは正義」「N+1は避ける」といった一般論ではなく、「自分のアプリで何が遅く、なぜ遅く、どう改善したか」を語れるかが分かれ目です。実装前から最適化に走るのは過剰設計、計測なしの改善は無駄打ちになります。

■ 回答の型

「計測した指標→発見したボトルネック→仮説→改善→再計測の結果」の流れで回答しましょう。計測の前後を語るのがポイントです。

▼回答イメージ

「ダッシュボードの表示に3秒かかっていた。Lighthouseで計測し、Largest Contentful Paintが遅いと判明した。LCP要素が大きなヒーロー画像で、その最適化不足が律速だと仮説を立てたので、Next.jsのImageコンポーネントに変更し、1.2秒に短縮した」

質問8｜拡張性・保守性を意識した箇所はありますか（将来の機能追加を見据えた設計）

■ よくあるNGな回答例

「将来、機能を追加できるように、疎結合に作っています」と、抽象的な答えになってしまいます。「コードをモジュール化しています」と答えても、「具体的にどう疎結合か」と掘られると詰まります。抽象的な答えはできても、「拡張性・保守性の具体的な仕掛け」を語れていません。

■ 面接官が見ているポイント

見られているのは、「過剰設計を避けつつ、必要な拡張性を確保できるか」です。すべてを汎用化すると複雑度が上がり、かえって保守性が下がります。「YAGNI原則（必要になったら作る）と、最低限の拡張性確保のバランス」が分かれ目です。ベテランほど「今は作らない」判断を大切にするため、若手の過剰設計はむしろ減点されます。

■ 回答の型

「予測した拡張ポイント→今回作り込んだ部分→作り込まなかった部分（YAGNI判断）→拡張時の作業見積もり」の流れで伝えましょう。「やった／やらなかった」を判断軸とともに語ります。

▼回答イメージ

「決済処理は、外部サービスへの依存を1か所に閉じ込めたかった。そこで、決済プロバイダとのやり取りをインターフェースで切り、本体から分離した。テスト時にモックへ差し替えやすくするためだ。一方、決済ロジック自体は要件になかったので作り込んでいない。追加が必要になっても、2〜3日で対応できる見込みだ」

4. 設計を語れる人と語れない人の違い

ここからは、評価される人とされない人の違いを3つの軸で整理します。前のセクションが「現象（どう評価されるか）」だとすれば、ここは「その差を生む考え方」、次の準備法は「差を埋める行動」です。なお、繰り返しになりますが、8問すべてに完答する必要はありません。3〜4問を自分の言葉で語れれば、十分に通用します。

違い1：構成の説明から入るか、判断根拠から入るか

語れない人は、「フロントとバックを分けて、間をREST APIで…」と、構成図を説明するところから始めます。

語れる人は、「ユーザー操作の即時反映が要件だったので、まずSPAが必要と判断した。バックエンドは…」と、要件と判断から始めます。

問われているのは「どう作ったか」ではなく「なぜそう作ったか」で、スタート地点が違います。

違い2：捨てた選択肢を語れるか

語れない人は、採用した構成だけを語ります。

語れる人は、「マイクロサービスも検討したが、開発人数が2人では運用負荷が高いと判断して見送った」のように、捨てた選択肢とその理由まで語ります。

捨てた選択肢を語れる人は、設計を「選んだ」のであって、「成り行きで決まった」のではないことが伝わります。

違い3：計測または観察した事実があるか

語れない人は、「N+1対策しました」「キャッシュを入れました」と、一般論レベルで語ります。

語れる人は、「Lighthouseで計測してLCPが3秒だったので、画像最適化を入れて1.2秒に短縮した」のように、測った数字や具体的な観察を語ります。

事実ベースで語れる人は、実装経験が「やった気になっている」レベルではないことが伝わります。

5. 設計判断を語れるようになるための準備法

最後に、設計判断を語れるレベルにするための準備法を解説します。「設計段階でここまで考えていなかった」という方も、当時を振り返り「こういう根拠があるからこの設計したのだ」「当時はこうしたが、今は〜〜を知っているのでこうする」と語れるようになれば問題ありません。

Step1｜ポートフォリオの「設計判断マップ」を作る

8つの質問それぞれについて、次の3つを整理しましょう。

1. 判断したこと（採用した設計）

2. 判断の根拠（要件・トレードオフ）

3. 捨てた選択肢（採用しなかった代替案）

回答を出せない質問があれば、それは面接で詰まりやすい箇所です。最初にお伝えした優先度に沿って、全て埋められるように準備しましょう。

Step2｜「過剰設計」を恐れない訓練

設計に自信がないと、「すべてに拡張性を持たせなければ」と過剰に作りがちです。これは、かえって評価を下げます。「今は作らない」という判断を、根拠とセットで語れるようにしましょう。たとえば、「決済機能は将来必要になるが、今は要件にないので作っていない。外部依存の境界だけは分離しておいた」のように伝えられれば問題ありません。

Step3｜実測の習慣を持つ

パフォーマンスやセキュリティ、コードの複雑度などは、Lighthouse、Chrome DevTools、ESLint、SonarLintなどのツールで実測する習慣を持ちましょう。実測した数字は、強い裏付けになります。

Step4｜設計を「他人の目」で見直す

模擬面接で設計を説明する前に、「自分の設計を、第三者として疑ってかかる」訓練をします。「なぜこの分割？」「なぜこのキー？」「なぜこのキャッシュ戦略？」と、自分でツッコミを入れてみましょう。

6. まとめ

設計の質問では、「構成」ではなく「判断根拠」を語ることが大切です。採用した設計だけでなく、捨てた選択肢とその理由を準備しましょう。一般論ではなく、自分のアプリで実測・観察した事実を語ると、説得力が増します。第2章で「何を選んだか」を固めた人は、本章でその選択を「どう設計に落としたか」まで語れる状態になっているはずです。

また、今回ご紹介した8問すべてに完璧に答える必要はありません。特にパフォーマンス（質問7）や拡張性（質問8）は、ポートフォリオの段階で語り切れなくても減点ではありません。1つでも、実測や判断の経験があれば十分です。

まずは8問分の設計根拠を洗い出し、埋まらない3〜4問を優先度順に潰していきましょう。