AIに会社のデータを見せて、本当に大丈夫なのか

生成AIを会社で使おうとすると、かなり早い段階で出てくる質問があります。

「会社のデータをAIに入れて、本当に大丈夫なの？」

顧客情報。売上データ。社内資料。契約書。メール。会議の議事録。人事情報。

会社には、外に出したくない情報が大量にあります。

だから、

「AIには機密情報を入れない」

というルールを設けている会社も少なくありません。

それ自体は、とても自然な判断です。

しかし、AIが単なる文章作成ツールではなく、会社の中で実際に仕事をするようになると、少し事情が変わってきます。

会社のことを何も知らないAIに、
会社の仕事ができるでしょうか。

AIに会社の情報を見せない。それで仕事はできるのか

たとえば、営業を支援するAIがいるとします。

顧客との過去の商談を知らない。どの商品を購入しているかも知らない。担当者とのメールも見られない。現在の案件状況も知らない。

これでは、

「次に何を提案すべきか」

と聞いても、一般論しか答えられません。

経営を支援するAIでも同じです。

売上を知らない。予算を知らない。在庫を知らない。各部門の状況を知らない。

それで、

「今、会社で何が起きていますか」

と聞いても、答えようがありません。

AIを会社の仕事に使うなら、
仕事に必要な会社の情報へアクセスすることは避けられない。

問題は、

「AIにデータを見せるか、見せないか」

という二択ではないのです。

実際、企業はAIとデータの扱いに苦労している

IBMとPonemon Instituteによる2025年の調査では、AI関連のセキュリティインシデントを経験した組織のうち、97%が適切なAIアクセス制御を行っていませんでした。

また、調査対象となった組織の63%で、AIを管理したりシャドーAIを防いだりするためのガバナンスポリシーが整備されていませんでした。

出典：IBM「Cost of a Data Breach Report 2025」

日本でも状況は似ています。

IPAが公開した「企業における営業秘密管理に関する実態調査2024」では、生成AIの業務利用について何らかのルールを定めている企業は52.0%でした。

そのうち、生成AIの利用を認めている企業は25.8%、利用を禁止している企業は26.2%。

さらに利用を認めている企業でも、
公開情報だけを外部の生成AIへ入力できる会社と、
組織内に閉じた生成AI環境で秘密情報まで扱える会社に分かれています。

出典：IPA「企業における営業秘密管理に関する実態調査2024」

企業側も、

「使いたい。でも、何をどこまで見せればいいのか分からない」

という段階にいることが見えてきます。

「生成AIに入力すると、全部学習される」は正しいのか

ここも混同されやすいところです。

生成AIと一口に言っても、データの扱いはサービスや契約によって異なります。

例えばOpenAIは、ChatGPT Business、EnterpriseやAPI Platformなどのビジネス向けサービスについて、入力・出力されたビジネスデータをデフォルトではモデル学習に使用しないとしています。

またEnterprise等では、内部データソースへの接続やアクセスについて組織側が制御できる仕組みも提供されています。

出典：OpenAI「Business data privacy, security, and compliance」

つまり、

「AIに入力した情報はすべてAIの学習に使われ、外へ出ていく」

と一括りにするのも正確ではありません。

一方で、

「企業向けAIだから何を入力しても安全」

とも言えません。

利用するサービス。契約。保存期間。アクセス権。接続するデータ。社内の運用ルール。

それぞれを確認する必要があります。

AIの安全性は、
AIモデルだけで決まるものではない
からです。

本当の問題は、「誰に何を見せるか」

ここで少し、AIから離れて考えてみます。

会社では、人間の社員にもすべての情報を見せているわけではありません。

営業担当者は顧客情報を見る。経理担当者は請求や支払い情報を見る。人事担当者は社員情報を見る。経営者は全社の数字を見る。

でも営業担当者が、全社員の給与情報を見る必要はありません。

経理担当者が、すべての顧客とのメールを読む必要もありません。

仕事に必要だから、その情報を見る。

それが普通です。

AIも同じように考えればよいのではないでしょうか。

AIだから、全部の社内データを覚えさせる必要はない

企業AIについて、

「社内データを全部AIに入れれば、会社のことを何でも知っているAIができる」

という発想があります。

しかし、本当にそれが必要でしょうか。

営業を担当するAIに、人事評価データは必要でしょうか。問い合わせ対応をするAIに、会社の銀行口座の操作権限は必要でしょうか。市場分析をするAIに、社員の個人情報は必要でしょうか。

必要のない情報まで見せることは、
AIを賢くするというより、
単純にリスクを増やすことにもなります。

World Economic ForumとCapgeminiが2026年に公表したAIエージェントのガバナンスに関する報告でも、AIエージェントについて「何ができるか」だけではなく、どの条件で何を許可するのかを定義し、その権限を監視・監査できることが重要だとしています。

出典：World Economic Forum / Capgemini「AI Agents in Action: Foundations for Evaluation and Governance」

AIが高性能になるほど、
何でも見せるのではなく、
何を見せる必要があるのかを決めること
の方が重要になります。

「見る」と「実行する」も、まったく違う

さらに重要なのは、
情報へのアクセスと、
その情報を使って何かを実行する権限を分けることです。

たとえば経費処理を支援するAIなら、

申請内容を見る。規程を確認する。過去の申請と比較する。不備を見つける。

ここまではAIに任せられるかもしれません。

では、

申請を却下する。支払いを確定する。銀行へ送金する。

ここまで自動で行ってよいでしょうか。

これは会社によって判断が違います。

だから、

見る。整理する。提案する。実行する。

を同じ権限として扱わないことが重要です。

Microsoftも、AIエージェントが企業データへアクセスしシステム上で行動するようになるほど、セキュリティ、ガバナンス、コンプライアンスの境界の中で運用する必要があるとしています。

出典：Microsoft Learn

では、CODATIならどう考えるのか

CODATIでは、

「AIに何のデータを入れるか」から考えません。

先に考えるのは、

「このAI社員は、何の仕事をするのか」

です。

たとえば営業を支援するAI社員なら、

顧客情報。商談履歴。商品情報。営業資料。必要であれば担当者とのやり取り。

そうした仕事に必要な情報へアクセスする。

しかし、人事評価や給与情報まで見る必要はありません。

経営を支援するAI社員なら、

売上。予算。案件。各部門の状況。

といった、より広い情報が必要になるかもしれません。

それでも、
会社のあらゆる情報を無条件に見て、
あらゆる操作を自由に行う存在にする必要はありません。

CODATIで大切にしているのは、

役割が先にあり、その役割に必要な情報と権限が決まる

という考え方です。

AI社員にも「社員証」のようなものが必要になる

人間の社員を想像すると分かりやすいかもしれません。

会社に入社すると、

所属が決まる。役割が決まる。使えるシステムが決まる。閲覧できるフォルダが決まる。承認できる範囲が決まる。

社員だからといって、会社のすべてを自由に見られるわけではありません。

AI社員も同じです。

何の役割なのか。何を見られるのか。何を提案できるのか。何を実行できるのか。どこから人の承認が必要なのか。

言ってみれば、
AI社員にも「社員証」と「職務権限」が必要になる。

CODATIでは、AIを何でも知っている万能な存在として会社へ置くのではなく、
役割を持つ働き手として会社の中に配置する
という考え方を取ります。

「AIに見せて大丈夫？」から、もう一歩先へ

AIに会社のデータを見せることに、不安を感じるのは当然です。

実際、アクセス制御やガバナンスが不十分なAI利用にはリスクがあります。

だからといって、

「機密情報は一切AIに見せない」

だけでは、AIは会社の仕事を十分に理解できません。

逆に、

「AIを賢くするために全部のデータを与える」

のも違います。

必要なのは、

このAIは何の仕事をするのか。その仕事には、何の情報が必要なのか。どこまで見る必要があるのか。何を提案してよいのか。何を実行してよいのか。どこから人が判断するのか。

を設計することです。

AIに会社のデータを見せても、本当に大丈夫なのか。

その問いに対する答えは、
単純な「YES」でも「NO」でもありません。

むしろ本当に問うべきなのは、

「そのAIは、なぜそのデータを見る必要があるのか」

なのだと思います。

CODATIでは、その問いを「AI社員の役割」から考えます。

具体的な仕組みや設計については、CODATIで詳しく紹介しています。

企画・監修：株式会社TOKIWAGI

← CODATIについて