この記事の要点
クラウドやAIを使う企業の備えは、情報の保存先と移動先を把握し、設定・アクセス権限、バックアップと復旧手順を確認するところから始めます。情報漏えいと業務停止の両方を想定し、被害時の連絡・判断体制も整理します。AIへ入力できる情報と利用ルールを定め、社員教育につなげます。
メール、顧客管理、請求書や契約書の保管。業務ごとに導入したクラウドサービスやSaaSを並べてみると、社内の情報がさまざまな場所に保存されていることに気づくかもしれません。
一方で、企業へのサイバー攻撃や不正アクセスが相次いでいます。「このままクラウドに情報を預けてよいのか」「自社が使うサービスで被害が起きたら、仕事を続けられるのか」と、不安を感じる担当者もいるのではないでしょうか。
さらに、AIによるメールの要約や資料の整理を利用すると、入力した文章や添付ファイルが外部サービスへ送られる場合があります。会社が把握している保存先に加えて、AIへの入力や連携による情報の移動にも目を向ける必要があります。
この記事では、最近の事例を入口に、データの預け先、セキュリティ設定と権限、被害時の対応と復旧、AIの利用ルールと社員教育を整理します。限られた人員や予算でも、自社の状況を確認するところから進められる備えを考えます。
相次ぐ被害は、情報漏えいと業務停止につながる
2025年9月のアサヒグループの事例以降、企業やサービスのサイバー被害が公表されています。以下は、2026年10月7日時点で確認した各社の公式発表に基づく概要です。
| 企業・サービス | 公表・発覚の時期 | 公表された被害・影響の概要 |
|---|---|---|
| アサヒグループ | 2025年9月以降 | サイバー攻撃によるシステム障害と情報漏えいを公表。商品供給にも影響が生じた。公式調査結果 |
| アスクル | 2025年10月以降 | ランサムウェア攻撃によってサービスが停止し、情報流出も発生した。公式説明 |
| さくらインターネット | 2026年8～9月 | 一部サーバーや販売管理システムへの不正アクセスを確認。情報が閲覧・取得された可能性を公表したが、外部持ち出しを裏付ける明確な事実は確認されていないとしている。公式調査結果 |
| タイムズカー | 2026年9月 | Webシステムへの不正アクセスに関し、運転免許証画像などの本人確認書類の漏えいを確認したと公表。公式発表 |
| 楽天ドライブ | 2026年10月の告知 | 管理用アカウントの認証情報が不正に取得され、一部のアカウント情報や保存データが取得・閲覧されたと公表。公式発表 |
各社の侵入経路や対象システム、確認された被害は異なります。この表は、各社が公表した被害と影響をまとめたものです。AIの関与や、クラウドサービス自体への侵入を一律に示すものではありません。
企業として考えたいのは、情報が漏れる影響と、業務が止まる影響の両方です。自社が攻撃を受ける場合に加え、利用するサービスが停止することで、受注、請求、顧客対応などに支障が出る場合もあります。
こうした事例を、自社の情報と業務がどのサービスに依存しているか、見直すきっかけにできます。
AIの進化を踏まえ、確認の仕方を見直す
こうしたサイバー被害への備えを考えるうえで、AIによる脅威の変化にも目を向けたいところです。AIは、攻撃を行う側の調査や作業にも利用されます。英国NCSCは、2027年までの脅威を評価した報告で、AIがサイバー侵入の一部工程を効率化し、攻撃の頻度や影響を増すと見込んでいます。英国NCSC「AIが2027年までのサイバー脅威に与える影響」
日常業務では、メールや依頼の見た目だけで信用していないかを見直します。「不自然な日本語なら怪しい」という判断だけでは、自然な文章のなりすましに対応しきれません。
例えば、取引先を名乗る振込先変更の依頼や、上司を名乗る至急の支払い指示を受けた場合は、あらかじめ登録している電話番号など、普段使っている別の連絡経路で確認する手順を決めます。届いたメッセージに記載された連絡先だけで確認を済ませないことも、手順に含めます。
こうした確認方法に加え、アカウント管理、ソフトウェアの更新、バックアップなどの基本的な備えも継続します。AIに関連する脅威と、社内でAIを使う際の情報管理を、どちらも自社の対策に組み込みます。
クラウドに預けているデータを把握する
クラウドやSaaSは、場所を問わず情報を共有し、業務を進めるための選択肢です。SaaSとは、インターネット経由で利用するソフトウェアのサービスで、会計、勤怠管理、顧客管理など、さまざまな業務で使われています。
サービスを業務ごとに導入すると、データの保存先や管理体制が複雑になりやすくなります。部署で契約したサービス、個人のアカウント、以前導入して使わなくなったツールまで含めると、会社全体では把握できていない保存先があるかもしれません。
そこで、まず利用するサービスと、そこに置く情報を一覧にします。
| 確認する項目 | 整理する内容の例 |
|---|---|
| サービスと用途 | メール、会計、顧客管理、ファイル共有、AIによる資料作成など |
| 保存・送信する情報 | 顧客情報、社員情報、契約書、請求書、未公開の売上、社内の判断資料など |
| 管理する人 | 社内の担当者と責任者、導入・保守ベンダー、問い合わせ先 |
| 利用者と連携先 | 社員、外部委託先、共有相手、接続している他のサービス |
| 被害や停止の影響 | 漏えいすると誰に影響するか、利用できないとどの業務が止まるか |
一覧をつくる際は、契約や導入の記録に加え、現場で実際に使っているものを確認します。入力・添付・共有・連携によって、情報がどこへ移るのかまでたどると、見落としていた保存先や接続先を見つけやすくなります。
被害の報道を受け、社内のサーバーで管理する方法を考える企業もあるかもしれません。その場合には、更新、監視、バックアップなど、自社で担う範囲も確認する必要があります。サービスごとに、自社と事業者が管理する範囲を確認し、扱う情報と運用体制に合う方法を選びます。英国NCSC「クラウドのセキュリティ責任分担」
クラウド活用を進める際は、預ける情報と、その守り方を社内で説明できる状態にしておくことが大切です。
セキュリティ設定と権限を、社内で把握できているか
社内・ベンダー・サービス提供会社の役割を整理する
クラウドの設定は、社内担当者が行う場合もあれば、導入・保守を外部ベンダーへ委託する場合もあります。また、SaaSの基盤やアプリケーションなど、サービス提供会社が管理し、利用企業が直接設定できない部分もあります。
「ベンダーに任せている」という説明から一歩進め、誰が、どの設定を変更できるのかを整理します。例えば、アカウントの追加・削除は社内、初期設定は導入ベンダー、サービス側の保守は提供会社というように、実際の契約と運用に合わせて確認します。
外部に委託する場合も、設定内容と権限の付与理由を把握し、変更を判断する社内担当者を決めます。技術作業を委託する場合でも、現在の設定、委託する範囲、変更時の承認先を社内で確認できるようにしておきます。
IPAの手引きでも、社内の管理担当者、利用者の範囲、認証設定などを確認する項目が示されています。IPA「クラウドサービス安全利用の手引き」
誰が、何を操作できるかを確認する
権限は、閲覧、編集、削除、外部共有、設定変更などに分けて確認します。社員に加え、委託先や連携するサービスが、どこまで情報にアクセスできるかも確認します。
- 管理者権限を持つ人は誰か。現在も、その権限が必要か。
- 個人ごとのアカウントになっているか。共用アカウントで操作した人が分からなくなっていないか。
- 退職・異動した人や、契約が終わった委託先のアクセスが残っていないか。
- 多要素認証など、サービスが提供する認証機能を適切に使っているか。
- 外部共有の範囲や期限、連携先のアクセス範囲を確認しているか。
- 操作記録やログインの通知を、誰が確認し、異常があれば誰へ連絡するか。
多要素認証は、パスワードと認証アプリなど、異なる種類の要素を組み合わせて本人を確認する方法です。導入するときには、認証機能そのものの設定と、端末の紛失や担当者の交代時の手順も確認します。
権限の一覧と設定記録を残し、担当者が変わっても確認できるようにします。設定を変更したときには、その理由と承認者も記録すると、後から見直しやすくなります。
被害が起きたときの連絡・判断・対応を決める
不正アクセスや漏えいが疑われたときに、初めて連絡先を探す状態では、判断に時間がかかります。社内で誰が受け付け、誰が状況を判断し、誰がベンダーへ連絡するかを、あらかじめ決めます。
対応の準備では、次の点を確認します。
| 準備すること | 確認したい内容 |
|---|---|
| 連絡と初動 | 社内の責任者、代行者、サービス提供会社、保守ベンダー、専門家への連絡方法。夜間・休日の対応範囲 |
| 被害拡大の防止 | アクセスの停止、共有の解除、端末の隔離などを、誰が判断・実施するか |
| 記録と調査 | 発覚時刻、対象サービス、行った操作を記録し、ログなどの調査に必要な情報を確保する方法 |
| 停止中の業務 | 受注・請求・顧客対応などを、どの代替手段で続けるか |
| 対外対応 | 影響する顧客や取引先への連絡、法令や契約に応じた報告・通知の確認担当 |
| 復旧と再発防止 | 安全性と業務の動作を確認し、再開を判断する人。原因を踏まえた設定・手順の見直し |
IPAの対応手引きでは、検知・初動、報告・公表、復旧・再発防止までの進め方を整理しています。調査に必要な記録を不用意な操作で消さないようにすることも示されています。IPA「セキュリティインシデント対応の手引き」
連絡先や手順書は、普段のメールやクラウドにアクセスできない状況でも確認できるようにしておきます。担当者不在や、業務用アカウントが使えない場合を想定した確認も必要です。
また、バックアップからデータを戻せても、既に漏えいした情報への対応は残ります。業務の復旧と、漏えいした情報の範囲の調査、関係者への連絡などを並行して進められるように準備します。
バックアップと復旧にかかる時間を確認する
バックアップの取得と復元を確かめる
復旧への備えとして、バックアップの対象データ、取得頻度、保存先、過去の状態へ戻せる期間を確認します。サービス側で用意されるバックアップが、自社の誤削除やアカウント侵害など、必要な場面で利用できるかも、契約や機能の説明で確かめます。
ファイルの同期と、過去の状態へ戻すためのバックアップは、役割が異なります。削除や変更が同期先にも反映される仕組みでは、コピーがあるだけで安心することはできません。
バックアップ自体が、元のデータと一緒に消されたり、暗号化されたりする場合にも備えます。別の保存先や独立した権限、変更・削除を制限する仕組みなど、利用環境に合う方法を検討します。米国CISAも、攻撃で影響を受けにくいバックアップの確保と、復元の定期的な確認を推奨しています。CISA「ランサムウェア対策ガイド」
復元の確認では、ファイルが開けることに加え、必要なデータがそろい、実際の業務で使えることまで確かめます。取得が失敗したときの通知先や、復元を行う担当者も決めておきます。
復旧目標と、実際に確認した時間を分けて考える
自社として、どの業務を何時間・何日以内に再開したいかを決めます。あわせて、どの時点のデータまで戻す必要があるか、バックアップ後の更新分をどこまで手作業で補えるかも確認します。
例えば、受注処理は先に再開する必要がある一方、月次の集計は後から対応できるかもしれません。この優先順位を、担当部署と経営側で共有します。
次に、データの取り出し、別環境への復元、設定の再構築、業務での動作確認に、どの程度の時間がかかるかを試します。訓練で確認した所要時間と前提条件を記録し、目標との差を把握します。実際の被害では条件が変わるため、復旧目標を決めることに加えて、手順や体制を検証しておくことが大切です。
サービスの稼働率と、自社の業務が再開できるまでの時間も分けて確認します。契約上の復旧に関する条件や、障害時のサポート範囲を確認し、サービスの再開後に社内で必要な作業も含めて考えます。
AIの利用で、社内情報をどこまで外部に渡しているか
入力・添付・連携による情報の移動を把握する
外部からの攻撃に備えると同時に、自社でAIを使う際の情報の扱いも確認します。メールの要約、議事録の整理、契約書の確認では、入力文や添付ファイルに顧客情報や機密情報が含まれている場合があります。
担当者が個人のアカウントで使っていたり、会社が承認していないサービスへ資料を渡していたりすると、管理担当者が知らないところで情報が外部へ送られる可能性があります。直接ファイルを添付する場合に加え、メールやストレージとの連携で、どの情報まで参照を許可したかも確認します。
外部へ送信されることと、第三者への情報漏えいは、区別して考えます。そのうえで、送信先、保存期間、学習への利用、削除条件、アクセスできる人の範囲を確認し、会社が認める情報の扱いと一致しているかを判断します。条件は、サービスや契約プラン、設定によって異なります。
「学習に使われない」という条件も、データが外部へ送られないことや、保存されないことを意味するとは限りません。自社が必要とする条件を、項目ごとに確認することが大切です。
AIの利用ルールと、社員へのIT教育を一緒に進める
会社として、利用できるAIサービスとアカウント、入力できる情報、確認や承認が必要な作業を決めます。ルールは、担当者が実際の仕事で判断できる形にします。
例えば、「顧客名と取引条件が載ったメールを、そのまま要約させてよいか」「社内の売上表を添付して分析してよいか」「ストレージ全体へのアクセスを許可してよいか」といった、具体的な場面を使って説明します。
教育では、AIの操作方法に加え、情報の重要度、共有権限、外部送信、なりすましの確認方法を扱います。情報の削除や匿名化が必要な場合も、どの部分を取り除くか、ほかの記述と組み合わせて、人物や取引を特定できないかまで考えます。
IPAは、AI利用者や管理者向けに、機密情報の取り扱いや詐欺への備えを学べる教材を公開しています。社内研修での利用も想定されています。IPA「AI利用者のためのセキュリティ豆知識」
判断に迷ったときの相談先と、誤って入力したときの報告手順も決めます。現場で使いにくいルールがあれば、業務に必要な利用方法と、情報を守る条件を一緒に見直します。
AIによるメールの要点整理と返信の下書きを進める場合にも、効率化の効果とともに、扱うメールの内容や、連携先に与える権限を確認しておきたいところです。
機密情報を継続して扱う業務では、データの送信先や接続先を会社が管理できるAI環境も検討します。いわゆる閉鎖型・社内向けAIを考える際にも、保存場所、外部への通信、利用者、参照権限を具体的に決めることが出発点になります。
一つの重要な業務から確認し、定期的に見直す
最初から全社の設定を一度に見直そうとすると、対象が広く、何から始めるか迷うことがあります。まずは、機密情報を扱う業務や、止まると売上・顧客対応に影響する業務を一つ選びます。
例えば、顧客対応の業務なら、メール、顧客管理、共有ストレージ、AIによる要約まで、実際の流れに沿って確認します。保存する情報、権限、担当者、バックアップ、停止時の連絡先を並べ、不明な点と、対応を急ぐ点を整理します。
見つかった課題には、対応する人と期限を決めます。使われていない管理者アカウントや、意図しない外部公開があれば、影響を確認したうえで早めに対処します。設定変更が業務に与える影響も確認し、必要に応じてベンダーと進めます。
一度確認した内容も、サービスの追加、社員の入退社、業務変更、AIの新機能や連携によって変わります。重要度に応じた定期確認と、変更時の確認を組み合わせて、一覧や手順を更新します。
定期的な確認では、設定の内容を社内で説明できるか、担当者が不在でも対応できるか、復元を試したか、社員がルールに沿って判断できるかを振り返ります。実際に運用できているかまで確認すると、備えの進み具合を把握しやすくなります。
自社だけで進めにくい場合は
利用するサービスが多く、データの流れを把握できない。ベンダーが設定した内容を、社内で説明できない。バックアップから業務を戻す方法や、停止中の対応が決まっていない。こうした場合は、現在の業務と管理体制を整理するところから、外部の支援を活用する方法があります。
相談する際は、使っているサービス、扱う情報、社内の担当者、委託契約、困っている点をまとめておくと、必要な支援を考えやすくなります。設定の点検、運用ルールの整備、社員教育、復旧訓練など、依頼したい範囲も具体的にします。被害の調査や緊急対応を依頼する先については、専門性と対応範囲を事前に確認します。
EDVAC Technologiesでは、業務の整理からツール・AIの活用、運用ルールの整備、導入後の定着まで、社内体制に合わせた進め方を検討します。
クラウドやAIを使う業務が増えるほど、情報の置き場所と権限、それを管理する人、被害時の動き方を合わせて考える必要があります。まずは一つの重要な業務について、何をどこへ預け、誰が操作でき、使えなくなったときにどう対応するかを、社内で確認するところから始めてみてください。
