AIシステム開発の費用｜初期・運用の内訳と再見積もり条件
AIシステム開発の費用を、データ準備、モデル・API利用、評価、ガードレール、人手確認、監視・運用に分けて解説。品質要件が変わったときの再見積もり条件も、発注者向けの例で整理します。
執筆・確認株式会社adding 編集部
cost / ai-dev
AIシステム開発の費用は、画面数やAPI連携数だけでは決まりません。通常のシステム開発費に加えて、データ準備、モデル・API利用、評価、ガードレール、人手確認、監視・運用を分け、算定条件を見積書に残します。
AIの品質は、一つの「精度」で固定できません。誰が、どの場面で出力を使うのか。誤りが起きたときに止められるのか。人が確認するのか。この条件が変われば、実装済みでも評価や運用を再設計します。
一般的な費用の変動要因は「システム開発の費用相場」を参照してください。ここでは、AI機能をシステムへ組み込む追加費用に絞ります。
AIシステム開発では試作の後にも費用が残る
生成AIのAPIを呼び出し、回答を画面に表示するだけなら、試作は早く作れることがあります。しかし「一度動いた」と「業務で継続利用できる」は同じではありません。入力データが変わり、利用者の質問が広がり、外部モデルも更新されるからです。
経済産業省のAI事業者ガイドライン（第1.2版）別添5「AI利用者向け」は、利用前の基本動作確認とログ管理体制の整備、利用中の定期確認、必要に応じた更新・点検を具体的な手法に挙げています。出力によって重大な影響や被害が生じ得る場合には、人間の判断を介在させる考え方も示しています。
NISTの「AI Risk Management Framework」は任意利用の枠組みで、AIのリスク管理をGovern、Map、Measure、Manageの四つの機能で整理しています。AI RMF Coreは、導入前のテスト、運用中の定期評価と挙動監視を示しています。なお、2026年8月12日時点でAI RMF 1.0は改訂作業中です。
これらは開発料金を定める資料ではありません。見積もりへ置き換えると、試作費だけでなく、評価方法、人の役割、ログ、監視、変更時の再評価にも作業があると分かります。
AIシステム開発の追加費用を六項目に分ける
AI機能の費用を分けると、抜けを見つけやすくなります。
初期費用 = 通常のシステム開発 + データ準備 + モデル・API組み込み + 評価 + ガードレール + 人手確認の導線 + 監視設計
運用費 = モデル・API利用 + データ更新 + 継続評価 + 人手確認 + 監視・障害対応 + 変更後の再評価
同じ作業名でも、対象範囲は案件ごとに異なります。発注時は「一式」とせず、少なくとも以下の内訳を確認します。
| 費用項目 | 初期に行うこと | 運用中に続くこと | 費用が変わる主な条件 |
|---|---|---|---|
| データ準備 | 利用可否の確認、収集、重複や形式の整理、権限設計 | 追加・削除・更新、品質確認、権限の見直し | データ源、形式、更新頻度、機密性 |
| モデル・API利用 | 候補比較、接続、プロンプトや検索方式の設計、試験利用 | リクエスト、保存領域、通信、必要に応じたモデル切替 | 入出力量、利用回数、応答時間、提供条件 |
| 評価 | 利用場面別のテストデータ、判定基準、受入条件の作成 | 回帰評価、利用実績を踏まえたテスト追加 | 対象業務、許容できない誤り、品質基準 |
| ガードレール | 入力制限、権限確認、出力検査、回答保留や代替手順 | 禁止条件の更新、回避例への対応 | 扱う情報、出力後の処理、影響の大きさ |
| 人手確認 | 確認画面、承認・差し戻し、責任分担の設計 | 確認作業、教育、判断記録、例外対応 | 全件確認か一部確認か、必要な専門性 |
| 監視・運用 | ログ、通知、停止・復旧、問い合わせ手順の設計 | 品質・障害の監視、調査、再発防止、定期報告 | 監視頻度、対応時間、保存期間、利用者数 |
外部サービスの単価は、提供会社、モデル、入力・出力の量、契約条件で変わります。そのため、開発会社の作業費と外部利用料を分け、利用量の仮定、超過時の通知、料金改定時の扱いまで記載してもらいます。
条件付き見積もり例：社内文書から回答案を作るAI機能
以下は見積書の作り方を示す仮定例で、金額相場ではありません。社内規程を検索し、担当者へ回答案と参照箇所を表示するAI機能を想定します。社内担当者だけが使い、回答案は全件を人が確認します。承認済み文書だけを参照し、根拠を示せない場合は回答を保留する条件です。
この段階の見積もりは、次の三つに分けます。
- 調査・検証：対象文書の状態を確認し、代表的な質問と判定基準を用意して、採用する方式を判断する
- 本番組み込み：権限に沿った検索、回答案、参照箇所、承認・差し戻し、ログ、回答保留を実装する
- 運用：文書更新、API利用、人手確認、品質確認、障害対応、モデルや検索方式の変更後の再評価を続ける
ここで「AI回答機能一式」と記載すると、発注後に境界が崩れます。条件付き見積もりでは、各項目へ成立条件を付けます。
| 項目 | この例で置く条件 | 条件が変わったら再見積もりする作業 |
|---|---|---|
| データ | 承認済みの社内規程、文書ごとの閲覧権限あり | 紙資料の読み取り、他部署データの追加、権限再設計 |
| モデル・API | 外部モデルを利用し、対象者と利用場面を限定 | 利用者増、長文入力、応答要件の短縮、提供会社の変更 |
| 評価 | 業務担当者が質問例と正答根拠を確認 | 対象業務の追加、受入基準の厳格化、評価担当の追加 |
| ガードレール | 根拠を表示できない回答は保留し、外部処理を自動実行しない | 個人情報の入力、顧客への直接回答、他システムの自動更新 |
| 人手確認 | 担当者が全件を確認してから利用 | 抜き取り確認への変更、確認者の権限・責任の変更 |
| 監視・運用 | 利用履歴、保留、訂正、障害を記録して定期確認 | 即時対応、保存期間の延長、監視指標や報告先の追加 |
この例なら、最初の調査・検証でデータと評価条件の不確実性を減らし、その結果から本番組み込みを見積もれます。API利用量が未確定なら、仮定した利用者数や利用頻度を明記し、実績が仮定から外れた時点で運用予算を更新します。見積額を最初から一つに固定するより、何が決まれば次の金額を確定できるかが明確です。
品質要件が変わると再見積もりの範囲も変わる
「もっと精度を上げたい」だけでは、再見積もりできません。増やしたい正答と、減らしたい誤りを利用場面に結び付けます。回答案の言い回しを整えるのか、参照漏れを減らすのか、根拠のない回答を保留させるのかで、手を入れる場所が違います。
たとえば、前節の条件を「社内担当者向けの下書き・全件確認」から「顧客へ直接表示・一部だけ確認」へ変えるとします。これは画面文言の変更ではありません。評価データを顧客の利用場面へ広げ、回答保留や相談先への切替を再設計し、問題を検知する監視と停止手順を強める必要があります。人手確認を減らす一方で、評価、ガードレール、監視の作業は増え得ます。
再見積もりの起点にする変更は、次のとおりです。
- 出力の用途が、下書きから最終回答や自動処理へ変わる
- 利用者、対象部署、データ源、権限が増える
- 人手確認の範囲や、問題発生時の責任者が変わる
- 受入条件、許容できない誤り、監視・対応時間が変わる
- モデル、提供会社、検索方式、主要なプロンプトを変更する
モデルを変えず、データ追加だけで済むとは限りません。品質基準を厳しくすれば、評価例の追加、データ整備、検索・出力制御の調整、回帰評価が必要になります。逆に、用途を限定して必ず人が確認するなら、初回に作る範囲を抑えられる場合があります。品質と費用の関係は一方向ではありません。
発注前に決めるのは精度の数字より利用条件
見積もりを依頼する前に、発注側と開発会社で四つの問いへ答えます。
- AI出力は誰が、何の判断や作業に使うのか
- どの誤りを許容できず、保留・訂正・停止をどう行うのか
- 評価データと正答根拠を誰が用意し、誰が合否を決めるのか
- 公開後に、誰がログを確認し、変更と事故へ対応するのか
答えられない項目は、無理に本番開発の固定額へ含めません。調査・検証の範囲、成果物、判断期限を切り出し、評価結果を見て本番範囲を確定します。通常の工程、前提、対象外、変更手続きの確認方法は「システム開発の見積もりの取り方と内訳」も参照してください。
AIシステム開発の費用を判断する基準は、相場への近さだけではありません。初期と運用を分け、六つの費用項目へ条件を付け、品質要件が変わったときに再計算する場所が分かること。それが、試作後の追加費用を見えやすくし、予算内で用途を絞るための見積もりになります。
参考資料
- 経済産業省「AI事業者ガイドライン（第1.2版）別添」（2026年8月12日確認）
- NIST「AI Risk Management Framework」（2026年8月12日確認）
株式会社adding 編集部
費用、期間、契約、法務・税務上の扱いは条件により異なります。記事の確認日とリンク先の一次情報を確認し、個別判断は専門家へご相談ください。
システム開発・発注ガイドへ戻る