技術設計面接の解説と模範解答｜toC向けWebメディア

技術設計面接（システムデザイン面接）のお題「toC向けWebメディア」を題材に、事前に押さえておく知識、面接で引き出せる前提、論点、模範解答、よくあるつまずきを順に解説します。

ほかのお題の解説は技術設計面接の解説と模範解答まとめにあります。

この記事で使う設計の基礎は、日本語のシステムデザイン面接の教材 SystemDesign InterviewCat で詳しく学べます。この記事の各節に関係する章は次のとおりです。

設計面接では、お題を聞いた時点で「たぶんこの作りだろう」という仮説を持ち、前提を聞くたびにそれを確かめたり崩したりします。Web メディアのお題なら、まず「記事の HTML をいつ、どこで作るか」の選択肢を押さえておきます。この選び方をレンダリング方式と呼びます。

読者が記事を開くまでの流れ

読者が記事の URL を開くと、リクエストは次の順に奥へ進みます。手前で答えが返せれば、それより奥には届きません。

• CDN：読者の近くの拠点に、ページの写し（キャッシュ）を置いて配る仕組み。写しには有効期限を付ける
• オリジン：CDN の裏にある、ページの元を置いたサーバーやストレージ
• キャッシュが当たる割合：読者のアクセスのうち、CDN の写しで返せた割合（ヒット率）
• LCP：ページを開いてから、主要な内容が表示されるまでの時間

HTML を作れる場所とタイミングは、事前に（ビルドや公開のとき）、アクセスのたびにサーバーで、読者のブラウザで、の 3 つです。レンダリング方式は、この 3 つのどれを使うかの違いです。

それぞれの方式で何が起きるか

同じ記事を読者が開いたとき、方式ごとに裏で起きることを並べます。

CSR（クライアントサイドレンダリング）：ブラウザはまず中身のほとんど無い HTML と JavaScript を受け取ります。JavaScript が API から記事を取ってきて、ブラウザの中で画面を組み立てます。ログイン後の管理画面のように、操作の多い画面に向いています。記事のように読むだけのページでは、JavaScript の読み込みと API の応答を待つ分だけ表示が遅れ、API が止まると中身が空になります。X や LINE で共有したときのリンクカード（OGP）は多くの場合 HTML だけを読んで作られるので、カードが空になりやすい点も弱みです。

SSR（サーバーサイドレンダリング）：アクセスのたびに、サーバーが DB や CMS から記事を読んで HTML を組み立てて返します。常に最新で、ログインした人ごとに中身を変えられるので、カートやマイページに向いています。CSR と比べると、データの取得がサーバー側で済むので内容が早く表示され、検索エンジンや SNS のリンクカードにも中身の入った HTML を渡せます。ただし、HTML を作り終えるまで応答が始まらないので、DB が遅いとその間は画面が白いままです。代わりに、5,000 人が開けば 5,000 回組み立てることになり、DB や CMS が止まると読めなくなります。

SSG（静的サイト生成）：公開の前にまとめて全記事の HTML を作り（ビルド）、ファイルとして置いておきます。読者には作り置きのファイルを返すだけなので速く、CDN にも載せやすく、DB が止まっても読めます。弱いところは、作った時点の内容で固定されることです。全員に同じ HTML を返すので、ログインした人ごとに中身を変えられません。記事を直しても、ビルドし直してファイルを置き直し、CDN の写しが入れ替わるまで読者には届きません。この遅れは、全件ビルドにすると記事が増えるほど長くなります。

ISR（インクリメンタル静的再生成）：SSG のように作り置きますが、ページごとに有効期限を決めておきます。期限が切れたあとに最初のアクセスが来ると、そのページだけを裏で作り直し、作り直している間は古いページを返します。全件ビルドを待たずにページごとに新しくなるので、SSG より新しい内容を出せます。それでも遅れは残ります。期限が 10 分なら、修正が読者に届くまで最大 10 分ほどかかります。さらに、期限が切れたあと最初に開いた読者には古いページが返り、新しいページが出るのはその次のアクセスからです。

オンデマンド再生成：ISR の一種で、期限を待たずに、記事を更新したときにこちらから「このページを作り直して」と指示します。修正はすぐ届き、指示がない間は写しを長く使えるので急増にも強くなります。その代わり、何が変わったらどのページを作り直すかを自分で管理する必要があります。Next.js では revalidatePath / revalidateTag にあたります。

エッジでの組み立て：ページを部品に分け、CDN の上で組み合わせて返します。たとえば本文は 1 日、金利の欄だけは 5 分、のように部品ごとに有効期限を変えられます。仕組みが複雑になり、使える CDN の製品も限られます。

方式名は Next.js などのフレームワークの機能名ですが、設計面接で比べたいのは名前ではなく、HTML をいつ作り、誰が作り直しのきっかけを作るかです。同じ考え方は、フレームワークを使わず自前の仕組みと CDN でも作れます。

方式を比べる

方式の違いは、「記事を直したとき」と「大勢が同時に開いたとき」の 2 つの場面に、「人ごとに中身を変えられるか」を加えて比べると分かりやすくなります。

表から分かるとおり、すぐ届く方式（CSR、SSR）は大勢が開くと裏側の仕事が増え、裏側の仕事が少ない方式（SSG、ISR）は修正が届くまでに時間がかかります。この 2 つを両立できるのがオンデマンド再生成で、代わりに作り直しの管理が要ります。一方で、作り置く 3 つの方式（SSG、ISR、オンデマンド再生成）は、どれも全員に同じ写しを返すので、人ごとに中身を変えられません。今回のお題では、将来の会員限定記事を考えるときにこの点が問題になります。

最初の仮説

お題文だけを読んだ段階では、次の仮説を置きがちです。どれも筋は悪くありませんが、前提を聞くと一部が崩れます。答え合わせは「隠れていた前提を見直す」で行います。

面接官から示されるお題は次のとおりです。

証券会社が運営する、20代向けにお金の情報を届けるWebメディアを作ることを考えています。記事を書いて法務の審査を通してから公開し、読者が記事を読んで口座開設ページへ移動できるようにしたいです。

▼このお題は CaseMatch の AI 面接で、面接官に前提を質問しながら練習できます。

前提は質問すれば答えてもらえます。面接で引き出せる前提を、レンダリング方式の選び方に関わるものとそれ以外に分けて並べます。種類の列は、機能要件、非機能要件、制約のどれにあたるかです。設計への影響の列は、次の節の問いを考えてから読んでください。

レンダリング方式の選び方に関わる前提

事前知識の比較表の 3 つの比べ方（直したときにいつ届くか、大勢が開いたときの裏側の仕事、人ごとに変えられるか）と、表示の速さ、裏側が止まったときに読めるかを決める前提です。

それ以外の前提

審査、権限、履歴、計測、体制のように、どの方式を選んでも別に設計が要る前提です。

お題文は「記事を書いて、審査して、公開する」としか言っていません。前提の表は、質問して初めて出てきたものです。設計への影響を見る前に、あらためて前提を読み直し、お題文の裏に何が隠れていたかを考えます。先に次の問いを考えてから、前提の表の「設計への影響」の列と見比べてください。

1. 前提のうち、互いにぶつかっている 2 つの組を 3 組挙げてください。
2. キャッシュを長く持ちたい理由と、短くしたい理由を、前提から 1 つずつ挙げてください。
3. 最初の仮説 1〜4 のうち、どれがどの前提で崩れますか。
4. お題文からは読み取れなかったのに、設計を一番大きく変えた前提はどれですか。

前提どうしのぶつかり

前提の多くは単独では難しくありません。難しいのは 2 つが互いに逆を向いているところで、このお題では次の 3 組です。これがそのまま、面接の後半で詳しく問われる 3 つの論点（深掘り）になります。

仮説の答え合わせ

このお題は記事を静的に配るだけのメディアに見えます。しかし実際に問われるのは、「審査を通っていない文言を一瞬も出さない」「古い金利を残さない」という金融ならではの正しさを、SNS での 50 倍の急増と両立させる設計です。

論点は 3 つあり、重さの順に配信とキャッシュ、編集と審査の流れ、変わる数字の分離です。どれも前提のうち 2 つが互いにぶつかっており、どちらをどう守るかを自分で決めて説明できるかが問われます。記事のデザインや SEO の細かい施策は評価の対象外です。

模範解答の深掘り（5〜7）では、論点ごとに「弱い答え」「よい答え」「より良い答え」を並べ、何が足りないかを示しています。

面接での問答の順には合わせず、このお題への答えを 1 つの設計としてまとめた解答例です。設計の筋は、読者のアクセスから DB と CMS を外し、審査を通った版だけから静的なページを作って CDN で配り、何かが変わったときは影響するページだけ作り直す、というものです。前提に無いことは仮定として置き、その旨を書いています。

1. 作る範囲

前提を確かめたうえで、最初に作る範囲を次のように切ります。

• 作る：執筆とプレビュー、法務の審査、公開と非公開、記事の配信、金利と手数料の差し込み、注意文言の一括反映、記事単位の遷移計測、修正履歴の保存
• 作らない：会員機能、コメント欄、口座開設ページそのもの、記事のおすすめ機能

編集ツールは外部のヘッドレス CMS を使います。何を公開してよいかの判定と修正履歴は CMS に持たせず、自前の小さな公開サービスに持たせます。

2. 見積もり

見積もりで出すのは、構成を決める 3 つの数字だけです。どれも前提の値から計算できます。

CDN からの削除は 1 秒もかからずに全拠点へ届くので（Cloudflare）、5 分以内の公開には間に合います。

3. データモデル

版は書き換えず、記事の「公開中の版 ID」がどの承認済みの版を指すかで、読者に出すものを決めます。中心になる表は次の 4 つです。

公開、非公開、巻き戻しは、どれも公開中の版 ID を付け替えるだけです。非公開は空にし、巻き戻しは前の承認済みの版に戻します。どちらも新しい文言を出さないので、審査なしで実行できます。

4. 全体構成

読者が記事を開くときに通るのは CDN とオブジェクトストレージだけです。編集、審査、数字の更新はすべてその裏で非同期に動き、結果として静的な HTML を書き換えます。

色を付けた公開サービスがこの設計の要で、生成ワーカーはここで承認された版しか読めません。

1. CMS：編集部と外部ライターが下書きを書き、プレビューして審査を依頼します。本文には金利の値ではなく、商品 ID と項目を指す差し込み記号を置きます。
2. 公開サービス（自前）：版、承認、公開中の版 ID、参照表を持ちます（3 の表）。操作の記録は追記のみのストレージに 5 年残します。
3. 生成キューと生成ワーカー：公開、修正、非公開、数字の変更、注意文言の改定を受けて、承認済みの版とその時点の数字から HTML を作り、ストレージに置きます。置いたあと、CDN の該当キャッシュを消します。
4. オブジェクトストレージと CDN：読者への配信です。オリジンは静的ファイルなので、CMS や DB が止まっても読めます。
5. 数字の同期：毎日、商品データ API から金利と手数料を取り、取得日時つきで保存します。前日と変わった商品だけを生成キューに流します。
6. 計測：口座開設へのリンクに記事 ID と配置位置を付け、クリックを計測用の受け口へ送ります。口座開設側には受け取った記事 ID を申込データと一緒に残してもらい、分析基盤で突き合わせます。

版と承認の記録は RDB に、公開の操作ログは追記のみのストレージに保存します。キューとワーカーはマネージドのものを使い、2 名で常駐のサーバーを見る必要をなくします。

実例：英国政府の GOV.UK は、編集アプリと配信の間に公開を司る Publishing API を置き、配信用のストアを下書き用と公開用の 2 つに分けています（GDS, 2016）。The New York Times は公開済みの全記事を書き換えないログとして持ち、配信側はそのログから自分のストアを作り直せるので、CMS に毎回問い合わせません（NYT / Confluent, 2017）。

代わりの案：生成キューとワーカーを自前で持たず、Next.js のオンデマンド再生成（revalidateTag）をマネージドな基盤で動かす構成も同じくらい有力です。その場合も、ページのデータは公開サービスの承認版 API からだけ取り、revalidateTag は公開サービスから呼びます。承認版だけを出すことと、タグで差分だけ入れ替えることという設計の要点は変わりません。どちらにするかは、社内のセキュリティ審査と既存の CDN 契約で決めます。違いは、一斉改定のときに先に全ページを作っておくか（自前）、次のアクセスで作り直すか（Next.js）です。

5. 深掘り：配信とキャッシュ

記事ページは公開のときに記事単位で生成し、CDN では長めにキャッシュして、変わったときだけこちらから消します。最初の仮説の 1 と 2 は、ここで崩れます。CDN に載せる点は残し、鮮度の決め方だけを「時間」から「変更のきっかけ」に替えます。

より良い答えの中身は次のとおりです。

• キャッシュにタグを付ける：ページごとに、記事 ID、使っている商品 ID、注意文言 ID、載っている一覧のタグを付けます。記事を直したらその記事のタグ、金利が変わったらその商品のタグを指定して消します。URL を 1 件ずつ消すと、トップやカテゴリ一覧の消し忘れが起きます。
• 生成を先、公開を後にする：HTML を作ってストレージに置いてから、一覧からリンクし、キャッシュを消します。まだ生成していない記事へのアクセスがオリジンで組み立てられることはありません。未公開 URL の 404 は短い期限でしかキャッシュしません。
• 期限切れ直後の集中を避ける：期限切れのあとも古いページを返しながら裏で取り直す設定（stale-while-revalidate）と、同じ URL への取得を 1 本にまとめる機能を使います。まとめきれずにオリジンへ届く取得が少しあっても、オリジンは静的ファイルなので耐えられます。
• 急増の前に温める：SNS で広がるのは公開直後が多いので、公開したら主な拠点の CDN に一度取得させておきます。
• キャッシュキーから計測用のパラメータを外す：SNS からの流入は URL に広告や共有元のパラメータが付き、そのままだとパラメータごとにキャッシュが分かれます。見積もりのとおり、当たる割合が 99% から 90% に下がるだけでオリジンへの取得は 10 倍になります。
• LCP を守る：HTML は静的なので、残るのは画像です。生成時に幅ごとに縮小した軽い形式を用意し、最初に見える画像だけ先に読み込み、計測のスクリプトは表示のあとに読みます。

この構成で最初に詰まるのはオリジンではなく、注意文言の改定のように 1 万ページをまとめて作り直すときの生成キューです（見積もりで数分）。並列数を絞って流し、その間に入った記事の公開や修正は別の優先キューで先に処理します。

実例：ページにタグを付けてまとめて消す方式は、Fastly が Surrogate Key として解説しています（Fastly, 2013）。Cloudflare はタグを指定した削除が世界中に届くまでを中央値 150ms 未満にしています（Cloudflare, 2024）。公開をきっかけにそのページだけ作り直す仕組みは Next.js が On-demand ISR として入れており、用途にヘッドレス CMS で記事を更新したときを挙げています（Next.js 12.1, 2022）。同じ URL への取得を 1 本にまとめる機能とその限界は Fastly, 2025、stale-while-revalidate と stale-if-error は Fastly, 2014 にあります。

6. 深掘り：編集と審査の流れ

公開できるのは、法務が承認した版そのものだけです。状態のフラグではなく、書き換えられない版と、その版を指す公開中の版 ID で守ります（3 のデータモデル）。

1. ライターが審査を依頼すると、公開サービスはその時点の本文、注意文言 ID、差し込み記号を 1 つの版として保存し、内容のハッシュを記録します。
2. 法務はその版のプレビューを見て承認します。承認は版 ID とハッシュに紐づき、承認者と日時を残します。
3. 承認されると、記事の公開中の版 ID がその版に変わり、生成キューに流れます。
4. 承認のあとに CMS で本文を直すと、それは新しい下書きになります。公開中の版は変わらず、新しい版が再審査を通るまで前の版を出し続けます。

この仕組みを破らせないために、生成ワーカーには承認済みの版を読む権限しか持たせず、CMS の下書きを直接読めないようにします。外部 CMS の公開ボタンを押しても、読者には何も届きません。

• プレビュー：公開と同じ生成器で作り、認証つきの別ドメインに出します。検索エンジンにも拾わせません。法務は公開後と同じ見た目、同じ金利で審査できます。
• 外部ライターの権限：記事ごとに担当者を持たせ、担当記事の下書きの編集と審査依頼までに限ります。承認、非公開、巻き戻しは編集部と法務だけができます。
• 修正履歴：承認した版と、公開、非公開、巻き戻しの操作を追記のみのストレージに 5 年残します。外部 CMS の履歴は、保存期間や契約の都合で消え得るので頼りません。

未審査の文言を出さない条件と、誤りをすぐ直す条件がぶつかるところは、すぐにできることを新しい文言を足さない操作（非公開、直前の承認版へ戻す）に限って解きます。どちらも審査を通った文言しか出さないので、編集部の責任者が審査なしで実行でき、数分で反映されます。そのうえで修正版は優先審査に回します。法務が 2 名しかいないので、修正だけは当日中に見るという取り決めを、仕組みとは別に法務と結んでおきます。金利の誤りは本文の修正ではなく、次の節の数字の差し替えで直ります。

実例：GOV.UK では、記事 1 件が持てるのは下書き 1 件、公開中または非公開 1 件、置き換わった過去の版だけです。公開した版は書き換えず、変更は新しい下書きとして作ります。取り下げにも、注記つきで残す、転送する、410 を返すなどの種類があり、誰がいつ何をしたかをログに残します（GOV.UK Publishing API）。プレビューは公開用と別に下書き用の配信一式を立て、認証と期限つきの共有 URL で見る人を絞っています（GOV.UK Content Preview）。

7. 深掘り：変わる数字の分離

金利と手数料は本文に書かず、数字の表に一か所で持ち、ページの生成時に埋め込みます。

• 本文には「どの商品のどの項目か」を指す差し込み記号を置きます。ライターは CMS 上で商品と項目を選ぶだけで、数字を手で打ちません。
• 生成ワーカーは、実際に差し込んだ商品 ID から参照表を作ります。記事だけでなく、比較表や一覧も同じように記録します。
• 毎日の同期で前日と値が変わった商品を拾い、参照表からその商品を使うページだけを生成キューに流し、商品のタグで CDN を消します。
• 数字には取得日を添え、「○月○日時点」と表示します。

数字の値そのものは商品データ API の公式の値なので、記事ごとの審査の対象にはしないと仮定します。審査するのは、数字を囲む文言と表示の形式です。この仮定は法務と合意が要るので、面接では確認したい点として口に出します。

読者のブラウザから数字を取りに行く方式は採りません。表示のあとに数字が入るので LCP とレイアウトのずれに響き、API が止まると数字が空になります。急増の 5,000 req/s が社内の商品データ API にそのまま届くことにもなります。

注意文言も同じ仕組みで扱います。文言は ID で参照し、改定は文言の新しい版を法務が 1 回承認するだけです。承認されたら、参照表からその文言を使う過去記事をすべて生成キューに流します。

実例：GOV.UK は以前、リンク先の内容をアクセスのたびに展開していましたが、遅く規模も伸ばせなかったため、公開時に展開して依存関係を DB に持つ方式に変えました（GDS, 2016）。今は、あるページが変わるとそれを参照するページを逆にたどって配信用のストアへ送り直しています（GOV.UK Dependency resolution）。この節の参照表と同じ考え方です。複数のタグを 1 回で消せるので、注意文言の改定のような一括の入れ替えも CDN 側は少ない回数で済みます（Fastly, 2017）。

数字の部分だけをページの断片にし、エッジで組み立てて断片ごとに期限を変える方式もあります（Fastly, 2022）。数字を載せるページが増えて作り直しが重くなったときの次の手として挙げられると、弱いところとその手当てまで言えます。

8. 障害への備えと監視

どこが止まっても、読者には最後に作ったページが見え続けます。例外は古い金利で、古い値を出し続けるより隠すほうを選びます。

監視するのは、CDN のエラー率とキャッシュが当たった割合、生成キューの滞留、数字の取得日の古さです。加えて、公開中のページが承認した版から作られたものかを定期的に突き合わせます。

9. 条件の変更への対応

面接の後半では、運用で起きた不具合や将来の要望という形で条件が足されます。答え方は、今の設計でなぜ起きたか、何をきっかけに何をどう処理して直すか、変えずに済むところはどこか、の順です。

例 1：金利を直したのに、一部の読者に古い金利が出ていた

• 原因：記事ページは作り直したが、金利を載せていた比較表や一覧のページが参照表に入っていなかった。もしくは CDN の削除が失敗し、再試行されていなかった。
• 直し方：参照表を、生成時に実際に差し込んだ商品 ID から全ページについて記録します。CDN の削除はキューに載せて再試行し、削除のあとにその URL を取得して、埋め込んだ取得日が新しいことを確かめます。保険として、数字を載せるページはキャッシュの期限を 1 日より短くします。
• 変えずに済むところ：審査の流れと配信の構成です。

例 2：口座を持つ人だけが読める会員限定記事を出したい

• 影響：今は全員に同じ HTML を配っているので、会員向けの本文を同じキャッシュに載せると誰でも読めてしまいます。
• 直し方：リード文と注意文言までは今と同じ静的なページにし、会員向けの本文だけを認証つきの経路から返して、共有キャッシュには載せません。口座の有無は口座開設側のシステムしか知らないので、別ドメインをまたいだ認証の連携を別チームと決める必要があり、ここが一番時間のかかるところです。
• 変えずに済むところ：審査、数字の分離、計測、公開記事の配信です。記事の表の公開範囲を使うだけです。

実例：ドイツの Die Zeit は、無料か有料かと購読者かどうかをエッジで判定し、本文全体か購読の案内かを出し分けながら、キャッシュが当たる割合を 9 割超に保っています（Fastly の導入事例）。会員限定を共有キャッシュに載せない今回の案より一歩進んだ形で、アクセスが増えたときの選択肢になります。

まとめ：選んだものと捨てたもの

▼解説を読んだら、同じお題を AI 面接官を相手に通しで解いてみましょう。

海外の技術ブログと技術文書です。どれも開いて内容を確かめています。CDN 事業者の記事は自社製品の紹介を兼ねており、GOV.UK は企業ではなく英国政府の開発チームです。

▼ほかのお題の解説

サカモトエンジニア監修

外資系企業のソフトウェアエンジニア。エンジニアのキャリアや面接について X や note で発信し、テック企業を目指すエンジニア向けの面接対策プラットフォーム InterviewCat を運営しています。