座学だけでは身につかない——実践学習に切り替えた理由
正直に言うと、座学はそれなりにやってきたつもりでした。
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
