作成した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. 画像のWebP化：
   ツールを使用して画像を手元でWebPに変換したうえでWordPressにアップ
2. キャッシュプラグインの導入：
   WP Fastest Cache を導入
3. CSS統合：
   サイト内外の複数読み込んでいたCSSを1つのファイルに統合
4. Googleフォントをサーバーで配信：
   フォントをダウンロードして /assets 配下に格納

画像のWebP化は以下のツールを使用してjpgやpngをWebPに変換しています。
複数の画像を圧縮したzipファイルをそのまま放り込んでも大丈夫なツールです。

ブログの画像処理を劇的に時短！ドラッグ＆ドロップで一括WebP変換＆リサイズを自動化する方法（Windows向け）

opticode.lab.com

速度改善の成果

なんとここまでやって58点。

サイト側で重い処理を実行しているならともかく、WordPress投稿ページ + キャッシュ でこのスコアはどういうことなのか。
1時間ほどコードとにらめっこしてました。

高速化一番のネックはGoogleのタグだった

いろいろ試した後にGoogleTagManagerのみ触れていなかったので、これを一時的に削除して速度を計測してみました。

ビンゴでした。GTMタグを削除するだけで96点まで跳ね上がりました。

GoogleTagManagerにはGoogleAnalyticsとGoogleAdSenceの2タグのみ登録していました。
まさかGoogle提供のPageSpeed Insightsで最も評価を下げていたのはGoogleのタグであり壮大なマッチポンプでした。
特にAdSenceくん、重すぎ。

Pagespeed Insightsに縛られすぎるべきではない

特にPagespeed Insights のスマートフォン パフォーマンスは非常に低いスコアが出る傾向にあります。
これは 低スペックスマホ + 弱回線 という日本では一般的ではない環境を想定した計測であるためです。

以下のGoogle公式ドキュメントにあるように、検索結果に与える影響はPagespeed Insightsよりも実際に優れたページエクスペリエンスを提供できているか。というのがカギのようです。

Google のコア ランキング システムは、優れたページ エクスペリエンスを提供するコンテンツを高く評価するように設計されています。サイト所有者が Google のシステムで高い評価を得るには、ページ エクスペリエンスの限られた要素のみにとらわれないようにすることが必要です。多くの要素について検討し、全般的に優れたページ エクスペリエンスを提供できているかどうかを確認してください。

引用：ページ エクスペリエンスが Google 検索の検索結果に与える影響について

具体的にはPagespeed Insights上部の「実際のユーザーの環境で評価する」やGoogle Search Consoleの「ウェブに関する主な指標」を重視するのがよさそうです。

まとめ

Pagespeed Insightsのスコアが低くなる要素が見当たらない場合はGoogleタグを一時的に削除して計測しなおしてみてください。

また、Pagespeed Insightsのスコアが低いこと自体はそこまで神経質になる必要はなく、あくまでもGoogle Search Consoleの「ウェブに関する主な指標」などで評価が低かった場合の改善ポイントを見つけるために使用するものと考えたほうがよさそうです。

Googleのタグを使用してGoogleに指摘されるという手の上で踊らされている状態ですが、僕たちがウェブで生きていくには頭を垂れるしかないという虚しさがありました。

今回は、そんな手間を完全にゼロにする「Windowsのドラッグ＆ドロップだけで、複数画像やZIPを自動でWebP化＆リサイズする自作ツール」の作り方をご紹介します。

少し面倒な手順もありますが、作ったあとはフォルダごと他の作業者に共有すればチーム全体で効率化できますので是非お試しください。

まずは知っておきたい「WebP（ウェッピー）」の基本

WebPは、Googleが開発した次世代の画像フォーマットです。従来のJPEGやPNGと比べて、画質を保ったままファイルサイズを25〜34%ほど軽くできるのが最大の特徴です。

現在ではChrome、Safari、Edge、Firefoxなど、主要なブラウザはすべてWebPに完全対応しています。さらに、WordPressもバージョン5.8以降から標準でWebPアップロードをサポートしているため、プラグインなしでそのままメディアライブラリに追加可能です。

サイトの表示速度アップ（SEO対策）のためにも、これからのブログ運営にWebPは必須と言えます。

この自動化ツールでできること

今回作成するツールを使うと、以下のような処理が一瞬で完了します。

• ドラッグ＆ドロップで一括処理:
  複数画像でも、Googleフォトからダウンロードした「ZIPファイル」でも、そのまま放り込むだけでOK。
• 自動リサイズ:
  横幅が1200pxを超える画像は、自動で比率を維持したまま1200pxに縮小（小さい画像はそのまま）。
• SEO対策バッチリの自動命名:
  指定したキーワード（例: blog-article）を使って、blog-article-01.webp のように綺麗な連番ファイル名に自動変更。
• 元ファイルの自動お掃除: 処理が終わったら、元の画像ファイルやZIPファイルを自動削除することも可能。

自動リサイズが横幅1200pxとなっているのは、Google自身が Google Discover に表示する画像として「幅 1,200 ピクセル以上、高解像度（300K 以上）、アスペクト比: 16:9」を推奨しているためです。

詳しくは Google Discover 公式ドキュメント をご覧ください。

それでは、具体的な作成手順（所要時間：約5分）を解説します。

ステップ1：Google公式ツール「cwebp」をダウンロード

WebP変換の心臓部となる、Google公式のツールを用意します。

1. Google DevelopersのWebP公式サイト にアクセスします。
2. Windows用のzipファイル（libwebp-x.x.x-windows-x64.zip）をダウンロードして解凍します。
3. 解凍したフォルダの bin フォルダ内にある cwebp.exe というファイルだけを取り出します。
4. PC上の使いやすい場所（デスクトップなど）に「画像変換」などの専用フォルダを作り、そこに cwebp.exe を入れます。

ステップ2：実行用バッチファイルを作成

次に、ドラッグ＆ドロップを受け付ける窓口となるファイルを作ります。

1. メモ帳を開き、以下のコードをコピーして貼り付けます。

@echo off
setlocal
cd /d "%~dp0"

echo ===================================================
echo   画像をWebP（ウェッピー）に変換します
echo ===================================================

powershell -NoProfile -ExecutionPolicy Bypass -File "%~dp02_convert_logic.ps1" %*

pause

2. ファイル名を 1_ここへドロップ.bat として、「Shift-JIS」形式で先ほどの cwebp.exe と同じフォルダに保存します。

ステップ3：処理ロジックのファイルを作成

最後に、裏側で画像を処理するメインのプログラムを作ります。

1. 再度メモ帳を開き、以下のコードをコピーして貼り付けます。

# 2_convert_logic.ps1

$DroppedItems = $args
$cwebp = Join-Path $PSScriptRoot "cwebp.exe"

if (-not (Test-Path $cwebp)) {
    Write-Host "[エラー] cwebp.exeが見つかりません。同じフォルダに入れてください。" -ForegroundColor Red
    return
}

Write-Host "【設定を入力してください】" -ForegroundColor Cyan
$prefix = Read-Host "1. ファイル名の頭につける文字（例: travel-tips）※空欄なら日付になります"
$deleteOption = Read-Host "2. 変換が終わった後、元の古い画像を削除しますか？ (y/n)"
$dateStr = Get-Date -Format "yyyyMMdd_HHmmss"

$outDir = Join-Path $PSScriptRoot "Converted_WebP"
if (-not (Test-Path $outDir)) { New-Item -ItemType Directory -Path $outDir | Out-Null }

$imagesToProcess = @()
$tempDirs = @()
$failedSources = @()

foreach ($item in $DroppedItems) {
    if (-not (Test-Path $item)) { continue }
    $ext = [System.IO.Path]::GetExtension($item).ToLower()

    if ($ext -eq '.zip') {
        Write-Host "ZIPファイルを解凍しています...: $([System.IO.Path]::GetFileName($item))"
        $tempDir = Join-Path $env:TEMP ([guid]::NewGuid().ToString())
        Expand-Archive -Path $item -DestinationPath $tempDir -Force
        $tempDirs += $tempDir
        $extractedImages = Get-ChildItem -Path $tempDir -Recurse | Where-Object { $_.Extension -match '\.(jpg|jpeg|png|webp)$' }
        foreach ($img in $extractedImages) {
            $imagesToProcess += [PSCustomObject]@{ Path = $img.FullName; Source = $item }
        }
    }
    elseif ($ext -match '\.(jpg|jpeg|png|webp)$') {
        $imagesToProcess += [PSCustomObject]@{ Path = $item; Source = $item }
    }
}

if ($imagesToProcess.Count -eq 0) {
    Write-Host "変換できる画像が見つかりませんでした。画像をドロップしてください。" -ForegroundColor Yellow
    return
}

Add-Type -AssemblyName System.Drawing
$count = 1
Write-Host "`n--- 変換を開始します (画質: 85) ---" -ForegroundColor Cyan

foreach ($item in $imagesToProcess) {
    $file = $item.Path
    $source = $item.Source
    try {
        $img = [System.Drawing.Image]::FromFile($file)
        $width = $img.Width
        $img.Dispose()

        $newName = if ([string]::IsNullOrWhiteSpace($prefix)) { "${dateStr}_" + $count.ToString("D2") + ".webp" } else { "${prefix}-" + $count.ToString("D2") + ".webp" }
        $outPath = Join-Path $outDir $newName
        
        Write-Host "変換中: $([System.IO.Path]::GetFileName($file)) -> $newName"

        # WebP変換実行
        if ($width -gt 1200) {
            & $cwebp -q 80 -m 6 -resize 1200 0 $file -o $outPath *>$null
        } else {
            & $cwebp -q 80 -m 6 $file -o $outPath *>$null
        }

        if (-not (Test-Path $outPath) -or (Get-Item $outPath).Length -eq 0) { throw "失敗" }
        $count++
    } catch {
        Write-Host "【失敗】: $($file) は変換できませんでした。" -ForegroundColor Red
        if ($failedSources -notcontains $source) { $failedSources += $source }
    }
}

# 後片付け
foreach ($td in $tempDirs) { Remove-Item -Path $td -Recurse -Force -ErrorAction SilentlyContinue }

# 元ファイルのクリーンアップ
if ($deleteOption -match '^[yY]') {
    Write-Host "`n--- 元ファイルの整理 ---" -ForegroundColor Cyan
    foreach ($source in $DroppedItems) {
        if ($failedSources -contains $source) {
            Write-Host "残しました（エラーがあったため）: $([System.IO.Path]::GetFileName($source))" -ForegroundColor Yellow
        } elseif (Test-Path $source) {
            Remove-Item -Path $source -Force -Recurse -ErrorAction SilentlyContinue
            Write-Host "削除しました: $([System.IO.Path]::GetFileName($source))"
        }
    }
}

Write-Host "`nすべて完了しました！" -ForegroundColor Green
Write-Host "『Converted_WebP』フォルダを確認してください。"

2. ファイル名を 2_convert_logic.ps1 とし、同じく cwebp.exe やバッチファイルがあるのと同じフォルダに「Shift-JIS」形式で保存します。

3. これで完成です！フォルダ内は以下の3つのファイルが並んでいる状態になります。

• cwebp.exe
• 1_ここへドロップ.bat
• 2_convert_logic.ps1

ツールの使い方

使い方は驚くほど簡単です。

1. 変換したい画像（JPG/PNG）やZIPファイルを、1_ここへドロップ.bat のアイコンにドラッグ＆ドロップします。
2. 黒い画面が開くので、ファイル名を入力（例: travel-tips）してEnterを押します。（何も入力せずにEnterを押すと日付になります）
3. 「元の画像やZIPを削除しますか？ (y/n)」と聞かれるので、削除してよければ y 、残すなら n（またはそのままEnter）を押します。
4. 全自動で処理が進み、同じフォルダ内に Converted_WebP というフォルダが作られ、そこに最適化されたWebP画像が連番で保存されます。

あとはこれをWordPressにアップロードするだけ！これまでの「画像ソフトを開いて、リサイズして、別名で保存して…」という作業が数秒で終わるようになります。ぜひ試してみてください。

エクスプローラーの「表示」→「特大アイコン」でアイコンを最大化するとドラッグ&ドロップしやすくていいと思います。

よく使うことになると思うので、このフォルダをエクスプローラー左にショートカットで登録することをオススメします。

Windows11 エクスプローラーのショートカットに表示されるフォルダを手動で管理する方法

opticode.lab.com

うまく動かないときは

以下の点について見直してみてください。

• Googleからダウンロードしたツールが cwebp.exe で間違いないか
• 保存したツールのファイル名があっているか
  1_ここへドロップ.bat　と　2_convert_logic.ps1　です。
• 保存したツールが「Shift-JIS」形式 で保存されているか
• 3つのファイルが同じフォルダ内に存在しているか

ツールを使うにあたっての注意点

以下の点は少し注意が必要です。

• WebPに変換するにあたって少しだけ画質を落としております。
• 一部の古いIEなど未対応ブラウザ（シェア合計1%前後）ではWebPが表示できません。
  サイトで使用する画像を完全にWebPのみに切り替えるかは慎重にご判断ください。
• 同じファイル名で保存すると、Converted_WebP フォルダ内に存在した同名ファイルに上書き保存されます。先にサーバーにアップしておくか、別のファイル名を指定するなどで回避してください。

まとめ

今回は作成したWebP変換ツールをご紹介しました。

当サイトは開発ブログやガジェット紹介などがメインなので、使用しているブラウザも新しいだろうということで完全WebPに切り替えています。

本来はGoogleAnalyticsなどで未対応ブラウザからのアクセス数を確認すべきですが、まだアクセスがほぼ無いのでサイトのジャンルで決めてしまいました。

今回はこのクイックアクセスを固定化し、追加・削除する方法をまとめます。

クイックアクセスのフォルダが消える&不要なフォルダが入る

Windows11は、デフォルトでは使用頻度の高いフォルダを自動でクイックアクセスへ登録する仕様となっています。
これが余計なおせっかいで、以下のようにどのフォルダかわからないものが登録されたり、必要なフォルダが除外されます。

2つの opticode-lab はそれぞれ別のフォルダなので「どっちのフォルダだよ！」となります。
よくある images や wordpress のようなフォルダが登録されると「どのサイトのフォルダだよ！」となります。

これを防ぐために、自動で登録・削除されないよう設定が必要です。

クイックアクセスが自動で更新されないようにする設定

エクスプローラーのメニューバー右の「・・・」を開き、「オプション」を開きます。

フォルダーオプション内の以下項目のチェックを外し、「適用」「OK」を押下して設定を閉じます。

• 最近使用したファイルを表示する(E)
• 使用頻度の高いフォルダーを表示する(Q)

これで自動更新が無くなります。

クイックアクセスにフォルダを登録・削除する方法

更新を止めた後は必要なものだけ手動で登録・削除しましょう。

クイックアクセスへ登録する方法

エクスプローラー上部のアドレスバーから登録したいフォルダをドラッグ&ドロップで登録ができます。

クイックアクセスから削除する方法

クイックアクセス内の削除したいフォルダを右クリックし、「クイックアクセスからピン留めを外す」から削除が可能です。

まとめ

開発していると同じようなディレクトリ構造・フォルダ名を扱うことが多いため、どのフォルダか非常に判り辛くなります。

固定・手動管理にしましょう。

この記事を読むと：

• 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は中々リッチリザルトで表示してくれませんが、表示されたときは「やってよかったな」という満足感があります。

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

この記事を読むと：

• 効率的な資格の学習方法がわかる
• 移動中など、手軽にスマホで勉強ができる
• 無料で試験対策ができる

資格対策にお金を払う時代は終わった

これまでの資格と言えば、試験対策テキストやオンラインカリキュラムなどの効率よく学習する手段にはお金を払う必要がある、というのが常識でした。
それもそのはず、膨大な出題範囲を解りやすくまとめ、試験に出やすいポイントや最新情報を押さえ、練習問題を作成する。といったとてつもない労力がかかるものにコストがかかって当然なのです。

しかし、AIが登場してからこの常識は終わったと感じています。

AIは学習によって膨大なデータを取得し、試験範囲に沿って情報を出力する能力を持っているため、これまで人間が時間をかけてきたことをノーコストでやってしまいます。
練習問題が欲しければすぐに出力し、間違った問題は解説してくれます。
さらに、質問すればなんでも深堀して回答してくれる、さながら家庭教師のような役割を持っています。

これは革命です。あと商売上がったりです。
とは言え利用しない手は無いです。

Gem 学習コーチとは？なにができる？

この記事では Gem 学習コーチ というものを使用してみたいと思います。

まず Gem とは、Google Geminiをベースとした特定の役割やタスクに特化した「自分専用のGemini」をカスタマイズできる機能です。
以前は有料だったようですが、2026年3月現在では無料で使用できます。

その中の Gem学習コーチ（Learning Coach）は Google公式が提供しているプリセットの一つで、「理解を深めるための導き」に特化したAI家庭教師 らしいです。（Gemini本人談）

Gem学習コーチは以下のようなことができます。

資格取得までの学習プランを作成

学習を始める際に何から手を付ければいいのか、どういったペースで進めればいいか、と悩むことがあるかと思いますが、試験日を伝えればそこから逆算した学習プランを作成してくれます。

直感的に理解しやすい説明

説明を聞いても「？」となってしまう内容を、直感的にわかるような例えを混ぜつつかみ砕いて説明してくれます。
逆にユーザー側が「これって〇〇みたいなもの？」と質問すれば、合っているかどうか判断してくれます。
もちろん理解できるまで付き合ってくれます。

画像で視覚的に説明

画像生成能力があるため、「図で表してみて」「画像で見せて」と言えば、説明した内容に沿った画像を作成してくれます。
注意点としてはAIは日本語（特に漢字）の画像出力が苦手なためテキストは英語で出力されることが多いです。

問題の作成・解説

練習問題を作成し、間違えれば詳しく解説してくれます。
実際の試験で出やすいポイントや覚え方のコツ、苦手な分野も把握して重点的に問題を作ってくれます。

興味があれば自身でGemを作成することもできます。
Gemの作成方法は GeminiアプリでGemを使用する でご確認ください。

Geminiを使用するにあたっての注意点

Geminiに限らずAIを使用する場合に気を付けるべきこととして、「AIは間違える可能性がある」ということです。
おかしなことを言っていると思った場合は自分で調べることをオススメします。

とはいえAWS SAAの資格試験のような明確に正解が決まっているものはほぼ間違えることは無いと思います。安心して学習を進めましょう。

Gem 学習コーチを使ってみる

ここからは実際にGem学習コーチを使ってみます。
まずはGoogleGeminiにアクセスし、左上のメニューを開き「Gem」を押下します。

Gemマネージャーの中の「学習コーチ」を押下します。

資格名、試験日、学習ペースなどを伝え、学習プランを作成してもらいます。
いつでも受けられる試験なら、試験日も相談してみるのもオススメです。

以下はプロンプトの例です。

以下の条件で資格取得のための学習プランを作成して

資格名：〇〇〇〇
試験日：〇月〇日、〇カ月後 など
今のレベル：全くの未経験、基礎はわかる、実務経験あり など
学習ペース：1日〇時間、週〇時間、余裕を持った

問題なさそうなので、さっそく学習プランの最初から始めてもらいます。

ここからは解説と試験で出るポイントなどを解りやすく説明してくれます。
何も言わなければテキストしかくれないので、疑問があれば質問したり画像を使った説明をお願いしながら学習を進めていきましょう。

ちなみに画像をお願いするとこんなのが出てきます。
見切れてますが、この画像の下にはテキストで詳細な説明があります。

一区切りつくと「小テスト」や「クイズ」を出して理解できているか確認してきます。
だいたい3択から選ぶ感じです。間違えた場合は問題を詳しく解説してくれます。

これを繰り返して学習していきます。
学習プラン通りの良いペースで進んでいると「今日はここまでにしますか？」と言ってくれるので、そこが辞め時です。

次回学習するときに話しかければ続きから進めてくれます。

最後の追い込み！フラッシュカードで練習問題

Gem 学習コーチは1つずつ丁寧に説明してくれるのが強みですが、その思想が邪魔をして試験直前のとにかく問題を多くこなすのが不得意です。

そのため最後はGem学習コーチではなく通常のGeminiに問題を出してもらいましょう。

「試験名」「問題数」「フラッシュカードで作成して」と伝えると、以下のような形式で作成した問題を表示してくれます。

回答をタップすれば正解・不正解を表示してくれるので、通勤・通学や時間が無い時など、スマホで簡単に学習が進められます。これが非常に便利。

ただし、Geminiはフラッシュカードで何が不正解だったかを取得できないようで、解説が必要なときは「問〇の解説して」のように伝える必要があります。

ラストスパートとしてどんどん問題を解きましょう。

まとめ

今回はGeminiおよびGem学習コーチを使用した資格試験対策について解説しました。
ポイントをまとめると：

• Gemコーチによる学習プラン作成と実行
• Geminiフラッシュカードによるラストスパート

正直なところ、すごいと感じると同時に怖いとも感じました。
僕らが頑張って勉強していることは既にAIが知っていること。少なくとも資格に関してはそう思ってしまいました。

とは言えAIが正しいかどうかを判断する人間は必要。使う側で居続けるためにも日々精進ですね。

この記事を読むと：

• 自由に触れる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 ファイル リファレンス（非公式）

この記事を読むと：

• Dockerの基礎知識が身につく
• チーム内での環境依存を減らした開発ができる

Dockerとは？

簡単に説明するなら、アプリを動かすのに必要なもの一式（実行環境）を「コンテナ」という箱にまとめて、どのPCでも同じように動かせる仕組みです。

コンテナ内にどんなアプリを入れるかは設定ファイルにて指定ができ、本番環境と同じ構成を指定すれば同様の構成をコンテナ内に再現できます。
その設定ファイルを開発チーム内で共有すれば、全員同じ環境で開発作業が行えるようになります。

またコンテナの作成・削除も容易なので、とりあえず触れるまっさらなWordPressを作る、というのにも最適です。

前提条件・環境

Docker Desktopを使用するには以下の要件を満たす必要があります。

• Windows 11 64 ビット: Home Pro Enterprise Education バージョン 21H2またはそれ以降 or
  macOS 10.15 またはそれ以降
• 4 GB 以上のシステム RAM
• BIOS 設定において BIOS レベルのハードウェア仮想化サポートが有効であること

そもそもWindows11が64bitのみで4GB RAMは必須なのでWindows11が入っているPCならほぼ大丈夫です。macもおそらく古すぎなければ大丈夫だと思われます。
記事ではWindows11 Proを使用しますが、macでも設定はほぼ同様と思われます。

ハードウェア仮想化サポートの有効確認

一番手軽なのが タスクマネージャ → パフォーマンス の 仮想化 という項目を見る方法です。
ここが「有効」になっていれば有効化されています。

無効の場合は以下2つの設定を確認する必要があります。

BIOSでの有効化

BIOSで仮想化が無効となっている場合があります。
BIOSの設定方法はPCごとに異なるため、以下のようなワードを検索してご自身でご確認ください。

• PC型番 仮想化
• PCメーカー名 仮想化
• マザーボード型番 仮想化
• マザーボードメーカー 仮想化

注意：BIOS設定ではデフォルトで有効 + 非表示 となっている場合アリ。設定項目が見当たらなければ先に「Windowsでの有効化」を試してみましょう。

Windowsでの有効化

Win + R → optionalfeatures → Enter（「Windows の機能」）

次にチェックを入れてOKを押し、PCを再起動する

• 仮想マシン プラットフォーム（Virtual Machine Platform）
• Linux 用 Windows サブシステム（Windows Subsystem for Linux）

再起動したらタスクマネージャーから仮想化が有効になっているかを確認しましょう。

導入手順

Windows11 Proでの手順となりますので、その他の環境では少々内容が異なることはあります。
設定項目の違いはあるものの、Windows11 Homeでも導入できることは確認済みです。

ステップ1 インストーラーのダウンロード

まずはDocker Desctop を入手しましょう。
Docker公式の Docker Desktop をダウンロードするから自分の環境にあった installerをダウンロードしてください。
Windowsは2種類ありますが基本的にはAMD64でOKです。ARM PCを使用している場合はARM64を選択してください。

ステップ2 インストーラーの実行

ダウンロードが終わったらinstallerを実行してDocker Desktopをインストールしてください。

注意：インストール中はPC再起動が発生するので作業中のデータがある場合は保存しておくことをおすすめします。

このアプリがデバイスに変更を加えることを許可しますか？という確認が表示されます。
「はい」でOKです。

以下の画面が表示されます。

Use WSL 2 instead of Hyper-V → チェックを入れる
Hyper-Vの代わりにWSL2を使用するかの確認
Allow Windows Containers to be used with this installation → チェック無し
Windowsアプリ用のコンテナもインストールするかの確認
Add shorcut to desktop → お好きに
デスクトップにショートカットを作成するかの確認

上記の通りチェックしたら右下の「OK」を押すとインストールが開始されます。
完了すると以下が表示されるので、「Close and restart」を押します。（ここでPCの再起動が発生します）

再起動が完了するとDocker Desktopが起動し、以下のような画面が表示されます。

使用許諾に関する内容で、以下のようなことが書いてあります。

サブスクリプションサービス契約、Dockerデータ処理契約、データプライバシーポリシー、およびDocker AI補足規約に同意したことになります。
従業員数250名以上、または年間売上高1,000万ドル以上の企業でDocker Desktopを商用利用するには、有料サブスクリプションが必要です。

確認のうえ、問題なければ「Accept」でOKです。

注意：記事作成時の内容なので念のためご自身でも内容をご確認ください。

ステップ3 WSL2 インストール

ここからWSL2のインストール状況によって分岐するようです。
WSL2とはWindows上でLinuxを動かすためのものです。Dockerを使用するために必要なものです。

管理人の場合は既にWSL2が入っていたようで、以下の確認が表示されました。
このアプリがデバイスに変更を加えることを許可しますか？ Linux用Windowsサブシステム
この場合は「はい」を選択してください。

上記のような画面が表示されます。任意のキーを押せば更新できます。

そもそもインストールされていなければインストールが必要となります。
その場合は以下を参考にインストールしてみてください。
WSL を使用して Windows に Linux をインストールする方法

ステップ4 動作確認

ステップ3 まで完了すると以下のようなDocker Desktopのウィンドウが表示されます。
SkipでOKです。

以下の状態になれば成功です。

これでPC上にDocker Desktopを使用する準備が整いました。

まとめ

今回はDocker Desktopの導入方法について解説しました。
なかなか手間のかかる設定ですが、Docker Desktopが使えると軽量かつ環境に依存せず開発が進められるため非常に便利です。

自分で好きにできる環境を試せるのはモチベに繋がるので、是非いろいろな環境を構築してみてください。