TPC LLC

ホームページをリニューアルしました

Payload CMS
2026年3月10日2026年3月30日
tpc-logo

この記事を書いた人

荻原 佑輔

Software Engineer

合同会社TPCを2022年に創業。

名古屋大学情報学部を卒業後、Web系をメインにフリーランスエンジニアとして活動。

ちょっとした業務効率化ツールの開発からWeb3案件、SaaS開発や公共系の案件まで幅広く従事。


ホームページリニューアルのお知らせ

2026年3月12日に弊社の公式ホームページを旧サイト( https://tpc-llc.dev )からリニューアルしました！

以前の自社サイトの問題点

以前のホームページはAWS Lightsailの上にWordPressを載せて公開していました。


また弊社では複数のWordPress製サイトを運営しておりましたが、運用にあたって以下のような問題を抱えていました。

  • 複数のレンタルサーバー事業者のサーバー上にサイトが配置されているため、無駄な費用が発生

  • WordPress製サイトにLPを組み込みつつ、コンテンツをCMS側で管理することが難しい

  • WordPressの機能を拡張するプラグインやテーマのためだけにPHPを使いたくない

ちょうど全社インフラの全面的な見直しを行うタイミングだったこともあり、ホームページのフルリニューアルを実施しました。

リニューアル後の技術構成

インフラ

Before

  • AWS Lightsail

  • ロリポップ

  • さくらのレンタルサーバ

After

  • コンピュート: GCP CloudRun

  • CDN: Cloudflare

  • DB: Turso

  • ストレージ: Cloudflare R2

ポイント

この変更により

  • Terraformで全てのインフラを管理できるようになった

  • サーバレス化 & DBにTursoを採用することで、サーバー代がほぼ0円になった

  • CDNの導入により表示速度が大幅に向上した

といったメリットが得られました。

CloudRunを低コストかつコールドスタートなしで運用するポイント

だいぶ色々な箇所を省略していますが主要な箇所は以下のコードに集約されています。

cms.tf
Terraform
resource "google_cloud_run_v2_service" "cms" {

  template {
    scaling {
      min_instance_count = 0
      max_instance_count = 2
    }

    containers {
      resources {
        limits = {
          cpu    = "2"
          memory = "1Gi"
        }
        cpu_idle = true
      }
    }
  }
}
monitor.tf
Terraform
resource "google_monitoring_uptime_check_config" "monitor" {

  timeout      = "10s"
  period       = "300s"

  http_check {
    path           = "/"
    port           = 443
    use_ssl        = true
    validate_ssl   = true
    request_method = "GET"
  }
}


色々省略していますが、ポイントとしては

  • min_instance_countを0にすることで常時起動を防ぐ

  • cpu_idleをtrueにすることでアイドルタイムに課金されないようにする（デフォルトはfalseなので注意）

  • uptime_checkで5分に1回リクエストを飛ばすことで常に1つ以上のインスタンスを動かしつつアイドルの状態を維持する

ことでサーバー代をほぼ0円にして運用できます。

CMS

Before

  • WordPress

After

  • Payload CMS

ポイント

この変更により

  • 単なるNext.jsのパスベースルーティングなので全画面フルコーディングされたLPとの統合が非常にやりやすく、サイト構造の自由度が高い

  • Payload CMSはNext.js製なので既存のパッケージを有効に利用できる

  • 中身は単なるNext.jsなので自由に拡張でき、TypeScriptなのでプラグインも作りやすくLLMも扱いやすいコードになる

  • ヘッドレスCMSなのでコンテンツとビューを疎結合にできる

  • 柔軟性が高く構造化マークアップも気軽に入れられる

  • OSSでセルフホスト可能なのでAPIが叩き放題

といったメリットが得られました。


とりわけ既存のnpmパッケージやNext.jsエコシステムの恩恵を受けられるメリットは非常に大きいように感じました。


UI周りならTailwind CSSを使っても良いし、Radix UIでヘッドレスUIみたいなことをしても良いです。

このサイトはTailwind CSSで作っています。


i18n周りならnext-intlやnext-i18nを使うことができます。


サイトマップもnext-sitemapで簡単に作れます。


活用可能なアセット観点では、少なくともWordPressと同程度以上の成熟度といえます。

デメリット

今回ホームページをPayload CMSで作り直して感じたデメリットとしては

  • 本体のサイトと独自拡張のプラグインの境界を定めるのが難しい

  • カスタムコンポーネントのドキュメントがコードしかなく、それを実装してどこに表示されるのかがわかりにくい

  • WordPressと異なりセルフアップデートができないので、Renovateを使うなど別途アップデートの流れを考える必要がある

  • 日本語文献が少ない

といったところでしょうか。


とはいえこれらの大半は長期的には解決するような問題です。

まとめ

個人的には、セルフホストができるOSSのヘッドレスCMSフレームワークとしての完成度はピカイチだと思っています。


また現在のPayload CMSはFigma傘下にあります。


Payload is joining Figma!

Payload is joining Figma!

Figma and Payload together can and will solve a problem that’s been bugging me (and probably all of you) for years.


今後の成長を楽しみにしながら積極的に使っていこうと思いました。

この記事を書いた人

荻原 佑輔

Software Engineer

合同会社TPCを2022年に創業。

名古屋大学情報学部を卒業後、Web系をメインにフリーランスエンジニアとして活動。

ちょっとした業務効率化ツールの開発からWeb3案件、SaaS開発や公共系の案件まで幅広く従事。