仕事の画面を撮って共有する。会議の録音を保存する。生成AIに資料を読ませる。どれも便利な使い方ですが、そのサービスに、どの情報が保存され、誰が見られ、削除後に何が残るかを確認しているでしょうか。
今回は、自社の機密情報を扱う外部情報サービスについて、必要なセキュリティ要件を定め、サービスが要件を満たすか確認する方法を説明します。あわせて、提供事業者との間で情報の取扱いを確認します。名前を知っているサービスでも、利用するプランや使い方に合わせた確認が必要です。
図1 今回扱う全2基準 利用時の適合確認と情報の取扱いを整理する
ここでいう機密情報には、外部へ知られたくない取引先資料、未公表の見積書、顧客情報等が考えられます。何を機密として扱うかは自社で整理します。情報の区分と取扱いの決め方は、次回の3-1-4で詳しく扱います。
Gyazoの公表事例で画像と関連情報を分けて考える
画像共有サービスGyazoについて、提供元のHelpfeelは2026年10月21日、不正アクセスと情報漏えいに関する第三報を公表しました。9月11日に、画像アップロードサーバの脆弱性を悪用した不正アクセスが発生した事例です。第三報は10月20日時点の確認結果に基づいています。
| 区別する情報 | 第三報で公表された内容 |
| 画像ファイル本体 | 133名のユーザーが保存した画像432件について、第三者の閲覧・取得が判明 |
| 画像のメタデータ | 削除済み画像に関するものも含め、流出した範囲を公表。画像本体の流出件数とは別 |
| 確認できていない範囲 | 大量の画像取得や、削除済み画像本体の取得を示す記録は確認されていない |
同社は、流出した情報に含まれる画像URLを使って、ほかの画像が閲覧された可能性を完全には否定できないとしています。「すべての画像が漏えいした」とも、「432件以外は絶対に閲覧されていない」とも言い切らないことが大切です。
削除後に残る情報も確認する
第三報では、画像本体を削除後一定期間で消去する一方、メタデータは調査等に備えて保持していたと説明しています。削除後60日でメタデータを自動消去する新たな方針も示しましたが、公表時点では策定・適用する方針として読む必要があります。
この事例を自社のサービス選定に置き換えると、「削除できますか」という一つの質問だけでは確認が足りない場合があります。画像や文書の本体、付随する情報、バックアップについて、それぞれの保存期間や削除の条件を確かめると、扱ってよい情報を判断しやすくなります。これは本稿の実務上の考察です。
利用条件の確認を自社の判断に使う
今回の公表内容から、利用企業の契約確認不足が不正アクセスの原因だったと推測することはできません。また、利用条件を確認すれば事故が起きなくなるという意味でもありません。自社が預ける情報と、サービスが行う保存・利用・削除の内容を照らし合わせ、利用条件を決めることが今回の目的です。
画像共有に限らず、ファイル共有、Web会議、生成AI等でも、業務上の情報をサービスへ渡す場面があります。画面やファイルに機密情報が含まれる場合は、その取扱いをサービスごとに確認します。
画像本体とメタデータを一緒に確認する
メタデータは、データに付随する情報です。画像のタイトルや、画像を識別する情報などが該当します。Gyazoの第一報では、画像URLを構成する情報のほか、画像から読み取った文字、画像タイトル、取得元URL等が挙げられています。
図2 画像本体と付随する情報の例 保存する項目はサービスにより異なる
OCRは、画像の中の文字を読み取る技術です。例えば、画像そのものが見えなくても、読み取られた文字に顧客名や見積金額が含まれていれば、その文字情報も取扱いの対象になります。これは内容を理解するための架空例で、Gyazoでそのような資料が漏えいしたと述べるものではありません。
共有する前に渡す情報を確かめる
画面の一部分だけを伝えるつもりでも、スクリーンショットに顧客名や別の資料が写り込むことがあります。共有する範囲を絞り、サービスが画像から作る文字情報や付随情報も確認します。何が収集・保存されるかは製品や設定によって異なります。
見えなくなった後の扱いを確かめる
利用画面で削除した後、ファイル本体、関連情報、バックアップがそれぞれいつ消えるかを確認します。一定期間の保持や法令対応等の例外が示されている場合は、その条件も読みます。画面上の削除操作だけで、あらゆる記録が同時に消えるとは限りません。
例えば、取引終了後に削除する必要がある資料を扱うなら、自社や取引先との約束と、サービス側の保持条件を照合します。合わない場合は、入力する情報や利用方法を変えるか、別のサービスを検討します。
3-1-3-1 利用するためのセキュリティ要件を定める
一つ目の基準では、外部情報サービスを利用する際のセキュリティ要件を定めた上で、利用時に、その要件を満たしているかサービス内容を確認します。要件とは、自社がそのサービスを利用するために必要とする条件です。
公式解説書は、自社方針との整合、稼働率や障害等の信頼性、セキュリティ対策や機能、データ保存先・保存期間などを、要件を考える観点として挙げています。以下は、その考え方を具体化した実務上の例です。
| 確認する観点 | 自社の要件として具体化する例 |
| 扱う情報と目的 | 顧客との打合せ資料を、指定した担当者だけで共有する |
| 公開と共有の範囲 | 利用者を限定でき、意図しない一般公開を防ぐ設定ができる |
| 認証と管理機能 | 自社で必要と決めた認証方法や利用者管理を実施できる |
| 保存先と保存期間 | 保存先、保持期間、削除後の取扱いが自社の条件に合う |
| 情報の利用目的 | 提供者による二次利用や学習等の扱いを確認できる |
| 障害と事故の対応 | 連絡窓口、通知方法、業務を続けるための条件を確認できる |
この表の全項目が、3-1-3-1で列挙された一律の必須チェックリストという意味ではありません。自社で扱う情報や業務を踏まえ、適用される他の評価基準も確認して要件を定めます。特定の保存日数や認証の取得を、この二基準だけの共通条件として追加するものでもありません。
有名かどうかより利用条件を具体化する
例えば「安全なサービスを使う」という要件だけでは、何を見れば適合を確認できるか分かりません。「指定した利用者に共有を限定できる」「保存・削除の条件を確認できる」など、資料や設定で照合できる形にします。無料か有料かだけで判断せず、実際の契約プランと機能を確認します。
取引先指定のサービスも確認する
公式解説書は、取引先等から提供される情報サービスも例に含めています。取引先に指定されたという理由だけで確認を省かず、何を保存し、誰が見られ、取引終了時にどう扱うかを整理します。確認が難しい点は、取引先の窓口へ問い合わせます。
サービスの説明と実際の利用方法を照合する
要件を定めたら、利用するサービスの規約、提供条件、機能説明、設定画面等と照合します。公式解説書は、利用申請・承認の手続を設け、名称、提供者、利用目的、機密区分、利用期間、利用者の範囲、確認結果等を整理する方法を例示しています。
図3 利用時の確認手順例 様式や承認方法は自社の運用に合わせる
一つの要件を確認する記入例
| 記録する内容 | 架空のサービスAの確認例 |
| 自社の要件 | 打合せ資料の閲覧を招待した担当者に限定する |
| 確認する範囲 | サービスAの法人プラン、当社の共有設定 |
| 確認資料と結果 | 機能説明［版・日付］と設定画面で、招待者限定を確認 |
| 利用条件と担当 | 公開リンクを使わない。管理担当［氏名］が設定を確認 |
これは記録方法の例です。実際には、定めた各要件について照合します。提供者が「共有を制限できる」と説明していても、自社の設定が一般公開になっていれば、意図した使い方になりません。機能の有無と利用時の設定を結び付けて確認します。
確認できない事項は「確認待ち」として、問い合わせ先と確認期限を残します。必要な条件が満たせない場合は、機密情報の利用を保留する、使い方を見直すなど、判断する担当者へつなげます。返答がないことを適合の根拠にはしません。
3-1-3-2 提供事業者と機密情報の取扱いを確認する
二つ目の基準は、外部情報サービスの提供事業者と、機密情報の取扱いについて合意を取り交わすことです。公式ガイドは、契約等による合意が困難な場合には、提供者の公開情報や説明書等で取扱いを確認する方法も認めています。
図4 合意文書を取り交わせる場合と困難な場合の確認方法
合意する情報を具体的にする
個別に契約できる場合は、秘密保持の対象情報を明確にする方法が考えられます。公式解説書は、秘密保持契約や、対象情報を別紙で整理する方法を示しています。例えば、預ける顧客資料、利用目的、公開範囲、終了時の返却・削除等について、自社が必要とする扱いを確認します。
個別契約が難しいサービスの確認を省かない
標準の利用規約で提供されるクラウドサービスでは、利用企業ごとの合意書を取り交わせない場合があります。その場合は、利用規約や提供条件等で、機密情報がどのように扱われるかを確認します。「同意する」を押したことだけで、内容の確認や自社要件との照合が済むわけではありません。
確認した文書名、版や確認日、該当箇所を残すと、後から判断を説明しやすくなります。公式ガイドの自己評価方法でも、確認した利用規約や契約書、公開情報等の文書名を確認します。確認した時点の資料を保管する方法は、そのための実務例です。
提供者の条件と自社の使い方をそろえる
外部サービスの利用では、提供者が用意する機能や取扱条件に加え、自社が決める利用者、入力する情報、共有設定が関わります。どちらの確認が必要かを整理すると、規約を読んだ後の社内作業が明確になります。以下は一般的な確認例です。
図5 サービス条件と自社の運用を対応させる例 具体的な分担は契約等で確認
生成AIでは入力と保存と学習を分けて確認する
公式解説書は、生成AIサービスも外部情報サービスの例に含めています。[2 p50] 例えば、議事録や顧客資料を入力するなら、入力内容や出力の保存、モデルの学習等への利用、提供者側での閲覧、外部サービスとの連携を確認することが考えられます。これは実務上の確認例です。
「学習に利用しない」という説明があっても、それだけで保存期間や削除条件まで分かるとは限りません。どのプランに適用される条件か、利用者が変更する設定があるかも確認し、自社で扱う情報に合う利用方法を決めます。特定の生成AI製品の現行仕様を、この例で断定するものではありません。
認証や評価情報は対象範囲と一緒に読む
公式解説書は、セキュリティに関する認証やSOC2報告書の確認、ISMAP登録サービスの利用も選択肢として挙げています。SOC2報告書は、サービス事業者のデータ保護等の内部統制を外部監査人が評価した報告書です。これらを全サービスの一律必須条件として扱うものではありません。
認証等を参考にする場合も、対象のサービス、確認対象の期間、利用者側に求められる対応を確かめます。規約変更、プラン変更、入力する情報の変更があったときに再確認する方法も有用です。これは運用例であり、今回の二基準で独自の年次点検頻度を追加するものではありません。
自己評価に使う文書と確認内容をそろえる
二つの基準について、要件を定めた文書、利用時の確認ルール、機密情報の取扱いを確認できる資料をつなげて整理します。公式ガイドが示す確認内容は、次のとおりです。
| 評価基準番号 | 自己評価で確認するもの |
| 3-1-3-1 | セキュリティ要件を定めた文書と文書名。利用時に要件への適合を確認する社内ルール等 |
| 3-1-3-2 | 機密情報の取扱いに関する利用規約・契約書・合意書等。個別合意が困難な場合の公開情報・説明書等と、その文書名 |
3-1-3-1の適合基準では、実際に利用時の確認を行っていることが求められます。サービスごとの確認結果を記録しておくと、その実態を説明しやすくなります。本稿の確認表は記録方法の一例であり、公式が指定する必須様式ではありません。
機密情報を扱うサービスを利用実態から探す
要求事項の出発点は、自社の機密情報を扱う外部情報サービスです。社内で正式に契約したサービスに加え、画像の共有、Web会議の録画、取引先指定の保存先等も、実際にどの情報を扱っているか確認します。二基準とも、公式ガイドの個別の対象外条件は「該当なし」です。
機密情報の取扱いに関する要件は、第7回の2-1-2-1「情報共有先との機密情報の取扱い」ともつながります。同じサービスについて別々の判断が食い違わないよう、対象情報と確認資料を対応させます。
本日の五つの確認
□ 外部サービスを利用するためのセキュリティ要件を文書で定めた。
□ 利用時に要件への適合を確認するルールがあり、実際に確認している。
□ 提供者と機密情報の取扱いを合意し、困難な場合は公開情報等で確認した。
□ 確認した規約や契約書等の文書名と内容を示せる。
□ 保存・共有・削除の条件と、自社の実際の使い方を照合した。
最後の確認は、サービスの条件を運用に結び付けるための実務例です。まず、機密情報を入れている外部サービスを一つ選び、利用目的、確認した要件、取扱条件、判断の根拠を一つの記録にまとめてみてください。
次回は情報の機密区分と取扱い
11月12日は、3-1-4「機密区分に応じた情報の管理」です。見積書や顧客名簿等を例に、情報の重要さに応じて取扱いを決める方法を説明します。
連載の関連項目とご相談
第1回は連載目次、第7回は共有先との機密情報の取扱い、第10回はネットワークの把握です。情報の機密区分は第12回、アカウントやアクセス権の管理は11月13日以降の関連回でも扱います。
ライトハウスコンサルタントでは、★3を見据えた現状確認や、規程・台帳・記録の準備を支援しています。利用している外部サービスと扱う情報を整理し、自社の要件や確認資料をそろえるお手伝いをします。
