綴Photo の web 版を、開発用のモック（仮データ）から本番の実データに繋ぎ替えている途中の話。移行作業で踏んだ、モックのうちは絶対に出ないバグの記録です。
リストは実データに切り替わったのに、そこをクリックして開く詳細画面だけが空になった。原因は、詳細画面が中で使っていた関数が 「モック専用」 に作られていて、本番のデータを想定できていなかったこと。モックのうちは絶対に出ず、本番に繋いだ瞬間だけ出るバグだった。
今回の「リストは実データなのに詳細だけ空」も、動作確認の途中で引っかかった。原因の切り分けと直しは、そこから AI と詰めた。
ドックのカウントもサムネも、ちゃんと実データの数になった。ここまでは順調に見えた。でもサムネを押すと、横から滑り込んでくる詳細画面が、中身ゼロのまま開いた。
この記事で見ていく点
- 取得口を本番に替えても、その先の「クリックで開く詳細画面」がモック専用の関数を使っていると壊れます
- 「id を渡して中身は関数に引かせる」設計は、モックのうちは動くが本番データで破れます
- 直すなら、引き直させずに「呼び出し側が既に持っている中身」を渡します
差し替えは1行。壊れたのは「その先のクリック」
ドックと本棚の☆棚が読んでいたのは、モックのダミーを返すフック（useFavorites）だった。それを、前回作った本番データのフック（useRemoteFavorites＝ backend の GET /api/favorites/ を読むやつ）に差し替えてもらう。付け替えるのは、呼び出しの1行だけだ。
// 取得口をモック→本番に差し替える（これが「差し替えは1行」）
// const { favorites } = useFavorites(); // ← モックのダミーを返すフック
const { favorites } = useRemoteFavorites(); // ← GET /api/favorites/ を読むフックこれでリストの見た目は実データになり、カウントも合います。
問題は、サムネを押したときに開く詳細画面だった。写真・綴った言葉・気分を大きく見せる帯が、何も表示しない。リストは実データなのに、その1枚を開くと空。
なぜ空になったか: 詳細画面はモック専用の関数で中身を引き直していた
詳細画面のコンポーネントは、photoId（id）だけを受け取る作りだった。中身は受け取らず、id を鍵に自分で引き直します。
// 詳細画面は id だけ受け取り、中身(写真URL・言葉・気分)は getPhotoById で引き直していた
const photo = getPhotoById(photoId);この getPhotoById が見にいくのは、モックのサンプルデータの索引です。つまり「モック専用」に作られた引き直し関数。リストもこの関数も同じモック索引を見ているうちは、id さえ合えば中身が出ます。
ここで気づいたのは、自分が差し替えた取得口は「リスト」だけで、もう1か所、同じデータを別ルート（モック専用の関数）で取りにいく場所があったということ。詳細画面の id 引きが、隠れた2つ目の結合点だった。リストの末端だけ見て「本番化できた」と思っていた。
直し方: 引き直さない。手元にある中身を渡す
ドックも本棚も、リストを描くためにお気に入りの中身を既に持っています（本番のフックが中身ごと取ってきています）。詳細に id だけ渡して引き直させるのをやめて、その中身をそのまま渡します。フォールバックの口を1つ足してもらった。
// サンプル索引に当たればそれ(従来の挙動)、無ければ呼び出し側が渡した中身で描く
const sample = getPhotoById(shown.id);
const view = sample ?? fallback; // fallback = リストが既に持っているお気に入りここで getPhotoById は消していない。本棚のデモ用写真はまだモックの索引にしか無く、そこは従来どおり引けるので経路を残した。**「モック専用の関数を消す」のではなく「それに頼るのをやめて、手元の中身に倒す」**という直し方だ。
本番のお気に入りには出所の本がまだ無いし、付け外しを backend に書き戻す経路もまだ作っていない。中身が無い・書き込み先が無い操作ボタンを置くと、押せるのに何も起きない誤解を生みます。だからフォールバックのときは見せて読むだけにした。
学びポイント
- データを本番に替えるときは、リストの末端だけでなく「その先で同じデータを別ルートで引いている所」を探します。
id を鍵に関数で引き直すは、表に出てこない結合になります - 引き直させる代わりに、呼び出し側が既に持っている中身を渡せば、索引がモックのままでも壊れません
- フォールバックで欠ける情報（出所・書き戻し先）に紐づく操作は、その場では出しません。押せるのに何も起きないボタンは置きません
このテーマの括り
設計としては、コンポーネントに「id を渡して関数に引かせる」か「中身を渡す」かの選択で、モックの間はどちらでも同じように動きます。差が出るのは本番に繋いだ瞬間だけだった。関数に引かせる作りは、その索引がデータの唯一の出所であり続けることに静かに依存していて、出所が複数になった途端に切れます。
直しは AI に書いてもらった。ただ今回自分に残ったのは、そこじゃない——モックで組むときに繋ぎ合わせを無理やり通してしまうと、本番に移したところで壊れる、という感覚のほうだ。本番を想定して繋いでいるつもりでも、細かいところまでは想定しきれません。こういうのは気づいたタイミングで直せば問題ない、とも思う。
AI に手伝ってもらっているとはいえ、動作確認と検証を自分の側で握っているうちは、ちゃんと勉強になります。AI でも抑えにくいところの解像度が、こうやって1つずつ上がっていきます。実務と同じ——だと信じたい。
次は、画像経路と、お気に入りの付け外しの書き戻しも本番側に寄せていく。
この記事は2026年6月時点の自分の理解で書いています。仕様や認識が変わってる可能性があります。