倉庫の運営者が新しいAIワークフローを見せてくれるたび、私がまず切り出す不都合な真実がある。巨大モデルにデータを入れた瞬間、それは床にこぼした水と同じだ。二度と取り戻せない。
ここ2年、AIを現場に導入する倉庫を数多く見てきた——WMSの出庫データをモデルに投げ込んで異常検知をさせたり、顧客の注文明細をAIアシスタントに食わせて日報を作ったり、ピッカーの作業実績シートを放り込んでシフトを組ませたり。成果は本当に目覚ましい。2時間かかっていた分析が数分で返ってくる。だが、そんな話を聞くたび、私の最初の質問は「どれくらい速い？」ではなく「そのデータ、ちゃんと下処理したの？」だ。
ほとんどの場合、答えはノーだ。倉庫のデータは無害そうに見えるからだ。SKUとケース数とロケーション番号だけじゃないの？違う。本物の出庫注文1件には、顧客の会社名と納品先住所、運送会社と交渉した実際の運賃レート、ピッカーの名前と勤務時間が隠れている。それがどこかの公開モデルの学習データに紛れ込んだ瞬間、あなたの価格戦略は見知らぬ人の目の前に広げられる。そしてカリフォルニア州のCCPA（2020年施行）も、EUのGDPRも、「うっかりだった」なんて言い訳には耳を貸さない——データ漏洩の請求書は、いつもデータを握っていた側に届く。
だから私の結論はこうだ。AIは大いに使えばいい。ただし倉庫のデータがどんなAIツールに触れる前に、必ず3つの門を通さなければならない——マスキング、アクセス制御、監査だ。どれか1つを欠いても賭けになる。
第一の門：マスキング——AIに顧客の素性を知らせない
マスキングとは名前をアスタリスクに置き換えることだと思っている人が多い。それだけではまったく足りない。倉庫データには、本当に危険なフィールドが3種類ある。
1つ目は顧客の特定情報だ。荷受人の会社名、住所、電話番号、メールアドレス。異常検知や日報作成に、AIは荷物が誰宛てかを知る必要はない——必要なのはその荷物だけだ。実務的な解決策：データが社外に出る前にマッピングテーブルを作り、本物の顧客IDと匿名トークンを対応付けておく。マッピングを保持するのは社内システムだけ。AIが見るのはトークンだけだ。
2つ目は商流の機密情報だ。運賃レート、顧客への見積単価、運送会社との精算価格。これは倉庫事業の至宝そのものだ。かつてカリフォルニアの3PLが、1年分の出庫データ——実際の運送レート付き——をAIツールに貼り付けてコスト分析をしたのを見たことがある。分析は見事に出来上がった。そしてそのレートは今、よそ様のサーバーに住んでいる。レート系のフィールドは、データの流れから完全に抜くか、帯域にまとめるか（「平均より上／平均より下」）のどちらかだ。そのままの形で送ることは絶対にない。
3つ目は従業員の個人データだ。氏名、勤務時間、生産性スコア、出勤記録。シフト最適化や生産性分析では確かに人のデータを使うが、AIが見るべきは「ステーションAのピック率」であって、「昨日Johnが何個ピックしたか」ではない。従業員IDはハッシュ化する。名前は社外に出さない。
ここには正直に言っておくべきトレードオフがある。マスキングを強くすればするほど、AIの分析力は弱まる。顧客名をすべて匿名化すれば、モデルは顧客セグメンテーションができなくなる。私の経験則は、データの行き先でマスキングの強度を変えることだ。オンプレミスに置いたAIツール（データが自社サーバーを出ない）なら軽いマスキングで十分。外部ベンダーやパブリッククラウドのAIサービスに送るものは強いマスキングだ。安全性と有用性のバランスに万能解はなく、決め手は「データが自社の境界を越えるかどうか」だ。
第二の門：アクセス制御——この蛇口を開けるのは誰でもいいわけじゃない
マスキングが決めるのは、AIが何を見られるかだ。アクセス制御が決めるのは、そもそも誰がデータをAIに渡してよいかだ。
私が見た中で最も恐ろしい構成はこうだ。WMSのホーム画面にAIアシスタントがピン留めされていて、誰でも使える。ピッカーが注文のスクリーンショット——顧客住所つき——を貼り付けて「これどう処理したらいい？」と聞く。データはその瞬間、社外に出た。AIツールへのアクセスはWMSのデータ権限と一致させなければならない。システム上でレート系フィールドを見られない人は、レート系フィールドをAIに渡してもいいわけがない。
実装は3層に分ける。第一にロール階層。本当に必要なロール——データアナリスト、オペレーションマネージャー——だけが、AIツールでフルデータにアクセスできる。現場オペレーターがAIアシスタントを使う場合は、データソースが既に衛生処理されたプリビルドのQ&Aシナリオだけを使う。第二にデータのホワイトリスト。どの種類のデータを、どの目的でAIに渡してよいかを明示したリストだ——例：「許可：需要予測のための匿名化された入出庫量。不許可：顧客情報を含む生の注文明細」。第三に技術的なチェックポイント。データの出口にゲートウェイを置く。外部のAIサービス宛てのリクエストはすべてスキャンして、顧客名、住所、レート、従業員名などの機密フィールドがあればブロックしてフラグを立てる。このゲートウェイが一番大事だ。誰の善意にも依存しないからだ。
もう1つ、見落としがちなアクセス制御の罠がある。ベンダーのアカウントだ。多くのAIツールはSaaSで、トラブルシューティングのためにベンダーのサポートエンジニアが一時的なデータアクセスを求めてくることがある。契約で明文化しておくこと。ベンダーのアクセスは承認を経て、期限付きで、監査可能にすること。インシデントの後になって「3カ月前にフルアクセスを与えたきりで、誰も取り消していなかった」と気づくことのないように。
第三の門：監査——何か起きたとき、説明できる物語が必要だ
最初の2つの門は予防だ。第三の門はセーフティネットだ。万が一何かが起きたとき、誰が、いつ、何のデータを、どのAIに、何の目的で送ったかを語れるか。
記録は3種類残す。第一にデータフローログ。外部のAIサービス宛てのリクエストはすべて記録する——タイムスタンプ、操作者、データ種別、データ量、宛先サービス。このログは自社のインフラに置く。ベンダーのダッシュボードには置かない。ダッシュボードはベンダーのものだ。紛争になったとき、「うちのログはもう期限切れです」と言われれば、何も残らない。
第二に、データに触れるすべてのAIベンダーとのデータ処理契約。DPAでは4点を固めること。あなたのデータはモデルの学習に使わない。データの保持期間。削除の手順。侵害が起きた場合の通知期限。この契約にサインしないベンダーに、データを流してはいけない。機能と価格だけでAIツールを選んで契約書のページを飛ばすチームが多すぎる——私が見てきた中で最も高くついた「節約」だ。
第三に四半期ごとのアクセス見直し。四半期に1度、確認すること。AIツールのアカウントは今も在職者の手にあるか。退職者のアクセスは取り消されているか。ホワイトリストは今も正しいか。権限は在庫と同じで腐る。循環棚卸をサボればズレていく。この見直しは四半期のオペレーション会議のアジェンダに載せて、在庫差異や安全点検と同じチェックリストに入れておくことを勧める。誰も忘れなくなる。
まず門をくぐれ、効率化を追うのはそれからだ
3つの門を読み通すと、面倒に思えるかもしれない。計算してみれば見え方は変わる。顧客データの漏洩1件で、CCPAの罰金と顧客の損害賠償を合わせれば、中規模3PLの年間利益が丸ごと吹き飛ぶことも珍しくない。マスキング、アクセス制御、監査の構築は、IT担当1人とオペレーション責任者1人で数週間だ。難しい計算じゃない。
私が勧める順序はこうだ。まず棚卸し（データの中の機密フィールドをすべて洗い出す）。次にマスキング（マッピングテーブルとフィールドルールを作る）。次にアクセスを固める（ゲートウェイ＋ホワイトリスト）。最後に監査で回路を閉じる（ログ、DPA、四半期見直し）。この4ステップが終われば、あとは気兼ねなくAIを使えばいい。
持ち帰ってほしい問いが1つある。あなたの倉庫が今使っているAIツールの中で、「データがどこに保存されているか」「そのデータがモデル学習に使われているかどうか」を正直に言えないものはないだろうか。あるなら、調査はそこから始めよう。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
