第１ 本記事の対象と結論
１ 対象と基準日
ウェブサイトやサーバーが外部から乗っ取られ，他の組織への攻撃の中継地点として使われることがある。
このように，攻撃者が自分の身元を隠すために他人の機器を経由させることを，一般に「踏み台」という。
令和８年１０月には，PHP，Node.js，Java及びGitLabで深刻度の高い脆弱性の修正が相次いで公表された。
本記事は，自社のサーバーが踏み台にされ，その結果として他社に損害が生じた場合に，サーバーの管理者が被害を受けた他社に対して損害賠償責任を負うかを，民法の条文，裁判例及び公的機関の資料から整理するものである。
基準日は令和８年１０月２５日である。
条文はe-Gov法令検索で現行の版を確認し，裁判例は判例秘書で本文を確認するとともに，裁判所ウェブサイトの裁判例検索で掲載の有無を調べた。
２ 結論
①踏み台にされたサーバーの管理者が被害を受けた他社に負う責任は，契約関係がなければ，主に民法７０９条の不法行為の問題であり，乗っ取られたという事実だけで責任が決まるわけではない。
②責任が問われるのは，管理者に過失がある場合であり，後記の裁判例のように，被害を受けた側が，管理者の採るべきだった具体的な対策と，その対策を怠ったことと損害との因果関係を主張・立証することになる。
③東京地裁令和３年３月１０日判決は，インターネット上に拡散されていた学生のＩＤ等を使って第三者がログインし，掲示板に原告の名誉を毀損するとされる記事を投稿した事案で，内部のセキュリティポリシーの違反は直ちに第三者に対する不法行為上の義務違反にならないとし，管理者の責任を否定した。
④本記事の基準日までに裁判所ウェブサイトと判例秘書で確認した範囲では，踏み台にされたサーバーの管理者に第三者への損害賠償責任を認めた裁判例は見当たらない。
⑤もっとも，国の資料は，取引先等の対策が不十分であると，そこを踏み台にして自社が攻撃され，その結果，他社の二次被害を誘発して加害者となるおそれがあると指摘しており，令和８年１０月１日からは，一定の要件の下で，警察が攻撃に使われているサーバーの管理者に措置を命じ，又は自ら措置をとって通知する制度も始まっている。
⑥管理者としては，更新と監視を続けること，社内規程と委託契約で役割を決めておくこと，ログを残しておくことが，被害を防ぐとともに，後に責任を問われたときの説明の材料にもなる。
第２ 踏み台にされるとはどういうことか
１ 乗っ取られたサーバーの使われ方
攻撃者は，脆弱性を突いたり，流出したＩＤとパスワードを使ったりして，他人のサーバーに侵入する。
侵入したサーバーは，そのサーバーの情報を盗む目的だけでなく，別の組織への攻撃の中継やコンピュータウイルスの配布のために使われることがある。
攻撃を受けた側から見ると，攻撃の通信は乗っ取られたサーバーから来ているので，そのサーバーの管理者が加害者のように見える。
２ 公的機関の資料の記載
情報処理推進機構（IPA）は，令和６年７月５日の注意喚起「PHPの脆弱性（CVE-2024-4577）を狙う攻撃について」で，国内の複数の組織のウェブサービスに不正な操作を行うプログラムが設置されていたとの指摘を紹介し，そこから組織内への侵入が試みられたり，他の組織への攻撃の踏み台として使われたりするおそれを説明している。
この注意喚起の対象は，Windows上で動作するPHPであり，踏み台の説明も攻撃の手口一般の説明である。
経済産業省とIPAの「サイバーセキュリティ経営ガイドライン Ver3.0」は，指示９の「対策を怠った場合のシナリオ」で，取引先等の対策が不十分であると，「これらの企業を踏み台にして自社が攻撃されることもある。その結果、他社の２次被害を誘発し、加害者となるおそれもある」としている。
国家サイバー統括室の「サイバーセキュリティ関係法令Q&Aハンドブック」Ver3.0のQ53も，サプライチェーンのリスクとして，他社の二次被害を誘発して加害者となるおそれを挙げている（２９６頁）。
いずれも，企業が想定すべきリスクの説明であり，踏み台にされた企業が法的にどのような要件で損害賠償責任を負うかを述べたものではない。
IPAの「ウェブサイト運営者のための脆弱性対応ガイド」（第３版第２刷，平成２９年３月）も，運営者が利用者から訴訟の対象とされ得ることや，サイトを止めたことで取引先から契約により損害賠償を求められ得ることを説明する一方，コンピュータウイルスを撒き散らす「加害者」となった場合については，社会的責任を果たしていないと非難されるとするにとどまる（５頁）。
第３ 被害を受けた他社への不法行為責任の枠組み
１ 民法７０９条
民法７０９条は，「故意又は過失によって他人の権利又は法律上保護される利益を侵害した者は、これによって生じた損害を賠償する責任を負う。」と定めている。
踏み台にされた管理者について故意が問題となることは通常なく，過失の有無が中心になる。
２ 過失の中身
過失があるといえるには，管理者が，自分のサーバーが攻撃に使われることを予見でき，それを避ける措置を採るべきであったのに採らなかったことが必要である。
後記の東京地裁令和３年３月１０日判決は，被害を受けた側に，採るべきであった具体的な対応手段と，その手段が技術的・経済的に見てある程度容易に導入できるほど一般に普及していたことの主張・立証を求めた。
例えば，修正版が広く公表され，国や専門機関が更新を強く求めていた脆弱性を，長い間放置していた場合と，修正版が出た直後に攻撃を受けた場合とでは，過失の評価が異なり得る。
３ 因果関係と損害
過失が認められても，その過失と他社の損害との間に因果関係がなければ，賠償責任は生じない。
攻撃者は，あるサーバーが使えなければ別のサーバーを使うこともあり得るので，特定のサーバーの管理者の過失がなければ損害が生じなかったといえるかは，事案ごとに判断される。
被害を受けた側は，攻撃の通信がどのサーバーから来たかを示す記録と，そのサーバーが乗っ取られた経緯の両方を明らかにする必要があると考えられる。
４ 契約関係がある相手との違い
サーバーの管理者と被害を受けた相手との間に，サービスの利用契約や取引契約がある場合は，不法行為とは別に，契約上の安全管理の義務の違反（債務不履行）が問題になる。
IPA等の「情報セキュリティ早期警戒パートナーシップガイドライン」（２０２６年１０月版）の付録３は，法律専門家の見解として，利用者がサイトに個人情報等を委ねる場合には，運営者は利用契約に付随した義務として一定レベルのセキュリティを維持する義務を負担していると考えることができるとしている（３９頁）。
このように，契約関係がある相手との関係では，契約関係のない第三者との関係よりも，義務の範囲は広くなり得る。
本記事は，主に契約関係のない第三者との関係を扱う。
第４ 裁判例
１ 東京地裁令和３年３月１０日判決
(1) 事案
東京地裁令和３年３月１０日判決（平成３０年（ワ）第２５５８４号，判例秘書の判例番号 Ｌ０７６３３６１４）は，インターネット上の電子掲示板の記事によって名誉を毀損されたとする原告が，投稿の通信を経由させた学校法人に対し，発信者情報の開示を求めるとともに，予備的に，学校法人が不正アクセスを防止する義務を怠ったとして損害賠償を求めた事案である。
記事は，インターネット上に拡散されていた学生のＩＤ等を使って，第三者が学校法人の付与したアカウントにログインして投稿したものと認定された。
これは，管理者が付与したアカウントや設備が第三者に使われて，別の人に損害が生じた場面であり，踏み台にされた管理者の責任と共通する構造を持つ。
(2) 判断
判決は，学校法人の情報セキュリティポリシーの規定について，「被告における「セキュリティポリシー」の違反があったとしても，それが直ちに第三者に対する不法行為上の義務違反を構成するものではない」とした。
そのうえで，不正アクセスを感知し，遮断する具体的な手段が，技術的，経済的観点からみて，ある程度容易に導入することができるレベルにまで一般的に普及していたことの具体的な主張・立証がないとし，採るべきであった手段とその違反と投稿との因果関係も的確に主張されていないとした。
また，投稿は正規に付与されたＩＤ等でログインして行われているので，そのログインが不正アクセスであることを即時に判断することは困難であったとし，投稿の前に外国からのログインがあったことについても，後になって検知の端緒があったからといって直ちに義務違反を認めることは困難であるとした。
さらに，情報提供を受けた後に，パスワードの変更，学生への説明，個人情報保護委員会と文部科学省への報告及びログイン履歴の調査を行っていたことから，検出後の義務違反も認めなかった。
判決は，ＩＤを付与された学生が発信者であるとはいえないとして発信者情報の開示請求も退け，請求をいずれも棄却した。
(3) 読み方
この判決は，管理者が社内で定めたセキュリティの規程に違反したことが，そのまま第三者への責任に結び付くわけではないことを示している。
他方，判決は，具体的な手段が普及していたことの主張・立証がない事案で責任を否定したものであり，どのような場合でも管理者が責任を負わないとしたものではない。
広く普及した対策を採っていなかったこと，警告を受けながら放置したことなどが具体的に主張・立証されれば，結論が変わる余地はある。
２ 東京地裁平成２９年９月１５日判決
東京地裁平成２９年９月１５日判決（平成２９年（ワ）第１３４３７号，判例秘書の判例番号 Ｌ０７２３０６０３）は，掲示板の記事の発信者情報の開示が求められた事案で，接続業者が，契約者と無関係の第三者が契約者の無線ＬＡＮに「ただ乗りし，または踏み台とする」ことにより書き込んだ可能性が高いと主張したものである。
判決は，第三者がただ乗り等していたことを認めるに足りる具体的な証拠がないとして，契約者が発信者であるとの推定を覆すには足りないとし，開示を命じた。
この判決は，第三者に機器を使われたという主張も，具体的な証拠がなければ採用されないことがあることを示しており，機器を第三者に使われたと説明する必要がある側にとって，ログの保存が重要であることが分かる。
３ 責任を認めた裁判例は見当たらない
本記事の基準日までに，裁判所ウェブサイトの裁判例検索で「踏み台」等の語を組み合わせて検索し，判例秘書で「踏み台」とサーバー・不正アクセス等の語，及びサイバー攻撃・ＤＤｏＳ・乗っ取り等とサーバー・損害賠償の語を組み合わせて検索した範囲では，踏み台にされたサーバーの管理者に，攻撃を受けた第三者への損害賠償責任を認めた裁判例は見当たらなかった。
これは，そのような裁判例が存在しないことを意味するものではない。
なお，ウェブサイトの制作会社やシステムの保守会社が，発注者に対して契約上の責任を負うかについては，前橋地裁令和５年２月１７日判決等の裁判例があり，Web制作・保守会社にPHPを更新する責任はあるかで扱っている。
第５ 警察から命令・通知が届く場合
１ 警察官職務執行法６条の２
令和８年１０月１日に施行された警察官職務執行法６条の２は，警察庁長官が指名するサイバー危害防止措置執行官が，サイバー攻撃等に用いられる通信や電磁的記録を認めた場合で，放置すれば人の生命，身体又は財産に対する重大な危害が発生するおそれがあるため緊急の必要があるときは，攻撃に関係するコンピュータの管理者その他関係者に対し，記録の消去その他の措置を命じ，又は自らその措置をとることができると定めている（同条２項）。
２項による命令又は自ら行う措置（条文では「処置」という。）には，原則として事前にサイバー通信情報監理委員会の承認が必要であり（同条４項），対象のコンピュータが国内にあると認める相当な理由がない場合は，警察庁の執行官に限り，警察庁長官を通じて外務大臣と協議した上で行う（同条３項）。
処置をとったときは，管理者に措置をとることを命じた場合を除き，遅滞なく管理者に通知する（同条８項本文）。
つまり，執行官が自ら措置をとった場合や，管理者以外の関係者に措置を命じた場合には，管理者に通知が届くことになる。
ただし，危害の防止に支障がある場合や管理者の所在が不明である場合は，通知しないことができる（同項ただし書）。
制度の全体は，重要電子計算機防護法とはで説明している。
２ 通知の方法
通知の方法は，「警察官職務執行法第六条の二第八項の規定に基づく管理者への通知等に関する規則」（令和８年国家公安委員会規則第１９号）２条が定めている。
同条によれば，通知は，電子メールを送信する方法その他の方法により，①処置をとった年月日，②対象のコンピュータを識別するＩＰアドレスその他の事項，③処置の概要，④処置をとった執行官の所属する機関を知らせて行う。
３ 通知を受けたときに確認すること
通知が電子メールで届いた場合は，メールに書かれた連絡先ではなく，所属する機関が公表している連絡先で，通知が本物かを確かめるのが安全である。
本物であれば，通知に書かれたＩＰアドレス，処置の年月日及び概要を記録に残し，自社のどのサーバーが関係するかを特定する。
そのうえで，侵入の経路の調査，ログの保全，修正版の適用，個人データの漏えい等に当たるかの検討及び取引先への説明の要否を順に検討する。
初動の手順は，法律事務所のサイバー事故初動チェックリストにまとめている。
警察から通知を受ければ，管理者は，自社のサーバーが攻撃に使われ，又はその疑いがあることを知ったことになるので，その後に同じ状態を放置すれば，過失の評価は厳しくなり得る。
第６ 事前の備え
１ 法律上の努力義務
不正アクセス禁止法８条は，アクセス制御機能を付加したアクセス管理者に，識別符号の適正な管理に努めるとともに，アクセス制御機能の有効性を検証し，必要があると認めるときは速やかにその機能を高度化する等の防御措置を講ずるよう努めることを求めている。
サイバーセキュリティ基本法７条１項も，事業者に，自主的かつ積極的にサイバーセキュリティの確保に努めることを求めている。
いずれも努力義務であり，それ自体から直ちに第三者への損害賠償責任が生じるものではないが，過失の判断で，管理者に期待される対応の水準を考える手掛かりになる。
２ 社内規程と外部への義務を分けて考える
前記の東京地裁令和３年３月１０日判決によれば，社内のセキュリティポリシーの違反が直ちに第三者への不法行為上の義務違反になるわけではない。
もっとも，社内規程は，自社が想定していたリスクと採るべき手順を示す資料にもなるので，規程を作ったまま運用していないと，事故の後に説明がつきにくくなる。
規程は，実際に運用できる内容にし，更新の確認，ログの点検及び異常時の連絡の担当者を決めておく。
３ ログを残す
踏み台にされたかどうか，いつ侵入されたか，どの通信が自社のサーバーから出たかは，ログがなければ確かめることが難しい。
前記の東京地裁平成２９年９月１５日判決のように，具体的な証拠がなければ，第三者に使われたという主張自体が採用されないこともある。
アクセスログ，管理画面へのログインの記録，送信したメールの記録等を，一定期間，サーバーとは別の場所に保存しておく。
調査会社の報告書の読み方は，情報漏えいのフォレンジック報告書をどう読むかを参照されたい。
４ 委託契約で役割を決める
IPAの「ウェブサイト運営者のための脆弱性対応ガイド」は，外部の事業者に保守業務を委託している場合には，脆弱性対策についても契約に含め，緊急時にも円滑な対応が得られるよう，体制や費用等をあらかじめ合意しておくことが望まれるとしている（９頁）。
同ガイドは，運営を外部の事業者に委託していても，被害者から見た「責任者」は一義的にはウェブサイト運営者であるとしている（５頁）。
踏み台にされた場合も，被害を受けた第三者からまず責任を問われるのは，サーバーの管理者であると考えられる。
委託先との間で，修正版の確認と適用，ログの保存，異常時の連絡を誰が行うかを決めておく。
保守契約の範囲の考え方は，Web制作・保守会社にPHPを更新する責任はあるかで説明している。
第７ 関連記事
①PHP2Shell（CVE-2026-109618・109619）とは―公式発表で確かめられること，深刻度９．２と「インターネットの７割」の意味及び国内のサイト停止
②脆弱なPHPを使っていただけで漏えい等報告は必要か―PHP2Shellと個人情報保護法２６条，施行規則７条３号の「おそれ」及び本人通知
③レジデンシャルプロキシとは―家庭用IoT機器が犯罪の踏み台になる仕組みと対策
④ECサイトのカード情報漏えいと加盟店の義務―割賦販売法３５条の１６，クレジットカード・セキュリティガイドライン６．１版及び開発委託先の責任
第８ 出典
１ 法令
①民法７０９条（e-Gov法令検索。令和８年６月２４日施行の版。令和８年１０月２５日確認）https://laws.e-gov.go.jp/law/129AC0000000089
②警察官職務執行法６条の２（e-Gov法令検索。令和８年１０月１日施行の版。令和８年１０月２５日確認）https://laws.e-gov.go.jp/law/323AC0000000136
③警察官職務執行法第六条の二第八項の規定に基づく管理者への通知等に関する規則（令和８年国家公安委員会規則第１９号）２条（e-Gov法令検索。令和８年１０月２５日確認）https://laws.e-gov.go.jp/law/508M60400000019
④不正アクセス行為の禁止等に関する法律８条（e-Gov法令検索。令和８年１０月２５日確認）https://laws.e-gov.go.jp/law/411AC0000000128
⑤サイバーセキュリティ基本法７条１項（e-Gov法令検索。令和８年１０月２５日確認）https://laws.e-gov.go.jp/law/426AC1000000104
２ 裁判例
①東京地裁令和３年３月１０日判決（平成３０年（ワ）第２５５８４号，判例秘書の判例番号 Ｌ０７６３３６１４）
②東京地裁平成２９年９月１５日判決（平成２９年（ワ）第１３４３７号，判例秘書の判例番号 Ｌ０７２３０６０３）
３ 公的機関の資料
①情報処理推進機構「PHPの脆弱性（CVE-2024-4577）を狙う攻撃について」（令和６年７月５日，同月１２日更新）https://www.ipa.go.jp/security/security-alert/2024/alert_20240705.html
②情報処理推進機構ほか「ウェブサイト運営者のための脆弱性対応ガイド」（第３版第２刷，平成２９年３月３０日）５頁・９頁https://www.ipa.go.jp/security/guide/vuln/ug65p90000019by0-att/000058492.pdf
③情報処理推進機構ほか「情報セキュリティ早期警戒パートナーシップガイドライン」（２０２６年１０月）付録３・３９頁https://www.ipa.go.jp/security/guide/vuln/partnership_guide.html
④経済産業省・情報処理推進機構「サイバーセキュリティ経営ガイドライン Ver3.0」（令和５年３月）指示９https://www.meti.go.jp/policy/netsecurity/mng_guide.html
⑤内閣官房国家サイバー統括室「サイバーセキュリティ関係法令Q&Aハンドブック」Ver3.0（令和８年１０月）Q53・２９６頁https://security-portal.cyber.go.jp/guidance/pdf/law_handbook/law_handbook_3.pdf
４ 脆弱性の修正の公式発表
①PHP「News Archive – 2026」（令和８年１０月２１日・２３日の告知。令和８年１０月２５日確認）https://www.php.net/archive/2026.php
②Node.js「Wednesday, October 21, 2026 Security Releases」（令和８年１０月２１日。令和８年１０月２５日確認）https://nodejs.org/en/blog/vulnerability/october-2026-security-releases
③Oracle「Oracle Critical Patch Update Advisory – October 2026」（令和８年１０月２０日。令和８年１０月２５日確認）https://www.oracle.com/security-alerts/cpuoct2026.html
④GitLab「GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13」（令和８年１０月２１日。令和８年１０月２５日確認）https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/