つづきの技術室開発会社と連絡が取れないシステムのセキュリティリスクと、最初にやること
「問い合わせフォームの調子が悪いので開発会社にメールしたら、宛先不明で戻ってきた」。私たちが引き継ぎの相談を受けるとき、最初に聞くのはだいたいこういう話です。電話もつながらない、担当者の携帯も解約されている。調べてみたら会社自体がなくなっていた、ということもあります。
システムはまだ動いています。売上も問い合わせも、そこから入ってきている。だから「とりあえず動いているうちは大丈夫だろう」と考えたくなります。ただ、セキュリティの面から見ると、連絡が取れなくなったその日から状況はかなり悪くなっています。この記事では、何が危ないのかと、発注担当や情シスの方が最初にやっておきたいことを、引き継ぎを受ける側の立場から書きます。
動いていることと安全なことは別の話
開発会社がいなくなって一番困るのは、障害対応よりも「誰も直さなくなる」ことです。
Webシステムは、プログラミング言語、フレームワーク、ライブラリ、OS、ミドルウェアといった部品の組み合わせで動いています。どの部品にも、あとから脆弱性が見つかります。普段は保守会社がそれを追いかけて更新しているのですが、その役目の人がいなくなると、見つかった穴がそのまま残り続けます。
たとえばPHPは、各バージョンが最初のリリースから2年間は通常のサポート、その後2年間は重大なセキュリティ修正のみ、合わせて4年でサポートが終わると公式サイトに明記されています。2026年10月時点でサポートされているのは8.2から8.5までで、8.2のセキュリティサポートも2026年12月31日で終わります（PHP: Supported Versions）。数年前に納品されたまま手が入っていないシステムなら、すでにサポートの外にいる可能性が高いということです。
IPAが毎年公表している「情報セキュリティ10大脅威」の2026年版でも、組織向けの4位に「システムの脆弱性を悪用した攻撃」が入っています。1位は「ランサム攻撃による被害」、2位は「サプライチェーンや委託先を狙った攻撃」です（IPA 情報セキュリティ10大脅威 2026）。委託先と連絡が取れないシステムは、この上位の脅威にまとめて当てはまってしまう立場にあると私たちは考えています。
連絡が取れないシステムでよく見るリスク
引き継ぎの現場で実際によく出会うものを挙げます。どれも珍しい話ではありません。
ひとつは、サーバーやドメインの契約が開発会社の名義になっているケースです。更新の案内が開発会社に届いていて、誰も払わないまま期限が切れる。ドメインが失効すると、サイトが止まるだけでなく、第三者に取得されてしまうおそれもあります。
次に、管理画面やサーバーのパスワードを誰も知らないケース。逆に、退職した開発者のアカウントが今も有効なまま残っていることもあります。どちらも、自分たちでは鍵を管理できていない状態です。
それから、ソースコードの最新版が手元にないケース。サーバー上で直接修正されていて、納品時のファイルと中身が違うことはよくあります。何をどう直せばいいか判断する材料そのものがない、ということになります。
最後に、バックアップがあるのか、どこにあるのかがわからないケース。ランサムウェアの被害を受けたときに戻せるかどうかは、ここで決まります。
最初の1か月でやること
ここからが本題です。順番に意味があるので、上から進めてもらうのがいいと思います。
1. 契約と名義を洗い出す
サーバー、ドメイン、SSL証明書、外部サービス（メール配信、決済、地図など）について、誰の名義で、いつ更新で、請求がどこに来ているかを一覧にします。請求書やクレジットカードの明細から逆にたどると見つかることが多いです。期限が近いものがあれば、技術的な話より先にそちらを片づけます。システムが止まってからでは打てる手が限られるからです。
2. アクセスできる手段を確保する
管理画面、サーバー（SSHやFTP）、データベース、ドメインの管理画面。ログインできるものとできないものを分けます。ログインできたものは、パスワードを変更して社内で保管します。不明なアカウントや、もういないはずの人のアカウントがあれば、止めるかどうかを判断します。
ここで無理をしないことも大事です。どこまで触っていいかわからないまま設定を変えて、システムが止まってしまった相談も受けたことがあります。わからないところは「わからない」と書き残しておけば十分です。
3. 今の中身を丸ごと保全する
サーバー上のファイル一式とデータベースのコピーを取り、サーバーの外に保管します。これが今後のすべての判断の土台になります。現状のバックアップさえあれば、引き継ぎ先が調べるときも、万一攻撃を受けたときも、戻る場所があります。
4. 使われている部品とバージョンを把握する
言語やフレームワーク、CMSのバージョンがわかれば、既知の脆弱性があるかどうかは公開情報で確認できます。国内外の脆弱性対策情報は、データベース「JVN iPedia」で検索できます（JVN iPedia）。この作業は非エンジニアの方には少し難しいので、ここから先は引き継ぎ先と一緒に進めるのが現実的です。
5. 何かあったときの連絡先を決めておく
不正アクセスや情報漏えいは、起きてから連絡先を調べ始めると遅れます。社内で誰が判断するか、外部の誰に頼むかを、この段階で決めておきます。
漏えいが疑われるときに知っておきたいこと
個人情報を扱うシステムなら、もうひとつ押さえておいてほしいことがあります。個人情報保護法では、一定の場合に個人情報保護委員会への報告が義務づけられています。たとえば、不正アクセスなど不正の目的をもって行われたおそれがある漏えい（またはそのおそれ）や、本人の数が1,000人を超える漏えい（またはそのおそれ）がこれに当たります。報告は発覚したらまず速やかに行い、不正の目的によるおそれがある場合は発覚日から60日以内に行う必要があります（個人情報保護委員会 漏えい等の対応とお役立ち資料）。
「おそれ」の段階で対象になるところがポイントです。保守してくれる人がいないシステムで、ログも見られない状態だと、漏れたのかどうかすら判断できません。それ自体がリスクだと考えてください。
技術的な相談先としては、JPCERT/CCがインシデントの報告や初動対応のサポート依頼を受け付けています（JPCERT/CC インシデント対応依頼）。IPAも、不正アクセスやランサムウェア被害の届出を受け付けています（IPA コンピュータウイルス・不正アクセスに関する届出について）。
新しい保守先を探すときに見てほしいところ
開発会社が見つからない以上、どこかに引き継ぐことになります。そのとき、見積もりの金額だけで決めるのはおすすめしません。
他社が作ったシステムは、ドキュメントがなく、作りにもクセがあることがほとんどです。引き継ぎ先が最初に「まず中身を調べさせてください」と言ってくるかどうかは、ひとつの目安になると思います。調べずに「全部作り直しましょう」と言われた場合は、本当にそれしかないのか、理由を聞いてみてください。作り直しが正解のこともありますが、今のシステムを生かしながら少しずつ安全にしていける場合も多いからです。
おわりに
連絡が取れなくなった時点で、システムの面倒を見る人は社内にしかいません。全部を自分たちでやる必要はありませんが、契約と鍵とバックアップの3つだけは、早めに自分たちの手元に戻しておいてください。そこさえできていれば、引き継ぎはずっと進めやすくなります。
ディレクターズ・リベロでは、他社が開発したシステムの調査と引き継ぎ、その後の保守を行っています。「何から手をつければいいかわからない」という段階でもかまいません。サービスの詳細はシステム引き継ぎ・保守のページをご覧いただくか、info@directorz-libero.co.jp までご連絡ください。