社内専用AIを委託先・協力会社に開放する際のセキュリティ設計と契約条件｜中小企業の判断ガイド

社内専用AIを導入したあとに「委託先にも使わせたい」「協力会社のスタッフと共有したい」という声が増えている。しかし外部からのアクセスを安易に許可すると、機密情報の漏洩・不正利用・契約トラブルといったリスクが一気に高まる。

この記事では、情報を外に出さない社内専用AI（ローカルLLM）への外部アクセスを安全に実現するためのセキュリティ設計3層と、委託契約書に必ず盛り込むべき5つの条項を解説する。アクセス制御の実装パターン比較表・FAQ・チェックリストを活用すれば、今日から設計に着手できる。

社内専用AIへの外部アクセスを許可する前に知るべきリスク

社内専用AIのサーバーには、顧客の見積書・内部マニュアル・財務データ・技術仕様書といった機密情報が日々蓄積されていく。従業員が使う内部ツールとして運用している間はアクセス範囲が限られているが、委託先や協力会社のスタッフに開放した瞬間、リスクの性質が根本から変わる。

外部アクセスを許可した際に実際に起きやすいリスクは3種類ある。

第1は情報の横断アクセスだ。社内AIに複数部門のドキュメントを学習させている場合、委託先スタッフは本来閲覧権限のない部門のデータまで検索・参照できてしまう可能性がある。アクセス範囲を制限せずにIDとパスワードだけを渡すと、意図せず情報が流出する。2023年以降に起きた中小企業での情報漏洩インシデントを振り返ると、外部アクセス権限の設計不備が原因の事案が全体の30%超を占めていた（IPA「情報セキュリティ10大脅威2024」参考）。

第2は認証情報の使い回しと漏洩だ。委託先スタッフ個人ではなく委託先企業のグループアカウントを作成してしまうと、退職・異動後も同じIDが使われ続ける。委託契約が終了してもアクセスが止まらない状態は「幽霊アカウント問題」と呼ばれ、セキュリティ監査の現場では非常に多く見つかる。ある製造業の中小企業では、委託先との契約終了から8カ月後に元スタッフのIDが不正利用され、設計図が外部に持ち出されたケースが報告されている。

第3は証跡の欠如だ。「誰が・いつ・何を質問して・どんな回答を得たか」のログを取っていないと、情報漏洩が発覚したとき原因を特定できない。法的紛争になった際に証拠を提出できないことが契約違反認定につながることもある。

中小企業がよくやってしまうミスを Before/After で整理すると次のようになる。

・Before（無対策）: 委託先スタッフが全社データに無制限アクセス・ログなし・契約上の縛りなし → 情報漏洩・不正利用・証拠なしの3重リスクが発生する
・After（設計済み）: 業務範囲に絞ったアクセス権・個人単位のアカウント・ログ取得・契約による義務付け → リスクをコントロールできる状態に移行する

この「Before→After」の移行を実現するのが、次節で解説するセキュリティ設計3層だ。

外部アクセスを安全に許可するセキュリティ設計の3層構造

外部アクセスのセキュリティ設計は「ネットワーク層」「認証・認可層」「監査層」の3層で考えると整理しやすい。1層だけ整えても他の2層が脆弱なら意味がない。3層を同時に整備することがポイントだ。

1. ネットワーク層の境界設計

委託先・協力会社のスタッフが社内AIサーバーに到達するまでのネットワーク経路を制御する。最も基本的な方法はVPN（仮想専用網）経由のアクセスに限定することだ。VPNを使うと通信が暗号化され、接続元のIPアドレスも管理できる。

市販のVPNサービスを使う場合、月額1,000円～5,000円程度のサービスで10名規模の委託先アクセスを管理できる。社内に専任IT担当がいなくても設定できる製品が増えており、初期構築に丸1日かかる案件は少ない。

さらに一歩進めた設計として「ゼロトラスト型のアクセス制御」がある。これは「社内ネットワークに接続しているから信頼する」ではなく、「誰が・どの端末から・何の業務で接続するか」を毎回検証する方式だ。クラウドサービスのIDaaS（ID as a Service）を組み合わせると、中小企業でも比較的低コストで実装できる。

委託先専用のサブネット（ネットワークセグメント）を設けて社内基幹システムとは分離するのも有効だ。これにより万一委託先のPCがマルウェアに感染しても、社内全体に被害が広がるリスクを大幅に下げられる。

2. 認証・認可層の設計

委託先スタッフには個人単位のアカウントを発行する。「委託先企業で1つ」「プロジェクト単位で1つ」という共有アカウントは、退職後のアクセス管理が破綻するため禁止する。アカウント発行時にはスタッフの氏名・所属・担当業務・使用する端末を記録するアカウント台帳を社内で管理する。

アクセスできるデータの範囲（認可）は役割ベースで設定する。具体的には、委託先が担当する業務に必要なドキュメントカテゴリのみ参照可とし、他部門データは閲覧不可にする。社内AIに入力する学習データの整備段階から「外部アクセス時の参照範囲」を意識した分類を行うことが、後工程の設計を大幅に楽にする。

多要素認証（パスワード＋スマートフォンアプリによるワンタイムコード）を必須化することで、認証情報が漏洩した場合でも不正ログインを防止できる。Google Authenticatorなどの無料アプリと組み合わせれば追加コストはほぼゼロだ。

3. 監査層（ログ・証跡の設計）

社内AIへのアクセスログ（誰が・いつ・どのエンドポイントに・何を質問したか）を自動取得する仕組みを構築する。ログは最低6カ月間保存し、委託契約終了後も1年間は保管する。これは万一の情報漏洩時の原因究明と法的証拠のためだ。

ログを取るだけでなく、月次でアクセスレポートを確認し、想定外の操作（深夜アクセス・大量クエリ・通常業務と異なるデータへのアクセス等）がないか目視確認する運用も必要だ。異常なアクセスパターンを検出したら自動でアラートを送信する設定を組み合わせると、対応速度が上がる。

アクセス制御の実装パターン比較

委託先への外部アクセスを許可する際の主な実装パターンを整理した。

中小企業に最も現実的なのは②のVPN＋RBACパターンだ。月額3,000円～8,000円程度のVPNサービスと、社内AIのアクセス権限設定を組み合わせることで実現できる。

無対策のまま外部公開するパターン（コスト0円）は一見安く見えるが、情報漏洩が発生した際の損害賠償・信頼失墜・業務停止コストは数百万円を超えることも少なくない。中小企業が取引先からの信頼を失うと、売上に直接影響するため長期的なコストで考えると②への投資は合理的だ。

③のゼロトラスト方式は初期構築に時間とコストがかかるが、顧客の個人情報・守秘義務情報を多く扱う税理士・社労士・法律事務所などの士業では最初からこの水準を目指すことを推奨する。

委託先・協力会社との契約書に必ず盛り込む5つの条項

外部アクセスを許可する際、セキュリティ設計だけでなく契約上の縛りも同時に整備する必要がある。技術的な対策が整っていても、契約上の責任範囲があいまいだと、問題が起きたときに対処できない。以下の5つの条項を委託契約書または個別の情報取扱覚書（NDA）に盛り込む。

条項1: アクセス権限の範囲と用途制限

「乙は、本システムへのアクセス権限を、甲が指定した業務目的にのみ使用し、他の目的に使用してはならない。アクセスできるデータの範囲は別紙（アクセス権限設計書）による。」

この条項により、委託先が業務外の情報を参照することを契約上も禁止できる。別紙に具体的なフォルダ・データカテゴリ・利用可能な機能を記載することがポイントだ。別紙を後日更新できる形にしておくと、業務内容が変わったときの対応が楽になる。

条項2: 情報の第三者提供禁止と再委託制限

「乙は、本システムを通じて取得した情報を、甲の書面による事前承諾なく第三者に開示・提供・漏洩してはならない。再委託先への開示も同様とする。」

再委託先まで縛ることが重要だ。委託先が別の外注業者にアクセス情報や取得データを渡すケースで発生する二次漏洩を防ぐ。実際、情報漏洩事故の原因を遡ると再委託先に行き着くケースが少なくない。

条項3: セキュリティ基準の遵守義務

「乙は、本システムへのアクセスにあたり甲が定めるセキュリティポリシー（別添）を遵守する。具体的には多要素認証の使用、業務用端末へのウイルス対策ソフトウェア導入、公共Wi-Fiからのアクセス禁止を含む。」

「別添のセキュリティポリシー」として1ページ程度の基準書を作成し、委託先の責任者に署名をもらうと実効性が上がる。委託先が基準を守らなかったことを原因として情報漏洩が発生した際に、責任を明確に分離できる。

条項4: 契約終了時のアクセス権限削除と確認

「本契約終了または個別業務の完了から7営業日以内に、乙の全スタッフのアクセス権限を削除する。甲は削除完了を確認次第、乙に書面で通知する。」

この条項がないと、委託先スタッフが退職・異動後もアカウントが残り続けるケースが頻発する。7営業日という具体的な期限と双方向の確認義務を明記することで、削除漏れのリスクを下げられる。

条項5: 情報漏洩時の報告義務と損害賠償

「乙が本システムに関連した情報漏洩の事実または疑いを認知した場合、甲に24時間以内に書面で報告する義務を負う。乙の故意または過失による情報漏洩については、乙は甲に対して損害賠償責任を負う。」

24時間以内という報告期限を設定することで、漏洩の被害拡大を防ぐ初動対応の義務を担保できる。「疑い」の段階で報告義務を課すことで、委託先が問題を隠蔽・先送りするインセンティブを減らす効果もある。

よくある質問

Q1. VPNを使わずに委託先に社内AIを使わせる方法はありますか？

委託先のIPアドレスを固定してIPホワイトリストに登録し、その範囲からのみアクセスを受け付ける方式があります。ただしこれはVPNに比べてセキュリティ強度が低く、委託先のネットワーク環境が変わるたびに設定変更が必要なため、中小企業が長期間管理するには手間がかかります。委託先スタッフが3名以下・期間が6カ月未満のような短期・小規模案件でなければ、VPN方式を選ぶほうが運用コストの観点からも合理的です。

Q2. 委託先のスタッフが退職したとき、アカウント削除を忘れるリスクをどう防ぎますか？

委託先に「スタッフの退職・異動が発生した際は7営業日以内に書面で通知する義務」を契約に明記することが最初の対策です。加えて、月次または四半期ごとに外部アカウントの一覧を確認するレビューを定例化することでダブルチェックになります。アカウント管理ツール（IDaaS）を使用している場合は、一定期間ログインのないアカウントに自動で無効化フラグを立てる設定も活用してください。

Q3. 協力会社が複数ある場合、それぞれ別々にアクセス範囲を設定する必要がありますか？

原則として会社単位・業務単位で設定を分けることを推奨します。A社は製造部門の仕様書のみ、B社は品質管理資料のみ、という形で参照範囲を絞ることで、万一どちらかで情報漏洩が発生しても被害範囲が限定されます。設定を共通化すると管理が楽になりますが、想定外のデータが外部に漏れるリスクが高まるため、コスト感覚だけで共通化するのは避けてください。

Q4. 社内AIへの外部アクセスを許可した事実を社内規程に記載する必要はありますか？

はい、社内情報セキュリティポリシーに「外部委託先へのシステムアクセス許可基準」を追記することを推奨します。具体的には、許可できる条件（契約締結済み・アカウント個別発行済み・多要素認証設定済み等）と禁止ケース（共有アカウント・多要素認証未設定等）を明記します。社内規程がないと「なぜこの委託先だけ使えるのか」という疑義が生じやすく、内部統制上も好ましくない状態が続きます。

外部アクセス許可前チェックリスト

外部アクセスを開放する前に以下のチェックを済ませておく。未完了の項目が1つでも残っている場合は開放を保留するのが原則だ。

・ネットワーク設計: 委託先用の独立したネットワークセグメント（VPNまたはサブネット分離）が設定されているか
・認証設計: 委託先スタッフ全員に個人単位のアカウントが発行され、共有アカウントが存在しないか
・多要素認証: すべての外部アカウントに多要素認証（MFA）が設定・強制されているか
・アクセス範囲: 委託先が参照できるデータカテゴリが業務目的に限定されており、不要なデータへのアクセスが禁止されているか
・ログ取得: アクセスログが自動取得されており、保存期間が6カ月以上に設定されているか
・契約整備: アクセス権限の範囲・用途制限・第三者提供禁止・セキュリティ基準遵守・契約終了時の削除義務・漏洩時の報告義務が契約書または覚書に記載されているか
・セキュリティポリシー署名: 委託先の責任者が遵守すべきセキュリティ基準書（別添）に署名しているか
・退出管理手順: 委託先担当者が変わった際のアカウント削除・引き継ぎフローが文書化されているか
・定期レビュー予定: 外部アクセス権限の棚卸しを3カ月に1回実施するスケジュールが決まっているか
・インシデント対応フロー: 情報漏洩の疑いが発生した際の初動対応（誰に・何時間以内に・何を報告するか）が整備されているか

本記事のまとめ

社内専用AIを委託先・協力会社に開放する際に必要な対策を整理する。

・リスクは3種類: 情報の横断アクセス・幽霊アカウント・証跡の欠如が中小企業でよく発生する三大リスクだ
・セキュリティ設計は3層で考える: ネットワーク境界分離・認証認可設計・監査ログ取得の3層を同時に整備する
・現実的な実装はVPN＋RBAC: 中小企業規模であれば月額3,000円～8,000円程度のVPNサービスと権限設定で実現できる
・契約書に5条項を盛り込む: アクセス権限の範囲・用途制限・第三者提供禁止・セキュリティ基準遵守・契約終了時の削除義務・漏洩時の報告義務を明記する
・チェックリスト10項目を確認してから開放する: すべてが完了していることを確認してから外部アクセスを許可する
・定期レビューを仕組み化する: 3カ月に1回、外部アカウントの棚卸しとアクセスログ確認を実施する

外部アクセスの許可は一度設定して終わりではない。委託先の担当者が変わるたびに・契約が更新されるたびに・半年ごとの棚卸しのたびに設定を見直す継続的な運用が求められる。設計と契約と運用の3つを組み合わせて初めて、安全な外部アクセス体制が完成する。