従来の開発見積もりは、「コードを書く時間」が大部分を占めていました。しかしAIがコードを書くようになると、その前提が崩れます。
この記事では、実際の移植案件での見積もり実務から整理したAI活用開発の見積もりの考え方をまとめます。
この記事の概要
作成日 | 2026年5月2日 |
|---|---|
背景 | Next.js + Supabase構成のアプリ移植案件での見積もり実務 |
主題 | コーディング時間を計上しない見積もりの組み立て方 |
本記事に登場する金額は、単価を仮定した計算例です。当社の料金体系を示すものではありません。
結論：工数の中身が入れ替わる
作業 | 従来の工数 | AI活用後 |
|---|---|---|
コーディング | 60〜70% | ほぼゼロ（AIが担当） |
設計・方針決定 | 10〜15% | 変わらず必要 |
レビュー・テスト | 15〜20% | 中心的な作業になる |
環境構築・設定 | 5〜10% | 割合として増える |
エンジニアの価値は実装量ではなく、判断・検証・設計の質に移行しています。
ここを理解しないまま従来の見積もり方法を使うと、「AIを使うなら安くなるはずだ」という話と噛み合わなくなります。
人間が担う3種類の作業
1. 設定作業（Configuration）
外部サービスの管理画面操作、環境変数の取得・設定、デプロイ設定など。
AIは代替できません。地味ですが、確実に時間がかかります。
- データベースのプロジェクト作成、認証設定、アクセス制御ポリシーの入力
- ホスティング環境の環境変数登録、ドメイン設定
- 外部APIのキー取得・制限設定
ブラウザで管理画面を操作する作業は、コード生成の外側にあります。
2. 確認作業（Verification）
AIが実装したコードを、実際にブラウザや管理画面で動かして正しいか確認する作業です。
品質を担保する最後の砦であり、特に認証・権限まわりは念入りな確認が必要です。
認証の確認パターンは、最低でも3つ必要になります。
- 管理者でログイン → 管理画面が見える
- 一般ユーザーでログイン → 自分に紐づくデータのみ見える
- 未認証 → 公開ページのみアクセス可
3. 判断作業（Decision）
設計の選択、仕様のトレードオフ、AIへの指示内容の決定。
これが最も専門性が高く、単価に見合う部分です。
- アクセス制御の設計方針（テーブル単位か行単位か）
- AI生成機能をAPIルートに分離するか、サーバーアクションにするかの判断
- 実行時間制限への対応方針（上位プランに上げるか、ストリーミングで回避するか）
フェーズ分割で根拠を作る
AI開発案件は、4フェーズに分けると工数の根拠を説明しやすくなります。
フェーズ | 内容 | 工数の目安 |
|---|---|---|
1. 基盤構築・疎通確認 | 認証・DBの基本接続を動かす | 3〜4h |
2. DB構築・アクセス制御 | テーブル作成・ポリシー設定・型生成 | 3〜5h |
3. 機能動作確認 | 各機能をブラウザで操作して確認 | 機能数 × 0.5〜1.5h |
4. デプロイ・最終確認 | 本番環境でのE2E確認 | 3〜4h |
フェーズ3の粒度感が実務的です。
- 単純なCRUD確認：0.5h
- 外部連携（AI生成・ファイルアップロード）：1〜1.5h
- 認証・権限が絡む確認：1〜2h
同じ「1機能」でも、認証が絡むかどうかで確認工数が3倍変わります。
バッファの根拠を言語化する
案件の性質 | バッファ率 | 理由 |
|---|---|---|
PoC・初回導入 | 20% | 想定外の設定ミス・サービス仕様変更が起きやすい |
既存パターンの横展開 | 10% | ハマりポイントが事前に予測しやすい |
社内ツール・リスク低め | 0〜5% | 想定外が少なく、追加請求しやすい関係性 |
この案件（データベース初導入・アクセス制御設定あり）は10%が妥当な落とし所でした。
詰まりやすいポイントをリスク費用の根拠にする
見積もり時にリスクを明示しておくと、追加費用が発生した場合の説明がしやすくなります。
ポイント | 影響 | 対策 |
|---|---|---|
アクセス制御の設定ミス | 他ユーザーのデータが見える・見えないバグ | 3パターン（管理者/一般/未認証）で必ず確認 |
関数の実行時間上限 | AI生成が60秒で切れる（無料プラン） | 早期に実測。超える場合は上位プラン（約3,000円/月）を提案 |
本番とローカルの環境差異 | OAuthリダイレクト失敗など | デプロイ直後にリダイレクトURLを追加する手順を事前に把握 |
外部APIの認証設定 | CORS・ドメイン制限で動かない | 本番デプロイ後に確認する工数を見積もりに含める |
「なんとなく20%」ではなく「この2点が不確定要素なので10%」と言える状態にしておくことが、バッファの説明力を決めます。
クライアントへの提示方法
「正しく動かす費用」として説明する
「コードを書く費用」ではなく「正しく動かす費用」として説明します。
AIが書いたコードを正しく設定・検証・判断する専門性への対価、という位置づけです。
インフラ費用は開発費と分けて明記する
月額コストが後から発覚するとトラブルになりやすいためです。
あわせて初期は無料プランで始められることも伝えると、印象が変わります。
工数の根拠を分解して見せる
フェーズ×作業項目で分解すると、納得感が高くなります。
金額感の参考（単価を仮定した計算例）
単価5,000円/hと仮定した場合の概算です。
案件規模 | 人間工数 | バッファ | 税込概算 |
|---|---|---|---|
小規模（PoC・3機能以下） | 8〜12h | 10% | 約5〜7万円 |
中規模（多機能アプリ） | 15〜20h | 10% | 約9〜12万円 |
大規模（複数ロール・外部連携多数） | 25〜35h | 20% | 約17〜23万円 |
見積もりの構成は次の順で組み立てます。
工数（h） × 単価 = 開発費小計
↓
＋ バッファ
↓
税抜合計
↓
＋ 消費税 10%
↓
税込合計よくある質問
AIを使うと見積もりは安くなりますか？
コーディング工数は減りますが、設定・確認・判断の工数は残ります。むしろ環境構築・設定は割合として増え、レビュー・テストが中心的な作業になります。
何に対して費用をもらうのですか？
「正しく動かす費用」です。設定作業（AIが代替できない管理画面操作）、確認作業（品質担保の最後の砦）、判断作業（設計の選択）の3種類が人間の担当範囲になります。
バッファは何%が妥当ですか？
案件の性質によります。PoC・初回導入なら20%、既存パターンの横展開なら10%、リスクの低い社内ツールなら0〜5%が目安です。重要なのは率より、その根拠を言語化しておくことです。
工数見積もりの粒度は？
4フェーズに分割し、機能確認は機能数×0.5〜1.5hで積みます。単純なCRUDは0.5h、認証・権限が絡むと1〜2hと、3倍程度の幅があります。
まとめ：3つの原則
- コーディング時間は計上しない。AIが書く。人間の時間は設定・確認・判断に集中させる
- 詰まりやすいポイントを事前にリスト化してバッファの根拠にする。「なんとなく20%」ではなく理由を言える状態にする
- インフラ費用は開発費と分けて明示する。月額費用を事前に伝えないと信頼を損なう
加えて押さえておきたい点です。
- 工数の中身はコーディング中心から検証中心へ入れ替わる
- 認証が絡む確認は工数が3倍になりうる
- 提示は「コードを書く費用」ではなく「正しく動かす費用」として
AIが実装を担うようになっても、見積もりが不要になるわけではありません。何に時間がかかるかが変わっただけで、その内訳を説明できるかが信頼を左右します。
株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の開発内製化とAI導入を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。