Shimanami RouteLab｜しまなみ海道のスポット紹介サイトを個人開発

"use client" はどこに書くのか——エラーが出るたびにつけ足していたら全部 Client Component になっていた

2026-04-17T13:59:39+09:00

サーバー領域（緑）でgetAllSpots()を実行してSpotを取得し、クライアント領域（紫）のHomeClient・SpotsListClientにpropsで渡します。MapboxやuseStateなどブラウザ専用の処理（オレンジ）はツリーの末端に置きます

以前、fs を使ったらビルドエラーが出た話を書きました。

mojitonews.hateblo.jp

あのときは「fs はサーバー専用だから Client Component で呼べない」という原因にたどり着いて終わりました。ただその後も同じ問題を別の形で踏み続けました。エラーが出る → とりあえず "use client" を先頭に追加 → 直る。この繰り返しをしているうちに、気づけばプロジェクトのほぼ全コンポーネントに "use client" がついていました。「Pages Router のときは全部クライアントだったんだから、同じでいいんじゃないの？」と思っていました。

今回はその先——「では "use client" はどこに書くべきか」という設計の判断基準を、実際のコードで整理します。

App Router の役割分担はシンプル

考え方の基本はこうです。

データ取得・ファイル読み込み → Server Component でやる
インタラクション（useState・イベント） → Client Component でやる

問題は「それがコードとしてどう表れるか」が最初はイメージしにくいことです。実際のファイルで確認します。

地図ページの場合（/map）

// src/app/map/page.tsx（Server Component・"use client" なし）
import HomeClient from "@/components/HomeClient";
import { getAllSpots } from "@/lib/spotsData";

export default function MapPage() {
  const spots = getAllSpots(); // サーバーで実行される

  return (
    <main className="relative h-[calc(100dvh-60px)] overflow-hidden">
      <Suspense fallback={null}>
        <HomeClient spots={spots} /> {/* Spot[] を props で渡す */}
      </Suspense>
    </main>
  );
}

// src/components/HomeClient.tsx（Client Component）
"use client";

import PowerMap from "@/components/PowerMap";

export default function HomeClient({ spots }: { spots: Spot[] }) {
  return (
    <>
      <section className="h-full">
        <PowerMap spots={spots} /> {/* Mapbox はブラウザ専用APIを使う */}
      </section>
    </>
  );
}

page.tsx はデフォルトで Server Component なので "use client" は書きません。getAllSpots() がサーバー上で実行され、結果の Spot[] 配列を HomeClient に props として渡します。HomeClient は "use client" を持ち、Mapbox（WebGL を使うブラウザ専用ライブラリ）を動かします。

スポット一覧ページの場合（/spots）

// src/app/spots/page.tsx（Server Component）
export default function SpotsPage() {
  const spots = getAllSpots(); // サーバーでファイル読み込み

  return (
    <main>
      <SpotsListClient spots={spots} />
    </main>
  );
}

// src/components/spots/SpotsListClient.tsx
"use client";

export default function SpotsListClient({ spots }: { spots: Spot[] }) {
  const [query, setQuery] = useState(""); // テキスト検索

  const filtered = useMemo(() => {
    const q = query.trim().toLowerCase();
    if (!q) return spots;
    return spots.filter(
      (s) =>
        s.name.toLowerCase().includes(q) ||
        s.shortDescription?.toLowerCase().includes(q) ||
        s.tags?.some((t) => t.toLowerCase().includes(q))
    );
  }, [spots, query]);

  // ... 島別グルーピング・表示
}

SpotsListClient は useState（検索クエリ）と useMemo（フィルタリング）を使うので "use client" が必要です。でも getAllSpots() は呼びません。サーバー側の page.tsx が呼んで渡してくれます。

「全部クライアントにする」の何が問題か

純粋にエラーが出なければ動くんじゃないか、と思うかもしれません。問題は2つあります。

1. fs などのサーバー専用モジュールをバンドルできない

"use client" をつけたコンポーネントが fs をインポートすると、Webpack はそれをブラウザ向けバンドルに含めようとしてエラーになります。ブラウザに fs は存在しないからです。

2. Server Component の恩恵が消える

Server Component はレンダリング結果を HTML としてサーバーで生成します。JavaScript をブラウザに送らなくて済みます。"use client" をつけると、そのコンポーネントの JavaScript がすべてブラウザに届きます。コンポーネントが増えるほどバンドルサイズが膨らみます。

"use client" をどこに書くべきか

整理するとこうなります。

状況	"use client"
useState / useEffect を使う	必要
onClick などのイベントハンドラを使う	必要
Mapbox など WebGL・DOM API を使うライブラリ	必要
fs でファイルを読む / DB にアクセスする	不要（サーバー専用）
ただデータを受け取って表示するだけ	不要

コンポーネントツリーの「葉」に近い部分——インタラクションが必要な部分だけに "use client" を置く。データ取得は根（page.tsx など）でやってから props で流す。これが App Router の設計の意図です。

「サーバーでデータを取って、クライアントでインタラクションする」という役割分担を意識するようになってから、エラーが出るたびに "use client" をつけ足すのではなく、「このコンポーネントはどちらに属するか」を先に考えるようになりました。その一つの判断が、開発のスピードと品質を変えていくと実感しています。

猫の細道を訪れてMDXでサイトに追加した——frontmatterが地図ピンになる仕組みと画像管理

2026-04-17T07:46:32+09:00

猫の細道を訪れてMDXでサイトに追加した——frontmatterが地図ピンになる仕組みと画像管理の話

現地に行って写真を撮り、帰ったらMDXを書くだけでサイトが更新できる。しまなみ海道の観光ガイドサイトをNext.js 15で個人開発していて、この運用が実際に成立した話です。

猫の細道に行ってきた

尾道の山手にある猫の細道は、幅1〜2m・全長約200mの石畳の路地です。千光寺へと続く坂道の途中にあり、古い民家の壁や石垣に沿って続く細い路地に、猫にまつわるオブジェや陶器が点在しています。

訪れたのは早朝5時50分。観光客がまだ誰もいない時間帯で、石畳に自分の足音だけが響いていました。猫の横丁の入り口にある受付小屋には「CLOSE」の看板が出ていて、その真横に1匹の猫が座っていました。こちらをじっと見ています。まるで「今日はまだ開いていないよ」と監視しているようで、看板との位置関係が絶妙すぎて思わずカメラを向けました。

標準レンズで1枚、望遠で引き寄せてもう1枚。表情がはっきり見えた望遠の写真の方が気に入ったので、こちらをサムネイルに使うことにしました。

CLOSE看板の真横に座ってこちらを監視するように見つめる猫。引き（左）と望遠（右）で収めました

このサイトのコンテンツ管理はMDXで完結している

このサイトのスポットページは content/spots/ 以下の .mdx ファイルで管理しています。猫の細道なら content/spots/neko-no-hosomichi.mdx が対応するファイルです。

ファイルの前半はfrontmatterで、スポットのメタ情報を書きます。

---
id: neko-no-hosomichi
name: 猫の細道
island: onomichi
lat: 34.41044813852006
lng: 133.1998058010011
shortDescription: "尾道山手の石畳路地（幅1〜2m・全長約200m）に..."
thumbnail: /spots/neko-no-hosomichi/neko-no-hosomichi-morning-cat-guard-telephoto.jpg
images:
  - src: /spots/neko-no-hosomichi/neko-no-hosomichi-morning-cat-guard-telephoto.jpg
  - src: /spots/neko-no-hosomichi/neko-no-hosomichi-stone-steps-summer.jpg
---

id がURLスラッグ（/spots/neko-no-hosomichi）になり、lat と lng が地図のピン位置になります。images に並べた順がギャラリーの表示順です。

frontmatterが地図ピンに変わる仕組み

frontmatterに書いたlat・lngが地図ピンの位置に変換されます。スポットを追加するたびに地図は自動で更新されます

getAllSpots() は content/spots/ の .mdx ファイルを全件読み込み、frontmatterだけを取り出して返すサーバー専用の関数です。

// src/lib/spotsData.ts（サーバー専用・fsを使うためクライアント不可）
export function getAllSpots(): Spot[] {
  return fs
    .readdirSync(CONTENT_DIR)
    .filter((f) => f.endsWith(".mdx") && !f.startsWith("_"))
    .map((f) => readSpot(f));
}

_ で始まるファイルを除外しているのは、_template.mdx（新規スポット追加用のテンプレート）を一覧に混入させないためです。

取得した Spot[] をサーバーコンポーネントから地図コンポーネントにpropsとして渡し、lat と lngを使ってMapboxのGeoJSONに変換してピンを描画しています。新しいスポットのMDXファイルを追加するだけで、地図のコードを一切触らずにピンが増える仕組みです。

本文にはMarkdown + JSXコンポーネントが書ける

MDXの強みは、Markdownの中にReactコンポーネントを直接書けることです。

このサイトには <SpotImage> と <SpotImageRow> という2つのカスタムコンポーネントがあります。<SpotImage> は画像を1枚表示し、<SpotImageRow> は2枚を横並びにします。

// src/components/mdx/SpotImageRow.tsx
export function SpotImageRow({ children }: { children: React.ReactNode }) {
  return <div className="grid gap-3 sm:grid-cols-2">{children}</div>;
}

今回の監視猫は標準版と望遠版の2枚があったので、MDX上でこう書きました。

<SpotImageRow>
  <SpotImage
    src=".../neko-no-hosomichi-morning-cat-guard.jpg"
    alt="猫の横丁・受付CLOSE看板の横で座る猫——2026年4月11日 午前5時50分撮影"
    caption="CLOSE看板の真横に座っていた猫。"
  />
  <SpotImage
    src=".../neko-no-hosomichi-morning-cat-guard-telephoto.jpg"
    alt="猫の横丁の受付横の猫を望遠撮影——2026年4月11日 午前5時50分"
    caption="望遠で引き寄せると表情がよくわかります。"
  />
</SpotImageRow>

カスタムコンポーネントをMDXRemoteに渡す

<SpotImage> などのカスタムコンポーネントは、mdxComponents オブジェクトにまとめて MDXRemote に渡します。

// src/components/mdx/index.tsx
export const mdxComponents = {
  SpotImage,
  SpotImageRow,
  // Markdownの標準要素も上書きしてスタイルを統一
  h2: ({ children }) => <div className="mt-6 border ..."><h3>{children}</h3></div>,
  p:  ({ children }) => <p className="text-sm leading-relaxed ...">{children}</p>,
  table: ({ children }) => <div className="overflow-x-auto"><table ...>{children}</table></div>,
};

h2 や table などMarkdownの標準要素もここで上書きしており、記事内のテーブルやリンクのデザインをサイト全体で統一しています。

実際の追記作業はこれだけ

やったことをまとめると5ステップです。

画像4枚を日本語ファイル名→英語にリネーム（URLエンコード対策）
public/spots/neko-no-hosomichi/ に配置
MDXに新セクションを書く（Markdown + <SpotImageRow>）
frontmatterの thumbnail と images[0] を監視猫の望遠写真に変更
git push → Vercelが自動デプロイ

コードを1行も書かずにページが更新できました。「現地で写真を撮って帰ったらMDXを書くだけ」という運用が成立しているのは、コンテンツ管理をMDXに寄せてコードと分離した設計にしたからです。観光スポットが増えるたびにこの流れを繰り返せます。

実際に手を動かして現地取材からデプロイまでを一通りやってみると、設計の意図が改めて腑に落ちます。「なぜfrontmatterにlat・lngを入れたのか」「なぜMDXにしたのか」は、コードを読んでいるだけでは実感しにくく、実際にスポットを追加してみて初めてわかることでした。

もう一つ気に入っているのは、後からいつでもセクションを追記できる点です。昼間に再訪して別の猫に会えたり、季節が変わって風景が変わったりすれば、同じMDXファイルに書き足してpushするだけです。データベースもCMSの管理画面も不要で、「また行ったら更新しよう」という気軽さで運用できています。

もちろん、WordPressやはてなブログのような既存のサービスを使えばもっと手っ取り早いのは事実です。ただ、自分でサイトを設計してコードを書くことで「なぜこの設計にしたのか」が体で理解できる副産物があります。技術を磨きながらサイトを育てていける、というのが個人開発を続けている一番の理由かもしれません。

mojitonews.hateblo.jp

async/await と .then() チェーン——しまなみ海道観光サイトで両方使い分けた理由

2026-04-15T22:19:34+09:00

ピンをタップすると吹き出し型のポップアップが表示され（左）、詳細を見るボタンからボトムシートが開いてホテルの空室確認や詳細情報を確認できます（右）

JavaScriptの非同期処理を書くとき、async/awaitと.then()チェーンのどちらを使うか迷ったことはありませんか？

「async/awaitの方がモダンだから常にそっちを使う」と思っていた時期が私にもありました。しかし実際にしまなみ海道の観光サイトを開発していると、同じプロジェクトの中で両方を意図的に使い分けている箇所が出てきました。この記事ではその理由を整理します。

まず基本の比較

同じ処理を両方の書き方で並べます。

.then()チェーン

fetch("/data/hotels.json")
  .then((res) => res.json())
  .then((data) => {
    console.log(data);
  })
  .catch((e) => {
    console.error(e);
  });

async/await

async function loadHotels() {
  try {
    const res = await fetch("/data/hotels.json");
    const data = await res.json();
    console.log(data);
  } catch (e) {
    console.error(e);
  }
}

どちらも同じ処理です。読みやすさの点ではasync/awaitの方が「上から下へ順番に読める」ため、多くの場面で優れています。

async/awaitを使った例：useHotelsData

地図上にホテルのピンを表示するために、/data/hotels.json をフェッチするカスタムフック useHotelsData を書きました。

// src/hooks/map/useHotelsData.ts
useEffect(() => {
  let cancelled = false;

  (async () => {
    try {
      setLoading(true);

      const [hotelRes, validRes] = await Promise.all([
        fetch("/data/hotels.json", { cache: "no-store" }),
        fetch("/data/valid-image-ids.json", { cache: "no-store" }),
      ]);

      if (!hotelRes.ok) throw new Error(`HTTP ${hotelRes.status}`);

      const json = await hotelRes.json();
      let parsed = parseHotels(json);

      if (validRes.ok) {
        const validData = await validRes.json();
        const validSet = new Set(validData.hotelNos);
        parsed = {
          ...parsed,
          features: parsed.features.filter((f) =>
            validSet.has(f.properties.hotelNo)
          ),
        };
      }

      if (!cancelled) setHotels(parsed);
    } catch (e) {
      if (!cancelled) setError("読み込みに失敗しました");
    } finally {
      if (!cancelled) setLoading(false);
    }
  })().catch(() => {});

  return () => { cancelled = true; };
}, []);

await Promise.all([...]) で2つのフェッチを並列実行し、その後に絞り込み処理をしています。処理が直線的に流れるので、async/awaitが読みやすい場面です。

.then()チェーンを使った例：useHotelDetail

一方、マップ上でホテルをタップしたとき詳細データをオンデマンド取得する useHotelDetail では、useEffectの中で.then()チェーンを使っています。

// src/hooks/hotels/useHotelDetail.ts
useEffect(() => {
  // ...前略（キャッシュ確認・AbortController設定）

  const p = existing ?? fetchDetail(normalizedNo, signal);
  if (!existing) inFlight.set(normalizedNo, p);

  p.then((data) => {
      if (latestNoRef.current !== normalizedNo) return;
      memoryCache.set(normalizedNo, data);
      setDetail(data);
      setLoading(false);
    })
    .catch((e: unknown) => {
      if (signal.aborted) return;
      if (latestNoRef.current !== normalizedNo) return;
      setError(e instanceof Error ? e : new Error(String(e)));
      setLoading(false);
    })
    .finally(() => {
      if (!existing) inFlight.delete(normalizedNo);
    });

  return () => controller.abort();
}, [normalizedNo]);

useEffectのコールバックは「クリーンアップ関数をreturnする」という役割があります。async関数は必ずPromiseを返すため、useEffectのコールバックに直接asyncを付けるとクリーンアップ関数を返せなくなるという問題があります。

// ❌ これはできない
useEffect(async () => {
  await fetchDetail(normalizedNo, signal);
  return () => controller.abort(); // Promiseに包まれてしまいクリーンアップとして機能しない
}, [normalizedNo]);

useHotelsData ではIIFE（即時実行関数）でasyncを閉じ込めることで回避しています。しかし useHotelDetail では事情が異なります。p は inFlight.get() から取り出した「すでに走っているかもしれないPromise」です。IIFEで await p と書くこともできますが、その場合 .finally() で inFlight.delete() するタイミング管理が複雑になります。.then().catch().finally() のメソッドチェーンにすることで、キャッシュへの書き込み・エラー処理・inFlightの削除がどこで行われているかが一目瞭然になりました。

判断基準をまとめると

状況	推奨
処理が直線的に流れる（順番にawaitするだけ）	async/await
try/catch/finallyで複数のエラーを整理したい	async/await
useEffectの中で書きたいが処理が単純	IIFE + async/await
すでにPromise変数が手元にある	.then()チェーン
useEffectの外でPromiseを共有・合流させたい	.then()チェーン
.finally()だけ使いたい（クリーンアップ処理）	.then()チェーンの末尾に.finally()

まとめ

async/awaitは「読みやすい」という点でほとんどの場面で優れています。ただし、useEffectの制約（クリーンアップをreturnする必要がある）や、すでにPromiseとして存在している変数に処理を繋ぎたい場面では、.then()チェーンの方が構造に合うことがあります。

「常にasync/await」ではなく、処理の形に合わせて選ぶ——それが判断基準です。

mojitonews.hateblo.jp

forwardRef・createPortal・Zustand——しまなみ海道観光サイトでReactの作法を少し外す設計をした話

2026-04-15T10:04:07+09:00

しまなみ海道の観光ガイドサイトをNext.js 15で個人開発する中で、通常のReactの作法——親子の一方向データフロー・ツリー内でのDOM管理——から外れた設計が必要になる場面が3つありました。forwardRef による命令型API・createPortal によるDOMへの脱出・Zustand によるプロバイダーなしの状態管理です。前回の記事（useRef・useCallback・AbortController編）の続きになります。

このサイトでは地図機能を中心に据えており、しまなみ海道観光マップとしてスマートフォン・デスクトップどちらからでも使えるようにしています。地図上にはホテルと観光スポットのピンをレイヤーで切り替えて表示でき、ピンをクリック・タップすると吹き出し型のポップアップが開く構成です。詳細を開くと、スマートフォンではボトムシートが下からスライドして開き、デスクトップでは右サイドからパネルが開いてスポットの詳細情報を確認できます。

観光スポットレイヤーとホテルレイヤーをReactコンポーネントとして描画しており、レイヤーで切り替えて表示できます

forwardRef + useImperativeHandle——親から子に「命令する」

Reactのデータフローは基本的に親から子への一方通行です。しかし「親から子に対して、今すぐ何かをしろと命令したい」ケースが出てくることがあります。このサイトのボトムシート（Sheet.tsx）がまさにそうでした。

モバイルのボトムシートには×ボタンがあり、押したときにアニメーション付きでシートを閉じる必要があります。最初はpropsで forceClose: boolean のようなフラグを持たせることを考えました。しかしこれをやると、親側にフラグのstateを追加し、閉じ終わったらリセットする処理も書く必要があり、管理が煩雑になります。

そこで forwardRef と useImperativeHandle を組み合わせて、requestClose だけを外部に公開する命令型APIを作りました。

export type SheetHandle = { requestClose: () => void };

const Sheet = forwardRef<SheetHandle, SheetProps>(function Sheet(props, ref) {
  const requestClose = useCallback(() => {
    setIsClosing(true);
    setShow(false);
    closeTimerRef.current = window.setTimeout(() => {
      finalizeClose();
    }, closeMs + 80);
  }, [closeMs, finalizeClose]);

  useImperativeHandle(ref, () => ({ requestClose }), [requestClose]);
});

RightPane.tsx側はrefを受け取り、×ボタンのonClickで sheetRef.current?.requestClose() を呼びます。

const sheetRef = useRef<SheetHandle>(null);
// ×ボタンのonClick
sheetRef.current?.requestClose();

useImperativeHandle で公開するAPIを requestClose だけに絞っているのがポイントです。refでDOMをそのまま渡すと setShow や setMounted といった内部stateにも触れてしまいます。公開するAPIを一つに限定することで、Sheet内部の実装をあとから変えてもインターフェースが壊れない設計になっています。

createPortal——ReactツリーとDOMツリーを切り離す

SheetのSSR対策：document.body直下にマウントする

ボトムシートのオーバーレイは createPortal を使って document.body の直下にマウントしています。これをしないと、親コンポーネントに overflow: hidden や z-index のスタッキングコンテキストが設定されている場合、オーバーレイがその内側に閉じ込められて正しく表示されません。document.body 直下に逃がすことでその制約を回避しています。

詰まったのがSSR対策です。Next.js App Routerではサーバーサイドでもコンポーネントが実行されますが、サーバーには document が存在しません。そのため document.body は useEffect の中でrefに代入し、createPortal にはそのrefを渡しています。

const overlayRootRef = useRef<HTMLElement | null>(null);

useEffect(() => {
  overlayRootRef.current =
    typeof document !== 'undefined' ? document.body : null;
}, []);

if (!mounted || !overlayRootRef.current) return null;
return createPortal(overlay, overlayRootRef.current);

mounted（シートの表示状態）と overlayRootRef.current（SSRガード）の両方をチェックしているのがポイントです。document.body を直接 createPortal に渡すのではなく、useEffect内で安全に取得してからrefに入れる、という順序が必要でした。

ピンをタップすると吹き出し型のポップアップが表示され（左）、詳細をタップするとボトムシートが下からスライドして開きます（右）。Sheet.tsxのcreatePortalとforwardRefが動いている場面です

MapboxマーカーへのReactコンポーネント埋め込み：createRoot版

createPortal とは少し異なるパターンとして、Mapboxのマーカー内にReactコンポーネントを描画する実装があります。

MapboxのMarkerはHTMLElementを受け取る仕様です。そのHTMLElementの中に createRoot でReactのツリーを生やすことで、MapboxのマーカーをReactコンポーネントとして扱えます。

const el = document.createElement('div');
const root = createRoot(el);
root.render(
  React.createElement(HotelPin, { thumb, title, onClick })
);
const marker = new mapboxgl.Marker({ element: el }).setLngLat(lnglat).addTo(map);

React 18以降は ReactDOM.render が非推奨のため createRoot を使います。アンマウント時は setTimeout(0) で遅延してから root.unmount() を呼んでいます。Reactのレンダーサイクル中に unmount を呼ぶと警告が出るため、次のマクロタスクに処理を遅らせています。

Zustand——useContextを使わなかった理由

このサイトの状態管理にはZustandを採用し、5つのストアを用意しています。

useMapUiStore：衛星レイヤーのon/off・不透明度
useSpotStore：選択中のスポット
useHotelStore：選択中のホテル
useRestaurantStore：選択中のレストラン
useBusStore：選択中のバス停

// useMapUiStore.ts
export const useMapUiStore = create<MapUiState>((set) => ({
  satOn: false,
  satOpacity: 0.8,
  setSatOn: (on) => set({ satOn: on }),
  setSatOpacity: (value) => set({ satOpacity: value }),
}));

// どこからでもimportして使うだけ
const { satOn, setSatOn } = useMapUiStore();

衛星レイヤーのon/offと不透明度はuseMapUiStoreで管理しています。どのコンポーネントからでも直接importして参照・更新できます

useContext ではなくZustandを選んだ理由は3つあります。

1. Providerが不要

Contextは <Provider> を上位コンポーネントに置く必要があります。このサイトはMapbox→ピン→ポップアップ→詳細パネルとコンポーネントツリーが深く、どの階層でも状態にアクセスできるようにするには中間に大量のProviderを通す必要があります。Zustandはストアをどこからでも直接importして使えるため、この問題が起きません。

2. 現時点で 'use client' ファイルが64個あるサイトでどこからでも呼べる

Next.js App RouterではServer ComponentとClient Componentが混在します。現時点で 'use client' のファイルが64個あるこのサイトでは、Zustandはimportするだけでどのクライアントコンポーネントからも参照できるため、Server Componentとの境界を意識せずに使えました。

3. 不要な再レンダーが起きにくい

Contextは値が変わると、そのContextを購読しているコンポーネントすべてが再レンダーされます。Zustandはセレクターで購読する値を絞れるため、useHotelStore(s => s.selectedHotel) のように書くと selectedHotel が変わったときだけそのコンポーネントが再レンダーされます。地図上に複数のレイヤーが同時に存在するこのサイトでは、余計な再レンダーを減らすことが動作の安定に直結しました。

前回の記事（useRef・useCallback・AbortController編）と合わせると、このサイトで使ったReact機能の主要な設計判断が一通り揃います。同じような地図系サイトや、深いコンポーネントツリーを持つ個人開発の参考になれば幸いです。

mojitonews.hateblo.jp

useRef・useCallback・AbortController——しまなみ海道観光サイトに組み込んだ地図機能で"stateに入れない・再生成させない・止める"を実践した話

2026-04-15T09:25:16+09:00

しまなみ海道の観光ガイドサイトをNext.js 15で個人開発する中で、Reactの非同期処理まわりで詰まったことを3つのテーマで整理します。「stateに入れない（useRef）」「再生成させない（useCallback）」「止める（AbortController）」——この3軸で読んでいただければと思います。

デスクトップ版ではピンをクリックすると吹き出し型のポップアップが表示され、詳細を押すと右サイドからパネルが開いてスポットの詳細情報を確認できます

地図上にはホテルと観光スポットのピンをレイヤーで切り替えて表示できます。MapboxのMarkerをReactコンポーネントとして描画しています

useRef——「stateに入れると困るもの」を保持する

useRefは「DOMを参照するためのもの」というイメージが強いですが、実際には「再レンダーをトリガーせずに値を保持したい」場面でのほうがよく使いました。

パターン1：タイマーIDの保持

ボトムシート（Sheet.tsx）では、requestAnimationFrame のIDを raf1Ref / raf2Ref に、setTimeout のIDを closeTimerRef に持たせています。これらはアニメーション中にクリーンアップが必要なだけで、画面の表示には影響しません。stateに入れると値が変わるたびに再レンダーが走りますが、refならその心配がありません。

パターン2：ドラッグ中フラグとクロージャ問題

draggingRef（ドラッグ中かどうかのフラグ）も同様です。ドラッグ中はポインターイベントが高頻度で発火するので、毎フレーム再レンダーが走るとアニメーションが崩れます。「画面には影響しないが、ロジック上は最新値を持ちたい」ものはrefに入れる、という判断です。

showRef はもう少し特殊で、show ステートの最新値をrefにコピーしています。イベントハンドラはクロージャなので、登録時点の show の値しか見えません。showRef.current を参照するようにすることで、ハンドラが「今この瞬間のshowはどうか」を正しく確認できるようになります。

パターン3：レースコンディション防止

useHotelDetail.ts では latestNoRef でレースコンディションを防いでいます。

const latestNoRef = useRef<number | null>(null);

useEffect(() => {
  latestNoRef.current = hotelNo;
}, [hotelNo]);

// フェッチ完了後
p.then((data) => {
  if (latestNoRef.current !== normalizedNo) return; // 古い結果は捨てる
  setDetail(data);
});

たとえばポップアップから「ホテルA→ホテルB」と素早く切り替えたとき、Aのリクエストが遅れて返ってくることがあります。このとき何もしなければ、最終的にAの情報がボトムシートに表示されてしまいます。latestNoRef に常に最新のhotelNoを書き込んでおき、フェッチ完了時に一致しなければ捨てる、というパターンです。

MapboxのMarkerインスタンスも markersRef（Map<string, Marker> 型）に保持しています。Mapboxのインスタンスをstateに入れると、ピンが一つ追加されるたびに地図コンポーネント全体が再レンダーされます。Mapboxは自前でDOMを管理しているため、Reactの再レンダーが走ると競合することもあります。「Reactの管理外のオブジェクトはrefに入れる」はほぼ鉄則だと感じました。

useCallback——「再生成させない」が必要なケース

useCallbackはパフォーマンス最適化のイメージがありますが、使ってみると「バグ防止」として機能する場面が多かったです。

パターン1：useEffectの無限ループ防止

Sheet.tsx の finalizeClose（シートが閉じ終わったあとの後処理）は、useEffectの依存配列に含まれています。

const finalizeClose = useCallback(() => {
  onClose();
  setMounted(false);
}, [onClose]);

useEffect(() => {
  closeTimerRef.current = window.setTimeout(() => {
    finalizeClose();
  }, closeMs);
}, [open, closeMs, finalizeClose]);

useCallback を外すと、finalizeClose は毎レンダーで新しい関数オブジェクトになります。するとuseEffectが「依存配列が変わった」と判断して再実行し、また finalizeClose が再生成され……という無限ループになります。依存配列に関数を入れるときは、useCallbackで参照を安定させるのがほぼ必須です。

パターン2：イベントリスナーの解除ができなくなる

useGeolocate.ts では、navigator.geolocation.watchPosition に渡すコールバックを useCallback で安定化しています。これをしないと、レンダーのたびに新しい関数が生成されてwatchの登録が毎回やり直されます。

useSatelliteLayer.ts では map.on('style.load', ensureSatellite) のようにMapboxのイベントリスナーを登録しています。イベントリスナーは「登録時と同じ関数の参照」を map.off に渡さないと解除できません。useCallback を使わずに毎レンダーで新しい関数を渡していると、off が空振りし続けてリスナーが溜まっていきます。これは開発中になかなか気づきにくいバグです。

AbortController——非同期処理を「止める」

シンプルパターン：styleUrlが変わったらキャンセル

useMapStyle.ts では最もベーシックな使い方をしています。

useEffect(() => {
  const ac = new AbortController();
  (async () => {
    try {
      const spec = await fetchAndLocalizeStyle(styleUrl, ac.signal);
      if (!ac.signal.aborted) setStyleSpec(spec);
    } catch {
      if (!ac.signal.aborted) setStyleErr('読み込み失敗');
    }
  })();
  return () => ac.abort();
}, [styleUrl]);

styleUrl が変わったとき、クリーンアップ関数で ac.abort() を呼んで前のフェッチをキャンセルします。フェッチ完了後に ac.signal.aborted を確認しているのは、中断後のstate更新を防ぐためです。これをしないと「キャンセルしたはずのリクエストが完了してstateを書き換える」という問題が起きます。

複合パターン：重複リクエスト排除との組み合わせ

ポップアップから詳細をタップするとホテルの詳細情報を取得しますが、素早く別のピンに切り替えると複数のリクエストが同時に飛びます。useHotelDetail.ts では AbortController に加えて、モジュールレベルの inFlight と memoryCache を組み合わせてこの問題に対応しています。

ピンをタップすると吹き出し型のポップアップが表示され、詳細をタップするとボトムシートが下からスライドして開きます。このSheet.tsxが今回の記事で扱うコンポーネントです

// モジュールレベル（複数のフックインスタンスで共有）
const memoryCache = new Map<number, HotelDetail>();
const inFlight = new Map<number, Promise<HotelDetail>>();

useEffect(() => {
  const controller = new AbortController();
  const existing = inFlight.get(normalizedNo);
  const p = existing ?? fetchDetail(normalizedNo, controller.signal);
  if (!existing) inFlight.set(normalizedNo, p);

  p.then((data) => {
    memoryCache.set(normalizedNo, data);
    setDetail(data);
  }).finally(() => {
    if (!existing) inFlight.delete(normalizedNo);
  });

  return () => controller.abort();
}, [normalizedNo]);

inFlight は「同じhotelNoへのリクエストが進行中なら、そのPromiseを使い回す」ための仕組みです。複数箇所から同じホテルの詳細を要求しても、フェッチは1本しか走りません。memoryCache は一度取得したデータをメモリに持ち続け、同じホテルを再度開いたときに即表示します。

この3つ（AbortController・inFlight・memoryCache）に、前述の latestNoRef も加わります。「キャンセル・重複排除・キャッシュ・レースコンディション防止」の4つが連動して、非同期処理の信頼性を担保しています。最初は全部必要なのか疑問でしたが、実際に地図上で素早くピンをタップして試してみると、どれか一つでも欠けると挙動がおかしくなりました。

ここまでが「Reactの内側で完結する」処理の話です。次の記事では、ReactツリーそのものをはみだすUIの実装——forwardRef による命令型API・createPortal によるDOMへの脱出・Zustand による状態管理——を同じサイトの実例で整理します。

記事の続きは以下へ

mojitonews.hateblo.jp

`fs` を使ったらエラーが出た——Next.js の Server / Client Component を理解するまで

2026-04-14T07:20:25+09:00

きっかけはビルドエラーでした

しまなみ海道の観光ガイドサイトを開発していたとき、MDX ファイルを読み込む処理を書きました。

// lib/spots.ts
import fs from 'fs'
import path from 'path'

export function getAllSpots() {
  const dir = path.join(process.cwd(), 'content/spots')
  return fs.readdirSync(dir)
}

「動くだろう」と思ってビルドしたら、こんなエラーが出ました。

Module not found: Can't resolve 'fs'

fs が見つからない？ Node.js の標準モジュールなのになぜ、と最初は意味がわかりませんでした。

最初は原因がわからず迷走しました

最初にやったのは fs のインポート文を確認することでした。タイポかと思ったのですが、スペルに問題はありません。次に tsconfig.json を疑い、node の型定義が入っているか確認しました。

{
  "compilerOptions": {
    "types": ["node"]
  }
}

これも問題なし。@types/node もインストール済みでした。

npm list @types/node
# @types/node@20.x.x ← 入っている

それでもエラーは消えません。30分ほど同じところをぐるぐるして、ようやく「そもそもなぜブラウザで fs を使おうとしているのか」という根本的な問いにたどり着きました。

「デフォルトがサーバー」を理解していませんでした

調べてわかったのは、fs を呼び出していたコンポーネントに 'use client' が書いてあったということです。

Next.js の App Router では、コンポーネントはデフォルトで Server Component として動きます。'use client' を書いた瞬間、そのコンポーネントはブラウザで実行されるようになります。

そして fs は Node.js のモジュールなので、ブラウザには存在しません。だから「見つからない」と怒られていたわけです。

整理するとこういうことです。

	Server Component	Client Component
実行環境	Node.js（サーバー）	ブラウザ
`fs` / `path`	✅ 使える	❌ 使えない
`useState` / `useEffect`	❌ 使えない	✅ 使える
イベントハンドラ	❌ 不可	✅ 使える
DB への直接アクセス	✅ 可能	❌ 不可

わかってしまえばシンプルですが、「どこで動いているか」を意識せずにコードを書いていたのが原因でした。

直し方：データ取得はサーバーに閉じ込める

解決策はシンプルで、fs を使う処理を Server Component 側に移すだけでよかったです。

// app/spots/page.tsx（Server Component・'use client' なし）
import { getAllSpots } from '@/lib/spots'

export default async function SpotsPage() {
  const spots = await getAllSpots() // サーバーで実行される
  return <SpotList spots={spots} />
}

SpotList の中でクリック処理や useState が必要なら、そのコンポーネントだけ 'use client' にします。データを取ってくる層と UI を操作する層を分ける、という考え方です。

// components/SpotList.tsx
'use client'

type Props = {
  spots: string[]
}

export default function SpotList({ spots }: Props) {
  return (
    <ul>
      {spots.map((spot) => (
        <li key={spot}>{spot}</li>
      ))}
    </ul>
  )
}

Server Component でデータを取得してから props として渡す——このパターンを覚えてから、設計がずいぶんスムーズになりました。

`server-only` パッケージという保険もある

今回のような事故を未然に防ぐ方法もあります。server-only というパッケージを使うと、そのファイルが Client Component から import されたときにビルドエラーを出してくれます。

npm install server-only

// lib/spots.ts
import 'server-only' // ← これを先頭に追加するだけ
import fs from 'fs'
import path from 'path'

export function getAllSpots() {
  const dir = path.join(process.cwd(), 'content/spots')
  return fs.readdirSync(dir)
}

クライアントから呼ばれた瞬間に「このモジュールはサーバー専用です」というエラーが出るので、うっかりミスを防げます。APIキーを扱うファイルなど、絶対にクライアントに渡したくない処理に入れておくのがおすすめです。

境界線の引き方

この経験以来、コンポーネントを書くときに「これはどちらに置くべきか」を先に考えるようになりました。自分の中での判断基準はこうです。

サーバーに置くもの - fs でファイルを読む処理 - API キーを使う処理（クライアントに渡したくない） - DB への直接アクセス - メタデータの生成（SEO）

クライアントに置くもの - onClick などのイベントハンドラ - useState / useEffect を使う状態管理 - Mapbox のようなブラウザ専用ライブラリ - ユーザーの操作に応じてリアルタイムで変わる UI

迷ったときは「ブラウザが必要な処理か？」と自問するとだいたい決まります。ブラウザが不要なら、サーバーに置いて損はありません。

Server Component のメリットを実感した

この一件でサーバーに閉じ込めることのメリットも体感できました。

ひとつはパフォーマンスです。サーバーで処理してから HTML を返すので、クライアントに送る JavaScript の量が減ります。MDX ファイルの読み込みや変換処理をサーバーで完結させることで、ブラウザ側の負荷が大幅に下がりました。

もうひとつはセキュリティです。API キーや DB の接続情報をサーバーに閉じ込めれば、ブラウザの開発者ツールから見えません。以前は NEXT_PUBLIC_ プレフィックスをつけた環境変数をクライアントに渡していましたが、Server Component を使えばそもそも公開する必要がなくなります。

やってよかったこと

最初のエラーで止まっていたら、そのまま 'use client' を外して終わりにしていたかもしれません。でも「なぜ fs が使えないのか」を調べたことで、App Router の設計思想がようやく腑に落ちました。

デフォルトがサーバーというのは、セキュリティとパフォーマンスのための意図的な設計です。クライアントに余計なコードを送らない、秘匿情報をサーバーに閉じ込める、という考え方が根底にあります。

エラーメッセージをしっかりと読まないといけないと、感じた出来事でした。

Next.js 15 + TypeScript + MDX でしまなみ海道の観光ガイドサイト（shimanami-guide.jp）を個人開発しています。詰まったことを記事にしていきます。

mojitonews.hateblo.jp

AIと一緒に個人サイトを開発するとはどういう体験か——Claude Code を使って気づいたこと

2026-04-12T23:24:08+09:00

猫の細道のスポットページをMDXで管理している。frontmatterに緯度経度・タグ・画像リストを書いておくと、地図・一覧・記事ページを1ファイルで制御できる。

はじめに

「AIにコードを書いてもらう」という表現をよく見かけます。でも実際のところ、少し違います。

Anthropic が提供する AI CLI ツール「Claude Code」を使いながら Next.js の個人サイトを開発してみてわかったのは、「一緒に考えながら作る」という感覚に近いということでした。

開発環境は VSCode で、Claude Code は VSCode のターミナルから起動して使っています。

この記事では、実際の開発フローや便利だと感じた場面、逆に思っていたのと違った場面を率直に書いていきます。

Claude Code とはどんなツールか

Claude Code は Anthropic が提供する CLI ツールです。ブラウザ版の Claude とは別物で、ターミナルから起動してプロジェクトのファイル構造を丸ごと把握した状態で動きます。ファイルの読み書き・編集・git 操作・コマンド実行まで自律的にこなせるのが特徴です。

ブラウザ版 Claude がチャット画面でやりとりするのに対して、Claude Code はコードベース全体を理解した上で作業するため、「このコンポーネントを修正して」「このエラーを調べて直して」といった指示がそのまま通ります。複数ファイルにまたがる変更や、エラーの原因究明から修正までを一気に行えるのはブラウザ版にはない強みです。

利用には Pro プラン（月額 $20）以上のサブスクリプションが必要です。私は Pro プランで使っています。個人開発の学習目的であれば、まず Pro プランで十分だと感じています。そのうち物足りなくなればMAXプランも使いたいなと思っています。

実際の開発フロー——どう指示を出すか

Claude Code への指示は自然言語で話しかけるだけです。たとえば実際にこんな指示を出したことがあります。

「立花海岸のMDXファイルに早朝の画像を4枚追加して、SEOの shortDescription を110文字以上に修正して、H2見出しにキーワードを追加してほしい」

これを一回伝えると、Claude Code は以下を自律的に実行します。

対象ファイルを読む
画像ファイルの存在を確認する
frontmatter を編集する
記事本文に画像コンポーネントを追加する
文字数を数えて shortDescription を調整する
修正内容を説明する

指示の出し方にはコツがあって、ファイル名や条件を具体的に伝えるほど精度が上がります。この辺りはまた別の機会に詳しく書くつもりです。

一方で、私がやることも明確にあります。方針・優先順位の決定（何をどの順番で作るか）、事実確認（「360度パノラマ」と書いてあったが実際は約240度だった、など現地に行かないとわからないこと）、写真の撮影とファイルの配置、最終的なデプロイ判断——これらは私が行います。

「何を作るか」を決めるのは人間、「どう実装するか」を一緒に考えるのが Claude Code という役割分担が、だんだん見えてきました。

やってみてわかったこと——便利な場面と、そうでない場面

使ってみて便利だと感じた場面は主に3つです。

大量の同じ作業：複数ファイルのH2見出しに一括でキーワードを追加するといった繰り返し作業は、Claude Code に任せると一気に片付きます。手作業でやると確実にミスが出るような作業ほど、効果を実感します。

調査→修正の繰り返し：SEOレポートを出して問題を洗い出し、修正して再確認する、というサイクルをそのまま会話の流れで進められます。「次に何をすべきか」を一緒に考えながら動いてくれる感覚です。

エラーの原因究明：「この画像が粗くなる理由を調べて解決して」と伝えると、ファイルを読んで原因を仮説立てして修正まで追ってくれます。独学でひとり詰まっているときに、相談相手がいる感覚になります。

一方で、思っていたのと違った場面もあります。

完全に任せると意図と違う実装になることがあります。指示の粒度が大事で、曖昧な指示を出した側の問題だと気づくことが多いです。また、Claude Code が書いたコードを理解しないままにしておくと、後でレビューも修正もできなくなります。「何が問題か」を自分でわかっていないと、そもそもうまく指示が出せない、という場面も何度かありました。

AIが書いたコードを理解する責任は自分にある——これは使い始めて早い段階で気づいた、一番大事なことだと思っています。

「書いてもらう」ではなく「一緒に作りながら理解する」という使い方

Claude Code を使い始めて変わったのは、座学で学んだ知識が「実際に動くコード」として目の前に現れる速度です。エラーの原因を調べて修正するまでの時間が短くなり、その分だけ「なぜそうなるのか」を考える余裕が生まれました。

ただ、私の場合は「個人サイトを作りながら学ぶ」という目的があるので、AIに全部お任せすると本末転倒になります。提案されたコードは必ず自分で読んで理解してから使う、という意識を持つようにしてから、学習としての手応えが出てきました。

「じゃあ別の書き方はどうなる？」と聞いてみると複数の実装パターンを出してくれるので、それを比べながら自分で選ぶ、という使い方もしています。こうすることで選択肢を知りながら学べるのが面白いところです。

「AIにコードを書いてもらう」ではなく「一緒に作りながら理解する」——この使い方が、学習目的の個人開発には合っていると感じています。

あなたはどう使っていますか？

Claude Code や GitHub Copilot など、AI と一緒に開発している方がいれば、どんな使い方をしているかぜひコメントで教えてください。

「こう使うともっといいよ」「その使い方は後でつらくなるよ」といったフィードバックも大歓迎です。バックエンド・フロントエンドの先輩エンジニアの意見もお待ちしています。

これからも作りながら率直に記録していきます。

しまなみ海道観光ガイドサイト：https://www.shimanami-guide.jp

mojitonews.hateblo.jp

手を動かして初めてわかった　Next.js + TypeScript で個人サイトを作りながら学ぶという選択

2026-04-12T22:31:25+09:00

座学だけでは身につかない——実践学習に切り替えた理由

正直に言うと、座学はそれなりにやってきたつもりでした。

JavaScriptの文法、Reactのコンポーネント設計、HTTPの仕組み、DBの正規化……。本を読み、Udemyを視聴し、ハンズオン記事を写経する。一通り「わかった気」になれる体験を繰り返してきました。

でも、ある日ふと気づいてしまいました。「これじゃ何も作れるようにはならない」と。

useEffect の依存配列についてはある程度説明できる。でも「じゃあ実際のプロジェクトで、どこに何を置いて、どうデプロイするの？」と聞かれると途端に詰まる。知識がパズルのピースとして頭の中に散らばっているだけで、このピースをどこに当てはめるのかわからない状況です。

座学の定着率に限界を感じたとき、出した結論はシンプルでした。「動くものを作って、運用する」 しかねぇと。それも、自分で興味のある分野を狙って作ることでずっと続けることができるもの。

テーマはしまなみ海道——地元題材で作るNext.js観光ガイドサイト

尾道市向島町立花の海岸です。一度はサイクリングに訪れるべきスポット

「何を作るか」は意外と重要で、ここで詰まると学習自体が止まります。

候補はいくつか考えました。TODOアプリ、ポートフォリオ、ブログ……でも「またTODOアプリか」という気持ちになってしまい、手が動かない。モチベーションが続く題材でないと、技術的につまずいたときに逃げてしまいます。

そこで選んだのが、しまなみ海道エリアの観光ガイドサイトです。

広島県尾道から愛媛県今治をつなぐしまなみ海道は、自分の地元に近いエリアです。サイクリングロードとして国際的にも知名度があり、島ごとに異なる風景や食・アートがある。ネタには困らないし、「地域の情報を自分の手でまとめて発信する」という目的があれば、コンテンツを作る動機にもなります。それから、外に出て体を動かしながら色々巡ることができるというのも大きな点でした。

作っているサイトはこちらです。 → https://www.shimanami-guide.jp

（まだ工事中の箇所だらけですが、それも含めて記録していくつもりです）

「作るものが決まれば、学習の方向性も決まる」——これは実感としてあります。「画像を最適化したい」「地図を埋め込みたい」「記事ページを増やしたい」と具体的な目標が生まれると、調べることが一気にはっきりします。

Next.js 15 + TypeScript + MDXを選んだ理由と構成

現在の構成はこうなっています。

用途	技術
フレームワーク	Next.js 15（App Router）
言語	TypeScript
スタイリング	Tailwind CSS
コンテンツ管理	MDX
ホスティング	Vercel
開発補助	Claude Code（AI CLI）

Next.js を選んだのは、「フロントエンドの現場でよく使われている」という理由が正直なところです。Next.js は React ベースのフレームワークなので、実質的に React を実践で使う経験も積めるという点も選んだ理由のひとつです。App Router は Pages Router と設計思想がかなり異なり、use client と use server の境界感覚はまだ手探り中です。

TypeScript は「型があると安心」という話を聞き続けていたので採用しましたが、実際に書いてみると any で逃げたくなる誘惑との戦いが続いています。

MDX によるコンテンツ管理は、観光サイトという性質上、記事をたくさん書くことになるため選びました。Markdown で書けてコンポーネントも埋め込める、というのが理想的に見えたのですが、ビルド設定やfrontmatterの型定義まわりで最初はかなり詰まりました。

開発には Claude Code（AnthropicのAI CLIツール）を使っています。エラーメッセージを貼り付けると原因の仮説を出してくれたり、「このコンポーネントどう分割する？」と相談できたりするのは、独学者にとって思いのほか心強いです。ただし、提案をそのままコピペすると後で意味がわからなくなるので、必ず自分で読んで理解してから使う、を意識しています。

実際に作って詰まった壁——座学では気づけなかったこと

座学では「そういうものだ」と流せた話が、実際に手を動かすと急に解像度を上げてくる——その連続です。

たとえばこんなことがありました。

画像の最適化：next/image を使えばいいとは知っていたけど、外部ドメインの画像を表示しようとして next.config.js の remotePatterns を設定する必要があることを、エラーを見て初めて理解した
App Router のキャッシュ：開発環境では反映されているのに本番では古いデータが表示される、という現象に遭遇して、fetch のキャッシュ戦略を初めてちゃんと調べた
Tailwind のレスポンシブ：md: プレフィックスの仕組みは知っていたが、実際のデザインを整えようとすると「モバイルファースト」の思考に切り替えるのにかなり時間がかかった
Vercel へのデプロイ：vercel --prod でデプロイするだけのはずが、環境変数の設定漏れでビルドが通らず、ローカルと本番の差異を初めて体で覚えた

どれも「知識として知っていた」と「手を動かして理解した」の間にある深い溝です。

そして気づいたのですが、この詰まりが全部、記事のネタになります。

「こうやって詰まって、こう解決した」という記録を残すことで、同じところで困っている誰かの役に立てるかもしれない。それ自体も、サイトを作り続ける動機になっています。

このプロジェクトで学べること・学べないこと

正直に書いておきます。このサイトで実際に触れていることと、触れていないことです。

触れていること

フロントエンドは Next.js 15 App Router（Server / Client Component の分離）、TypeScript による型安全な実装、Tailwind CSS でのレスポンシブ・ダークモード対応、MDX によるコンテンツ管理、next/image の最適化オプション（fill / sizes / priority）を扱っています。

インフラ・運用面では Vercel への本番デプロイ、Google Search Console と GA4 の実データを見ながらの改善、sharp.js による画像圧縮スクリプト、git / GitHub でのバージョン管理を実践しています。

SEO・設計面では metadata / OGP / JSON-LD によるメタデータ設計、Hub & Spoke のページ構成設計、パンくずリストの実装にも取り組んでいます。

触れていないこと

このサイトはファイルベースのため、データベース・認証・ログイン機能・API設計（REST / GraphQL）には触れていません。テストコードも書けていません。

フロントエンドと運用の実践としては十分な内容ですが、バックエンド（DB・API・認証）を深めたい場合は別途機能を追加するか、別プロジェクトが必要だと認識しています。ただ、このサイト自体に機能を追加していくにつれて、学べることは増えていくはずだとも思っています。

フィードバック歓迎——一緒に学べる方へ

バックエンド・フロントエンドの両方で、まだ見えていない地雷がたくさんあると思っています。「そのやり方は後でつらくなるよ」「ここはこう考えた方がいい」というフィードバックを、もしよければコメントでいただけると非常に助かります。

技術的に間違ったことを書いてしまう可能性もあります。そのときもご指摘いただけると、自分の学習にとってこれ以上ない励みになります。

作りながら記録する、という方針でこのブログを続けていくつもりです。同じように「座学から実践へ踏み出した」タイミングの方がいれば、ぜひ一緒に詰まりましょう。

これからここで、ちゃんと記録を残していきます。

しまなみ海道観光ガイドサイト：https://www.shimanami-guide.jp

mojitonews.hateblo.jp

Shimanami RouteLab｜しまなみ海道のスポット紹介サイトを個人開発

"use client" はどこに書くのか——エラーが出るたびにつけ足していたら全部 Client Component になっていた

App Router の役割分担はシンプル

地図ページの場合（/map）

スポット一覧ページの場合（/spots）

「全部クライアントにする」の何が問題か

"use client" をどこに書くべきか

猫の細道を訪れてMDXでサイトに追加した——frontmatterが地図ピンになる仕組みと画像管理

猫の細道を訪れてMDXでサイトに追加した——frontmatterが地図ピンになる仕組みと画像管理の話

猫の細道に行ってきた

このサイトのコンテンツ管理はMDXで完結している

frontmatterが地図ピンに変わる仕組み

本文にはMarkdown + JSXコンポーネントが書ける

カスタムコンポーネントをMDXRemoteに渡す

実際の追記作業はこれだけ

async/await と .then() チェーン——しまなみ海道観光サイトで両方使い分けた理由

まず基本の比較

async/awaitを使った例：useHotelsData

.then()チェーンを使った例：useHotelDetail

判断基準をまとめると

まとめ

forwardRef・createPortal・Zustand——しまなみ海道観光サイトでReactの作法を少し外す設計をした話

forwardRef + useImperativeHandle——親から子に「命令する」

createPortal——ReactツリーとDOMツリーを切り離す

SheetのSSR対策：document.body直下にマウントする

MapboxマーカーへのReactコンポーネント埋め込み：createRoot版

Zustand——useContextを使わなかった理由

useRef・useCallback・AbortController——しまなみ海道観光サイトに組み込んだ地図機能で"stateに入れない・再生成させない・止める"を実践した話

useRef——「stateに入れると困るもの」を保持する

パターン1：タイマーIDの保持

パターン2：ドラッグ中フラグとクロージャ問題

パターン3：レースコンディション防止

useCallback——「再生成させない」が必要なケース

パターン1：useEffectの無限ループ防止

パターン2：イベントリスナーの解除ができなくなる

AbortController——非同期処理を「止める」

シンプルパターン：styleUrlが変わったらキャンセル

複合パターン：重複リクエスト排除との組み合わせ

`fs` を使ったらエラーが出た——Next.js の Server / Client Component を理解するまで

きっかけはビルドエラーでした

最初は原因がわからず迷走しました

「デフォルトがサーバー」を理解していませんでした

直し方：データ取得はサーバーに閉じ込める

server-only パッケージという保険もある

境界線の引き方

Server Component のメリットを実感した

やってよかったこと

AIと一緒に個人サイトを開発するとはどういう体験か——Claude Code を使って気づいたこと

はじめに

Claude Code とはどんなツールか

実際の開発フロー——どう指示を出すか

やってみてわかったこと——便利な場面と、そうでない場面

「書いてもらう」ではなく「一緒に作りながら理解する」という使い方

あなたはどう使っていますか？

手を動かして初めてわかった Next.js + TypeScript で個人サイトを作りながら学ぶという選択

座学だけでは身につかない——実践学習に切り替えた理由

テーマはしまなみ海道——地元題材で作るNext.js観光ガイドサイト

Next.js 15 + TypeScript + MDXを選んだ理由と構成

実際に作って詰まった壁——座学では気づけなかったこと

このプロジェクトで学べること・学べないこと

フィードバック歓迎——一緒に学べる方へ

`server-only` パッケージという保険もある

手を動かして初めてわかった　Next.js + TypeScript で個人サイトを作りながら学ぶという選択