MINDがAIエージェントに読ませないデータ｜分類して止める線

「社内のAIエージェントに共有フォルダを読ませたいが、人事の評価や顧客の情報まで読まれないか心配だ」「権限を絞れば足りると思っていたら、人が見られる資料はエージェントも全部見られた」——社内でAIエージェントを動かし始めた会社の、情報システムや情報セキュリティの担当者から聞く声です。エージェントに渡す権限を細かく設計すれば解決する、と考えたくなるところです。でも、権限の設計だけでは止まりません。本当は、データそのものに区分を付け、エージェントに読ませない区分を決めて止めることが要ります。この記事では、機密データの自動分類とAIエージェントの制御を打ち出す米国の会社 MIND を例に、止める区分と、その分類を誰が確かめ、例外を誰が認めるかを整理します。

MINDは何をする製品か

MIND は、情報漏えい対策（DLP）の基盤を提供する会社です。社内のどこにどんな機密データがあるかを見つけて分類し、危ない動きを見つけ、漏れる前に止める、という一連の仕事を1つの基盤で行います。公式サイトは、対象としてクラウドのサービス、生成AI、AIエージェント、社員の端末、社内のファイルサーバー、メールを挙げています（2026年10月時点）。

特徴として前に出しているのが、分類にAIを使う点です。公式の説明では、文書の中身と文脈の両方を読む多層の分類の仕組みを持ち、型の照合、ベクトルの分析、統計の分析、分類のために作った独自の言語モデルを、その場で最も合う方法に切り替えて使うとされます。契約書、ソースコード、医療の記録、取締役会の議事録といった文書の種類まで分けるとしています。

止め方にも段階があります。公式の説明では、危険度に応じて、止める、いったん止めて理由を書かせたうえで通す、利用者に方針を案内する、見張るだけにする、許す、を選べます。端末では常駐の軽いソフトとブラウザの拡張機能が利用者の操作を受け止め、その場で判定するとされます。

この記事が扱うのは、そのうちのAIエージェントに読ませるデータの制御です。社員が生成AIに機密情報を貼り付ける話は、別の記事（Harmonic の記事）で扱っているので、ここでは1行で送ります。社員の端末で動くエージェントを洗い出す話も、Singulr AI の記事に譲ります。

どんな会社が作っていて、なぜ国内で知られていないか

MIND は、公式の会社紹介によれば、米国シアトルとイスラエルのテルアビブに拠点を置いています。発表文ではシアトルに本拠を置くとしています。2026年9月17日には、7,200万ドルのシリーズBを公式に発表しました。前年の3,000万ドルのシリーズAと合わせ、累計の調達は1億1,200万ドルとされています。

このほか公式サイトでは、AIの管理の仕組みの国際規格 ISO/IEC 42001 の認証を取ったこと、Anthropic のサイバーセキュリティの検証の枠組みに採択されたことが示されています。いずれも、データ保護の道具自体がAIを使うことへの説明の材料として打ち出しているものです。

国内でまだ知られていない理由は、確かめた範囲で3つ考えられます。画面と資料が英語であること、料金が公開されておらず商談で決まる形であること、利用先として紹介されているのが米国の企業や医療、金融の組織に寄っていることです。日本語の画面や国内の拠点、データの保存地域は、公式の資料では確かめられませんでした（2026年10月時点）。

情報漏えい対策の製品自体は、国内でも大手の製品が広く使われています。MIND を取り上げるのは、その中で「AIエージェントが読み込む前に止める」ことを正面から打ち出しているからです。製品を入れるかどうかに関係なく、エージェントを社内のデータにつなぐときに立つ問いを、はっきり形にしています。

2026年の3つの発表で見えること

2026年1月28日、MIND はAIエージェント向けの情報漏えい対策を発表しました。発表文は、モデルを守るのでも出力に後から対応するのでもなく、AIエージェントが触れたり動いたりする前に機密データを理解し、管理し、守る、という考え方を示しています。社内でどのエージェントが動いているかを見つけ、エージェントが触れるデータを見張り、データに応じた制御をかける、という3つの柱です。

2026年7月29日には、情報漏えい対策の日々の運用をAIエージェントに担わせる、と発表しました。役割ごとに、会社に固有の分類の仕組みを作るもの、方針を提案して直すもの、事案を調べて原因を説明するもの、是正を実行し人の承認が要るときは上げるもの、利用者が書いた理由を方針に照らして評価するもの、と分かれています。分類を作る役割は、誤検知を判定役に確かめさせて自ら改善するとされます。

同じ発表では、AIと外部の道具をつなぐ共通の仕組み（MCP）の窓口を通じて、言葉で指示を出せるようにするとも書かれています。ただ、発表文は「使えるようにする」と先の話として書いており、提供の状況は公開ページでは確かめられませんでした。

2026年9月29日には、Claude の Compliance API との連携を発表しました。Claude Enterprise では会話の中身（チャット、アップロードしたファイル、プロジェクト）と操作の記録と利用者の名簿を、開発者向けの基盤では操作の記録を取り込み、既存の方針で見張るとされます。追加の費用はかからないとされています。この連携は、エージェントの手前で止めるというより、AIとのやり取りを後から見える化する仕組みである点は押さえておきます。

課題：エージェントが、読んではいけないデータを読む

社内のAIエージェントは、共有フォルダ、文書の管理の仕組み、顧客の管理の仕組み、チャットの履歴といった場所からデータを読み、要約し、別の場所に書き込みます。人が1件ずつ開くのと違い、一度に大量の文書を読むのが特徴です。

その中に、人事の評価、給与の一覧、顧客の個人情報、未公表の決算の資料、買収の検討の資料が混ざっていると、エージェントはそれも読みます。読んだ内容は要約や回答に混ざり、本来そのデータを見てはいけない人の画面に出ることがあります。エージェントの出力が別の道具に送られれば、データは社外にも出ます。

公式のAIエージェント向けのページも、一度の設定の誤りで、エージェントが機密情報に触れ、業務の流れに広げ、外部の道具に出すまでが数秒で起きる、と書いています。人なら途中で「これは見てはいけない」と気づく場面でも、エージェントは気づかずに進みます。

さらに厄介なのは、何を読んだかが後から分かりにくいことです。人の操作なら開いたファイルの記録が残りますが、エージェントが何百件を読んで1つの要約にしたとき、どの文書のどの部分が混ざったかをたどるのは簡単ではありません。止めるなら、読む前に止めるほうが確実です。

課題の続き：「権限を絞れば足りる」が当たらない

エージェントの対策として最初に出てくるのは、エージェントに渡す権限を絞ることです。専用の利用者を作り、読める場所を限る。これは基本として正しく、まずやるべきことです。

ただ、多くの社内のエージェントは、使う人の権限で動きます。社員が自分の業務を手伝わせるエージェントは、その社員が見られるものを全部見られます。そして社員が見られる範囲は、多くの会社で本来より広くなっています。全社に共有されたままの人事の資料、退職者から引き継いだまま整理されていないフォルダ、「リンクを知っている人は誰でも」で共有された文書がその例です。

人なら、見られる場所にあっても、わざわざ開かない文書があります。エージェントには、その遠慮がありません。権限の上では見てよいことになっている文書を、検索の結果として素直に読みます。だから、権限の設計に加えて、データの中身に応じて止める層が要ることになります。

では、なぜエージェントは読んではいけないデータを読むのか。原因を3つに分けると、道具で解けるところと、人が決めなければならないところが分かれます。以下、原因を1つずつ見てから、原因ごとの分担を表にまとめます。

原因1：エージェントが人の閲覧権限をそのまま引き継ぐ

1つ目の原因は、エージェントの権限の作りです。社員の資格で動くエージェントは、社員が見られる範囲をそのまま受け継ぎます。社内検索の仕組みで、利用者が見てよい文書だけを答えに使う「権限の引き継ぎ」が大事だとされるのと同じ理屈が、逆向きに効きます。権限の引き継ぎそのものは、Onyx の記事で扱っています。

問題は、引き継いだ権限が、データの中身を知らないことです。権限は「この人がこのフォルダを開けるか」で決まり、「このフォルダの中に給与の一覧があるか」は見ていません。権限の棚卸しで広すぎる共有を直すのは大切ですが、全社の共有を正しく直し終える日は、なかなか来ません。

ここに、データの中身を読んで止める道具の出番があります。MIND の発表文が、モデルではなくデータを守る、エージェントが触れる前に守る、と打ち出しているのは、権限の側だけでは届かない部分を、データの側から埋める考え方です。

ただし、どの種類のエージェントの、どの読み込みの経路に対して止められるのかは、製品と接続先の組み合わせで変わります。公開ページでは、エージェントの読み込みを止める仕組みの細部や、対応する接続先の一覧は確かめられませんでした。自社で動かしているエージェントの名前を並べて、1つずつ提供元に確かめる必要があります。

原因2：データに区分が付いていない

2つ目の原因は、データに区分が付いていないことです。中身で止めるには、「これは人事の評価」「これは顧客の個人情報」という印が要ります。ところが多くの会社では、文書を作った人が区分の印を付ける決まりがあっても、実際に付いている文書はわずかです。

ここで自動の分類が効きます。公式の説明では、MIND は文書の中身と文脈を読んで分類し、Microsoft の情報保護の仕組みである Purview の秘密度のラベルを自動で読み書きできるとされます。人が付けなかった印を道具が付けてくれれば、Copilot などのラベルを見て動く道具の側でも、止める判断に使えます。

ただし、自動の分類は外れます。給与の一覧に似た形の社内の練習用の表を機密と判定したり、取締役会の資料の抜粋を一般の資料と判定したりすることはあり得ます。提供元は誤検知の少なさを効果として挙げていますが、それは提供元の発表であり、自社のデータで外れ方を測るまでは信じないのが原則です。

区分の段階をいくつにするか、公開・社内・限定・厳秘のような段の作り方は、別の記事「社外秘の区分を4段階で決める」で扱っています。この記事では、区分がある前提で、そのうちどれをエージェントに読ませないか、自動で付いた印を誰が確かめるかに絞ります。

原因3：区分の持ち主がいない

3つ目の原因は、道具では解けません。区分の印は付いても、その区分の定義を誰が決め、誤った印を誰が直すかが決まっていない状態です。情報セキュリティの部門が道具を入れ、道具が印を付け、印が外れていても誰も気づかない、という流れになりがちです。

区分の持ち主は、データの持ち主と同じであるべきです。人事のデータの区分は人事が、顧客のデータの区分は営業や顧客対応の責任者が、決算のデータの区分は経理が持ちます。情報セキュリティの部門は、区分を決める人ではなく、区分を守る仕組みを動かす人です。

持ち主がいないと、止めたときにも困ります。エージェントが人事の資料を読もうとして止められたとき、それが正しい停止か誤りかを判断できるのは人事だけです。情報セキュリティの担当者が代わりに判断すると、止めすぎて業務が止まるか、緩めすぎて漏れるかのどちらかに振れます。

そこで、原因ごとにAIに任せることと人が決めることを分けておきます。次の表の右の2列は、道具を入れる前に社内で決めておく部分です。

原因ごとの、AIと人の分担

3つの原因を並べると、道具で埋められるのは主に1つ目と2つ目の一部で、3つ目は人の仕事として残ることが分かります。

原因	AIに任せること	人が決めること	決める人の例
権限の引き継ぎ	どのエージェントが動き、どのデータに触れているかの洗い出し	エージェントごとに読ませてよい場所と、読ませない区分	情報システムの部門とエージェントの持ち主
区分の欠け	中身と文脈を読んだ分類の案、ラベルの自動付与	区分の定義、分類の外れを直す基準	データの持ち主の部門
持ち主の不在	誤分類の候補の指摘、止めた件数の集計	区分ごとの持ち主、例外を認める人	情報セキュリティの責任者と各部門の責任者

表の右の2列が空のまま道具を入れると、道具は動いても、止めた理由も止めなかった理由も誰も説明できません。逆に、この2列が埋まっていれば、道具を別の製品に替えても運用はそのまま続けられます。

同じ日に公開するヘルプデスクのエージェントの記事（Serval）は、エージェントに権限を与える側の承認の話です。こちらは、エージェントが読むデータの側で止める話で、両方がそろって初めて、エージェントの読み書きに線が引けます。

対策1：自動分類を、人が抜き取りで確かめる

1つ目の対策は、自動の分類をそのまま信じないことです。最初の数週間は、止める動作をかけず、分類だけを動かします。道具が付けた印を、データの持ち主の部門が抜き取りで確かめ、外れた件数を数えます。

確かめる件数は、全件でなくてかまいません。区分ごとに毎週決まった件数を選び、「機密なのに一般と判定された」「一般なのに機密と判定された」の2種類を数えます。止める判断に効くのは前者、機密を見逃した件数です。後者は業務を止める原因になるので、こちらも数えておきます。

MIND の発表では、分類を作る役割のエージェントが誤検知を判定役に確かめさせて自ら改善するとされます。道具が自分で直す仕組みがあっても、直した結果を確かめるのは人です。分類の基準が変わったら、変わったことを持ち主の部門に知らせる決まりを置いておくと、ある日突然止まり方が変わる事態を避けられます。

抜き取りの結果は、止める区分を決める材料になります。外れが多い区分は、止める動作をかけずに見張るだけにしておく。外れが少なく、漏れたときの損が大きい区分から、止める動作をかけていきます。

対策2：エージェントに読ませない区分を決める

2つ目の対策は、エージェントに読ませない区分を決めることです。断言してよいのは、全部を止める必要はなく、止める区分は少ないほど運用が続くということです。止める区分が多すぎると、エージェントは何もできなくなり、社員は道具を迂回し始めます。

読ませない区分の候補は、漏れたときに取り返しがつかないものです。人事の評価と給与、健康に関する情報、顧客の個人情報のうち本人を特定できるもの、未公表の決算や買収の資料、秘密保持の取り決めで第三者に渡せない相手方の情報が典型です。これらは、エージェントの業務の役に立つ場面が少ない割に、漏れたときの損が大きいものです。

区分は全社で1つに決めるのではなく、エージェントごとに読ませる範囲を変える考え方もあります。人事の業務を手伝うエージェントは人事の資料を読む必要があるので、人事の区分を止めると仕事になりません。エージェントごとに、読ませてよい区分を表にするのが現実的です。

決めた区分は、エージェントを作る人に見える形で配ります。社内でエージェントを作れる人が増えるほど、作る人が区分を知らないまま広い場所を読ませる危険が増えます。作る前に区分の表を確かめる手順を、エージェントの申請の流れに組み込んでおきます。

対策3：止めたときの通知と、例外の申請

3つ目の対策は、止めた後の流れを決めることです。公式の説明では、MIND は危険度に応じて、止める、いったん止めて理由を書かせて通す、方針を案内する、を選べ、人が介在して自動か手動で止めるとされます。7月の発表では、利用者が書いた理由を方針に照らして評価する役割のエージェントも挙げられています。

ここで決めるのは、止めたことを誰に知らせるかと、例外を誰が認めるかです。エージェントが止められたとき、知らせる先は情報セキュリティの部門だけでなく、エージェントの持ち主と、データの持ち主にします。止めた理由を持ち主が見て、誤りなら区分を直し、正しければそのまま止めておきます。

例外の申請も同じです。業務でどうしても止められた区分を読ませる必要があるとき、申請を受けて認めるのはデータの持ち主です。AIが理由を評価して通す仕組みがあっても、例外を認めた責任は人の名前で残します。例外には期限を付け、期限が来たら見直します。

• 自動の分類の結果を確かめないまま、止める動作を全社にかける
• 止めた通知が情報セキュリティの部門にしか届かず、データの持ち主が知らない
• AIが理由を評価して通した件を、誰も見返さない
• 例外に期限を付けず、一度通したエージェントが同じ区分を読み続ける
• 誤った停止が続いたので、区分の定義を直さずに止める動作だけを外す

誤った停止が続いたときに、止める動作だけを外すのは最もよくない手当てです。止まらなくなった代わりに、なぜ止まっていたのかが分からなくなります。外れの原因が区分の定義か、分類の基準か、エージェントの読む範囲かを、持ち主の部門と一緒に見直します。

止める仕組みを入れる段取り

ここまでの対策を、入れる順番に並べると次のようになります。いきなり止める動作から始めないのが要点です。

見張るだけの段は、短く済ませたくなるところです。けれども、この段で「本当は誰がどのデータを使っていたか」が初めて見えます。止める前に見る期間が、止めた後の揉め事を減らすと考えて、1〜2か月は取っておくのが無難です。

段取りの途中で、エージェントの持ち主に知らせる手順も入れておきます。ある日から急に読めなくなると、持ち主は不具合だと思って情報システムの部門に問い合わせます。止める区分と、止まったときの申請の窓口を、止める前に伝えておきます。

止める道具そのものに、何が渡るか

見落としやすいのが、止める道具自体が社内の機密データを読むことです。分類するには中身を読む必要があるので、MIND は社内の文書の中身と文脈を読みます。Claude の Compliance API との連携では、Claude Enterprise の会話の中身、アップロードしたファイル、プロジェクトまでを取り込むとされています。

つまり、社員がAIとやり取りした中身が、情報漏えい対策の道具の側に集まります。誰がその中身を見られるかは、道具を入れる前に決めます。情報セキュリティの担当者が、社員の相談の中身まで自由に読める状態は、社員への説明なしには作るべきではありません。

データの保存地域、保持の期間、再委託先の一覧は、公開ページでは確かめられませんでした。分類に独自の言語モデルを使うとされているので、そのモデルが自社のデータで学習するのか、学習した結果が他社と共有されないかも、契約の前に資料で確かめる項目です。

費用は公式サイトに公開されておらず、商談で決まる形です（2026年10月時点）。増え方は、見張る場所の数、端末の数、利用者の数で見ます。止め方としては、解約したときに分類の結果と記録を持ち出せるか、ラベルを書き込んだ文書のラベルがどうなるか、特定の場所だけ止める動作を外せるかを確かめておきます。

エージェントに読ませない区分のチェックリスト

ここまでの話を、導入の前に決める項目としてまとめます。全部が埋まってから、止める動作をかける範囲を広げるのが安全な順番です。MIND 以外の製品を比べるときにも、そのまま使えます。

区分と持ち主

• 区分ごとに持ち主の部門を決め、区分の定義を持ち主が承認した
• エージェントに読ませない区分を、漏れたときの損の大きさで選んだ
• エージェントごとに、読ませてよい区分の表を作った
• 社内のエージェントの一覧を作り、それぞれの持ち主と動く資格（誰の権限か）を書いた

分類の確かめ

• 止める前に分類だけを動かす期間を決めた
• 区分ごとに毎週の抜き取りの件数と、確かめる部門を決めた
• 機密を見逃した件数と、一般を機密とした件数を分けて数えると決めた
• 分類の基準が変わったときに、持ち主の部門へ知らせる決まりを置いた

止めた後と道具そのもの

• 止めた通知を、エージェントの持ち主とデータの持ち主にも届けると決めた
• 例外を認める人をデータの持ち主とし、例外に期限を付けた
• 止める道具に集まるデータを誰が見られるかを決め、社員に説明した
• 保存地域、保持の期間、学習への利用、再委託先を資料で確かめた

埋まらない項目があるなら、道具の比較より先に、その項目を決める打ち合わせを開くほうが近道です。とくに区分の持ち主は、情報セキュリティの部門だけでは決められません。各部門の責任者を呼んで、最初の1回で決めてしまうのが早道です。

まとめ

MIND は、機密データをAIで自動分類し、生成AIやAIエージェントとのやり取りで止めることを打ち出す情報漏えい対策の会社で、2026年にはエージェント向けの対策、運用を担うAIエージェント、Claude の Compliance API との連携を相次いで発表しました。エージェントが読んではいけないデータを読むのは、人の権限を引き継ぎ、データに区分がなく、区分の持ち主がいないからです。分類の案と停止と通知は道具に任せられますが、読ませない区分の決定、自動分類の確かめ、例外の承認は人に残ります。自動分類を100%と考えず、見張るだけの期間を経てから、損の大きい区分から止めてください。

• 製品の機能と提供状況は、MIND の公式サイトと公式ニュース（2026年1月28日、7月29日、9月17日、9月29日の発表）を2026年10月22日に確かめた範囲に基づきます。導入の前に最新の原文と契約の資料で確かめてください
• エージェントの読み込みを止める仕組みの細部、対応する接続先、データの保存地域、日本語への対応は、公開ページでは確かめられませんでした
• 提供元が挙げる効果の数字は本文では扱っていません。自社のデータで外れ方を測ってから判断してください

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。