「社内の規程やマニュアル、過去の見積りを生成AIに答えさせたい。けれど、どう作ればいいのか、何から始めればいいのかが分からない」——社内向けの生成AI構築を検討する情シス・DX推進・経営企画の方から、いま最も多くいただく相談です。
ChatGPTのような汎用AIは便利ですが、自社の社内文書は知りません。そこを埋めるのが「社内データを参照させる生成AIの構築」です。結論から言えば、社内 生成AI 構築の最短ルートは「RAGで社内データを参照させる方式」を選ぶこと。 そのうえで、用途を1つに絞ってPoC（小さな実証）から始めるのが定石です。本記事では、選択肢の比較・RAGの作り方・閉域網のセキュリティ・PoCの進め方と落とし穴までを実務目線で解説します。
この記事の結論（先出し）
– 社内生成AIの第一選択はRAG（社内データを検索して回答に使う方式）。ファインチューニングより速く・安く・更新が容易。
– 機密度が高いなら閉域網／プライベートクラウド前提でアーキテクチャを逆算する。
– 用途を1つに絞り、KPIと撤退基準を先に決めてPoCから始めるのが成功率を最も上げる。
– 規模感の目安：RAGのPoCは概ね数週間〜2か月、コストは「クラウドAPI＜RAG＜ファインチューニング」の順で上がる。
なぜいま「社内向けの生成AI構築」なのか
総務省の令和7年版 情報通信白書によると、生成AIを「業務に活用している／活用方針を定めている」と答えた日本企業の割合は2024年度調査で49.7%（2023年度の42.7%から増加）に達しています（出典: 総務省 令和7年版 情報通信白書。同白書の企業向けアンケート調査に基づく値）。生成AIは「試す」段階から「自社業務にどう組み込むか」へ移りつつあります。
一方で、IPAの「DX動向2025」では「DX推進人材が不足している」と回答した日本企業が85.1%にのぼり、米独より突出して高いと報告されています（出典: IPA DX動向2025）。つまり「やりたいが、作り方と進め方が分からない」企業が大半、という構図です。
汎用のクラウドAIをそのまま使うだけでは、(1)自社の社内文書を知らない、(2)機密情報を外部に送ることへの懸念が残る、という二つの壁にぶつかります。この両方を解くために、社内データを参照でき、必要なら社外にデータを出さない生成AIを自社向けに構築する、という発想が必要になります。
これは私たちキュリオシティが掲げる「現場主義 × AI」——現場の業務に密着したうえでAIを設計する——という考え方とも一致します。
社内生成AIを構築する3つの選択肢
社内向け生成AIの構築アプローチは、大きく3つに整理できます。
| 方式 | 概要 | 手軽さ | 社内データ活用 | コスト | 更新性 |
|---|---|---|---|---|---|
| ① クラウドAPI活用 | 既製の生成AIをそのまま使う／プロンプトで工夫 | ◎ すぐ | △ 都度貼付け | 低 | ◎ |
| ② RAG | 社内データを検索して回答に使わせる | ○ | ◎ 強い | 中 | ◎ 文書差替で即反映 |
| ③ ファインチューニング | モデル自体を社内データで追加学習 | △ 専門知識要 | ○ | 高 | △ 再学習が必要 |
※構築期間の目安（あくまで概算・自社の状況で変動します）：①は即日〜数日、②RAGのPoCは数週間〜2か月程度、③ファインチューニングは学習データ整備を含め数か月規模になりがちです。コストも①→③の順に上がる傾向があり、まずは小さく検証できる②から入るのが安全です。
まず「RAG」を選ぶべき理由
多くの社内ユースケース（規程・マニュアル・FAQ・過去案件の検索的な回答）では、RAG（Retrieval-Augmented Generation）が費用対効果で最も優れます。
- ファインチューニングはモデルを学習し直すためコストと専門知識のハードルが高く、文書が変わるたび再学習が要ります。
- RAGは社内文書を差し替えるだけで回答が最新化され、「どの文書を根拠にしたか」を出典として示せるため、ハルシネーション（もっともらしい誤答）も抑えやすい。
実際、私たちが製造業（数百名規模）の設計・品質マニュアルを対象に支援したPoCでも、ファインチューニングではなくRAGを選び、「出典を必ず表示する」設計にしたことで、問い合わせの一次回答にかかる時間が体感で数分単位から十数秒のオーダーに短縮し、現場が回答を信頼して使える状態に近づきました（※匿名化のため、業界・規模・概要のみ。具体的な実名・正確な実数は非開示。改善幅は対象文書や運用設計で大きく変動します）。
なお、ファインチューニングが例外的に有効なのは、回答の文体・専門用語・出力フォーマットを強く固定したいケース（例: 定型の社内文書ドラフトを一貫したトーンで生成させたい等）です。多くの「社内文書を検索して答える」用途ではRAGが優先されます。
RAGで社内データを活用する「作り方」
RAGは難解に見えますが、構成要素は4つに分解できます。
- データソース：社内規程・マニュアル・FAQ・議事録などを集める。
- チャンク分割＋埋め込み（ベクトル化）→ ベクトルDB：文書を適切な長さに区切り、意味で検索できる形にしてデータベースに格納する。
- 検索（Retrieval）：ユーザーの質問に意味的に近い文書片を取り出す。
- 生成（Generation）：取り出した文書片を根拠として、生成AIが回答と出典を返す。
この流れは、各クラウドベンダーの公式ドキュメントでも標準パターンとして示されています。たとえばAWSのAmazon Bedrock Knowledge Basesはデータ指定だけでチャンク化～出典付き回答までをマネージドで提供し、MicrosoftのAzure OpenAI On Your DataはAzure AI Searchと組み合わせ「クエリ再構成→検索→生成」の3段階で社内データに基づく回答を返します。
精度を決めるのは「チャンク設計」と「出典必須」
RAGの当たり外れは、モデルの賢さよりもチャンク設計（区切り方）と検索精度で決まります。区切りが粗いと無関係な情報が混ざり、細かすぎると文脈が切れます。私たちの実務所感では、最初に「出典（参照文書）を必ず表示する」仕様にしておくと、現場が回答の真偽を自分で確かめられ、導入初期の信頼を一気に高められます。これは間接業務の効率化にも直結します（関連: 間接業務の効率化）。
セキュリティと閉域網：社外にデータを出さない構築方式
社内文書を扱う以上、「機密情報を外部に出さない」設計は避けて通れません。構築方式は、機密度に応じて主に3つに分かれます。
- API連携型：クラウドの生成AIを使うが、IP制限・専用接続・オプトアウト（入力を学習に使わせない）設定で守る。手軽さ重視。
- プライベートクラウド（VPC）型：自社専用のクラウド領域に閉じ、専用線/VPNで接続。バランス型。
- オンプレミス／閉域網型：社外にデータを一切出さない。機密度が最も高い金融・公共・製造の機微情報向け。
私たちが情報管理の厳格な金融系部門を支援した際は、「社外APIに送信しない」という要件を出発点に、要件からアーキテクチャを逆算しました。「便利だから」と方式を先に決めるのではなく、守るべき情報の機密度から構築方式を決めるのが鉄則です。
AI事業者ガイドラインと社内ルールを先に固める
技術と並行して欠かせないのが、社内のガバナンス整備です。総務省・経済産業省はAI事業者ガイドライン（第1.1版）を公表し、AIの開発・提供・利用に関わる事業者が取るべき基本的な考え方を示しています。入力してよい情報の範囲・利用禁止用途・ログの扱いを社内ルールとして先に定め、構築の前提条件に組み込んでおくと、後戻りを防げます。こうした業務とルールの再設計は、業務改善コンサルティングの領域とも重なります（関連: 業務改善コンサルティング）。
PoCの進め方｜用途を1つに絞り、KPIと撤退基準を先に決める
社内生成AIの構築は、いきなり全社展開せず、PoC（小さな実証）から段階的に進めます。
- 活用方針の検討：どの業務の・誰の・どの困りごとを解くかを1つに絞る。
- 利用環境の構築：機密度に応じた構築方式（前章）を選び、最小構成で用意する。
- PoC：問い合わせ頻度の高い文書（マニュアル・FAQ・規程）から着手し、KPIと撤退基準で評価する。
- 本開発・スケール：効果が出た用途を横展開する。
- 定着・継続改善：チャンクや検索の精度、社員教育、ルールを回し続ける。
PoCの設計から本番実装までの伴走支援については生成AI開発・PoC支援で詳しく紹介しています。PoCで最初に決めるべきは評価KPIと撤退基準です。たとえば「一次回答の自己解決率（PoCの初期実測は概ね5〜7割のレンジに収まることが多い）」「回答までの時間」「正答率（出典との一致率）」を指標に置き、対象は問い合わせ頻度の高い数十〜数百件規模の文書に絞り、「8週間で自己解決率◯%に届かなければ用途を変える／止める」と数値で先に決めておく。私たちのPoC支援でも、この撤退基準を最初に握れたケースは判断が速く、握れなかったケースは「なんとなく続く」状態に陥りがちでした。指標がないと、PoCは「なんとなく便利そう」のまま終わります。
よくある落とし穴（実務で最も多い失敗）
私たちが社内向け生成AI／閉域網AIのPoC支援で繰り返し見てきた失敗は、次の4つに集約されます。
- 全社一括で始めてしまう：用途が広がりすぎて評価軸が曖昧になり、撤退判断ができない。→ 用途を1つに絞る。
- KPIと撤退基準を決めていない：「やめどき」が分からず延々と続く。→ 始める前に数値で決める。
- 出典を表示しない：現場が回答を信用できず使われない。→ 出典必須を初期仕様に。
- 運用・更新設計がない：文書が古いまま回答が陳腐化する。→ 更新フローと担当を最初に決める。
これらは、ツールの良し悪し以前の「進め方」の問題です。実際の改善事例の積み上げ方は業務改善の事例集も参考になります。
まとめ：RAGで小さく作り、出典と撤退基準で「使われる」AIにする
社内向け生成AIの構築は、(1)RAGで社内データを参照させるを第一選択とし、(2)機密度から構築方式（閉域網含む）を逆算し、(3)用途を1つに絞ってKPI・撤退基準を先に決めたPoCから始める——この3点を押さえれば、過半数の企業がつまずく「作り方と進め方が分からない」を越えられます。
「自社のどの業務から、どう小さく始めればよいか」を具体的に設計したい方へ。生成AIのPoCを失敗なく企画するための「生成AI PoC企画テンプレート」を無料で配布しています。用途の絞り込み・KPI設計・撤退基準のフレームをそのまま使えます。
📄 生成AI PoC企画テンプレートを無料ダウンロード
用途選定・KPI・撤退基準・体制までを1枚で整理できるテンプレートです。自社の状況に合わせて構築方式やPoC設計を相談したい方は、無料相談もご利用ください。
監修：大槻 伸夫（キュリオシティ株式会社 代表取締役CEO）。「現場主義 × AI」を掲げ、製造・金融・BPOなど複数業界で社内向け生成AI・閉域網AIのPoC設計から業務改善・PMI支援まで、現場に入り込んだ伴走型の支援を多数統括している。
