top of page

クラウド構成図から「法務的に危ないポイント」を洗い出すチェックの流れ


ree

クラウドをちゃんとやっている会社ほど、

  • ネットワーク構成図

  • システム構成図

  • データフロー図

はきれいに揃っていることが多いです。

……が、たいてい**「技術チームだけが見ている」**んですよね。

一方で、IPA のクラウド安全利用の手引きや、IoTセキュリティフレームワークなど、公的なガイドラインでも

まずシステム構成図・データフロー図を整理してから、リスクを洗い出すべき

とされています。

つまり、構成図さえあれば、法務的な危ないポイントもかなり見えてしまうということです。

この記事では、

「クラウド構成図を前にして、法務・情シスが一緒に“赤丸ポイント”を見つけていく流れ」

を、シンプルなステップとしてまとめます。

全体像:クラウド構成図を「3つの観点」で見る

クラウド構成図を、法務目線で見るときの観点はだいたいこの3つです。

  1. 個人情報・機密情報が“どこを通り、どこに溜まるか”

  2. その途中で“誰(どこの会社・どこの国)が触れる状態か”

  3. その状態が、法令・契約・社内規程で約束した内容と合っているか

個人情報保護委員会やJIPDECの資料でも、クラウド利用時には

  • 委託か第三者提供か

  • 国外移転の有無

  • 委託先の監督

を整理しなさい、と繰り返し書かれています。

この3つを構成図の上で追いかけていくのが、「法務的に危ないポイント」を洗い出す基本の流れです。

STEP 0:準備編 ― 「図」と「ルール」を並べる

用意したいもの

  1. 最新のクラウド構成図

    • ネットワーク図+クラウド(AWS/Azure/GCP・SaaS)の箱が載っているもの

    • 可能なら「データフロー(矢印)」も入っているもの

  2. データの種類が分かるメモ

    • どのシステムで

      • 個人情報

      • マイナンバーや健康情報など要配慮情報

      • 営業機密(見積・取引条件等)を扱っているかの一覧(ざっくりでOK)

  3. 前提となるルール類

    • 個人情報保護方針・情報セキュリティ規程

    • 主要な顧客との契約(秘密保持・委託契約・DPAなど)

    • 必要であれば、業界ガイドライン(FISC、マイナンバーガイドライン等)

これらを机の上に全部並べてスタートです。

STEP 1:構成図に「個人情報・機密情報の箱」を書き込む

まずやることはシンプルで、

“重要なデータが置いてある箱”に丸をつける

ことです。

  1. 構成図の中で、

    • DB

    • ストレージ(Blob、S3 等)

    • SaaS(CRM、人事給与、会計、グループウェアなど)に印をつける

  2. それぞれに「どんなデータが主役か」をざっくり書き込む

    • 例:

      • 「顧客マスタ(個人情報)」

      • 「従業員情報(個人情報+マイナンバー)」

      • 「見積・契約書(営業機密)」

IPAやJIPDECも、クラウドやIoTのリスク評価の出発点は**「どの情報がどのシステムにあるかを棚卸しすること」**だと説明しています。

ここで「印がついた箱」こそ、この後のチェックで重点的に見るべきポイントです。

STEP 2:矢印を追って「外に出るポイント」をマークする

次に、丸をつけた箱から**外に向かう矢印(通信経路)**だけを見ていきます。

特に注目したい矢印

  • 自社のクラウド → 他社のSaaS・外部サービス

    • 例:ログ解析サービス、メール配信サービス、AIエンジン など

  • 日本リージョン → 海外リージョン・海外サービス

  • 本番環境 → 保守・運用ベンダの接続経路

この「外に出る矢印」ごとに、次の3つをメモします。

  1. 相手は誰か(どの会社か)

    • どのクラウド事業者・どのSaaSか

    • そのサービスがデータを「委託」として扱うのか、「自社の目的でも使う」のか

  2. どこの国か

    • 日本事業者か、海外事業者か

    • 海外なら、主なデータセンターの所在国

  3. 何のデータが流れるか

    • 個人情報を含むか

    • マイナンバーや健康情報など要配慮情報が混ざるか

個人情報保護委員会やJIPDECの解説では、クラウド利用時に

  • 「委託」なのか

  • 「第三者提供(特に国外)」なのか

を見極めた上で、

  • 委託先の監督(契約+実態把握)

  • 国外提供の説明・同意

が必要とされています。

このSTEP 2の目的は、構成図の上で「委託・第三者提供・国外移転になりそうなポイント」に付箋を貼ることです。

STEP 3:「委託」か「第三者提供」かをざっくり仕分ける

STEP 2で付箋を貼った「外に出るポイント」について、法務と一緒にざっくり仕分けしていきます。

3-1. まず“委託”になりそうな矢印

  • メインのクラウド基盤(IaaS/PaaS/SaaS)

  • 監視・運用・バックアップなど、自社のためだけにデータを扱う会社

→ 多くは**「個人データの取扱いの委託」**に整理できます。

この場合に重要なのは:

  • 適切な委託契約(安全管理措置・再委託・事故報告など)

  • 委託先の監督

    • 説明資料・監査報告書の確認

    • 必要に応じたインタビュー・現地確認 等

3-2. “第三者提供かも?”と疑いたい矢印

次のような場合は、クラウド事業者自身が個人情報取扱事業者として動いている可能性があります。

  • 利用規約上、

    • 「サービス改善・マーケティングのために利用者データを利用する」と明記されている

  • 分析・広告系のサービスにデータを送っている

  • AIサービスにプロンプトとして個人データをそのまま渡している

この場合、

  • 「クラウド例外」が使えない

  • 個人データの第三者提供(特に国外提供(法28条))のルールが効いてくる

ため、

  • 本人への情報提供と同意

  • 移転先の制度・体制の確認

などが必要になる場合があります。

構成図の上で、「自社のためだけに処理してくれている会社」と、「その会社の目的でも使われ得る会社」を分けておくのがポイントです。

STEP 4:「誰が触れるのか」を図上でチェックする

次は、“人”の観点です。

構成図上のそれぞれのクラウドサービス・ネットワークに対して、

  • 自社従業員

  • グループ会社

  • 業務委託先(BPO、システム開発会社など)

  • 取引先(ポータルにログインする顧客など)

誰が・どの権限で入れるのかをざっくり書き込みます。

法務的に危ないパターンの例

  • 本番環境に、保守ベンダが24時間いつでも入れる状態

    • NDAや委託契約できちんと位置づけられていない

  • 個人情報を扱うSaaSに、海外拠点のメンバーや別会社の社員が普通にアクセスできる

    • 契約上「再委託禁止」となっているのに、その再委託に当たりそう

個人情報保護法では、

  • 委託先に個人データを扱わせる場合の**「必要かつ適切な監督」**

  • 国外の再委託先も含めた管理責任

が強調されていますし、2024年3月の個人情報保護委員会の注意喚起でも、クラウド事業者や委託先を監督していない場合の問題点が指摘されています。

構成図の上で「この線の先にいる人たちは、全員契約と規程で想定しているメンバーか?」を確認するフェーズです。

STEP 5:ログ・証跡の“空白地帯”を探す

次にやりたいのは、

「何かあったときに、後から追えない場所」がないか

を構成図から探すことです。

見るべきポイント

  • 本番系システムにアクセスする経路で、認証・アクセスログが残っていない場所がないか

  • 重要データが通る外部サービス(SaaS・API)で、操作ログ・監査ログがどれくらい残るかが不明のままになっていないか

  • ログがバラバラに散らばっていて、インシデント時に「全部揃えられない」構造になっていないか

IPAのクラウド安全利用手引きでも、

  • ログの取得場所と保持期間を把握しておくこと

  • 事業者と利用者で分担するログ管理責任を整理すること

が重要だとされています。

また、JIPDECや各種ガイドラインでも、クラウド利用時に監査・検証の方法が確保されているかがチェックポイントになっています。

構成図に「ログをどこで取るか」「どこに集約するか」を書き込んでいくと、ログの空白ゾーン=法務的に危ないゾーンが浮かび上がります。

STEP 6:契約書・規程と「ズレている箱・線」をリストアップ

ここまでで、

  • 外に出る矢印(委託・第三者提供・国外移転候補)

  • 誰が触れるか(再委託・アクセス権限)

  • ログの空白地帯

に付箋がついたはずです。

最後に、それぞれについて:

  1. どの契約・規程と関係するかをメモ

    • 個人情報保護方針

    • 情報セキュリティ規程

    • NDA・業務委託契約・DPA

    • 業界ガイドライン

  2. 「何が“ズレている”のか」を一言で書く

    • 例:

      • 「海外SaaSに個人情報が飛んでいるのに、プライバシーポリシーに書いていない」

      • 「再委託禁止条項があるのに、運用上は再委託先が普通にアクセスしている」

      • 「ログを1年保存すると規程にあるが、このSaaSは90日で消える」

CREX のクラウド利用ガイドライン作成記事でも、クラウドの現状と規程・契約のギャップを洗い出し、どこから手を付けるか優先順位を付けることが重要だとされています。

ここまで整理できれば、

  • 契約を直すべきか

  • 構成を変えるべきか

  • 規程・説明資料をアップデートすべきか

がかなり見えやすくなります。

まとめ:クラウド構成図チェックの「5つの質問」

実務で手早く回す用に、クラウド構成図を見ながら自問自答したい質問を5つに絞ると、こんな感じです。

  1. この図のどこに「個人情報・機密情報」が溜まっている?

  2. その箱から外に出る矢印は何本あって、相手は誰・どこの国?

  3. その相手は「委託」か、「第三者提供(特に国外)」になりそうか?契約と監督は十分か?

  4. そのシステムには“誰”(自社・グループ・委託先・顧客)が入れるようになっている?契約と規程で想定しているメンバーだけか?

  5. 何かあったときに追えるだけのログ・証跡は、その経路・サービスに残るか?期間は足りているか?

この5つを、構成図を指差しながら技術者と一緒に確認するだけでも、「法務的に危ないポイント」のかなりの部分は浮かび上がります。

山崎行政書士事務所がお手伝いできること

山崎行政書士事務所では、クラウド法務・情報セキュリティ専門として、

  • Azure/M365/各種SaaSを含むクラウド構成図・データフロー図の法務目線レビュー

  • 構成図に基づいた「委託」「第三者提供」「国外移転」ポイントの整理メモ作成

  • それに紐づく契約条項(委託契約・DPA・NDA等)の見直し候補リストの作成

  • 情シス・技術者と一緒にホワイトボードを囲んで、「図を見ながら赤丸ポイントを洗い出す」ワークショップのファシリテーション

などを行っています。

「構成図はあるけれど、法務的にどこがヤバいのかまでは整理できていない」

という段階からで大丈夫です。

静岡県内の企業さま向けには、オンライン・訪問どちらでも対応可能です。

実際の構成図(PDFやPowerPoint)をお見せいただければ、

  • どこが「まず優先的に押さえたい危険ポイント」か

  • 契約を直すのか、構成を直すのか、説明文書を直すのか

を一緒に整理することができます。

 
 
 

最新記事

すべて表示
③Azure OpenAI を用いた社内 Copilot 導入事例

1. 企業・プロジェクトの前提 1-1. 想定する企業像 業種:日系グローバル製造業(B2B・技術文書多め) 従業員:2〜3万人規模(うち EU 在籍 3〜4千人) クラウド基盤: Azure / M365 は既に全社標準 Entra ID による ID 統合済み 課題: 英文メール・技術資料・仕様書が多く、 ナレッジ検索と文書作成負荷が高い EU の GDPR / AI Act、NIS2 も意識

 
 
 
②OT/IT 統合を進める欧州拠点での NIS2 対応事例

1. 企業・拠点の前提 1-1. 想定する企業像 業種:日系製造業(産業機械・部品メーカー) 拠点: 本社(日本):開発・生産計画・グローバル IT / セキュリティ 欧州製造拠点:ドイツに大型工場(組立+一部加工)、他に小規模工場が 2〜3 箇所 EU 売上:グループ全体売上の 30〜40% 程度 1-2. OT / IT の現状 OT 側 工場ごとにバラバラに導入された PLC、SCADA、D

 
 
 
① EU 子会社を持つ日系製造業の M365 再設計事例

1. 企業・システムの前提 1-1. 企業プロファイル(想定) 業種:日系製造業(グローバルで工場・販売拠点を持つ) 売上:連結 5,000〜8,000 億円規模 組織: 本社(日本):グローバル IT / セキュリティ / 法務 / DX 推進 欧州統括会社(ドイツ):販売・サービス・一部開発 EU 内に複数の販売子会社(フランス、イタリア等) 1-2. M365 / Azure 利用状況(Be

 
 
 

コメント


bottom of page