Askhub
資料請求 お問い合わせ
お問い合わせ

入門

AI導入の費用相場と予算の取り方、ベンダーの選び方 〜AX推進入門 第7回〜

松本拓哉

30万円と300万円、どちらの見積もりを信じるか

請求書の処理をAIで自動化しようと、推進担当（社内でDX・AXを進める担当者）が見積もりを頼んだとします。頼んだ先は、開発・導入を請け負う外部の会社であるベンダー2社です。届いた金額は、1社が30万円、もう1社が300万円でした。同じ業務の見積もりなのに、10倍の差があります。

この記事は、AX推進入門シリーズ（全10回）の第7回です。シリーズの一覧はこちら。

AX（AIトランスフォーメーション。AIを前提に業務や組織を変えること）を進めると、どこかで「自社で作るか、外に頼むか」「どこに頼むか」「いくら払うか」を決めることになります。エンジニアなら見積もりの中身を聞けば妥当かどうか見当が付きますが、非エンジニアの推進担当には、ここが一番判断しにくい所です。

この記事では、次の順で整理します。冒頭の30万円と300万円の違いにも、途中で答えます。

  • 内製と外注のメリット・デメリット
  • 保守とセキュリティ：アップデートが追いつかないと、事故の要因になる
  • 内製か外注かより、既製のプラットフォームの上で作る
  • ベンダーの選び方
  • 予算の妥当性の見方と、相見積もり
  • 小さな検証（PoC）から入り、半期ごとに予算を広げる

内製と外注には、それぞれ良さがある

内製は自社の人で作ること、外注はベンダーに作ってもらうことです。推進担当が自分でAIを使って作る場合も、ここでは内製に入ります。

内製の良さは、外注費がかからないことと、自社の業務を一番よく分かっている人が作れることです。今はバイブコーディング（AIに自然な言葉で指示して、ソフトウェアを作ってもらうやり方）のツールがあるので、内製もある程度できるようになりました。代表的なのが、AI開発企業のAnthropicが出すClaude Codeや、OpenAIが出すCodexです。開発者を1〜2人置き、現場と協力しながら作る形は十分にありえます。

外注の良さは、人が足りないときに、ベンダーに頼んで人手を増やせることです。その分お金がかかり続けるのが、外注の弱みです。

そして外注の一番の良さは、保守をやってくれることです。保守とは、作ったシステムが動き続けるように、不具合を直したり、ソフトウェアを更新したりすることを指します。内製なら、この保守も自社で抱えることになります。

保守とセキュリティ：アップデートが追いつかないと、事故の要因になる

内製か外注かを考えるうえで、今いちばん大事な論点は保守、とくにセキュリティの更新です。2026年の夏から、特に9〜10月に、国内で大きなセキュリティ事故の公表が相次ぎました。

国家サイバー統括室は、政府のサイバーセキュリティ対策を取りまとめる組織です。同室の2026年10月26日の資料は、サイバー攻撃による情報漏えいが2026年に大幅に増えたと示しています。そのうち、Webシステム（ネット越しに使うサイトやサービスの仕組み）に関わる事案は、10月に入って急増したとしています。

報道によると、セキュリティ企業マクニカの集計では、国内のWebシステムへの侵入の公表は2026年10月6日時点で119件でした。2025年の1年間の84件を、すでに超えています。119件のうち81件（約68%）は、7月以降の公表です。

大きな要因の1つは、パッチが当たっていないこと

脆弱性はソフトウェアの弱点で、攻撃者が入り込む穴になるものです。パッチは、その弱点を直すために配られる修正プログラムです。

パッチの未適用と被害の関係が統計で見えるのは、ランサムウェアの被害です。ランサムウェアは、データを暗号化して使えなくし、元に戻す代わりに金銭を要求する攻撃です。警察庁の2026年上半期のまとめでは、被害の報告は123件で、半期として統計を取り始めてから最多でした。

被害に遭った組織に感染の経路を聞くと、50%がVPN機器（社外から社内のネットワークにつなぐための機器）からでした。また、被害に遭った組織の約6割には、当てていない修正がありました。

海外の調査でも、侵入の入り口で最も多いのは脆弱性の悪用です。米国の通信会社Verizonの2026年の調査では、データの侵害（不正に入り込まれ、データを盗まれるなどの被害）のうち、最初の侵入の31%が脆弱性の悪用でした。Google傘下のセキュリティ企業Mandiantの2026年の報告でも、侵入の32%が脆弱性を突いたもので、6年続けて最多です。

ただし、今秋の事故の主な原因がパッチの未適用だとまでは言えません。先ほどのマクニカの集計（報道）では、7月以降の81件のうち約8割は、侵入の原因が公表されていません。Webサイトごとの作りの不備のように、パッチを当てても直らない種類の弱点を突かれた例もあります。

それでも、更新が大事なことは変わりません。2026年10月には、国の機関や専門の組織がそろって、修正の速やかな適用を求めました。情報セキュリティの注意喚起を行うIPA（情報処理推進機構）は、使っているアプリやサービスの部品に、当てていないパッチがないかを確かめるよう呼びかけています。あれば、できるだけ速やかに当てるよう求めています。

同じ月には、JPCERT/CC（国内のセキュリティ事故への対応を調整する組織）も修正の適用を求めました。個人情報の扱いを監督する個人情報保護委員会も、脆弱性への早めの対応を求めています。国家サイバー統括室と警察庁も、事業者にソフトウェアの更新などへの対応を求めています。

大きな事故の例：GMOインターネットの件

2026年10月21日から、GMOインターネットは、同社のサービス「お名前.com デスクトップクラウド」への不正アクセスを公表しています。このサービスは、FX（外国為替証拠金取引）の自動売買などに使うWindowsの作業環境を、ネット越しに貸し出すものです。

同社は、一部の利用者のサーバー環境に第三者が不正なプログラムを置いたことを確かめ、全プランのサーバーを止めました。顧客の情報が外部に持ち出されたことや、攻撃者から金銭の要求と脅迫を受けていることも公表しています。報道によると、対象となりうるサーバーは26,739件にのぼります。

侵入の経路は公表されておらず、この件の原因をパッチの未適用と言うことはできません。11月2日の会見で会社が認めたのは、報道によると次の3つです。

  • 2024年にグループ会社の診断で指摘された課題への対応が、十分でなかった
  • 利便性のための初期設定（手元のパソコンのファイルを共有する機能）が、有効のままだった
  • 侵入されてから2か月以上、気付けなかった

指摘された課題に手を打つこと、設定を見直すこと、異常に気付くことは、どれも保守運用の仕事です。会社が認めた3つは、いずれもその不足にあたります。

ほかにも9月にはデジタル庁が、ネットワーク機器（VPN）の脆弱性を利用した侵入を公表しました。10月にはクラウド事業者のIDCフロンティアが、使っていたオープンソースソフトウェアの脆弱性を悪用されたと公表しています。オープンソースソフトウェアは、設計図が公開され、誰でも使えるソフトウェアです。どちらも、修正が出ていたのに当てていなかったのかどうかまでは公表されていません。

受託開発の保守にも、定期的な更新が入っているとは限らない

セキュリティのパッチは、たいていソフトウェアのバージョンアップデート（新しい版への更新）として配られます。アップデートが追いついていない、つまり保守運用ができていないと、攻撃者が入り込む穴が残り、事故の要因になります。

ここで気を付けたいのが、受託開発の保守運用の中身です。受託開発は、ベンダーが注文を受けて、その会社専用のシステムを作ることです。筆者の経験上、受託開発の保守運用でも、インフラ（システムを動かすサーバーやネットワーク）の監視や、異常を知らせるアラートの通知はしてくれます。しかし、定期的なアップデートまでやってくれる所は、それほど多くありません。IPAの2019年の調査でも、脆弱性など新たな脅威への対応を、誰が担うか文書で決めていない委託元が約8割ありました。

ベンダーに頼むなら、保守の契約に定期的なアップデートが含まれるかを確かめます。内製するなら、そのアップデートを自社で追いかけ続けることになります。

内製か外注かより、既製のプラットフォームの上で作る

ここからの内容は、インターセクト（この記事の発行元）としてのおすすめで、基本はケースバイケースです。そのうえで、今は内製か外注かで迷うより、既製のプラットフォームの上で作るのが良いと考えています。プラットフォームとは、AIの機能を提供し、その上に自社用の仕組みを作れる既製のクラウドサービスのことです。

Copilot、ChatGPT、Gemini、Claudeのような既製品は、最新の技術へ自動でアップデートされます。これらはそれぞれMicrosoft、OpenAI、Google、Anthropicが提供する生成AIのサービスです。サービスの内部で使っている部品や骨組みのプログラムも、提供者が最新にしてくれます。アップデートの遅れが事故につながる以上、セキュリティの面でもこれはとても良いことです。

「SaaSなら安全」ではない

ただし、SaaS（クラウドで提供される業務サービス）のような既製のサービスを使えば、事故に遭わないわけではありません。良さと注意点は、次の2段で考えます。

  1. 更新を、それを専門にする事業者にまとめて任せられる。そのため、自社で追いかけるより追いつきやすい
  2. ただし、任せる相手の保守・監視・情報開示の体制は確かめる

2段目が要るのは、サービスを提供する側が侵入されることもあるからです。先ほどのGMOインターネットやIDCフロンティアの件が、その例です。Verizonの調査でも、侵害のうち48%に、委託先やサービス事業者などの第三者が関わっていました。個人情報保護委員会の注意喚起も、利用するクラウドサービスから漏えいした事例を挙げ、利用規約や安全性に関する資料で確かめてサービスを選ぶよう求めています。

確かめるのは、次の3つです。

  • 保守：更新をどのくらいの頻度で行い、緊急の修正をどう当てるか
  • 監視：侵入や異常に、どうやって気付くか
  • 情報開示：事故が起きたときにどう知らせるか。セキュリティの取り組みを資料で示しているか

機能の部分だけを、会話で作れるサービスもある

最近は、インフラとセキュリティの管理をサービス提供者が受け持ち、利用者はその上で動く機能だけをバイブコーディングで作れるサービスも出てきています。AIエージェントは、AIが自分で手順を選びながら仕事を進める仕組みです。こうしたサービスでは、画面を含むAIのアプリから、その中で動くAIエージェント、それらを組み合わせた業務の全自動化までを、AIとの会話だけで作れます。

このようなサービスなら、保守運用は提供者に任せたまま、作ることは自分たちで進められます。自社で作れる内製の良さと、保守を任せられる外注の良さの、いいとこ取りができる形です。ただし、任せる相手の体制を確かめることは、ここでも変わりません。

何の上に作るかで、改善のしやすさも決まる

第3回（AI導入の進め方：7つのステップと、人とAIの分担）では、作った後の改善の進め方を扱いました。最初の2か月ほど運用しながら直し、その後は半年〜1年寝かせて（手を加えずに使って）から、その間に進んだAIの技術で直すというものです。

フルスクラッチ（既製品を使わず、一から作ること）なら、新しい技術を取り入れて仕組みを改善することを、ずっと全部自社で続けなければなりません。開発を頼んだ場合は、そのベンダーにやり続けてもらうことになります。

プラットフォームの上で作っていれば、自社が手を入れなくても、1年たつ間に提供者がAIの技術を新しくしています。寝かせた後に、その新しい技術で直せば、品質や判定の精度が上がります。

何の上に作るかを3つに分けて比べた図。フルスクラッチを自社で作る内製は、保守と更新も新しい技術の取り込みも全部自社で、作る自由は最も高い。フルスクラッチをベンダーが作る受託開発は、保守と更新が契約次第で定期的な更新まで入らないことが多く、新しい技術はベンダーに頼んで取り込み、内製に戻すにはベンダーの作りを引き継ぐ。プラットフォームの上で作る場合は、保守と更新を提供者がまとめて行い（相手の体制は確かめる）、土台が勝手に進化し、作る自由は下がるが一定あり、内製に戻しやすい。3つ目がインターセクトとしてのおすすめで、基本はケースバイケースと添えている

ベンダーは、プラットフォームを持つ所か、その上で作れる所を選ぶ

ベンダーに頼む場合、プラットフォームを持つ会社と、その上で作ってくれる会社は、同じ会社でなくてかまいません。たとえば、MicrosoftのCopilot Studioで仕組みを作ってくれる会社に頼む形です。Copilot Studioは、Copilotの上に自社用のAIエージェントを作れるサービスです。ここでの作ってくれる会社とは、業務の整理から相談に乗り（コンサルティング）、作るところまでやる会社のことです。

フルスクラッチに比べると、作る自由（柔軟性）は下がります。下がり方は製品によって違い、経験上、Copilotの場合はかなり下がります。それでも、ある程度は自由に作れます。

最終的に内製に戻すときも、戻しやすくなります。ベンダーが作った仕組みを、自社も契約して使える同じプラットフォームの上で引き継げるからです。第3回で書いた、最終的には改善を自社でできるようにする、という方向にも合います。

推進担当が自分で作る場合も、プラットフォームの上で作れば、保守を自分で抱えずに済みます。

予算の妥当性：作るだけは安く、本番品質と既存システムとの連携で上がる

作るだけのコストは、どんどん下がっています。非エンジニアでもバイブコーディングで作れるのなら、エンジニアはもっと簡単に作れます。

ただ、セキュリティなどを考えて、実際の業務で使い続けられる品質（プロダクションレベル）のものを作ろうとすると、途端にコストが上がります。誰が何を使えるかを決める、操作の記録を残す、障害が起きても業務が止まらないようにする、といった作り込みが加わるからです。

さらに、長く使い続けてきた既存の古い仕組みが絡むと、コストは急に跳ね上がります。代表的なのが、会計・販売・在庫など会社の中心の業務を支える、基幹システムとの連携です。ゼロから新しく作るより、既存の込み入ったソフトウェアと統合するほうが、圧倒的にコストがかかるのです。

冒頭の請求書の例で考えます。請求書の内容をAIに読み取らせて一覧にするだけなら、試作はすぐにできます。それを会計システムに自動で書き込むとなると、会計システムの入力の決まりを調べ、データの形を合わせる必要があります。誤って書き込んだときに、どう戻すかも決めなければなりません。

コストが上がる要因を3段に積んだ図。作るだけ（請求書を読み取って一覧にする）は、バイブコーディングで安くなった。本番品質（プロダクションレベル）を加えると、権限、操作の記録、障害への備えなどの作り込みで途端に上がる。既存システムとの連携（会計システムに書き込む）を加えると、入力の決まりを調べ、データの形を合わせ、誤ったときの戻し方を決める必要があり、跳ね上がる。棒の長さはイメージで、金額ではない

こうした費用が妥当かどうかを、非エンジニアの推進担当がぱっと判断するのは、とても難しいことです。

相見積もりは3社。上流とアダプションに払う

相見積もり（複数の会社に同じ内容で見積もりを頼み、比べること）は、やったほうがいいです。ただし、やりすぎも良くありません。3社にきちんと話を聞けば十分です。10社、20社と当たる会社もありますが、そこまでは要りません。

予算は、下げればいいわけではない

比べるときに見るのは、金額の大小より、どこまでが含まれているかです。作るコストは下げられますが、上流のコストはそこまで下げられません。上流とは、要求定義と要件定義、場合によっては設計までを指します。

要求定義は、今の業務と課題から、AIで何を実現したいかを決めることです。要件定義は、それを満たすために業務とシステムが何を満たすべきかを確定させることです。設計は、現場が使う画面や操作の流れも含めて、どう作るかを決めることです。仕上げのアダプション（新しい業務のやり方を現場に定着させること）にも、コストがかかります。中身は、マニュアル作りや利用者向けの研修などです。

冒頭の30万円と300万円の違いは、ここにあります。上流からアダプションまでやる前提の300万円と、作るだけの30万円では、10倍の差が出ます。

30万円と300万円の見積もりの違いを、どこまで含むかで比べた図。作るだけの30万円は、作る部分だけを含み、上流（要求定義・要件定義、場合により設計）とアダプション（現場への定着）を含まないので、「作りました、さようなら」になりやすい。上流からアダプションまでの300万円は、3つとも含み、最後まで責任を持つ。作るコストは下げられるが、上流とアダプションは下げにくいと添えている。金額は目安

アダプションまで責任を持たない所に作らせるのは良くありません。「作りました、さようなら」、つまり作って渡したら終わり、という進め方ができてしまうからです。作ったシステムが現場で使われなければ、効果は出ません。高くても、最後まで責任を持ってやってくれる所を選びます。

見積もりを比べるときは、次の点を確かめます。

  • 要求定義と要件定義（場合により設計）が含まれているか
  • アダプション（マニュアル作り、利用者向けの研修など）が含まれているか
  • 保守に、定期的なアップデートが含まれているか
  • プラットフォームの上で作るのか、フルスクラッチで作るのか
推進担当が3社の見積書を机に並べ、要求定義・要件定義、作る、アダプション、保守の項目ごとに、含まれているかを蛍光ペンで印を付けながら見比べている水彩の絵

まずPoCから：3か月・平均300万円・2〜3業務が目安

3社から1社を選んでも、「このベンダーで本当にいいのか」という不安は最後まで残ります。だから、必ずPoC（本格導入の前に、小さく作って効果と実現性を確かめる検証）から入ります。規模は次のとおりで、いずれも経験上の目安です。

項目

目安

期間

3か月

ベンダー側の作業量

0.5人月 × 3か月、合計1.5〜2人月ほど（人月は、1人が1か月働く作業量）

予算

200〜500万円、平均300万円くらい

対象

2〜3業務

この規模なら、作るだけの人ではなく、上流（コンサルティング）も作ることもできる人に、上流からアダプションまで通して見てもらえます。2〜3業務をPoCで回してみて、その結果で、今後もそのベンダーとやるかを決めます。

続けるかの基準は、3年での回収率

3年での回収率は、3年間で生まれる効果の合計を、3年間にかかる費用の合計で割った割合です。費用には、作る費用、AIの利用料、保守に加えて、外部のコンサルティング会社やベンダーへの委託費用も含めます。導入にかかる費用をすべて含めて、100%なら、かけた費用をちょうど取り戻せたことになります。

一般には、AIへの投資は回収に時間がかかると言われています。会計・コンサルティング大手のデロイトは、2025年に欧州・中東の経営層1,854人を調査しました。典型的なAIの使い道で満足できる投資対効果が出るまで、多くが2〜4年かかると答えています。一般的なIT投資で期待される7〜12か月より、ずっと長い期間です。

一方で、筆者の会社がAskhubを使って支援してきた現場では、3年での回収率が300〜400%に届く例が多く出ています。支援の費用も含めた数字で、業務を適切に選び、ここまでの回で扱った進め方で進めた場合の結果です。

回収率300%は、効果が毎月同じだけ出るとすると、およそ1年で費用をすべて取り戻せる計算です。400%なら9か月ほどです。PoCの結果を見て、この水準に届く効果をそのベンダーが出せそうかを、まず見ます。

たとえば、3年間で作る費用・AIの利用料・保守を合わせて1,000万円かけるとします。効果が年1,000万円なら、3年で3,000万円になり、回収率は300%です。効果の金額は、第5回（業務フローの作り方と、AI導入のROIの出し方）で扱った、現場の時間を積み上げるやり方で出します。

本番の予算は、半期ごとに段階的に広げる

PoCの結果から、回収率300〜400%に届きそうだと見込めたら、本番の予算を取ります。規模にもよりますが、できるなら半期（半年）ごとに取ります。1年単位だと長すぎて、途中で予算を増やせないからです。

金額の目安は、PoCの300万円から、次の半年で1,000万円、その次の半年で2,000〜3,000万円と、徐々に広げる形です。効果を確かめながら、半期ごとに対象の業務を増やしていきます。

予算を半期ごとに広げる階段の図。1段目はPoCで、3か月、300万円（200〜500万円）、2〜3業務を回す。そこで3年で300〜400%を回収できる効果をこのベンダーが出せそうかを判断する。2段目は次の半期で1,000万円、本番に入れる。効果が出ていて回収が見込めるなら、3段目のその次の半期で2,000〜3,000万円とし、新しい業務へ広げる。1年単位だと途中で増やせないので半期ごとに取ること、ランニングコストだけにして止めないことを添えている。金額は目安

一度入れて効率化した後に、費用をランニングコスト（動かし続けるためにかかる費用）だけにするのはお勧めしません。新しいユースケース（AIを使う業務の場面）の開拓が止まってしまうからです。効果が出ていて、投資を回収できる見込みがあるなら、次から次へと進めます。

理由は、AIが世界の経済に与える変化があまりに大きいからです。今は、投資して失敗するリスクより、投資しないで乗り遅れるリスクのほうが大きくなっています。

推進担当が押さえる要点

  • 事故の大きな要因の1つは、パッチが当たっていないこと。外注の一番の良さは保守だが、受託開発の保守に定期的なアップデートが入っているかを確かめる
  • 今は、既製のプラットフォームの上で作るのがおすすめ（基本はケースバイケース）。更新を提供者に任せられ、作る自由もある程度残る
  • 「SaaSなら安全」ではない。任せる相手の保守・監視・情報開示の体制を確かめる
  • 作るだけは安い。本番品質と、基幹システムなど既存の仕組みとの連携でコストが上がる
  • 相見積もりは3社。金額より上流からアダプションまで含むかを比べ、最後まで責任を持つ所を選ぶ
  • PoCは3か月・200〜500万円・2〜3業務が目安。3年の回収率が300〜400%に届きそうかで続けるかを決め、本番は半期ごとに広げる

まとめ：効果が見込める限り、投資を止めない

外注の一番の良さは保守ですが、受託開発の保守に定期的な更新が入っているとは限りません。アップデートの遅れは事故につながるため、更新を提供者に任せられる既製のプラットフォームの上で作るのが、インターセクトとしてのおすすめです。ただし、任せる相手の体制は確かめます。

作るだけのコストは下がっていますが、本番品質と既存システムとの連携で上がります。相見積もりは3社に絞り、上流からアダプションまで責任を持つ所に払います。PoCで3年の回収率を見込み、本番の予算は半期ごとに広げ、効果が見込める限り投資を止めません。

次回の第8回（AXが進まない会社で、上と現場を動かして社内合意をつくる方法）では、PoCの結果や予算の組み方を材料に、上と現場をどう動かすかを扱います。

シリーズの目次

関連記事

参考資料

Askhubについて

Askhubは、日本の中堅・大企業がAIに業務を任せるための基盤です。業務の型（オントロジー）でAIに許す操作を定め、承認と判断ログで任せる範囲を広げながら、国産の基幹システムまで書き込めるようにします。導入はコンサルタントが伴走します。

この記事の言葉で言えば、Askhubは、インフラとセキュリティの管理を提供者が受け持ち、その上の業務の仕組みを会話で作れるプラットフォームにあたります。

※Askhubのサービスに関する記載は、2026年11月時点の情報です。

関連するページ：製品の全体像、伴走支援

PoCの進め方や予算の組み方を相談したい方は、お問い合わせからご連絡ください。

この記事を書いた人

松本拓哉

インターセクト株式会社 代表取締役 CEO

東京大学大学院 工学系研究科 物理工学専攻 博士課程中退。2023年4月、インターセクト株式会社を創業。これまで数十社以上の AX 推進を支援し、自らもコンサルタントとして現場を主導。エンジニアとして AI エージェント基盤「Askhub」の開発にも従事。

この記事の内容について相談する

自社の業務でどう進めるか、相談したい方はこちらのフォームからご連絡ください。1〜2営業日以内に担当者よりご連絡します。

サービス資料をダウンロードする

入門の記事をもっと見る