取引先の図面・仕様書を外部AIに送れない｜社内ネットワークでAI検索・照合を始める前の設計と確認

1. 背景と課題
2. 構成の選択肢
3. データ区分の決め方
4. データが通る経路の確認
5. 最小権限と人の承認
6. ログの設計
7. 閉域でも残る経路
8. 障害時の設計
9. AIと人の分担・進め方
10. よくある質問
11. 関連記事・関連ソリューション

「外部AIに送れない」で止まっている検討を、どこから動かすか

取引先から預かる図面や仕様書には、秘密保持契約や取引基本契約で持ち出し・目的外利用・第三者提供の制限が付いていることが多く、外部のAIサービスへ送信してよいかどうかを自社だけで決められません。一方で現場の困りごとは具体的です。図面が図番で引けない、仕様書のどの版が最新か分からない、取引先要求事項がどの文書に書いてあったか探せない。検索と照合の準備にAIを使いたい理由ははっきりしているのに、「送れない」の一点で検討全体が止まります。

このとき起こりがちなのが、両極端への振れです。一方の極は「使えないので何もしない」。もう一方の極は「ローカルLLMなら安全らしいので、まず入れてみる」。どちらも、判断の材料が揃っていない点では同じです。前者は選択肢の確認をしておらず、後者は構成の名前を安全性の結論と取り違えています。

この記事で扱うのは、その間にある実務です。すなわち、どのデータを対象にするかの区分、データが通る経路の洗い出し、権限・承認・ログの設計、閉域でも残るリスクの確認、障害時の手順を、仕組みを入れる前に決めることです。図面から図番・版数・材質・公差を抽出して見積準備を整理する工程そのものは図面見積の準備と類似加工実績の検索で扱っており、本記事はその手前——そもそもどの環境で、どの範囲のデータを対象に始めてよいかを決める部分——に絞ります。

なお、共同開発や協業の文脈で相手から受け取るデータ・知財の扱いを契約面から整理したい場合は、共同開発の知財・データ取り扱いもあわせて参照してください。本記事は契約の解説ではなく、契約上の制約を前提にした社内側の設計を扱います。また、物流・3PLで荷主から預かった出荷指示・在庫・届け先データについて同じ構造の問題を扱った姉妹記事として荷主データを外部AIに送れない場合の設計があります。本記事は図面・仕様書という貸与文書を対象にし、同記事は多荷主の業務データと契約・分離の設計を対象にしています。

社内で完結させる構成は「選べる選択肢」。ただし単一の正解ではない

まず前提を整理します。現在は、ローカルPC上で動くモデルや、社内ネットワーク内のサーバーに検索基盤と推論環境を置く構成が現実的な選択肢になっており、要件を確認したうえで、推論・文書検索・照合の処理を社内ネットワークの内側で完結させる構成を選ぶことができます。外部のAIサービスに図面を送らないという一点を確認しやすいのが、この構成の特徴です。

ただし、ここで断定を避けたいことが二つあります。

• クラウド・オンプレ・閉域・ハイブリッドのどれが正解かは、一般論では決まりません。扱うデータの区分、取引先との契約、既存のネットワーク構成、サーバーとGPUの調達、運用できる人員によって、妥当な構成は会社ごとに変わります。社外送信に問題のないデータしか扱わないなら、クラウドの方が更新や運用の面で扱いやすい場合もあります。データ区分ごとに処理場所を分けるハイブリッドも選択肢です。
• すべての会社に社内完結構成を提供できると約束するものでもありません。設置環境・データ量・既存システムとの接続方法によっては、要件確認の段階で別の構成や段階的な進め方をおすすめすることがあります。

ローカルとクラウドの一般的な比較——費用構造、モデルの更新、得意な処理の違い——はローカルLLMとクラウドLLMの比較で整理しています。また、機密性の高い現場データを前提としたAI構成の考え方の全体像はバーティカルAI×セキュリティで扱っています。本記事は以降、「取引先図面・仕様書を含むデータを、社内ネットワーク内で検索・照合する」場合に絞って、始める前の設計項目を順に見ていきます。

何を対象にするかを決める——単体では無害でも、組み合わせは別物

最初の設計項目はデータ区分です。「社内の文書を全部検索対象にする」から始めると、権限の設計もログの設計もできません。検索・照合の対象にする候補を区分ごとに書き出し、それぞれについて、対象にしてよいか・誰まで見せてよいか・どの環境で処理してよいかを決めます。

最後の行が見落とされがちです。横断検索は、これまで別々の場所にあって事実上結合されていなかった情報を、一つの質問で束ねられるようにします。単体では公開しても差し支えない情報同士でも、組み合わせると取引条件や開発中の製品が推測できる——この性質があるため、区分の確認は「ファイル単位で機密か否か」だけでなく「何と何が同じ検索範囲に入るか」まで見ます。取引先の規格書・変更連絡が散在する構造とその整理は商品規格書・原材料表示の改訂準備でも扱っており、区分の考え方は図面以外の預かり文書にも同じように当てはまります。

入力から更新まで、データがどこへ出ていくかを工程ごとに見る

「社内で完結」という言葉は、確認して初めて事実になります。AI検索・照合の仕組みは、推論だけで動いているわけではありません。文書の取込、検索インデックスの作成、ツール連携、監視、バックアップ、そして各種の更新——それぞれの工程に送信先と経路があり、そのどれか一つが外へ抜けていれば、推論をローカルにした意味は薄れます。導入前に、少なくとも次の工程について送信先・経路を確認します。

この表は「全部を閉じよ」という意味ではありません。たとえば監視やバックアップを外部サービスに置く判断はあり得ます。重要なのは、どの工程で何が外へ出るかを把握したうえで判断している状態を作ることです。把握していない経路は、判断もできず、取引先への説明もできません。社内文書を検索して答えさせる仕組み（RAG）の基本構造は社内文書をAIに答えさせる仕組み（RAG）とはで解説しています。

モデルに広い権限を渡さない——閲覧・検索・送信・更新・制御を分ける

社内で完結する構成にすると、今度は社内側の権限設計が主戦場になります。外部への送信を止めても、社内の誰もがあらゆる図面を検索できる状態は、貸与図面の管理としては説明がつきません。設計の原則は最小権限です。

• 文書閲覧・検索・送信・基幹更新・設備制御の権限を分離する。検索できることと、原本を開けることは別の権限です。回答を社外へ送ること、基幹システムを書き換えること、設備に指示を出すことは、さらに別の、より強い権限として扱います。
• 利用者の権限を検索に反映する。担当する取引先・所属部門の範囲でだけ候補が返る構造にし、権限外の文書は検索結果にも要約にも現れないようにします。
• モデル自体に広い権限を直接渡さない。AIには、その利用者・その用途に必要な範囲の読み取りだけを許し、書き込みや送信を伴う操作は既定で持たせません。
• 影響の大きい操作には人の承認を挟む。社外への送信、基幹データの更新、権限範囲の変更のような高リスク操作は、AIが下書き・提案までを担い、実行の確定は人が承認する構造にします。

権限をどう最小に区切るかの具体的な考え方はAIエージェントの権限設計で、どの操作に承認を挟むかの決め方はAIエージェントに任せる範囲と人の承認ポイントの設計で詳しく扱っています。また、図面以外の社内規程・手順書・案件資料までを検索対象に広げるときに、部署別・案件別の閲覧権限を検索結果・要約・引用元まで通す設計は社内文書AI検索の閲覧権限設計で扱っています。

追跡できるログを残しつつ、ログ自体を第二の機密にしない

貸与図面を扱う仕組みでは、後から経緯を説明できることが要件になります。取引先から管理状況を問われたとき、抽出の誤りを遡って直すとき、想定外の参照が起きたときの根拠は、すべてログです。最低限、次の項目を追跡できるように設計します。

• 誰が・いつ使ったか（利用者と時刻）
• どのデータ区分の文書に触れたか（03節の区分と対応させる）
• どのモデル・どのルールの版で動いていたか（後から挙動を再現・説明するため）
• 何を要求し、高リスク操作については誰が承認したか

同時に、逆向きの設計も必要です。ログに質問文や文書の断片をそのまま残すと、ログ自体が機密の複製になり、ログの閲覧権限を持つ人が事実上すべての図面情報に触れられてしまいます。追跡に必要な識別子は残し、内容はマスキングする。ログを閲覧できる人を限定する。保存期間を決め、期間を過ぎたログは廃棄する。バックアップに含まれるログも同じ扱いにする。——「何でも記録する」と「何も漏らさない」の間の設計であり、ここは記録の粒度を決める作業です。監査に耐える記録の残し方はAIエージェントの監査証跡で扱っています。

「閉域だから安全」とは言えない理由を、経路で確認する

ネットワークを閉じると、外部AIサービスへの送信という分かりやすい経路は塞がります。しかしそれで確認が終わるわけではありません。閉域構成でも、少なくとも次の経路は個別に確認が必要です。

• 資料経由の間接プロンプトインジェクション。AIが読み込む文書の側に、AIへの指示として作用する文字列が含まれている場合があります。取引先から受け取った外部由来のファイルや、検索対象に加えたRAG資料は、閉域の内側に入った後もこの性質を持ち続けます。利用者が何も悪い入力をしなくても、資料を読んだAIの挙動が変わり得る——これが間接型の厄介さで、ネットワークの閉鎖では防げません。対策は05節の権限分離と承認で影響を限定することです。この類型はOWASPのLLM01:2025 Prompt Injectionに整理されており、設計時の確認観点として参照できます（本記事は同文書への準拠を主張するものではありません）。
• 更新媒体。閉域環境のモデル・OS・ドライバ・検索インデックスは、USBメモリや持込PCなどの媒体経由で更新されることが多く、この媒体が事実上の外部接点になります。入手元の確認、持込媒体の管理、更新前の検証を運用に組み込みます。閉域でのモデル更新の運用は閉域ネットワークでのローカルLLMモデル更新で扱っています。
• DNS・NTP・遠隔保守・テレメトリ。完全に閉じているつもりの環境にも、名前解決や時刻同期、機器ベンダーの遠隔保守回線、OSや機器が送る診断データといった細い通信が残っていることがあります。一つずつ、存在の確認と、残す場合の内容の確認をします。

リスクを洗い出す作業全体の枠組みとしては、NISTのAI Risk Management Framework 1.0が、AIシステムのリスクを特定・評価・管理する際の観点を整理しており、こちらも準拠を名乗るためではなく、自社の確認項目に抜けがないかを照らす道具として使えます。工場のOTネットワーク側の閉域設計は工場のOTセキュリティと閉域ネットワークのAIも参照してください。

止まったときの流れを先に決める——バックアップは「戻せて」初めて要件を満たす

社内で完結する構成は、外部サービスの障害に業務が引きずられない代わりに、障害からの復旧も自社側の仕事になります。稼働率や復旧時間をあらかじめ約束することはできない前提で、止まったときに何が起こるかを先に決めておきます。流れは次の順です。

1. 検知。検索が返らない、回答の品質が急に変わった、想定外の参照がログに現れた——気づくための監視項目を決めておきます。
2. 切り分け。モデルか、検索インデックスか、サーバーか、データかを切り分けられるよう、構成図と確認手順を平時に用意します。
3. 停止・隔離。疑わしい挙動——たとえば資料経由の注入が疑われる場合——は、原因究明より先に該当機能を止める・切り離す判断ができるようにします。止める権限を誰が持つかも決めておきます。
4. 人手業務への切替。AI検索が使えない間も見積・照合の業務は続きます。導入前の手順書とファイルの置き場所を「切替先」として維持し、切替の宣言の仕方を決めておきます。
5. 復旧。バックアップは、取ってあることではなく戻せることが要件です。文書・インデックス・設定・ログのそれぞれについて、復元テストを実施して所要と手順を確認しておきます。
6. 記録と再発防止。何が起き、いつ検知し、どう切り替えたかを記録し、確認項目（03〜07節）へ反映します。取引先に説明が必要な事象かどうかの判断も、この記録が根拠になります。

この流れの本質は、障害をゼロにする約束ではなく、障害が起きても業務と説明責任が崩れない構造を先に作ることです。

AIに任せる範囲と人が確定する範囲、そして始める順序

ここまでの設計を踏まえて、仕組みが担う範囲を確定します。機密資料を扱う場面では、この線引きを曖昧にしたまま始めないことが、権限設計とログ設計の前提にもなります。

進め方は、小さく始めるのが現実的です。

1. データ区分表（03節）を書く。対象候補の区分と、それぞれの制約・閲覧範囲を1枚にします。契約の確認が必要な区分は、確認が済むまで対象から外します。
2. 経路表（04節）を埋める。検討中の構成について、8つの工程の送信先を確認します。埋まらない欄が、ベンダーや情報システム部門への質問リストになります。
3. 1区分・1部門で始める。たとえば「特定の取引先1社の図面と授受記録だけ」を対象に、閲覧権限を担当チームに絞って検索・照合を試し、権限どおりに候補が絞られるか、引用元が正しく表示されるか、ログが設計どおり残るかを確かめます。
4. ログと承認の運用を確かめてから広げる。高リスク操作の承認が実際に機能しているか、ログに機密が複製されていないかを確認したうえで、対象の区分と部門を広げます。

検索・照合の先にある業務——見積準備、規格書の改訂準備、社内問い合わせ対応——へ広げる際の全体像はAI業務コーディネーターで紹介しています。

よくある質問

ローカルLLMや社内サーバーで動かせば、図面の漏えいの心配はなくなりますか

なくなるとは言えません。社内ネットワークで推論と検索を完結させる構成は、外部のAIサービスに図面を送らないという一点については確認しやすい選択肢ですが、それだけで安全と呼べる状態にはなりません。RAGの資料経由の間接プロンプトインジェクション、モデルや検索インデックスの更新に使う媒体、DNS・NTP・遠隔保守・機器のテレメトリといった経路は、閉域構成でも個別に残ります。また、社内の権限設計が粗ければ、閲覧してよくない人が検索経由で図面に届く経路が社内に生まれます。構成の名前ではなく、データが通る経路と権限とログを一つずつ確認して初めて、自社にとっての妥当性を判断できる状態になります。

クラウド・オンプレ・閉域・ハイブリッドのどれを選ぶべきですか

どの業種・どの会社にも当てはまる単一の正解はないと考えるべきです。判断の材料になるのは、扱うデータの区分（貸与図面か、自社資料か、原価を含むか）、取引先との契約で許される処理の範囲、既存のネットワークとサーバーの構成、運用できる人員です。取引先図面のように社外送信の可否を自社だけで決められないデータがあるなら、ローカルPCや社内サーバーで推論・検索を完結させる構成が選択肢に入りますし、社外送信に問題のないデータだけを扱うならクラウドの方が運用しやすい場合もあります。両者を組み合わせ、データ区分ごとに処理場所を分けるハイブリッドも選択肢です。要件を確認したうえで選ぶものであり、先に構成を決めてからデータを合わせるのは順序が逆です。

閉域ネットワークならプロンプトインジェクションは防げますか

防げるとは言えません。プロンプトインジェクションには、利用者が直接入力するものだけでなく、AIが読み込む資料の側に指示が仕込まれている間接型があります。取引先から受け取ったファイルや、検索対象に加えた文書の中の文字列が、AIへの指示として作用する可能性は、ネットワークが閉じていても残ります。対策は防げると宣言することではなく、影響を小さくする設計です。モデルに広い権限を直接渡さず、文書閲覧・検索・送信・基幹更新の権限を分け、外部由来の資料を扱う処理では出力の扱いを限定し、送信や更新のような影響の大きい操作は人の承認を挟みます。OWASPが整理しているLLM Prompt Injectionの解説は、この設計時の確認観点として参照できます。

社内AI検索を入れた場合、AIにはどこまで任せられますか

任せやすいのは、権限の範囲内にある資料の一覧化、条件に合う文書・図面の候補検索、回答に引用元を添えて表示すること、版や文書間の差分候補の提示、足りない資料や記載の確認、そして確認事項や照合結果の下書きまでです。一方で、NDA・知財・取引先要求事項への適合の判断、図面の解釈、どの版が正しいかの確定、品質・安全・法令に関わる判断、価格・納期・発注の決定、顧客への送信、基幹システムの更新は、人が確定する範囲として残します。AIの出力は探索の起点と下書きであり、確定の根拠として扱わないことが、機密資料を扱う場面ではとくに重要です。

障害やAIの誤りが起きたときは、どう備えればよいですか

検知、切り分け、停止・隔離、人手業務への切替、復旧、記録と再発防止という流れを、起きる前に決めておくことが備えになります。社内で完結する構成は、外部サービスの障害に引きずられない代わりに、復旧も自社側の仕事になります。検索が使えない間も見積や照合の業務が止まらないよう、AI導入前の手順を人手業務への切替先として残しておきます。バックアップは取ってあることではなく戻せることが要件なので、復元テストまで実施します。なお、稼働率や復旧時間をあらかじめ約束することはできない前提で、どこまで止まったら人手に切り替えるかの判断基準を先に決めておく方が実務的です。

関連記事・関連ソリューション