このWebサイトは、単にプロフィールや実績を掲載するためだけに作ったものではありません。

自分自身の活動を整理し、発信の土台を作り、今後のサービス展開やコミュニティ運営にもつなげていくための、ひとつの技術基盤として設計しています。

今回から、このWebサイトを作る中で考えたこと、選んだ技術、実装中に発生した課題、AWS上で運用するために検討したことなどを、連載形式で少しずつまとめていきます。

なぜ自分でWebサイトを作るのか

Webサイトを作るだけであれば、既存のCMSやノーコードツール、ブログサービスを使う選択肢もあります。

実際、初期コストや運用負荷だけを考えるなら、その方が合理的な場面も多いです。

それでも今回は、Next.js、Payload CMS、AWSを組み合わせて、自分で設計・実装・運用する構成を選びました。

理由は大きく3つあります。

1つ目は、発信内容や見せ方を自分でコントロールしたかったことです。

記事、実績、プロフィール、問い合わせ、将来的なコミュニティ機能などを考えると、単なるブログではなく、自分の活動全体を扱えるWeb基盤が必要でした。

2つ目は、技術検証の場として使いたかったことです。

SSG、SSR、CMS、認証、画像管理、AWSインフラ、CI/CD、コスト設計など、実務でも重要になる要素を、自分のプロジェクトで一通り扱えるようにしたいと考えました。

3つ目は、長く育てられる構成にしたかったことです。

最初から大きなシステムを作るのではなく、まずは小さく公開し、必要に応じてCMSや動的機能を追加し、さらに将来的にはコミュニティツールなどへ拡張できる余地を残す設計を意識しています。

最初から完璧な構成にはしない

今回のWebサイトでは、最初からすべてを動的なWebアプリケーションとして作るのではなく、段階的に構成を変えていく方針を取りました。

最初の段階では、静的サイトとして公開できる範囲を優先しました。

静的サイトは、運用コストが低く、表示速度も安定しやすく、障害範囲も小さくできます。個人サイトや小規模な事業サイトでは、とても強い選択肢です。

一方で、記事や実績を継続的に更新していくにはCMSが必要になります。

そこで次の段階として、Payload CMSを導入しました。CMSを入れることで、記事やメディアを管理画面から更新できるようになりますが、その分だけ、データベース、認証、画像保存、デプロイフローなど、考えるべきことも増えます。

このあたりの判断は、単に「どの技術が新しいか」ではなく、今の規模、将来の拡張性、運用コストのバランスを見ながら決める必要がありました。

今回扱っていく主な技術

この連載では、主に以下のようなテーマを扱っていく予定です。

  • Next.js App Routerによるサイト構成
  • SSG、SSR、ISR、CSRの使い分け
  • Payload CMSの導入とコレクション設計
  • 記事、カテゴリ、メディア管理の実装
  • Keycloakを使ったSSO認証
  • ローカル開発での認証モック
  • AWS App RunnerによるCMS運用
  • S3とCloudFrontによる静的サイト配信
  • Payload CMSから静的サイトを再ビルドする仕組み
  • S3を使ったメディア保存
  • RDBを含むインフラコストの考え方
  • DNS、独自ドメイン、メール利用との共存
  • デプロイ後に発生した不具合と修正方針

実装そのものだけではなく、「なぜその構成にしたのか」「どこで詰まったのか」「次に同じことをやるならどうするか」も含めて整理していくつもりです。

実装して初めて見えたこと

今回のWebサイト作成では、実際にデプロイしてから見えてきた問題も多くありました。

たとえば、CMSで記事を更新しても公開サイト側に反映されない問題がありました。

静的サイトとして配信している場合、CMSのデータを変更しただけではHTMLは更新されません。静的サイトを再ビルドし、S3へ同期し、CloudFrontのキャッシュを無効化する必要があります。

また、Payload CMSで画像をアップロードしたものの、アイキャッチ画像が表示されない問題もありました。

これは、メディアのレコードはデータベースに存在している一方で、実体ファイルが永続ストレージに保存されていない、あるいはS3連携前にアップロードされたファイルが残っていない、という問題でした。

さらに、S3ストレージプラグインを導入した後、Payloadの管理画面が何も表示されなくなる問題もありました。

原因は、Payload Admin用のimport mapを再生成していなかったことです。HTMLは返っているのに画面が空になるという症状だったため、Playwrightでブラウザ上の描画状態を確認しながら切り分けました。

こうした問題は、ドキュメントを読んでいるだけではなかなか実感しづらい部分です。

実際に作って、壊して、直していくことで、構成の意味や注意点が見えてきます。

この連載で目指すこと

この連載は、完成済みのきれいな手順書というよりも、Webサイトを実際に作りながら得た技術的な記録です。

個人サイト、小規模な事業サイト、CMS付きのWebサイト、AWS上での低コスト運用を考えている人にとって、判断材料になる内容を目指します。

特に、以下のような人には参考になるかもしれません。

  • Next.jsでWebサイトを作りたい人
  • CMSを自分のサイトに組み込みたい人
  • Payload CMSに興味がある人
  • AWSで小さく始める構成を考えている人
  • 静的サイトとCMSをどう分けるか悩んでいる人
  • 個人開発でも運用まで見据えた設計をしたい人

Webサイトは、作って終わりではありません。

記事を書き、実績を追加し、画像を管理し、必要に応じて機能を増やし、障害が起きたら直していく。そこまで含めて、ようやく「運用できるWebサイト」になります。

この連載では、その過程をできるだけ具体的に残していきます。

まずは次回、Webサイト全体の構成と、なぜNext.jsとPayload CMSを組み合わせることにしたのかを整理していきます。