Plesk Obsidianのアップデート：ホスティングプロバイダー向けの新機能

バージョン情報とコンポーネントを明確に分離する

2026年10月2日時点での記録上の状況は、以下のとおりである。 主力製品 Plesk Obsidian 18.0.81 アップデート 2。このアップデートは 2026 年 9 月 29 日にリリースされ、重大なセキュリティ上の問題を修正しています。 この記事で説明されている新しいパネル機能は、2026年9月15日にリリースされた Plesk Obsidian 18.0.81 に含まれています。一方、アップデート 1 およびアップデート 2 には、文書化されたバグ修正およびセキュリティ修正が含まれています。.

ただし、コアバージョン 18.0.81 Update 2 に変更を加えることなく、それ以降の更新が行われている可能性があります： 例えば、変更履歴には、9月29日の「SSL It!」や「Let’s Encrypt」といった拡張機能の更新、および2026年9月30日のPHPパッケージの更新が記載されています。したがって、「最新のPlesk」とだけ言う場合は、計画やサポートにとって重要な情報が欠落していることになります。.

Plesk では、更新レベルがいくつか区別されています。Plesk パッケージは、パネル本体とその直接関連する機能で構成されています。これとは別に、Plesk が提供するサービスパッケージや拡張機能があり、これらは追加機能を提供したり、外部サービスと連携したりすることができます。 したがって、拡張機能のバージョン番号が更新されたからといって、Pleskのコアも最新の状態にあるとは限らず、その逆も同様です。.

さらに、各 ホスティングパネル オペレーティングシステム内にはさらに以下のレイヤーが存在します：OSパッケージ、およびデータベース、PHPランタイム、Webサーバー、メールサービスなどのサードパーティ製コンポーネントです。これらのパッケージソース、サポートサイクル、依存関係は、必ずしもPleskのリリースサイクルに準拠するとは限りません。 プロバイダーにとって、この区分は実務上重要な意味を持ちます。なぜなら、発生するエラーの様相、メンテナンスウィンドウ、および責任の所在は、影響を受けるコンポーネントによって異なる可能性があるからです。.

したがって、環境ドキュメントには常に、Pleskのバージョンとアップデート番号、インストール済みの拡張機能のバージョン、OS、および関連するランタイムパッケージという具体的な組み合わせを記載する必要があります。証明書やアプリケーション機能に関しては、使用されている統合機能も記載する必要があります。 これにより、変更が「SSL It!」、Let’s Encrypt 統合、あるいはパネルコアのうちどれに起因するものかが明確になります。これにより、顧客への告知における期待の齟齬を防ぎ、サポート時の原因特定を容易にします。.

Pleskのアップデートがプロバイダーに与える影響

Obsidian 18.0 シリーズでは、アップデートが継続的に、 順次 インストール済み。 個々の中間アップデートをスキップすることはできません。これにより、明確な更新パスが確立されますが、プロバイダーが自身の環境を確認する責任が免除されるわけではありません。サーバーがホストする顧客サイト、個別のPHP依存関係、および拡張機能が多ければ多いほど、どの変更がどのサービスクラスに影響を与えるかという点が重要になります。.

Plesk では、独自のアップデートに関する自動更新機能と、同梱されているサードパーティ製コンポーネントおよびシステムパッケージ向けの個別のオプションについて説明されています。しかし、ドキュメントページには、サードパーティ製コンポーネントのオプションのデフォルト設定に関して矛盾した記述があります。 したがって、管理者はグローバルに適用されるデフォルト設定を前提とせず、各サーバーごとに実際に設定されているオプションを Tools & Settings > Update Settings 確認してください。新しいコンポーネントはホストされているウェブサイトと互換性がない可能性があるため、特に注意が必要です。.

多くの顧客インスタンスの運用において、この区別はプロセスに反映されることでメリットとなります。パネルの修正やセキュリティ変更は、その範囲に基づいて計画できますが、コンポーネントの変更については、別途互換性評価が行われます。 マネージドホスティングサービスは、利用可能なすべてのパッケージバージョンを直ちに導入する必要はありません。重要なのは、約束されたスタック、テスト済みの顧客基盤、および想定されるサポートモデルに適合するバージョンを選ぶことです。.

最新のObsidianバージョンの利点は、複数の運用領域に及んでいます。診断機能はファーストレベルサポートの体制を整備し、新しいアプリケーションホスティングツールは料金プランの選択肢を拡大し、さらに証明書およびアシスタント機能はセキュリティと権限管理に関与しています。 本製品ラインのこれまでの基礎と発展については、以下の記事でも解説されています。 Plesk Obsidian 2025: ウェブホスティングの革命的イノベーション 。ただし、今回の導入にあたっては、製品名だけでなく、具体的な構成要素が決定的な要素となります。.

したがって、自動化は一律に承認すべき決定ではありません。文書化されたPleskアップデートの定期的なインストールと、顧客スタックに対する意図的に管理された変更とを区別することが適切です。 特に共有サーバーの場合、この境界線を設けることで、気づかれないまま行われたコンポーネントの変更が、互いに独立した多数のウェブサイトに同時に影響を及ぼすことを防ぐことができます。これはテストの代わりにはなりませんが、リスクを可視化し、その原因を特定できるようにします。.

ホスティングのシナリオ別新機能

共有ホスティングにおいて、最初の活用例として挙げられるのは、ドメイン障害の迅速な特定です。 Plesk Obsidian 18.0.81 一般提供版のDNS診断機能には、ホスト名の解決、MX関連項目、DNSSEC、ネームサーバー、およびドメインの有効期限に関するチェックがまとめられています。 パネル上に表示されるわかりやすいレポートは、サポート担当者が、問題がエスカレーションする前に、DNS、メール、および委任に関する課題を体系的に確認するのに役立ちます。.

しかし、この報告書は 診断 また、自動修正機能はありません。特にドメインエイリアスについては、現時点では対応対象外となっています。誤った委任やゾーンを示唆する検出結果が出た場合でも、その修正はレジストラや外部のDNSプロバイダーの責任となる場合があります。 したがって、この機能は、チケット内で責任の所在と次のエスカレーション手順が明確に記録されている場合に、サポートツールとして特に有用です。.

2つ目の分野は アプリケーションホスティング 代理店や開発者向け。Node.js Toolkit 2.5.0 では、有効化された Node.js アプリケーションの一元的な概要表示機能と、既存プロジェクトのワンクリック設定機能が追加されました。自動検出機能は、広く利用されている複数のサーバーフレームワークや静的フロントエンドを検出可能です。 さらに、pnpm 拡張機能は Linux 版 Plesk でのみサポートされています。これにより、繰り返し行われる個別の手順が削減されますが、個々のデプロイメントがすべてそのまま引き継げることを保証するものではありません。.

新しいPython拡張機能1.0.0もLinuxシステムに対応しており、ドメインごとのPythonサポート、仮想環境、依存関係、環境変数、および暗号化されて保存されたシークレットを提供します。 アプリケーションはPhusion Passengerを介してWSGIアプリケーションとして実行され、「Pythonサポート管理」の権限はサービスプランやサブスクリプションを通じて制御可能です。これにより、管理された料金プランの機能となる可能性がありますが、必ずしもあらゆるPythonアーキテクチャの代替となるわけではありません。.

3つ目の分野は、証明書とアシスタント機能です。SSL It! バージョン18.0.81では、前述のext-acmeおよびext-letsencrypt統合において、HTTP検証の代替手段としてDNS検証をサポートしています。これは、ポート80が開いていないドメインなどで特に重要です。 ただし、実際に管轄するゾーンにDNSレコードを設定するための適切な手段が必要であり、レコードを表示するだけでは書き込み権限は得られません。.

MCPはバージョン18.0.81ではデフォルトで無効化されており、WebProsアカウントを介して接続することができます。管理者は panel.ini MCPクライアントへの接続を許可されるユーザータイプ。したがって、その適性は機能だけでなく、ロール、アクセス権、およびログ記録にも左右されます。 プラットフォーム固有の拡張機能、外部DNSの管理範囲、および顧客アプリケーションのアーキテクチャが総合的に判断され、どの新機能がどの料金プランに含まれるかが決定されます。.

製品計画のための機能比較

製品計画においては、「Plesk Obsidian」という名称だけでは不十分です。ここで関連する機能の一部はコア製品に由来し、一部は別途バージョン管理されている拡張機能に由来するからです。そのため、プロバイダーは機能の有用性だけで評価するのではなく、OS、ライセンスモデル、技術的な依存関係をそれぞれ料金プランに盛り込む必要があります。.

この概要では、プラットフォーム機能と販売可能な料金サービスが特に明確に区別されています。DNS診断は、幅広いサポートツールとして提供可能です。一方、Pythonは、その権利管理やサポート範囲がそれに適したLinux向けサービスにのみ含まれます。 Node.js に関しては、プロバイダーはそれぞれの部分機能を区別する必要があります。pnpm は Linux 専用として文書化されていますが、変更履歴（Changelog）では、中央管理機能や自動設定について、それに応じた制限が設けられていません。.

証明書機能やMCP機能についても、グローバルな有効化ではなく、製品ごとの決定が必要となります。DNS-01では、ゾーンの管理権限が実用性を左右します。 MCPにおいては、技術的な接続はプロジェクトの一部に過ぎず、重要なのは許可された利用者の範囲、追跡可能なプロセス、および副作用を伴うアクションへの対応です。.

サポートにおけるDNS診断と証明書

Plesk Obsidian 18.0.81 で一般提供されている DNA診断 ドメインチケットの初期的な技術的評価に適しています。パネル内の「Troubleshoot DNS」をクリックすると、DNS解決、MX関連のチェック、DNSSEC、ネームサーバーの問題、およびドメインの有効期限に関する分かりやすいレポートが表示されます。 これにより事前チェックの時間を短縮できますが、権威ゾーンの分析や、レジストラや外部DNSプロバイダーとの調整に代わるものではありません。.

再現可能なファーストレベル対応プロセスを実現するためには、サポート担当者はまず、問題のメインドメインとレポートを把握し、その後、担当範囲と問題の重大度を割り当てる必要があります。例えば、レポートに誤った委任が示されている場合、その修正は多くの場合、パネルの管轄外となります。 また、文書化された制限事項も重要です。現在、このチェックではドメインエイリアスは対象外となっています。.

コマンドラインでの診断について、変更履歴には中立的なサンプルドメインを用いた以下の呼び出し方法が記載されています。実際に使用する前に、管理者は実際にインストールされているPleskのバージョンに対応するヘルプまたはコマンドリファレンスを確認する必要があります。 チェンジログに記載されている構文のみから、このコマンドが及ぼすあらゆる影響について、それ以上の保証を導き出すことはできません。.

plesk repair dns -n -j -check-resolution example.com

証明書については拡張 DNS-01の検証 利用可能な用途：SSL It! を使用すれば、Plesk Obsidian 18.0.81 において、HTTP 検証に代わる方法として、証明書の発行や更新を行うことができます。これは、ポート 80 を意図的に開放していない API ドメインやメールドメインなどで特に有用です。 Pleskは必要なDNSレコードを表示し、今後の更新に備えてドメインごとに選択された方法を保存します。.

ただし、レコードが表示されたからといって、処理が自動的に成功するわけではありません。運用者は、実際に管轄するDNSゾーンへの書き込み権限、あるいは適切に設定された自動化プロセスが必要です。 変更履歴によると、バージョン18.0.81で導入されたDNS検証機能は、SSL It!の「ext-acme」および「ext-letsencrypt」統合にのみ適用され、すべての証明書プロバイダーに一律に適用されるわけではありません。.

これとは別に、後日の拡張アップデートがあります SSL It! 1.24.0 2026年9月29日。このバージョンでは、ホスティング契約のないドメインについても、コントロールパネルまたはコマンドラインからワイルドカード証明書で保護できるようになりました。自動更新も同様にワイルドカード証明書で行われます。 この追加機能は、Plesk Obsidian 18.0.81の本来の機能範囲には含まれておらず、この拡張機能独自のバージョンおよびリリース状況に基づいています。.

管理型料金プランとしてのアプリケーションホスティング

最新の拡張機能により、アプリケーションホスティングを料金プランのオプションとしてより明確に区別できるようになりました。Node.js Toolkit 2.5.0 では、有効化された Node.js アプリケーションの一元的な概要表示機能と、既存プロジェクトのワンクリック設定機能が追加されました。 さらに、この拡張機能は、Linux版Pleskにおけるパッケージマネージャー「pnpm」をサポートしています。これにより、プロバイダーは、各顧客のアプリケーションを個別のサーバー運用として扱う必要なく、反復的なセットアップ作業を標準化することができます。.

チェンジログによると、プロジェクトの自動検出対象には、Express、Next.js、NestJS、Nuxt.jsのほか、React、Vue.js、Angular、Viteをベースとした静的フロントエンドなどが含まれます。 Pleskは、Passenger互換の起動ファイルを作成し、ハードコードされたポートを考慮に入れ、ドキュメントルートを設定することができ、変更内容は確認前に表示されます。静的フロントエンドはビルドされ、Node.jsプロセスを常時実行することなく配信されます。.

この自動化は有用ですが、アーキテクチャレビューの代わりにはなりません。複数のプロセス、ワーカーキュー、特殊なリバースプロキシ、外部シークレット、あるいは独自のビルドパイプラインなどがある場合、追加の運用ルールが必要になる可能性があります。 チェンジログによると、Linuxに関する制限はpnpmに明示的に適用されますが、中央ドメイン一覧およびワンクリック自動設定については、同チェンジログにそのようなプラットフォーム制限は記載されていません。したがって、料金プランの説明では、これらの部分機能を個別に明記する必要があります。.

Python拡張機能1.0.0では、Linux上でドメインごとに個別に制御可能な機能を提供します。お客様は、仮想環境を作成したり、インターフェースを介して依存関係をインストールしたり、pyproject.tomlのメタデータを閲覧したり、環境変数や暗号化されて保存されたシークレットを管理したりすることができます。 この機能は、サービスプランおよびサブスクリプションの「Python support management」権限を通じて利用可能になります。.

技術的には、これらのアプリケーションは WSGIアプリケーション Phusion Passenger について。Web サーバーの設定は Plesk が自動的に生成します。 したがって、例えば「Python Web App」というプランには、仮想環境、定義されたリソース枠、および従来のWSGIプロジェクトに対するサポートが含まれている場合があります。しかし、それをもって、同じプランが複雑なASGIスタック、常時稼働するワーカー、あるいはコンテナ化された特殊なアーキテクチャまでカバーしているとは限りません。.

古い機能やインターフェースの変更点を整理するには、以下の記事が参考になります Plesk Obsidian：新機能と改善点の概要 補足として参照される。新しい料金プランについては、拡張バージョン、文書化されたプラットフォームの制限、権限、および具体的にサポートされるアプリケーションの種類をまとめて文書化することが依然として重要である。.

本番環境への更新を段階的に導入する

ホスティングパネルの更新は、プロバイダー環境において、本番用メインサーバー上で最初にクリックした時点で開始されるべきではありません。まず、 インベントリー Pleskのバージョン、OSのバージョン、有効化された拡張機能、およびそれら上で稼働している顧客アプリケーションなどです。 さらに、DNSプロバイダー、メールリレー、バックアップ、独自のPHPパッケージ、デプロイメントプロセスといった外部依存関係も重要です。これにより、どのシステムが同じ状態にあるか、またどの特殊なケースを個別に扱う必要があるかが明確になります。.

その後、サーバークラスごとに依存関係を確認してください。コア製品のアップデートは、拡張機能やサードパーティ製コンポーネントのアップデートとは異なる影響を及ぼす可能性があります。また、オペレーティングシステムによって提供されるパッケージも、独自のメンテナンス対象となります。 Pleskはこれらのカテゴリを明確に区別しています。特に、サードパーティ製コンポーネントの更新は、ウェブサイトが変更されたバージョンや実行環境に対応していない場合、ウェブサイトに影響を及ぼす可能性があります。.

次に、代表的な パイロットインスタンス 任意のテストサーバーの代わりに。この環境は、典型的な料金プランの構成を反映している必要があります。例えば、一般的なCMSウェブサイト、メールドメイン、データベースの利用、および提供されている場合は、有効化されたNode.jsやPythonアプリケーションなどです。 その目的は、本番環境と完全に同一であるかのように装うことではなく、オペレーティングシステム、拡張機能、および顧客アプリケーションの関連する組み合わせを事前に可視化することにあります。.

本番環境への展開については、明確な手順を定めたメンテナンスウィンドウを設定してください。まず限定されたサーバーグループを更新し、その結果を分析した上で、その後に展開範囲を拡大してください。 その後、パネルの到達性、予定されているバックアップ、Webおよびメールサービス、証明書の更新、ならびに影響を受けるアプリケーションからのエラーメッセージを確認してください。これらの確認作業は不確実性を低減しますが、障害が発生しないことやアプリケーションの完全な互換性を保証するものではありません。.

容量計画に関して、PleskはLinux環境ではRAM 1 GBに加えスワップ領域1 GB、Windows環境ではRAM 2 GBを最低要件として挙げています。 共有ホスティングについては、ホストされている全ウェブサイトのうち、週または月単位で持続的あるいは定期的な訪問者数を記録しているものが最大10％に留まる場合、40～50サイトにつき1 GBのRAMを目安とするのが一般的です。このような 資源の目安 これらは容量の保証ではなく、自社の負荷を測定する代わりにはなりません。データベースの稼働状況、メールの送受信量、セキュリティソフトウェア、アプリケーションの種類などにより、必要量は大きく変動する可能性があります。.

エラーの原因とセキュリティ上の優先順位を特定する

繰り返し発生するエラーは、多くの場合、製品の範囲が曖昧であることが原因です。そのため、発表のたびに、具体的なコア製品バージョンまたは拡張バージョンを明記してください。 Node.js や Python の機能が、Plesk for Linux でのみドキュメント化されている場合、Windows プランについて一律に宣伝してはなりません。同様に、Passenger 経由の WSGI による Python ホスティングは、任意の ASGI、ワーカー、またはコンテナアーキテクチャのサポートを意味するものではありません。.

• DNS-01は、権威DNSゾーンへの書き込みアクセス権、または適切な自動化手段が確保されてから、料金プランの機能として計画してください。.
• Plesk、サードパーティ製コンポーネント、およびシステムパッケージの自動更新オプションを同一に設定しないでください。「Tools & Settings > Update Settings」で、各サーバーごとに実際に設定されている状態を確認してください。.
• 各製品ラインごとに、新機能の有効化前に、拡張機能、権限、およびオペレーティングシステムを確認してください。.
• MCPにおいて、ロールの承認前に、許可されるユーザーグループ、承認フロー、およびアクションのログ記録を設定します。.

仝 セキュリティの優先順位 これは、メンテナンス期間の利便性だけに基づいて決定されるものではありません。本記事の執筆時点において、2026年9月29日付けの「Plesk Obsidian 18.0.81 Update 2」が、このコアリリースラインの最新の公式パッチバージョンとなっています。 Pleskはこの件に関して重大なセキュリティ問題を指摘しており、速やかなインストールを推奨しています。9月21日のUpdate 1にも、変更履歴でLinux向けに明示されている重大なセキュリティ修正が含まれていました。したがって、LinuxシステムではUpdate 1のままで留まるべきではありません。.

また、9月の変更履歴には、2026年9月14日付けのNode.js Toolkit 2.5.0および2026年9月23日付けのSite Import 1.12.2に対する重要なセキュリティ修正が記載されています。 そのため、影響を受ける各コンポーネントがインストールされているかどうかを常に確認し、Panelコア、拡張機能、PHPパッケージ、その他のアドオンを別々のパッチ適用対象として扱うようにしてください。後に行われる拡張機能やPHPのバージョン更新は、未実施のコア製品の更新に代わるものではありません。.

MCPは限定的な 試験運用 即座に広範囲に有効化するのではなく。この機能はデフォルトで無効になっています。管理者は panel.ini どのユーザータイプがMCPクライアントに接続できるかを定義します。事前に、どのタスクをサポートするか、誰が変更を検証できるか、そして不審な操作や望ましくない操作がどのように追跡されるかを明確に定めておいてください。AIとの連携は、役割モデルや変更管理、技術レビューに取って代わるものではありません。.

警告：サードパーティ製コンポーネントは、単に新しいバージョンが利用可能になったという理由だけで、すべての顧客環境に無断で導入されるべきではありません。Pleskは、ホストされているウェブサイトとの互換性の問題が生じる可能性があると指摘しています。また、最新のドキュメントページには、当該の自動機能がデフォルトで有効になっているかどうかについて、矛盾した記述が含まれています。 したがって、サーバーごとに以下の場所を確認してください。 Tools & Settings > Update Settings 設定されたオプションに基づき、一般的な実行期間やプラグインについては、代表的なパイロットグループを対象とした段階的な公開を計画する。.

アップグレードかサーバー移行か、どちらを選ぶか

のどちらかを選ぶ。 インプレース・アップグレード また、サーバーの移行は、希望するObsidianのバージョンではなく、現状の環境から開始されます。同一サーバー上でのアップグレードを行うには、OSおよびインストール済みのPleskの初期バージョンが、予定されている移行パスに対応している必要があります。 さらに、使用中の拡張機能、独自のカスタマイズ、およびバックアップ用の空き容量も確認してください。技術的に可能な更新パスであっても、それがすべてのお客様の環境に適しているとは限りません。.

Plesk Onyx については、アップグレードに関するドキュメントに、バージョン 17.0、17.5、および 17.8 から Obsidian への直接移行方法が記載されています。 古いバージョンや、適切にサポートされていない元の環境の場合、元のバージョンが移行可能であれば、新しいObsidianサーバーへの移行が必要になることがあります。この移行により、OS、リソースのレイアウト、および拡張機能の構成を、旧システムとは別に準備することが可能になります。.

既存のオペレーティングシステムのサポート終了が迫っている場合、プラットフォームが長期間にわたり独自にカスタマイズされてきた場合、あるいは複数の大きなバージョンアップが重なっている場合は、新しいターゲットサーバーを特に慎重に検討する必要があります。Pleskのシステム要件は、その際の計画における最低限の基準に過ぎません。 目標規模を決定するにあたっては、ウェブサイトの数、メールボックス、データベース、セキュリティサービス、バックアップの保存期間、および移行後の予想負荷も同様に考慮する必要があります。.

時点では 転送によるアップグレード 既存の環境を、Plesk Obsidianがインストールされたサーバーに移行します。アップグレードのドキュメントによると、移行の前提条件として、移行先のサーバーのOSがサポート対象であること、およびインストール済みの元のバージョンがObsidianへの移行に対応していることが挙げられています。 したがって、この方法が利用可能かどうかは、計画を立てる前に具体的なソースバージョンを基に確認する必要があります。.

最新の状態を維持し、サポート対象であり、管理しやすい環境を構築するためには、資産調査とパイロット運用を経て、速やかにパッチを適用することが、多くの場合、最も妥当な方法です。 新しい拡張機能やLinux固有の機能については、的を絞ったパイロット運用を行うことが有効です。OSのサポート状況、初期バージョン、あるいは技術的な課題によって導入の道が制限される場合は、まず 移行の準備が整った となります。どのバリエーションが適切かは、サポート状況、互換性、運用モデルによって決まるものであり、一律の本番環境へのリリース決定によるものではありません。.