Next.js + NextAuth (v5) で構築された、AI画像ストックサイト「free-images」というサービスに E2E テスト（Playwright）を導入しました。
初期段階では「Googleログインしかないから、テストが難しいな」くらいに考えていたのですが、実際は認証基盤のアーキテクチャ変更にまで発展する大工事となりました。
この記事では、直面したエラーとその解決策、そして最終的に完成した「テスト用裏口実装」のコードを共有します。
「ドメインは短い方がクールだ」
そう思って、個人開発のサイトではこれまで https://example.com のような「wwwなし（ネイキッドドメイン）」を好んで使っていました。しかし、このブログ（Astro Starlight + Vercel）を構築し、Google AdSenseやSearch Consoleの設定を進める中で、その認識を改めることになりました。
今回は、Vercel環境においてなぜ「wwwあり」が推奨されるのか、そしてAstroの設定でハマりやすい サイトマップの罠について共有します。
Webアプリケーションを開発する上で、避けて通れないのが**「認証 (Authentication)」**です。
特に Next.js + NextAuth (Auth.js) のようなモダンな構成を採用する場合、裏側で何が起きているのかを理解していないと、「ログインできない」「テストが通らない」「意図しないログアウトが起きる」といったトラブルに対処できません。
この記事では、認証周りの重要キーワードを、イメージしやすいように整理しました。
現在開発中のAI画像ストックサイト『free-images』に、品質担保のためE2Eテストツールである Playwright を導入することにしました。
「モダンなツールだし、サクッと導入できるだろう」と高を括っていたのですが、Firefox環境でのみテストが落ちる という泥沼にハマりました。 今回はそのトラブルシューティングの記録を残しておきます。WSL環境で開発している方の参考になれば幸いです。
「赤い布の画像を作って」 AIにそう頼めば、確かに赤い布の画像は出てきます。しかし、それは果たしてストックフォトサイトで「売れる素材」と言えるでしょうか？
現在開発中の画像ストックサイト『free-images』では、単なる自動生成を超え、デザイナーが「これこそ探していた質感だ」と唸るクオリティを目指しています。今回は、Google Gemini APIを駆使したプロンプト改善の旅についてお話しします。