はじめに
Next.js（v14 app router）,TypeScriptでWordPressのREST APIを使ったヘッドレスCMSのサイトを制作していました。
デプロイ先はvercelです。
今回、「開発環境では問題なく機能し、ビルドエラーも一切出ないのに、本環境でのみデータフェッチに失敗する」というエラーに行き詰まったので、筆者と似たようなエラーに遭遇された方の解決の一助となるべく記事にしていきます。
今回のエラーの内容や概要に関しては以下の質問に詳しく記載していますので必要に応じてご参照ください。
結論
今回のエラー原因は、データフェッチもとWordPressサイトをホスティングしている国内サーバーのサーバー設定にありました。
そのサーバー設定というのが 「国外IPからのREST APIへのアクセス制限設定」 です。
おそらく、デプロイ先がvercelなのでこの制限に抵触したのだと考えています。
今回はタイトルから察せる通り、この制限をOFFにすることで無事に本環境でもデータフェッチできるようになりました。
とはいえ今回テーマのデプロイ時エラーをはじめ、起こりうる様々なエラーの原因は多岐に渡るかと思いますので、自戒と備忘録、誰かの一助になれればと筆者なりのデバック方法について書いていきます。
課題と原因の列挙
今回の課題は先ほど述べたように以下となります。
- 開発環境では問題なく機能し、ビルドエラーも一切出ないのに、本環境でのみデータフェッチに失敗する
上記に対して以下のような可能性が考えられます。
- タイポ（ケアレスミス）
- プログラミング・コーディングそのもののミス（知識・技術不足）
- フレームワーク（
Next.js）やデプロイ先（vercel）の仕様・設定への理解不足 - エンドポイントの作成・設定ミス
-
CORSをはじめ各種webに関する仕様や設定への考慮漏れや記述ミス
他にもまだあるかと思いますが、筆者はこれらを原因の可能性として考えていました。
「タイポ」や「プログラミング・コーディングそのもののミス」
先ほど挙げた中でも特に自身に起因するものを一番怪しんでいたため、生成AIを活用したりして右往左往しながら時間が過ぎていきました。（これはこれで、デバック過程において色々な知識や経験、学びを得られたので良かったのですが）
生成AIを活用する中でハルシネーションに出会いました。
具体的には生成AI（Claude 3.5 Sonnet）の回答である「Nextのドキュメントページまたはその引用文が実は存在しません」でした。
回答内容をもとにデバックしていて何かおかしいと感じたことから引用元ページを見に行くと404だったり、ページが存在していても当該引用文がなかったりして、生成AIにそのことを尋ねると「存在しない情報を提供して申し訳ない」的な謝罪をされました。
「うぉーい！」って感じだったのですが、そもそも最初に見抜けなかった自身の知識不足に残念です。
釈迦に説法かもですが、生成AIが情報ソースや引用文を提示してきた場合は鵜呑みにせず「自分の目で情報ソースページや当該引用文が存在するかを確認」されたほうが良いかと思います。
話が少し逸れましたが、人間なのでミスはあると思います。
VSCodeなど多くのテキストエディタは記述ミスっぽいところを明示的に教えてくれますが、「データやファイルの参照先ソースパス、エンドポイントの記述ミス」などは流石に拾ってくれないので注視しておきたいところです。
（データやファイルの場合はログに404などが表示されるので明示的と言えばそうですが、エンドポイントが違っていた場合や設計ミスでパスが通ってしまった場合はエラー特定が不明瞭になるケースも考えられるかと思います）
「フレームワークやデプロイ先の仕様への理解不足」
これはそもそも『利用するフレームワークやデプロイ先のドキュメント（マニュアル）をしっかり読んでおけよ』という話かと思います。
しかし筆者みたいに『説明書を読む前に触ってみて楽しみたい！』という方も多い？かと思い、筆者のようなタイプの人向けに提案してみたいと思います。
大前提として当たり前ですが公式ドキュメントはちゃんと読むべきですし（自戒）、今から記載する内容は公式ドキュメントを決して蔑ろにすることを推奨するものではありません。
結論として「行き詰まった時にドキュメントを参考にする」です。
公式ドキュメントの重要性は理解しつつも、全てを読んでから作り始めるのは （腰が重いし） 時間的な制約が厳しいですし、モチベーションも上げづらいです。
何より一切アウトプットをせずにインプットするばかりでは実装イメージが付きづらく、理解につながらないと思います。
そのため先ずは（必要最低限のインプットは必要ですが）アウトプットを意識して行き詰まった時にドキュメントを参考にするのがモチベーション的にもベターだと感じています。
そして公式ドキュメントのほか、効率的に必要な情報を得るために筆者が意識している一つに「英単語での検索」があります。
これは有名だと思うのでメリットなど詳しくは説明しませんが、筆者は以下のような感じで検索したりします。
- 「開発環境 → dev」
- 「デプロイ → deploy」
- 「動く、機能する → work」
- 「うまくいかない、動かない、効かない → ~~ but failed」
もちろん、日本語で分かりやすい情報があって無事に解決できたならそれでも良いのですが、なかなか目ぼしい情報がヒットしない場合はこの方法を検討してみてください。
あとは、表示されたエラー文章そのものをダブルクォーテーションで囲って検索したりとか、情報の正しさには注意が必要ですが Qiita や Zenn などの技術記事を参考にしたりとかですかね。
とはいえ、くどいようですが一次情報源である公式ドキュメントが一番良い情報ソースです。
「エンドポイントの作成・設定ミス」
これは「タイポ」や「プログラミング・コーディングそのもののミス」といった部分にも被ってくる内容かもしれません。
あと、エンドポイントは【設計】という奥深さがあるので筆者の知識量・経験では深入りできないところでもあります（逃げ）。
「CORSをはじめ各種webに関する仕様や設定への考慮漏れや記述ミス」
こちらも学習コストが高い部分だと感じます。
個人的に、こういった理解するのに時間かかりそうなところは Qiita や Zenn など程よく内容を咀嚼してくれている技術記事で大体の雰囲気を掴んでから次のステップ（より本格的な情報ソースや書籍での学習）に進む、というような感じでも良いかなと思っています。
最初からがっつり本格的な内容を見ても理解できず苦しいと思いますしね（実体験）。
筆者もまだまだな部分なので今後も精進していきたいと思います。
さいごに
冒頭の結論に書いた通り、
今回のエラー原因はデータフェッチもとWordPressサイトをホスティングしている国内サーバーの 「国外IPからのREST APIへのアクセス制限設定」 でした。
今回の筆者ようなvercelをはじめ、AWSやAzure、Google Cloud、CloudFlare、netlifyなど海外ホスティングを使っている方も最近では少なくないと思います。
筆者は愚かなことに「国外IPからのアクセス制限」という解にたどり着くまで3ヶ月近く費やしてしまいました。
もし似たような状況で困っている方が本記事を読んで、
「もしかしてデータフェッチエラーは自分起因ではなく『（データフェッチもとの）サーバー設定』にあるのかも？」となり、
あわよくば無事に解決につながったり、その糸口が掴めたりすれば嬉しく思います。
筆者は、今回のデバック過程においてNext.js（React）のサーバーアクションやRoute Handlersの知識や経験、コンポーネント構成、useStateへの理解（*1）、ネットワークに関する基礎知識、生成AIへのプロンプトや回答情報の取り扱いなど多くのことを学べましたのでヨシ！とします。
（というか少しでもポジティブに考えないとデバックに費やした時間と労力が虚しいので……泣）
*1：useStateのスナップショットについての内容です。
state をセットしても、既にある state 変数は変更されず、代わりに再レンダーがトリガされます。
リンク先の冒頭説明にあるように「セッター関数でstateを更新しても即座に反映されるのではなく、次の更新に向けた状態をセット（再レンダリングをトリガー）するだけであり、実際に反映されるのは次回更新時（再レンダリング時）になります。
一般的に state管理においてはその対象を最小限として計算可能なもの（例：配列のsortやfilter操作など）は計算によって用意することがベターとされています。
実は、まるまる3ヶ月近くずっとデバックしていたわけではなく、案件の進捗に鑑みてSSR/ISR × vercelからSSG（client fetch） × 国内ホスティングサービスという仕様に切り替えて進めており、合間を縫って片手間でデバックをしている状況でした。
仕様変更していたので本エラーの解消は必須ではなかったのですが、放置するのも気分が悪いと感じていたのです。
諦めずにデバックすることで無事に解消できたので、プログラミングにおける粘り強さ・根気の重要性を再確認できましたし、新たな視点が広がった実感もあります。あとは、何より達成感でいっぱいですね。
ここまで読んでいただき、ありがとうございました！
参考記事