作成したAWS環境で高可用性構成 というのが何か知りたい方は以下もご覧いただけますと幸いです。

Fargate + Single AZ RDSで構築する、高可用性&コスト最適化WordPress AWS構成

opticode.lab.com

なお、AWSプランや管理画面はよく変更されるため、2026年3月時点の設定であることをご理解ください。

CloudFrontとは？サービス内容を解説

CloudFrontは、AWS（Amazon Web Services）が提供するCDN（Content Delivery Network）サービスです。
簡単に言うと、「世界中に配置されたキャッシュサーバーを使って、Webサイトの画像や動画、HTMLなどのコンテンツをユーザーに素早く届ける仕組み」です。
競合サービスとしてはCloudflare、Akamai、Fastlyなどがありますが、AWSで環境を構築しているならCloudFront一択です。

CloudFrontを導入するメリット

導入すると以下のようなメリットがあります。

• ページキャッシュ：ページや画像などをキャッシュしてユーザーへ渡すため、オリジンであるWebサーバー等へのアクセスを抑えてコストダウン&負荷耐性が向上
• エッジロケーション：ユーザーと物理的に近いデータセンターにキャッシュを保持してユーザーへ渡すため、表示速度の向上につながる
• AWSコンポーネントとの親和性：AWS連携が容易でサービス間でのデータ転送量が安い
• 無料枠：小規模なサイトであれば実質無料で使用できることも珍しくない
• セキュリティ向上：CloudFrontが間に入りユーザーがWebサーバーを直接見ないためセキュリティが向上・WAF設定も可能

無料枠を超えるアクセス数の多いサイトは費用がかかりますが、高スペックなサーバーを動かし続けるより安く済む場合が多いでしょう。

WordPressでCloudFrontを使用する場合の注意点

メリットは大きいですが、注意点もあります。

• ログイン状態のページがキャッシュされる
• カスタムポリシーを使用できるプランに制限がある

ログイン状態のページがキャッシュされる問題と解消方法

CloudFrontはユーザーがページへアクセスした場合に、
キャッシュがあればキャッシュを返す
キャッシュが無ければオリジンからページを取得しキャッシュを生成
という動作を行います。

そこで問題になるのが、ログイン状態のユーザーです。
WordPressでログインをしている場合、ページ上部の admin bar のようにWordPressログイン状態にのみ表示される要素が存在するため、これをCloudFrontがキャッシュしてしまうと一般ユーザーにも admin bar が表示されるような事態となってしまいます。

つまり、WordPressにログインしたユーザーをキャッシュ対象外にする必要があります。

設定にはCloudFrontのカスタムポリシー作成が必須となりますので、以下の手順でカスタムポリシーを作成のうえCloudFrontのビヘイビアに登録します。

• AWSコンソールからCloudFrontの管理画面を開き、左メニューからポリシーの管理ページを表示

• ページ下部の「キャッシュポリシーを作成」
• cookie「指定された cookie を含める」を選択し以下の3つを追加しポリシーを作成する
  comment_author_*、wp-postpass_*、wordpress_logged_in_*

• CloudFrontのディストリビューション、ビヘイビア設定の「デフォルト(*)」を選択し編集
• キャッシュポリシーで作成したカスタムポリシーを選択、オリジンリクエストポリシーをAllViewerに設定し保存

これはWordPressのログインセッションに使用するcookieを持っていればログインユーザーとして扱い、ページをキャッシュしない&キャッシュを表示しない という設定です。

カスタムポリシーを使用できるプランに制限がある

なんと、CloudFrontのディストリビューションが定額料金プランのFreeプラン(0$)・Proプラン(月額15$)はカスタムポリシーが選択できず、ビジネスプラン(月額200$)以上を選べという案内が表示されます。
学習目的や収益の少ないサイトでこの負担は現実的ではありません。

しかし、従量課金プラン(Pay as you go) を使用すればビジネスプランでなくともカスタムポリシーを使用することが可能です。
従量課金プランでも一定の範囲内であれば無料で使用が可能ですので、学習用や小規模なサイトであれば従量課金プランで始めて、アクセス数が増え収益が出るならビジネスプランへの変更を検討するのがよさそうです。

無料枠については今後変更される可能性があるため、AWS公式の情報をご確認のうえ検討してください。

まとめ

最初は定額プランのFreeプランで設定していたのでカスタムポリシーが設定できず手間取りました。
学習目的でお金をかけたくなかったため、従量課金プランでも無料枠があってくれてラッキーでした。

とはいえCloudFront自体はかなり安価なので、よほど記事がバズったりしなければ高額な請求などは無いかなとは思います。

1. 要件

• AWS学習を目的としてAWS Lightsail環境の当サイトをAWS高可用性構成で再現する。
• あくまでも学習のため、削れるコストは可能な限り削る。
• Lightsail環境のデータベースやメディアを全て移行する。

可用性とコストのどちらを優先するかは都度判断。

2. 構成図の全体像と設計思想

この構成図は、WordPressをAWS上に構築するための、疎結合（Decoupled）なモダン・アーキテクチャを示しています。

この構成の肝となる3つのポイント

• 高可用性（High Availability）: CloudFront、ALB、FargateマルチAZ展開
• コスト最適化（Cost-Optimized）:Fargate Spot、Single AZ RDS
• ステートレスなコンピュート層：Fargateコンテナを使い、テーマ、プラグイン、メディアファイルを外部サービスへ外部化

3. 各コンポーネントの詳細解説：データの流れに沿って

データの流れ（フロントエンドからバックエンドへ）に沿って、各コンポーネントの役割と設計意図を解説します。

3-1. フロントエンド（VPC外サービス）：配信の効率化と可用性

ユーザーアクセスはまず、VPC（Virtual Private Cloud）の外にあるグローバルサービスで受けます。

• AWS Route 53 (DNS): DNSルーティングを行います。
• AWS CloudFront (CDN): データの配信の肝です。
• 静的コンテンツ origin: Amazon S3 から画像やCSS/JSをキャッシュして高速配信。
• 動的コンテンツ origin: ALBを経由してWordPress（Fargate）に接続。
• Amazon S3: WordPressのメディアファイル（アップロード画像など）を保存するストレージ。静的ファイルの配信はここを起点に行います。

設計のポイント：
静的ファイルをCloudFront/S3へ外部化することで、Fargateコンテナの負荷を大幅に軽減し、かつユーザーの体感速度を向上させています。

3-2. VPC内ネットワーク（Subnet設計）：疎結合と可用性の担保

VPC内は、高可用性を実現するために2つのアベイラビリティゾーン（AZ-a、AZ-b）にまたがって設計しています。

• Public Subnet: WordPressが動作するFargateコンテナを配置。
• Private Subnet: データベース（RDS）と、共有ストレージのマウントターゲット（EFS）を配置。外部からの直接アクセスを遮断し、セキュアに守ります。

コスト削減のポイント：
FargateコンテナはPrivate Subnet内に配置するとセキュリティを向上させることが可能ですが、NATゲートウェイ（月額2,000円ほど）が必要となります。
今回はコスト削減のためFargateコンテナはPublic Subnetに配置し、インバンドアクセスをALBに限定することでセキュリティを担保しています。

3-3. ロードバランサー（ALB）：マルチAZ可用性の鍵

• ALB (Application Load Balancer): Public Subnetにまたがって配置。CloudFrontからの動的リクエストを受け取り、背後のFargateタスクへ負荷分散します。

高可用性のポイント：
ALBは、AZ-aとAZ-bの両方のサブネットを監視し、正常なタスクにのみリクエストを振るため、どちらかのAZで障害が発生してもサイトは落ちません。

3-4. コンピュート層（Fargate）：ステートレス化とコスト最適化

WordPressが動作するコンピュート層は、EC2ではなくマネージドなコンテナサービスであるAWS Fargateを利用します。EC2のOSパッチ当てなどの運用負荷を軽減できます。

この構成の最大のポイントは、FargateのAutoScalingによる高可用性の実現です。

• On-Demand Base Task: 常時1台起動する、サイトの「生命線」となるベースタスク。安定性を確保。
• Spot Task: 負荷に応じて追加されるタスク。負荷低減により自動で停止。

コスト削減のポイント：
今回は学習目的のため、スケールアウトで追加される2台目以降のFargateはSpot Taskを採用しています。
Spot Taskはオンデマンドと比較して最大80-90%引きと安価に使用可能ですが、AWSのリソースが枯渇するとタスクが中断されるデメリットがあります。実際の案件ではオンデマンド：Spot は 50:50 の程度の比率が現実的です。

学習のポイント：
Fargateコンテナをステートレス化（ファイルはEFS、メディアはS3、DBはRDSへ外部化）しているため、Spot Task の突然の中断にも耐えられる設計になっています。

3-5. データベース層（RDS）：コスト優先のSingle AZ構成

• Amazon RDS for MySQL [Single AZ]: データベースはプライベートサブネットに配置。Fargateからの接続のみを許可。

コストと可用性のトレードオフ：
高可用性を目指すならRDSもマルチAZ（Multi-AZ）にすべきですが、今回は「学習目的」であり「削れるコストは削る」という方針のため、あえてSingle AZ構成にしています。これにより、RDSのコストを大幅に削減しています。
コスト度外視で高可用性・耐久性・性能を求める場合はAWS Auroraも使用可能です。

3-6. ストレージ層（EFS）：Fargateステートレス化の肝

• Amazon EFS (Elastic File System): Fargateコンテナは起動・終了を繰り返すため、コンテナ内にテーマ、プラグイン、設定ファイルを保存できません。これらを複数のFargateコンテナ間で共有・保存するための共有ストレージです。
• EFS Mount Target: 各AZのプライベートサブネットにマウントターゲットを配置し、Fargateからマウントします。

疎結合設計のポイント：
Lightsailでは1つのVPS内にあったすべてのファイルを、Fargate、RDS、EFS、S3へと外部化した疎結合設計にすることで、スケーラビリティと可用性を実現しています。

4. 既存Lightsail環境からの移行手順

Lightsailの環境（WordPress Certified by Bitnami）からの移行は、以下のようなステップになります。

1. 各コンポーネントの作成
2. 中心となるFargateとRDS,EFS,ALBを接続
3. LightsailのMySQLからデータをエクスポート（mysqldump）
4. RDSへデータをインポート（Fargate経由）
5. テーマファイルをFargate WordPressの管理画面からアップロード（マウント済みのEFSに自動アップロード）
6. プラグインをFargate WordPressの管理画面からインストール&有効化
7. LightsailのWordPressからwp-content/uploadsディレクトリをS3へコピー
8. Fargate WordPressメディアアップロードから画像がS3にアップされるように接続
9. CloudFrontとALB,S3を接続し、動的ページをALB、静的ファイルをS3から取得するようビヘイビア設定
10. 動作検証（WordPress動作やスケールアウトなど）
11. WordPressサイトURLやDB内URLを本番ドメインに切り替え
12. Route 53でDNSを切り替え
13. DNS浸透待ちで数日経過後にLightsail停止

このプロセスを通じて、Lightsailという「オールインワン」のシンプルさから、AWSの基本サービスの「疎結合設計」への変化を深く理解できます。

5. この構成を作るにあたって学んだこと

以下のAWS技術と設計思想を理解し、実際に作成できることの証明ができます。

• 疎結合設計（Decoupled Architecture）: Web、DB、Storage、Global Servicesの分離。
• 高可用性（High Availability）: CloudFront、ALB、マルチAZネットワーク設計の理解。
• コスト最適化（Cost-Optimized）: Fargate Spot、Single AZ RDSの使い分け。
• AWSの基本サービスの理解: Route 53, CloudFront, ACM, ALB, VPC (Subnet/SG), Fargate, RDS, EFS, S3
• コンテナ技術: Fargateの利用とコンテナのステートレス化。
• トレードオフの理解: 学習目的として可用性とコストのバランスを意識した設計（例：RDS Single AZ）。

5-1. 苦労したポイント

• CloudFrontがWordPressログインユーザーのアクセスをキャッシュしてしまう：
  CloudFrontのキャッシュポリシーを変更し、WordPressログインを判別するCookieを持ったアクセスはキャッシュさせない
• Fargateコンテナの操作：
  EFSマウントしたファイル以外は保持されず、デフォルトだと機能が最小限でzip解凍すらできなかった
• RDSが直接操作不可：
  RDSがPrivate Subnet内に存在するため直接接続ができずFargate経由で接続する必要があった
• エラー原因の特定：
  複数のコンポーネントに跨るため、どこにエラーがあったか特定が難しい
• 料金が高い：
  可能な限りコストを削減するための構成かつ安価なプランを使用したが、それでも月8,000円ほどかかる見込み
  RDS無料枠はAWSアカウントを作成して1年間のみなのが痛い

6. まとめと今後の展望

この構成は、学習用としてはかなり実戦的なWordPress環境が作成できたのではと思います。Lightsailからのステップアップとして、Fargateや疎結合設計を学ぶのに最適でした。

ただし、小規模なブログを運用するには過剰なスペックかつ高価です。おとなしく国内レンタルサーバー + Cloudflare を使用した安価な環境が現実的でしょう。
僕はしばらく学習に使用する際にのみ起動し、Lightsailでの運用を継続しようと思います。

今後の展望としては、以下を想定しています。

• CloudFrontのより詳細なキャッシュ設定
• IaC を使用したstg環境の作成
• GitHub からの CI/CD
• Lambda@Edgeを使用したS3画像ファイルのWebP,AVIF生成自動化

ご相談・ご依頼お待ちしております。

お問い合わせはこちら

この記事を読むと：

• Googleの検索結果で投稿がリッチリザルトで表示できる
• クリック率が上がる
• Googleに正確な情報が伝えられSEO評価向上につながる

リッチリザルトとは？

リッチリザルトとは、検索結果において、通常の「青いリンクと少しの説明文」だけでなく、画像、星の評価、よくある質問などが視覚的にリッチ（豪華）に表示される仕組みのことです。

百聞は一見に如かずということで、リッチリザルトのサンプル画像をご覧ください。
ニュース がカルーセルで表示されているかと思います。

このように、検索結果の画面で他よりも明らかに目立って表示されるのが最大の特徴です。
代表的なリッチリザルトの種類は以下のようなものがあります。（実際はもっとたくさんの種類があります。）

• レシピ（Recipe）
• レビュー（Review）
• よくある質問（FAQ）
• 記事（Article,BlogPosting）
• カルーセル（ItemList）

通常より目立つ表示なので、できるだけこのリッチリザルトで表示されるようサイト側で設定を行いたいです。
そのために必要なのが構造化データです。

構造化データとは？一言でいうと「Google専用の自己紹介カード」

私たちのサイトを巡回するGoogleのクローラーは、単なるテキストの羅列としてしか認識していません。
たとえばページに著者名を入れていた場合に、それが投稿の著者（ライター）なのか記事の中身の登場人物か、Googleのクローラーには完全には判別できないのです。

そこで役立つのが構造化データです。

構造化データがあればGoogleのクローラーに対して
「このテキストは記事のタイトル（Headline）ですよ」
「この画像はアイキャッチ画像（Image）ですよ」
「この記事を書いたのは山田太郎（Author）ですよ」
と、意味を明確にタグ付けして伝えるための「自己紹介カード」のような役割を果たします。

これによって、Googleクローラーがサイトの情報を正確に取得しリッチリザルトとして表示してくれるようになります。

構造化データはどのように設定する？

現在、Googleが最も推奨している構造化データの書き方が「JSON-LD（ジェイソン・エルディー）」という形式です。これは、HTMLのタグを直接いじるのではなく、headタグの中にスクリプトとして記述するため、サイトの見た目に影響を与えずに安全に実装できるというメリットがあります。

サポートしている構造化データの種類や形式が詳しく知りたい場合は公式ドキュメント：Google 検索がサポートする構造化データ マークアップ をご覧ください。

WordPressで構造化データを設定する方法

WordPressを使用する場合、SEOプラグインに出力させる方法と、head タグ内に JSON-LD を出力するコードを functions.php に追記する方法があります。
今回は後者の方法で解説します。

functions.php に以下を追記すれば投稿に記事（Article）の構造化データが追加されます。
Articleはニュースやブログ記事などに使える汎用的な指定です。

function insert_custom_json_ld() {
    // 記事ページ（is_single）のみ出力
    if ( is_single() ) {
        global $post;
        
        // 公開日時と更新日時の取得
        $pub_time_c  = get_the_time( 'c' ); // 出力用（ISO 8601形式）
        $mod_time_c  = get_the_modified_time( 'c' );
        
        // 比較用にUnixタイムスタンプも取得
        $pub_time_ts = get_the_time( 'U' );
        $mod_time_ts = get_the_modified_time( 'U' );

        // アイキャッチ画像（ない場合のデフォルト画像）
        $image_url = get_the_post_thumbnail_url( $post->ID, 'full' ) ?: home_url( '/wp-content/uploads/default-image.jpg' );

        $schema = array(
            '@context'         => 'https://schema.org',
            '@type'            => 'Article',
            'mainEntityOfPage' => array(
                '@type' => 'WebPage',
                '@id'   => get_permalink()
            ),
            // 投稿タイトル
            'headline'         => get_the_title(),
            // アイキャッチ画像
            'image'            => array( $image_url ),
            'datePublished'    => $pub_time_c,
            // 'dateModified' は下の条件分岐で追加します
            'author'           => array(
                '@type' => 'Person',
                // WPプロフィール設定の「ニックネーム」を明示的に指定
                'name'  => get_the_author_meta( 'nickname', $post->post_author ),
                // WPプロフィール設定の「サイト」を明示的に指定
                'url'   => get_the_author_meta( 'user_url', $post->post_author )
            ),
            'publisher'        => array(
                '@type' => 'Organization',
                // WP一般設定の「サイトのタイトル」を明示的に指定
                'name'  => get_bloginfo( 'name' ),
                'logo'  => array(
                    '@type' => 'ImageObject',
                    // サイトのロゴ画像を指定
                    'url'   => home_url( '/wp-content/uploads/logo.png' )
                )
            )
        );

        // 更新日時が公開日時以上のときのみ dateModified を配列に追加
        if ( $mod_time_ts >= $pub_time_ts ) {
            $schema['dateModified'] = $mod_time_c;
        }

        // JSON-LDの出力
        echo '<script type="application/ld+json">' . "\n";
        echo wp_json_encode( $schema, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES | JSON_PRETTY_PRINT );
        echo "\n" . '</script>' . "\n";
    }
}
// head内で出力
add_action( 'wp_head', 'insert_custom_json_ld' );

各項目の指定内容はコメントの通りですので、変更したい場所は該当項目を修正してください。
注意点のみ以下に記載します。

注意① 著者 author をユーザー名にしない

author（著者）の情報は名前とURLを設定します。

上記コードでは名前をWordPressのプロフィール画面「ニックネーム」の内容を取得するようにしています。ここは必ずユーザー名以外を表示するようにしてください。
ユーザー名はWordPressのログインに使用するため、公開すると不正アクセスの危険があります。

また、URLは必須ではないものの強く推奨される項目です。
現在のGoogleは、記事の評価において「E-E-A-T（経験、専門性、権威性、信頼性）」を非常に重視しています。
url を指定して著者プロフィールと紐づけることは、Googleに対して次のようなアピールになります。

• このURLの先には、著者のこれまでの執筆実績や、SNSへのリンク、専門的な経歴が載っています
  個人ブログであれば aboutページなどを指定すればよいです。
• この記事は、どこの誰とも分からない匿名の人ではなく、身元がはっきりしたこのURLの人物が責任を持って書いています

結果として、記事単体だけでなく「サイト全体の信頼性」を底上げすることに繋がります。
個人ブログであれば about ページでもよいので、必ずサイトを指定しましょう。

注意② 更新日時 dateModified は公開日時 datePublished より新しい日時にする

WordPressの更新日時は、投稿画面を保存した時間となる仕様です。
そのため、予約投稿を行った際は 公開日時 > 更新日時 となってしまい、これをそのまま使用すると公開日時より前に更新日時がある というチグハグな状態となっています。

これを防ぐために以下のように公開日時と更新日時を比較し、更新日時の方が新しい場合のみ dateModified を指定するようにしています。

        // 更新日時が公開日時以上のときのみ dateModified を配列に追加
        if ( $mod_time_ts >= $pub_time_ts ) {
            $schema['dateModified'] = $mod_time_c;
        }

ポイントとしては、Unixタイムスタンプで比較することです。
ISO 8601形式の比較は文字列同士の比較となってしまうため、予期せぬバグが発生することがあります。
そのためUnixタイムスタンプ（整数）同士の比較をするほうがプログラム的には安全で確実です。

記事以外に構造化データを追加する方法

追記したfunctionの頭にあるif ( is_single() )を分岐させてテンプレートごとに適した構造化データを指定しましょう。
また、投稿の内容によって、レシピ・レビュー・FAQ など、別の構造化データを指定したい場合は、投稿のカテゴリやタグを利用して分岐させるのがおすすめです。

Google 検索がサポートする構造化データ マークアップ の中から選びましょう。

ただし、構造化データのタイプによって必須な項目も異なるため、継続的に運用できるかを考慮して判断しましょう。
（たとえば、商品 Product の価格 offers は常に変動するものなので指定が難しい など）

構造化データの検証方法

構造化データが適切に設定されているかは以下のツールで検証が可能ですが、スキーマ マークアップ検証ツールはGoogle固有の警告は表示してくれないようです。
Google公式が提供しているのがリッチリザルト テストなので、こちらのほうがおすすめです。

• リッチリザルト テスト
• スキーマ マークアップ検証ツール

ただし、構造化データが正しい形式で指定されていたとしても、リッチリザルトで表示されるとは限りません。
とは言えGoogleには正しく伝わっているはずなので、気長に待ちましょう。

まとめ

今回はプラグインを使用しないWordPressでの構造化データの指定方法を解説しました。

設定してもGoogleは中々リッチリザルトで表示してくれませんが、表示されたときは「やってよかったな」という満足感があります。

デメリットも無いので、とりあえずで設定しておくべきの必須級の機能ですね。

要件

実績作り兼AWS学習を目的としたブログメディア構築

後ほど EC2+RDS+S3+CloudFront 環境へ移行することを前提として AWS Lightsail にてサイトを作成し、ドメインやルーティングは Route53 を使用する。

計測・広告のタグなど、ハードコーディングは避け管理画面で設定可能とする。

実施内容

• サイトデザイン作成
  Geminiにてベースデザインを作成し微調整
• インフラ構築
  AWS Lightsail + WordPress + Route53、CloudWatchによる監視
• WordPress設計・構築
  既存テーマは使用せず新規テーマ作成
• 広告
  GoogleAdsenceによるディスプレイ広告およびAmazon、楽天などのアフィリエイト広告を導入
• SEO施策
  プラグインを使用しないsitemapやcanonical指定等、標準的なSEO設定のみ
• セキュリティ
  セキュリティプラグインの導入
• 運用
  コードはGit管理、広告はGoogleTagManager or 管理画面

使用技術

• HTML/CSS
• JavaScript
• PHP
• WordPress
• AWS Lightsail
• Route53
• CloudWatch

まとめ

まずは最低限の実装から始めています。
SEOプラグインを導入せず一つずつ自前で設定しており、想定より工数がかかってしまったため、次回からはおとなしく既存のプラグインを使用したほうがよさそうです。

また今回は学習のためAWS Lightsailを使用しましたが、小規模なメディアであればConoHa wingなどの国内レンタルサーバーを使用するほうが安価で簡単です。

ディレクションばかりやってましたが、実はコードを触るほうが好きです。

こんな相談に対応できます

当サイトと同程度の規模でしたら10営業日ほどで作成可能です。

ご相談・ご依頼お待ちしております。

お問い合わせはこちら

この記事を読むと：

• 自由に触れるWordPress環境を構築できる
• Dockerによる環境構築方法を理解できる

なぜDockerなのか？

Dockerを使用してローカル開発環境を作るメリットは「動作環境をコード化して、どのPCでも同じ状態を再現できる」という点にあります。

実務上は以下のようなメリットになります。

• 本番環境に合わせた構成が簡単に作成できる
• 環境差分（PC環境ごとに動作が違う）を無くす
• 複数の構成が異なる環境を同時に起動できる

逆にデメリットはローカルで動かすためPCに負荷がかかる点です。
PCのスペックが低い、Docker側で重い作業を行う等でPCの動作が遅くなります。

前提条件・環境

今回の検証環境は以下です。

• Docker Desktop
• テキストエディタ（VSCodeなど）
• Webブラウザ（Chromeなど）
• コマンドプロンプト（macならターミナル）

Docker Desktopの導入方法は以下にて解説しておりますので、未導入の場合は是非参考にしてください。

ローカル開発環境構築のためのDocker Desktop導入手順

opticode.lab.com

ステップ1 Docker Desktopの起動

なにはともあれDocker Desktopを起動しましょう。起動すれば以下のような画面が表示されるはずです。

また、Windowsなら以下のようにタスクバーにも表示されているはずです。

ステップ2 Docker設定ファイルの作成

Dockerで環境を構築するためには docker-compose.yml という設定ファイルが必要になります。
このファイルにはコンテナ内に構築する環境の構成を記述し、それをもとにDockerが自動で環境を構築する仕組みになっています。

docker-compose.yml に記述する構成は本番環境と同様のものを指定しましょう。
本記事では複雑になりすぎないよう “ローカルにWordPress環境を作るための最小構成” で説明します。

作業用ディレクトの作成

まずは docker-compose.yml を置くフォルダを作成します。
場所やフォルダ名は何でもいいですが、WordPressのDBやテーマファイルもここに入るため作業しやすい場所がいいと思います。

今回は Cドライブ直下に test-site フォルダを作成することとしました。

docker-compose.yml ファイルの作成

テキストエディタを開き、以下の内容を記述したうえで docker-compose.yml というファイル名で保存し、作成した作業用ディレクトリに置きます。

services:
  db:
    image: mysql:8.4
    restart: unless-stopped
    environment:
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wpuser
      MYSQL_PASSWORD: wppass
      MYSQL_ROOT_PASSWORD: rootpass
    volumes:
      - db_data:/var/lib/mysql

  wordpress:
    image: wordpress:6.9.1-php8.2-apache
    restart: unless-stopped
    depends_on:
      - db
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_NAME: wordpress
      WORDPRESS_DB_USER: wpuser
      WORDPRESS_DB_PASSWORD: wppass
    volumes:
      - ./wp-content:/var/www/html/wp-content

volumes:
  db_data:

ひとつずつ解説します。

全体像

• services: の下に「起動するコンテナ（サービス）」を並べる
  今回は db: と wordpress: を起動しています。
• volumes: でデータを永続化するための領域を定義
  これがなければコンテナを停止した時にデータが消えちゃうので必須の記述です。

DB

db:
    image: mysql:8.4
    restart: unless-stopped
    environment:
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wpuser
      MYSQL_PASSWORD: wppass
      MYSQL_ROOT_PASSWORD: rootpass
    volumes:
      - db_data:/var/lib/mysql

• db という名前のサービスの設定内容を記述
• image: mysql:8.4 MySQL 8.4 の公式イメージを指定する
• restart: unless-stopped コンテナが落ちた時に自動で再起動する（手動で停止させた場合を除く）
• environment:データベース名、ユーザー名とそのパスワード、rootユーザーのパスワードをそれぞれ指定する
• volumes:MySQLのデータ保存場所を指定する

WordPress

  wordpress:
    image: wordpress:6.9.1-php8.2-apache
    restart: unless-stopped
    depends_on:
      - db
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_NAME: wordpress
      WORDPRESS_DB_USER: wpuser
      WORDPRESS_DB_PASSWORD: wppass
    volumes:
      - ./wp-content:/var/www/html/wp-content

• wordpressという名前のサービスの設定内容を記述
• image: wordpress:6.9.1-php8.2-apache WordPress 6.9.1 をPHP 8.2、WebサーバーはApacheを指定
• restart: unless-stopped DBと同様に落ちたら自動復帰
• depends_on: - db 先に記述したdbが起動した後にWordPressを起動するという指定
• ports:- "8080:80" ブラウザを使用し http://localhost:8080 でページを閲覧するためのポート設定
• environment:先に記述したDBをWordPressに使用させるための接続情報を指定
• volumes: コンテナ内の wp-content を、PC上の ./wp-content フォルダにマウントさせる設定

長くなりましたが、ひとまずこれで最低限WordPressを動かすための準備ができました。

ステップ3 コンテナの起動

コマンドプロンプト（またはターミナル）を使用してコンテナを起動します。
まずはコマンドプロンプトを起動し、docker-compose.yml を格納した作業用フォルダに移動します。

そこで以下のコマンドを実行してください。

docker compose up -d

これは docker-compose.yml の内容をもとにコンテナを作成するものです。
実行するとコンテナの初回起動が行われます。以下のような表示が出るはずです。

また、Docker Desktopを見ると以下のように起動中のコンテナが確認できるようになっています。

ステップ4 WordPressにアクセス

起動したWordPressにアクセスしましょう。
http://localhost:8080 でアクセスできるよう設定していたので、Webブラウザを使用してこのURLにアクセスしてみてください。
まっさらなWordPressが入っているので、以下のような言語設定の画面から始まると思います。日本語を選択して次へ進んでください。

サイトの基本情報を入力して、WordPressをインストールしてください。
ここで入力した内容は後ほどWordPressの管理画面から設定変更が可能なので、まだ決まって無ければとりあえずのものを入れておきましょう。

インストールが完了したらログイン画面に遷移するため、先ほど設定したユーザー名・パスワードでログインしてください。
無事ログインできればWordPressのダッシュボードが表示されるはずです。

ステップ5 コンテナの停止と保存確認

コンテナを停止した際に情報が消えてしまわないか確認します。
コマンドプロンプトにて、作業用ディレクトリへ移動し以下のコマンドを実行します。

docker compose down

これで再度 http://localhost:8080 にアクセスしてみてください。停止できていればアクセスできなくなっているはずです。
そのまま以下のコマンドを実行し、コンテナを起動してみましょう。

docker compose up -d

初回起動ほど待たずに起動されたかと思います。http://localhost:8080 にアクセスしましょう。
コンテナ停止で情報が消えてなければ、初回起動時のような言語設定・基本情報設定は表示されません。
http://localhost:8080/wp-login.php にアクセスしてログインしてみましょう。ユーザー情報も残っているためログインできます。

ステップ6 テーマ読み込み確認

ステップ2 にて wp-content フォルダのマウント設定を行っているため、作業フォルダ内の wp-content 内にあるファイルを変更すればローカル環境にもその内容が反映されます。

WordPress 6.9.1 ではデフォルトで twentytwentyfive のテーマが読み込まれているので、このテーマを編集して反映されるか確認してみましょう。

触るファイルは何でもいいですが、今回はわかりやすいように wp-content/themes/twentytwentyfive/patterns の header.php を使用してみます。

テキストエディタで header.php を開き、末尾に好きな文字列を入れて保存してみてください。
以下のようにサイトのヘッダーに記述した文字列が出ていれば成功です。

これでDockerを使用したWordPressローカル環境を作成することができました。

既に本番サイトが存在する場合はローカル環境にテーマファイルをアップロードしたり、投稿のインポート・エクスポート機能を用いて本番同様の環境にしてしまいましょう。

まとめ

今回はDockerを使用したWordPress開発環境の作り方を解説していきました。

コンテナは複数作ってもOKなのでサイトごとにどんどんコンテナを作っていきましょう。
また、チームで開発を行っている場合は同じ docker-compose.yml を共有することで環境差分を減らせます。

本来は本番環境の構成に合わせて設定を行うため、細かな設定は以下のリファレンスで確認してみましょう。

• Compose file reference（公式）
• Compose ファイル リファレンス（非公式）