「出荷指示の取込も、在庫照会の一次対応も、AIで楽になるのは分かっている。ただ、あのデータは荷主から預かったものだ——外のAIに上げてよいのか、荷主AとBのデータが混ざらないのか、誰も答えを持っていない」。3PL・多荷主倉庫の現場責任者・荷主窓口・情報システムのあいだで、検討がこの一点で止まっている会社は少なくありません。この記事は、荷主から預かった出荷指示・在庫・届け先データを、契約と分離の面から整理してからAIにつなぐ——データ区分と許可範囲、受領から更新までの経路、荷主別の分離、荷主に確認する項目、ローカル・閉域でも残るリスク——を、AIに任せる範囲と人が確定する範囲の線引きとあわせて整理します。
3PL・物流倉庫でAI活用の話が出るとき、対象になる業務はたいてい具体的です。荷主ごとにバラバラなメール・Excelの出荷指示を読み取って取り込みたい。在庫照会や誤出荷申告の一次切り分けを速くしたい。送り状や宛先ラベルの転記をなくしたい。困りごとも、AIが助けになりそうな場所も、はっきりしています。
ところが検討を一歩進めると、多くの会社が同じ場所で止まります。そこで扱うデータのほとんどが、自社のものではなく荷主から預かったものだという現実です。出荷指示に書かれた品目・数量・出荷先は荷主の取引情報です。WMSの在庫データは荷主の資産の記録です。送り状の宛先は荷主の顧客の氏名・住所です。そして多荷主の倉庫では、これらが荷主ごとに別々の約束のもとで預かられ、同じ倉庫・同じシステムの中に同居しています。「このデータをAIに読ませてよいのか」「外部のサービスに送ってよいのか」「荷主Aの担当者に荷主Bの情報が見えないと言い切れるのか」——この問いに答える材料がないまま、検討が止まります。止まる理由としては、まったく正当です。
このとき起こりがちなのが、二つの極端です。一方は「荷主に説明できないからやらない」と着手を無期限に先送りすること。もう一方は「社内ツールだから大丈夫だろう」と、許可範囲を確認しないまま手元のデータで始めてしまうことです。前者は、確認すれば使えたはずの範囲まで含めて止まっています。後者は、後から荷主に説明を求められたときに、何をどこまで使ったかを答えられません。預かったデータは、一度扱いを誤ると自社の判断だけでは戻せないという意味で、社内文書より不可逆性が高い対象です。
この記事が扱うのは、その中間にある実務です。すなわち、AIをつなぐ前に、預かったデータの区分と許可範囲、データが通る経路、荷主別の分離、荷主に確認する項目を決めておくことです。出荷指示の読み取り・正規化・WMS取込という工程の実務は出荷指示メール・Excelの取込が、在庫照会・誤出荷問い合わせの一次切り分けは在庫照会・誤出荷問い合わせの一次対応が扱っており、本記事はその二つの手前にある前提条件——どのデータを、どの許可のもとで、どう分離してつなぐか——に絞ります。多荷主オペレーション全体の標準化の論点は3PL倉庫の多荷主オペレーションを参照してください。また、製造業で取引先から預かった図面・仕様書について同じ構造の問題を扱った姉妹記事として取引先図面を外部AIに送れない場合の設計があります。本記事は図面ではなく、物流の荷主データ——出荷指示・在庫・届け先——を対象にします。
最初の設計項目はデータ区分です。「倉庫のデータを全部AIにつなぐ」から始めると、契約の確認も分離の設計もできません。対象候補を区分ごとに書き出し、それぞれについて、契約上どんな利用が許されているか・AIに使う前に何を確認するかを決めます。下表は出発点として使える区分の例です。荷主ごとに契約の内容は異なるため、実際には荷主×区分の表になります。
| データ区分 | 含まれやすい情報の例 | 確認したい許可範囲の例 | 決めること（人の判断） |
|---|---|---|---|
| 出荷指示（メール・Excel・PDF） | 品目・数量・納期・出荷先。荷主の取引先名や販売動向が読み取れる | 取込・正規化のための読み取りが業務遂行の範囲か。処理場所に条件があるか | 読み取り結果の保存期間。原本メールの扱い。荷主への確認要否 |
| 在庫・入出庫・返品データ | SKU・ロット・数量・ロケーション。荷主の資産と商流の記録 | 照会対応・調査のための参照が範囲か。集計・分析への利用は別扱いか | 荷主別の参照範囲。荷主と取り決めた開示範囲との整合 |
| 届け先・宛先データ（送り状・宛先ラベル） | 氏名・住所・電話番号。荷主の顧客の個人に関する情報 | 出荷業務に必要な範囲を超える利用がないか。個人情報としての社内規程上の扱い | AIに渡す前に絞る項目。保持期間・削除・ログへの残り方（他区分より厳しく） |
| 荷主から預かった商品マスタ・規格情報 | 商品コード・名称・入り数・取扱条件 | 照合・正規化のための参照が範囲か | 荷主の更新とどう同期するか。古い版の扱い |
| 荷主との契約・料金・精算情報 | 保管料・荷役料の単価、精算条件 | 原則としてAI検索・取込の対象に含めない切り分け | 同じ基盤に載せない判断。載せる場合の閲覧者の限定 |
| 組み合わせで推測可能になる情報 | 荷主別の出荷量の推移＋出荷先＋品目を束ねると、取引関係や販売動向が推測できる | 単体では各区分の範囲内でも、横断で束ねる処理が許可の趣旨に反しないか | 何と何を同じ検索・分析の範囲に入れるか。荷主をまたぐ集計の可否 |
最後の行が、多荷主の倉庫では特に効いてきます。AIによる検索や集計は、これまで別々の帳票・別々の画面にあって事実上結合されていなかった情報を、一つの質問で束ねられるようにします。単体では預かった業務の範囲内の情報でも、荷主をまたいで束ねると、荷主同士の取引関係や事業の動きが推測できる——この性質があるため、区分の確認は「ファイル単位で機密か否か」ではなく「何と何が同じ処理の範囲に入るか」まで見ます。生成AIに渡してよい情報の社内基準づくりという一般論は入れてよい情報・いけない情報の線引きで扱っており、本記事はそれを「預かりデータ×多荷主」という条件に当てはめたものです。
「外部に送っていない」という言葉は、確認して初めて事実になります。出荷指示の取込や問い合わせ対応のAIは、推論だけで動いているわけではありません。メールの受領から、読み取り、保存、検索、連携、出力、そしてログや更新まで、それぞれの工程にデータの置き場と送信先があります。導入前に、少なくとも次の工程を確認します。
| 工程 | 何が通るか | 確認すること | 残るリスク・人が決める点 |
|---|---|---|---|
| 受領・アップロード | 出荷指示メール・添付Excel/PDF・FAX・スキャン画像 | 受領した時点で荷主識別子が付くか。共有メールボックスから取り込む範囲 | 宛先間違いで届いた他荷主宛のデータの扱いは人が判断 |
| 解析・OCR・抽出 | 帳票画像・本文・抽出された品目・数量・宛先 | 読み取り処理がどこで動くか。外部OCR・外部変換サービスを経由していないか | 抽出対象を許可範囲内のフィールドに限定する設定は人が確定 |
| 保存・インデックス | 原本・抽出結果・検索用インデックス・埋め込み | 保存場所と荷主別の分離。埋め込み生成が外部APIか社内か | 分離の方式（物理か論理か）の決定。原本と抽出結果の保持期間 |
| AI推論 | 質問文＋検索で取り出されたデータの断片 | 推論がローカル・社内サーバー・外部APIのどこで実行されるか。送信先の記録 | 外部APIを使う区分と使わない区分の線引きは契約確認の結果で人が決める |
| 連携ツール | WMS・基幹・チャット・ストレージへの要求 | 連携先の一覧。連携経由で荷主データが別システムへ複製されないか | 書き込みを伴う連携（WMS登録など）に人の承認を挟むか |
| 回答・出力 | 回答文・引用元・エクスポートファイル | 引用元のファイル名・件数・メタデータに範囲外の荷主情報が出ないか。出力の保存先と持ち出し経路 | 荷主・顧客へ送る文面は人が確定。出力の社外送信の可否 |
| ログ・キャッシュ・バックアップ・更新 | 操作ログ・会話履歴・検索キャッシュ・バックアップ世代・モデル/インデックスの更新物 | ログに荷主データの断片が複製されないか。バックアップの保存先と復元手順。更新の入手経路 | ログの閲覧者と保存期間。削除依頼が来たときにキャッシュ・バックアップまで消せるかの確認 |
この表は「全部を社内に閉じよ」という意味ではありません。区分ごとに確認した許可範囲によっては、外部サービスを使える工程もあります。重要なのは、どの工程で何がどこへ行くかを把握したうえで判断している状態を作ることです。把握していない経路は、判断もできず、荷主への説明もできません。文書を検索して答えさせる仕組み（RAG）の基本構造は社内文書をAIに答えさせる仕組み（RAG）とはで解説しています。
荷主から預かったデータの利用可否は、技術ではなく契約と荷主の意向で決まります。ただし、契約書に「AI」という言葉が書かれていることはまれです。実務で必要なのは、やりたい処理を契約が扱っている言葉——利用目的、複製、保管場所、第三者提供、再委託、返却・廃棄——に翻訳して確認することです。少なくとも次の点を、区分ごとに整理します。
なお、本記事は契約や法令の解説ではありません。契約の解釈、個人情報の法令上の整理、荷主への説明義務の有無といった判断は、社内の管理部門・法務、必要に応じて外部の専門家が確定する範囲であり、AIにも本記事にも代替させないでください。
多荷主の倉庫でAIを使う場合、荷主間の分離は「気をつける」ではなく設計項目です。分離が効いているかは、次の四点がすべて揃っているかで確認します。
この四点は、導入時に一度確認して終わりではありません。荷主の入替、担当替え、システム更新のたびにずれが生じ得るため、権限を絞った試験用アカウントで「範囲外が出ないこと」を確かめる点検を、運用の型として持ちます。
ここまでの整理で扱ってきたのは、主に「預かったデータが社外・許可範囲外へ出ないか」という軸です。もう一つ、これと混同されやすい別の軸があります。「社内の誰に、どのデータが見えるか」です。
外部送信を止めても、社内の誰もがすべての荷主のデータを検索できる状態は、預かりデータの管理としては説明がつきません。逆に、社内の閲覧権限を整えても、処理の一部が許可なく外部サービスを経由していれば、荷主への説明は崩れます。二つの軸は片方を解決しても他方が解決しない関係にあり、確認項目も異なります。前者は本記事の経路表（03節）と契約の確認（04節）、後者は検索・回答の場面でのアクセス制御——検索対象の分割、ID・グループとアクセス制御リストの同期、継承と例外、失効、引用元の表示——の設計です。後者の設計項目は社内文書AI検索の閲覧権限設計で詳しく扱っています。同記事は社内文書（規程・手順書・案件資料）を対象にしていますが、閲覧権限を検索側で保つ確認項目は、荷主データを社内の誰に見せるかの設計にもそのまま使えます。本記事側の固有の論点は、その権限の根拠が社内の組織ではなく荷主との契約と取り決めにある、という一点です。
構成の選択肢として、ローカルPC、社内ネットワーク上のサーバー、オンプレミス、閉域、クラウドとの併用（ハイブリッド）は、データ区分と契約の制約、既存環境、運用体制を確認したうえで選べます。荷主データのように社外送信の可否を自社だけで決められないデータがあるなら、社内で完結する構成は確認しやすい候補になります。構成ごとの費用や更新の違いはローカルLLMとクラウドLLMの比較で整理しています。
ただし、どの構成を選んでも、次のリスクは自社側に残ります。「ローカルだから」「閉域だから」で確認を省略できる項目は、この中に一つもありません。
確認項目に抜けがないかを体系的に照らす道具としては、NISTのAI Risk Management Framework 1.0が使えます。準拠や認証を名乗るためではなく、自社の確認リストの漏れを点検する観点として参照してください。機密性の高い現場データを前提としたAI構成の考え方の全体像はバーティカルAI×セキュリティで扱っています。
ここまでの設計の前提として、AIが担う範囲を先に確定しておきます。預かりデータを扱う場面でこの線引きが曖昧だと、「AIが処理したから」という誰も責任を持たない状態が生まれます。
| 工程 | AIに任せられると考えられる範囲 | 人が確定する範囲 |
|---|---|---|
| 棚卸し | 預かっているデータの区分・出所・保存場所の一覧の下書きを作る | 区分の確定と、対象に含めてよいかの決定（02節） |
| 契約の確認準備 | 確認したい処理の一覧化、荷主への質問リスト・確認書の下書き | 契約の解釈、利用可否の判断、荷主への送付と合意の確定 |
| 抽出・取込 | 許可が確認できた範囲内でのフィールド抽出、候補の提示、確信度の明示 | 抽出対象フィールドの決定、登録実行の承認 |
| 照会対応 | 権限の範囲内での該当データの候補・証跡の提示、確認チェックリストの生成 | 原因の確定、在庫や指示の修正、荷主・顧客への回答と約束 |
| 分離の点検 | アカウントと荷主の対応表・例外一覧・点検リストの下書き | 例外の承認と期限、分離方式の決定、点検結果の判定 |
| 保持・削除 | 保持期限が近いデータ・削除対象の一覧化 | 削除の実行判断と、契約終了時・削除依頼時の対応 |
| 判断 | 担わない（材料の提示にとどめる） | 法令・契約・個人情報・荷主への説明に関わる判断と、最終承認 |
この表で押さえたいのは、AIが抽出・提示できたことを「使ってよい根拠」として扱わないことです。AIは許可範囲を知りません。技術的に読めること・検索できることと、契約上それをしてよいことは独立しており、後者は04節の確認と人の判断だけが決めます。承認をどこに挟むかの一般的な考え方は任せる範囲と承認ポイントの設計を、後から経緯を説明できる記録の残し方はAIエージェントの監査証跡を参照してください。
荷主全社・全データを一度に整理してから始める進め方は現実的ではありません。次の順で、確かめながら広げます。
前提が整った後の実務——出荷指示の取込は出荷指示メール・Excelの取込、問い合わせの一次切り分けは在庫照会・誤出荷問い合わせの一次対応へ進んでください。取込・照会の先にある業務へ広げる際の全体像はAI業務コーディネーターで紹介しています。
そのままは使えない前提で始めるのが安全です。WMSの中のデータは自社の運用データに見えますが、実際には荷主から預かった出荷指示・在庫・届け先の情報が含まれています。荷主との契約や覚書で許されている利用目的は保管・入出庫・出荷といった業務の遂行であることが多く、AIによる解析や別システムへの複製がその範囲に含まれるかは、契約の文面と荷主の意向を確認しないと分かりません。確認の順序としては、まず対象にしたいデータの区分と出所（どの荷主から預かったか）を書き出し、区分ごとに契約上の扱いを確認し、判断がつかない区分は確認が済むまで対象から外すことです。契約の解釈と利用可否の確定は、担当者の推測ではなく人の判断として残します。
なくなりません。ローカルPC・社内サーバー・オンプレミス・閉域・ハイブリッドは、要件を確認したうえで選ぶ構成の候補であり、外部のAIサービスへ送らないという一点は確認しやすくなりますが、荷主の許諾、契約上の利用目的、多荷主の分離、保持と削除、運用の残りは別の問題として残ります。むしろ社内完結の構成では、広すぎる権限で動くサービスアカウント、権限や分離設定の同期漏れ、ログやバックアップへのデータ複製、更新媒体・遠隔保守・DNS/NTP・テレメトリといった細い経路、受領ファイル由来の指示の混入、出力の持ち出し、障害時の切替が自社側の宿題になります。構成の名前を結論にせず、契約と分離と経路の確認を一つずつ行うことが検討の実際の中身です。
受け取った時点で荷主識別子を付けること、保存とインデックスを荷主単位で分けるか論理的に区切ること、担当者のアカウント・グループと荷主の対応を機械が読める形で持つこと、そして出力側の確認です。見落とされやすいのは出力側で、回答の本文だけでなく、引用元のファイル名・該当件数・メタデータに他の荷主の名前や品目が現れる経路があります。荷主Aの担当者への回答に荷主Bのファイル名が引用として出れば、本文が出ていなくても混在です。確かめ方としては、権限を絞った試験用アカウントで検索と質問を行い、結果・要約・引用元・件数のいずれにも範囲外の荷主の情報が現れないことを、実際の画面で確認します。
出荷指示や送り状に含まれる届け先の氏名・住所・電話番号は、荷主から預かったデータであると同時に個人に関する情報でもあり、二重の確認が必要になります。実務的な進め方は、AIに渡す前に業務へ必要な範囲まで絞ることです。たとえば問い合わせの一次切り分けに住所の全文が要るのか、番地や電話番号を伏せた形で足りるのかを業務ごとに見ます。そのうえで、保存場所・保持期間・削除の手順・ログへの残り方を、他の区分より厳しく決めます。法令上の整理や荷主・本人への説明が必要かどうかの判断は本記事の範囲では扱えない人の判断であり、社内の管理部門や必要に応じて専門家に確認する事項として残してください。
対象にするデータの区分と利用目的を具体的に示したうえで、少なくとも五点です。(1)その処理が契約・覚書で許された範囲に含まれるか、(2)処理を行う場所と構成（社内で完結するか、外部サービスを使うか）に条件があるか、(3)保持期間と契約終了時の削除・返却の扱い、(4)外部ベンダーの関与が再委託などの取り決めに該当するか、(5)事故や想定外の参照が起きたときの連絡の取り決め。「AIを使ってよいですか」という抽象的な聞き方では荷主側も答えようがないため、データ区分・目的・場所・期間を一枚にまとめた確認書の形にすると確認が進みやすくなります。質問リストや確認書の下書きはAIに手伝わせることができますが、荷主への送付と合意の確定は人が行います。
任せやすいのは、預かっているデータの棚卸し（区分・出所・保存場所の一覧化）の下書き、許可が確認できた範囲内でのフィールド抽出や候補の提示、確認事項のチェックリストや荷主への質問リストの下書き、担当者への引き継ぎメモや回答文の下書きまでです。人が確定する範囲として残すのは、契約の解釈と利用可否、荷主への確認と合意、データ区分と保持・削除の決定、例外の承認、荷主・顧客への回答や約束、そして最終承認です。重要なのは、AIの出力を「使ってよい根拠」として扱わないことです。AIが抽出できたことと、そのデータを使ってよいことは別の問題であり、後者は契約と荷主の許諾で決まります。
まずは、荷主ごとにどの業務データを預かり、どの利用目的・処理場所・保存期間が許されているのかを、現行の契約・覚書と運用に照らして確認します。荷主別の識別子、保存先、出力先までつながらない箇所は、荷主・情報システム部門・委託先へ確認するための論点として残します。許可範囲や分離の前提が固まらない場合は、AI化を急がず、先に確認を進める選択をお伝えします。
荷主データの区分・許可範囲・分離の棚卸しを相談する