WordPressの「Notice: Undefined index」およびPHP Noticeエラーを修正する方法

表示されている現象

PHPのNoticeは、ページ出力に直接テキストとして吐き出されます。フロントエンドや管理パネル上に表示されたり、「ソースを表示」でHTMLソース内に埋め込まれた形で見つかることもあります。具体的には以下のような表示です：

Notice: Undefined index: sidebar_position in /var/www/html/wp-content/themes/mytheme/functions.php on line 42
Notice: Undefined variable: post_id in /var/www/html/wp-content/plugins/myplugin/class-plugin.php on line 118
Notice: Trying to get property 'ID' of non-object in /var/www/html/wp-content/themes/mytheme/single.php on line 27

これだけではサイトがダウンすることはありません。しかし、HTML出力が乱れ、AJAXコールからのJSONが壊れ、JSONボディの前に予期しないテキストが混入することでREST APIクライアントが誤動作します。さらに悪いことに、これらのNoticeは基本的な安全チェックを省略したコードの症状であることが多く、そこにこそ本物のバグが潜んでいます。

発生する原因

PHPは、まだ定義されていない配列のキーや変数を読み取ろうとするたびにNoticeを発生させます。これが根本原因ですが、WordPressがそれを表示可能にしています。

wp-config.php内のWP_DEBUGを有効にすると、エラーの表示が有効になります。一度有効にすると、未定義の値に触れるテーマ・プラグイン・カスタムコードはすべてNoticeとして表面化します。よくある原因は以下の通りです：

存在確認なしに$_GET、$_POST、$_SERVERのキーにアクセスしている
get_post_meta()を呼び出し、nullチェックなしにその結果を使用している
まだ保存されていないテーマオプションやカスタマイザーの設定にアクセスしている
必要なデータが利用可能になる前のフックでプラグインコードが実行されている

ステップ1 — Noticeの発生箇所を特定する

修正を行う前に、完全なファイルパスと行番号が必要です。ログを有効にしつつ、フロントエンドへの出力は非表示にします：

// wp-config.php
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);   // /wp-content/debug.log にログを記録
define('WP_DEBUG_DISPLAY', false); // フロントエンドには表示せず、ログに記録

WP_DEBUG_DISPLAYをfalseに設定すると、フロントエンドへのNotice表示が即座に消え、ログへの書き込みは継続されます。次のコマンドでログを監視します：

tail -f /var/www/html/wp-content/debug.log

Noticeが表示されたページをリロードしてください。ログに正確なファイルと行番号が表示されます。

ステップ2 — 未定義のインデックス・変数を修正する

ファイルと行番号が問題箇所を直接指し示しています。修正はほぼ必ずこの4つのパターンのいずれかに当てはまります：

パターンA：未定義の配列インデックス

// 壊れたコード — Noticeが発生する
$value = $options['sidebar_position'];

// 修正済み — isset() またはnull合体演算子を使用
$value = isset($options['sidebar_position']) ? $options['sidebar_position'] : 'right';
// PHP 7+ の省略記法：
$value = $options['sidebar_position'] ?? 'right';

パターンB：未定義の変数

// 壊れたコード
echo $post_id;

// 修正済み
$post_id = $post_id ?? null;
if ($post_id) {
    echo $post_id;
}

パターンC：未定義の$_GET / $_POST / $_REQUESTキー

// 壊れたコード — プラグインのフォームハンドラによくあるパターン
$action = $_POST['my_action'];

// 修正済み
$action = sanitize_text_field($_POST['my_action'] ?? '');
if (empty($action)) {
    return;
}

パターンD：get_post_meta()が空文字列を返す場合

// 壊れたコード — メタが存在しない場合、$metaは空文字列になる
$meta = get_post_meta($post->ID, 'custom_field', true);
echo $meta['key']; // $metaが配列ではなく''の場合にNoticeが発生

// 修正済み
$meta = get_post_meta($post->ID, 'custom_field', true);
if (is_array($meta) && isset($meta['key'])) {
    echo $meta['key'];
}

ステップ3 — サードパーティのプラグインまたはテーマのNoticeに対処する

自分が作成していないプラグインやテーマからNoticeが発生している場合、2つの選択肢があります。

オプションA：PHPレベルで抑制する（即効性のある対処法）

実際のエラーはログに記録しつつ、Noticeや非推奨警告を抑制するためにwp-config.phpに以下を追加します：

// wp-config.php — サードパーティコードのNoticeを抑制する
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
error_reporting(E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_STRICT);

オプションB：プラグイン・テーマの作者に報告する

Notice全体（ファイルパス、行番号など）をコピーして、プラグインのリポジトリにIssueを作成してください。積極的にメンテナンスされているプラグインのNoticeはバグとして扱われ、通常1〜2リリース以内にパッチが当たります。

ステップ4 — NoticeがJSON/AJAXレスポンスを壊している場合

JSONレスポンスに混入するNoticeは見た目の問題だけではなく、実際に機能を破壊します。JSONボディの前にテキストが付加されると、ブラウザでJSON.parseがエラーをスローします：

// AJAXハンドラが実際に送信する内容：
Notice: Undefined index: nonce in /wp-content/plugins/myplugin/ajax.php on line 5
{"success":true,"data":"result"}

// ブラウザは不正なJSONを受け取る — JavaScriptが動作しなくなる

まずWP_DEBUG_DISPLAYをfalseに設定し（ステップ1）、AJAXハンドラ内の未定義インデックスを修正してください。それでも余分な出力が漏れ出す場合は、wp_send_json()が実行される前にob_start()とob_end_clean()でハンドラを囲み、出力をキャプチャして破棄します：

add_action('wp_ajax_my_action', function() {
    ob_start(); // Noticeの出力をキャプチャする
    
    $nonce = $_POST['nonce'] ?? '';
    if (!wp_verify_nonce($nonce, 'my_action')) {
        ob_end_clean();
        wp_send_json_error('Invalid nonce');
    }
    
    ob_end_clean(); // 漏れ出たものを破棄する
    wp_send_json_success(['result' => 'ok']);
});

修正の確認

Noticeが表示されていたページをリロードします。HTMLからNoticeのテキストが消えているはずです。
ログがクリーンであることを確認します：

tail -20 /var/www/html/wp-content/debug.log

AJAXエンドポイントを修正した場合は、DevTools → Networkを開いてアクションを実行し、レスポンスが前置テキストのない有効なJSONであることを確認してください。
編集したファイルのシンタックスを簡単にチェックします：

php -l wp-content/themes/mytheme/functions.php

本番環境チェックリスト

本番環境ではWP_DEBUGをfalseに設定する — 本番サイトでのNoticeは内部ファイルパスを訪問者に公開してしまう
本番環境でもWP_DEBUG_LOGはtrueのままにしておき、エラーを静かにキャプチャできるようにする
wp-content/debug.logのローテーションを設定する — 活発なWooCommerceストアではログローテーションなしに1日で200MB以上のログが生成される可能性がある
本番環境にプッシュする前に、WP_DEBUG_DISPLAYをtrueにしたステージング環境でテストを行う