WordPress: ブロックエディタがCloudFront経由で動かないの原因と解決策

概要

CloudFront経由でWordPressにアクセスすると、ブロックエディタ（Gutenberg）が使えなくなる、またはクラシックエディタのビジュアルタブが表示されない問題。原因はUser-Agentヘッダーがオリジンに転送されていないことです。

症状

ブロックエディタが表示されず、HTMLエディタのみになる
クラシックエディタで「ビジュアル」タブが消える
投稿編集画面が正常に動作しない
メディアのアップロードができない

原因

User-Agentヘッダーの欠落: CloudFrontがオリジンにUser-Agentを転送していない
WordPressのブラウザ判定: User-Agentでデスクトップかどうかを判定している
デフォルトのリクエストポリシー: CloudFrontはデフォルトでUser-Agentを「Amazon CloudFront」に置き換える

なぜ起きるのか

WordPressはUser-Agentを見て、ビジュアルエディタを表示するかどうかを決定します。CloudFrontがUser-Agentを転送しない、または「Amazon CloudFront」に置き換えると、WordPressは「デスクトップブラウザではない」と判断し、ビジュアルエディタを無効化します。

クライアント → CloudFront → WordPress
              ↓
    User-Agent: Amazon CloudFront
              ↓
    WordPress: "デスクトップじゃない？エディタ無効化"

解決策

1. オリジンリクエストポリシーを設定

CloudFrontのディストリビューション設定で、User-Agentヘッダーをオリジンに転送します。

AWS Console での設定:

CloudFront > ディストリビューション > ビヘイビア編集

オリジンリクエストポリシー:
  - 「AllViewerExceptHostHeader」を選択
  または
  - カスタムポリシーで User-Agent を含める

2. マネージドポリシーを使用

AWSが提供するマネージドポリシー「AllViewerExceptHostHeader」を使用すると、User-AgentとRefererを含む多くのヘッダーが転送されます。

オリジンリクエストポリシー:
  Managed-AllViewerExceptHostHeader

3. wp-admin用のビヘイビアを作成（推奨）

管理画面用に専用のビヘイビアを作成し、キャッシュを無効化してすべてのヘッダーを転送します。

パスパターン:

/wp-admin/*
/wp-login.php
/wp-json/*

設定:

キャッシュポリシー: CachingDisabled
オリジンリクエストポリシー: AllViewerExceptHostHeader
許可されたHTTPメソッド: GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE

4. AWS CLI で設定

1
2
3
4
5
6
7
8
# オリジンリクエストポリシーの確認
aws cloudfront list-origin-request-policies --type managed

# AllViewerExceptHostHeader のポリシーID
# 216adef6-5c7f-47e4-b989-5492eafa07d3

# ディストリビューション設定の取得
aws cloudfront get-distribution-config --id YOUR_DISTRIBUTION_ID

5. Terraform での設定例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
resource "aws_cloudfront_distribution" "wordpress" {
  # ... 省略 ...

  # 静的コンテンツ用（デフォルト）
  default_cache_behavior {
    allowed_methods  = ["GET", "HEAD"]
    cached_methods   = ["GET", "HEAD"]
    target_origin_id = "wordpress"

    cache_policy_id          = "658327ea-f89d-4fab-a63d-7e88639e58f6"  # CachingOptimized
    origin_request_policy_id = "216adef6-5c7f-47e4-b989-5492eafa07d3"  # AllViewerExceptHostHeader

    viewer_protocol_policy = "redirect-to-https"
  }

  # 管理画面用
  ordered_cache_behavior {
    path_pattern     = "/wp-admin/*"
    allowed_methods  = ["GET", "HEAD", "OPTIONS", "PUT", "POST", "PATCH", "DELETE"]
    cached_methods   = ["GET", "HEAD"]
    target_origin_id = "wordpress"

    cache_policy_id          = "4135ea2d-6df8-44a3-9df3-4b5a84be39ad"  # CachingDisabled
    origin_request_policy_id = "216adef6-5c7f-47e4-b989-5492eafa07d3"  # AllViewerExceptHostHeader

    viewer_protocol_policy = "redirect-to-https"
  }

  # wp-login.php
  ordered_cache_behavior {
    path_pattern     = "/wp-login.php"
    # ... 同様の設定 ...
  }

  # REST API
  ordered_cache_behavior {
    path_pattern     = "/wp-json/*"
    # ... 同様の設定 ...
  }
}

確認方法

オリジンに届いているヘッダーを確認

1
2
3
4
5
6
// functions.php に一時的に追加
add_action('init', function() {
    if (current_user_can('administrator')) {
        error_log('User-Agent: ' . ($_SERVER['HTTP_USER_AGENT'] ?? 'NOT SET'));
    }
});

CloudFront経由かどうか確認

1
2
// CloudFront経由の場合、X-Forwarded-For が設定される
$is_cloudfront = isset($_SERVER['HTTP_X_FORWARDED_FOR']);

よくある間違い

キャッシュポリシーとオリジンリクエストポリシーを混同する
管理画面をキャッシュしてしまう
POSTリクエストを許可し忘れる
Cookie転送を設定し忘れる（ログイン状態が維持されない）

パフォーマンスへの影響

User-Agentを転送すると、CloudFrontのキャッシュヒット率が下がる可能性があります。User-Agentの値ごとに別のキャッシュエントリが作成されるためです。

対策:

管理画面（/wp-admin/*）はキャッシュ無効化
フロントエンドは必要最小限のヘッダーのみ転送
静的アセット（/wp-content/uploads/*）は完全にキャッシュ

WordPress: ブロックエディタがCloudFront経由で動かない

概要

症状

原因