社内専用AIを1台で複数部門に使わせたいが、どこから設計を始めればよいのか分からない——そう感じている情シス兼任担当者は少なくありません。
情報を外に出さない社内専用AI（ローカルLLM）を導入した中小企業が次にぶつかる壁が、複数部門への展開です。営業・総務・製造などが同一のAIサーバーを共有するとき、「誰がどのデータにアクセスできるか」と「処理能力をどう分配するか」を事前に設計しておかないと、部門間のデータ混在・応答遅延・利用の偏りが発生します。
この記事では、社内専用AIを複数部門で安全・公平に共有するためのアクセス制御とリソース配分の設計方針を解説します。設計の考え方から具体的な実装パターン、よくある失敗の回避策まで、情シス兼任担当者が実務で使える粒度でカバーします。
複数部門共有で起きやすい3つのトラブルとその原因
設計なしに複数部門へ社内専用AIを解放すると、次の3種類のトラブルが高い確率で現れます。これらは「AIが悪い」のではなく、設計の不備が原因です。
① 部門をまたいでデータが意図せず参照される
営業部が入力した顧客情報や製造部の原価データが、チャット履歴やベクトルデータベース（文書検索の仕組み）を介して、別部門のユーザーに参照されるケースです。社内専用AIは外部にデータを送信しませんが、「社内」は「全社員が自由に見てよい」を意味しません。特に人事部が給与情報を扱い始めたとき、または経営層が機密文書をAIに読み込ませた瞬間に問題が顕在化します。
Before: 全部門のデータが1つのデータベースに混在し、全員が全文書を検索できる状態
After: 部門別にデータを分離し、参照権限をユーザーグループ単位で設定した状態
このBefore/Afterの違いは、一見小さいようですが、データ混在が起きた場合の対応コスト——原因究明・関係者への説明・場合によっては情報漏洩の謝罪対応——と比較すると、設計コストが格段に小さいことが分かります。
② 特定部門が処理能力を独占する
社内AIサーバーの処理能力（CPU・メモリ・GPU）は有限の共有資源です。製造部が100件の仕様書を一括で解析し始めると、同じ時間帯に報告書を作成しようとした営業部の応答が数十秒から数分単位で遅延します。「AIがつながらない」という苦情がヘルプデスクに寄せられ始めたときには、すでにリソース設計の失敗が起きています。リソースの独占が起きる前に、部門別の上限を設計で決めておくことが重要です。
③ 部門ごとの利用ルールが属人化する
「うちの部門ではこのやり方でOKと言われた」「隣の部門は制限されていない」という状態が続くと、AIの使い方が担当者ごとにバラバラになります。コンプライアンス上の問題が発生したとき、誰がどの権限でどのデータを扱ったかの追跡が困難になり、事後の原因究明に余計な時間とコストがかかります。全部門共通のルールと、それを支える技術的な制御の両方が必要です。
これらはすべて、アクセス制御とリソース配分の設計を後回しにした結果です。次のセクションから、具体的な設計の考え方を解説します。
アクセス制御を3層で設計する
社内専用AIのアクセス制御は3層に分けて考えると整理しやすくなります。それぞれの層が「誰が・何を・どのデータで」使えるかを制御します。3層をすべて設計しておくことで、問題が起きたときの原因が特定しやすくなるというメリットもあります。
1. ユーザー認証層（誰がシステムにログインできるか）
最初の層は「入口の鍵」です。社内専用AIのWebUI（ブラウザ画面）やAPIエンドポイントに対して、ログインを許可するユーザーを管理します。
中小企業で現実的な認証方式は次の3種類です。
・社内Active Directory（AD）／LDAPとの連携: 既存のWindowsアカウントをそのままAIのログインに使える。追加のパスワード管理が不要で、退職者のアカウント削除も既存のAD管理と一元化できる。すでにADを使っている社員30名以上の会社に向いている。
・APIキー方式: 部門ごとに専用のAPIキー（パスワードに相当する文字列）を発行し、キー単位でアクセスを管理する。Active Directoryがない小規模事業者向き。社員20名以下の会社では最も導入コストが低い。ただしキー漏洩のリスクがあるため、定期的なローテーション（更新）が必要。
・VPN必須化: 社内ネットワークまたはVPN接続状態でのみAIにアクセスできるよう制限する。在宅勤務やサテライトオフィスからのアクセスには別途VPNクライアントのセットアップが必要だが、外部からの不正アクセスを物理的に遮断できる。他の認証方式と組み合わせることで多重防御になる。
認証とあわせて、ログイン記録（誰がいつどのIPアドレスからアクセスしたか）を最低90日間保存する設計も含めてください。問題発生時の原因追跡に不可欠で、後述するコンプライアンス対応でも役立ちます。
2. モデル・機能の割当て層（何を使えるか）
2層目は「使える道具の範囲」を部門別に決める設計です。すべての部門に同じAIモデルと機能を開放する必要はありません。用途に応じてアクセスできるモデルと機能を絞ることで、意図しない使われ方を防げます。
部門別の割当て例を示します。
・全社員共通: 一般的な文章作成・要約・翻訳のみ使用可能。社内文書へのRAGアクセスなし。誰でも使えるが参照できるのは公開情報と汎用的な知識のみ。
・営業部: 顧客提案書のRAG（社内文書検索）に加え、過去の受注データを参照できるモデルを割当て。顧客情報は営業部コレクションのみに格納されているため、他部門からは参照不可。
・人事部: 給与計算・勤怠データへのアクセスを持つ専用モデルのみ使用可能。かつ人事部員のみに限定し、管理者がアクセスログを定期確認する運用と組み合わせる。
・情シス担当（管理者）: 全モデルへのアクセス権と、全部門の利用ログ確認権限を持つ。モデルの追加・削除・設定変更も管理者のみが実行できる。
OllamaやLocalAI、OpenWebUIといったオープンソースのAIフロントエンドは、モデルをユーザーグループ別に割り当てる機能を持っています。設計段階でどのフロントエンドを選ぶかが、アクセス制御の実装しやすさに直結します。導入前に「グループ別モデル割当て」機能の有無を確認しておくことを推奨します。
3. データアクセス層（どの文書・データを参照できるか）
3層目は「見てよい情報の範囲」です。社内専用AIがRAG（社内文書を検索して回答を生成する仕組み）を使っている場合、どの部門がどのフォルダや文書コレクションを参照できるかを明示的に設計します。
Before: 全社の文書をまとめて1つのベクトルデータベースに格納し、全員が全文書を検索できる状態
After: 部門別にコレクション（フォルダ）を分割し、アクセス権をユーザーグループ単位で設定した状態
この「コレクション分割」を省略すると、人事部の給与台帳や顧問弁護士とのやり取りが、一般社員の検索結果に混入するリスクが残ります。特定の文書を「除外設定」するよりも、「参照を許可するコレクションだけを指定する」ホワイトリスト方式の方が安全です。
データを分けるコストは初期設計の数時間です。一方、情報漏洩が起きた後の対応コスト——顧客への説明・信頼回復・場合によっては法的対応——は、その何倍にもなります。最初から分割設計を行うことが合理的な投資です。
リソース配分の設計方針：処理能力を公平に分ける3つの方法
アクセス制御の設計が終わったら、次は「処理能力の分け方」です。社内専用AIのサーバーリソースは共有資源であり、使い方によっては特定部門が他部門の業務を実質的に止めることになります。3つの方法を組み合わせて設計してください。
1. 部門ごとに処理上限（クォータ）を設定する
最も基本的な方法が、部門ごとの1時間あたりリクエスト数の上限を設定することです。上限を超えたリクエストは「しばらく待ってから再試行してください」というメッセージとともに返されます。
上限設計の考え方を以下に示します。
・通常クォータ: 過去の試験運用（1～2週間の無制限運用期間）のデータを元に、各部門の実際のリクエスト数の上位20%をカットした値を初期値として設定する。
・バースト許容時間帯: 月次報告の締め切り前日・四半期末・決算期など、一時的に上限を超えることが予測される時間帯を事前に定義し、その期間のみクォータを緩める設定を入れておく。
・優先度付け: 業務クリティカル度に応じて部門に優先度（高・中・低）を設定する。全体の負荷が80%を超えた時間帯は、優先度の低い部門のリクエストをキューで待機させる仕組みを設ける。
・定期見直し: クォータ設定は固定でなく、四半期ごとに実績データを確認し、業務実態に合わせて調整する運用を組み込む。
2. 重い処理の時間帯をずらす（タイムスロット設計）
リソース上限の設定に加えて、部門ごとの「重い処理」の実行時間帯をずらす設計も効果的です。「今すぐ処理する」ではなく「予約して後で実行する」仕組みを作ることで、全員がリアルタイムで使いたい時間帯のサーバー負荷を大幅に分散させられます。
・営業部: 顧客提案書の大量生成は14時～16時の業務低負荷時間帯に予約実行するルールを設ける。午前中のリアルタイム会議サポート用途とは時間帯を分ける。
・製造部: 仕様書や品質報告書の一括解析はバッチ処理として夜間（22時以降）に実行するよう設定する。翌朝には結果が出ている状態にする。
・管理部: 月次レポートの生成は月初の土日に実行するよう予約設定しておく。平日業務時間中に処理能力を消費しない。
バッチ処理の予約が自動化できると、担当者が夜間や休日に作業を意識する必要がなくなります。Ollamaのような軽量フレームワークでは、シンプルなシェルスクリプトとcronを組み合わせてバッチ実行を実現できます。
3. モデルの種類で処理を分けて効率を上げる
すべての部門が同じ大型モデルを使う必要はありません。用途に応じて軽量モデルと高性能モデルを使い分けることで、リソースをより有効活用できます。大型モデルは処理が重い分、回答の精度が高い領域があります。一方、軽量モデルは速度が速く、シンプルなタスクには十分な精度を発揮します。
・軽量モデル（7B～13Bパラメータ規模）: 文章の要約・翻訳・簡単なQ&Aに割当て。処理が速く、全部門が常時利用可能な状態を維持できる。大多数の日常業務はこれで賄える。
・高性能モデル（32B以上）: 複雑な文書分析・長文の要約・コード生成・法的文書のレビューに割当て。利用は申請制または時間帯制限を設ける。リソース消費が大きいため、全員が無制限に使うと他部門への影響が大きい。
用途別にモデルを分けることで、「一般業務用のAIが高性能処理に引きずられて遅くなる」問題を構造的に防げます。2026年時点で主流の社内専用AIフロントエンドはモデルの切り替えをユーザー操作で実現できますが、管理者側で「このユーザーはこのモデルのみ」と制限できる設定を有効にしておくことを推奨します。
比較表：アクセス制御の実装パターン3選
中小企業でよく使われるアクセス制御のパターンを比較します。自社の規模と既存インフラに合わせて選択してください。
| パターン | 概要 | 向いている規模 | 管理コスト | セキュリティ水準 | 主な注意点 |
|---|---|---|---|---|---|
| APIキー分離 | 部門ごとにAPIキーを発行し、キー単位でモデルと利用上限を管理する | 社員20名以下の小規模 | 低 | 中 | キー漏洩時は即時無効化と再発行が必要。定期ローテーション推奨 |
| LDAP/AD連携 | 既存のWindowsアカウントと連携し、グループポリシーでAIへのアクセスを制御する | 社員30名～100名の中規模 | 中 | 高 | AD環境の構築・維持コストがかかる。退職者管理は一元化できて楽になる |
| VPN＋個人認証 | VPN接続を前提とし、個人ID・パスワードでAIにログイン。部門グループにモデルを割当て | 全規模・リモート対応 | 高 | 高（多重防御） | VPNクライアントの全社配布と設定サポートが必要。在宅勤務者への展開コストに注意 |
中小企業では「APIキー分離」から始めて、社員数や利用部門が増えたタイミングで「LDAP/AD連携」に移行するのが現実的な段階設計です。最初からVPN＋個人認証を目指すと構築コストが高くなりすぎるため、まず最小構成で動かしながら、実際の利用状況を見て拡充する進め方を推奨します。いずれのパターンでも、利用ログの保存と管理者によるアクセス確認の仕組みは必ず設けてください。
よくある質問
Q1. 部門ごとにサーバーを別々に用意した方が確実ではないですか？
A. 部門別サーバーはデータ分離の面では明快ですが、サーバー台数分のハードウェアコスト・電力代・保守負担が増えます。月額コストで比較すると、適切に設計された1台共有モデルの方が大幅に経済的です。適切なアクセス制御（3層設計）とコレクション分割を設計すれば、1台のサーバーで複数部門を安全に分離できます。まず1台で設計し、「特定部門が24時間専用の処理能力を必要とする」など分離しきれない要件が出てから分割を検討する順序が合理的です。
Q2. RAG（社内文書検索）を使っていない場合、設計は不要ですか？
A. いいえ、RAGがない場合でも設計は必要です。チャット履歴の管理と利用ログの保存が最低限必要で、誰がいつAIにどんな質問をし、AIがどう答えたかの記録を部門別に管理しておくことで、問題発生時の原因追跡が可能になります。ユーザー認証と利用ログの設計は、RAGの有無に関わらず必ず整えてください。RAGを後から追加する場合も、認証の仕組みが先にあれば、データアクセス層の追加が格段に楽になります。
Q3. リソースの上限値はどのように決めればよいですか？
A. 最初から厳密に決めようとせず、まず1～2週間は上限なしで試験運用し、部門別の実際のリクエスト数とサーバー負荷をモニタリングすることを推奨します。そのデータを元に「全体負荷が80%を超えない範囲で各部門に割り当てる」という基準で設定すると、実態に即した数値になります。設定後も四半期ごとに実績と比較し、業務実態の変化に合わせて調整してください。
Q4. クラウドサービスと社内専用AIを併用していますが、アクセス制御は共通にできますか？
A. 共通化は難しいですが、方針の統一は必須です。2つのシステムで扱えるデータの種類を社内ルールとして明確に分ける必要があります。「社外秘・個人情報・顧客情報は社内専用AIのみで処理する」「公開情報の調査や一般的な文章作成はクラウドサービスも可能」という基準を文書化してください。基準が曖昧なまま両方を使い続けると、情報漏洩リスクの管理が難しくなり、問題発生時の責任範囲も曖昧になります。
Q5. 社員がルールを守らず機密データを入力した場合はどう対処しますか？
A. 技術的な制御と運用ルールの2段構えで対応してください。技術的制御（アクセス制御・コレクション分割）で防げるのは「物理的にアクセスできないデータへの侵入」です。一方、「アクセス権のある情報を不適切な質問に使う」行為は、利用ログの定期監査と社員教育で対応します。導入時に全社員向けのAI利用ガイドラインを整備し、年2回程度の利用状況レビューを仕組みとして組み込むことを推奨します。問題が起きたときに「知らなかった」「ルールがなかった」とならないよう、ガイドラインは書面で配布し、受領サインをもらっておくことが重要です。
複数部門展開前のチェックリスト
展開前に次の項目をすべて確認してください。1項目でも「未」がある場合は、展開前に対処することを推奨します。
・認証方式の決定: APIキー方式・LDAP連携・VPN＋個人認証のいずれかを選定し、既存の社内インフラとの整合性を確認した。退職者アカウントの即時無効化フローも設計済み。
・部門別コレクションの設計: RAGを使う場合、部門ごとに文書コレクションを分割し、部門×データアクセス範囲の対応表（誰がどのコレクションを参照できるか）を作成した。
・リソース上限の方針決定: 部門別の1時間あたりリクエスト上限と処理の優先度を決め、AIフロントエンドの設定ファイルに反映した。
・利用ログの保存設計: 誰がいつ何を質問したかのログを最低90日間保存し、参照できるのは情シス担当（管理者）のみとした。
・重い処理の時間帯設計: 大量文書の一括処理はバッチ予約方式にし、業務時間内のリアルタイム利用と競合しない運用ルールが整っている。
・AI利用ガイドラインの整備と周知: どの情報を社内専用AIに入力してよいかを部門別に明文化し、全社員に書面で周知した。
・トラブル時の対応手順の整備: 応答遅延・アクセス不可・データ混在疑いが起きた際の初動手順と報告先を決め、関係者に周知した。
まとめ
社内専用AIを複数部門で安全・公平に共有するためには、3層のアクセス制御（ユーザー認証・モデル割当て・データアクセス）とリソース配分の設計を、展開前に整えておく必要があります。
設計なしで展開すると、部門間のデータ混在・特定部門によるリソース独占・利用ルールの属人化という3つのトラブルが高い確率で発生します。一方、最初に設計を整えておけば、追加部門を展開するたびに同じ枠組みを適用するだけで済み、管理コストが大幅に下がります。部門数が増えるほど、設計投資の回収が早くなります。
設計の難易度が高く感じる場合は、まず「APIキー分離＋部門別コレクション分割」の最小構成から始め、試験運用の実測値を見ながら段階的に拡充する進め方が現実的です。
社内専用AIの複数部門展開や設計支援については、イーネットマーキュリーにお気軽にご相談ください。中小企業の実情に合わせた設計をご提案します。
