この記事で分かること
- AIシステムの費用・期間が会社ごとに違う理由
- 見積もりを比較するためにそろえる発注条件
- PoC、本開発、運用保守を分けて依頼する方法
- 契約前に確認したい成果物、責任範囲、追加費用の条件
AI開発の費用は、モデルの料金より業務へ組み込む作業で決まる
AIを使うためのAPIやクラウドの利用料は、開発費の一部にすぎません。実際の発注金額には、業務整理、データの収集・整形、既存システムとの連携、画面開発、権限設定、評価、教育、導入後の保守などが含まれます。AIの回答が作れるだけでは、担当者が日常業務で安全に使えるシステムにはなりません。
たとえば社内文書検索では、文書を取り込む処理、最新版の管理、権限に応じた検索、根拠の表示、回答を確認する画面、文書更新時の反映方法が必要です。ExcelやCSV分析では、ファイルの受け渡し、項目の対応、欠損値の扱い、集計ロジック、出力レポートの形式を整えます。機能が似ていても、既存データの状態と利用者の数で作業量は変わります。
見積もりを読むときは、AIモデル名や「機械学習」という言葉だけでなく、業務に必要な周辺作業が何に含まれているかを確認します。既存環境の調査が別契約なのか、PoCの成果物が本開発へ引き継げるのか、運用設計や教育が含まれるのかを、項目ごとに質問します。
費用を構成する主な項目
| 項目 | 確認する内容 | 金額が変わる要因 |
|---|---|---|
| 企画・要件整理 | 業務、対象範囲、評価条件、運用の整理 | 関係部署の数、未整理の度合い、既存資料の有無 |
| データ準備 | 収集、匿名化、整形、ラベル付け、文書登録 | 形式のばらつき、件数、正解を判断する作業量 |
| AI機能 | 検索、抽出、分類、要約、回答、予測など | 精度要件、例外処理、モデルや方式の選択 |
| 業務システム | 画面、権限、ログ、通知、既存システム連携 | 連携方式、利用者数、セキュリティ要件 |
| 検証・導入 | テスト、教育、マニュアル、移行、本番確認 | 拠点数、業務停止の可否、受入担当者の確保 |
| 運用・改善 | 監視、データ更新、精度評価、保守、追加開発 | 更新頻度、対応時間、改善の範囲、利用量 |
公開されている費用・期間の目安を、自社の条件へ置き換える
マクティズムのAI開発サービスページでは、AI業務適用診断を30万〜50万円程度・2〜4週間、AI Quick PoCを120万〜250万円程度・1〜2か月、既存システムへのAI機能追加を250万〜600万円程度・1〜4か月、AI業務システム受託開発を500万円〜・3〜6か月という目安で案内しています。これは各工程の範囲を考えるための公開目安であり、自社のデータや連携条件を入れた確定見積もりではありません。
この目安を使うときは、「自社はどの段階に近いか」を考えます。課題やデータがまだ整理できていないなら診断・要件整理、実データで効果を確かめたいならPoC、既存システムへ組み込むなら機能追加、利用者・権限・運用まで作るなら本開発というように、依頼の目的を分けます。
期間も、コーディングだけの日数ではありません。意思決定、データ提供、業務側レビュー、接続先の調整、評価、受入テストが含まれます。発注側の確認が二週間止まれば、開発会社の作業だけを早めても納期は短くなりません。見積書の期間と合わせて、発注側が行う作業と期限を確認します。
期間の見積もりに、発注側の作業を含める
開発会社の作業期間だけを合計しても、プロジェクト全体の納期にはなりません。データを提供する、業務担当者がサンプルを確認する、情報管理者が利用条件を承認する、接続先の管理者がテスト環境を用意するなど、発注側の工程があります。見積もりには、各工程の前提と、前提が遅れた場合の影響を記載してもらいます。
納期を短くしたい場合は、機能を削るだけでなく、意思決定者を固定する、評価ケースを先に作る、連携を手動にする、対象部署を限定するなどの方法があります。何を簡略化し、何を本番前に残すかを明示すれば、短納期の提案でも品質上のリスクを比較できます。
「最短で作る」提案を比較するときの注意
短い期間の提案が悪いわけではありませんが、何を省いているかを確認します。対象データを限定しているのか、権限やログを後回しにしているのか、回答の確認を人に任せているのか、運用設計を含めていないのかで意味が変わります。省略した作業が本番前に必要なら、その費用と期間を別に記録します。
「精度保証」という表現も定義を聞きます。どのデータ、どの質問、どの期間で測るのか、重大な失敗をどう扱うのかが書かれていなければ、単なるデモ評価と受入条件は比較できません。AIの出力は入力や資料の状態で変わるため、評価方法の合意が価格と同じくらい重要です。
発注前に作るべきRFPは、機能ではなく判断条件を伝える
RFPや相談資料には、背景、対象業務、現状の流れ、利用者、データ、希望する出力、既存システム、セキュリティ条件、予算・期間の制約、評価方法、運用体制を書きます。すべてが決まっていなくても、確定・仮置き・未確認を分けておけば、提案側は不足情報を質問できます。
特に、AIに任せない判断を明記します。回答案を作るまで、候補を並べるまで、要約を作るまでなど、人の承認を残す範囲です。完全自動化を前提にすると、必要な権限や安全策が大きくなり、導入後の現場負担も見えにくくなります。
RFPの内容をさらに具体化する際は、データ整備と評価の基本を参考に、正解データ、例外、データの更新、評価記録を項目へ入れます。発注会社が違っても同じ条件で提案してもらうことが、価格比較の前提です。
見積もりの比較表に入れる項目
| 比較軸 | 見るポイント |
|---|---|
| 対象範囲 | 対象部署、データ、利用者、含む機能と対象外 |
| 成果物 | 設計書、評価結果、ソース、設定、操作資料、運用手順 |
| 発注側の作業 | データ提供、レビュー、受入テスト、承認、教育担当 |
| 追加費用 | データ追加、連携変更、利用量増加、モデル変更、保守外の作業 |
| 品質・受入 | テストデータ、合格条件、重大な失敗、修正回数、再テスト |
| 運用 | 障害窓口、対応時間、データ更新、精度改善、契約終了後の扱い |
よくある失敗例から、発注条件の抜けを見つける
失敗例1：デモの印象だけで会社を決める
用意されたサンプルに対して、きれいな回答が返ることは、実業務での利用を保証しません。自社の文書、表記揺れ、権限、例外を使った検証をしないまま契約すると、本番で検索できない、根拠が表示されない、確認の方が時間がかかることがあります。発注前に、自社の代表的なケースを何件確認できるか、機密情報をどう扱うかを相談します。
失敗例2：安い初期費用だけを見て運用を後回しにする
初期構築が安くても、文書更新、ユーザー追加、障害対応、精度の再評価、API利用料が別で必要なら、年間の負担は変わります。見積もりの初期費用と、運用開始後の固定費・変動費を分けて整理します。利用量が増えたときの上限や通知も、費用管理の要件に含めます。
失敗例3：発注側の判断者が決まっていない
業務担当は忙しく、情報システムは技術だけでは業務の正解を決められません。レビューの回答が遅れ、未決定事項が積み上がると、開発会社も仮の判断で進めるしかなくなります。目的、データ、精度、運用、受入の項目ごとに責任者を置き、会議で決める範囲と持ち帰る範囲を分けます。
失敗例4：契約に成果物とデータの扱いが書かれていない
AIの設定や評価データ、プロンプト、連携プログラム、ログ、学習・検索用データが、誰の管理物か不明なままでは、会社を変更したり社内で改善したりする際に困ります。納品物、利用権、再利用の範囲、秘密情報の取り扱い、削除方法、契約終了時の引渡しを確認します。契約上のリスクは、AI開発会社の契約前チェックでも整理しています。
PoC契約と本開発契約を分けるか、最初に判断する
不確実性が大きいときは、診断やPoCで仮説を検証し、その結果をもとに本開発を発注する方法があります。PoCの成果物は、評価データ、評価結果、失敗の分類、採用した方式、残る課題、本番化の条件です。動く画面だけを成果にすると、本番見積もりに必要な情報が残りません。
一方、対象業務、データ、出力、運用が明確なら、本開発の中に限定的な検証工程を含めることもできます。契約を分けるかどうかより、次の工程へ進む条件と、進まない場合に何が残るかを明確にすることが重要です。
段階発注では、PoCから本開発へ移るときに、追加の要件確認が必要になることがあります。実データを増やす、利用者を広げる、既存システムへ連携する、監査ログを追加するなど、検証では不要だった要件を事前に候補として記録します。
発注先との打ち合わせで記録する4つの欄
打ち合わせの議事録は、会話を要約するだけでなく、判断に使える形にします。「決まったこと」「確認が必要なこと」「発注側が準備すること」「見積もりへ反映すること」の4欄を作り、担当者と期限を付けます。AI開発では、質問への回答がそのまま仕様になるとは限らないため、前提や対象外も残してください。
特に、開発会社が「可能」と答えた機能は、どのデータ、どの画面、どの精度、どの運用条件で可能なのかを確認します。実データでの検証が必要なら、サンプルをいつ渡し、誰が合格を判定するかを決めます。後で認識違いが分かったときも、記録があれば変更の影響を整理できます。
発注側の社内決裁に時間がかかるなら、その日程も工程へ入れます。予算の承認、セキュリティ審査、利用規約の確認、現場代表の選定を同時に進められるか確認し、開発会社の開始日だけを先に固定しないようにします。
契約前の最終チェックリスト
- 改善する業務、利用者、対象データ、対象外が一文で説明できる
- 精度の測定方法、重大な失敗、受入条件が決まっている
- データの正本、更新者、権限、外部サービスへの送信範囲が明確である
- 画面、連携、ログ、バックアップ、障害時の動作が見積もりに含まれている
- 成果物、ソースや設定の引渡し、契約終了時のデータ扱いが確認できる
- 発注側の作業、レビュー期限、承認者、意思決定の方法が決まっている
- 初期費用だけでなく、利用料、保守、追加開発、モデル変更の費用を見積もっている
候補会社との打ち合わせでは、良い提案だけでなく、難しい条件への回答を聞きます。実データが不足している場合、精度を約束できない場合、既存システムの仕様が不明な場合に、どんな調査と判断を提案するかを確認します。リスクを小さく見せる会社より、前提と限界を見積もりへ反映できる会社の方が、発注後の認識違いを減らせます。
発注前の準備として、候補会社へ同じ質問を渡し、回答の違いを表にします。技術の優劣だけでなく、業務理解、データの扱い、評価、引渡し、保守窓口、追加費用の説明を比較すれば、価格差の理由も見えてきます。
よくある質問
AIシステム開発は、いくら用意すればよいですか？
対象業務、データ、連携、精度、運用の条件で大きく変わります。公開目安として、診断・PoC・既存システムへの機能追加・新規開発で段階が分かれるため、まず自社がどの段階かを整理します。価格だけでなく、何が含まれ、何が別費用かを比較してください。
相見積もりでは、同じ提案が出てきません。どう比較しますか？
対象業務、入力・出力の見本、利用者、評価ケース、対象外、納期の前提を同じ資料で渡します。提案の違いは、方式の優劣だけでなく、含める調査や運用の範囲の違いかもしれません。見積項目を同じ表に転記し、差分の理由を質問します。
PoCだけを複数社に依頼してもよいですか？
比較目的なら可能ですが、機密データの共有範囲、評価条件、成果物、データ削除を統一します。PoCの価格だけを競わせると、対象範囲を狭くした提案が有利になるため、本番化に必要な材料が残るかも確認してください。
契約前に実データを渡すのが不安です。
機密性を確認し、匿名化、サンプル化、閲覧場所の制限、秘密保持契約、保存期間、削除方法を決めます。実データでなければ分からない評価もあるため、渡せる範囲と時期を段階的に合意し、架空データの結果を実データの精度と混同しないことが大切です。
価格ではなく、条件をそろえてからAIシステム会社を選ぶ
AIシステムの発注で失敗を減らすには、安い会社を探す前に、業務の対象範囲、データ、精度、成果物、責任、運用をそろえます。費用と期間の目安は、診断、PoC、機能追加、本開発のどこに該当するかを明らかにして初めて、自社の判断材料になります。
提案を比較するときは、デモの華やかさより、制約・失敗時の動作・発注側の作業・導入後の支援まで説明できるかを見ます。最初から大きな契約を結ぶのではなく、必要なら現状診断や小さなPoCから始めることで、実データと現場の反応を次の判断へつなげられます。
