AI導入の費用を1つの金額で捉えようとすると、見積もりとのズレが発生しやすくなります。実際には性質の違う4種類の費用が積み上がっているためです。

稟議で問題になりやすいのは、最初の3つだけを積み上げて予算を組んでしまうことです。4番目の運用費は継続的に発生するため、初年度の予算には収まっても、翌年度以降に「これは何の費用か」という話になります。

段階を飛ばすと、かえって高くつく

費用を抑えたいという理由で、構想とPoCを省いて開発から入る判断をすることがあります。ただしこれは、多くの場合で総額を押し上げます。

対象業務の選定を誤ったまま開発すると、動くけれど使われないシステムができあがります。この場合、手戻りが発生し、追加コストにつながる可能性があるだけでなく、次の検討をゼロから始めることになります。構想フェーズの費用は、この失敗を避けるための保険と考えると判断しやすくなります。

逆に、対象業務が明確で、似た事例が世の中に多くある案件では、PoCを省いて開発に進む判断が合理的なこともあります。省けるかどうかは、不確実性がどこにあるかで決まります。

見積書に載らない5つ目の費用

4段階のほかに、社内で発生する費用があります。見積書には出てこないため予算化されませんが、実際には相応の時間を消費します。

• 業務を説明し、資料を用意する時間（構想フェーズ）
• 検証結果を評価し、社内の合意を取る時間（PoCフェーズ）
• 受け入れテストと、現場への説明の時間（開発フェーズ）
• 使い方の問い合わせ対応と、運用ルールの調整（運用フェーズ）

「丸投げできますか」と聞かれることがありますが、完全に任せることは難しく、業務を理解している担当者の協力が必要です。どの段階でも、業務を知っている人の関与が必要になります。稟議を書く際は、外部への支払額だけでなく、社内で何人が何時間関わるかも見ておいてください。ここを想定していないと、繁忙期と重なって計画が止まります。

一般的なAI導入案件では、以下のような費用感になるケースがあります。いずれも幅が広く、自社の条件によって大きく動く点にご注意ください。

業務別に見るとイメージしやすい

導入の形で分けても実感が湧きにくい場合、業務から見たほうが判断しやすくなります。

この表で伝えたいのは金額そのものより、やりたいことの大半は上から2〜3行目に収まるという点です。最初から一番下の行を検討している場合は、その前に上の行で代替できないかを確認する価値があります。

「PoC 100万円」と「PoC 10万円」は別のものを指している

相場を調べていると、同じ「PoC」という言葉に対して、10万円台の記載と500万円の記載の両方が見つかります。これはどちらかが間違っているのではなく、指しているものが違うためです。

• 数十万円規模のPoC — 既製ツールやノーコードで数日〜2週間、動くものを作って感触を確かめる
• 数百万円規模のPoC — 自社データを使い、精度を数値で測り、本開発に進めるかを判断する

見積もりを比較するとき、この違いを揃えずに金額だけを並べると判断を誤ります。相見積もりを取る際は、「PoCで何をどこまで確かめるのか」を先に自社で定義し、同じ条件で各社に提示してください。そうしないと、安い会社が安いのではなく、やることが少ないだけという結果になります。

なお上の表は、あくまで公開情報を集計した参考値です。実際の見積もりは業務内容を伺ってから算出しています。表の数字は「桁を掴む」ために使い、判断材料にはしないでください。

AI導入の費用で最も大きな分岐がここです。既製ツールを使うか、自社向けに作るか。この判断ひとつで、費用が1桁変わります。

まず問うべきは「既製ツールで足りないか」

結論から言えば、多くの業務は既製ツールで足ります。問い合わせ対応、議事録の作成、文書の要約、社内文書の検索。こうした汎用的な業務には、すでに完成度の高いツールが揃っています。

それでも開発が必要になるのは、次のような条件が重なったときです。

• 既存の基幹システムと双方向でデータをやり取りする必要がある
• 自社固有の判断ルールが複雑で、ツールの設定では表現しきれない
• 扱うデータの機密性が高く、外部サービスに置けない
• 業務量が大きく、従量課金だと既製ツールのほうが割高になる

1つも当てはまらないなら、開発を検討する前に既製ツールを試す価値があります。「AI導入＝独自開発」と考える必要はありません。

逆に、ツール導入型で見落とされる費用

一方で、ツール導入型が常に安いとも限りません。月額費用そのものは小さくても、次の費用が別に発生します。

既存データの移行と整形、社内向けの利用ルールの整備、教育、そして業務手順の変更。特に業務手順の変更は、費用として見積書に載らないぶん見落とされますが、現場の時間を最も消費する部分です。ツール代が月2万円でも、現場が慣れるまでの数ヶ月は生産性が落ちます。

実務で多いのは、その中間

ツール導入型か開発型かの二択で語られがちですが、実際に選ばれることが多いのは中間の形です。既製ツールを土台にして、足りない部分だけを開発してつなぐ組み方です。

たとえば、社内文書の検索は既製のAIツールに任せ、その回答を基幹システムの顧客情報と突き合わせる部分だけを作る。あるいは、既製のチャットボットを入れたうえで、問い合わせ内容を自社の管理台帳へ自動で記録する連携部分だけを開発する。

この形の利点は、費用のかかる部分を最小化しながら、業務への適合度を確保できることです。全体を作るより安く、既製ツールだけよりも自社の業務に合います。費用感としては、既製ツールの月額に、連携開発として数十万〜200万円程度が乗るイメージです。

見積もりを取るときは、「全部作る」前提だけでなく、この中間案でも出してもらうと比較材料が増えます。提案が開発一択で返ってくる場合、その理由を聞いてみてください。

比較すべきは「ツール代と開発費」ではなく「総保有コスト」です。3年間でどちらがいくらになるかを並べると、判断が変わることがあります。

AI導入では、初期費用よりも運用費のほうが判断を左右することがあります。特に生成AIを使う場合、API型の生成AIサービスでは、利用量に応じて費用が増える場合があるためです。

継続的に発生する4つの費用

このうち想定を外しやすいのがAPI利用料です。従量課金は、社内に浸透するほど増えます。導入初期の1ヶ月の実績で年間予算を立てると、利用が広がった後に足りなくなります。

従量課金が増える要因は、利用回数だけではありません。1回あたりに読み込ませる文書量も効きます。社内マニュアル全体を毎回参照させる設計と、必要な章だけを絞り込んでから渡す設計では、同じ質問でも費用が変わります。

つまり運用費は、作り方でかなり下げられるということです。見積もりの段階で「利用量が増えたときに費用がどう伸びるか」「それを抑える設計になっているか」を確認しておくと、稼働後の想定外を減らせます。開発費を安く抑えた結果、運用費が高い設計になっていた、というのは避けたいところです。

試算は「複数のシナリオ」で行う

クラウドサービスの料金は利用規模と構成で大きく変わるため、1つの前提だけで試算すると外れます。少なくとも次の3パターンを出しておくと、予算の議論がしやすくなります。

• 想定どおり — 計画した部署・人数で使われた場合
• 浸透した場合 — 利用が全社に広がった場合（想定の3〜5倍で見る）
• 使われなかった場合 — 最低限の固定費だけが残る場合

3つ目を出しておく意味は、撤退ラインを決められることにあります。利用が伸びないときに、いくらまでなら維持して様子を見るのか。これを先に決めておかないと、使われていないシステムの費用を払い続けることになります。

データの更新を誰がやるか

見積書に載らないうえ、最も忘れられるのがこれです。社内文書を読ませるAIは、元の文書が古くなれば回答も古くなります。就業規則が変わったとき、商品情報が更新されたとき、誰がAI側に反映するのか。

この担当と頻度が決まっていないと、半年後には「AIの回答が信用できない」という理由で使われなくなります。運用費とは、サーバー代のことではなく、この作業を担う人の時間のことです。

1. 対象を1業務に絞る

最も効果が大きいのがこれです。複数部署にまたがる仕組みを最初から作ろうとすると、要件の調整だけで数ヶ月かかります。1業務に絞れば、要件が固まり、開発範囲が縮み、判断も早くなります。

絞り方の目安は、処理量が多く、判断基準が言語化でき、間違えても取り返しがつく業務です。この条件に合う業務から始めると、成果が出るまでの期間も短くなります。

2. 段階を分けて発注する

構想から運用までを一括で発注すると、途中で前提が変わったときの手戻りが大きくなります。段階ごとに区切り、その都度「進む・止める」を判断できる契約にしておくと、無駄になる範囲を限定できます。

特にPoCと本開発の間には、必ず判断のタイミングを挟んでください。PoCの成果には「やらないという判断」も含まれます。止められない契約になっていると、この選択肢が消えます。

3. 発注前に、自社の情報を整理しておく

見落とされがちですが、これが見積もりに最も効きます。対象業務の手順、扱うデータの所在と形式、既存システムの仕様。これらが整理されているかどうかで、見積もりの金額そのものが変わります。

理由は単純で、情報が揃っていない部分は、見積もる側がリスクとして金額に上乗せせざるを得ないからです。「データがどこにどれだけあるか分からない」という状態で正確な見積もりは出せないため、多めに見るしかありません。

当社自身、開発の現場でこれを実感しています。ある会員制アプリの開発案件で、複数のエンジニアが入れ替わりながら1年以上進める体制を取っていた時期がありました。途中から、打ち合わせで決めたことを必ずドキュメントへ反映し、仕様書を正として作業する運用に切り替えたところ、仕様の確認にかかる往復と、修正依頼の洗い出しの手間が明確に減りました。新しく参加したメンバーが、人に聞かずに経緯まで追える状態になったためです。

これは開発側の話ですが、構造は発注側でも同じです。判断の経緯と業務の実態が資料として残っていれば、見積もりの精度が上がり、確認のやり取りも減ります。発注前の1〜2週間を情報整理に使うことは、値引き交渉より確実に効きます。

なお、この取り組みについて当社では前後の工数を計測しておらず、削減率として示せる数字がありません。現場の手応えとしての話です。数字で語れないことは反省点で、現在は計測を始めています。

中小企業であれば、国の補助金でAI導入の自己負担を下げられる可能性があります。2026年度に検討対象となるのは主に3制度です。

2026年度は、3制度のうち2つが名称変更または統合されています。古い制度名で情報を集めると、締切や要件が食い違うため注意してください。

費用の観点から押さえておきたいのは、次の3点です。

• 補助金は後払い — 交付決定後に自社で全額支払い、実績報告を経てから入金されます。一時的に全額の資金が必要です
• 交付決定前の発注は対象外 — 先に契約すると補助を受けられません。ベンダーとの最初の打ち合わせで意向を伝えてください
• 導入時期を選べなくなる — 締切と交付決定のスケジュールに、導入時期を合わせることになります

そのため「補助金が使えるなら導入する」という判断は、実はおすすめしません。補助金なしでも投資対効果が成立する計画を立てたうえで、使えるなら使うという順序のほうが、結果的にうまくいきます。3か月後に稼働させたい事情があるなら、補助金を待つ間の機会損失のほうが大きいこともあります。

各制度の対象範囲、申請スケジュール、見落としやすい対象外の条件は別の記事で詳しく整理しています。

複数社から見積もりを取ったとき、金額だけでは比較できません。以下は、見積書を受け取ったときに確認する項目です。そのまま社内の検討資料に転記して使ってください。

見積書の中身について

• 工程ごとに金額と期間が分かれているか（「AI開発一式」の1行になっていないか）
• その見積もりに要件定義が含まれているか（別途になっていることが多い項目です）
• 既存システムとの連携が範囲に入っているか。入っていない場合、誰がやるのか
• データの整備は、どちらの作業範囲か
• 受け入れテストで自社が担う作業と、必要な工数の目安

運用開始後について

• 保守費の金額と、その範囲（障害対応のみか、改善も含むか）
• API利用料の試算根拠と、想定を超えた場合の扱い
• データ更新の担当と頻度
• 運用を自社に引き取りたい場合の移行の想定

前提の確認

• PoCで「何をどこまで確かめるのか」が明記されているか
• PoC後に本開発へ進む場合、同じ会社・同じチームが担当するか
• 精度の目標値について、約束の有無と、達成できなかった場合の扱い

金額の差が大きい見積もりが並んだときは、多くの場合作業量ではなく責任範囲の差です。安い見積もりを選んだ結果、データ整備と運用が全部自社に残った、という話は珍しくありません。上のリストは、その差を可視化するために使ってください。

相見積もりを取るときの進め方

複数社に声をかける場合、各社に自由に提案してもらうと、範囲も前提もバラバラの見積もりが並びます。金額を比べられる状態になりません。

そこで、先に自社側で条件を揃えて提示してください。最低限、次の4点があれば比較可能な見積もりが集まります。

• 対象業務と、現在の処理量（月に何件、1件あたり何分、担当は何人か）
• 連携が必要な既存システムの名称
• PoCで確かめたいことと、その合格ライン
• 予算の桁感と、稼働させたい時期

4つ目を伝えることをためらう方が多いのですが、伝えたほうが精度の高い提案が返ってきます。桁が分かれば、その範囲で何ができるかという提案になるためです。伏せたまま進めると、各社が想定で組んだ見積もりが並び、比較の手間だけが増えます。

自社の業務内容を伺えれば、どの段階からいくらかかるか、既製ツールで足りるかどうかも含めて概算をお出しします。