前回の続き——境界の次は「データの鮮度」
前回のI-09では、部品をサーバー側で動かすか、ブラウザ側で動かすかという境界を学びました。今回はその次の段階として、その部品が扱うデータそのものを、どこで取得し、どれくらい新しい状態に保つかを設計します。I-01で挙げたフロントエンドの5つの責務のうち、通信の仕上げにあたる回です。この設計を持たないと、速さと新しさのどちらかを必ず犠牲にしてしまいます。
このスライドのポイント
- I-09: サーバーコンポーネントとクライアントコンポーネントで「どこで動くか」を分けた
- 本講義: そのうえで「データをどこで取り、どれくらい新しく保つか」を設計する
- カテゴリIの5責務（I-01）のうち「通信」を仕上げる最終回
定義——データ取得の3つの設計
データ取得には3つの設計項目があります。1つ目は取得場所で、I-09で学んだサーバー側かクライアント側かの選択です。2つ目がキャッシュ、取得した結果を毎回取り直さず一定期間そのまま使い回す仕組みです。この発想は新しいものではなく、D-07のCache-Controlや、C-07のDNSキャッシュと同じ考え方の画面版です。3つ目が再検証で、古くなったキャッシュを取り直すことを指します。時間の経過で取り直す場合と、利用者の操作を機に取り直す場合があります。
このスライドのポイント
- 取得場所: サーバーコンポーネントで取るか、クライアント側で取るか（I-09）
- キャッシュ: 取得した結果を毎回取り直さず、一定期間そのまま使い回す仕組み
- 再検証: 古くなったキャッシュを取り直すこと（時間で、または操作を機に）
- キャッシュの発想はD-07のCache-Control、C-07のDNSキャッシュと同じ。その画面版
なぜ必要か——「更新したのに古いまま」を防ぐ
この設計を知らないと、2つの方向に失敗します。1つは、データを更新したのに一覧が古いまま表示される状態です。これはキャッシュを取り直す再検証を設計していないために起きる、最も多いつまずきです。もう1つは逆に、キャッシュをまったく使わず毎回取得しにいって、動作の遅いアプリになる失敗です。速さと新しさは引っ張り合う関係にあり、どちらか一方に寄せる正解はありません。だからこそ、データごとにつり合いを決める設計が要ります。
このスライドのポイント
- 再検証を設計しないと: 更新したのに一覧が古いまま（最頻出のつまずき）
- 逆にキャッシュを一切使わないと: 毎回取得して遅いアプリになる
- 速さ（キャッシュ）と新しさ（再検証）はつり合いの関係。データごとに決める
構造——3つの問いで決める判断フロー
設計は3つの問いを順にたどると決まります。まず、それは誰のデータかを問います。全員で共有してよいのか、利用者ごとに違うのかで扱いが変わります。次に、I-09の判断でどこで取得するかを決めます。最後に、どれくらいの鮮度が必要かを問います。この3問に答えると、キャッシュをどれくらい使い回すか、いつ再検証するかが定まります。とくに、利用者ごとに違うデータを、全員で共有するキャッシュに乗せないよう注意します。
このスライドのポイント
- 判断フロー（四角の枠と矢印）:
具体例——データの性質が設計を決める
具体例で見ます。自分の経費一覧は、申請した直後に自分の画面へすぐ反映されてほしいデータです。ですから、申請という操作を機に再検証します。一方、会社のお知らせは、1時間ほど古くても困りません。ですから、時間の経過で取り直す時間ベースのキャッシュが向いています。同じアプリの中でも、データの性質によって設計はこれだけ変わります。「全部すぐ取り直す」でも「全部使い回す」でもなく、データごとに決めるのが要点です。
このスライドのポイント
- 自分の経費一覧: 申請直後に自分の画面へ即反映したい → 申請操作を機に再検証
- 会社のお知らせ: 1時間古くても困らない → 時間ベースのキャッシュ
- 同じアプリでも、データの性質ごとに設計が変わる
技術サンプルカード——データ種別×3問の設計表
これが今回の中心となる設計表です。3種類のデータについて、取得場所・キャッシュ・再検証を並べています。自分の経費一覧は利用者ごとに違うため共有せず、操作を機に取り直します。会社のお知らせは全員で共有でき、時間ベースで取り直せば十分です。外部情報は、ごく短い間隔で取り直します。読み方の要点は、全部を毎回取得するのも、全部を使い回すのも設計の放棄だということです。データごとに決めます。
このスライドのポイント
- 種別: table
- 目的: データの性質ごとに「取得場所・キャッシュ・再検証」を決める設計表
- サンプル本体:
混同しやすい概念——「取得失敗」と「キャッシュが古いだけ」
混同しやすいのが、データの取得が失敗している状態と、キャッシュが古いだけの状態です。前者はH-07で学んだエラー状態で、そもそもデータが取れていません。後者は取得はできていて、ただ取り直す再検証が漏れているために、古い内容が残っている状態です。原因も直し方も違います。切り分けの第一問は、再読み込みで直るかどうかです。再読み込みで新しくなるなら、それは再検証漏れの側です。
このスライドのポイント
- 取得が失敗している（H-07のエラー状態）: そもそもデータが取れていない
- キャッシュが古いだけ（再検証漏れ）: 取得はできていて、古い内容が残っている
- 別の不具合。切り分けの第一問は「再読み込みで直るか」
バイブコーディングでの確認点
バイブコーディングでの確認点です。追加・更新・削除といった更新系の機能をAIに作らせたら、必ず「更新した後、関係する一覧の再検証はどこで行っていますか」と聞いてください。ここが抜けていると、更新は成功しているのに画面が古いまま、という不具合になります。なお、再検証を実際に動かすサーバー側の処理の中身はカテゴリJで扱います。この講義の段階では、再検証の指示がコードのどこかに入っているかどうかを確認できれば十分です。
このスライドのポイント
- 更新系の機能をAIに作らせたら「更新後、関係する一覧の再検証はどこで行っているか」を必ず確認
- 再検証を実際に動かすサーバー側の処理はカテゴリJで扱う。ここでは「再検証の指示があるか」を確認する
- AIへの質問例（下記）
一問一答とまとめ
最後に一問一答です。更新したのに一覧が古いまま表示される、その典型的な原因は何でしょうか。答えは、再検証漏れ、つまりキャッシュが古いまま取り直されていないことです。30秒でまとめます。データ取得は、どこで取るか、いつまで使い回すか、いつ取り直すかの3問で設計し、データの性質ごとに決めます。これでカテゴリIは修了、画面を動かす実装の一式が揃いました。次回からはカテゴリJ、これまで「サーバー側が担当」と抽象的に扱ってきた部分の実装へ進みます。関連資料は「Webアプリ構築 完全ワークフロー」と「エラー解決プロンプト50」です。
このスライドのポイント
- 一問一答: Q「更新したのに一覧が古いままの典型原因は？」→ A「再検証漏れ（キャッシュが古いまま）」
- 30秒まとめ: データ取得は「どこで取るか・いつまで使い回すか・いつ取り直すか」の3問。データの性質ごとに決める
- カテゴリI修了。画面を動かす実装の一式が揃った
- 次回: カテゴリJ、サーバー側の実装へ
- 関連資料: 「Webアプリ構築 完全ワークフロー」「エラー解決プロンプト50」
