ホーム › ブログ › 首相が自身のサイトを止めた夜、当事務所も止めた――PHP重大脆弱性への即応と、サイト全面移行の記録

首相が自身のサイトを止めた夜、当事務所も止めた――PHP重大脆弱性への即応と、サイト全面移行の記録

· English version

このサイトは、いまご覧になっている時点で、ひとつ前の記事を書いたときとは別の仕組みで動いています。 2026年10月21日の夜に公表されたプログラミング言語PHPの重大脆弱性をきっかけに、当事務所のウェブサイトを当夜のうちに遮断し、翌22日の夕方までに、サーバーもPHPも使わない新しい仕組みへ全面的に移し替えました。

たとえて言えば、これまでのサイトは、ページを開くたびにサーバーの中で「配管」（PHPというプログラム）が動いて水を引いてくる仕組みでした。配管があれば、配管の欠陥が問題になります。新しいサイトは、あらかじめ出来上がったページをそのまま置いておくだけの、配管のない仕組みです。欠陥の生じようがない部分だけを残した、と言ってもよいでしょう。

本稿では、何が起きたのか、当事務所が何をどの順番で行ったのか、そしてなぜ弁護士がこの種の事案に自ら即応できなければならないと考えるのかを記します。

何が起きたのか

PHPは、世界中のウェブサイトの土台として使われているプログラミング言語です。多くの企業サイトやブログを支えているWordPressもPHPで動いています。

2026年10月20日（協定世界時）、PHPの開発元が「CVSS 9.2（最高評価に近い深刻度）」の脆弱性2件を修正するセキュリティリリースを予告し、日本時間10月21日23時に修正版が公開されました。認証なしに外部から任意のコードを実行できる、いわゆるリモートコード実行（RCE）の脆弱性で、通称「php2shell」と呼ばれています。

異例だったのは、公開前の段階から各国当局が一斉に動いたことです。EUのCERT-EU、英国のNCSC、オーストラリアのACSCが注意喚起を出し、日本でも情報処理推進機構（IPA）が10月21日に「事前準備のお願い」を公表し、国家サイバー統括室も修正版の速やかな適用準備を呼びかけました。国家サイバー統括室は、すぐに修正できない場合には「ウェブサイトの一時停止」も有効なリスク低減策であるとしています。

実際に、厚生労働省のシステム、大学、鉄道会社、ECプラットフォーム、ゲーム会社など、国内の多数の組織が10月21日のうちにサイトやサービスを停止しました。そして高市早苗内閣総理大臣も、自身のホームページを10月21日夜から停止し、「各社ウェブサイト大丈夫でしたか？うちは遮断しました」と呼びかけました。自民党の政調会長も、WordPressを使っていることを理由にホームページを即刻停止したと公表しています。

一国の総理大臣が自分のサイトを止める。それほどの事案でした。

そして翌22日午後には、最高裁判所が裁判所ホームページの機能（司法統計、裁判例検索など）を同日午前から一部停止したことが報じられました。弁護士が日常的に使う裁判例検索まで止まったのです。幸い、民事裁判書類電子提出システム「mints」には影響がなく、裁判手続自体に支障は出ていないとされています。当事務所にとっては、この報道が流れた時点で、すでに前夜の遮断を終え、新サイトへの切替の最終段階に入っていました。

当事務所が行ったこと（時系列）

当事務所のサイトも、ほかの多くの事務所と同じく、レンタルサーバー上のWordPress、すなわちPHPで動いていました。

10月21日（火）夜 IPAと国家サイバー統括室の呼びかけ、そして修正版公開の情報を把握した時点で、当事務所が管理する4つのドメインすべてについて、外部からのアクセスを遮断しました。修正版が自分のサーバーに適用されたことを確認できるまでは、止めておくのが唯一確実な対処だからです。

10月22日（水）午前 サーバー事業者側で修正版が適用されたかを確認しようとしましたが、事業者の管理画面は全国からのアクセスで混雑し、ほとんど操作できない状態でした。管理画面に表示されるバージョン情報も画面ごとに食い違いました。そこで管理画面を介さずにサーバーへ直接接続する手段に切り替え、WordPressの内部情報から実際に動いているPHPのバージョンを確認したところ、修正版には達していないことが判明しました。遮断の継続を決めました。

併せて、遮断前に侵入された痕跡がないかを点検しました。サーバー上のファイルの更新日時、管理者アカウント、導入済みプラグインをひとつずつ確認し、異常がないことを確かめました。

10月22日（水）昼〜夕方 ここで判断を変えました。「修正版が来るのを待って復旧する」のではなく、そもそもPHPを使わない仕組みに乗り換えることにしたのです。

事務所のサイトは、事務所案内と、このようなコラムで構成されています。問い合わせフォーム以外に動的な処理は必要ありません。それならば、サーバー上でプログラム（配管）を動かすのをやめ、あらかじめ生成した静的なページだけを配信する方式にすれば、「サーバー側にパッチを当てなければならないプログラム」そのものがなくなります。これが、冒頭で述べた「動的なサイトから静的なサイトへ」の意味です。今回のような事案が再び起きても、止める必要がなくなるのです。

旧サイトの記事と固定ページをすべて書き出し、新しい仕組みに合わせて変換し、画像を移し、旧URLから新URLへの転送を設定し、問い合わせフォームを別途組み直し、ドメインの向き先を切り替える。この一連の作業を、AIを使いながら進め、10月22日15時台にドメインの切替を完了、16時過ぎには新サイトが稼働しました。

旧サーバーのWordPressは復旧させず、遮断したままにしています。修正版が入ったかどうかは、もう当事務所にとって問題ではなくなりました。

「待つ」のではなく「構造を変える」

今回の対応で意識したのは、二段階の判断です。

第一段階は即時の遮断です。事案の深刻度が明らかで、自分の側で確実な対処（修正版の適用）ができない以上、止めるしかない。これは迷う余地のない判断で、総理大臣が自身のサイトについて下した判断とも同じです。

第二段階は構造の見直しです。止めたあとに「いつ戻せるか」だけを考えるのは受け身です。そもそも、なぜ事務所のサイトが外部事業者の修正を待たなければ安全にならない構造になっているのか。そこを問い直し、依存を断つ方向に動く。この第二段階まで一日で踏み切れたのは、AIによってサイト再構築の作業量が桁違いに圧縮されたからにほかなりません。

弁護士にとっての「情報感度」

ここからが本稿で本当に書きたかったことです。

当事務所は、不動産取引、企業法務、民事訴訟、国際家事、労働問題、製品安全といった分野を扱っています。これらはいずれも、依頼者の皆様の権利関係が、日々、外部環境の変化によって揺さぶられる領域です。法改正、判例の変化、取引相手の状況の変化、そして今回のような技術的な事案。侵害は、こちらの準備が整うのを待ってはくれません。

依頼者の権利を守るために必要なのは、法律の知識だけではありません。世の中で何が起きているかを即座に把握し、それが依頼者にどう影響するかを見極め、その日のうちに動くという感度と行動力です。今回、私は自分の事務所のサイトについてそれを実践しました。自分の足元でできないことを、依頼者の案件でできるはずがないと考えるからです。

そして、この「即座に動く」ための道具として、AIを日常業務に組み込んでいることが決定的に効きました。前回の記事で、AIは究極の「イソ弁」であり、単位時間当たりの思考密度を上げる道具だと書きました。今回はそれが、一晩と一日のうちにサイトを遮断し、点検し、再構築し、移行するという形で現れました。人の手だけでやっていたら、週単位の作業だったはずです。

もちろん、弁護士の本業はサイトの構築ではありません。しかし、新しい事案に対して「まず自分で把握し、自分で判断し、自分で手を動かして確かめる」という姿勢は、本業そのものです。依頼者の皆様には、そのような姿勢で案件に向き合う弁護士を選んでいただきたいと思っています。

皆様へのお願い

最後に、実務的なお願いを一つ。

ご自身や会社のウェブサイトがWordPressなど、PHPで動く仕組みを使っている場合、管理を委託している事業者に対し、「PHPの修正版（8.2.35 / 8.3.36 / 8.4.27 / 8.5.12以降）が適用されているか」を確認してください。PHP 8.1以前はサポートが終了しており、修正版は提供されません。確認が取れるまでは、サイトを一時停止することも、国家サイバー統括室が示すとおり有効な対処です。

もしウェブサイトやシステムの不具合をめぐって、委託先や取引先との間で責任の問題が生じた場合には、技術的な経過を踏まえて法的に整理する必要があります。そのようなご相談も承っています。

同業者向け技術メモ：当事務所が実際に行った措置

ここから先は、同じようにWordPressで事務所サイトを運用している弁護士・士業の方向けの覚え書きです。専門用語が続きますが、この節をそのままAI（Claude、ChatGPTなど）に読ませて「同じことをしたい」と指示すれば、おおむね再現できる程度に具体的に書いておきます。

1. 緊急遮断（10月21日夜）

  • WordPressのルートディレクトリにある .htaccess の先頭に Require all denied を1行追加し、全ドメインを一括で403（アクセス拒否）にした。PHPを実行させないことが目的なので、WordPress側の設定ではなくサーバー側で止める。
  • その後、作業用に自分の固定IPアドレスだけを Require ip（自分のIPアドレス） で許可し、他は拒否のままにした。
  • 対象は、事務所の主ドメイン（日本語・英語）と旧ドメイン2つの計4ドメイン。

2. 事業者側の修正適用の確認（10月22日午前）

  • レンタルサーバーの管理画面はアクセス集中で機能せず、表示されるPHPバージョンも画面ごとに食い違ったため、信用しないことにした。
  • FTP（FTPS）アカウントを作成し、FTPクライアント（Cyberduck）でサーバーへ直接接続する体制に切り替えた。管理画面経由の設定保存が反映されない状況でも、.htaccess を直接編集できる。
  • 実際に動いているPHPのバージョンは、WordPress管理画面の「ツール → サイトヘルス → 情報 → サーバー → PHPバージョン」で確認した。ここが唯一信頼できる表示だった。確認結果は修正版（8.3.36）未満。

3. 侵入痕跡の点検

  • 公開ディレクトリ直下の不審ファイルの有無、wp-config.php と index.php の更新日時（手付かずであること）、管理者ユーザーの一覧（想定外のアカウントがないこと）、導入プラグインの一覧（正規のものだけであること）を確認した。
  • 併せて、WordPressの管理者メールアドレスの設定誤りが見つかったので、移行時に是正した。

4. 移行の材料の書き出し

  • WordPressの「ツール → エクスポート」でWXR形式（XML）を日本語・英語の両サイト分書き出した。
  • テーマ側で組まれていてWXRに含まれないページ（トップ、取扱分野）は、表示テキストを別途保存した。
  • 画像・PDFは wp-content/uploads をFTPで丸ごと取得した。

5. 新サイトの構築（静的サイト生成）

  • 静的サイトジェネレーター Astro を採用。記事・固定ページはMarkdownファイルとして src/content/ 配下に置き、ビルド時にHTMLを生成する。サーバー側で動くプログラムはない。
  • WXRからMarkdownへの変換は、AIに短いPythonスクリプトを書かせて一括で行った（記事本文、日付、旧URLの記録、画像パスの置換）。
  • 旧URL（?p=105 や ?page_id=72 といったWordPress形式）から新URLへの対応表を作り、301リダイレクトとして実装した。検索エンジンの評価とリンク切れ対策のためで、ここは省略しないほうがよい。
  • 構造化データ（LegalService / Person / BlogPosting）、日英のhreflang、OGP、sitemap、RSSを標準装備した。
  • AIクローラーへの方針（検索・回答用は許可、学習用は拒否）を robots.txt と llms.txt に明記した。

6. ホスティングと公開の仕組み

  • ソース一式を GitHub の非公開リポジトリに置き、Cloudflare Pages をリポジトリに接続した。main ブランチに変更が入ると自動でビルド・公開される（1〜2分）。記事を1本追加するには、Markdownファイルを1つアップロードするだけでよい。
  • 費用は無料枠の範囲。サーバーの契約・保守・PHPのバージョン管理という概念そのものがなくなる。
  • GitHub・Cloudflare のアカウントは、パスワードではなく物理セキュリティキー（YubiKey）によるパスキーで保護した。

7. 問い合わせフォーム

  • 唯一の動的処理である問い合わせフォームは、Cloudflare Pages Functions（サーバーレス関数）で受け、メール送信API（Resend）経由で事務所のメールアドレスへ転送する構成にした。送信ドメイン認証（DKIM）を設定し、Reply-To に相談者のアドレスを入れて返信できるようにした。
  • スパム対策は Cloudflare Turnstile（CAPTCHAの代替）とハニーポットの併用。
  • この関数はPHPではなくTypeScriptで、Cloudflare側が実行基盤を管理するため、自分でパッチを当てる対象ではない。

8. DNSの切替（10月22日15時台）

  • ドメイン登録事業者側でネームサーバーを Cloudflare に変更。Cloudflare が既存のDNSレコード（MX、SPF、DKIM、DMARC）を自動で取り込むので、メールには一切影響しない。
  • サイト用の A レコードを CNAME → ○○.pages.dev に置き換え、HTTPS証明書は Cloudflare が自動発行。
  • 旧ネームサーバー側のゾーンにも同じ向き先を書いておき、DNSキャッシュが残る経路からも新サイトに到達するようにした。
  • 旧ドメイン2つは、サイトを置かず Cloudflare の Redirect Rules で主ドメインへ301転送した。

9. 旧サーバーの扱い

  • 旧サーバーのWordPressは復旧させず、遮断したまま。しばらく様子を見て解約する。解約前に、SPFレコードから旧サーバーの送信許可（include: の該当部分）を外す。

所要時間と役割分担

  • 私自身の実働は、各サービスのアカウント作成、GitHubへのファイルアップロード、DNS切替の操作、新旧サイトの見比べで、合計2時間前後。残りの設計・変換・実装・検証はAIとの対話で進めた。
  • 一人事務所で、ITの専任担当がいなくても、この規模のサイトなら一日で移行できるというのが今回の実感です。

参考情報（公式発表・報道）

← ブログ一覧へ戻る