LEEの自宅サーバ運用記 | Build後の画面遷移で発生する「TypeError: Cannot read properties of undefined (reading 'get')」の解決

✅ 🚀 はじめに：開発環境と本番環境の「見えない壁」

WordPressからNuxt.jsへのブログ移行も大詰め。Mac上のローカル環境（npm run dev）では完璧に動作していたシステムを、いよいよ本番用のサーバーへデプロイする段階まで来ました。今回の構成は、ラズベリーパイから一歩進んだ新しいサーバー環境でのSSR（サーバーサイドレンダリング）運用です。しかし、デプロイ完了後の動作テストで、フロントエンドエンジニアなら誰もが一度は遭遇する「Build後限定のバグ」に直面することになりました。

✅ ⚠️ トラブルの発生：本番ビルドでだけ画面が真っ白に

本番サーバーにプロジェクトをデプロイし、以下の手順でアプリケーションを起動しました。

npm run build（プロダクション用ビルド）
npm run start（本番モードでの起動）
（または）npm install（依存関係の解決）

サーバー上のブラウザからアクセスすると、トップページは正常に表示されます。しかし、そこから個別の記事リンクをクリックして画面遷移を試みた瞬間、以下のエラーがコンソールに吐き出されました。

TypeError: Cannot read properties of undefined (reading 'get')

記事ページが表示されず、画面が止まってしまいます。ところが不思議なことに、そのページで「ブラウザの更新（リロード）」を押すと、何事もなかったかのように正常に表示されるのです。

✅ 🔍 原因の切り分け：環境の差か、それともビルドの差か

最初は「Mac（開発機）とLinux（本番機）の環境の差」を疑いました。本来、本番と開発の環境は極力揃えるべきですが、今回は検証も兼ねて異なる構成にしていました。しかし、開発環境であるMacでnpm run start（ビルド後の実行）を試したところ、全く同じエラーが再現。これにより、原因はサーバー環境ではなく、「Nuxtのビルド後の挙動」にあることが明確になりました。

✅ 技術的な考察：asyncDataとSSRの挙動の違い

原因を深く調査していくと、Nuxt.js特有の「SSR（サーバーサイドレンダリング）」と「クライアントサイドでの遷移」の仕組みの違いに突き当たりました。今回のプロジェクトでは、記事データの取得にasyncDataメソッドを使用していました。

画面遷移時（nuxt-link）: NuxtはSPA（Single Page Application）として振る舞い、ブラウザ側（クライアントサイド）でasyncDataを実行しようとする。
リロード時（初回アクセス）: サーバー側でasyncDataが実行され、HTMLが完成した状態でブラウザに届く。

エラーの正体は、クライアントサイドで実行される際に、axiosなどのプラグインや環境変数が正しく参照できていなかった（undefinedになっていた）ことによるものでした。

✅ 💡 解決策：nuxt-link から a タグへの変更

本来であれば、クライアントサイドでのデータ取得を完璧に実装し直すべきですが、今回のブログ構築の目的は「SSRによるSEO効果の最大化」と「確実な表示」です。検討の結果、内部リンクに使用していた<nuxt-link>を、標準的な<a>タグへ書き換える手法を選択しました。

📌 修正前

<nuxt-link to="/blog/xxx">記事を読む</nuxt-link>

📌 修正後

<a href="/blog/xxx">記事を読む</a>

📌 この対応による変化

<a>タグを使用することで、画面遷移のたびにサーバーへリクエストが飛び、常にSSRされた状態のページが返ってくるようになります。これにより、クライアントサイドでJavaScriptがデータ取得に失敗するリスクをゼロにすることができました。SPA特有の「一瞬で画面が切り替わる」感覚はわずかに薄れますが、ブログというコンテンツの性質上、リロードが発生しても表示の確実性を優先する判断を下しました。

✅ 📌 まとめ：エンジニアとして学んだこと

今回のトラブルを通じて、以下の3点を再認識しました。

「動くこと」を最優先する判断: 完璧なSPAを目指してデバッグに数日かけるよりも、まずは<a>タグで確実にサービスをリリースする。この「納期と品質のバランス」も、実務に通じる大切な視点だと感じています。
SSRのライフサイクル: サーバー側で動くコードと、クライアント側で動くコードの境界線を意識することの難しさと面白さを学びました。
devモードを過信しない: npm run devで動くのは当たり前。早い段階でプロダクションビルド（npm run start）での挙動を確認する重要性を痛感しました。

この時の「なぜ？」という探究心が、現在のインフラ・ネットワーク構築のスキルにも繋がっています。