接続エラーでも、
データを消さずに
確認できます。

01 / IDENTIFY THE SYMPTOM

その画面だけで、原因は決まりません。

「データベース接続確立エラー」は、WordPressが必要なデータベースへ接続・選択できない状態を示します。サイトを表示するファイルが残っていても、記事や設定を読み出せなければ表示できません。エラーが出たことだけで、記事データの消失やConoHaの障害と断定はできません。

画面の主な表示が「500」「真っ白」「ログインだけ失敗」なら、同じ問題とは限りません。まず500エラー・白い画面の切り分けと区別します。WordPress公式の接続エラー解説

今の状況から、確認順を選ぶ

直前変更が分かればその対応から。分からなければ、対象と現状の確認だけに留めます。下の各手順もそのまま読めます。

02 / READ BEFORE CHANGING

何も変えていないなら、障害情報と現状から。

1. 公式のお知らせ：ConoHa WINGの障害・メンテナンス情報で、対象サービス・発生時間・影響範囲を確認。掲載がないことも、個別障害がない証明ではありません。
2. 影響範囲：同じサイトの公開記事と管理画面、同一契約の別サイトに同じ症状があるかを確認。別サイトが動くことだけで、対象DBの正常は確定しません。接続試行を連打せず、一度の結果と時刻を控えます。
3. 容量・サービスの状態：コントロールパネルでDBの利用容量、契約・利用状態を確認。容量が多いだけで原因と断定せず、上限や利用制限は現在の公式案内・サポートと照合します。記事やテーブルの一括削除で空けようとしません。

障害・メンテナンスの影響が疑われるときは、接続情報の書き換えや再インストールを重ねず、案内に従います。接続情報が変わっていないことも担当者へ確認しましょう。

03 / MATCH THE SETTINGS

4項目を「同じサイトの情報」と照合する。

ConoHaのアカウント、WordPress管理者、DBユーザーは別のものです。管理画面へ入れないからといって、DBパスワードが間違っているとは限りません。以下のConoHa画面操作は公式公開ガイドによる案内で、当サイトが会員画面で実操作した記録ではありません。

1. 対象サイトと保存物を確認する

対象ドメインとWordPressを置いたフォルダーを確認。複数サイトや移行前後の環境を取り違えないようにします。編集前のwp-config.phpを端末の非公開フォルダーへ保存し、日時を付けて保管します。設定ファイルのコピーをWeb公開ディレクトリへ「.bak」「.txt」等で置きません。ファイルだけでなく、DBのバックアップの所在と復元できる範囲も確認します。バックアップと復元の基本

2. ConoHa側のDBとユーザーを確認する

対象サイトを選び、データベース一覧の詳細でDB名・接続先・容量を確認。ユーザー一覧では、そのユーザーがどのDBへ接続できるかを確認します。表示用のネームタグとDB名は区別してください。DB情報の確認 ／ ユーザーと接続先DBの確認

3. WordPress側の設定と対応させる

公式ガイドのファイルマネージャーから、public_html内の対象ドメイン、WordPressを置いた場所のwp-config.phpへ。内容は自分の環境内で確認します。ConoHa公式：設定ファイルの場所・編集上の注意

値を転記する表ではなく、照合する項目の一覧です。

テーブル接頭辞（$table_prefix）もデータとの対応に関わりますが、接続先4項目と別の確認です。見覚えのないインストール画面が出た場合は、初期設定を進めず対象DB・テーブルの取り違えを疑って停止します。WordPress公式：設定ファイル

4. 編集が必要な場合だけ、一か所ずつ

正しい値・担当権限・保存物・戻し方が分かる場合に限り、不一致の箇所を修正します。引用符やセミコロンを壊さず、無関係な設定を変更しません。保存後は対象サイトを一度確認。変化がなければ、推測で別の値を試し続けず戻して相談します。

04 / WHAT WE TESTED

同じエラー画面に、4つの異なる原因。

独立したWordPress 7.1.2＋MariaDB 10.11.19で、合成の接続設定を1項目ずつ変えました。正常時はHTTP200。認証情報不一致、存在しないDB名、利用権限なし、接続先に到達できない状態は、すべてHTTP500・同じ公開エラー画面になりました。4画面のHTMLも同一でした。

当サイト独自の検証環境で行った実験です。ConoHa WINGの実環境での障害再現ではありません。

DB名不一致と権限なしは、この環境では接続検査のコードまで同じでした。コードだけで原因を決めず、設定とDB側の対応を確認する必要があります。これらの数値を読者が本番で取得するために、公開デバッグ表示や診断用PHPファイルを追加する手順は勧めません。

05 / STOP AND RECOVER

悪化したら、直前の設定へ戻す。

1. 設定変更だけなら：変更箇所を記録し、保存しておいた元のwp-config.phpまたはその箇所へ戻します。別の設定変更を重ねません。復旧しなければ、元からの問題が続いている可能性もあり、推測の変更を止めます。
2. DBパスワード等も変えたなら：ファイルだけ戻してもDB側と再び不一致になります。どちらで何を変えたか、他の利用先も含め担当者へ共有します。新旧の秘密値は公開せず、正規の安全な連絡手段を使います。
3. データ復元が必要なら：戻す日時・対象DB・接続先・現在の更新データを先に確認。ConoHaの「リストア完了」とWordPressが正しいDBを参照して読めることは別です。公式のDB復元手順を確認し、不明なら実行前に相談します。

公開側に秘密値や詳細エラーを出す、DBを削除する、WordPressを初期化・再インストールする、意味の分からないSQL修復を流す作業は、この切り分けの初手にはしません。

「エラーが消えた」の先まで確認する。

トップだけでなく、既存の個別記事・画像・管理画面を確認。移行後なら新旧どちらを見ているか、記事の内容と最終更新も照合します。キャッシュされた画面が見えたことだけで、接続が回復したとは判断しません。

0 / 5 確認済み

チェックは読者自身の確認用です。端末外へ送信せず、保存もしません。完了しても将来の障害が起きない保証ではありません。

分からなければ、この情報だけを整理して相談する。

契約・対象サイトの識別はConoHaの正規サポートで必要に応じて伝えます。公開相談にはパスワード、設定全文、DBエクスポート、Cookie、ログ全文を載せないでください。設定を読めない・権限がない・元へ戻せない・最新データを保全できない場合は、編集前に停止して管理担当へ相談します。

根拠と確認範囲

2026年10月20日に公開一次資料を確認。ConoHa側の操作は公式ガイドに基づく説明、接続失敗と復元は別の隔離実験です。架空のConoHa管理画面や、実サービスでの復旧実績は作っていません。

• ConoHa：データベースFAQ
• ConoHa：DB情報の確認 ／ DBユーザーと接続先
• ConoHa：WordPress設定ファイルの編集
• ConoHa：phpMyAdminへのログイン — DBを扱う必要がある場合の公式手順。接続確認のためにテーブルを変更する指示ではありません。
• ConoHa：DBリストアと復元
• WordPress：接続エラー ／ 設定ファイル

実際のConoHa障害・会員操作・実機・第三者初心者テスト・成果帰属・収益改善は未検証です。編集・検証方針 ／ 訂正を連絡する