AIや生成AIの導入を検討していると、ベンダーから数百万円規模の提案を受けることがあります。ところが、社内にAIやシステム開発を詳しく評価できる人材がいない場合、「この機能は本当に必要なのか」「技術的に妥当なのか」「500万円は高いのか」と判断に迷うことがあります。
ここで注意したいのは、AIシステムの提案は、総額だけを見ても妥当性を判断しにくいことです。
同じ「社内向け生成AIチャットボット」でも、既存サービスを設定するだけなのか、社内文書を検索する仕組みを構築するのか、SSOや権限制御を実装するのか、基幹システムと連携するのかによって必要な作業は変わります。
そのため、「500万円は高いか」という問いを、「何を実現するための500万円なのか」「その要件が自社に必要なのか」という問いへ変えることが重要です。
本記事では、架空の企業が「社内問い合わせ対応用の生成AIチャットボットを初期費用500万円で導入する」という提案を受けたケースを使い、AIベンダーの提案を発注前に確認する7つのポイントを整理します。
AIベンダーの提案は金額だけでは評価できない
例えば、2社から同じ500万円の見積もりを受けたとしても、その内容が同じとは限りません。
- 要件定義
- 社内文書の整理・データ整備
- 生成AIとの接続
- 社内文書検索
- 認証・権限管理
- 既存システムとの連携
- 評価・テスト
- 本番移行
- 利用者教育
のどこまで含まれているかによって、500万円の意味は変わります。
また、生成AIサービスには、汎用サービスをそのまま利用する形、企業向けに設定や機能を追加する形、新たにシステムを開発する形などがあります。経済産業省の「AIの利用・開発に関する契約チェックリスト」でも、汎用AIサービス利用型、カスタマイズ型、新規開発型など、AIの利用形態によって契約上の論点が異なることが整理されています(経済産業省, 2025)。
したがって、まず市場価格と比較するのではなく、提案内容を構成要素へ分解する必要があります。
500万円の生成AIチャットボット提案を例に考える
ここでは、社内問い合わせ対応を目的として、生成AIチャットボットを初期費用500万円で構築する提案を受けたとします。なお、この金額は記事説明用の架空例であり、市場相場を示すものではありません。
提案書には「生成AI」「RAG」「API連携」「社内データ活用」といった技術用語が並んでいたとしても、それだけでは発注判断はできません。
RAG(Retrieval-Augmented Generation:検索拡張生成)とは、生成AIが回答を作成する際に、社内文書等の外部情報を検索して参照させる仕組みです。社内FAQや規程を参照する用途では有力な方式ですが、RAGを採用すれば自動的に回答が正確になるわけではありません。文書の内容、更新状態、検索精度、質問の性質等によって回答品質は変わります。
そこで、以下の7点を順番に確認します。
1. 目的・課題:AIチャットボットで何を改善するのか
最初に、「チャットボットを導入したい」ではなく、現在何に困っているのかを確認します。
- 社内問い合わせが月に何件あるか
- どの部署へ問い合わせが集中しているか
- 回答にどの程度の時間がかかっているか
- 既存FAQや社内検索では不足する理由は何か
- 回答時間短縮によって何を改善したいか
問い合わせ件数が少なく、既存FAQを整理するだけで十分な場合には、生成AIシステムを新たに構築する必要性が低い可能性もあります。
2. 要件:提案されている機能は本当に必要か
次に、500万円の見積もりに含まれる機能を一つずつ確認します。
- 何人が利用するのか
- どの部署を対象にするのか
- どの文書を検索対象にするのか
- 部署・役職別の閲覧制御が必要か
- 回答の根拠となった文書を表示する必要があるか
- SSO等の認証が必要か
- 既存システムとの連携が必要か
- 管理画面や利用ログが必要か
要件が増えるほど設計・実装・試験の範囲も増えます。反対に、「あると便利」程度の機能を外すことで、小さい範囲から検証できる場合もあります。
3. 技術方式:なぜその方法が必要なのか
技術名称そのものではなく、その技術を採用する理由を確認します。
- なぜ生成AIが必要なのか
- なぜRAGを利用するのか
- 既製のAI・SaaSでは対応できない理由は何か
- どの部分を個別開発するのか
- 外部のAIモデルやAPIへどの程度依存するのか
例えば既製サービスで要件の大部分を満たせるのであれば、最初から個別開発する方法だけでなく、既製サービスを限定範囲で試す方法も比較対象になります。
4. 評価方法:「精度90%」の意味を確認する
AI提案では「回答精度90%」「高精度な回答」といった説明が出ることがあります。しかし、数字だけでは判断できません。
- どの質問を使って評価したのか
- 何件の質問で試験したのか
- 誰が正解・不正解を判断したのか
- 完全に正しい回答だけを正解としたのか
- 回答できない質問をどう評価したのか
- 根拠のない回答をどう扱ったのか
を確認する必要があります。
NISTのAI Risk Management Frameworkでは、AIの評価を単純な精度だけで捉えず、信頼性、安全性、プライバシー、透明性等を含むリスク管理の対象として整理しています(Tabassi, 2023)。生成AIについても、人によるレビュー、記録、監視等を含む追加的な管理が必要になる場合があると整理されています(Autio et al., 2024)。
社内チャットボットであれば、「分からない質問に無理に回答しない」「参照元を提示する」といった挙動も重要な評価項目です。
5. セキュリティ・リスク:入力した情報はどこへ行くのか
生成AIでは、回答品質と同時に情報の扱いを確認します。
- 入力データはどこへ保存されるか
- 入力内容がAIモデルの学習へ利用されるか
- 顧客情報や個人情報を入力できる設計か
- アクセス権限をどのように制御するか
- 利用ログを誰が閲覧できるか
- 外部AIサービスへどの情報が送信されるか
- インシデント時の連絡・対応方法は決まっているか
を確認します。
総務省・経済産業省の「AI事業者ガイドライン 第1.2版」でも、AI利用者を含む各主体に対してリスク管理やAIガバナンスの考え方が整理されています(総務省・経済産業省, 2026)。また、経済産業省の契約チェックリストでは、AIサービスへ提供するデータの利用範囲や第三者提供等も契約時の検討項目とされています(経済産業省, 2025)。
6. 費用・ROI:500万円に何が含まれているか
初期費用の総額だけではなく、その内訳を確認します。
- 要件定義
- 社内文書・データ整理
- システム構築・設定
- 認証・システム連携
- 評価・テスト
- 利用者教育
- 本番移行
さらに、導入後にはAPI利用料、クラウド利用料、保守費、文書更新、品質確認、追加改修などの費用が発生する場合があります。
そのため、初期500万円だけではなく、TCO(Total Cost of Ownership:総保有コスト)で考えます。
ROIを確認するときも、「問い合わせ業務を何時間削減できるか」「利用者が実際に使うか」「人による回答確認がどの程度残るか」など、現状業務との比較が必要です。
7. 運用・出口:導入後と契約終了後まで確認する
AIシステムは導入して終わりではありません。
- 社内文書を誰が更新するのか
- 回答品質を誰が定期的に確認するのか
- AIモデルやAPIの仕様変更へ誰が対応するのか
- 利用者からの問い合わせを誰が受けるのか
- 障害発生時の対応範囲はどこまでか
を確認します。
さらに、ベンダー変更や契約終了時についても、データや設定を取り出せるのか、別サービスへ移行できるのか、契約終了後にデータが削除されるのかを確認しておくと、将来の選択肢を残しやすくなります。
発注・PoC・要件縮小・見送りを比較する
7つの観点を確認した結果、そのまま500万円の提案を発注することだけが選択肢ではありません。
AIを使う理由
必要機能と対象範囲
方式と代替手段
品質・セキュリティ
TCOとROI
導入後・契約終了後
例えば、社内文書検索だけをまず検証したいのであれば、全社展開を前提とした個別開発ではなく、限定した部署・文書で小規模に試す方法もあります。
反対に、権限制御や基幹システム連携が業務上不可欠であれば、それらを削ることは適切ではありません。
重要なのは「安くすること」ではなく、必要なものへ費用を配分し、不要なものへ費用をかけないことです。
ベンダーへそのまま聞ける確認質問
提案内容に不明点がある場合、例えば次の3点から確認すると整理しやすくなります。
「なぜこの機能が必要ですか?」
「この機能を外した場合、何ができなくなりますか?」
「既存のサービスで代替できない理由は何ですか?」
さらに、AI固有の部分については次のような質問も有効です。
- AIの回答品質をどの質問・指標で評価しましたか
- 回答できない質問の場合、どのような挙動になりますか
- 参照した文書・根拠を利用者が確認できますか
- 入力したデータはモデル学習へ利用されますか
- 外部AIサービスへ送信される情報は何ですか
- モデルやAPIの仕様変更時には誰が対応しますか
- PoC後に本番化する場合、追加で必要な費用は何ですか
- 契約終了時に自社データを取り出せますか
回答そのものだけでなく、提案書の前提条件が明確になることに意味があります。
AIベンダー提案の発注前チェックリスト
| 確認領域 | 確認する内容 |
|---|---|
| 課題 | AIで解決したい業務上の問題が明確か |
| 対象者 | 誰が、どの程度利用するか決まっているか |
| 要件 | 各機能が必要な理由を説明できるか |
| データ | 利用する文書・データと更新方法が明確か |
| 技術方式 | AI・RAG・個別開発を採用する理由があるか |
| 代替手段 | 既存SaaSや業務改善と比較したか |
| 評価 | テストデータ・指標・成功条件が明確か |
| 誤回答 | 回答不能・誤回答時の扱いを決めているか |
| 人の確認 | 人が確認・承認する範囲が明確か |
| 情報管理 | 入力・保存・外部送信・学習利用を確認したか |
| 初期費用 | 要件定義から本番移行までの範囲が明確か |
| 継続費用 | API、クラウド、保守、更新、改修を確認したか |
| 発注者側作業 | データ整理・評価・運用等の自社工数を確認したか |
| 保守 | 障害・仕様変更・品質低下への対応範囲が明確か |
| 出口 | データ移行・解約・ベンダー変更の条件を確認したか |
まとめ
AIベンダーから500万円の提案を受けたとしても、金額だけで「高い」「安い」と判断することは困難です。
まず確認したいのは、次の7点です。
- 目的・課題:何を改善するためのAIなのか
- 要件:本当に必要な機能は何か
- 技術方式:なぜその方式・個別開発が必要なのか
- 評価方法:何をもって使えると判断するのか
- セキュリティ・リスク:データとAIのリスクをどう管理するのか
- 費用・ROI:初期費用と継続費用に見合うか
- 運用・出口:導入後と契約終了後をどうするのか
これらを整理すると、「そのまま発注する」以外にも、要件を小さくする、PoCから始める、既存SaaSを使う、データ整備を先に行う、今回は見送る、といった選択肢を比較しやすくなります。
SCI総合研究所株式会社のKAMUSHIRUBEでは、AI・DX・IT等のベンダー提案や技術資料について、導入・契約前の段階から論点整理を行っています。
提案内容の要件、技術方式、費用対効果、運用上の懸念等を整理し、次にベンダーへ確認すべき事項や発注判断に必要な情報を明確にします。「AIの提案を受けたが、本当に必要か分からない」「見積もりの前提を技術的に確認できる人材が社内にいない」といった段階からご相談いただけます。
参考文献
- 総務省・経済産業省. 2026. AI事業者ガイドライン 第1.2版.
- 経済産業省. 2025. AIの利用・開発に関する契約チェックリスト.
- Tabassi, E. 2023. Artificial Intelligence Risk Management Framework (AI RMF 1.0). National Institute of Standards and Technology. NIST AI 100-1. DOI: 10.6028/NIST.AI.100-1.
- Autio, C. et al. 2024. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. National Institute of Standards and Technology. NIST AI 600-1. DOI: 10.6028/NIST.AI.600-1.