< back to blog

組織の生成AI導入に備えた機密性の高い業務データの保護

清水 孝郎
組織の生成AI導入に備えた機密性の高い業務データの保護
Published by:
清水 孝郎
@
組織の生成AI導入に備えた機密性の高い業務データの保護
Published:
January 21, 2026
シスディグによるファルコフィード

Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。

さらに詳しく

本文の内容は、2026年1月21日に Conor Sherman が投稿したブログ(https://www.sysdig.com/blog/protecting-sensitive-business-data-in-preparation-for-the-organizations-gen-ai)を元に日本語に翻訳・再構成した内容となっております。

組織が Microsoft Copilot や Google Gemini といった生成AIツールの導入準備を進める中で、機密データの保護を担う担当者は、リスクを洗い出し、実行可能な提言を提示するという、ほぼ不可能に近い課題に直面しています。この課題が困難である大きな理由の一つは、最も重要な業務データの多くが非構造化データである一方、セキュリティ業界の大半は構造化データやインフラの保護を前提として成り立っている点にあります。業界全体として、私たちはデータそのものではなく、データを格納する技術、いわば「バケツ」を守ることを優先してきましたが、本来守るべきはデータそのもの、つまり「水」です。

非構造化データの価値は、その形式ではなく、内容と文脈にあります。そのため、この種のデータの発見、棚卸し、保護は困難になります。Microsoft Copilot や Google Gemini のようなエンタープライズ向け生成AIは、主にデータを保護することではなく、回答を提供することに焦点を当てているため、データ保護を担う担当者は生成AI技術と相反する立場に置かれています。

私は、なぜ業界がこれまで採ってきた対策では生成AIの影響に耐えられないのか、また、AIを責任をもって導入(「責任あるAI(Responsible AI)」)するために、防御側と生成AIを整合させる上で克服すべき課題は何かについて、私の見解を共有します。

機密データを守る防御側と、現在企業で利用可能な生成AI技術、すなわち Microsoft Copilot や Google Gemini を整合させるためには、まず、この技術がいかに異質で強力であるかを示す重要な特性を認識する必要があります。

展開は従来のゲートキーパーを迂回して行われる可能性があります。このソフトウェアは生産性向上ソフトウェアと同じベンダーによって提供されているため、全従業員に対して容易にグローバルで有効化することができます。

データ消費に制限がありません。ベンダーはすでにデータを保有しているため、生成AI機能はデータストアの上に配置され、提供されている限りのデータを消費することができます。

優先されるのは回答です。生成AIツールの成功は、与えられた質問に対する回答の正確性にかかっています。これらのツールは、「その要求者が回答を得るべきかどうか(should)」という文脈では動作せず、「その要求者が回答を見ることができるかどうか(can)」のみに制約されています。

回答はデータから導き出されるため、生成AIツールは最終的に「回答エンジン」です。組織が生成AIを責任をもって展開するためには、次の問いに答える必要がありますが、ここに課題があります。私たちがこれまで採用してきた手法は、非構造化データには十分に適していないのです。

機密性の高い業務データ

  • それが何であるかを把握しているでしょうか。機密性の高い業務データを特定するための体系的な方法はあるのでしょうか。
  • それがどこにあるかを把握しているでしょうか。データを特定する手段を得たとして、そのデータが存在し得るすべての場所を確認できるでしょうか。
  • それが信頼できるものかを把握しているでしょうか。すべてのデータの棚卸しができたとして、それが正確であり、改ざんされていないことを保証できるでしょうか。
  • 誰がそれにアクセスできるかを把握しているでしょうか。信頼できるデータがどこに存在するかを把握したうえで、そのデータ、そしてより重要には、そのデータから導き出され得る回答に誰がアクセスできるのかを把握しているでしょうか。
  • それが適切に取り扱われているかを把握しているでしょうか。誰がアクセスできるかを把握したうえで、そのデータは十分な注意を払って取り扱われているでしょうか。

非構造化データの課題

上記の問いに答えることが難しい主な理由の一つは、非構造化データが機密であるかどうかを判断するための明確な基準(「明確な線引き」)が存在しないことです。正規表現で問題を回避することはできません。さらに問題を複雑にしているのは、機密性が本質的な属性ではなく、創発的な性質であるという点です。構成要素が個別に存在している場合、それ自体は機密ではありませんが、それらが回答、洞察、あるいは単一のデータ成果物という形で結合すると、その成果物は機密性を帯びるのです。

CUIの例

管理対象非機密情報(CUI)は、非構造化された機密性の高い業務データの一例です。CUI とは、米国政府が作成または保有し、保護または配布管理を必要とする情報を指します。国家安全保障情報や原子力関連情報には分類されませんが、適用される法律、規制、政府全体の方針に従って保護されなければなりません。CUI には、政府のために、または政府に代わって、組織が作成または保有する情報も含まれる場合があります。

要約すると、CUI とは米国政府が CUI と指定したあらゆるデータを指し、正規表現によって合否を判定できるようなものではありません。

CUIとは?

CUI や一般的な業務データはいずれも非構造化データですが、私たちはそれらの情報を保護するためのアプローチも同様に踏襲してきました。例えば次のとおりです。

問題 要件 解決策
それが何であるかを把握しているか? 棚卸しされていなければならない データマーキング(「CUI//Privacy」「Proprietary / Confidential」)
それがどこにあるかを把握しているか? 認可されたシステム上に存在しなければならない ジオトラッキング(米国内所在、データ所在地)
それが信頼できるかを把握しているか? 完全性を備えていなければならない ロギング(NIST 800-171 AU)、アクセスログ
誰がそれにアクセスできるかを把握しているか? 制限されていなければならない アクセス制御(NIST 800-171 AC)、「知る必要性(need to know)」
それが適切に取り扱われているかを把握しているか? データの取り扱い トレーニング、33ページの文書、許容される利用

私たちが解決すべき課題についての視点:

  • インベントリ:人がデータマーキングを付与することに依存しない形で、機密データを特定できる手段が必要です。
  • 防御:データストアだけでなく、データそのものを保護する方法が必要です。すなわち、「バケツ」ではなく「水」を守るという考え方です。
  • 完全性:そのデータが信頼できるかどうかを把握する必要があります。
  • 完全性:どの機密性の高いクエリが、どのデータに基づいてその回答を導き出したのかを関連付けられる能力が必要です。
  • アクセス:誰がそのデータに直接的・間接的にアクセスしているか、また過去にアクセスしていたかを把握する必要があります。
  • アクセス:そのデータ、そしてそのデータから導き出された回答がどのように利用されているかを把握する必要があります。

About the author

No items found.

セキュリティの専門家と一緒に、クラウド防御の最適な方法を探索しよう