HTTPステータスコードの422エラーは、404500などのコードほど一般的にはみられません。422エラーは、リクエストのどの部分が問題を引き起こしているかが明確にわからないため、判断が難しいことがあります。

概して、422はサーバーがリクエストを理解しているのに、ユーザー側の問題で処理されないことを意味するコード。何かしらの問題を修正し、ページを再読み込みすれば、エラーは解決できます。

この記事では、WordPressユーザー向けに、422エラーの原因と解決方法をご説明します。早速みていきましょう!

422エラーについて動画での解説もご用意しています。

HTTPステータスコードの422エラーとは

422エラーは、サーバー側がリクエストを理解しているにもかかわらず、処理ができないというHTTPステータスコードで、正式名称は「422 Unprocessable Entity(処理できないエンティティ)」です。

通常、リクエストのどこか、特にPHPやJavaScriptのファイル内でセマンティックエラーが起こっているのが原因です。

他のHTTPエラーとは異なり、422コードはリクエストの問題を修正するまで繰り返し表示されます。そして、リクエストのどの部分が処理できないていないのか具体的な情報が確認できないため、一筋縄ではいきません。

HTTPステータスコードの422エラーの原因

先にも述べましたが、422エラーの原因は、リクエストの内容にセマンティックエラーがあることが一般的です。WordPressを使用している場合は、通常、以下の2つのうちどちらかです。

  1. リクエストに関連したファイルの1つにセマンティックエラーを持つコードが含まれている。つまり、コードのエラー。
  2. データベーステーブルが破損している。

422エラーの厄介な点は、ひと目見ただけではその原因がわからないことです。したがって、問題の原因にたどり着くまで、複数のトラブルシューティングを行う必要があります。

HTTP 422エラーは、404や500などの他のコードほど知られていない😅 でもこの記事を読めば大丈夫!🚀 クリックでつぶやく

HTTPステータス&リダイレクトチェッカーで、該当ページのHTTPレスポンスコードを確認することができます。

WordPressの422エラーを解決する方法(2つの手法)

この章では、破損したWordPressデータベースを修復する方法、そしてセマンティックコードエラーを持つファイルを特定する方法をご紹介します。なお、この手順はHTTP 400コードなどの問題のデバッグにも役立ちます。

1. 破損したWordPressデータベースを修復する

WordPressデータベースは、更新中にテーブルが破損してしまうことがあります。つまり、プラグイン、テーマ、もしくはWordPress自体を更新している際にその処理が中断されると、データベースのエントリがエラーを表示するようになる可能性があるということです。

データベースが破損すると、ページを読み込むことができない、機能が正しく動作しない、HTTPステータスコードが422になるなど、WordPress内であらゆる種類の問題が発生することがあります。破損したデータベースを修復するには、2つの方法があり、簡単なのは、WP-DBManagerなどのプラグインを使用する方法です。

WP-DBManager plugin
WP-DBManager

WP-DBManagerを有効にすると、管理画面に「Database」タブが追加されます。「Database」 「Repair DB」に進んで、修復したいテーブルを選択しましょう。今回の場合は、どのテーブルが破損しているのかわからないため、全てを選択して「Repair」をクリックします。

「Repair DB」タブに進む
「Repair DB」タブに進む

この処理は数秒で完了します。準備ができると成功のメッセージが表示されます。この後、422エラーが発生したページに再度アクセスして、まだエラー表示が見られるかどうか確認してください。

422エラーのせいでWordPressの管理画面にアクセスできない場合は、現在使用しているサーバーの管理画面から、データベースにアクセスする必要があります。

Kinstaを利用している場合、MyKinstaからデータベースにアクセスすることができます。「サイト」から該当のサイトを選んで、「情報」タブに移動します。「データベースへのアクセス」の下にあるデータベースのログイン認証情報を見つけます。「phpMyAdminを開く」をクリックし、ログイン情報を入力してください。

Login to phpMyAdmin
phpMyAdmin

左側のメニューから修復したいデータベースを選択すると、そのデータベースに含まれるすべてのテーブルの内訳が右側に表示されます。ページ下部にある「Check all」をクリックして、すべてのテーブルを選択します。次に、その横にあるドロップダウンメニューから「Repair table」を選びましょう。

「Repair table」を選択
「Repair table」を選択

「Go」ボタンをクリックしたら、完了メッセージが表示されるのを待ちます。メッセージが表示されたら、該当ページに再度アクセスし、まだエラー表示があるかどうかを確認してください。

2. HTTP 422コードの原因特定にWordPressのエラーログを使用する

データベースを修復しても422エラーが消えない場合は、WordPressファイルのいずれかに問題がある可能性があります。WordPressには、数十から数百のファイルがあり、セマンティックコードエラーを見つけるためにすべてのファイルを確認するのは気の遠くなる作業です。

この場合、WordPressのデバッグモードを有効にして、エラーログにアクセスするのが最善の策です。手動で有効化するには、ルートディレクトリにあるwp-config.phpファイルを編集します。

ファイル転送プロトコル(FTP)クライアントでサイトにアクセスし、wp-config.phpファイルを見つけてください。ファイルを開いて、以下の2行のコードを「/* That’s all, stop editing! Happy blogging. */」の前に貼り付けてください。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );

WP_DEBUGがすでにある場合は、trueであることを確認し、コードの2行目(WP_DEBUG_LOG)を追加するだけでOKです。変更を保存して、エラーが表示されるページを再読み込みしてください。

エラーはまだ解消されませんが、これでエラーログにアクセスできます。エラーログを読むには、ルートディレクトリ内のwp-contentフォルダに移動して、debug.logファイルを見つけてください(ファイルはテキストエディタで開くことができます)。

そのファイルがまだ新しければ、コードは数行しかなく、そのうちの1行が、422コードの原因になっているエラーを示しているはず。そして、そのエラーが問題を引き起こしている特定のファイルを示しているはずです。また、ファイル内のどの行にセマンティックエラーがあるかという情報も確認できます。

Kinstaを利用している場合は、FTPクライアントに頼ることなく、WordPressのデバッグモードを有効にし、エラーログを確認できます。MyKinstaにアクセスして該当のサイトを選択し、「ツール」タブに進んでください。「WordPressデバッグ」で有効化することができます。

MyKinstaの「WordPressデバック」
MyKinstaの「WordPressデバック」

デバッグを有効にした後は、「ログ」タブに移動して、「error.log」を使うと、最新のエラーが表示されます。「ログビューア」では、特定のエントリを見つけるのに便利な検索機能も利用できます。

MyKinstaでエラーを確認
MyKinstaでエラーを確認

最新のエントリを確認すれば、422エラーの原因となっているファイルを特定できるはずです。ファイルを特定したら、セマンティックエラーを修正するか、WordPressの最新版に置き換えてみてください。

WordPressユーザー必見。この記事で422エラーの原因と解決方法を学ぼう😄 クリックでつぶやく

まとめ

HTTP 422エラーの原因特定方法は、やや複雑になることも。ですが、このエラーの修正自体にはそれほど時間はかかりません。WordPressユーザーであれば、エラーのデバッグに役立つツールを利用することができ、はるかに簡単になります。

WordPressでHTTP 422エラーに遭遇した場合、以下の2つの方法で解決しましょう。

  1. 破損したWordPressデータベースを修正する
  2. HTTP 422コードの原因特定にWordPressのエラーログを使用する

Kinstaを利用していれば、エラーのトラブルシューティングは超簡単。専用のコントロールパネル、MyKinstaには、WordPressをデバッグするためのツールが内蔵されています。自分で問題を解決するのは面倒、という場合には、いつでもKinstaのカスタマーサポートまでご連絡ください。


手間と費用を節約しながら、サイトパフォーマンスを最大化しませんか?

  • 24時間年中無休で、WordPressに精通したエンジニアが親切丁寧にサポート
  • Cloudflare Enterpriseとの統合
  • 東京、大阪をはじめとする世界35箇所にあるデータセンターから選択可能
  • アプリケーションのパフォーマンス監視機能を使って最適化を徹底

長期契約による縛りはございません。サーバー移行のサポート、30日間の返金保証など、さまざまなサービスが付帯します。お客様にぴったりのプランをご提案いたしますので、営業までお気軽にお問い合わせください。また、プラン一覧はこちらからご確認いただけます