【9章】microCMS導入演習の振り返り

結論

• APIキーなどの秘匿情報は .env.local に定義し、GitHubの管理対象から外す

• .env.local は プロジェクトのルート(package.json と同じ階層) に置く

• 今回のエラーの原因はコードではなく、VS Codeで開いていたフォルダが1つ上の階層だったこと

• 技術的な知識が正しくても、環境や操作のズレがエラーを生む。ヒューマンエラーを防ぐ運用ルールが必要

Chapter 9 の最後にやったこと

microCMSのAPIキーをコードに直書きしていた状態から、環境変数 .env.local に移す対応を行いました。APIキーがGitHubにpushされてしまうと、第三者に悪用されるリスクがあるためです。

.env.local がpushされないのは、Next.jsプロジェクト作成時に生成される .gitignore にデフォルトで含まれているためです。ファイル名を .env.local にすれば自動で安全になるのではなく、.gitignore がGitの追跡対象から外してくれている、という仕組みです。

作業を進めるにあたっては、エラーの影響範囲を狭くするため、コードの編集は最小単位で行うことを意識しました。一度に複数箇所を変更すると、エラーが出たときに原因の切り分けが難しくなるからです。

発生したエラー

APIキーを環境変数に置き換えたところ、以下のエラーが発生しました。

Uncaught TypeError: Cannot read properties of undefined (reading 'length')

これは posts が undefined の状態で .length を参照したことを意味します。因果関係を整理すると、

1. 環境変数からAPIキーが読み込めない

2. microCMSへのfetchが失敗する

3. posts に値が入らず undefined になる

4. posts.length を参照した時点で TypeError

つまりエラーが表示された箇所は「結果」であって、「原因」は環境変数の読み込みにありました。

原因調査の過程

当初は次の2つを疑いました。

• .env.local に書いた変数定義の記述ミス

• エラーが出た対象コードの不具合

しかし、ぶべさんのお手本動画と見比べても、コードに違いはありませんでした。

次に疑ったのが .env.local の格納位置です。「プロジェクトの一番上に配置する」という自分の認識が正しいのか調べたところ、認識自体は合っていました。

本当の原因

ファイルの位置を見比べて気づいたのは、VS Codeで開いていたフォルダが、プロジェクトのルートより1つ上の階層だったことです。

VS Code上では「一番上」に .env.local を作ったつもりでも、実際にはプロジェクトの外側に置かれていたため、Next.jsが環境変数を読み込めていませんでした。

コードも知識も正しかったのに、「フォルダの開き方」という技術以前の要素がエラーの原因になっていた。この経験から、エラーの原因は技術的な面だけでなく、小さな操作のズレにも潜んでいると実感しました。

再発防止策

「ヒューマンエラーに繋がらない設計」を抽象論で終わらせないために、次のルールを決めました。

• VS Codeは、Pull Requestを出すディレクトリを最上階層にして開く

こうすれば「VS Code上の一番上 = プロジェクトのルート」が常に一致し、今回のようなファイル配置ミスは構造的に起きなくなります。

まとめ

エラーは成長するための機会だと考えています。「原因はコードの中だけにあるとは限らない」という視点と、それを防ぐ具体的な運用ルールを得られました。次の章でも、詰まったら原因を切り分けて、1つずつ潰していきます。