サイトを本番公開したら、テスト環境と同じ Noindex 設定のままだった。大規模改修後に Google Analytics のタグが計測できていなかった。こういったミスは「次から気をつけよう」と思っても、また繰り返す。なぜなら原因は「注意力が足りないこと」ではなく、「ミスができる構造になっていること」だからです。

製造業には「ポカヨケ」という概念があります。トヨタ生産方式から生まれた言葉で、ヒューマンエラーを人の注意力に頼らず、構造・仕組みによって防ぐという考え方です。この記事では、その考え方を WordPress サイト運用に応用した具体的な実装を紹介します。

    なぜチェックリストではダメなのか

    ポカヨケの本質はここにあります。

    ダブルチェックやチェックシートなど、従来の「人の意識にだけ頼ったミス防止策」で、多くのポカを防ぐことはできない。

    チェックリストや指差し確認は「確認すること」自体をタスクとして人間に委ねています。疲れているとき、急いでいるとき、複数の作業が重なっているとき——そういう状況のときに限って、ミスは起きます。

    ポカヨケの考え方はこうです。

    • 発生防止なそもそもミスができない構造を作る
    • 流出防止なミスが起きたとしても、すぐ検知して通知する

    この2つを組み合わせることで、「気をつけていなくても大丈夫」な状態を目指します。

    実装1：テストサイトと本番サイトを視覚的に区別する（AdminBar カラーリング）

    WordPress の管理バー（AdminBar）の背景色は、admin-style.php でコントロールできます。URLに test が含まれるかどうかで自動判定し、色を切り替えます。

    /* admin-style.php */
function dnone_styles() {
  $is_test = strpos($_SERVER['HTTP_HOST'], 'test') !== false;
  echo '<style>';
  if ($is_test) {
    // テストサイト：グレー
    echo '#wpadminbar { background: #666 !important; }';
  } else {
    // 本番サイト：テーマのプライマリカラー
    echo '#wpadminbar { background: var(--color-primary) !important; }';
  }
  echo '</style>';
}
add_action('wp_head',    'dnone_styles');
add_action('admin_head', 'dnone_styles');

    なぜ本番を赤・テストを緑にしないのか。 プライマリカラーが緑のサイトもあれば、赤のサイトもあります。全サイトで色の意味を統一しようとすると、今度は「この色は何を意味するのか」を覚えなければならない。それ自体がミスの温床になります。グレー = テスト環境という1つのルールにすることで、どのサイトを開いていても「グレーなら触っても安全」と直感的に判断できます。

    実装2：テストサイトの Noindex を強制付与する

    WordPress の「設定 > 表示設定 > 検索エンジンがサイトをインデックスしないようにする」は、テストサイトでオンにしていても、All in One Migration などで本番にインポートした際にそのままオンになっているか確認が必要です。

    これも「確認する」という人間のタスクに依存しているので、構造で解決します。

    /* テストサイトでは強制的に noindex を付与 */
function force_noindex_on_test() {
  $is_test = strpos($_SERVER['HTTP_HOST'], 'test') !== false;
  if ($is_test) {
    echo '<meta name="robots" content="noindex, nofollow" />' . "n";
  }
}
add_action('wp_head', 'force_noindex_on_test', 1);

    priority: 1 にすることで、プラグインが出力するどの robots メタよりも先に挿入されます。URLに test が含まれる限り、WordPressの設定がどうなっていようと必ず noindex になります。

    あわせて、<title> タグにも [テスト] を自動付与します。

    /* <title> に [テスト] を付与 */
function add_test_prefix_to_title($title_parts) {
  $is_test = strpos($_SERVER['HTTP_HOST'], 'test') !== false;
  if ($is_test && isset($title_parts['title'])) {
    $title_parts['title'] = '[テスト] ' . $title_parts['title'];
  }
  return $title_parts;
}
add_filter('document_title_parts', 'add_test_prefix_to_title');

/* 管理バーのサイト名にも [テスト] を付与 */
function add_test_prefix_to_adminbar($wp_admin_bar) {
  $is_test = strpos($_SERVER['HTTP_HOST'], 'test') !== false;
  if ($is_test) {
    $node = $wp_admin_bar->get_node('site-name');
    if ($node) {
      $node->title = '[テスト] ' . $node->title;
      $wp_admin_bar->add_node((array)$node);
    }
  }
}
add_action('admin_bar_menu', 'add_test_prefix_to_adminbar', 999);

    ブラウザのタブ・管理バー・ページタイトルのすべてに [テスト] が表示されるので、どこを見ても「今テスト環境を触っている」と認識できます。

    実装3：アナリティクスタグをテーマ外に置く

    WordPress のテーマファイルやプラグイン設定に GA4 タグを置くと、All in One Migration でテーマごと本番にインポートしたとき、テスト環境の設定が混入するリスクがあります。

    解決策は、アナリティクスタグをサイトのルートディレクトリに置き、テーマからはパスを参照するだけにすることです。

    /（サーバーのドキュメントルート）
└── site_root/
    ├── analytics-head.php   ← ここに GA4・GTM タグを書く
    ├── analytics-body.php
    ├── analytics-foot.php
    └── wp-content/ ← WordPress 本体
        └── themes/
            └── zaratan/ ← テーマ（Migration で持ち運ぶ範囲）

    テーマの head.php からの呼び出しはこうです。

    <?php
$_f = do_shortcode('[root_sitepath]') . '/analytics-head.php';
if (file_exists($_f)) include $_f;
?>

    file_exists() でチェックしているので、ファイルがなくてもエラーになりません。

    このアプローチの利点：

    • All in One Migration でテーマを丸ごと移動させても、ルートの analytics-*.php には触れない
    • テストサーバーには analytics-*.php を置かないだけで、タグが出力されない
    • ファイルをアップロードする作業は公開時の1回だけで、その後触る必要がない

    実装4：設定の変更し忘れを1箇所に集約する

    複数サイトを管理するとき、「このサイトのルートパスはどこか」という情報があちこちに散らばっていると、変更漏れが起きます。

    shortcodes.php にパス設定を集約し、ショートコードとして呼び出せるようにします。

    /* shortcodes.php */
$root_path      = $_SERVER['DOCUMENT_ROOT'];
$root_sitepath  = $root_path . '/site_root';   // ← ここだけ変える
$root_themepath = $root_sitepath . '/wp-content/themes/zaratan';

$paths = [
  'root_sitepath'  => $root_sitepath,
  'root_themepath' => $root_themepath,
  // ...
];

    高天原サイトなら '/takamagahara' に変えるだけです。テーマの呼び出し側は一切変更不要。「変更が1か所だけ」というのはポカヨケの基本原則のひとつです。

    実装5：アクセス異常を自動検知してメールで通知する（GAS）

    発生防止の仕組みをいくら整えても、想定外のミスはゼロにはなりません。そこで流出防止として、Google Apps Script（GAS）で GA4 のアクセス数を毎朝チェックし、異常があればアラートメールを送る仕組みを作ります。

    判定ロジックは2つです。

    • 前日比な一昨日と比べて −40% 以下
    • 直近7日平均比な過去7日の平均と比べて −40% 以下
    const CONFIG = {
  REPORT_TO: 'your@email.com',
  GA_PROPERTIES: [
    { label: 'サイトA', propertyId: '000000000' },
    { label: 'サイトB', propertyId: '111111111' },
  ],
  ALERT_THRESHOLD: 0.4,  // 40%減でアラート
  BASELINE_DAYS: 7,
};

    GA_PROPERTIES にサイトを追加するだけで複数サイトを1通のメールで管理できます。アクセスが正常なときは ✅ GA4 デイリーレポート、急落したときは ⚠️【要確認】GA4 アクセス異常検知 と件名が変わります。

    件名だけで判断できるので、毎日メールを開いて数値を確認するコストがかかりません。

    詳しい設定手順については、別記事「GA4のレポートを毎日自動でメール配信する方法【GASで異常値アラート付き】」を参照してください。

    GA4レポートを毎日自動メール配信する方法【GASで異常値アラート付き】

    Google Apps Script（GAS）でGA4のアクティブユーザー数・PV数を毎朝自動メール配信する方法を解説。前日比・7日平均比でアクセスが急落したとき件名で通知する異常値アラート機能付き。複数サイト対応。  続きを読む

    3つのレイヤーで多層防御する

    ポカヨケの実装を整理すると、3つのレイヤーになっています。

    レイヤー実装内容目的
    視覚的に気づかせるAdminBarの色分け / [テスト] 表示今どの環境にいるか常に意識させる
    物理的にミスできない構造ルートへのタグ配置 / $root_sitepath 集約 / 強制 noindexミスが起こる余地をなくす
    自動検知・通知GAS デイリーレポート＋アラート漏れたミスを早期発見する

    1つの防御に頼るのではなく、これらが組み合わさることで実効性が上がります。

    まとめ

    「次から気をつける」「毎回確認する」というアプローチには、根本的な限界があります。人間は集中力が持続せず、繰り返し作業を飽きる生き物だからです。

    ポカヨケの考え方は「ミスをする人間が悪い」ではなく「ミスが起きやすい構造が悪い」という視点から出発します。構造を変えてしまえば、注意力に関係なく正しい結果が得られる——これが本質です。

    今回紹介した実装のほとんどは、一度設定してしまえばその後触る必要がありません。そのこと自体が、優れたポカヨケの設計の証明だと思います。