AIに渡してよい情報をどう決めるか — 機密区分とデータ分類の実務

多くの企業のAI利用ルールには「機密情報を入力しないこと」と書かれています。では、何が機密情報なのか。この問いに即答できる社員がどれだけいるでしょうか。データ分類が曖昧なままのAI利用ルールは、判断を毎回、現場の社員に丸投げしているのと同じです。AI利用を前提にしたデータ分類の作り方を整理します。

なぜAI利用で分類が前に出てくるのか

データ分類自体は昔からある実務です。ただ、AI以前は「社外秘の文書を社外の人に渡す」ような明確な場面で機能すれば足りました。生成AIの利用は、この前提を変えます。

• 判断の頻度が桁違いに増える — AIへの入力は1日に何十回も発生し、その都度「これは入れてよい情報か」の判断が要る
• 境界が見えにくい — 「社外に送る」感覚がないまま、入力は外部サービスへ送信される
• 混ざる — コードの中に顧客名が、議事録の中に未公開の数字が。文書単位ではなく断片単位で機密が混入する

頻度が増えるほど、人の判断は雑になります。だから分類は「判断を正確にさせる」ためではなく、「判断の回数を減らす」ために設計し直す必要があります。

区分の作り方 — 3〜4段階・AIでの扱いと1対1

段階は少なく

区分が多いほど精密に見えますが、現場の判断は遅く・不正確になります。多くの一般業務では、まず3〜4段階から始めるのが扱いやすい構成です（個人情報・医療・金融・輸出管理など規制対象の情報を持つ場合は、法令・契約に応じた区分を追加します）。

重要なのは右の列です。区分ごとに「AIでどう扱えるか」を1対1で対応づけること。「機密度に応じて適切に」のような余白を残すと、結局その場の判断に戻ります。

迷う情報の倒し方を先に決める

分類で現場が止まるのは、境界例です。「これは社内か機密か」と迷ったとき、どちらに倒すか。迷ったら上の区分（安全側）と、あらかじめ決めておきます。同時に、上に倒しても仕事が止まらないこと（機密区分でもAIを使う手段があること）が、このルールを守れるものにします。安全側に倒すと仕事ができなくなる設計では、現場は下に倒し始めます。

「断片」の扱いを書く

AI利用特有の論点として、文書単位ではなく断片の混入があります。「機密文書の一部を含むテキストは機密として扱う」と一文入れておくと、「全部じゃないからいいか」という抜け道を塞げます。

分類を構造で支える

ここまでは紙の上の設計です。分類が実際に守られるかは、運用が人の判断にどれだけ頼るかで決まります。

理想は、区分とAI環境の対応が、環境として分かれていることです。機密区分の情報は機密用のAI環境（外部に送信されない環境）に置かれ、その環境でだけAIに処理させられる。通常のAI環境には機密区分の情報がそもそも存在しない。この構造があると、「入れてよいか」の判断は「どの部屋で仕事をするか」という、間違えにくい判断に置き換わります（クラウドLLMとローカルLLMの使い分け）。

機密区分の情報をAIで扱う環境としては、ローカルLLMのように社内に閉じたAI環境が選択肢になります（機密データをAIに扱わせたい）。一方、外部のクラウドAIへ送る区分については、送信先サービスの規約確認が対になります（「学習に使われない」は十分か）。

まとめ

• 「機密はAIに入れるな」は、データ分類が曖昧なままでは判断の丸投げにしかならない
• 区分は3〜4段階。各区分に「AIでの扱い」を1対1で対応づけるのが要点
• 迷ったら上の区分へ。ただし上の区分でもAIが使える手段を用意して、安全側に倒せるようにする
• 分類は構造で支える。区分ごとに環境を分ければ、判断は「どの部屋で働くか」に単純化される

紙の上の分類表は、そのまま部屋の分け方に落とすこともできます。Hoko（矛）は、機密区分の情報を扱う部屋（ローカルLLMのみ・外部遮断）と通常の部屋を分けて提供するAIエージェント実行アプライアンスで、区分と環境の対応を2つのルームとして持ちます。