- AIの利用を禁止しても、たいていうまくいきません。社員は私用のスマートフォンで使い続け、会社からはそれが見えなくなります。
- データの種類によってリスクの大きさは違います。データをレベルに分け、どのレベルをどのAIで使ってよいかを決めます。
- 入札価格、契約書、顧客データのような機密文書が多い会社は、一人ひとりの権限の範囲で文書を読む社内AIを用意するべきです。
AIのチャットにデータを貼り付けると、何が起きるのか
購買担当者が、比較を手伝ってもらおうと、全仕入先の価格表をAIのチャットに貼り付けます。人事担当者は、グラフを作ってもらおうと、氏名と給与の一覧を貼り付けます。2人とも仕事を早く終わらせようとしただけですが、そのデータが社外に出たことを、社内の誰も知りません。
一般向けのAIサービスに貼り付けた文章は、サービス提供者のサーバーに送られて処理され、そのサービスのポリシーに従って保存されます。個人向けアカウントの中には、ユーザーが自分で設定をオフにしない限り、会話をモデルの改善に使うことを提供者に認めているものもあります。会社の側には、誰がいつ何を送ったのかという記録が一切残りません。顧客や監査人に聞かれても、会社は答えられないのです。

2023年5月、Samsungは社員が会社の端末で一般向けのAIツールを使うことを禁止しました。エンジニアが社内のソースコードと会議の記録をChatGPTに貼り付けていたことがわかったためです。会社が把握していないところでAIが使われるこうした状況はシャドーAI(Shadow AI)と呼ばれ、社員がスマートフォンを持つ会社ならどこでも起きています。
3つの選択肢と、それぞれで引き換えにするもの
会社の選択肢は3つです。利用を禁止するか、AI提供者の法人向けプランを契約するか、自社のインフラにモデルを導入するかです。それぞれ得られるものも費用も違い、ほとんどの会社は最終的に複数を組み合わせて使います。
| 選択肢 | 得られるもの | 引き換えにするもの | 向いている会社 |
|---|---|---|---|
| AIの利用を禁止する | 投資が要らない | 社員は私的な手段で使い続け、会社は効率と状況の把握の両方を失う | 法律や契約で全面的に禁じられている一部の業務 |
| AI提供者の法人向けプラン | 市場で最も性能の高いモデル、データをモデルの学習に使わないと明記した契約、社員アカウントの管理機能 | データは引き続き社外で処理されるため、利用条件とデータの保存場所を確認する必要がある | データの保存場所に制約がない大半の会社 |
| 社内またはプライベートクラウドで動かすプライベートLLM | データは自社のインフラにとどまり、権限と利用記録を自分で管理できる | サーバー代と保守費がかかり、自社で動かすモデルは大手提供者の最新モデルより性能が劣ることが多い | 契約上の機密情報やセンシティブデータを扱う組織、顧客や規制当局から要件を課されている組織 |
よくある誤解は、モデルを社内に導入すればデータは自動的に安全になる、というものです。社内AIがすべてのフォルダの文書を読めるなら、インターンでも経営幹部の給与を尋ねられます。リスクが社外への漏えいから部署をまたぐ漏えいに移るだけです。そのため社内AIには、質問した人に見る権限のある文書だけが見えるようにする必要があります。

架空のケース
エンジニアリングコンサルティング会社と、チャットに流れた見積提案書の下書き
社員120人のエンジニアリングコンサルティング会社は、日常的に入札に参加しています。あるエンジニアが、単価の入った提案書の下書きを一般向けAIのチャットに貼り付け、文章を整えてもらいました。たまたま通りかかった上司が、その画面を目にしました。話が経営層に上がったとき、最初に出た質問は、これまでに同じことが何回起きていたのかでしたが、誰も答えられませんでした。
経営層は禁止しないことに決めました。入札チームは大量の書類を書く必要があり、AIが実際に役立つとわかっていたからです。会社は下の方法でデータを4つのレベルに分け、「社内」レベルの業務には法人向けプランを契約し、「機密」レベルには社内アシスタントを作りました。このアシスタントは過去の提案書、業務の基準、契約書を検索し、質問した人に開く権限があるフォルダの文書だけを表示します。試験導入は、まず入札部門だけで始めました。
データを4つのレベルに分ける
- 「公開」は、すでに自社のWebサイトに載っている情報です。どのAIで使っても構いません。
- 「社内」は、マニュアル、業務手順、一般的な会議の記録です。会社が法人契約を結んでいるAIで使えます。
- 「機密」は、価格、原価、契約書、顧客データです。権限を管理し、利用記録を残す社内AIで使えます。
- 「極秘」は、健康情報、個人ごとの給与、契約で開示が禁じられている文書です。データの責任者と法律顧問が個別に承認するまで、AIに入力してはいけません。
使い方としては、各部門の責任者に、チームが最もよく使う文書を10種類選んでもらい、レベルに振り分けます。フォルダにレベルのラベルを貼り、その部門の実際の業務から例を挙げて社員に教えます。記録として残すべきなのは、文書の種類とレベルの一覧と、まだ振り分けていない文書の数です。この方法が失敗するパターンは2つあります。1つは、レベルを細かく分けすぎて社員が覚えられなくなることです。もう1つは、「機密」レベルを決めておきながら、そのレベルで使ってよいAIを用意しないことで、社員は結局、一般向けのツールに戻ってしまいます。
信頼できる社内AIアシスタントに必要なもの
文書をもとに答えるチャットボットなら、バイブコーディングで1日あれば作れます。時間がかかるのは、一人ひとりの権限に沿って答えさせること、元の文書を示せるようにすること、後から確認できる記録を残すことです。この3つがそろって初めて、法務部門とIT部門が利用を認めてくれます。
権限は、会社がすでに使っている社員アカウントの仕組みと結びつけるべきです。社員はSSOでほかのシステムと同じアカウントを使ってログインし、アシスタントはそのアカウントで開ける文書だけを検索します。社員が異動したり退職したりすると、アシスタントでの権限もすぐにそれに合わせて変わります。
すべての回答には、根拠にした文書を添えるべきです。質問した人は元の文書を開いて、回答がどの版から来たのかを確かめられます。先に文書を検索し、それからモデルに答えさせるこの仕組みをRAG(検索拡張生成)と呼びます。文書が修正されれば、モデルを再学習させなくても回答がそれに合わせて変わる、という利点もあります。
会社が決めなければならないことは、ほかにも2つあります。会話をどのくらいの期間保存するかと、利用記録を誰が見られるかです。文書に顧客の個人情報が含まれている場合、そのデータを外部の提供者に送って処理させることは、タイの個人情報保護法(PDPA)の対象になります。会社は提供者とデータ処理契約を結び、利用を始める前に法律顧問かデータ保護責任者に確認してもらうべきです。

開発チーム向け · 技術的な詳細
権限によるフィルタリングはベクトル検索の段階から行い、各文書の埋め込み(Embedding)と一緒にACLを保存します。アカウントはSSOで連携し、ユーザーグループを自動で同期します。質問、取得した文書、回答は監査ログに記録します。モデルルーティングを設定して、「機密」レベルには社内のモデルを、「社内」レベルには提供者のモデルを使います。社外に送る前にPII(個人を特定できる情報)をマスキングし、各部門の実際の質問から作った評価セットで、回答の正確さと引用の正しさを測ります。
次に当てはまるなら、プライベートLLMへの投資はまだ必要ない
- 会社のデータのほとんどが「公開」と「社内」のレベルにある
- データの保存場所を指定する契約や要件がない
- サーバーとモデルを保守する人材がまだチームにいない
こうした会社なら、法人向けプランとデータのレベル分けのルールを組み合わせれば十分です。「機密」レベルの業務が増えてきたら、その部分に限って社内アシスタントを追加します。
試験導入の期間には、4つの指標を測ってください。会社が承認したAIを使っている社員の割合、週あたりの質問数、正しい版の文書を引用した回答の割合、「機密」レベルのデータが社外に送られたのが見つかった回数です。3か月たっても社員が「機密」レベルの業務に一般向けのAIを使い続けているなら、社内アシスタントがまだ実務に十分応えられていないということです。ほかの部門に広げる前に、回答の質を改善してください。
文書を社内に置いたまま、チームがAIを使えるようにする
会社の権限の構造を知っているのはIT部門です。どの種類のデータに制約があるかを示すのは法律顧問とデータ保護責任者で、どの文書が機密かを知っているのは各部門の責任者です。DNA Makerはこの3者とワークショップを開いてデータをレベルに分け、文書がどこにあり、誰が開けて、社員がその文書から何を知りたいのかを地図にまとめます。
そのうえで私たちは、自社のインフラかプライベートクラウドに言語モデルを導入し、社内文書を検索して出典つきで答えるアシスタントを作ります。結果は質問した人の権限でフィルタリングし、監査ログを残し、利用開始前に回答品質の評価セットで確認します。作業は1つの部門での試験導入から始め、実際にどれだけ使われ、どれだけ正しく答えられるかを測ってから広げます。どの選択肢が自社に合うか迷っているなら、社員が最もよくAIに手伝わせている文書の種類の一覧を持って、ご相談ください。レベルの振り分けを手伝い、どの部分に社内のシステムが必要かをお示しします。
SOFTWARE ENGINEERING GLOSSARY
ソフトウェア開発用語集
経営層、IT部門、法務部門が、会社のデータとAIの使い方について合意するときに使う用語です。
| 用語 | 意味 | わかりやすい例 | 開発チームへの質問 |
|---|---|---|---|
| Private LLM | 自社が管理するインフラの上で動かす言語モデル。入力したデータは外部の提供者に送られない | 会社の契約書を検索するアシスタントが、自社のサーバールームにあるサーバーで動いている | サーバー代と保守費は年間いくらかかりますか?外部のサービスと比べて、回答の質はどのくらい違いますか? |
| On-premise | クラウドを借りる代わりに、自社の施設にあるサーバーにシステムを導入すること | モデルを動かすサーバーが本社のサーバールームに置かれている | 誰がサーバーを保守し、システムを更新し、故障したときに責任を負いますか? |
| Data Classification | データを機密性に応じてレベルに分け、レベルごとに保存、送信、利用の方法を決めること | 原価の価格表を「機密」レベルに分類し、社内AIでしか使えないようにする | まだレベルが決まっていない文書はどれですか?判断がつかないときは誰が決めますか? |
| Shadow AI | 会社が承認しておらず、把握もできていないAIツールを社員が使うこと | 社員が私用のスマートフォンで契約書を撮影し、AIアプリに要約させる | 今、社員がどのAIをどんな業務に使っているのかを、どうすれば把握できますか? |
| DLP | 重要なデータが社外に送られるのを検知して防ぐツール。Data Loss Preventionの略 | 誰かが大量の国民ID番号を外部のWebサイトに貼り付けると、システムが警告する | 設定したルールはどのレベルのデータを対象にしていますか?誤った警告はどのくらいの頻度で出ていますか? |
| Data Residency | データをどの国や地域で保存・処理しなければならないかを定めた要件 | 顧客との契約で、プロジェクトのデータはタイ国内のサーバーに置くことになっている | 自社のデータは、AIに送るときも含めて、どの国で処理されていますか? |
| SSO | 会社のアカウントで1回ログインすれば、複数のシステムに入れる仕組み。Single Sign-Onの略 | 社員は会社のメールアカウントでAIアシスタントに入り、退職するとすべてのシステムの権限が同時に止まる | 社員が異動したら、アシスタントでの権限はどのくらいの時間で切り替わりますか? |
