AIチャットボットの費用は5項目で決まる

AIチャットボットの見積もりを取ると、金額の幅に戸惑う。片方は小さな月額利用料で、もう片方は個別開発を含む大きな提案だ。どちらも「社内文書に答えるチャットボット」と書かれているのに、なぜここまで違うのか。

理由はシンプルだ。費用を決めるのは、チャット画面やAIモデルだけではない。どの資料を正とするか。誰に何を見せるか。間違えたときにどう止めるか。導入後に誰が更新するか。これらの条件が見積もりを動かす。

そこで、AIチャットボットの費用を5項目に分ける。見積書を受け取る前の整理にも、複数社を比較するときにも使える。

AIチャットボットの費用は「初期」と「運用」に分ける

見積もりの最初の落とし穴は、初期構築費と月額費用だけを見ることだ。実際には、次の式で考えた方がズレにくい。

費用項目は、接点・認証、データ整備、業務機能、セキュリティ、評価・運用の5つに固定する。それぞれに初期作業と継続作業がある。

したがって、初年度費用は「5項目の初期設計・構築」と「5項目の継続運用」を足して考える。月額利用料は、このうち接点・認証や業務機能に含まれる基盤費の一部だ。

クラウド側の利用料は比較しやすい。たとえば、Google CloudのConversational Agents料金表では、テキストチャットのPlaybooksは1リクエスト0.012米ドル、Flowsは0.007米ドルと示されている。データストアは月10GiBまで無料枠があり、それを超える保存量に課金される。

仮に1,000人が1日3回、月20日使うなら、6万ターンだ。1ターンを1リクエストと単純化して0.012米ドルを掛けると、リクエスト部分は月720米ドルになる。ただし、公式説明のとおり、1ターンに必要なリクエスト数は構成で変わる。為替、税、リージョン差、検索、外部API、監視、ログ保管、データ更新、有人対応も含まない試算である。実際の月額見積もりとしては使わず、利用量と単価を掛ける考え方だけを確認してほしい。

安い基盤を選んでも、毎週の資料更新を人が手作業で直していれば、総費用は下がらない。逆に、利用料が少し高くても、更新と評価が自動化されていれば、運用全体では安くなることがある。

1. 接点・認証の費用は利用者区分で決まる

最初に決めるのは、どこで誰が使うかだ。

• Web画面だけで使う
• SlackやMicrosoft Teamsから使う
• 顧客向けサイトで公開する
• 社員番号や社内アカウントでログインする
• 部門、役職、プロジェクトごとに回答範囲を変える

単独のWeb画面で、全員が同じ情報を見るなら構成は比較的軽い。ところが、SlackやTeamsと連携し、既存の認証情報を引き継ぎ、部門別に回答を出し分けると、連携とテストが増える。

ここで「後から認証を追加すればよい」と考えるのは危ない。公開情報だけを扱う構成と、社内限定資料を扱う構成では、データの持ち方そのものが変わるからだ。

利用者数だけでなく、利用者の種類と見せ分けの数を数えたい。全社員1,000人でも権限が1種類なら単純だ。利用者100人でも、顧客別・案件別・役職別に権限が分かれるなら設計は重くなる。

見積依頼時には、利用者区分と窓口を1枚の表にする。ベンダー比較では、SSO設定、SlackやTeamsのアプリ設定、アカウント追加、利用量の上限管理が初期費用と月額費用のどちらに含まれるかを見る。

2. データ整備の費用は正式版の判定で決まる

AIチャットボットの開発費を左右する最大の変数は、モデルよりデータである。

「社内資料はGoogle Driveにあります」と聞くと、すぐ検索できそうに見える。だが実際に開くと、旧版と最新版が同じフォルダにある。ファイル名が「最終」「最終2」「最新版」になっている。PDFの中に画像として文字が入っている。閲覧権限も揃っていない。

この状態では、AIは正しい答えを選べない。先に次の作業が必要になる。

1. 正式な情報源を決める
2. 旧版と最新版を区別する
3. 文書を検索できる単位に分ける
4. タイトル、更新日、対象部門などの属性を付ける
5. 更新や廃止を反映する仕組みを作る

MicrosoftのRAG設計ガイドも、文書の準備、分割、属性付与、埋め込み、検索インデックス、検索評価を別工程として整理している。ファイルを読み込ませるだけでは終わらない。

見積もりでは、ファイル数よりもデータ状態を見る。「1万件ある」より、「正式版を機械的に判定できるか」「毎月何件更新されるか」の方が費用に効く。

ここで作る成果物は、データソース台帳だ。保存場所、責任者、正式版の条件、更新頻度、廃止条件、閲覧権限を並べる。初回取り込みだけが見積もられ、更新・削除・再取り込みが除外されていないかも確認したい。

3. 業務機能の費用は「答える」と「動かす」の境界で決まる

AIチャットボットには、大きく3段階ある。

検索型なら、固定された文書群に対する標準的なRAGで足りる場合がある。MicrosoftのAIエージェント事業計画ガイドも、固定インデックスから回答や要約を返すFAQでは、複雑なエージェントより通常のRAGが適する場合があると説明している。

一方、「有給の残日数を調べて申請する」「顧客情報を確認してCRMに記録する」まで任せるなら、チャットボットは業務システムの一部になる。外部APIの失敗、二重登録、途中離脱、承認待ち、取り消しまで仕様が必要だ。

見積差が最も大きくなりやすいのが、この境界である。「答える」と「動かす」は、似ているようで別の製品だ。見積依頼には、各ユースケースを検索・案内・実行のどれにするか明記したい。

さらに、実行型では正常系だけを数えない。APIが失敗したとき、同じ依頼が再送されたとき、承認者が不在のとき、途中で取り消されたときの扱いを書く。例外フローの本数が、設計・実装・テストの工数になる。

4. セキュリティの費用は権限表と停止条件で決まる

社内資料を扱うなら、回答精度だけでなく「答えてはいけない質問」を決める。

たとえば、人事規程の一般説明は全社員に見せられる。個別の給与情報は本人と担当者に限る。顧客との契約条件は案件メンバーだけが見られる。元データの権限を、検索結果にも引き継がなければならない。

MicrosoftのマルチテナントRAG設計では、利用者の認可情報と、検索する独自データの範囲を結びつける必要がある。設計を省くと、検索できてはいけない文書が回答根拠に混ざる。

さらに、RAGは安全装置そのものではない。OWASPのPrompt Injection解説は、RAGや追加学習だけでは攻撃を十分に防げないとして、最小権限、入出力検査、高リスク操作の人間承認を挙げている。

安全対策には実装費だけでなく、検証費もかかる。

• 権限の違う利用者で同じ質問を試す
• 文書に悪意ある指示が混ざった場合を試す
• 個人情報や機密語を含む回答を止める
• 外部更新の直前に人間承認を入れる
• 誰が何を質問し、何を参照したか記録する

ここを見積書の「セキュリティ対応一式」に丸めない方がよい。対象データ、禁止回答、承認対象、ログ項目を権限表と停止条件一覧に分ければ、各社の提案を比較しやすくなる。

既存の社内AIエージェントの権限設計で詳しく扱ったとおり、参照と実行は別権限にする。本見積もりでは、その権限表を何パターン実装し、何パターン試験するかを数える。

5. 評価・運用の費用は受け入れ条件と責任分界で決まる

デモで10問に答えられたからといって、本番で使えるとは限らない。利用者は言い換え、略語、誤字、前提不足を持ち込む。資料も更新される。

RAGの評価は、回答だけを採点しない。検索が正しい文書を取れたか。回答が根拠に沿っているか。質問に答え切れているか。MicrosoftのRAG評価指標でも、文書検索と回答の評価を分けている。

NIST AI RMFは、AIの設計・開発・利用・評価にリスク管理を組み込む考え方を示している。導入時だけでなく、運用中の監視、利用者からの入力、変更管理まで含める。

月額の運用費には、少なくとも次を含めたい。

• 新規・更新文書の取り込み
• 代表質問セットによる定期評価
• 誤回答と未回答の分析
• 利用量、応答時間、1回答あたり費用の監視
• 有人窓口への引き継ぎ
• モデルや検索設定を変えた後の再試験

評価用の質問を誰も持っていない場合、最初に現場ヒアリングが必要になる。逆に、問い合わせ履歴と正解例が揃っていれば、評価設計は早い。過去の質問ログは、立派な開発資産だ。

受け入れ条件には、正答率だけでなく、根拠表示、回答拒否、権限違反、応答時間、有人引き継ぎを含める。責任分界には、文書更新、誤回答の一次確認、モデル変更、障害対応の担当者を書く。これで「運用保守一式」の中身を比較できる。

見積依頼に書くべき10項目

相場だけを聞くより、条件を10項目にして渡す方が、比較できる見積もりになる。

1. 対象業務と利用目的
2. 想定利用者数と月間の質問数
3. Web、Slack、Teamsなどの利用窓口
4. 回答に使うデータの場所、量、更新頻度
5. 利用者ごとの権限区分
6. 検索・案内・実行のどこまで求めるか
7. 回答に必須の出典表示
8. 答えてはいけない質問と停止条件
9. 合格とする代表質問と評価基準
10. 導入後の更新、監視、有人対応の担当者

この10項目が揃えば、不要な機能を外せる。たとえば、第一段階は「1部門・1データソース・検索型」に絞り、実行機能は利用状況を見て追加できる。小さく始めるとは、機能を適当に減らすことではない。検証する範囲を明確に切ることだ。

生成AI PoCの成功基準で扱ったように、試す前に契約へ進む条件を決める。正答率だけでなく、未回答率、有人引き継ぎ率、1回答あたりの総費用、文書更新にかかる時間も見るとよい。

複数社の見積もりを並べる際は、金額の横に次の4列を足すと差が見える。

「一式」の金額だけでは比較できない。前提が外れたときの追加単価まで見て、初年度の上振れを読む。

安い見積もりより、抜けの少ない見積もりを選ぶ

AIチャットボットの費用は、画面、モデル、API利用料だけでは決まらない。接点・認証、データ整備、業務機能、セキュリティ、評価・運用の5項目をそろえて初めて総額が見える。

比較するときは、金額の大小だけでなく「何が見積もりに含まれているか」を見る。初期費用が安くても、データ整理と評価が別契約なら、導入後に膨らむ。反対に、最初の設計費が高く見えても、更新と改善の手順まで含まれていれば予算を読みやすい。

自社の条件を整理しづらい場合は、業務フロー、参照データ、権限、受け入れ条件から先に分解する。株式会社Atsumellでは、AIチャットボットやAIエージェントの構築前に、何を答え、何を実行し、どこで人に戻すかを一緒に整理している。要件がまだ固まっていない段階でも、お問い合わせフォームから相談できる。

関連記事

• 生成AI PoCの成功基準は本番化の前に決める
• AIワークフローは業務フローから設計する
• 社内AIエージェントは権限設計から