このサイトはWordPressで作っています。CMSとして有名で情報も多く、プラグインも豊富。設置も簡単だったので使い始めたのですけど、いかんせん重い。
とくにコメント機能が盛り上がっているわけでもないので静的サイトで十分じゃないか、という結論に達しまして。編集作業はローカルで行い、静的サイトとしてエクスポートして公開することにしました。
ローカルでWordPressを稼働させるにあたり、SynologyのNASを活用させることにしました。というわけでそれなりに苦労もしたので手順を残しておきたいと思います。
移行の手順
WordPress
我が家にある SynologyのNASは DS216j です。家庭用の低価格マシンです。
パッケージセンターから WordPressを探してインストールすると、依存関係にある Apache HTTP Server や PHP や MariaDB も自動でインストールされます。これは楽ちんです。やり方を紹介しているサイトもたくさん見つかります。
最新版のWordPressではなく Synology が動作確認したバージョンで固定されたものになります。(私がインストールしたときは、WordPress 6.1.1、Apache HTTP Server 2.4、PHP 8.0、MariaDB 10.3.32 でした。)
インストールが完了したらサイトの移行を行います。WordPress間の移行はエクスポート機能を利用することができるので省略します。
GitHub
まず、GitHub に公開資材を格納するレポジトリ(komina-info-publish)をPrivateで作成しました。任意のディレクトリで git clone して初期資材を作成していきます。
$ git clone https://github.com/komina77/komina-info-publish.gitkomina-info-publish
├── app.yaml
└── www/
└── index.html
直下に app.yamlを作成。
wwwフォルダを作成しテスト用のindex.htmlを作成。
runtime: python313 # ランタイム指定(静的でも必須)
instance_class: F1 # 無料枠を使うならF1を指定
automatic_scaling:
min_instances: 0
max_instances: 1
handlers:
# ルートURLの場合 index.html を返す
- url: /
static_files: www/index.html
upload: www/index.html
# その他のパスは www/ 以下のファイルにマッピング
- url: /(.*)
static_files: www/\1
upload: www/(.*)<h1>Hello, World!</h1>App Engine
サイト公開用のプロジェクトの準備ができたら、Google Cloud にログインしプロジェクト(komina-info-publish)を作成、App Engineでアプリ作成します。
- 近場の東京リージョン(
asia-northeast1)を選択 - サービスアカウントはデフォルト設定
- 言語は
Python、Standard環境を選択。
AppEngine側の準備ができたらプロジェクトを手動でデプロイして動作確認してみます。
$ gcloud app deploy
$ gcloud app browseブラウザにテスト用のindex.htmlの内容が表示されていればOKです。
GitHub → AppEngine
そうしたら、GitHub のコミット契機で AppEngine へデプロイされる仕組みを作ります。
Google Cloud Console で IAM サービスアカウント作成します。
- 権限付与
App Engine Deployer(App Engine デプロイ担当者)Storage Admin(Storage オブジェクト管理者)App Engine Admin(App Engine管理者)Cloud Build Service Account(Cloud Build サービスアカウント)Service Account User(サービスアカウントユーザ)
- 鍵を作成、json形式で保存
GitHub→Settings→Secrets and variables→Actions を開き、新しいSecret作成します(名前は GCP_CREDDENTIALS、内容はjson形式の鍵ファイルの中身を転記)。
GitHub→Settings→Secrets and variables→Actions を開き、新しいRepositoryVariable作成します(名前はGCP_PROJECT_ID、値は komina-info-publish)。
AppEngineへのデプロイ準備が整ったら、mainブランチへのpushをトリガにして AppEngineへデプロイするジョブを作成します。
name: Deploy to App Engine
on:
push:
branches: [ main ] # mainブランチへのpushをトリガー
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout source
uses: actions/checkout@v3
- name: Authenticate to Google Cloud
uses: google-github-actions/auth@v2
with:
credentials_json: ${{ secrets.GCP_CREDENTIALS }}
- name: Deploy to App Engine
uses: google-github-actions/deploy-appengine@v1
with:
project_id: ${{ vars.GCP_PROJECT_ID }} # リポジトリ変数から取得
deliverables: app.yaml # デプロイ対象
- name: Clean up old versions
run: |
# トラフィック割当0%の全バージョンを削除
gcloud app versions list \
--project=${{ vars.GCP_PROJECT_ID }} \
--format="value(version.id)" \
--filter="traffic_split=0.0" | \
xargs -r gcloud app versions delete \
--project=${{ vars.GCP_PROJECT_ID }} --quietApp Engine Admin APIを有効にします。

main/www 配下に任意のweb資材を置いてpush。App Engine へリリースされていることを確認できればOKです。
WordPress-Staaticプラグイン
静的サイトを出力するプラグインとしては Simply Static というプラグインが有名なようです。残念ながら WordPress 6.1.1 では動作しないということでインストールできなかったので、次点でヒットした Staatic – Static Site Generator をインストールしました。
- GitHub の プロフィールアイコンから、Settings → Developer settings → Personal access tokens→Fine-grained personal access tokens
- 適当な期限を入力。
- レポジトリを指定:
komina-info-publish - 権限の付与:
Content: read and write - 生成されたトークンをGitHubトークン欄へコピペ。
- レポジトリ:
komina77/komina-info-publish - ブランチ:
main - 接頭辞:
www(/を付けてはいけない)
WordPress-パーマリンク
WordPressサイトを静的サイトに変換するにあたってパーマリンク設定に注意が必要です。GETパラメータを含むURLや、/ (スラッシュ)で終わらないURLは、htmlのみで再現できないためです。
変換元サイトでは /archives/123 のような数字ベース形式を採用していたのですが、このままでは変換できないので最後に / (スラッシュ)を加えた形式をカスタム構造に設定しました。

リダイレクト設定
変換元サイトで検索エンジンに登録されていた /archives/123 のようなURLへの参照があったときに 404 が返されてしまうと訪問者に不便が生じます。新しい /archives/123/ へ 301リダイレクトするように設定を追加します。
といっても app.yaml の handlers設定ではそこまでできないようなので、Pythonにやってもらうことにしました。
from flask import Flask, redirect
app = Flask(__name__)
@app.route("/archives/<int:num>")
def redirect_archives(num):
return redirect(f"/archives/{num}/", code=301)Flask==3.0.0# handlers以下を抜粋
handlers:
# アーカイブURL(数値のみ)をスラッシュ付きにリダイレクト(ルート除く)
- url: /archives/([0-9]+)$
script: auto # アプリケーションコードに処理を委ねる
# スラッシュで終わるURL(任意の深さ)の場合、index.htmlを返す
- url: /(.*)/$
static_files: www/\1/index.html
upload: www/(.*)/index.html
# ルートURLの場合 index.html を返す
- url: /
static_files: www/index.html
upload: www/index.html
# その他のパスは www/ 以下のファイルにマッピング
- url: /(.*)
static_files: www/\1
upload: www/(.*)一連の動作確認
これまでの設定がうまく行われていれば、Staaticプラグインで公開することで、静的サイト資材の作成、GitHubへのPush、AppEngineへのデプロイまで自動で行われるようになります。
私の環境、サイトでは資材の作成の10分強、GitHubへのPushに10分弱、AppEngineへのデプロイに3分弱、と言ったところでしょうか。
カスタムドメイン設定
NASで稼働する WordPressサイトを AppEngineで公開できることが確認できたら、ドメイン設定を行って正式に移行を完了させます。
AppEngineの設定からカスタムドメインを選択。




自分のドメインと対応付けていき、最後に表示されるキーをDNSのレコードに登録します。私の場合は muumuuドメインを利用しているので管理画面からムームーDNSの komina.info の変更へ進みます。

DNS設定が反映されるまでに少し時間がかかります。めでたく https://komina.info/ で静的サイトへアクセスできなっていれば移行は成功です。
考察など
App Engineに静的資材を公開する機能があるのは知っていはいたのですが、ほぼ100%静的サイトとして利用するのは初めての試みでした。
非常にレスポンスも速く、今のところ満足しています。
今回犠牲になったコメント機能ですが、AppEngineということなのでPythonで実装するのもアリかな、とか思ったりしています。手が空いたら考えてみたいと思います。