社内GPT・社内AIチャットボットの構築ガイド｜方式の選び方と発注前チェックリスト

執筆：Swooo編集部／監修：諸藤 哲耀（株式会社アイビス Swooo）

社内GPT（社内AIチャットボット）とは、ChatGPTのような対話型AIを、自社の規程・マニュアル・業務知識を参照できるかたちで社内向けに整備したものです。「就業規則のこの規定はどう解釈する？」「この手続きの申請先は？」といった社内の問い合わせに、根拠となる文書を示しながら答える仕組みで、生成AIの企業活用の中で導入が進んでいる領域のひとつです。

この記事は、社内GPT・社内AIチャットボットの構築を検討している情報システム部門・DX推進担当・管理部門の方に向けて、構築方式の3つの選択肢と使い分け、そして開発会社に声をかける前に社内で整理しておくべきことのチェックリストを整理したものです。技術比較や費用相場の紹介にとどまらず、「発注前に何を決めておくと立ち上がりが速いか」「どこでつまずくケースが多いか」という実務の観点を中心に扱います。

社内AIチャットボット導入の現在地

まず前提となる状況を、確認できる公的データで押さえておきます。

総務省の令和7年版情報通信白書によると、生成AIの活用方針を定めている日本企業は49.7%（2024年度調査）です。約半数が方針を定めた段階にあり、生成AIは「一部の先進企業が試すもの」から「多くの企業が向き合う前提のもの」に移りました。
一方で、帝国データバンクが2026年3月に実施した調査（有効回答1万312社）では、生成AIを業務で活用している企業は34.5%です。方針策定は進んだものの、実際の業務活用は3社に1社という段階で、方針と実務の間にはまだ開きがあります。

この開きが生まれる理由のひとつが、汎用のチャットAIをそのまま配っても、社内の質問には答えられないことです。ChatGPTは一般知識には答えられますが、自社の就業規則・経費規程・製品マニュアル・過去の議事録は知りません。
そこで、社内文書を参照して回答する仕組み（RAG：検索拡張生成）を組み合わせた「社内GPT」「社内AIチャットボット」が、業務活用の具体的な受け皿として検討されるようになりました。あわせて、会社が公式の利用環境を用意しないままだと、社員が個人契約の生成AIに業務情報を入力してしまう、いわゆるシャドーAIの温床にもなります。公式の社内チャットボットを整備することは、利便性の話であると同時に、情報管理の実務対応でもあります。

なお、前述の帝国データバンクの調査では、活用企業の多くが効果を実感する一方で、課題としては回答内容の正確性への不安や、社内に専門人材・ノウハウが足りないこと、情報漏洩への懸念が上位に挙げられています。つまり企業側のつまずきどころは、「AIを導入するかどうか」ではなく「正確性・人材・セキュリティにどう手を打つか」に移っています。この記事の後半で扱う根拠表示の設計、運用体制、セキュリティの論点は、まさにこの3つに対応するものです。

構築方式は3択：SaaS利用・プラットフォーム・個別RAG構築

「社内GPTを作る」と一口に言っても、実装のかたちは大きく3つに分かれます。最初にこの3択の全体像を押さえておくと、開発会社との会話も、社内での検討もかみ合いやすくなります。

① SaaSをそのまま利用する

ChatGPTの法人向けプランやMicrosoft 365 Copilotのような既製サービスを契約し、ユーザー数に応じた月額課金で使う方式です。開発は不要で、契約と初期設定だけで使い始められます。法人プランでは、入力内容がAIの学習に使われない設定・契約になっているのが標準で、この点が個人向け無料プランとの大きな違いです。

この方式の守備範囲は、文書の下書き・要約・翻訳・アイデア出しといった汎用業務です。Copilotのように既存のOfficeファイルやメールを参照できるものもありますが、自社の規程やマニュアルを体系的に参照させ、根拠付きで答えさせるという「社内GPT」的な使い方には、カスタマイズの余地が限られます。
逆に言えば、検討している用途が汎用業務の効率化であれば、開発を発注する必要はありません。まず「既製SaaSで足りるかどうか」を最初に疑うのが、無駄な投資を避ける第一歩です。

② 構築プラットフォーム（Dify等）で組み立てる

Difyに代表されるLLMアプリ構築プラットフォームを使い、その上に自社用のチャットボットやRAGを組み立てる方式です。ゼロから開発するより速く、既製SaaSより自由度が高い、中間の選択肢にあたります。社内文書をアップロードして参照させる、複数のAIモデルを切り替える、条件分岐のあるワークフローを組む、といったことが画面操作中心でできるため、PoC（概念実証）を素早く回すのに向いています。

企業導入では、クラウド版とセルフホスト版（自社環境に置く形態）の選択、SSO・監査ログといった統制要件への対応など、判断すべき論点がいくつかあります。Difyの料金体系・セキュリティ審査の通し方・構築代行の選び方はDify企業導入ガイドで詳しく整理しているので、プラットフォーム型を検討する場合はそちらを参照してください。

③ 個別RAG構築（スクラッチ開発）

Azure OpenAI ServiceやAWS Bedrockといったクラウドの生成AI基盤の上に、自社要件に合わせてRAGシステムを個別開発する方式です。参照する文書の処理方法、検索の仕組み、権限制御、画面まわりまで自社仕様で作れるため、次のような要件がある場合の選択肢になります。

• 機密性が高く、データの置き場所や経路を厳密に制御したい（自社契約のクラウド内に閉じた構成にする等）
• 既存の業務システムと連携させたい（社内ポータル・基幹システム・チャットツールとのつなぎ込み）
• 部署や役職に応じて参照できる文書を変える、細かい権限設計が必要
• 独自のUIや業務フローに組み込んで展開したい

自由度が高いぶん、費用と期間は3方式の中でもっとも大きくなります。要件が固まっていない段階でいきなりこの方式に踏み込むと、後述する「PoCで止まる」失敗につながりやすいため、位置づけとしては「要件が具体化してから選ぶ方式」と考えるのが実務的です。

使い分けの判断軸：小さく始めて、要件が固まったら作り込む

3方式は排他的な選択ではなく、段階として捉えるのが実態に合っています。判断の順序は次のとおりです。

• 第1段階：既製SaaSで足りる業務はSaaSに任せる。汎用の文書作成・要約のために開発はしない
• 第2段階：社内文書を参照させたい用途は、プラットフォーム型で小さく検証する。対象業務を絞ったPoCで、精度と利用実態を確かめる
• 第3段階：基幹連携・厳格な権限設計・独自UIといった要件が具体化したら、個別RAG構築に進む。この段階では検証結果という根拠があるため、投資判断がしやすい

なお「そもそも外注するか、内製するか」という手前の論点は、本記事では深入りしません。SaaSと自社開発の使い分け、内製化の進め方と判断基準はAI内製化の進め方ガイドで整理しているので、社内開発の選択肢も含めて検討したい場合はそちらをどうぞ。以降は、外注して構築する前提で「発注前に何を整理すべきか」に進みます。

発注前チェックリスト：社内で整理しておく4項目

社内チャットボットの構築で、成否と費用をもっとも大きく左右するのは、実はAIモデルの選定ではありません。発注する側が、自社のデータと運用について何をどこまで決めているかです。ここが曖昧なまま見積もりを取ると、金額のぶれが大きくなり、開発が始まってからの手戻りも増えます。
開発会社に声をかける前に、次の4項目を社内で整理しておくことをおすすめします。

1. データの所在と鮮度：参照させたい文書はどこにあるか

RAG型のチャットボットの回答品質は、参照する文書の品質でほぼ決まります。そこで最初に必要なのが、参照させたい文書の棚卸しです。具体的には次を書き出します。

• どこにあるか：ファイルサーバー、SharePoint、Notion、グループウェア、個人のローカル、紙
• どんな形式か：Word・PDF・スプレッドシート・Webページ・スキャン画像（スキャンPDFはテキスト抽出の追加処理が必要になることが多い）
• 最新版が特定できるか：同じ規程の新旧バージョンが混在していないか。「最新版はどれか」を答えられる人がいるか
• 誰が更新しているか：更新の責任部署と頻度

実際の構築プロジェクトでは、この文書整備が工数の大きな部分を占めます。文書はあるものの旧版と新版が混在し、どれを正とするか誰も答えられない状態が判明して、開発より先に文書の整理から始めることになった、というケースは典型的です。
棚卸しが完璧である必要はありません。ただ「対象文書のリストと保管場所の一覧」があるだけで、開発会社は処理方式と工数を具体的に見積もれるようになり、見積もりの精度が大きく上がります。

もうひとつ判断しておきたいのが、議事録・チャットのやり取り・個人メモといった「非公式なナレッジ」を対象に含めるかどうかです。これらは情報量こそ多いものの、正確性の保証がなく、発言者の個人的見解や検討途中の内容も混ざります。規程・マニュアルのような「会社として正式な文書」だけを初期対象にし、非公式ナレッジは精度と運用が安定してから検討する、という線引きが実務的です。この線引き自体が、発注時に伝えるべき重要な要件になります。

2. 権限設計：誰がどの情報まで見てよいか

社内文書には、全社員が見てよいもの（就業規則・経費規程）と、特定の部署・役職しか見てはいけないもの（人事評価・給与情報・経営資料・取引条件）が混在しています。チャットボットは聞かれれば答えてしまう仕組みなので、「参照させる文書の範囲」と「誰の質問にどこまで答えてよいか」を要件として明文化しておく必要があります。

実務上の判断ポイントは、既存のアクセス権限をボットに引き継がせるかどうかです。利用者ごとに参照範囲を変える権限連携は技術的には可能ですが、設計と実装の難易度が上がり、費用に直結します。
初期段階では「全社員が見てよい文書だけを対象にする」と割り切るのが現実的な選択肢で、これだけで権限設計の複雑さは大幅に下がります。部門限定情報を扱うのは、運用が回り始めた後の拡張フェーズに回す、という段階の切り方が定石です。

3. 回答の根拠表示：出典をどう見せるか

生成AIの回答には誤り（ハルシネーション）が混ざる可能性があり、これを完全にゼロにすることは現在の技術では困難です。社内チャットボットの実務では、誤答をゼロにすることよりも、「回答の根拠となった文書を利用者がすぐ確認できること」を要件にするのが現実的な対策になります。

具体的には、回答と一緒に出典文書名とリンクを表示する、該当箇所を引用表示する、根拠が見つからない質問には「わかりません」と答えさせる、といった仕様です。これらはRAG構築では標準的な機能ですが、発注時に要件として明示するかどうかで、成果物の使い勝手が変わります。「回答には必ず出典を表示すること」「根拠がない場合は回答を差し控えること」の2点は、要件定義書に必ず入れておきたい項目です。

4. 運用担当：リリース後に誰が面倒を見るか

チャットボットはリリースした瞬間がもっとも精度が高く、放置すれば劣化していきます。規程は改定され、組織は変わり、手続きは更新されるからです。参照文書が古くなれば、ボットは自信を持って古い情報を答えるようになり、それに気づいた利用者から順に使わなくなります。

発注前に決めておきたいのは次の3点です。参照文書の更新を誰がいつ行うか（文書の責任部署と反映のルール）、回答品質を誰がどう評価するか（利用ログの確認、誤答の報告窓口）、利用者からの問い合わせを誰が受けるか。
運用を開発会社の保守契約に含めるのか、社内で担うのかによって、見積もりの構成も変わります。「運用は導入後に考える」は、後述する失敗パターンの入口です。

整理した4項目は、そのまま見積もり依頼の材料になる

ここまでの4項目を整理すると、開発会社に渡す提案依頼の骨子がほぼでき上がります。具体的には、次のセットが揃った状態です。

• 対象業務と想定利用者：最初にAI化する業務（1〜2つ）と、使う部署・人数
• 参照文書の一覧：文書リスト、保管場所、形式、更新頻度
• 権限方針：初期は全社共通文書のみか、利用者ごとの制御が必要か
• 回答仕様の要件：出典表示の必須化、根拠がない場合の回答差し控え
• 運用体制の案：文書更新・品質評価・問い合わせ対応の担当と、保守を外部委託する範囲
• 評価基準：PoCの想定質問リストと、合格とみなす正答の水準

この状態で複数社に声をかければ、各社の見積もりが同じ前提に揃うため、金額と提案内容を横並びで比較できます。逆にこれがないと、各社がそれぞれ別の前提を置いて見積もるため、金額差が「実力差」なのか「前提の違い」なのか判別できません。発注前の整理は、社内の準備であると同時に、開発会社を正しく比較するための土台でもあります。

よくある失敗パターン5つ

社内チャットボットの構築は、技術的に失敗するケースよりも、企画と運用の設計でつまずくケースの方が多い領域です。実務でよく見られる失敗を、5つのパターンに整理しました。いずれも、前章のチェックリストと表裏の関係にあります。

パターン1：作ったが使われない

もっとも多いのがこれです。「導入したが利用が定着せず、テコ入れか作り直しを検討している」というケースは典型的です。原因は複合的ですが、分解すると次の3つに集約されます。

• 精度への初期不信：最初に試したときに的外れな回答が返ると、利用者は二度目を試さない。参照文書の整備不足が精度不足として表面化するケースが多い
• 導線が悪い：普段の業務動線（チャットツールや社内ポータル）から離れた場所にあり、使うためにひと手間かかる
• 何に使えるかが伝わっていない：「何でも聞いてください」という案内だけでは、利用者は何を聞いてよいか分からない。「経費精算・社内手続き・製品仕様の質問に答えます」のように守備範囲を具体的に示す必要がある

対策は、対象業務を絞って精度を確保した状態で公開すること、業務動線上に置くこと、そして「このボットに聞けること」を具体例つきで周知することです。リリースは開発の終わりではなく、利用定着の施策の始まりと捉えるのが実態に合っています。

パターン2：PoCの精度が出ずに止まる

PoCを実施したものの期待した精度に届かず、本番化の判断ができないまま検証が終了する、というパターンです。「PoCで精度が出なかったので生成AI活用自体を見送った」というケースも典型的です。

掘り下げると、原因がAIモデルの能力ではなく、参照データの状態にあるケースが目立ちます。旧版の文書が混在して矛盾した回答が出る、スキャンPDFからテキストがうまく抽出できていない、そもそも答えの書かれた文書が存在しない、といった具合です。
また、評価基準を決めずにPoCを始めると、「なんとなく物足りない」という感想ベースの評価しかできず、続行か中止かの判断材料が残りません。PoCの前に「対象業務の想定質問リスト」と「何問中何問正答すれば合格か」を決めておくと、この空振りを避けられます。

パターン3：リリース後に情報が古くなり、信頼を失う

リリース時点では好評だったのに、半年後には使われなくなっていた、というパターンです。原因の多くは運用体制の不在です。規程改定や組織変更が参照文書に反映されず、ボットが古い情報を答えるようになる。利用者は一度誤った回答を掴まされると、以後は「結局、担当部署に聞いた方が確実」に戻ります。

厄介なのは、この劣化が静かに進むことです。エラーが出るわけではなく、ボットは古い情報を正しい体裁で答え続けます。対策は構築時に運用を設計しておくことに尽きます。文書更新の反映ルール、利用ログの定期確認、誤答の報告窓口。この3点が回っていれば、劣化は防げます。

パターン4：範囲を広げすぎて、期待値が崩れる

「せっかく作るなら全社のあらゆる質問に答えられるものを」と初期スコープを広げた結果、どの領域でも中途半端な精度になり、全方位から「使えない」という評価を受けるパターンです。参照文書が増えるほど整備の手間は増え、領域ごとの精度チューニングも薄まります。

逆説的ですが、社内チャットボットは守備範囲が狭いほど信頼されます。「経費と社内手続きのことなら確実に答える」ボットは使われ続け、「何でも聞けるが半分は外す」ボットは使われません。最初の対象は1〜2業務に絞り、利用が定着してから領域を広げる。遠回りに見えて、これが定着への最短路です。

パターン5：セキュリティ審査を後回しにして、直前で止まる

現場主導でPoCを進め、精度も利用者の評判も良かったのに、本番展開の直前になって情報システム部門や法務のセキュリティ審査に引っかかり、そこから数ヶ月停滞する、というパターンです。「検証はうまくいったのに、審査対応のやり直しで止まっている」というケースは典型的です。

Difyなどのプラットフォームで構築する場合の審査要件（データ所在・ログ・アクセス制御など）は、Difyの企業導入ガイドで具体的に整理しています。

審査で問われるのは、データの保管場所、入力内容が学習に使われないことの確認、アクセス制御、ログの取得体制といった論点で、方式選定の段階で決まってしまう項目が多いのが厄介な点です。クラウド版で検証を進めた後に「自社環境に閉じた構成でなければ承認できない」となれば、構成の作り直しになります。
対策はシンプルで、方式を選ぶ段階から審査部門に一枚かんでもらうことです。「この構成なら審査を通せるか」を先に確認してからPoCを始めれば、検証結果を無駄にせずそのまま本番構成に引き継げます。

構築の進め方5ステップ

チェックリストと失敗パターンを踏まえると、進め方は次の5ステップに整理できます。

ステップ1（対象業務の選定）では、「問い合わせ件数が多い」「答えが文書に明文化されている」「間違えたときの影響が限定的」の3条件が揃う業務が最初の対象に向いています。社内手続き・経費・情シスのFAQ対応あたりが定番です。答えが人の頭の中にしかない業務は、文書化が先でありチャットボットの出番はまだ先です。
どの業務が既製ツールで済み、どの業務に開発が効くのかを部門単位で切り分ける考え方は、総務のAI活用ガイドで詳しく整理しています。管理部門の業務から着手する場合は、あわせて参考にしてください。

ステップ2（データの棚卸しと整備）は前章のチェックリスト1・2をそのまま実行する工程です。ここは自社にしかできない作業ですが、どこまで整備すれば十分かの見極めは開発会社の助言を受けながら進めると効率的です。完璧な整備を待つ必要はなく、対象業務の分だけ整えばステップ3に進めます。

ステップ3（方式選定とPoC）では、要件に応じて3方式から選び、小さく検証します。期間は1〜2ヶ月程度が一般的です。ここで重要なのは、事前に用意した想定質問リストと合格基準で評価することです。感想ではなく正答率で判断できれば、本番化の判断も、見送りの判断も、根拠を持って下せます。

ステップ4（パイロット運用）では、限定した部署で実業務に使ってもらい、利用率・質問内容・回答品質を実測します。PoCでは見えなかった「実際に社員が何を聞くか」がここで初めて分かり、参照文書の追加やチューニングの方向が定まります。

ステップ5（展開と運用）で対象部署・対象業務を広げ、文書更新と品質確認のサイクルを定常運用に乗せます。利用側の教育もこの段階の論点です。質問の仕方ひとつで回答品質は変わるため、展開時に短い利用ガイドや研修をセットにすると定着が速くなります。Swoooでは法人向けのAI研修（全3回9時間・1人10万円）も提供しており、詳細はAI研修のページにまとめています。

費用の目安：市場の一般相場

外注で構築する場合の、市場の一般的な相場感は次のとおりです。構築する内容の複雑さで階段状に変わります。

同じ「社内チャットボット」でも幅が大きいのは、金額を動かす変数がいくつもあるためです。主な変数は、参照する文書の量と状態（整備済みか、スキャンPDF等の追加処理が要るか）、権限設計の複雑さ（全社共通か、利用者ごとに参照範囲を変えるか）、連携するシステムの数（チャットツール・社内ポータル・基幹システム）、インフラ要件（クラウドの標準構成か、自社環境に閉じた構成か）です。前章までのチェックリストが整理できていれば、この変数を具体的に伝えられるため、見積もりの精度と比較のしやすさが大きく変わります。

もうひとつ見落とされがちなのが、初期開発費とは別建てのランニングコストです。AIの応答ごとにかかるLLM API利用料、インフラ費、保守費は継続的に発生します。見積もりを取る際は「初期費用に何が含まれ、月々何がかかるか」を必ず確認してください。とくにAPI利用料は利用量に比例するため、パイロット段階で実測してから全社展開の予算を組むのが確実です。

セキュリティ・ガバナンスの基本論点

社内チャットボットは社内情報を扱う仕組みである以上、セキュリティとガバナンスの設計が導入の前提になります。公的機関から実務の指針が出ているので、まずそれを押さえるのが早道です。なお、ここで挙げるのは一般的な論点の整理であり、個別の法的評価は状況によって変わります。最終的には自社の法務部門や専門家への確認を前提にしてください。

• 個人情報の取り扱い：個人情報保護委員会は2023年6月に、生成AIサービスの利用に関する注意喚起を公表しています。個人情報を含む内容を入力する場合は利用目的の範囲内かの確認が必要で、入力内容がサービス側で応答生成以外の目的に取り扱われる場合には個人情報保護法上の問題が生じ得る、という趣旨です。学習に使われない契約・設定の確認が実務の起点になります
• 利用ルールの整備：IPA（情報処理推進機構）は2024年7月に「テキスト生成AIの導入・運用ガイドライン」を公表しています。機密情報の入力ルール、出力内容の事実確認、著作権への配慮、プロンプトインジェクション対策、AI利用ポリシーの策定といった項目が柱で、社内ルールを作る際の下敷きに使えます
• 技術面の設計：参照文書のアクセス制御、通信と保管の暗号化、利用ログの記録と監査可能性、データの保管場所（国内か海外か、自社環境に閉じるか）。要件の厳しさに応じて、前述の3方式のどれを選ぶかにも直結します

ガバナンスというと構築のブレーキと捉えられがちですが、実務では逆の面もあります。会社が安全な公式環境を用意しないままだと、社員が個人契約のAIサービスに業務情報を入力する状態を止めにくくなります。入力ルールとセットで公式の社内チャットボットを整備することは、それ自体がシャドーAI対策の実務解になります。「禁止だけして代替を与えない」状態がもっともリスクが高い、というのが多くの企業の実感に合うはずです。

実務の落としどころとしては、情報の機密度に応じて使う環境を分ける設計が広く採られています。一般的な文書作成は法人契約のSaaSで、社内規程やマニュアルの参照は学習利用のない社内チャットボットで、社外に出せない契約・人事情報を扱う処理は自社契約のクラウド内に閉じた個別構築で、という三層の使い分けです。すべてを最高レベルの構成で作る必要はなく、扱う情報のレベルに構成を合わせることで、費用とセキュリティ要件の両方に無理のない着地点を作れます。

よくある質問

Q. 社内GPTとRAGは何が違うのですか？

社内GPTは「社内向けに整備した対話型AI」という用途側の呼び名で、RAG（検索拡張生成）はそれを支える技術方式の名前です。RAGは、質問に関連する社内文書を検索し、その内容を根拠としてAIに回答させる仕組みを指します。社内の規程やマニュアルに答えられる社内GPTを作ろうとすると、実装としてはRAGを使うのが現在の標準的な構成です。発注時の会話では「RAG型の社内チャットボット」とほぼ同じ意味で使われている、と理解しておけば実務上は困りません。

Q. 構築期間はどれくらいかかりますか？

規模と方式によりますが、PoCで1〜2ヶ月程度、本番構築は数ヶ月単位が一般的な目安です。既製SaaSの導入なら契約と設定のみで数週間かかりません。期間を左右する最大の要因は開発作業そのものよりも、参照文書の整備と社内の意思決定です。発注前に対象業務とデータの棚卸しが済んでいれば、その分だけ立ち上がりは速くなります。

Q. 費用を抑えるにはどうすればよいですか？

効果が大きいのは3つです。第一に、既製SaaSで足りる業務に開発費をかけないこと。第二に、初期スコープを1〜2業務に絞ること。対象文書が減れば整備コストも構築費も下がり、精度も出しやすくなります。第三に、権限設計を初期は「全社員が見てよい文書のみ」に割り切ること。利用者ごとの権限連携は費用を押し上げる代表的な要因なので、拡張フェーズに回す判断が有効です。安く作ること自体より、小さく確実に立ち上げて根拠を持って追加投資する、という順序がもっとも無駄がありません。

Q. 回答の精度はどこまで期待できますか？

100%の正答は現在の技術では保証できません。前提にすべきは「誤答をゼロにする」ではなく「誤答があっても業務が壊れない設計にする」ことです。具体的には、回答に出典文書を必ず表示して利用者が確認できるようにする、根拠が見つからない質問には答えを差し控えさせる、重要な判断は人が最終確認する運用にする、の3点です。この設計があれば、多少の誤答があっても「調べる時間を大幅に短縮するツール」として十分に機能します。精度そのものは、参照文書の整備状態に大きく依存します。

Q. 内製と外注、どちらで進めるべきですか？

社内にエンジニアがいて継続的に手を入れられるなら内製、スピードと確実性を優先するなら外注、というのが大枠です。実務では「初期構築は外注し、運用しながら内製に移す」ハイブリッドも有力な選択肢で、Dify等のプラットフォーム型はこの移行がしやすい構成です。判断基準の詳細はAI内製化の進め方ガイドで整理しているので、そちらを参照してください。

まとめ：発注前の整理が、社内GPTの成否を分ける

最後に、この記事の要点を整理します。

• 生成AIの活用方針を定めた企業は49.7%（総務省 令和7年版情報通信白書・2024年度）、業務で活用している企業は34.5%（帝国データバンク・2026年3月調査、有効回答1万312社）。方針と実務の間を埋める受け皿として、社内文書を参照できる社内GPT・社内AIチャットボットが検討されている
• 構築方式は「既製SaaS利用」「Dify等のプラットフォーム」「個別RAG構築」の3択。SaaSで足りる業務に開発はせず、プラットフォームで小さく検証し、要件が固まったら作り込む、という段階論が基本
• 成否を分けるのは発注前の整理。参照文書の所在と鮮度、権限設計、根拠表示の要件、運用担当の4項目を社内で決めてから声をかけると、見積もり精度も立ち上がりも変わる
• 典型的な失敗は「使われない」「PoCで止まる」「運用不在で劣化」「範囲の広げすぎ」「セキュリティ審査で直前に停滞」の5つ。いずれも技術ではなく企画・運用の設計で防げる
• 費用の一般相場は、LLM API活用で50万〜300万円、RAG・業務組み込みで100万〜1,000万円、AIエージェント型で500万〜3,000万円。初期費用とは別にAPI利用料・保守などのランニングコストを必ず確認する

Swoooは、対象業務の切り分けとPoCから、RAG構築・既存システムとの連携、リリース後の運用保守まで担当します。運営は東証グロース上場の株式会社アイビス（証券コード9343）です。対象業務の選び方や方式選定の段階からでも、ご相談ください。サービスの詳細は業務AI化支援のページにまとめています。

関連ガイド：Dify企業導入ガイド／AI内製化の進め方／総務のAI活用ガイド／AI研修