Parse error: syntax error とは？WordPress での直し方｜unexpected token の読み方と管理画面に入れないときの復旧手順

「Parse error: syntax error, unexpected ...」は、PHPファイルの書き方に誤りがあり、PHPがファイルを読み込む段階で止まっていることを示すエラーです。直すには、エラーに表示されたファイルの該当行付近を修正するか、直前に加えた変更を元に戻します。管理画面に入れなくなっていても、FTP・ファイルマネージャー・WP-CLIのどれかでファイルを直接触れば復旧できます。この記事では、メッセージの読み方、原因の探し方、状況別の復旧手順、再発を防ぐ編集の仕方を説明します。

メッセージから場所を特定する

エラーは次のような形で表示されるか、サーバーのエラーログに記録されます。

PHP Parse error:  syntax error, unexpected token "}", expecting ";" in /var/www/html/wp-content/themes/my-child/functions.php on line 42

読み取るべきなのは3点です。

• ファイルパス：どのファイルに誤りがあるか。themes/ ならテーマ、plugins/ ならプラグイン、wp-config.php なら設定ファイルです。
• 行番号：PHPが誤りに気づいた行です。実際の誤りはその直前の行にあることがよくあります。たとえば41行目の末尾のセミコロンが抜けていると、PHPは42行目の先頭で初めて不自然さに気づきます。
• unexpected の後ろ：PHPが想定していなかった記号や語です。PHP 8では unexpected token "}"、PHP 7では unexpected '}' のように表記が少し異なります。

画面が真っ白になってメッセージが見えない場合は、サーバーのエラーログを確認します。レンタルサーバーではコントロールパネルにエラーログの閲覧機能があることが多く、VPSならApacheやNginx、PHP-FPMのログに記録されています。

よくある原因とメッセージの対応

セミコロンや括弧の閉じ忘れ

もっとも多い原因です。unexpected token "..."、expecting ";" のように出る場合は、表示された行とその前の行の文末を確認します。unexpected end of file と出る場合は、どこかで { に対応する } が足りず、ファイルの最後まで読んでしまった状態です。関数やif文を追加した箇所の括弧の対応を数えてください。

ネット上のコードをコピーしたときの混入

ブログや資料からコードをコピーすると、次のような文字が紛れ込むことがあります。

• 引用符が “ ” や ‘ ’ のような装飾付きの文字に変わっている
• 全角スペースや全角の記号（； （）が入っている
• 見た目では分からない制御文字が入っている

見た目では正しく見えるため、気づきにくい原因です。エディターで不可視文字を表示する設定にするか、該当行を手で打ち直すと解消します。

functions.php に <?php を重ねて書いた

functions.php はすでに先頭の <?php でPHPのコードとして読まれています。途中に追加するコードの先頭に、もう一度 <?php を付けて貼り付けると、unexpected token "<" のようなエラーになります。追加するコードからは <?php を外して貼り付けます。

PHPのバージョンに合わない書き方

?->（nullsafe演算子）や match 式はPHP 8.0以降、enum はPHP 8.1以降の構文です。新しいPHPを前提に作られたプラグインやテーマを古いPHPで動かすと、構文として解釈できずにParse errorになります（2026年10月現在、WordPressの推奨はPHP 8系です）。サーバーのPHPバージョンを下げた直後や、古いサーバーに移転した直後にこのエラーが出た場合は、まずバージョンの違いを疑ってください。

管理画面に入れる場合

致命的なエラーが起きると、WordPress 5.2以降では「このサイトで重大なエラーが発生しました」と表示され、サイト管理者のメールアドレスにリカバリーモードへのリンクが届きます。リンクから入ると、原因のプラグインやテーマを一時停止した状態で管理画面を開けるので、そのまま無効化したり、更新したりできます。

ただし、wp-config.php の誤りはWordPressの読み込みより前に起きるため、この仕組みは働きません。後述のFTPやファイルマネージャーで直します。

FTP・ファイルマネージャーで直す

管理画面に入れない場合の基本の手順です。どの作業でも、編集前にファイルのコピーを手元に保存しておきます。

1. FTP/SFTPクライアントか、レンタルサーバーのファイルマネージャーで、エラーに表示されたファイルを開く
2. 直前に追加・変更した部分があれば、その部分を削除して元の状態に戻す
3. 変更箇所が分からなければ、表示された行番号とその前後を確認して修正する
4. 保存してサイトを再読み込みし、表示が戻ったか確認する

修正箇所が見つからない場合は、原因のプラグインやテーマを止めて、まずサイトを表示させます。

• プラグインが原因：wp-content/plugins/ の中の該当フォルダ名を変更します（例: example-plugin を example-plugin-off に）。WordPressはそのプラグインを読み込まなくなります。
• テーマが原因：wp-content/themes/ の該当フォルダ名を変更します。ほかにインストール済みのテーマがあれば、WordPressはそちらに切り替えて表示します。デフォルトテーマが残っていないと表示できないことがあるので、デフォルトテーマは削除せずに置いておくのが安全です。

WP-CLIで直す

SSHで入れるなら、作業はさらに速くなります。原因のプラグインやテーマを読み込んだままだとWP-CLI自体も同じエラーで止まるため、--skip-plugins や --skip-themes を付けて実行します。

# 構文チェック（誤りがあれば行番号付きで表示される）
php -l wp-content/themes/my-child/functions.php

# テーマ内のPHPファイルをまとめてチェックし、問題のあるものだけ表示
find wp-content/themes/my-child -name '*.php' -print0 | xargs -0 -n1 php -l | grep -v '^No syntax errors'

# 原因のプラグインを無効化（プラグインを読み込まずに実行）
wp plugin deactivate example-plugin --skip-plugins

# 原因のテーマから既定テーマへ切り替え（テーマを読み込まずに実行）
wp theme activate twentytwentyfive --skip-themes

php -l はコマンドライン用のPHPで構文を確認するため、Webで動いているPHPとバージョンが違うと結果が変わることがあります。php -v とサイトヘルスに表示されるPHPのバージョンが一致しているかも確認しておくと、前述のバージョン違いによるエラーを見落としません。

エラーログで詳細を確認する

Parse errorの内容をログに残したい場合は、wp-config.php の /* 編集が必要なのはここまでです */ より上に次を書きます。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );      // wp-content/debug.log に記録
define( 'WP_DEBUG_DISPLAY', false ); // 訪問者の画面には表示しない

記録は wp-content/debug.log に追記されます。本番サイトでは画面に表示しない設定にし、調査が終わったら WP_DEBUG を false に戻してください。debug.log は外部から読めるとファイルパスなどの情報が漏れるため、調査後は削除するか、Webから読めない場所に記録先を変えます。なお、wp-config.php 自体にParse errorがある場合はこの設定も読まれないので、サーバーのエラーログを見ます。

再発を防ぐ編集の仕方

Parse errorの多くは、本番サイトのファイルを直接編集したときに起きます。次の運用にすると、同じ事故を防ぎやすくなります。

• 親テーマの functions.php ではなく、子テーマか、コードスニペット管理用のプラグインにコードを追加する。親テーマは更新で上書きされるうえ、誤りがあったときの影響も大きくなります。
• 管理画面のテーマ・プラグインファイルエディターは、保存時にループバックで致命的エラーを検査し、問題があれば変更を戻します。ただしBasic認証などでループバックが失敗する環境では使えないため、頼り切らずに使う前のバックアップを習慣にします。
• 手元のエディターで書き、php -l で構文を確認してからアップロードする。PHPに対応したエディターなら、保存前に括弧の対応や構文の誤りが表示されます。
• ステージング環境で動作を確認してから本番に反映する。

ファイルの末尾にある ?> の後ろに空行やスペースがあると「Cannot modify header information - headers already sent」という別のエラーになります。PHPだけのファイルでは、末尾の ?> は書かないのが一般的です。

まとめ

• Parse errorはPHPの書き方の誤り。メッセージのファイルパスと行番号を見て、その行と直前の行を確認する
• unexpected end of file は括弧の閉じ忘れ、コピーしたコードでは装飾付きの引用符や全角文字の混入を疑う
• 管理画面に入れなければ、FTPやファイルマネージャーで変更を戻すか、該当プラグイン・テーマのフォルダ名を変える
• WP-CLIでは --skip-plugins・--skip-themes を付けて無効化し、php -l で構文を確認する
• 本番の直接編集を避け、子テーマ・ステージング・バックアップで再発を防ぐ

• WordPressの500 Internal Server Errorを直す方法
• 本番環境でWP_DEBUGを無効化する方法と注意点