また六一儿童節がやってきました。古参のサイト運営者なら覚えているかもしれませんが、以前は毎年六一に軍哥がLNMP一键インストールパッケージを更新していました。Naibaも最初はLNMP一键パッケージのおかげでVPSでウェブサイトを構築することを知りました。2023年、LNMP一键インストールパッケージに悪意のあるプログラムが仕込まれていることが発覚し、その後軍哥がこの事業を売却したことがわかりました。ちょうどその頃、宝塔パネルも台頭してきたため、Naiba サイト構築ノートのチュートリアルの多くは宝塔パネルを使ったサイト構築に切り替わりました。
2009年からWordPressサイト構築に携わってきた初心者として、WordPressの隆盛と衰退を目の当たりにしてきました。外国貿易向け独立サイトの需要がなければ、国内のWordPressエコシステムがどうなっていたかはわかりません。
ここ数年、AIの台頭により、Naibaもプログラムを書く„能力“を得て、WordPressコミュニティにできる限りの貢献をしようと試みています。
以前WordPress公式プラグインリポジトリに提出したB2B製品管理プラグインは、本稿執筆時点でアクティブインストール数が100以上になりました。2026年の儿童節を前に（誰もが子供ですよね）、NaibaはAIにWordPressサイト管理専用のサーバーパネルを開発させました：WP Panel
まず、このパネルがどのように生まれたか
NaibaはNaiba サイト構築ノート多くのWordPressサイト構築チュートリアル記事を共有し、WeChatでも少なくとも5000人以上の相談を受け付けてきたため、初心者ユーザーが自分でウェブサイトを構築する際の難しさを深く理解しています。宝塔パネルは操作が十分に簡単ですが、一部のユーザーにとっては、サイト構築の道における一つのハードルとなっています。
WordPressでサイトを構築する場合、VPS上でサイトを動かすことは最初のステップに過ぎません。動かした後のサイトのセキュリティと安定性こそが、初心者にとって本当に頭の痛い問題です。インターネット上では常にボットがサーバーの脆弱性をスキャンしており、一部のクローラーは1分間に数十から数百回のリクエストを送り、サーバーのCPU使用率が100%になり、サイトがカクついて操作できなくなります。するとまた「WordPressはゴミだ、カクつく、使いにくい」と罵るのです。(⊙﹏⊙)
WordPressを使いこなせない人は、よく「敷居が高い」と感じます。しかし私の見解では、初心者ユーザーが企業公式サイトを構築するには、現時点でもWordPressが最適な選択肢です。
「もうAIでサイトを構築する時代だから、WordPressを使う必要はない」という意見もあります。
実際、サイト構築は最初のステップに過ぎず、その後の運営、管理、メンテナンスが核心です。現段階のAIは、簡単な指示だけでプロフェッショナルなサイトを作り出すことはできません。特にゼロから始めるユーザーにとって、記事公開やSEO最適化などの日常的な運用シナリオでは、AIが生成したサイトはWordPressほど包括的で使いやすく設計されていません。
WP Panelパネル開発の当初の目的はWordPressサーバー管理だけを行うことです。Docker、メール、FTP、他の言語の実行環境は扱いません。一行のコマンドでインストールでき、クリーンなDebian 13が直接WordPress托管プラットフォームになります。初心者はインストールするだけで自分のWordPressサイトを構築できます。
WP Panelで何ができるか？
一言でまとめると：VPSを購入してWordPressサイトを構築するところから、サイトの日常的な運用・保守まで、WP Panelがすべてをサポートします。
WordPressサイトを一键作成
Naibaが以前公開したVultrでWordPressを構築するチュートリアルに従い、VPSを購入したら、まず宝塔パネルをインストールするを実行し、宝塔パネルでサイトを作成します。サイト作成後、手動でWordPressインストールパッケージをダウンロードし、ブラウザでドメインにアクセスしてインストール画面でデータベース情報を入力し、最後にサイトのアカウントとパスワードを設定します。
WP Panelを使用すれば、VPSを購入した後、宝塔パネルをインストールする手順をWP Panelのインストール（同じくワンクリックインストール）に置き換えるだけで、管理画面でサイトを作成し、作成後すぐにブラウザでドメインにアクセスしてサイトのアカウントとパスワードを設定すれば完了です。インストールパッケージのダウンロードやデータベース設定の手間が省けます。
さらに、サイト作成時にWP PanelはWordPressインストールオプションも追加しており、デフォルトで未使用の標準テーマやプラグインを削除したり、人気のテーマやプラグインをインストールすることもできます。
すべてのリソースはWordPress公式から取得され、安全性と最新性が保証されています。インストール画面でインストールするテーマやプラグインのリストをカスタマイズすることも可能です。
サイト管理
各サイトはSSL証明書管理、ステータス監視、Nginxキャッシュ最適化、データベース自動バックアップ、サイトファイル自動バックアップをサポートしています。
また、有効期限の設定もサポートしており、1台のサーバーで複数のクライアントサイトを管理するユーザーにとって非常に便利です。期限前にサーバー管理者にメールで通知が送られるため、手動でクライアントサイトの期限を記録する必要がありません。
WordPressの最適化
WordPressサイトにとって、キャッシュ最適化は避けて通れないポイントです。Naibaは以前、宝塔パネルNginx FastCGIキャッシュ設定チュートリアルを共有しましたが、正直なところ、この操作は初心者には簡単ではなく、設定を間違えるとサイトが開かなくなる可能性があります。そこでNaibaはこの機能をWP Panelパネルに直接組み込みました。
なぜFastCGIキャッシュを選ぶのか、通常の最適化プラグインとの違いは？
通常のキャッシュ最適化プラグイン（WP Rocket、WP Super Cacheなど）とは、動作モードが異なります。
1）WP Rocket（PHP / プラグインレベルキャッシュ）
- 動作するのはWordPress + PHP 層。
- フロー：ユーザーリクエスト → WPに入る → プラグインが判断 → 静的HTMLを読み取り/生成 → 返却。
- キャッシュファイル：
wp-content/cache/に保存され、PHPが管理。 - 必ずPHP-FPM + データベースを経由する（未ヒット時）。
2）Nginx FastCGI Cache（サーバー / システムレベルキャッシュ）
- 動作するのはNginx 層，PHPを完全にバイパス。
- フロー：ユーザーリクエスト → Nginx → ローカルキャッシュを確認 → HTMLを直接返却。
- キャッシュファイル：サーバーディスク/メモリに保存され、Nginxカーネルが管理。
- PHP、MySQL はほとんど関与しません、負荷が極めて低いです。
Nginx FastCGI キャッシュを使用する方が、キャッシュプラグインをインストールするよりも効率的です。
また、更新検出の禁止（コア/プラグイン/テーマ）とバックエンドファイル編集の禁止という2つの機能が追加されています、バックエンドから直接有効にでき、wp-config.php ファイルを手動で編集する必要はありません。
更新検出を無効にすることは標準的な方法ではありませんが、Naiba が接してきた大多数の WordPress ユーザーは定期的に更新する習慣がありません。バックエンドには長年にわたって大量の更新通知が溜まっており、多くの人が一度に一括更新を選択し、結果としてサイト障害を引き起こしています。
その理由は、プラグインやテーマが長期間更新されないと、複数バージョンにわたる機能変更が蓄積されるからです。複数バージョンをまたいで直接アップグレードすると、互換性の問題が発生しやすくなります。ユーザーがタイムリーに更新する習慣がないのであれば、バックエンドで更新検出を直接無効にし、根本からリスクを回避する方が良いでしょう。
さらに、XML-RPC インターフェースへのアクセスがデフォルトで禁止されています。
XML-RPC は WordPress のリモート通信インターフェースです。無効にすると Nginx が直接 403 を返し、PHP-FPM にリクエストが届かないため、xmlrpc.php へのブルートフォース攻撃を完全に防御できます。ほとんどのサイトではこの機能は不要です。
宝塔パネルを使用している場合、サイトのログに入り、xmlrpc.php を検索すると、おそらく多くの xmlrpc.php へのリクエスト記録が見つかります。時には継続的に複数回リクエストされることもあり、それがサイトが突然遅くなる原因です。
计划タスク
計画タスクには主に2つの特徴的な機能があります：サイトファイルのバックアップと WP Cron 呼び出しの作成。
サイトバックアップはフルバックアップと増分バックアップをサポートしています。
フルバックアップ：サイトのルートディレクトリ全体をパッケージ化します。
スマート増分：前回のバックアップ以降に新規追加または変更された wp-content/uploads/ 内のファイルのみをバックアップします。
WP Cron 呼び出しは、WordPress の組み込み疑似 Cron を置き換えるために使用されます — WordPress はデフォルトでページアクセスのたびに計画タスク（予約投稿の公開、更新の確認など）をトリガーするため、不安定でパフォーマンスを消費します。このタスクはシステム Cron を使用して定期的に wp-cron.php を直接呼び出すため、より信頼性が高くなります。
ファイル管理
これは説明するまでもありません。WP Panel にはファイル管理システムが組み込まれており、セキュリティ上の理由からオンライン編集はサポートせず、アップロード、ダウンロード、圧縮、解凍、切り取り、コピー、貼り付け、名前変更のみをサポートしています。
ソフトウェア管理
パネルはデフォルトでオペレーティングシステムとして Debian 13 を推奨しています。PHP 呼び出しに使用する Ondřej Surý ソース（WordPress 公式推奨 PHP バージョンは 8.3 ですが、Debian 13 のデフォルトソースは PHP 8.4 をインストールするため）を除き、他のソフトウェアはすべて Debian 13 公式ソースからインストールされ、これらのソフトウェアのセキュリティは Debian 13 公式がメンテナンスします。
Debian 13 LTS のサポートは約 2030 年 6 月までで、今日から WP Panel を使い始めれば、少なくとも 4 年間はサーバーにインストールされたソフトウェアのセキュリティを心配する必要がないことを意味します。
ソフトウェア管理インターフェースでは、これらのソフトウェアの設定変更もサポートしており、宝塔パネルでのソフトウェア設定変更と同様に、手動でファイルを編集する必要はありません。
アラート通知
SMTP 送信または Webhook プッシュを設定することで、サーバーリソースの使用率が高い、プロセスが異常、バックアップが失敗したなどのシナリオで、サーバー管理者に通知を送信します。
目玉機能：セキュリティ防御
パネル自体のセキュリティ
正直に言うと、AI 開発のパネルについては Naiba もあなた以上にそのセキュリティを懸念しています。そのため、4 層のセキュリティ防御を設計しました。理論上、サーバーの root パスワードとパネルのログインアカウントが突破されなければ、サーバーがハッキングされるリスクは極めて低いです。
誰かがあなたの WP Panel パネルのバックエンドに侵入しようとする場合、少なくとも 4 層の防御を突破する必要があります。
第 0 層：スキャン防御。WP Panel はデフォルトで 8443 ポート + 自己署名証明書を使用してアクセスします。ファイアウォールルールでは、ブラウザ以外からの 8443 ポートへのアクセスを直接ブラックリストに登録するルールが設定されています。つまり、ブラウザを介してサーバーの 8443 ポートにアクセスしない限り、すべてファイアウォールのブラックリスト行きです。
第 1 層：ランダムエントリ。宝塔パネルと同様に 8 桁のランダム文字が付いており、ip+8443 に直接アクセスしてもパネルのログイン画面にはたどり着けません。バックエンドのエントリを推測することは不可能なタスクです。
第 2 層：BasicAuth認証。ブラウザに表示されるネイティブな入力ダイアログで、ユーザー名とパスワードを入力します。この層のパスワードは bcrypt 12 ラウンドのハッシュで保存されており、データベースに平文はありません。
第3層：Web ログイン。BasicAuth 認証を通過した後、さらにウェブフォームのログインパスワードがあります。こちらも bcrypt ハッシュで、ログイン成功後にサーバーサイドのセッションが生成され、Cookie は HttpOnly + Secure + SameSite=Lax で、30 分のスライディング有効期限が設定されています。
BasicAuth と Web ログインの2つのアカウント・パスワードのいずれかで、連続5回入力に失敗すると、ファイアウォールによってブラックリストに登録されます。サーバーが非常に高い価値を持つ場合を除き、IP がブロックされるリスクを負ってパスワードを推測しようとする人はいません。
追加の保護
CSRF トークン：すべての非クエリリクエストには専用の検証トークンが必要です。これにより、クロスサイトリクエストフォージェリを効果的に防止し、悪意のあるサイトがあなたの代わりに操作を送信するのを防ぎます。
セキュリティレスポンスヘッダー：HSTS、X-Frame-Options、nosniff、Referrer-Policy の完全なセキュリティポリシーが設定されており、クリックジャッキングやブラウザスニッフィングなどのクライアントサイド攻撃を防御し、アクセスセキュリティをさらに強化します。
エラーメッセージの難読化：API のエラー内容は処理されており、サーバーパスや実行コマンドなどの内部情報が漏洩しないようになっています。機密データの外部流出を防ぎます。
コードは完全にオープンソース：GPL-3.0 ライセンスに基づいてオープンソース化されており、コードは公開され誰でも確認できます。プログラムはユーザーデータを収集せず、外部のサードパーティサーバーに接続しません。また、ウェブページのバックドアやオンラインコード編集機能は組み込まれておらず、根本からリスクを回避します。
WordPress 専用保護
よく Naiba に「サイトにほとんどアクセスがないのに、一日中重くて仕方ない」という相談があります。実際には、本当にアクセスがないわけではありません。サーバーの背後では、見えないところでボットがサーバーのファイルを執拗にスキャンしています。例えば、上のスクリーンショットでは、152.59.52.221 という IP が /xmlrpc.php に執拗にリクエストを送り、5.101.85.213 という IP が /wp-login.php ファイルを探索しているのがわかります。
リクエストの User-Agent が Jetpack や WordPress と書かれていても、このサイトには Jetpack はインストールされていません。Jetpack からの正当なリクエストがあるはずがなく、IP を調べると、1つはインド、もう1つはロシアです。確認するまでもなく、これらのアクセスは100%ボットです。
そのため、WP Panel パネルはデフォルトで多面的なセキュリティ保護を備えており、手動で設定する必要はなく、自動的に有効になります。
WP Panel は Fail2ban（Linux サーバー上の自動ブルートフォース防止ツール）の複数ルールの組み合わせを使用して悪意のあるリクエストをブロックし、2つの独立した防御 Jail（„監視 + 処罰“ルールパッケージ）を備えています。
メイン防御 Jail（wppanel）、デフォルトのしきい値：60 秒以内に累計 5 回トリガーでブロック（しきい値、時間枠、ブロック時間はパネルで調整可能）。トリガー条件は以下を含みます：
- POST /wp-login.php — ログインブルートフォース。ログインページへの POST リクエストはすべてカウントされます
- POST /xmlrpc.php が HTTP 403 を返す — サイトが XML-RPC インターフェースを無効にした後もプローブされる場合（XML-RPC が有効な場合はカウントされず、Jetpack などの正当なツールが誤ってブロックされるのを防ぎます）
- HTTP 429 を返す — リクエスト頻度制限を超えた場合（レート制限は Nginx が独立して処理し、429 のアクセスログは Fail2ban のカウントに同期されます）
- 機密ファイルのスキャンが HTTP 404 を返す — .env、.git、wp-config.php、.sql、.tar、.gz、.zip など、404 の蔓延に対する防御 Jail（wppanel-404）。メイン Jail から独立しており、しきい値は固定で調整不可：
- 60 秒以内に任意のパスで 404 が 30 回発生した場合、ディレクトリスキャンと判断され、即座にブロックされます。
ブロックアクション：nftables を呼び出して IP の HTTP/HTTPS アクセスを拒否し、同時に Nginx レベルで 444 を返します（接続を直接閉じ、何も返しません）。初回ブロックは 10 分、再犯時はブロック時間が増加します。
CloudFlare、Google、Bing の公式 IP リストを自動的に取得してホワイトリストに追加するため、誤ってブロックされる心配はありません。
CloudFlare を経由した悪意のあるリクエストについては、実際の IP を識別してブロックできます。
ウェブサイトセキュリティ保護
1つの VPS で複数の WordPress サイトを運用する場合、最も懸念されるのは、1つのサイトがダウンした際に他のサイトも影響を受けることです。WP Panel はサイト作成時点から分離を実施しています。
各サイトは独立したシステムユーザーとユーザーグループ（例：wp_naibabiji:wp_naibabiji）を持ち、www-data グループは共有しません。PHP-FPM プロセスプールはそのユーザーとして実行され、Nginx とは分離されています。
PHP レベルでは3つの制限を設けています：
- open_basedir を自サイトのディレクトリ + /tmp + /usr/share/php に限定し、他サイトへのファイル読み取りを防止
- 危険な関数を無効化：exec、passthru、shell_exec、system、proc_open、popen、show_source
- allow_url_include をオフにし、外部URLからのファイル読み込みやコード実行を禁止
機密ファイルのシステム権限も強化：wp-config.php は 600（自サイトユーザーのみ読み取り可能）、鍵ディレクトリは 700 に設定。他サイトの同名ファイルは現在のサイトユーザーからは不可視・不可読。
各サイトは独立したデータベースとデータベースユーザーを使用し、互いに接続不可。
総じて：プラグインの脆弱性を突かれてサイトが乗っ取られた場合、攻撃者はそのサイト内でファイルの改ざんや自身のデータベースの読み書きは可能ですが、他サイトのファイルの読み取り、他サイトのデータベースへの接続、システムコマンドの実行はできません。隔離境界はシステムユーザーとユーザーグループのレベルでブロックされ、越えることはできません。
WP Panelは安全か？
パネルとサイトはそれぞれ多層の隔離と防御を施しており、コードレベルでは十分に安全です。しかし、安全性に100%はなく、以下の状況では WP Panel も対応できません：
- サーバーまたはパネルのアカウント・パスワード漏洩
- システムカーネルの脆弱性が悪用され、攻撃者が root に権限昇格（WP Panel はシステム更新の検出をサポートし、Debian 13 のセキュリティ更新を漏れなく適用）
- 誰かが私の GitHub アカウントとオフライン秘密鍵を同時に入手し、悪意のあるアップデートをプッシュしてアップグレードを騙す
パネルコード自体に脆弱性がある場合は？
確かに、AI が書いたコードはセキュリティ面で不安を感じさせるかもしれません。しかし、当社が設定したセキュリティ防御から判断すると、攻撃者がパネルコードの脆弱性を利用してサーバー権限を取得するには、以下の関門を突破する必要があります：
- ランダムエントリ — 8桁の16進数ランダムパス、43億通りの組み合わせ、ブルートフォースは次の関門へ
- BasicAuth — ブラウザのポップアップ認証、Webログインとカウンターを共有、5回失敗でIPをブロック
- Webログイン — ページフォーム、同じカウンター、累計5回失敗でIPを24時間ブロック
- CSRFトークン — GET以外のリクエストは必須、クロスサイト偽造はヒット不可
この4層のいずれかでブロックがトリガーされると、nftables がネットワーク層でそのIPの全接続を拒否します。攻撃者がパネルのバグを悪用するには、まずこの4つの関門を突破してバグのあるコードに到達する必要があり、その確率は極めて低いです。
また、パネルコードは完全にオープンソースであり、ホワイトハットやセキュリティ研究者によるテストを歓迎します。有効な脆弱性が修正された場合、リリースノートで謝辞を記載します。
WP Panelのインストール方法
ここまで説明しましたが、WP Panel に興味がありますか？まずは適当なVPS、例えば時間課金対応のVultrでインストールしてお試しください。問題なければ本番サーバーにデプロイしてください。
WP Panel は Debian 13 システムで開発されています。理論上は Debian 12 でも使用可能ですが、他のシステムではバグが発生する可能性が高いため、Debian 13 システムでのインストールを推奨します。
SSH で VPS に接続後、以下のコマンドをコピー＆ペーストして Enter キーを押し、インストールが完了するまでお待ちください。
apt-get update && apt-get install -y wget ca-certificates && wget -qO- https://raw.githubusercontent.com/naibabiji/wp-panel/main/install.sh | bashまとめ
WP Panel は大規模な万能パネルではなく、WordPress サイト管理のみに特化しています。より多くのユーザーが VPS を使って自身の WordPress サイトを構築する一助となれば幸いです。
最後に、パネルにバグがあれば、ぜひフィードバックをお寄せください。
GitHub アドレス：github.com/naibabiji/wp-panel
