開発会社や前任者と連絡が取れなくなったとき、最初に考えるべきことは「すぐに別会社へ作り直してもらう」ことではありません。先に、現在動いているシステムを止めないことと、会社が管理すべき契約・アカウントを確保することが重要です。
焦って契約を解約したり、設定を変更したりすると、Webサイトだけでなくメール、決済、社内業務まで影響する場合があります。ここでは、次の引継ぎ先へ相談するまでの確認順序を整理します。
まず現在の状況を記録する
障害が起きている場合は、原因を推測する前に事実を残します。
- いつから、どの画面や機能で起きているか
- すべての利用者で起きるか、一部だけか
- 表示されたエラー文と画面の記録
- 直前に行った更新、設定変更、契約変更
- 業務への影響と、いつまでに対応が必要か
問い合わせを受ける側は、この情報から確認の優先順位を決めます。パスワードや個人情報が写り込む場合は、そのままメールへ添付しないよう注意してください。
0〜24時間の状況別初動表
まず「現在稼働中」「障害発生中」「侵害の疑い」を分けます。この表の「0」は異常を認知した時刻です。「当日中」は暦日の23時59分までという締切ではなく、認知後の初動を継続して行う時間帯を指します。深夜・休日に侵害の疑いを認知した場合も翌営業日まで待たず、利用できる専門事業者や公的相談窓口へ連絡します。
ここでの0〜24時間は対応を整理するための目安であり、復旧時間やサービスレベルを保証するものではありません。各行の対応は必要に応じて並行します。進行中の攻撃通信、情報漏えい、他システムへの拡散がある場合は、被害拡大を抑えるため必要最小限のネットワーク隔離を直ちに行い、その判断・対象・時刻・操作を記録します。電源断・再起動・設定変更などはネットワーク隔離と分け、証拠保全と稼働への影響を踏まえて判断します。複数の状況に当てはまる場合は侵害の疑いを含む列を優先し、状況を見ずに全システムを一律停止しません。
表は横にスクロールできます
| 時間 | 現在稼働中 | 障害発生中 | 侵害の疑い |
|---|---|---|---|
| 0〜2時間 | 稼働画面と業務影響を記録。契約の解約、更新、認証情報変更など影響不明の操作を保留する。 | 発生時刻、対象機能、エラー、直前変更、利用者影響を記録。既存の障害連絡先と手順を確認する。 | 情報セキュリティ責任者へ連絡。時刻、画面、アラート、ログの所在を記録し、上書き・消失させない。進行中の攻撃通信・漏えい・拡散があれば必要最小限のネットワーク隔離を直ちに行い、判断と操作を記録する。電源断・再起動・設定変更は証拠保全と影響を踏まえて判断する。 |
| 当日中 | ドメイン、DNS、サーバー、クラウド、決済などの契約名義・請求・更新日・管理者を台帳化する。 | バックアップの対象・取得日時・保管先を確認。切り戻しや設定変更は、影響範囲と復旧手順を確認してから実施する。 | 専門事業者またはJPCERT/CCなどの相談窓口へ連絡し、保全・隔離・調査の順序を決める。関係者への連絡・報告要否も所管窓口へ確認する。 |
| 24時間以内 | ソースコード、データ、外部連携、監視、運用手順の取得状況と次の確認先を整理する。 | 暫定対応、未復旧範囲、業務回避策、次の判断時刻を関係者へ共有。原因未確定なら断定しない。 | 保全した情報を基に被害範囲と対応計画を更新。証拠、対応経過、判断者を記録し、復旧・公表・届出は専門家や所管窓口と調整する。 |
IPAのセキュリティインシデント対応手引きは、初動時に不用意な電源断などでシステム上の記録を消さないこと、必要に応じてログ等を証拠保全すること、対応が難しい場合は外部専門組織や公的窓口へ相談することを示しています。JPCERT/CCのインシデントハンドリングマニュアルも、検知・連絡受付、トリアージ、対応計画、対応実施という流れを示しています（いずれも2026年8月27日確認）。そのため、状況を確認せずに全パスワード変更、全サービス停止、再起動を一律に行うのではなく、被害拡大防止と証拠保全の両面から順序を決めます。
止めてはいけない契約を確認する
システムが動いている間は、次の契約を一方的に停止しないようにします。
表は横にスクロールできます
| 対象 | 停止した場合に起こり得ること | 確認する情報 |
|---|---|---|
| ドメイン・DNS | Webサイトやメールへ接続できなくなる | 契約会社、名義、更新日、DNS管理先 |
| サーバー・クラウド | システムやデータへ接続できなくなる | 契約名義、請求、管理者、構成 |
| メール配信 | フォーム通知や自動メールが送れなくなる | 送信サービス、認証情報、送信元ドメイン |
| 決済・外部API | 購入、予約、データ連携などが止まる | 契約者、利用機能、認証情報、請求 |
| 証明書・ライセンス | 警告表示や機能停止が起きる | 更新方法、有効期限、入手元 |
請求書、クレジットカードの明細、契約更新メールは、利用中サービスを見つける手掛かりになります。前任者個人のメールアドレスへ通知が届いていた場合は、契約先の正式な手続きで管理先を変更します。
アカウントとバックアップを確保する
ドメイン・DNS、サーバー、ソースコード、データベース、外部サービスの管理権限を、引継ぎ台帳へ記録します。ログインできない場合は、契約名義や請求情報を使った正規の復旧手続きを確認してください。
侵害や進行中の障害がない場合は、稼働を維持し、バックアップを確保してから構成を調査します。取得対象・日時・保管先を記録し、復元方法が未確認なら、そのまま台帳へ残します。設定や認証情報を変更する前には、接続先への影響と復旧手順を確認します。侵害が疑われる場合は、上の初動表に従って被害拡大防止と証拠保全を優先します。
むやみに行わない方がよいこと
- 稼働中サーバーで、目的を決めずにソフトウェアを一括更新する
- 影響先を確認せず、APIキーやパスワードを一斉変更する
- 古そうに見えるサーバー、ドメイン、外部サービスを解約する
- バックアップを確認せず、環境を初期化する
- 本番環境だけを直接修正し、変更内容を残さない
セキュリティ上すぐに認証情報を変更する必要がある場合も、対象システムがどの認証情報を使っているか、変更後にどこを更新するかを確認します。
侵害が疑われる場合は、ログの保存先・保存期間、アラート原文、発生時刻、操作履歴、端末やアカウントの状態を記録します。収集やコピー自体が証拠や稼働へ影響する可能性があるときは、自己判断で操作を続けず、フォレンジック対応が可能な専門事業者へ相談してください。JPCERT/CCのインシデント相談窓口では、初動対応や被害箇所の特定方法などの相談を受け付けています（2026年8月27日確認）。
契約・法的判断は技術調査と分ける
連絡不能だからといって、契約解除、成果物の所有、アカウント移管、損害賠償、顧客・行政機関への報告要否が自動的に決まるわけではありません。次を分けて確認します。
- 契約書、見積書、発注書、利用規約に定めた保守範囲・連絡方法・解約・成果物・データ返却
- メール、議事録、作業記録、請求書など、依頼と履行状況を確認できる記録
- システムの稼働、権限、ログ、バックアップなどの技術的事実
記録は削除・上書きせず保全します。契約の解釈、権利義務、紛争対応はこの記事で結論付けず、契約書一式を持って弁護士へ相談してください。情報漏えい・不正アクセス等の届出や公表は、対象データ、業種、被害状況で窓口や期限が異なり得るため、所管官庁、警察、JPCERT/CCなどの専門窓口へ確認します。
引継ぎ先へ最初に伝える情報
すべての資料がそろっていなくても、次の情報があると初回相談を進めやすくなります。
- システムやWebサイトのURLと用途
- 現在起きている問題と業務への影響
- 最後に正常動作を確認した時期
- ログインできる管理画面やサービス
- ソースコード、サーバー、契約資料の有無
- 希望する対応時期と、止められない業務
調査後は、現行環境を保守できるか、部分改修が必要か、リプレイスを含めて比較すべきかを、取得できた権限・コードと継続運用の条件から判断します。継続契約と単発対応の選び方は、月額保守とスポット対応の違いを参照してください。
公式資料・相談窓口
- IPA「中小企業のためのセキュリティインシデント対応の手引き」（第4.0版付録8。2026年8月27日確認）
- JPCERT/CC「インシデントハンドリングマニュアル」（2026年8月27日確認）
- JPCERT/CC「インシデント相談・情報提供」（最終更新2026年3月13日、2026年8月27日確認）