PHP2Shell on Synology: 1日で6つのサイトにパッチを適用した方法

PHP2Shell は、PHP エンジン自体に存在する、認証なしでリモート コードの実行を可能にする重大な欠陥である CVE-2026-109618 と CVE-2026-109619 に業界で決定した名前です。詳細は、協調開示の前日である 2026 年 10 月 20 日に漏洩し、PHP プロジェクトは 10 月 21 日に緊急リリースを出荷しました。このバグはアプリケーションではなくインタープリタに存在するため、WordPress、Joomla、または MediaWiki にパッチを適用しても何も変わりません。唯一の本当の修正方法は、新しい PHP ビルドです。私たちは Synology ハードウェア上で 6 つの公開 WordPress サイトを運用しており、PHP2Shell により、それらすべてを同じ週に再構築する必要がありました。このガイドでは、バグが実際には何であるか、パッケージ センターを介して DSM にパッチを適用する方法、サイトがコンテナで実行されている場合の対処方法、および Synology が出荷したものと他の NAS ベンダーがこれまでに管理してきたものとの間の不快な比較について説明します。

SynoPower Clubポイント：PHP2Shellの勧告が出されてから1営業日以内に、私たちの6つのサイトにパッチが適用されました。それを可能にしたのは、英雄的な行動ではなく、Synologyが勧告と同じ日に修正済みパッケージを公開したことでした。Synology-SA-26:14は10月22日に「解決済み」ステータスで公開され、PHP 7.4までの修正済みバージョンの完全な表が掲載されました。同じ日にQNAPは「修正中」ステータスでQSA-26-18を公開し、修正済みバージョンの各セルに「後日発表」と記載しました。ASUSTORは、パッチを適用するのではなく、App CentralからレガシーPHPを削除することで対応しました。NASで公開ウェブサイトをセルフホストしている場合、このギャップはマーケティング上の詳細ではありません。パッケージを更新するか、更新待ちの間サイトをインターネットから削除するかの違いです。

PHP2Shellとは何か、そしてなぜ他と異なるのか

PHP2Shellは単一のバグではなく、メモリ不足になったリクエストの後にPHPがクリーンアップする方法における、関連するメモリ安全性の欠陥の集合です。PHPは longjmp() メモリ不足などの致命的なエラーを回避するため、このジャンプは、通常であればエンジンを既知の状態に戻すクリーンアップコードをスキップします。その状態の一部はグローバルであり、同じワーカープロセスによって処理される次のリクエストにも引き継がれます。

CVE-2026-109618はメモリ不足の脆弱性です。細工されたHTTPリクエストがメモリ制限を超過する一方で、リクエストデータが部分的にしか初期化されていないため、クリーンアップルーチンが未完了の構造を走査してしまいます。CVE-2026-109619は解放後使用の脆弱性です。解放されたリクエストメモリを指すグローバル状態が残っており、同じワーカー上の後続のリクエストで読み取られる可能性があるため、このバグによってコード実行やメモリ漏洩が発生します。

PHP2Shellが通常のPHPアドバイザリよりも深刻な理由は2つあります。まず、認証前段階で発生することです。どちらの脆弱性もアプリケーションレベルの認証が実行される前に発生するため、ログインウォール、メンバーシッププラグイン、管理者パスワードなどは一切役に立ちません。次に、メモリ漏洩型の脆弱性ではワーカープロセスのメモリがリークします。WordPressサイトのPHPワーカーは、データベース認証情報、APIトークン、支払いキーなどを保持しています。読み取りが成功すれば、コード実行に至らなくても、あなたの1週間を台無しにしてしまう可能性があります。

PHP2Shellの2つのCVEは、PHPセキュリティチームによってCVSS v4.0で9.2と評価されました。Synologyは独自の勧告で、CVSS v3.1で9.8と評価しています。評価尺度は異なりますが、結論は同じです。悪用に関する報告はまちまちです。watchTowerは、ハニーポットネットワークに対する攻撃の試みを確認したと述べていますが、Bitdefenderは執筆時点でテレメトリに何も報告しておらず、QNAPは、QNAP製品を特に標的とした悪用に関する報告は受けていないと述べています。

PHP2Shellと通常のWordPressエクスプロイトの比較

公開されているWordPressサイトで発生する問題のほとんどは、プラグインの脆弱性によるものです。そのパターンはよく知られています。プラグインが欠陥のあるRESTエンドポイントを同梱し、スキャナーがそれを発見し、プラグインを更新すれば脆弱性は解消される、という流れです。PHP2Shellはこの慣習を完全に覆し、プラグインの監査という反射的な行動はここでは無駄な労力となります。

側面	典型的なプラグインのCVE	PHP2Shell
虫が住んでいる場所	アプリケーションコード（プラグインまたはテーマ）	PHPインタープリタ自体
誰がそれを引き起こせるのか	多くの場合、購読者または管理者ロールが必要です	誰もいません。認証前、アプリのロジックが実行される前に。
WordPressのアップデートは役に立ちますか？	通常はそうです	いいえ。コアとプラグインのアップデートは関係ありません。
WAFはそれを阻止しますか？	通常、ルールが存在すると	部分的にはそうです。リクエスト形状ルールではOOMパスが抜けています。
実際にそれを解決するものは何か	プラグインのアップデート	新しいPHPビルド、それ以外は何もありません。
爆発半径	1つのサイト、1つの機能	ボックス内のすべてのPHPサイトを一度に

最後の行が、PHP2Shellの作業が午後ではなく丸一日かかることになった理由です。NAS上の単一の共有PHPパッケージが、十数台のWeb Station仮想ホストの背後にある可能性があり、単一のコンテナイメージが複数のサイトのベースになっている可能性があります。パッチ適用はサイトごとではなく、ランタイムごとであり、何かが完了したと主張する前に、ランタイムを列挙する必要があります。

NASが危険にさらされているかどうかを確認する方法

PHP2Shell の脆弱性を把握するには、まず 2 つの異なる問題を区別することから始めます。そのマシンには脆弱な PHP ビルドが含まれているか、そしてそのビルドはインターネットからアクセス可能か、ということです。Synology はこの区別を明確にしています。DSM にはオペレーティングシステムで使用される内部 PHP コンポーネントが同梱されていますが、Synology では外部からアクセス可能なモジュールはなく、したがって攻撃対象領域も露出していないと述べています。このコンポーネントに対するリスクは最小限であり、脆弱性スキャンで検出されないように、パッチは後の DSM リリースで適用される予定です。

PHP2Shellにとって重要なパッケージは、PHPをWebに提供するパッケージです。Synologyには、Calendar、IDrive、Joomla、KodExplorer、MailStation、MediaWiki、phpMyAdmin、vtigerCRM、Web Station、WordPressがリストされています。これらのいずれかがインストールされていてアクセス可能な場合は、PHP2Shellの対象となります。

ダッシュボードを鵜呑みにせず、バージョンを直接確認してください。パッケージセンターでは、インストール済みのPHPパッケージのタイルにバージョンが表示され、更新通知にはターゲットビルド名が表示されます。シェルからランタイム自体に問い合わせることもできます。

# Synology PHPパッケージ（実行するバージョンに合わせてパスを調整してください）/volume1/@appstore/PHP8.2/usr/local/bin/php -v # コンテナ化されたサイト docker exec php -v

主張する理由は php -v PHP2Shellの監査を行う際に注意すべき点は、他のすべてのシグナルが嘘をついているということです。ビルド出力はキャッシュされたレイヤーを再利用しながら成功を報告する可能性があり、ダッシュボードは実行中のワーカーが最新でないにもかかわらずパッケージを最新と表示することができ、HTTPレスポンスヘッダーはCDNによって表示される前に削除される可能性があります。私たちの6つのサイトのうち2つは、パッチが適用されていないインタープリタがまだ実行されているにもかかわらず、管理画面では正常と報告されていました。

Synology 上で PHP2Shell をパッチ適用する 4 つのステップ

DSM 上の Web Station サイトの場合、PHP2Shell の修正はパッケージ センターのアップデートだけで完了します。Synology は DSM 7.4、7.3、7.2 用の PHP セキュリティ アップデートを公開しており、PHP パッケージのアップデート後、依存パッケージが自動的に再起動されるため、問題が解決します。Mail Station は例外として文書化されており、手動でアップデートする必要があります。

上記のスクリーンショットは、PHP2Shellの勧告が出された翌朝、弊社のマシンで撮影したものです。「新機能」パネルにはアップストリームのバージョンが直接表示されているため、SynologyのビルドサフィックスとPHPのリリースを推測することなく照合できます。Synology Calendarは、同じアップデートリストに3.0.4-21435として表示されており、これは勧告で推奨されているバージョンと全く同じです。

Web Stationユーザーにとって注意すべきPHP2Shellの落とし穴が1つあります。DSMマシンには複数のPHPブランチが同時にインストールされることがあり、各仮想ホストは1つのプロファイルにバインドされます。デフォルトプロファイルを更新しても、別のブランチに固定されているサイトには効果がありません。まずプロファイルを列挙し、すべてを更新してから、Web Service配下の各サイトのバインドを確認してください。

影響を受けるDSMパッケージはどれですか？

PHP2Shell の Synology ステートメントは、想定されていたパニックよりも範囲が狭いものです。影響を受けるのは特定の PHP 依存パッケージを実行しているシステムのみであり、Synology Drive は明示的にその対象には含まれていません。IDrive は対象リストに含まれていますが、サードパーティ製ソフトウェアです。

• ウェブに公開されており、最優先事項です。 Web Station、WordPress、Joomla、MediaWiki、vtigerCRM、KodExplorer、phpMyAdmin。これらは、アクセスできる人なら誰でもPHPを利用できる環境を提供している。
• メールとカレンダー。 Mail StationはPHPパッケージのアップデート後に手動でアップデートする必要があります。Synology Calendarは独自の修正ビルド3.0.4-21435で提供されています。
• DSMの内部コンポーネント。 存在するが外部からはアクセスできない。パッチは後のDSMリリースに延期。Synologyによりリスクは最小限と評価されている。
• 容器は覆われていません。 Container Manager 内の PHP ランタイムは、ユーザー自身がパッチを適用できます。パッケージのアップデートでは変更されないため、NAS の所有者が作業完了だと思い込んでしまう最も一般的な理由の一つとなっています。

DSM 7.2 より前のバージョンを使用している場合は、パッチ適用済みのバージョンが利用可能になるまで、影響を受けるパッケージを一時的に無効にすることをお勧めします。なお、DSM 7.2 自体は、PHP のアップデートが適用されているにもかかわらず、サポート終了として記載されています。

PHP2Shellにとって最も厄介なケースは、PHP 7.3以前のバージョンです。Synologyはサポート終了ブランチであるため、7.3の修正は行われません。また、アップストリームは7.3以前のバージョン向けに何も公開していません。Linuxディストリビューションは一部の古いストリーム向けにバックポートを提供していますが、Synology PHPパッケージはディストリビューションパッケージではありません。サイトが7.3または5.6で動作する必要がある場合、パッチは提供されないため、現実的な選択肢は、サイトをサポート対象ブランチに移行するか、WAFの背後に置くか、パブリックインターネットから削除することです。

コンテナサイトのオーナーはPHP2Shellをどのように扱うか

弊社の6つのサイトのうち5つは、Web StationではなくDocker上でWordPressを実行しています。そして、まさにこの点でPHP2Shellが興味深い存在となります。なぜなら、パッケージセンターでは対応できないからです。ランタイムはイメージに含まれるものに依存し、イメージの再構築は更新とは異なります。

PHP2Shell で最初に遭遇した、そしておそらく他の人も遭遇するであろう障害は、カスタム イメージの再構築でキャッシュされたベース レイヤーが再利用されることです。 から タグが付いているからといって、必ずしも最新とは限りません。私たちのイメージの1つは4日前に再構築されたばかりでしたが、2025年7月のPHPビルドがまだ含まれており、セキュリティ修正が1年以上も遅れていました。これは、Dockerがベースイメージを再取得する必要がなかったためです。

# 間違い: ローカルにキャッシュされているベースレイヤーを暗黙的に再利用します docker build -t mysite . # 正しい: ベースイメージを常に再プルします docker build --pull -t mysite . # 次に、休止状態の兄弟プロセスを起動せずに、目的のサービスのみを起動します docker compose up -d --no-deps wordpress # そして、実際に重要なことを検証します docker exec wordpress php -v

2回目のPHP2Shellの失敗は、成功を報告するため、より厄介です。ビルド出力をパイプで通過させます。 しっぽ パイプラインの終了コードはパイプライン内の最後のコマンドに属し、ビルドの失敗を隠蔽します。 set -e 決して実行されません。その後、compose ステップが古いイメージからコンテナを再作成し、「Started」と表示して、パッチが適用されていない、新しくデプロイされたように見えるサイトから離れます。ビルド結果を単独で確認し、以下で検証します。 php -v その後。

2点ほど補足事項があります。再構築する前に古いイメージにタグを付けてください。イメージはタグを保持し、スナップショットよりもはるかに安価なロールバックポイントを無料で提供します。また、イメージを更新してもアプリケーションがアップグレードされるとは限りません。公式のWordPressイメージのエントリポイントは、ドキュメントルートが空の場合にのみコアファイルをコピーするため、新しいイメージ上にコンテナを再作成しても、既存のインストールはそのまま残ります。本番環境に適用する前にステージング環境で確認しましたが、WordPressのバージョンは変更されませんでした。

session.upload_progressを無効にしても半分しか解決しない理由

パッチを適用できないマシン向けに流布している PHP2Shell の緩和策は、 session.upload_progress.enabled = 0また、Web Stationのスクリプト言語設定にあるDSMのPHPプロファイルのコアタブで設定できます。これは行う価値があります。根本的な解決策ではありませんが、このギャップは重要です。

セッションのアップロード進行状況パスは、侵入経路の 1 つにすぎません。メモリ漏洩のバリアントは、通常のマルチパートリクエスト処理を通じて到達可能であり、セッション機能は全く必要ないため、この機能をオフにすると、その経路が開いたままになります。PHP プロジェクトは、完全な緩和策はなく、アップデートが唯一安全な解決策であると直接述べています。Imunify360 は、現在 CVE-2026-109618 のメモリ不足パスをブロックするルールはないと報告しており、Elastic は、upload-progress 設定によって確認済みのセッションパスは閉じられますが、すべてのバリアントが閉じられるわけではないと指摘しています。

また、 メモリ制限 = -1 メモリ不足が原因でバグが発生するという論理に基づき、この解決策が提案されました。これはメリットではなくデメリットとして捉えるべきです。公開Webサーバーで制限を解除すると、障害モードが1つから別のモードに置き換わるだけであり、共有メモリ予算を持つNASでは、ワーカープールがマシン全体のメモリを使い果たしてしまうことになります。

エッジフィルタリングは、PHP2Shell のレイヤーの中で真に効果を発揮する部分です。なぜなら、ルーターでは見ることのできない復号化されたトラフィックをエッジフィルタリングが監視できるからです。Cloudflare は PHP2Shell 用のマネージドルール保護を展開しており、AWS は PHP マネージドルールグループのバージョン 2.3 で CVE-2026-109619 の対策を追加し、Azure Front Door はデフォルトで無効になっているルール 99006001 をリリースしました。GitHub にはコミュニティの Snort および Suricata ルールが存在しますが、執筆時点では公式の Snort および Emerging Threats ルールセットは公開されていなかったため、NAS の侵入防止機能はここでは役に立ちません。いずれにせよ、TLS の内部を読み取ることはできません。

実際に修正プログラムを出荷したNASベンダーはどれか

これは、PHP2Shell に関する話の中で、購入の判断材料となる部分です。PHP のアップストリームは 10 月 21 日にリリースされました。翌日、主要な消費者向けおよびプロシューマー向け NAS ベンダー 4 社がどのような状況にあったかを以下に示します。これは、報道記事ではなく、各社のアドバイザリ ページから抜粋したものです。

ベンダー	勧告	状態	修正版が公開されました
シノロジー	Synology-SA-26:14、2026年10月22日	解決済み	はい。PHP 7.4から8.4までのすべてのブランチに加え、カレンダーとメールステーションも含まれています。
QNAP	QSA-26-18、2026年10月22日	修正	いいえ。すべての行に「後日発表」と書かれています。
ASUSTOR	PHPの旧バージョンは2026年10月22日にサポート終了となります。	引退、パッチではない	いいえ。PHP 7、7.3、7.4、8.1はApp Centralから削除されました。
Uグリーン	見つかりませんでした	未知	UGOS Proに関する勧告は見つかりませんでした。

Synologyは、勧告と同日にPHP2Shellの完全なバージョン一覧表を公開し、勧告を解決済みとしました。DSMの所有者は、その日の午後にパッケージセンターを開き、「更新」をクリックして検証するだけで済みました。これが修復手順のすべてであり、Web Stationマシンが数日ではなく数分で復旧できた理由です。

QNAPは同日に、QTS 6.1.0、QTS 5.2.11以前、QuTS hero h6.1.0、h6.0.x、h5.2.11以前、QuTScloud c5.2.9以前、Note Station 3、QNE ADRA、ARM32モデルのQVR Surveillance、TVR OSなど、影響を受ける製品群を多数掲載した。これらの製品はすべて「修正中」と表示され、修正バージョンは指定されていない。PHPランタイムはQTSウェブコンポーネントの一部であるため、更新するパッケージはなく、ファームウェアによる修正が必要となる。

QNAPがPHP2Shellの被害者向けに提供しているのは、その対策リストです。このリストには、ルーターのポートフォワーディングとUPnPの無効化、myQNAPcloudサービスの非公開化、リモートアクセスをVPN経由で行う、管理ポートを信頼できるサブネットに制限する、不要なPHPベースのアプリケーションを停止する、使用していない場合は内蔵Webサーバーを無効にする、QuLog Centerを監査して侵害の兆候がないか確認する、といった内容が含まれているため、注意深く読む価値があります。これは、パッチが適用されていないマシンにとっては適切なアドバイスです。しかし、公開Webサイトをホストしている人にとっては、Webサイトを停止するよう求めるものでもあります。

ASUSTORは3つ目の方法をとった。10月22日付の「レガシーPHP廃止のお知らせ」と題された通知では、PHP 7、PHP 7.3、PHP 7.4、PHP 8.1をApp Centralから即時削除し、重要なデータのバックアップを推奨し、今後はPHP 8.3または8.4のみを使用するようユーザーに伝えている。アップストリームでは8.2以降にしかパッチが適用されないため、この理由は正当化できる。古いPHPアプリケーションを実行しているユーザーへの影響は、ランタイムが修正されるのではなくストアから消えることであり、ASUSTORは8.3または8.4のパッチ適用済みビルドが出荷されたとは述べていない。ここで注目すべきは、ASUSTORが移行を求めているまさにそのユーザー向けに、7.4.33-0131で修正済みの7.4ビルドを公開したSynologyとの対比である。

UGREEN社に関しては、UGOS Proに関するPHP2Shellのアドバイザリを一切見つけることができませんでした。公式発表がないからといって、製品に脆弱性があるとは限りませんし、UGOS Proにはウェブ向けのPHPランタイムが搭載されていない可能性もあります。しかし、もしあなたが製品の所有者であれば、沈黙は有効な対応策とはなり得ず、それ自体が一種の脆弱性と言えるでしょう。

こうした点を踏まえても、Synologyが完璧というわけではありません。PHP 7.3の脆弱性は修正されず、DSM 7.2はサポート終了と表示され、内部のPHPコンポーネントもパッチ適用ではなく、スケジュールされたままになっています。重要なのは、ブランド論争よりももっと狭く、より実用的な点です。PHPエンジンに事前認証によるリモートコード実行の脆弱性が発見された日、あるベンダーはパッケージセンターに修正ボタンを設置したのに対し、他のベンダーはただ待つしかない状況に追い込んだのです。

その他の公式資料の入手先

PHP2Shellは執筆時点でリリースから2日しか経っておらず、状況は刻々と変化しているため、概要ではなく一次情報源を参照してください。ベンダー各社からの公式動画はまだ公開されていないため、以下のリストはチュートリアルではなくドキュメントとして掲載しています。

• Synology-SA-26:14 は公式のバージョン表です。アドバイザリは改訂される可能性があるため、パッチを適用する前に再度確認してください。
• Synology PSIRT声明 影響を受けるパッケージの一覧を示し、DSMの内部コンポーネントとメールステーションの例外について説明します。
• 上流のGitHubアドバイザリGHSA-w8hw-w9fx-j79wとGHSA-6wmf-4rv5-p3rpは、Synologyアドバイザリからリンクされており、ベンダーのパッケージではなくエンジンの動作について説明しています。
• QNAP QSA-26-18 QTSまたはQuTS Heroを実行すると、ここに修正済みのファームウェアバージョンが表示されます。これはニュース記事ではなく、注目すべきページです。
• インストールされているものについては、パッケージ センターが最終的な判断を下します。アドバイザリはターゲット ビルドを示し、タイルは実際にインストールされているものを示し、 php -v 何が実行されているかを示します。

Synology仮想マシン上で公開サイトを実行することの背景については、次のチュートリアルを参照してください。 VDSMゲスト間でDockerスタックを移動する 本書では、今回の緊急事態を乗り切ることができたスナップショットとロールバックの習慣について解説する。

PHP2Shellの制限事項とセキュリティに関する注意事項

PHP2Shellへのパッチ適用はDSMでは簡単ですが、それ以外の環境では複雑なので、作業完了を宣言する前にいくつかの制限事項を明確に述べておく価値があります。

PHP2Shellパッケージのアップデートはサイト監査ではありません。PHPをアップデートすればその時点から脆弱性は解消されますが、10月20日から22日の間にインターネットからアクセス可能だった場合、有効なエクスプロイトが公開されていた期間にアクセス可能だったことになります。ログで予期しないPOSTリクエスト量を確認し、書き込み可能なディレクトリに出現したファイルを探し、PHPワーカーが保持していた可能性のある認証情報をローテーションしてください。メモリ漏洩型の脆弱性の場合、認証情報のローテーションは過剰な心配ではなく、合理的な予防策となります。

PHP2Shellの検証は、実行中のインタープリタを対象とする必要があります。ダッシュボード、ビルドログ、レスポンスヘッダーはすべて、このラウンドで少なくとも1回は失敗しました。CDNはバージョンを示すヘッダーを削除する可能性があり、ビルドはキャッシュされたレイヤーを再利用しながら成功を報告する可能性があり、パッケージタイルは古いワーカーがまだサービスを提供しているにもかかわらず、現在のバージョンを表示する可能性があります。 php -v リクエストを処理する内部で、それが解決される。

コンテナは、どのベンダーのPHP2Shellアドバイザリにも記載されていません。これはNASにおける最も一般的な誤った安心感の原因であるため、改めて強調しておきます。サイトがコンテナマネージャーで動作している場合、パッケージセンターがすべてを最新の状態と報告しても、サイトの状態については何も分かりません。これは、独自のランタイムをバンドルしているサードパーティ製アプリケーションにも同様に当てはまります。

設定による緩和策は、設計上、部分的なものです。セッションアップロードの進行状況を無効にすることは有効ですが、メモリ制限を解除すると、あるリスクが別のリスクに置き換わることになります。また、ルーターの侵入防止機能では、他の場所で終端するTLSトラフィックを検査することはできません。これらはすべて、本格的なパッチを適用するまでの時間稼ぎとして捉え、パッチの代替手段として考えないでください。

サポート終了となったランタイムには、PHP2Shell パスが一切存在しません。PHP 7.3 以前のバージョンは、アップストリームからも Synology からも何もサポートを受けていません。サイトがどうしてもサポート対象外のブランチを必要とする場合、選択肢は移行、隔離、またはパブリックインターネットからの撤退のいずれかです。他に選択肢はなく、そうでないふりをすると、レガシーサイトが同じマシン上の他のすべてのシステムへの入り口となってしまいます。

最後に、ニュースサイクルよりもアドバイザリに注目してください。SynologyはSA-26:14を解決済みとマークし、公開後6分以内に一度改訂しました。QNAPは、修正版が利用可能になり次第、QSA-26-18を更新すると述べています。これらのページは両方とも変更され、この記事のバージョン番号は2026年10月22日に公開されたものです。

参考文献

• Synology-SA-26:14 PHP2Shell セキュリティ アドバイザリ2026年10月22日に公開、ステータスは解決済み、PHP 7.4から8.4までの修正バージョンが含まれています。
• SynologyによるPHP2Shellの脆弱性に関する声明PSIRTのメモには、影響を受けるパッケージとDSMの適用範囲が記載されています。
• QNAP QSA-26-18ステータス：修正中、修正済みバージョンを含む対象製品一覧は後日発表。
• ASUSTOR レガシーPHPサポート終了のお知らせApp Central から PHP 7、7.3、7.4、および 8.1 を削除します。
• PHP2Shellのアップストリームリリースに関するNet Securityへの支援PHP 8.5.12、8.4.27、8.3.36、8.2.35、およびそれ以前のブランチのソースのみのバックポートを対象としています。

よくある質問