生成AI PoC・受託開発の費用相場｜50万円〜の検証から本番開発まで

「生成AIの開発には、どのくらいの費用がかかりますか？」という質問をよく受けます。

数百万円で収まるのか、1,000万円を超えるのかが分からなければ、社内で検討を進めるのも難しいでしょう。

先に目安を示すと、Beekleでこれまで対応してきた案件では、小規模な実証実験で50〜300万円程度、実際に操作できる試作品の開発で200〜600万円程度、本番運用まで進める場合は500〜1,500万円以上になることがあります。

これは一般的な相場を調査して算出した数字ではなく、Beekleが過去に対応した案件の規模や進め方をもとにした目安です。

実際の費用は、対象となる業務、データの量や形式、既存システムとの連携、求める精度、運用体制などによって変わります。

また、生成AIを使う案件では、開発を始める前には判断しにくいこともあります。

そのため、最初から総額だけを固定するのではなく、実現方法が明確な部分と、検証しなければ判断できない部分を分けて考えることが重要です。

まず、生成AI開発の費用相場はどのくらいなのか

Beekleで過去に対応した案件をもとにすると、大まかな目安は次のとおりです。

この金額は、開発段階ごとの一般的な価格を示すものではありません。Beekleが過去に対応した案件をもとにした参考値です。

例えば、同じ「社内資料をAIで検索したい」という相談でも、資料が100件なのか10万件なのかによって、必要な作業は変わります。

既存システムとの連携が必要か、部署ごとに閲覧権限を分けるか、回答の根拠を表示するか、回答精度をどの程度求めるかによっても費用は変動します。

さらに、資料の形式や状態も影響します。テキスト化された資料が中心なのか、画像やスキャンデータが多いのか、資料の重複や古い情報を整理する必要があるのかによって、前処理や検証に必要な作業が変わります。

そのため、この表だけを見て「自社の場合は300万円」と判断することはできません。

初期検討では、金額の目安とあわせて、どの条件が費用に影響するのかを確認する必要があります。

費用を左右する主な条件

生成AI開発の費用は、機能数だけで決まるわけではありません。

特に確認しておきたいのは、次のような条件です。

• 対象となる業務の範囲
• 利用するデータの量、形式、品質
• 既存システムとの連携の有無
• 利用者や部署ごとの権限管理
• 求める回答精度や処理精度
• 誤りが発生した場合の確認フロー
• 利用状況や回答内容を記録する必要性
• 本番運用後の監視、保守、改善の方法

例えば、社内資料を検索する仕組みでも、単に回答を表示するだけなのか、参照元の資料や該当箇所まで表示するのかによって必要な設計は変わります。

また、全社員が同じ資料を検索するのか、部署ごとに閲覧できる資料を分けるのかによって、権限管理の設計も変わります。

費用を確認するときは、機能の一覧だけでなく、どのようなデータを使い、誰が、どの業務で、どの程度の頻度で利用するのかまで整理することが大切です。

費用を決めるのは、機能数だけでなく「まだ分からないこと」です

一般的なシステム開発では、画面数、必要な機能、接続するシステムなどを確認することで、ある程度の工数を見積もれます。

生成AI開発でも、この考え方は基本的に同じです。

ただし、機能の一覧だけでは、必要な作業量を判断しにくい場合があります。

例えば、帳票を読み取り、内容を自動入力する仕組みを開発するとします。

入力画面や確認画面を作成すること、データを保存する仕組みを構築することは、比較的明確に設計できます。

一方で、実際に利用される何十種類もの帳票を正確に読み取れるかどうかは、実データを使って検証しなければ判断できないことがあります。

手書きの文字が含まれる場合はどうか。会社ごとにレイアウトが異なる場合はどうか。似た数字を誤認識しないか。例外的な帳票がどの程度あるのか。

このような点が、開発上の不確実性になります。

そのため、生成AI開発では「何を作るのか」だけでなく、「何がまだ分かっていないのか」によって費用が変わります。

不確実性の高い部分を残したまま、「すべて含めて500万円」と先に固定すると、開発途中で追加の検証や設計変更が必要になり、当初の計画と実際の作業に差が生じる可能性があります。

確実な部分と、検証が必要な部分を分ける

分からないことが多い案件では、すべてを調査してから開発を始める方法も考えられます。

一方で、実現方法が明確な部分まで検証段階にとどめる必要があるとは限りません。

Beekleでは、商談で概要を伺ったうえで、実際の資料や業務内容を確認した方がよいと判断した場合は、秘密保持契約を締結します。

その後、実際の資料や業務情報を確認し、PM on Railsという自社の仕組みを使って、実現したいことや利用者、具体的な業務フローを整理します。

ここまで整理できれば、実現方法が明確な部分については、比較的早い段階でデモを作成できます。

作成したデモは、お客様にも実際に操作していただきます。

すると、

• 「想定していたものと異なる」
• 「この情報も必要になる」
• 「実際の業務では、この順番では使わない」

といった意見が出てくることがあります。

Beekleの案件でも、実際に操作していただくことで、当初の想定と実際の業務との違いが明らかになる場合があります。

このような認識の違いを早い段階で確認できれば、後から大きな設計変更が発生する可能性を抑えられます。

文章だけで要件を詰める場合と比べて、実際に操作できるものを見ながら確認する方が、利用イメージや追加条件を共有しやすいケースもあります。

確実な部分を先に形にすることで、検証が必要な部分も整理しやすくなります。

本当に分からない部分だけを、小さく検証する

例えば、社内資料をもとに質問へ回答する仕組みを開発する場合、質問画面を作成できるかどうかを検証する必要はありません。

画面の作成自体は、要件が明確であれば設計できます。

確認すべきなのは、実際の資料を登録したときに必要な情報を検索できるか、誤った回答をしないか、回答の根拠となる資料を正しく提示できるかといった点です。

Beekleでは、こうした案件でシステム全体を実証実験にするのではなく、実際の資料を使って回答精度や根拠の提示を確認することがあります。

生成AIを利用する案件だからといって、すべての機能を実証実験として扱う必要はありません。

実現方法が明確な部分はデモや試作品として進め、残った不確実性だけを検証することで、初期段階で必要な費用を抑えられる場合があります。

反対に、「AIを使う案件なので、まず300万円で実証実験を実施する」と最初から金額だけを決める方法には注意が必要です。

重要なのは、検証費用を使って何を確認するのか、どのデータを使うのか、どの結果で次の判断をするのかを明確にすることです。

小規模な実証実験では、「何が分かれば終了か」を決めておく

小規模な実証実験で避けたいのは、システムが動作したものの、実用性を判断できない状態です。

生成AIが回答した。

帳票を読み取れた。

システムとしては動作している。

しかし、それが業務で利用できる水準なのかは分からない。

この状態では、次の投資判断につなげにくくなります。

Beekleの案件でも、単に動作することと、業務で使えることは別に確認する必要があります。

そのため、検証を始める前に評価方法を決めておくことが重要です。

例えば、100件中90件を正しく処理できれば成功とするのか。残り10件では、どのような誤りが許容されるのか。金額だけは絶対に間違えてはいけないのか。誤りが発生した場合に担当者へ確認を回せれば、業務上は問題ないのか。

同じ「正解率90％」でも、業務への影響は大きく異なります。

そこで、実際の業務に近い質問や資料を集め、正しい結果もあわせて用意します。

これは、生成AIに繰り返し解かせる正解付きの問題集のようなものです。

Beekleでも、改善前と改善後を比較するために、評価用の質問や正解データを用意して検証することがあります。

評価用データがあれば、改善前と改善後を同じ条件で比較できます。

例えば、評価結果が70点から80点に向上した一方で、特定の種類の質問だけは悪化したとします。

このような状況まで把握できれば、次に改善すべき箇所を判断しやすくなります。

実証実験を依頼する場合は、評価用データの作成が含まれているか、評価基準が事前に定められているかを確認するとよいでしょう。

デモを作る費用と、実務で使える状態まで改善する費用は別です

生成AIの進歩により、最初に動作するものを作るまでの時間は短くなりました。

ただし、実際の業務で利用できる状態まで改善するには、別途時間と費用が必要になる場合があります。

例えば、実際のデータを増やしたことで、特定の質問だけ回答精度が低下することがあります。

特定の帳票だけ読み取れないこともあります。

回答自体は正しいものの、参照している資料が適切でない場合もあります。

Beekleでも、実際のデータを使った段階で、想定していなかった形式や例外的なケースが見つかることがあります。

このような問題は、開発の過程で発生する可能性があります。

そのため、一度動作したものを、そのまま本番運用できる状態とみなすことはできません。

評価する。

失敗した箇所を確認する。

改善する。

再度評価する。

このサイクルを繰り返します。

実証実験の後に、改善作業が長期化する案件もあります。

生成AIの技術や活用方法は現在も発展途上であり、改善に必要な作業量を初期段階ですべて正確に予測することは困難です。

初期のデモや検証にかかる費用だけを見て、全体の費用を判断すると、後から追加の予算が必要になる可能性があります。

見積もりを確認する際は、初期開発の費用だけでなく、本番化に必要な作業や、運用開始後の改善費用が含まれているかも確認してください。

改善段階では、契約方法によって費用の考え方が変わる

改善段階では、評価結果によって次に取り組むべき内容が変わります。

AIへの指示を変更すれば解決できる場合もあります。

検索方法の見直しが必要になる場合もあります。

元となる資料の整理方法を変更した方がよい場合もあります。

場合によっては、システムではなく業務フローそのものを見直す必要があります。

これらを初期段階ですべて予測し、「この作業をこの金額で完了させる」と固定することは容易ではありません。

そのためBeekleでは、ある程度形にして評価できる状態を作った後、一定期間にわたって共同で改善を進める準委任契約が適している案件もあると考えています。

準委任契約とは、完成品の仕様や作業内容を最初からすべて固定するのではなく、一定期間、チームとして開発や改善を継続する契約です。

この契約方法を検討する場合は、作業内容が不明確なまま進めるのではなく、期間、体制、担当範囲、成果物、費用の計算方法、優先順位の決め方を事前に確認する必要があります。

Beekleでは、評価結果を確認しながら、次にどの部分へ投資するのが適切かを判断するために、この進め方を採用することがあります。

実現方法が明確な部分は、最初から範囲を定めて開発します。

不確実性の高い部分は、検証結果を確認しながら次の対応を決めます。

どの契約方法が適しているかは、要件の確定度、検証の必要性、社内の意思決定方法、予算管理の方針によって変わります。

最初から「本番までいくらかかるか」を確認する

発注側からすると、総額が分からないまま開発を始めることに不安を感じるのは当然です。

そのため、「成功した場合、本番運用までにどの程度の規模になりそうか」は、初期段階で確認しておくべきです。

ただし、そこで提示される数字は確定金額ではなく、現時点で分かっている条件にもとづく予算の幅として捉える必要があります。

例えば、初期検証が100万円で完了しても、本番化に1,000万円必要になる可能性があります。

その場合、会社としてその投資が可能かどうかを、早い段階で判断しなければなりません。

反対に、本番化まで数百万円程度で済む見込みであれば、初期検証に多額の費用をかける必要はないかもしれません。

初期段階では、次のような内容を確認するとよいでしょう。

• 現時点で分かっていないことは何か
• それが分かれば、費用の幅はどの程度まで絞れるか
• 成功した場合、本番化では何に費用がかかるか
• 本番運用に必要なセキュリティ、権限管理、監視、保守は含まれているか
• 想定外のデータや追加要件が発生した場合、費用はどのように変わるか

「すべて含めて正確にいくらかかりますか？」という質問だけではなく、費用が変動する条件を確認することが重要です。

生成AI開発の費用は、解決したい課題の価値からも考える

AI開発の費用を検討する際は、解決したい課題にどの程度の価値があるかも確認します。

毎月100時間かかっている業務を20時間に削減できるのか。

人による入力ミスや確認作業をどの程度減らせるのか。

問い合わせ対応を迅速化することで、どの程度の商談機会を維持できるのか。

このような効果を、可能な範囲で金額や時間に置き換えて考えます。

例えば、年間で数千万円規模の人件費や機会損失が発生している業務であれば、数百万円を投じて検証する意義があるかもしれません。

一方、年間の負担が数十万円程度の業務に1,000万円を投じる場合は、そこまでの開発が必要かを慎重に検討する必要があります。

既存のサービスを利用した方が適している可能性もあります。

また、削減できる時間だけでなく、品質向上、対応速度、属人化の解消、監査や記録のしやすさなど、どの効果を重視するのかによっても判断は変わります。

AIを導入すること自体を目的に予算を決めるのではなく、解決したい課題がどの程度の価値を持つのかを基準に、投資額を考えることが重要です。

見積もりを取るときは、金額以外にこの5つを確認する

生成AI開発の見積もりを比較するときは、総額だけで判断しないようにしましょう。

最低限、次の5点を確認することをおすすめします。

1. どこまでが実現方法の明確な開発範囲なのか
2. 何がまだ不確実なのか
3. その不確実性をどのように検証するのか
4. 何をもって成功と判断するのか
5. 成功後、実務で利用できる状態までにどの程度の費用を想定しているのか

加えて、次の点も確認しておくと、見積もりの比較がしやすくなります。

• 評価用データの作成が含まれているか
• 本番環境への移行作業が含まれているか
• セキュリティや権限管理の設計が含まれているか
• 運用開始後の監視、保守、改善が含まれているか
• 追加要件やデータ形式の変更があった場合の扱い

例えば、300万円と500万円の見積もりがあるとします。

300万円の見積もりに、評価用データの作成や本番化に向けた検討が含まれていなければ、単純に200万円安いとは判断できません。

初期費用が安く見える見積もりでも、後から追加費用が発生し、結果的に高額になることがあります。

Beekleでも、見積もりを作成する際は、確定している作業と、検証結果によって変わる作業を分けて考えます。

ただし、見積もりの範囲や費用の含まれ方は案件ごとに異なります。依頼する際は、金額そのものだけでなく、「何がその金額に含まれているのか」を確認することが重要です。

結局、生成AI開発にはいくら用意すればよいのか

Beekleが過去に対応した案件をもとにした初期検討の目安としては、小規模な実証実験で50〜300万円程度、試作品の開発まで含めて200〜600万円程度、本番化まで進める場合は500〜1,500万円以上になる案件があります。

ただし、実際の費用は、対象業務、データ、連携先、精度要件、セキュリティ、運用体制、改善期間などによって変わります。

そのため、相場の数字だけで予算を決めるのではなく、次の3点を整理する必要があります。

• 実現方法が明確な部分はどこか
• 実際に試さなければ分からない部分はどこか
• 何が分かれば、次の投資判断ができるのか

また、初期費用だけでなく、本番化や運用開始後に必要な費用も確認してください。

実現方法が明確な部分は早い段階で形にする。

不確実性の高い部分だけを小さく検証する。

検証結果を評価し、継続する価値がある場合は改善を進める。

Beekleでは、これまでの案件でも、確定している作業と検証が必要な作業を分けて進めることがあります。

この進め方によって、初期段階で必要以上に作り込むことを避けられる場合があります。

生成AI開発の費用は、最初にすべてを正確に見積もることが難しい領域です。

不確実性を一つずつ減らしながら、次にどの程度の費用を投じるかを判断していく必要があります。

Beekleでは、過去の案件で得た進め方をもとに、実現方法が明確な部分と、検証が必要な部分を分けてご提案しています。

相談する際は、費用の目安だけでなく、費用が変動する条件、検証の方法、成功基準、本番化や運用に必要な費用まで確認すると、自社に適した進め方を判断しやすくなります。