「AI開発の見積もりを複数社から取ったら、金額に大きな差がついた」——AI開発の発注を検討する担当者から、こうした声をよく耳にします。ある会社は「AI活用で開発費を削減できます」と説明し、別の会社は「データ準備・モデル学習・運用保守を含めるとこの金額になります」と説明する。どちらも間違いではないのに、なぜここまで見積もりの考え方が違うのでしょうか。
この疑問を解く鍵は、「AI開発」という言葉が指す範囲が実は2つに分かれていることにあります。1つは、GitHub CopilotやCursorといったAI Codingツールを使って通常のシステムを開発する案件。もう1つは、AIモデルそのものを組み込んだシステム（自社データを使った予測・分類・生成機能など）を新規に構築する案件です。前者は主に「コーディング工程の工数削減」が論点になり、後者は「データ準備・モデル選定・運用保守」という従来のシステム開発にはなかった費用構造が加わります。見積もりの金額差は、この2つの要因のどちらが、どの程度効いているかで生まれています。
本記事では、この2つの軸——①AI Codingツールによる工数削減効果、②AI開発特有の費用変動要因——を整理したうえで、近年増えている「見積もり自動化ツール」を使う開発会社の見積もりをどう評価すべきかも解説します。そのうえで、「AI活用で安くなります」「AI開発なのでこの金額になります」という提案を発注者が評価するための実践的なチェックリストをお伝えします。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
AI Codingツールとは何か、何を自動化するのか
GitHub Copilot・Cursorが担う「コーディング補助」の実態
GitHub CopilotやCursorは、エンジニアがコードを書く作業を補助するツールです。開発者がコードを書き始めると、AIが続きの候補を提示し、それをそのまま使うか修正するかを判断します。また、自然言語で「こういう機能を作りたい」と入力すると、それに対応するコードを自動生成することもできます。
具体的には、次のような作業を補助します。
- 定型的なコードの生成: データベースとのやり取り（データの取得・保存・更新・削除）や、ユーザー認証、ファイルの読み書きなど、パターンが決まっている処理の実装
- コードの補完: 関数の途中まで書くと、残りの部分を自動で提案
- コードの説明・翻訳: 既存のコードが何をしているか説明させたり、別のプログラミング言語に変換したり
- テストコードの生成: 実装したコードに対するテストコードを自動生成
これらのツールはあくまで「コーディング」という作業を補助するものです。システム全体の設計、要件定義、業務フローの整理、クライアントとのコミュニケーションには直接関与しません。
AI Codingツールが自動化できること・できないこと
対応可能（効率化される作業） | 対応不可（変わらない作業） |
|---|---|
定型的なコード実装（CRUD処理等） | 要件定義・業務フローの整理 |
ボイラープレートコードの生成 | システム設計・アーキテクチャ設計 |
コード補完・候補提示 | 複雑なビジネスロジックの設計 |
テストコードの一部生成 | レガシーシステムの調査・把握 |
コードのリファクタリング支援 | プロジェクト管理・進捗管理 |
ドキュメントコメントの生成 | クライアントとの仕様調整 |
この「できること・できないこと」の区別が、見積もり評価の核心です。
開発工程のどの部分が変わり、どの部分は変わらないのか
システム開発は複数の工程から成り立っています。それぞれの工程にAI Codingツールがどう影響するかを見ていきます。
要件定義・設計フェーズ - AI Codingツールの影響は限定的
要件定義は、「何を作るか」を決める工程です。発注者のビジネス課題を聞き取り、必要な機能・画面・データの流れを整理します。このフェーズでの主な作業は、関係者との会議、業務フローの整理、ドキュメント作成です。
設計フェーズは、要件定義を受けて「どう作るか」を決める工程です。システム全体の構成（アーキテクチャ）、データベースの設計、画面の設計を行います。
これらのフェーズは、AI Codingツールの恩恵をほとんど受けません。理由は単純で、コードを書く作業がほとんど発生しないからです。コーディング補助ツールは、あくまでコードを書く作業を補助するものです。「何を作るか」「どう設計するか」という判断は、依然としてエンジニアの経験と専門知識に依存します。
コーディングフェーズ - 工数削減の実態と限界
コーディングフェーズ（実装フェーズ）こそ、AI Codingツールが最も効果を発揮する工程です。
複数の企業での導入事例では、コーディング工数の10〜30%程度が削減されたという報告が見られます。日立製作所の評価では「コーディングと単体テストの領域で平均10〜20%、ケースによっては30%の生産性向上効果が得られている」とされています（出典: Microsoft Customer Stories, 2024年）。
ただし、この削減効果は案件の性質によって大きく異なります。
効果が高いケース:
- 新規Webアプリケーション開発（標準的なCRUD処理が多い）
- ゼロから始めるプロジェクトで、定型的な処理が多い場合
- TypeScript・Python・JavaScriptなどメジャーな言語での開発
効果が限定的なケース:
- 既存の複雑なシステムへの機能追加・改修
- 独自のビジネスロジックが複雑に絡み合っている部分
- レガシーシステムとの連携（古い技術・独自仕様）
- ニッチな技術スタックや社内独自フレームワークを使う場合
一方、注意すべきデータもあります。AI安全研究機関のMETRが2025年に実施したランダム化比較試験では、大規模なオープンソースプロジェクトに精通した経験豊富な開発者16名を対象に調査した結果、AIコーディングツールを使用した開発者は使用しない場合と比べて19%遅くなったという結果が出ました（METR, 2025年7月）。興味深いのは、開発者自身は「20%速くなった」と感じていた点です。
これは「AIツールを使うと必ず速くなる」というわけではないことを示しています。特に自分が熟知しているコードベースでは、AIへの指示出しやAIの出力を確認する時間がかえってオーバーヘッドになる場合があります。
テスト・品質保証フェーズ - むしろ重要性が増す場合も
テストフェーズは、実装したシステムが仕様通りに動くか確認する工程です。
AIが生成したコードは一見正しく見えても、微妙なバグや想定外の動作を含む場合があります。特に、AIは「それっぽいコード」を生成するのが得意ですが、自社固有のビジネスルールや例外ケースを正確に反映できているかどうかは、人間がテストで確認する必要があります。
そのため、AI Codingツールの活用が進むほど、テスト工程の重要性は高まる、あるいは変わらないというのが現場での実感です。「AIが書いたから大丈夫」という過信は禁物です。
コーディング工数削減の「実態」と「限界」
効果が高いケース - 新規開発・標準的な機能
AI Codingツールの恩恵を受けやすいのは、以下のような案件です。
- 新規Webサービス・アプリの開発: ゼロから作るため、定型的なコードが多い。ユーザー認証、商品一覧・詳細ページ、カート・決済機能など、同様の機能を過去に多くの開発者が実装しており、AIの学習データが豊富
- 管理画面・ダッシュボードの開発: データの一覧表示・検索・編集・削除といった、パターンが決まった操作の実装
こうした案件では、20〜30%程度のコーディング工数削減が期待できる場合があります。ただし、コーディングが全体工数の40〜50%程度とすれば、全体では20%×40〜50%＝8〜15%程度の見積もり削減が現実的な範囲です。
効果が限定的なケース - 複雑なビジネスロジックとレガシー連携
一方、次のようなケースでは削減効果が限定的になります。
- 複雑な業務ロジック: 「この条件の場合はA、ただしB社の場合はC、さらに月末なら特例でD」といった、自社固有の複雑なルールが絡み合うビジネスロジックは、AIが正確にコード化するのが難しい。実装した後の確認・修正にむしろ工数がかかる場合も
- レガシーシステムとの連携: 古い技術（数十年前の言語・フレームワーク）や、ドキュメントが整っていない独自仕様のシステムと連携する場合、AIは助けにならないことが多い。むしろ既存システムの調査・把握に多くの工数がかかる
- セキュリティが厳しい領域: 金融・医療・個人情報を扱うシステムでは、AIが生成したコードのセキュリティ検証に通常以上の手間が必要
「AIで87%削減」といった数字をどう読むか
「AIツール活用でプロジェクト工数を87%削減」といった数字を見かけることがあります。これは事実ですが、文脈を理解することが重要です。
87%という削減率を実現したケース（トランスコスモスの「VibeOpsメソッド」）は、従来15.5人日の案件を1.5人日で完了させたものです。ただし、これは「定型的なWebサイト制作」に近い案件で、かつ厳格な品質管理プロセスを伴っています。すべてのシステム開発案件でこのような削減が実現するわけではありません。
「AI活用」の提案を受けた際は、その削減率がどのような案件・工程で達成されたものなのかを確認することが重要です。
AI開発特有の見積もり変動要因 - データ準備・モデル選定・運用保守費
ここまでは「AI Codingツールを使って通常のシステムを開発する場合」の見積もり変化を見てきました。一方、発注する案件がAIモデルそのものを組み込んだシステム（需要予測・画像認識・チャットボットなど、自社データを学習・活用する機能）の構築である場合、見積もりにはこれまでのシステム開発にはなかった費用要因が加わります。ここが、AI開発の見積もりに費用予算の見積もりが立てにくいと感じる大きな理由です。
データ準備・アノテーションが見積もりを左右する
AIモデルは学習データの質と量に精度が大きく左右されるため、データを整備する工程（欠損値の補完、フォーマットの統一、正解ラベルの付与＝アノテーションなど）が必要になります。自社に整備済みのデータが十分にある場合と、紙帳票や散在したExcelファイルからデータを作り直す必要がある場合とでは、この工程だけで工数が数倍変わることも珍しくありません。見積もり明細に含まれる項目としてこの費目が独立して立っているか、それとも「一式」に含まれているかで、内訳の透明性が変わってきます。
モデル選定・精度要件がコストを左右する
システム開発におけるAIの精度要件も、費用に直結する要因です。既存の汎用APIやオープンソースモデルをそのまま使えるケースは比較的低コストですが、自社データに合わせてファインチューニング（追加学習）が必要な場合や、要求される精度水準が高い場合（誤判定が業務上の損失に直結する領域など）は、モデルの選定・検証・チューニングに繰り返し工数がかかり、費用が積み上がります。「どの程度の精度を求めるか」を発注時点で具体的に伝えられているかどうかが、見積もりの精度そのものにも影響します。
運用保守費（再学習・監視）が見落とされやすい
通常のシステム開発では、運用保守費は「不具合対応・軽微な改修」が中心です。しかしAIモデルを組み込んだシステムでは、これに加えて「モデルの精度が時間とともに劣化していないかの監視」「新しいデータでの再学習」といった、AI特有の運用保守作業が発生します。初期見積もりにはこの費用が含まれておらず、運用開始後に追加費用として提示されるケースもあるため、見積もり段階で運用保守フェーズの内容を確認しておくことが重要です。
案件の難易度・種類によって相場の目安は大きく変わる
AI開発の見積もりに「この金額が相場」という一律の目安を示すのが難しいのは、案件の種類によって必要な工程の組み合わせが変わるためです。既存の汎用AIサービスを組み込むだけの案件と、自社専用モデルをゼロから学習させる案件とでは、必要なデータ準備・モデル開発の工数が大きく異なります。相場の目安を知りたい場合は、金額そのものよりも先に「自社の案件がどの種類に近いか」（汎用API活用型か、自社データによる独自モデル構築型か）を整理したうえで、開発会社に照らし合わせて確認することをおすすめします。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
見積もり自動化ツールの普及と発注者が確認すべきポイント
近年、開発会社の側でも「見積もり自動化」の動きが進んでいます。過去の類似案件データをAIに学習させ、要件の入力に対して工数・費用を自動算出するツールを導入する会社が増えてきました。あわせて、DataSpiderのようなノーコード・ローコードの開発工数削減ツール（データ連携・業務自動化基盤）を組み込むことで、実装自体の工数を圧縮する会社も見られます。これらのツール活用は、発注者が受け取る見積もりの中身や作られ方に影響するため、内容を理解しておく価値があります。
見積もり自動化のメリットと注意点
見積もり自動化のメリットは、担当者による属人的なブレが減り、類似案件との比較が一貫した基準で行える点にあります。一方で注意したいのは、自動算出ロジックが案件固有の事情（既存システムとの連携難易度、社内特有の業務ルールなど）をどこまで反映できているかです。自動算出された数字をそのまま提示するのではなく、担当者が個別事情を踏まえて調整しているかを確認しましょう。「自動見積もりなので正確です」という説明だけで終わる会社より、「自動算出した工数に、御社特有の連携要件を加味して調整しました」と説明できる会社のほうが、運用の実態として信頼度が高いといえます。見積もり自動化ツールを社内でどう運用しているか（誰が最終チェックをするか、算出結果をどのタイミングで見直すか）まで説明できる会社は、ツール任せにしていない証拠として評価できます。
開発工数削減ツールの導入有無を比較の視点に加える
開発会社がDataSpiderのようなiPaaS（データ連携基盤）やノーコードツールを活用し、開発工数そのものを削減している場合、その削減効果が見積もりにどう反映されているかを確認する価値があります。工数削減ツールの導入は開発会社にとってのコスト構造の変化であり、それが発注者への価格に反映されているか、それとも会社側の利益率改善に留まっているかは、会社によって対応が分かれます。複数社を比較する際は、金額だけでなく「どのようなツール・体制で開発工数を削減しているか」を尋ねてみるとよいでしょう。
発注者が見積もりを評価する際の新しい視点
従来の見積もり評価と何が変わったか
従来のシステム開発見積もりは、主に「工数（人月・人日）×単価」で計算されていました。発注者の評価ポイントも、工数の根拠（機能ごとの工数内訳）と単価の妥当性でした。
AI Codingツールが普及し、AIモデルを組み込んだ開発案件も増えた現在、これに加えて「AI活用の効果がどの工程にどの程度反映されているか」「AI開発特有の費用（データ準備・モデル選定・運用保守）が内訳として明示されているか」という2つの視点が必要になりました。
「AI活用」の提案で確認すべき4つのポイント
ポイント1: 削減される工程が具体的に示されているか
「AI活用で工数削減」という説明に対して、「具体的にどの工程の工数を何%削減する計画ですか？」と確認しましょう。コーディング工程での削減であれば根拠のある提案ですが、「全体的に削減できます」という説明は曖昧で、根拠として不十分です。
ポイント2: 削減されない部分も説明されているか
誠実な開発会社は、AI Codingツールの限界についても説明します。「要件定義・設計フェーズはAIの影響を受けないため、この部分の工数は変わりません」「御社の業務ロジックが複雑なため、コーディング工数の削減効果は限定的です」といった説明があるかどうかが、信頼性の指標です。
ポイント3: AIツールの費用の扱いが明示されているか
GitHub Copilot（月額$10〜19/人）やCursor（月額$20/人）などのツール費用は、開発費用に含まれているのか別途請求なのかを確認しましょう。多くの場合、ツール費用は開発者の費用に含んで計上されますが、明確にしておくべきです。
ポイント4: 案件の性質・AI開発特有のコスト構造を考慮しているか
前述の通り、AI Codingツールの効果は案件の性質によって大きく変わります。新規開発か既存システムの改修か、ビジネスロジックの複雑さ、レガシーシステムとの連携有無に加え、案件がAIモデルを組み込んだ開発である場合は、データ準備・モデル選定・運用保守という追加コストが必要な範囲まで考慮した上での工数・費用を提示しているかを確認しましょう。
複数社見積もり比較時の注意点
「AI活用で安くなります」という会社と「AIを活用しない」という会社の見積もりを比較する場合、単純な金額比較では適切な判断ができません。
AI活用の開発会社の見積もりが安い場合でも、それがテスト工程や設計工程の手抜きによるものであれば、後工程でのトラブルリスクが高まります。反対に、AI Codingツールを活用していない場合でも、経験豊富なエンジニアによる丁寧な開発が必ずしも割高とは限りません。
また、案件がAIモデルの構築を含む場合は、工程別の内訳に加えて、データ準備・モデル選定・運用保守という費目が各社の見積もりに含まれているかも比較しましょう。ある会社の見積もりに含まれる費目が、別の会社では「別途相談」扱いになっているケースもあるため、費目の有無をそろえたうえで金額を比較することが重要です。
比較する際は、各社の見積もりが工程別・費目別に内訳を示しているかを確認し、全体金額だけでなく工程ごとの工数・単価を比較することが重要です。
「AI活用で安くします」という提案をどう評価するか
信頼できる「AI活用見積もり」の特徴
次のような提案は、誠実さと専門性の高さを示しています。
- 工程別の工数内訳が明示されている: 「要件定義: 5日、設計: 10日、コーディング: 20日（AI活用で従来比20%削減）、テスト: 10日」のように、工程ごとの工数が示されている
- 削減根拠が具体的: 「弊社では月次で開発効率を計測しており、類似案件での実績として、新規Webアプリ開発のコーディング工数を平均15%削減しています」のような実績に基づく根拠
- 限界についても正直に話す: 「御社のシステムが既存の基幹システムと連携する部分は、AI Codingツールの効果が限定的です。この部分については工数削減を見込んでいません」
- AIツール費用の扱いが明確: ツール費用の扱いについて明示している
注意すべき「AI活用見積もり」のパターン
逆に、次のようなパターンには注意が必要です。
- 根拠のない大幅削減: 「AI活用で費用を50%削減できます」と言いながら、その根拠（どの工程で、どういう根拠で）を示せない
- AI活用をアピールしながら工数が変わらない: AIツールを使うと言いながら、見積もり金額が他社と比べて高い。ツール費用が二重計上されている可能性
- テスト工程が極端に少ない: コーディング工数は削減されているが、テスト工数も比例して削減されている。品質保証が不十分なリスクがある
- AI活用の実績が示されない: 「最新のAIを使います」とだけ言って、具体的な活用実績・社内体制・ツール名が不明
秋霜堂株式会社のAI Coding活用における考え方
秋霜堂株式会社では、GitHub CopilotやCursorなどのAI Codingツールを開発現場で活用しています。その中で実感しているのは、「効果がある部分」と「効果が限定的な部分」の区別です。
標準的な新規Webアプリケーション開発のコーディング工程では、定型処理を中心に一定の工数削減ができています。一方、要件定義・設計フェーズはAIツールの影響をほとんど受けず、複雑なビジネスロジックやレガシーシステム連携部分も削減効果が限定的です。
そのため、見積もりにAI活用の効果を反映する際は、案件の性質を十分に分析した上で、削減できる部分に絞って適切に反映することが誠実な対応だと考えています。
AI時代の見積もり評価チェックリスト
「AI活用で安くなります」「AI開発なのでこの金額です」という提案を受けた際に、以下の項目を確認することで、提案の妥当性を判断できます。
見積もり内容の確認項目
チェック項目 | 確認ポイント |
|---|---|
1. 削減工程の明示 | どの工程（コーディング等）で何%削減するか、具体的に説明されているか |
2. 工程別内訳 | 要件定義・設計・コーディング・テストそれぞれの工数が内訳として示されているか |
3. 削減の根拠 | 過去の類似案件での実績や、具体的な計測データがあるか |
4. 削減されない部分の説明 | AI Codingツールの限界（設計・要件定義・複雑なビジネスロジック等）についても言及されているか |
5. ツール費用の扱い | GitHub CopilotやCursorなどのツール費用の扱いが明示されているか |
6. 案件特性への言及 | 自社案件の特性（新規か改修か、ビジネスロジックの複雑さ、レガシー有無）を踏まえた説明があるか |
7. テスト工程の充実度 | AIコード生成を前提とした場合でも、テスト工程の工数が適切に確保されているか |
8. AI活用実績の提示 | 自社でのAIツール活用実績や社内体制について具体的な情報があるか |
9. AI開発特有費目の明示 | 案件がAIモデルの構築を含む場合、データ準備・モデル選定・運用保守（再学習・監視）が内訳として明示されているか |
10. 見積もり自動化ツールの説明 | 自動算出ツールを使っている場合、算出ロジックと案件固有事情の反映有無を説明できるか |
判断の目安
チェック項目のうち、1・2・4・7・9の5項目は特に重要です。これらが説明できない場合、提案の信頼性に疑問符がつきます。
また、AI活用を前提とした見積もりが他社より10〜15%程度安い場合は合理的な範囲です。20%以上安い場合は、工程の省略がないか確認が必要です。50%以上の大幅削減を謳う場合は、その根拠と対象工程を詳しく確認することをおすすめします。案件がAIモデルの構築を含む場合は、金額の高低よりもまず、データ準備・モデル選定・運用保守という費目がそもそも見積もりに含まれているかを確認することが、比較の出発点になります。
AI Codingツールの普及、そしてAI開発案件そのものの増加は、システム開発の見積もりのあり方を確実に変えつつあります。ただしその変化は「全体的にコストが下がる」という単純なものではなく、「特定の工程で効率化が進む一方、AI開発特有の費用構造が新たに加わる」という、二重の構造を持っています。
この構造を理解することで、「AI活用で安くします」「AI開発なのでこの金額です」という提案を、どちらも適切に評価できるようになります。提案の内容を工程別・費目別に確認し、削減の根拠と追加コストの両方について誠実に説明できる開発会社を選ぶことが、AI時代の発注者として大切な視点です。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- AI活用で見積もりが「安くなる」のは何%程度が妥当ですか？
AI Codingツールの効果はコーディング工程に限られるため、全体見積もりへの影響は概ね8〜15%程度が現実的な範囲です。コーディング工数の20〜30%削減でも、それが全体の40〜50%を占めるに過ぎないため、「50%削減」などの大幅な主張は根拠を必ず確認してください。
- 自社の案件はAI活用の効果が出やすいタイプですか？
新規のWebアプリ開発でCRUD処理が多い場合は効果が出やすく、既存システムの改修・複雑な業務ロジック・レガシーシステム連携が絡む場合は効果が限定的です。発注前に「新規か改修か」「業務ロジックの複雑さ」「レガシー連携の有無」の3点を開発会社に伝えて、どの工程にどの程度の削減を見込んでいるか確認することが判断の近道です。
- AI活用を謳いながらテスト工程も削減している見積もりは問題ですか？
AIが生成したコードは一見正しく見えてもバグや想定外の動作を含む場合があるため、テスト工程はむしろ重要性が増します。コーディング削減に比例してテスト工数も減っている見積もりは品質保証が不十分なリスクがあり、注意が必要です。
- GitHub CopilotやCursorのツール費用は見積もりに含まれているか確認すべきですか？
はい、確認が必要です。GitHub Copilot（月額$10〜19/人）やCursor（月額$20/人）などのツール費用が開発費に含まれているか別途請求かを明確にしておかないと、二重計上や予算超過のリスクがあります。
- 複数社を比較するとき、AI活用の会社と非活用の会社の見積もりをどう比較すればいいですか？
金額だけで比較するのではなく、工程別の工数内訳を各社から取り寄せて比較してください。AI活用で安くなっていても、テストや設計の工数が削られていれば後工程でのトラブルリスクが高まるため、全体金額より各工程の妥当性を確認することが重要です。
