「社内の問い合わせをチャットボットで減らしたい」という相談は、ここ数年でかなり増えました。そして最初に必ず出てくるのが「既製品を契約すべきか、自社向けに作るべきか」という問いです。
この問いに、機能一覧の比較表で答えを出そうとすると迷います。どの製品も「社内文書を読み込んでAIが答える」と書いてあり、デモを見れば大抵うまく動くからです。差が出るのは機能ではなく、データをどこに置くか・誰が更新するか・誰に何を見せるか・いくらかかるか・壊れたとき誰が直すかの5点です。本稿ではこの5点に絞って、中小企業が判断するための見方を整理します。
機能比較で決まらない理由
社内チャットボットの中身は、多くの場合RAG（検索拡張生成）という仕組みです。質問が来たら社内文書の中から関係しそうな部分を検索で取り出し、それをAIモデルに渡して文章を作らせる、という二段構えになっています。つまり「検索して当てる部分」と「文章にする部分」が別物です。
製品のデモで差が付きにくいのは、後者のAIモデルが各社ほぼ同じ基盤を使っているためです。実務で差が出るのは前者、すなわち自社の文書がどれだけ検索しやすい形で置かれているかという点で、これは製品の性能ではなく自社側の状態に依存します。この構造についてはRAG の精度はモデルではなく文書管理で決まるで詳しく書きました。
したがって「どちらが賢いか」ではなく「自社の文書・権限・体制にどちらが噛み合うか」で選ぶことになります。
5点の比較軸を一覧にする
既製品（SaaS型のチャットボットサービス）と、受注開発による自社構築を、5点で並べると次のようになります。なお既製品にも設定の自由度が高いものから低いものまで幅があるため、あくまで傾向として読んでください。
| 観点 | 既製品（SaaS） | 自社構築（受注開発） |
|---|---|---|
| データの置き場 | 提供事業者のクラウド。保存先の国・契約条件は規約で確認 | 自社が選べる。社内環境・指定クラウドも可 |
| 更新 | 管理画面から手動アップロードが中心。自動同期は対応製品に限る | 既存のファイルサーバーや基幹システムと連携して自動化できる |
| 権限 | 製品が用意した単位（部署・グループ）に合わせる | 自社の人事・職位の体系に合わせて設計できる |
| 費用 | 月額（利用人数または質問数に連動）。初期費用は小さい | 初期の開発費が大きく、稼働後は実行費と保守費 |
| 保守 | 提供事業者が対応。仕様変更は受け入れる前提 | 自社または開発会社。変更の主導権は持てる |
表にすると分かりやすいのは、既製品は「決まっているから早い」、自社構築は「決められるから合わせられる」というトレードオフだということです。どちらが優れているという話ではありません。
データの置き場と更新 — 最初に潰すべき2点
置き場は「規約」と「社内規程」の両方を見る
社内文書をクラウドに置くこと自体は、今では珍しくありません。確認すべきは次の3点です。
- 入力した内容がAIモデルの学習に使われるか。使われない設定になっているか
- データの保存先リージョン（国・地域）と、保存期間
- 個人情報を含む場合、個人情報保護法でいう委託先管理の要件を満たせるか
業種によっては、取引先との秘密保持契約や業界団体のガイドラインで、外部サービスへのデータ保管に条件が付いていることがあります。契約書の条項を先に確認しておくと、後から差し戻されずに済みます。クラウドと社内設置のどちらを取るかの判断軸はクラウドAIか、社内設置かでも整理しています。
更新が止まると、ボットは静かに嘘をつく
導入直後は正しく答えていたのに、半年後には古い規程を答えるようになる。これが社内チャットボットで最も起きやすい失敗です。モデルが劣化したのではなく、読み込ませた文書が更新されていないだけです。
検討時に決めておくべきことは2つです。
- 更新の頻度と方式（担当者が都度アップロードするのか、フォルダを定期的に自動取り込みするのか）
- 更新の責任者（文書を改訂した部署が、同時にボット側も直す運用になっているか）
既製品で自動同期に対応していない場合、この手作業が毎月の負担として残ります。文書の改訂が多い会社ほど、自動取り込みを前提に設計できる自社構築が効いてきます。
権限設計 — ここでつまずく案件が最も多い
社内チャットボットで一番厄介なのが権限です。「全社員が同じ答えを見られればよい」なら話は簡単ですが、実際にはそうなりません。たとえば次のような場面です。
- 人事評価や給与テーブルの規程は、管理職だけが参照できる
- 顧客との個別契約条件は、担当部署以外には見せられない
- 役員会資料は、閲覧者が記録として残る必要がある
ここで問題になるのは、RAGが「質問者が見てよい文書だけを検索対象にする」仕組みになっているかです。全文書をまとめて1つの検索対象に入れてしまうと、権限のない人の質問に対しても機密文書から答えが作られてしまいます。AIが要約した形で出てくるため、ファイル権限の制御だけでは防げません。
既製品を選ぶ際は、次の点を具体的に質問してください。
- 利用者ごとに検索対象を分けられるか。分ける単位は何か（フォルダ単位か、タグ単位か）
- 既存のアカウント基盤（Microsoft Entra ID、Google Workspace など）と連携して権限を引き継げるか
- 誰がいつ何を質問し、どの文書が参照されたかのログが残るか
3つ目のログは、権限設計の検証と、後から「なぜこの答えが出たか」を追うために必要です。この設計項目についてはAIの「なぜこの答えになったか」を後から追う — ログ設計で決めるべき7項目にまとめています。
費用と保守 — 月額の安さだけで比べない
費用の比較では、初期費用と月額だけを並べがちですが、実務で効いてくるのは次の3つです。
| 費目 | 見落としやすい点 |
|---|---|
| 利用量に応じた費用 | 質問数・文書量が増えると月額が段階的に上がる契約があるため、1年後の想定利用量で試算する |
| 文書整備の人件費 | 既製品でも自社構築でも共通して発生する。むしろここが最大の初期コストになることがある |
| モデル更新への追従 | 基盤モデルの世代交代で、以前は正しく答えていた質問の挙動が変わることがある |
3つ目は自社構築で特に意識すべき点です。保守費を「障害対応の費用」としてだけ見積もると、モデルが変わったときの再検証や調整が予算外になります。この考え方はAI機能の保守費は「モデルが変わる日」を先に見積もるで詳しく扱っています。
既製品の場合、この追従は提供事業者が行いますが、裏を返せば変更のタイミングを自社で選べないということでもあります。繁忙期に挙動が変わっても、こちらからは止められません。これを「手間が省ける」と見るか「リスク」と見るかは、業務の性質によります。
判断の手順 — 3ステップで絞る
以上を踏まえると、判断は次の順で進めるのが現実的です。
- 扱う文書に機密区分があるかを確認する。全社員が見てよい文書だけで足りるなら、既製品で十分な可能性が高い。区分が必要なら、権限連携の可否が最優先の選定条件になる
- 文書の改訂頻度を数える。月に数回程度の改訂なら手動更新でも回る。週単位で改訂が入るなら、自動取り込みの設計が必要になる
- まず既製品で小さく試す。どちらに転ぶ場合でも、文書整備は必ず必要になる。既製品で3か月運用し、「どの質問に答えられなかったか」を記録すると、自社構築に進む際の要件がほぼそのまま書ける
3つ目が重要です。いきなり自社構築に進むと、要件が「社内の問い合わせに答える」という曖昧なまま開発が始まり、検収段階で揉めます。既製品での試行は、それ自体が要件定義の作業になります。
まとめ
社内チャットボットの「作るか買うか」は、AIの性能ではなく、データの置き場・更新・権限・費用・保守の5点で決まります。整理すると次のようになります。
- 全社員共通の文書が中心で、改訂が少ないなら既製品が合いやすい
- 職位や部署で見せる範囲を分ける必要があり、文書の改訂が頻繁なら自社構築の検討価値がある
- どちらでも文書整備の工数は発生する。ここを外注先に丸投げできない点は共通
- まず既製品で小さく試し、答えられなかった質問を記録することが、次の判断材料になる
最初から完成形を目指す必要はありません。「どの質問に答えられれば業務が楽になるか」を10個書き出すところから始めれば、比較の軸は自然と絞れます。