図面をAIに渡す前に決めること｜「再学習に使わない」だけでは足りない理由

こんにちは、株式会社TIMEWELLの濱本です。

「図面はAIに入れられないんですよ」。製造業の方と話すと、まずこれを言われます。その感覚は正しいと思います。ただ、なぜ入れられないのかを制度の言葉で説明できるかというと、そこは怪しい。理由が言葉になっていないと、対策は「とりあえず様子見」で止まります。

実は国が、2025年3月にはっきり線を引いています。経済産業省の営業秘密管理指針の改訂で、脚注にこう書き込まれました。

ただし、当該企業にとどまらず、当該情報αが当該企業以外の第三者（例えば、生成 AI 提供事業者等）に提供される場合は、秘密管理性が否定される場合もあり得る。¹

生成AI提供事業者を名指しした一文です。この記事では、この線がどこに引かれているのかを一次情報で確認し、預かった図面の扱い、処理する場所の段階、そして自社で動かす場合の現実の制約までを整理します。図面をデータ化する技術そのものは紙図面・PDFのデジタル化とは？に、製造業のAI活用の全体像は製造業のAI・DX完全ガイドに書いたので、ここでは「渡してよいのか」という一点に絞ります。

日本の不安は「外に出る」の一点に偏っています

先に数字から。総務省の令和8年版情報通信白書（2026年7月24日公表）に、企業が生成AIの活用に関して懸念するリスクの国際比較があります。調査は2026年1月から2月、日本の有効回答は515社（大企業353社・中小企業162社）です²。

日本の1位は「社内情報の漏洩などのセキュリティリスクがある」で46.4%。米国36.9%、ドイツ31.7%、中国42.7%を上回り、4か国で最も高い数字です³。

面白いのは、その裏側です。「出力結果に倫理上不適切な内容や偏見が含まれる可能性がある」は日本24.7%に対し、米国38.5%、ドイツ35.9%、中国45.0%。「個人情報の取り扱いなどプライバシーの侵害の可能性がある」は日本24.5%に対し、米国38.2%、ドイツ44.0%、中国43.4%³。倫理もプライバシーも、日本は4か国でいちばん低いのです。

つまり日本企業の不安は、「うちの情報が外に出る」という一点にかなり偏っています。私はこの偏りを、製造業にとっては合理的なものだと考えています。図面は技術情報そのものです。倫理的な出力の是非より、外部に出るか出ないかのほうが先に来る。それは当然でしょう。

ただ、ここから先が問題です。恐れているのに、その恐れを止める手が打たれていません。リスク対策の取組状況を見ると、日本は「全社的な指針やガイドラインを整備している」が41.1%で最多。ところが、いちばん直接的な対策である「生成AIへの入力データを学習データとして利用できない仕組みを導入している」は19.9%にとどまります。米国32.2%、ドイツ34.1%、中国47.8%です³。生成AIによる業務変革について「組織的な取組はない」と答えた企業も27.0%あり、中小企業では45.6%に達します³。

もうひとつ。生成AIを何らかの業務で使っている日本企業は86.4%まで来ました。前年度調査の55.2%から大きく伸びています。にもかかわらず、「生成AIに社内データを学習させたり、生成AIが参照可能なデータベースを構築したりしている」のは24.5%だけで、白書本文は他の3か国より顕著に低いと指摘しています⁴。使ってはいるが、本丸のデータには繋いでいない。恐れが対策ではなく先送りに変換されている状態です。自社の現在地が気になる方は、先にAI導入診断で確かめてから読み進めてください。

国は「AI禁止」と言っていません。線を引いています

では制度側は何と言っているのか。ここを誤解している方が多いので、丁寧に確認します。

前提として、不正競争防止法の営業秘密は第2条第6項でこう定義されています。「秘密として管理されている生産方法、販売方法その他の事業活動に有用な技術上又は営業上の情報であって、公然と知られていないものをいう」⁵。ここから秘密管理性、有用性、非公知性の3要件が導かれます。ちなみに条文自体には「秘密管理性」という言葉は出てきません。この呼称は経済産業省の営業秘密管理指針の側にあります⁵。

その営業秘密管理指針（平成15年1月30日策定、令和7年3月31日最終改訂）が、外部サービスの利用についてこう書いています。

また、外部のクラウドを利用して営業秘密を保管・管理する場合も、秘密として管理されていれば、秘密管理性が失われるわけではない。¹

失われるわけではない、と明記しています。ここが出発点です。そのうえで冒頭に引いた脚注が付きます。自社にとどまらず、第三者（例として生成AI提供事業者等）に提供される場合は、秘密管理性が否定される場合もあり得る¹。

2つを並べると、国が引いている線がはっきりします。線は「AIを使うか使わないか」ではありません。社内の管理下にとどまる利用か、第三者に提供される利用かです。この線引きで考えると、対策の方向も変わります。使うのをやめる、ではなく、どこで処理するかを設計する、になります。

もう一点、安心してよい話も書いておきます。秘密管理措置は過剰でなくてよいのです。同指針は、必要な秘密管理措置の程度について、営業秘密保有者の秘密管理意思が従業員等に明確に示され、その認識可能性が確保される必要があるとしたうえで、こう続けます。情報の内容・性質等からいって重要な情報であることが明らかな場合には、外部のクラウドにアクセスするためにID・パスワードなどが設定されているといった程度の技術的な管理措置や、就業規則や誓約書において当該情報の漏えいを禁止しているといった規範的な管理措置で足りる場合もある¹。

完璧な仕組みを作るまで待つ必要はない、と読めます。なお指針自体は「一つの考え方を示すものであり、法的拘束力を持つものではない」と自ら明記しており、個別事案は最終的に裁判所が総合的に判断するとしています¹。図面の輸出管理側の論点は図面・設計データの輸出管理にまとめてあります。

預かった図面は、自社の図面より厳しい

ここが実務でいちばん危ないところです。自社で描いた図面と、取引先から預かった図面は、扱いが違います。

公正取引委員会・中小企業庁・特許庁が令和8年6月24日に公表した「知的財産権・ノウハウ・データの適切な取引のための優越的地位の濫用等に関する指針」は、あるべき姿としてこう書いています。

相手方の秘密情報を知った場合には、これを厳に秘密に保持するものとし、相手方から事前に明示的に承諾を得ることなく利用し、又は、第三者へ開示しないこと。⁶

事前に明示的に承諾を得ることなく、第三者へ開示しない。預かった図面を第三者のAIサービスに投入する行為は、この構造にまっすぐ重なります。分かれ目は、事前の明示的な承諾があるかどうかです。NDAに「第三者への開示禁止」と書いてあるとき、AIサービスがその第三者に当たらないと言い切れるでしょうか。私は言い切れないと思います。

同じ指針は、逆向きの要請にも触れています。取引の本来の目的に照らして合理的に必要と考えられる範囲を超えて相手方のノウハウ等の提供を求めないこと、そして取引の目的物とされていない金型等設計図面や設計・加工データその他技術データの提供を、当事者の意に沿わない形で強制しないこと⁶。図面を出せと言われる側にとっては、こちらが盾になります。

素形材産業取引ガイドライン（平成19年6月策定、令和7年11月最終改訂）は、金型図面の性質をさらに踏み込んで書いています。「金型製造業者が独自のノウハウによって設計・作成したものであり、金型製造に必要な知的財産である。これは本来委託事業者が取得する性質のものではなく、当然、売買の対象ではない」⁷。根拠法令として取適法第5条第2項第2号（不当な経済上の利益の提供要請の禁止）が挙げられています⁷。自社の図面は、渡すのが当然のものではないという整理です。

同ガイドラインは素形材企業側の宿題も書いています。ノウハウ等の技術情報を営業秘密管理指針に基づいて適切に管理し、不正競争防止法による保護を受けられるよう、秘密管理性・有用性・非公知性の要件を満たす体制を整備することが重要である⁷。守られる資格を自分で作れ、ということです。

現実の数字も見ておきます。警察庁の統計では、令和7年中の営業秘密侵害事犯の検挙事件数は38事件で、前年より16事件、72.7%増加しました。過去10年で最多です⁸。警察庁は「転職・独立時に営業秘密に関する情報を持ち出す事犯が多くみられる」と分析しています⁸。図面が流れる経路は、外部サービスだけではありません。人の移動でも流れます。

「再学習に使わない」契約だけでは足りません

ここまでの整理を踏まえて、よくある対策の限界を書きます。

「アップロードした図面がAIの再学習に使われない契約か確認する」。これは正しい対策です。個人情報保護委員会も2023年6月2日の注意喚起で、当該個人データを機械学習に利用しないこと等を十分に確認することを求めています⁹。ただし、前章で見たとおり日本でこれを仕組みとして導入しているのは19.9%です³。確認を求められているのに、8割は仕組みになっていません。

そして契約だけでは埋まらない穴が、もうひとつあります。会社が契約したサービスの外側で起きることです。

経済産業省の秘密情報の保護ハンドブック（平成28年2月策定、令和6年2月最終改訂の第6版）には、AI利用に関する参考コラムが載っています。そこで挙がっている漏えいシナリオの1つ目が、これです。職員が個人で秘密情報保護に関する契約に不備がある生成AIを利用し、営業秘密にあたる情報を学習させてしまう¹⁰。会社がどれだけ良い契約を結んでも、従業員が個人アカウントで使えば関係ありません。

この構造は、IPAも指摘しています。「情報セキュリティ10大脅威 2026」では、組織向けの3位に「AIの利用をめぐるサイバーリスク」が初選出されました。解説書でリスクの第1項に挙がっているのがシャドーAIで、職場に許可なくAIを業務利用し情報漏えいにつながる可能性、とされています¹¹。注目したいのはIPAの原因説明です。例えば職場でAIサービスの利用が無い場合など、従業員が個人的に利用しているAIサービスを業務利用する、と書かれています¹¹。

つまり、会社が用意しないことが引き金なのです。禁止は解決になりません。禁止したうえで代替を用意しなければ、業務は個人アカウントへ逃げます。国内の調査でも、生成AIツール利用者の約5人に1人がシャドーAIに該当し、社内規程が「ない」45%、「わからない」26.7%という結果が出ています（エルテス、2026年1月13日公表、n=300）¹²。

規模の差も効いてきます。IPAのDX動向2026では、AIを導入している企業の割合は従業員1,001人以上で8割近い一方、101人以下では16.6%でした¹³。会社として用意できていない小規模事業者ほど、個人アカウントに頼る余地が大きいわけです。シャドーAIへの向き合い方はシャドーAI 71%の現実、LLMベンダーへ直接データを渡すことの一般的なリスクはあなたの会社の資産、AIに無防備に渡していませんかに書きました。

処理する場所を、4段階で考える

では何を設計するのか。私の答えは、図面を「どこで処理するか」を段階で持つことです。全部をいちばん厳しい段階にする必要はありません。図面の中身によって段階を分けます。

第1段階は、外部の共有APIにそのまま投げる形です。何も設定していない状態がこれです。営業秘密管理指針の脚注が言う「第三者に提供される場合」に、いちばん近い位置にあります。ここに機微な図面を置くのは避けるべきです。

第2段階は、契約とオプトアウトで学習利用を止める形です。個人情報保護委員会が求める「十分に確認する」を仕組みにする段階で、日本ではまだ19.9%しか到達していません³。最低ラインとして、ここは越えておきたいところです。

第3段階は、自社のクラウドアカウント側で動かす形です。たとえばMicrosoft Foundryでは、オープンウェイトモデルをマネージドコンピュートとして自社サブスクリプション上の専用VMに配備できます。課金はVMのコア時間で、配備には該当VM製品のクォータが自社のAzureサブスクリプションに必要だと明記されています¹⁴。データの置き場所とアカウントの主体が自社側に寄ります。

第4段階は、完全に自社インフラで閉じる形です。ネットワークから切り離した環境でも動かせます。NVIDIA NIMは、インターネット接続のあるマシンでモデルプロファイルをキャッシュに取得し、そのキャッシュをエアギャップ環境へ移送すれば、レジストリへの接続なしで推論を提供できます。公式ドキュメントは、エアギャップ実行時はAPIキーを渡さないよう指示しています¹⁵。vLLMも、CUDA向け・ROCm向け・Intel XPU向けの公式Dockerイメージを提供しており、OpenAI互換サーバーとして自社インフラ上で起動できます¹⁶。

どの段階を選ぶかの判断材料も、公的資料にあります。秘密情報の保護ハンドブックは、取引先に秘密情報を共有する前に留意すべき点として2つだけ挙げています。秘密情報を取り扱う業務を不用意に委託しないこと、そして取引先の管理能力の事前確認をすること。後者はISMSやプライバシーマーク等を参考に事前確認するとされています¹⁰。AIベンダーの選定チェックリストは、この2点を出発点にすれば公的な根拠を持てます。

自社で動かすなら、制約を先に見ておく

第4段階に踏み込む場合の現実を書きます。ここは楽観すると導入直後に止まります。

まず、ご期待に添えない話から。OpenAIが公開しているオープンウェイトモデルは gpt-oss-120b と gpt-oss-20b で、ライセンスはApache 2.0、Hugging Face上の公開は2025年8月4日です。パラメータは120bが総計117B・アクティブ5.1B、20bが総計21B・アクティブ3.6B¹⁷。ただし、**これらは画像が入りません。**2026年7月28日時点で、OpenAIのHugging Face公式アカウントにある全39モデルはいずれもテキスト生成向けで、画像を入力してテキストを生成するモデルは存在しませんでした¹⁸。図面を読ませたいなら、別系統を選ぶことになります。

画像入力に対応したオープンウェイトモデルは、2026年に入ってから選択肢が増えました。

モデル	ライセンス	規模	コンテキスト長	公開日
Qwen3.5-122B-A10B	Apache 2.0	総122B・アクティブ10B	262,144	2026-02-24
Qwen3.6-27B	Apache 2.0	27B	262,144	2026-04-21
Gemma 4 31B	Apache 2.0	30.7B	256K	2026-03-11
Mistral Small 4 119B A6B	Apache 2.0	総119B・アクティブ6.5B	256k	2026-01-23

いずれもモデルカードでライセンスと仕様を確認できます¹⁹。図面のような文書画像の読み取りに絞るなら、OCRに特化した軽いモデルもあります。GLM-OCR（MIT、0.9B、2026年1月30日公開）、DeepSeek-OCR-2（Apache 2.0、約3.4B、2026年1月27日公開）、Unlimited-OCR（MIT、約3.3B、2026年6月19日公開）といったところです²⁰。

もうひとつ、面白い選択肢が出ています。OpenAIは2026年4月17日に、PIIマスキング用のオープンウェイトモデル「OpenAI Privacy Filter」をApache 2.0で公開しました。総パラメータ1.5B・アクティブ50M、コンテキスト長128,000トークンで、モデルカードは「オンプレミスで実行できるモデルを必要とするチーム向け」と明記しています²¹。渡す前に落とす、という発想を軽いモデルで実装できるということです。図面の全部を守る必要がない場合、どこを落として渡すかという設計は現実的な中間解になります。

GPUの見積もりは、外すと動きません。Googleの公式ドキュメントが示すGemma 4のメモリ所要量は、BF16で31Bが69.9GB、26B A4Bが57.7GB、12Bが26.7GB、E4Bが17.9GB、E2Bが11.4GB。4ビット量子化ではそれぞれ17.5GB、14.4GB、6.7GB、4.5GB、2.9GBです²²。ただし原典が明記しているとおり、これは静的な重みのロードに必要なメモリだけを見積もったもので、コンテキストウィンドウに必要な追加VRAMは含まれていません²²。

MoEモデルの罠も押さえておく価値があります。Gemma 4の26B A4Bは1トークンあたり4Bしか活性化しませんが、公式ドキュメントはルーティングと推論速度を保つため260億パラメータすべてをメモリに載せる必要があると明記しています²²。アクティブパラメータの小ささを見てGPUを削ると、起動しません。

「マネージドサービスに自社の重みを持ち込む」という構想も、仕様で止まることがあります。Amazon Bedrock Custom Model Import の対応リージョンは eu-central-1、us-east-1、us-east-2、us-west-2 の4つで、東京は記載がありません。インポートする重みはマルチモーダルモデルで100GB未満、モデルが対応する最大コンテキスト長は128K未満でなければならないという制約もあります²³。上の表を見ればわかるとおり、いま出ている画像対応モデルは256Kコンテキストが標準です。国内リージョンで、という要件と組み合わせると、通らない組み合わせが出てきます。

そして運用責任は、自社に来ます。Microsoftの公式ドキュメントは、パートナー・コミュニティ由来のモデルについて、通常は提供元自身が検証し、サポートと保守はそれぞれの提供元が管理すると明記しています。マネージドコンピュート配備では、安全フィルタもサーバーレス配備のように推論APIに統合されているわけではなく、自分でAPIを使う扱いです¹⁴。Gemma 4のモデルカードも、開発者は自らの製品ポリシーとユースケースに応じた適切なコンテンツ安全策を実装することが推奨されるとし、事前学習データのカットオフを2025年1月と明記しています¹⁹。この構造は、先日書いたオープンウェイトAIとサイバー防御と同じです。自社で持つ選択には、運用負荷を引き受けるという決定がセットで付いてきます。国内サーバーで動く既存ツールの比較は高セキュリティAIエージェント比較にあります。

私たちが提供しているZEROCKは、この第3段階から第4段階のあたりを、製造業向けに作り込んだものです。図面は国内のAWSサーバーで暗号化して保管し、お客様の図面がAIの再学習に使われることはありません。不要になれば7日以内に完全削除し、削除証明書を発行します（ISMS準拠）。過去図面と原価実績をナレッジグラフでつなぐところまで社内で完結させる設計です。ただ、順番だけは正直に書きます。まず自社の図面を段階のどこに置くかを決めてください。ツールはその決定のあとです。

まとめ

要点を整理します。

• 総務省の令和8年版情報通信白書で、日本企業の生成AIに対する懸念1位は「社内情報の漏洩などのセキュリティリスク」46.4%。4か国で最も高い一方、倫理24.7%とプライバシー24.5%は最も低く、不安が「外に出る」の一点に偏っています
• 恐れている割に手は打たれていません。入力データを学習データとして利用できない仕組みを導入しているのは19.9%（米国32.2%、ドイツ34.1%、中国47.8%）。生成AIの利用は86.4%まで来たのに、社内データを参照できる形にしているのは24.5%です
• 国は「AI禁止」と言っていません。営業秘密管理指針は、外部クラウドでも秘密として管理されていれば秘密管理性は失われないとしたうえで、第三者（例として生成AI提供事業者等）に提供される場合は否定される場合もあり得ると脚注で留保しています。線は「社内の管理下か、第三者提供か」です
• 秘密管理措置は過剰でなくてよい、とも指針は書いています。重要性が明らかな情報なら、ID・パスワード程度の技術的措置と就業規則や誓約書による規範的措置で足りる場合もあります
• 預かった図面はさらに厳しく扱ってください。令和8年6月24日の指針は、相手方の秘密情報を事前の明示的な承諾なく第三者へ開示しないことをあるべき姿としています
• 「再学習に使わない」契約は必要ですが、会社の契約の外側でシャドーAIが起きます。IPAは原因を「職場でAIサービスの利用が無い場合など」と説明しており、用意しないことが引き金です
• 処理する場所を4段階（外部の共有API、契約とオプトアウト、自社クラウドアカウント、自社インフラやエアギャップ）で持ち、図面の中身で使い分けてください
• 自社で動かすなら、OpenAIのgpt-ossは画像が入らないこと、GPUメモリの見積もりにコンテキスト分が含まれていないこと、MoEでも全パラメータをメモリに載せる必要があること、そしてマネージドへの持ち込みにはリージョンとコンテキスト長の制約があることを先に見てください

最後に、いちばん伝えたいことを書きます。「図面はAIに入れられない」で止まっている会社と、段階を決めて一部から入れている会社の差は、これから開くと思います。前者は結局、従業員の個人アカウントに逃げられます。後者は、どこまでを外に出さないかを自分で決めています。

決めるのは技術ではなく、方針です。まずは自社の図面を3つに分けてみてください。外に出しても困らないもの、契約があれば出せるもの、絶対に社内から出さないもの。この仕分けができれば、あとはどの段階に置くかを当てるだけです。図面と原価を社内に残す設計を具体的に詰めたい方は、ZEROCKの担当までご相談ください。仕分けのところからご一緒します。

参考文献・一次情報

Footnotes

1. 経済産業省「営業秘密管理指針」平成15年1月30日策定、令和7年3月31日最終改訂。「２．秘密管理性について（３）秘密管理措置の具体例／電子媒体の場合」に「また、外部のクラウドを利用して営業秘密を保管・管理する場合も、秘密として管理されていれば、秘密管理性が失われるわけではない」および重要な情報であることが明らかな場合にID・パスワード程度の技術的措置や就業規則・誓約書による規範的措置で足りる場合もあるとの記載。脚注24に「ただし、当該企業にとどまらず、当該情報αが当該企業以外の第三者（例えば、生成 AI 提供事業者等）に提供される場合は、秘密管理性が否定される場合もあり得る。」と記載。「はじめに（本指針の性格）」に「一つの考え方を示すものであり、法的拘束力を持つものではない」と明記 https://www.meti.go.jp/policy/economy/chizai/chiteki/guideline/r7ts.pdf ↩ ↩² ↩³ ↩⁴ ↩⁵

2. 総務省「令和8年版情報通信白書」付注。企業向けアンケートの有効回答数は日本515社（大企業353社・中小企業162社）、米国309社、ドイツ309社、中国309社、合計1,442社。調査期間は2026年1月から2月、インターネットアンケート調査 https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r08/pdf/01fuchuu.pdf ↩

3. 総務省「令和8年版情報通信白書」2026年7月24日公表。図表Ⅰ-2-1-8「生成AIの活用に関して懸念されるリスク（国別）」で日本は「社内情報の漏洩などのセキュリティリスクがある」46.4%（米国36.9%、ドイツ31.7%、中国42.7%）、「出力結果に倫理上不適切な内容や偏見が含まれる可能性がある」24.7%（米国38.5%、ドイツ35.9%、中国45.0%）、「個人情報の取り扱いなどプライバシーの侵害の可能性がある」24.5%（米国38.2%、ドイツ44.0%、中国43.4%）。図表Ⅰ-2-1-9「リスク対策の取組状況」で日本は全社的な指針やガイドラインの整備41.1%、入力データを学習データとして利用できない仕組みの導入19.9%（米国32.2%、ドイツ34.1%、中国47.8%）。図表Ⅰ-2-1-3で「組織的な取組はない」は日本27.0%（大企業18.1%、中小企業45.6%。同図の母数は活用方針で「利用を禁止している」と回答した対象を除いたもの） https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r08/pdf/n1210000.pdf ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

4. 総務省「令和8年版情報通信白書」概要。日本企業で自社の何らかの業務に生成AIを利用していると回答した割合は86.4%（2024年度調査は55.2%。母数は活用方針の設問で「わからない」と回答した対象を除いたもの）。「生成AIに社内データを学習させたり、生成AIが参照可能なデータベースを構築したりしている」は日本24.5%で、白書本文は他の3か国より顕著に低いと指摘している https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r08/summary/summary01.pdf ↩

5. 不正競争防止法（平成5年法律第47号）第2条第6項「この法律において「営業秘密」とは、秘密として管理されている生産方法、販売方法その他の事業活動に有用な技術上又は営業上の情報であって、公然と知られていないものをいう。」なお条文自体に「秘密管理性」「有用性」「非公知性」「三要件」という語は存在せず、これらの呼称は経済産業省「営業秘密管理指針」等の側で用いられている https://laws.e-gov.go.jp/law/405AC0000000047 ↩ ↩²

6. 公正取引委員会・中小企業庁・特許庁「知的財産権・ノウハウ・データの適切な取引のための優越的地位の濫用等に関する指針」令和8年6月24日。「第２ １ 情報の管理 ⑴ ア 秘密情報の取扱い・秘密保持契約（NDA）の締結について」の【あるべき姿】に「相手方の秘密情報を知った場合には、これを厳に秘密に保持するものとし、相手方から事前に明示的に承諾を得ることなく利用し、又は、第三者へ開示しないこと。」と記載。「イ ノウハウ等の取扱い」の【あるべき姿】に「取引の本来の目的に照らして合理的に必要と考えられる範囲を超えて、相手方の有するノウハウ等の提供を求めないこと。また、取引の目的物とされていない金型等設計図面や設計・加工データその他技術データの提供を、当事者の意に沿わない形で強制しないこと。」と記載 https://www.jftc.go.jp/houdou/pressrelease/2026/jun/260624_chizaitorihiki2.pdf ↩ ↩²

7. 経済産業省「素形材産業取引ガイドライン（素形材産業における受託適正取引等の推進のためのガイドライン）」平成19年6月策定、令和7年11月最終改訂。第2章「１３．図面・ノウハウの流出」に金型図面が「金型製造業者が独自のノウハウによって設計・作成したものであり、金型製造に必要な知的財産である。これは本来委託事業者が取得する性質のものではなく、当然、売買の対象ではない」との記載と、根拠法令として取適法第5条第2項第2号（不当な経済上の利益の提供要請の禁止）の明示。「（２）目指すべき取引方法 ②営業秘密の管理と不正競争防止法の活用」に「素形材企業においては、ノウハウ等の技術情報を「営業秘密管理指針」に基づいて適切に管理し、不正競争防止法による保護を受けられるよう、要件（秘密管理性・有用性・非公知性）を満たす体制を整備することが重要である。」と記載 https://www.meti.go.jp/policy/mono_info_service/mono/sokeizai/pdf/sokeizaiguideline202511.pdf ↩ ↩² ↩³

8. 警察庁生活安全局生活経済対策管理官「令和7年における生活経済事犯の検挙状況等について」令和8年3月。「２ その他の知的財産権侵害事犯（１）営業秘密侵害事犯の検挙状況」に「令和７年中の営業秘密侵害事犯の検挙事件数は、38 事件で前年より 16 事件（72.7％）増加した。」および「営業秘密侵害事犯としては、転職・独立時に営業秘密に関する情報を持ち出す事犯が多くみられる。」と記載。過去10年の推移で38事件は最多 https://www.npa.go.jp/publications/statistics/safetylife/2026_nenpou_teisei.pdf ↩ ↩²

9. 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等」令和5年6月2日。個人データを取り扱う際に、当該個人データを機械学習に利用しないこと等を十分に確認することを求めている。なお同委員会の注意情報一覧を確認した限り、生成AIを主題とする注意喚起としてはこれが最新である（2026年7月時点） https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/ ↩

10. 経済産業省「秘密情報の保護ハンドブック」平成28年2月策定、令和6年2月最終改訂（第6版、2024年2月29日）。第1章の参考コラム「「秘密情報の保護」の視点からのＡＩ利用」に、漏えいリスクの例として「職員が個人で秘密情報保護に関する契約に不備がある生成ＡＩを利用し、営業秘密にあたる情報を学習させてしまった」ケースを掲載。第3章「３－４ 具体的な情報漏えい対策例（３）取引先に向けた対策」の「（取引を開始する前に留意すべき点）」に「秘密情報を取り扱う業務を不用意に委託しない」「取引先の管理能力の事前確認」（ISMS・プライバシーマーク等を参考に事前確認）の2点を記載 https://www.meti.go.jp/policy/economy/chizai/chiteki/pdf/handbook/full.pdf ↩ ↩²

11. IPA「情報セキュリティ10大脅威 2026」2026年1月29日決定、解説書［組織編］2026年3月。組織向け3位に「AIの利用をめぐるサイバーリスク」が初選出。解説書のリスク第1項に「職場に許可なくAIを業務利用し、情報漏えいにつながる可能性（シャドーAI）」を掲げ、「例えば職場でAIサービスの利用が無い場合など、従業員が個人的に利用しているAIサービスを業務利用することがある」と説明している https://www.ipa.go.jp/security/10threats/10threats2026.html ↩ ↩²

12. 株式会社エルテス「生成AI利用実態調査」2026年1月13日公表（n=300）。生成AIツール利用者のうち約5人に1人がシャドーAIに該当し、個人情報を含むデータを入力した経験がある人が6.8%、社内規程が「ない」45%、「わからない」26.7%との結果。民間調査であり、サンプル数が限られる点に留意 https://eltes.co.jp/ ↩

13. IPA「DX動向2026」2026年（調査期間2026年4月17日から6月12日、1,799社）。AIを導入している企業の割合は従業員1,001人以上で8割近くに達する一方、101人以下では16.6%。なお完全版報告書とデータ集は2026年7月下旬公開予定とされており、業種別内訳は本稿執筆時点で未確認 https://www.ipa.go.jp/digital/chousa/dx-trend/index.html ↩

14. Microsoft「Foundry Models overview」2026年4月20日更新。オープンウェイトモデルを「マネージドコンピュート」として自社サブスクリプション上の専用VMに配備でき、課金はVMのコア時間、配備には該当VM製品のクォータが自社のAzureサブスクリプションに必要と明記。パートナー・コミュニティ由来のモデルについては通常は提供元自身が検証し、サポートと保守はそれぞれの提供元が管理するとし、マネージドコンピュート配備では安全フィルタはAzure AI Content SafetyのAPIを自分で使う扱いであると説明している https://learn.microsoft.com/en-us/azure/ai-foundry/concepts/foundry-models-overview ↩ ↩²

15. NVIDIA「Deploy NIM in an Air-Gapped Environment」。インターネット接続のあるマシンで download-to-cache によりモデルプロファイルを取得し、そのキャッシュをエアギャップ環境へ移送すればNGCレジストリへの接続なしで推論を提供できるとし、エアギャップ実行時は NGC_API_KEY を渡さないよう指示している https://docs.nvidia.com/nim/large-language-models/1.4.0/deploy-air-gap.html ↩

16. vLLM「Using Docker」。NVIDIA CUDA向け vllm/vllm-openai、AMD ROCm向け vllm/vllm-openai-rocm、Intel XPU向け vllm/vllm-openai-xpu（0.26.0以降）の公式Dockerイメージを提供しており、OpenAI互換サーバーとして起動できる https://docs.vllm.ai/en/latest/deployment/docker.html ↩

17. OpenAI「gpt-oss-120b」Hugging Faceモデルカード。ライセンスはApache 2.0、Hugging Face上の公開は2025年8月4日。パラメータは gpt-oss-120b が総計117B・アクティブ5.1B、gpt-oss-20b が総計21B・アクティブ3.6B https://huggingface.co/openai/gpt-oss-120b ↩

18. Hugging Face API による確認（2026年7月28日）。OpenAIアカウントの全39モデルの pipeline_tag を取得したところ、gpt-oss-120b / gpt-oss-20b / gpt-oss-safeguard-120b / gpt-oss-safeguard-20b を含みいずれも text-generation で、画像を入力してテキストを生成する image-text-to-text のモデルは存在しなかった https://huggingface.co/api/models?author=openai&sort=createdAt&direction=-1&limit=30 ↩

19. 各モデルのHugging Faceモデルカード。Qwen3.5-122B-A10B（Apache 2.0、総122B・アクティブ10B、コンテキスト262,144トークン、2026年2月24日公開） https://huggingface.co/Qwen/Qwen3.5-122B-A10B 、Qwen3.6-27B（Apache 2.0、pipeline_tag: image-text-to-text、27B、262,144トークン、2026年4月21日公開） https://huggingface.co/Qwen/Qwen3.6-27B 、Gemma 4 31B（license: apache-2.0、総30.7B、コンテキスト256K、対応モダリティ Text・Image、2026年3月11日公開。事前学習データのカットオフは2025年1月、開発者が自らの製品ポリシーとユースケースに応じた安全策を実装することが推奨されると明記） https://huggingface.co/google/gemma-4-31B-it 、Mistral Small 4 119B A6B（Apache 2.0、総119B・トークンあたり6.5Bアクティブ、コンテキスト256k、画像入力対応、2026年1月23日公開） https://huggingface.co/mistralai/Mistral-Small-4-119B-2603 ↩ ↩²

20. OCR特化のオープンウェイトモデル。GLM-OCR（MIT、モデルカード記載0.9B、2026年1月30日公開） https://huggingface.co/zai-org/GLM-OCR 、DeepSeek-OCR-2（Apache 2.0、実測約3.39B、2026年1月27日公開）、Unlimited-OCR（MIT、実測約3.34B、2026年6月19日公開） ↩

21. OpenAI「Privacy Filter」Hugging Faceモデルカード、2026年4月17日公開。ライセンスApache 2.0、総パラメータ1.5B・アクティブ50M、コンテキスト長128,000トークン。モデルカードは「オンプレミスで実行できるモデルを必要とするチーム向け」と明記している https://huggingface.co/openai/privacy-filter ↩

22. Google「Gemma core models」公式ドキュメント。メモリ所要量はBF16で31Bが69.9GB、26B A4Bが57.7GB、12Bが26.7GB、E4Bが17.9GB、E2Bが11.4GB、4ビット量子化（Q4_0）でそれぞれ17.5GB、14.4GB、6.7GB、4.5GB、2.9GB。原典は「静的な重みのロードに必要なメモリだけを見積もったもので、サポートするソフトウェアやコンテキストウィンドウに必要な追加VRAMは含まない」と明記。26B A4Bについては1トークンあたり4Bしか活性化しないが、ルーティングと推論速度を保つため260億パラメータすべてをメモリに載せる必要があるとしている https://ai.google.dev/gemma/docs/core ↩ ↩² ↩³

23. AWS「Import a customized model into Amazon Bedrock」。対応リージョンは eu-central-1、us-east-1、us-east-2、us-west-2 の4つ。インポートする重みはマルチモーダルモデルで100GB未満、テキストモデルで200GB未満、モデルが対応する最大コンテキスト長は128K未満でなければならないとされている https://docs.aws.amazon.com/bedrock/latest/userguide/model-customization-import-model.html ↩