「自社専用ChatGPT」とは、社内のマニュアルや議事録、規程といった自社の文書を参照して回答するChatGPT環境のことです。仕組みの中心はRAG(Retrieval-Augmented Generation/検索拡張生成)で、質問に関連する社内文書を検索し、その内容をもとにAIが回答を組み立てます。社内データを安全に使う鍵は、(1)入力データが外部の学習に使われない契約・設定を選ぶ、(2)文書ごとのアクセス権限を分ける、(3)ログを残す、の3点です。本記事では作り方の選択肢を比較し、情報漏洩を防ぐ実務上の要点と、内製・外注の判断軸まで具体的に解説します。
自社専用ChatGPTとは何か(RAGの仕組み)
通常のChatGPTは、自社の最新マニュアルや社内規程を知りません。学習時点までの一般知識しか持たないため、「うちの就業規則では有休は何日付与される?」と聞いても正しく答えられず、もっともらしい嘘(ハルシネーション)を返すこともあります。自社専用ChatGPTは、この弱点をRAGという仕組みで補います。
RAGは、質問が来たときにまず社内文書のデータベースを検索し、関連する文章を取り出してから、その文章と質問をセットでAIに渡して回答させる方式です。AIに社内情報を「丸暗記(再学習)」させるのではなく、回答のたびに必要な資料を「カンニングペーパー」として手渡すイメージに近いものです。
具体的には、社内文書を次の流れで検索可能にします。
- チャンク分割:長い文書を数段落単位の小さな塊に区切る
- ベクトル化(Embedding):各チャンクを意味を表す数値の並びに変換し、ベクトルデータベースに保存する
- メタデータ付与:部署・更新日・機密区分などの情報を各チャンクに紐づける
- 検索と生成:質問もベクトル化し、意味が近いチャンクを取り出してAIに渡す
この方式の利点は、文書を差し替えれば回答内容もすぐ更新できること、そして「どの文書を根拠に答えたか」を出典として表示できることです。実務では、根拠表示があるかどうかが現場の信頼を左右します。出典が見えれば、利用者が元の文書で裏取りでき、誤回答にも気づきやすくなります。
作り方の3つの選択肢とメリット・デメリット
自社専用ChatGPTの作り方は、大きく「既製のエンタープライズ機能を使う」「ノーコード/SaaSツールを使う」「独自開発する」の3通りです。それぞれ向き不向きがはっきり分かれます。
(1) 既製のエンタープライズ機能を使う
ChatGPTの法人向けプラン(ChatGPT BusinessやEnterprise)には、社内ファイルをアップロードして参照させる機能が用意されています。OpenAIは、Business・Enterprise・Eduの各プランで、入力・出力データを既定でモデルの学習・改善に使わないと公式に明言しています(Enterprise privacy at OpenAI)。
料金は、旧Teamから改称されたChatGPT Businessが1ユーザー月25ドル(2名から、年払いの場合)が目安です。Enterpriseは大規模向けで、データ保持期間のカスタム設定やSCIM自動プロビジョニング、DLP連携などが加わりますが、料金は個別見積もりです。
項目 | エンタープライズ機能 |
|---|---|
導入スピード | 速い(契約後すぐ) |
必要な技術力 | 低い |
カスタマイズ自由度 | 低〜中 |
向いている規模 | 全社展開・ガバナンス重視 |
メリットは、セキュリティと運用をベンダーに任せられること。デメリットは、自社の業務フローに深く組み込む(基幹システムと連携する等)柔軟性は限られる点です。
(2) ノーコード/SaaSツールを使う
「社内ChatGPT」を名乗るSaaSや、RAG構築を簡単にするノーコードツールも増えています。文書をアップロードし、権限を設定するだけで専用チャットが立ち上がるものが多く、契約初日から使い始められます。
メリットは、初期開発が不要でスモールスタートできること。月額はユーザー数課金が一般的で、小さく試して効果を確かめてから広げられます。デメリットは、ツールの仕様にこだわりの業務要件を合わせる必要があること、そして社内データを外部SaaSに預けるため、提供元のデータ取り扱い方針(学習利用の有無・保管場所・暗号化)を契約前に必ず確認しなければならない点です。
(3) 独自開発する
OpenAIのAPIやAzure OpenAI Serviceを使い、検索・チャット画面・権限管理まで自社で組み上げる方法です。UIや業務連携を完全に作り込めるため、自社のワークフローにぴったり合わせられます。
API利用の大きな利点は、データの扱いを自社で制御しやすいことです。OpenAIは、APIに送信されたデータを既定ではモデルの学習・改善に使わないと公式ドキュメントで明記しています。APIの入出力は不正利用監視のために最大30日間保持され、その後削除されますが、Enterprise顧客は事前承認を得てZero Data Retention(保持ゼロ)を申請することもできます(Data controls in the OpenAI platform)。閉域ネットワークや国内データレジデンシーを重視するなら、Microsoftが顧客データをモデル学習に使わないと明言するAzure OpenAI Serviceも有力です。
デメリットは明確で、エンジニアリソースと継続的な保守が必須なこと。RAGの精度チューニング、APIキーの安全な管理、モデルのバージョンアップ追従など、作って終わりにはなりません。
選択肢 | 初期コスト | 必要な技術力 | カスタマイズ性 | 向く規模・目的 |
|---|---|---|---|---|
エンタープライズ機能 | 低 | 低 | 低〜中 | 全社のガバナンス重視 |
ノーコード/SaaS | 低 | 低 | 中 | まず試す小規模導入 |
独自開発 | 高 | 高 | 高 | 業務に深く組み込む |
「まず一部の部署で試し、効果が見えたら広げる」進め方なら、SaaSやノーコードから始め、要件が固まった段階で独自開発に移すのが堅実です。自社の業務にどこまで作り込むべきか迷う場合は、要件整理から相談できるパートナーを選ぶと失敗が減ります。
社内データを安全に使うための4つの要点
自社専用ChatGPTで最も警戒すべきは、社外秘や個人情報の漏洩です。技術的な対策は、次の4点に集約されます。
入力データが学習に使われない契約・設定を選ぶ
無料版や個人向けプランのChatGPTでは、入力内容がモデル改善に使われる場合があり、機密情報の入力は避けるべきです。一方で、API利用やChatGPTの法人プラン(Business/Enterprise)、Azure OpenAI Serviceでは、入力データが既定で学習に使われません。「学習に使われない」ことを、利用するサービスの公式方針で必ず確認するのが第一歩です。
アクセス権限を文書単位で分ける
全社員が全文書を検索できる状態は危険です。RAGの検索対象に、利用者の権限に応じたフィルタをかけ、「役員のみ閲覧の経営資料」や「人事の評価データ」は一般社員の検索結果に出ないようにします。実務では、元の文書管理(共有ドライブやファイルサーバー)の権限設計をそのままAIの検索にも反映させる作りにすると、管理が二重にならず破綻しにくくなります。
社外秘を分離し、入力ルールを定める
そもそもAIに渡してよい情報の線引き(社外秘・個人情報・契約上開示禁止の情報など)を社内ルールとして明文化します。技術面では、特定のキーワードや個人情報の入力を検知・ブロックするDLP(Data Loss Prevention/情報漏洩対策)の仕組みを併用すると、うっかり入力の事故を減らせます。
ログを残し、定期的に点検する
誰がいつ何を質問し、AIがどの文書を根拠に何を答えたかのログを保存します。万一の漏洩時の追跡、不適切な使い方の発見、そして回答精度の改善(よく聞かれるのに答えられない質問の把握)に役立ちます。監査ログは、後から「対策していた」と説明できる証跡にもなります。
よくある失敗パターン
導入が失敗する原因は、技術よりも準備不足にあることが多いものです。現場で多いのは次のようなケースです。
- データが未整備で精度が出ない:古い版と新しい版のマニュアルが混在していたり、PDFが画像スキャンで文字を読めなかったりすると、AIは矛盾した・古い回答を返します。RAGの精度は元データの質で決まります。
- 権限設計を後回しにする:とりあえず全文書を放り込んだ結果、見えてはいけない情報が検索でヒットする事故。リリース前の設計が必須です。
- 根拠(出典)を表示しない:回答だけ出すと、利用者が正誤を判断できず使われなくなります。出典リンク付きの回答は信頼を生みます。
- 導入して放置する:文書は更新され続けます。更新の取り込みと、答えられなかった質問の改善を回す運用がないと、半年で陳腐化します。
裏を返せば、文書の棚卸し(最新版への統一・不要文書の除外・テキスト化)を先に済ませるだけで、精度は大きく変わります。AIの導入は、社内ナレッジを整理する良い機会でもあります。製造業の現場で技術マニュアルを整備しながら進めた具体例は、製造業の技術マニュアルをAI検索する仕組みとRAG導入事例で詳しく解説しています。海外拠点や外国人スタッフ向けに、社内文書を多言語で検索対象にしたい場合は、翻訳の品質と用語統一もあわせて設計しておく必要があります。具体的な業務フローは社内文書を多言語化するAI翻訳の業務フローで解説しています。
内製と外注、どちらを選ぶか
最後に、内製(独自開発)と外注の判断軸を整理します。次の問いに答えると、自社に合う進め方が見えてきます。
判断軸 | 内製が向く | 外注・既製が向く |
|---|---|---|
社内のエンジニア | RAG・API開発の経験者がいる | 専任の開発者がいない |
目的 | 業務システムに深く組み込む | まず社内Q&Aを効率化したい |
スピード | 多少時間がかかってもよい | 早く成果を出したい |
保守体制 | 継続的にチューニングできる | 運用負荷を抑えたい |
中小企業の多くは、専任エンジニアの確保が難しく、まずは既製ツールや外注で小さく始めるのが現実的です。費用感をつかみたい場合は、社内ナレッジAIの費用相場と月額数万円で小さく始める方法もあわせて確認すると判断しやすくなります。
外注先を選ぶなら、「学習にデータを使わない構成を提案できるか」「権限設計やログまで含めて設計してくれるか」「自社の文書整備から伴走してくれるか」を見極めるとよいでしょう。ツールを売るだけでなく、業務に合わせて設計し、運用まで支える相手が良いパートナーです。Mihataでは、社内ナレッジAIや接客AIをオーダーメイドで構築し、要件整理から運用までを一貫して支援しています。