「一式◯◯万円」の正体 AI受託開発の見積書を発注者目線で分解する

2026年8月28日

執筆・監修：株式会社Walkers 代表取締役渡辺敦司

AI受託開発の見積書に並ぶ「一式150万円」という表記は、多くの場合、工程、工数、単価の積み上げを1行に圧縮した結果です。ただし、積み上げを持たないまま1行になっている見積も混じり、両者は書面の見た目では区別できません。発注者が取るべき行動は、金額の妥当性を印象で判断しないこと。後述する10の質問で内訳を言語化させ、それに答えられる相手かどうかで発注先を選ぶことです。

クリックできる目次

「一式」の1行が書かれるまで

同じ要件書を渡した3社から、見積書が返ってきたとしましょう。どの書面にも「一式」の1行と合計金額しか書かれていません。そして三つの金額が揃いません。どれかが高すぎるのか、どれかが工程を落としているのか、書面からは手がかりが出てきません。

一式見積とは、要件定義、設計、実装、テストといった個別工程の金額を積み上げて示さず、開発全体を一つの金額にまとめて提示する見積形式を指します。この表記を見た瞬間に「内訳を隠されている」と感じる発注者は多いです。ですが、その感覚だけで発注先の誠実さを判断するのは早計です。

システム開発の見積りは、本来「人月単価 × 工数」で算出されます。人月単価とは、エンジニア1人が1か月稼働した場合にかかる金額のことで、給与や社会保険料に加えて、開発会社の管理費、教育費、環境費、営業費、利益が含まれます(発注ラウンジ)。この単価に、要件定義から保守運用までの各工程で何人が何か月働くかを掛け合わせ、工程ごとの金額を合算したものが、本来の見積の内訳です。

見積を作る側の机の上には、工数が読める項目と読めない項目が混ざっています。画面数が決まっている機能の実装なら、過去の案件から日数を引いてこられます。一方で、AI機能の出力をどこまで詰めるかは、何巡の検証で要求水準に届くかが着手前に確定しません。読めない項目に0を置くわけにはいかないから、幅を見込んだ数字を置き、全体を丸めます。

そこから先は、説明の順序をどう選ぶかという問題になります。工程別に割り戻して載せれば、幅を見込んだ項目の数字だけが独り歩きし、提案の場が検証回数の交渉から始まります。だから合計だけを示し、聞かれたら口頭で説明します。この判断が重なって、提案書に合計額だけを載せる慣行が定着しました。つまり一式は、見積書の体裁を整えるための省略であって、計算根拠が存在しないわけではありません。

この慣行が問題化するのは、発注者が内訳を求めても答えが返ってこない場合です。内部に工程別の工数見積りが存在しないまま「一式」で通しているとすれば、単価も工数も精査せずに金額を決めていることになります。内訳を持ちながら開示しない場合もあります。前者は見積能力の欠如で、後者は情報の非対称性を利用した価格戦略。別の問題です。そして、どちらであるかは書面からは読み取れません。読み取れるのは、内訳を尋ねたあとの反応だけです。

工程ごとに何にいくらかかるのか？

では、1行に圧縮される前の姿はどうなっているのでしょうか。一般的なシステム開発やAI開発は、要件定義、設計、実装、テスト、保守運用の5工程に分かれます。工程ごとの費用配分には業界内でおおよその相場観があり、開発会社間で大きくは違いません。

工程	費用配分の目安	何にかかる費用か
要件定義	全体の10〜20%	業務ヒアリング、要求の整理、機能範囲の確定。工数自体は小さいが、業務とAI技術の両方を理解した上級人材が担うため単価が高い(ysinc.co.jp、みんなのシステム企画)
設計	全体の15〜25%	画面設計、データ構造の設計、AIモデルや外部API連携方式の設計。要件の曖昧さがここで吸収しきれないと、実装以降の手戻りに直結する(ysinc.co.jp)
実装	全体の40〜50%	画面や機能の開発、AI機能の組み込み、外部システムとの連携。工数の絶対量が最も大きく、金額の主要部分を占める(ysinc.co.jp)
テスト	全体の10〜20%	機能テスト、結合テスト、AI機能特有の出力精度や異常系の検証。テストを圧縮するほど、納品後の不具合対応コストが発注者側に転嫁されやすい(ysinc.co.jp)
保守運用	開発費とは別建て。年間で開発費の15〜20%が目安	障害対応、機能追加、AIモデルやAPI仕様変更への追従。開発費用の見積りには含まれないことが多く、別途契約になる(c3index.co.jp)

見積「一式」の中身を工程別の費用配分で示したレンジバー図。要件定義は全体の10〜20%、設計は15〜25%、実装は40〜50%、テストは10〜20%。保守運用は開発費とは別建てで年間に開発費の15〜20%が目安。4工程の配分は幅を持つため合計は100%にならない — 図1 見積「一式」の中身：工程別の費用配分の目安。数値は本文の工程別内訳表と同じ。

人月単価そのものにも幅があります。発注ラウンジの集計では、プログラマーで月額60〜70万円程度、システムアナリストで80〜110万円程度、プロジェクトマネージャーで70〜130万円程度とされ、首都圏と地方でも差があると報告されています(発注ラウンジ)。また、開発会社としての人月単価とプロジェクト総額の目安をまとめた集計では、小規模開発で人月単価100〜180万円、総額500〜1,200万円、中規模で150〜220万円、大規模で180〜250万円という幅が示されています(SIA株式会社)。いずれも集計方法によって数値の幅が異なります。だから単一の「正しい相場」として扱わず、複数の見積りを比較する際の目安として使うのが実務的です。

机の上の3社に戻ります。三つの金額が揃わない理由の一つは、この単価の幅にあります。同じ職種でこれだけ開きがあれば、体制の組み方が違うだけで総額は動きます。もう一つは工程配分と保守の扱いで、テストを全体の10%で見た会社と20%で見た会社では同じ実装量でも合計が変わり、保守運用を別建てにした会社の見積は含めた会社より安く見えます。つまり、金額が揃わないこと自体は異常ではありません。

異常なのは、揃わない理由を尋ねたときに数字が出てこないほうです。「一式◯◯万円」を上の表の工程別配分に当てはめたとき、どこにどれだけ配分されているかを、開発会社が具体的な数字で答えられるかどうか。答えられないなら、金額の妥当性を検証する手段が発注者側にない状態で契約することになります。

見積書を受け取った日に投げるべき10の質問とは？

見積書を前にした発注者が最初に思い浮かべるのは、たいてい工程配分でも単価でもありません。これを全部聞いたら、値切りに来たと思われないか。

その心配は的外れではありません。10問を一度に並べて送れば、体裁は詰問に近づきます。ただ、10問は同じ重さではありません。1と2に数字で答えが返ってくれば、残りの8問は確認作業として流れます。1と2で言葉が濁るなら、残り8問も同じ調子になります。順番に意味があるのはそこです。

以下の10問は、見積書を受け取った段階でそのまま使えます。

この見積金額は、要件定義、設計、実装、テストのそれぞれにどれだけ配分されていますか。
想定している人月単価と、投入人数と期間の内訳を教えてください。
要件定義の結果、機能範囲や仕様が当初の想定から変わった場合、追加費用はどう発生しますか。
AI機能の精度検証やチューニングにかかる工数は、見積のどの工程に含まれていますか。
テスト工程では、具体的にどのようなテスト（機能、結合、負荷、AI出力の異常系など）を、誰がどれだけの工数で行いますか。
納品後の保守運用費用は、この見積に含まれていますか。含まれていない場合、年間でいくらを見込めばよいですか。
仕様変更や追加要望が出た場合、どの単位（時間単価か工数単位か）で追加費用を計算しますか。
プロジェクトの体制は何人で、それぞれの役割（PM、エンジニア、デザイナーなど）は誰が担いますか。
ソースコードや成果物の著作権や知的財産権は、契約上どちらに帰属しますか。
開発途中で契約を解除する場合、それまでの成果物に対する支払い義務はどう発生しますか。

すべてに数字や固有名詞で答えが返ってくる会社は、内部で工程別の積算を持っている可能性が高いです。曖昧な言葉で返される項目があれば、その項目がそのままリスクの所在になります。4がぼやけるなら、AI部分の工数はまだ読めていません。

相見積で比較すべき金額以外の軸とは？

では、10問に数字で答えた会社が2社残ったら、あとは安いほうを選べばよいのでしょうか。そうしたい、とは思います。総額は手元にあり、比較の手間もいりません。ですが総額だけの比較は、契約後に効いてくる条件をまとめて視界の外へ置きます。金額以外に確認すべき軸は次の四つです。

体制では、提案時に説明した担当者が実際の開発チームに入るかを確認します。営業と実装が分かれている会社では、説明と実装内容が乖離することがあります。

保守契約では、開発費用の見積りに保守運用費が含まれているかどうかを区別します。含まれていない場合、契約直後の総額は安く見えても、年間の保守費用が開発費の15〜20%程度かかります(c3index.co.jp)。だから中期的な総コストで比較する必要があります。

権利関係では、開発したシステムのソースコードや、AI機能に使うプロンプトやチューニング済みモデルの著作権が発注者に帰属するかを確認します。帰属先が開発会社のままだと、将来別の会社に保守を引き継ぐ選択肢が狭まります。

変更対応では、要件定義後に仕様変更が発生した場合の追加費用の算定方法が明文化されているかを見ます。「別途見積り」としか書かれていない契約は、変更のたびに交渉コストが発生します。

四つとも見積書の金額欄には現れません。現れるのは、あとから届く請求書のほうです。

Walkersはどのように見積を組み立てているか？

株式会社Walkersでは、AI受託開発や導入支援の見積りを「一式」の一言で終わらせず、サービスの種類、導入目的、開発期間、連携範囲という加算要素の組み合わせで算出しています。この構造をそのまま公開しているのが、料金シミュレーター(https://simulation.walker-s.co.jp)です。10個の質問に答えるとその場で費用の目安が表示され、自分の案件を入力しながら、どの要素が金額を押し上げるのかを確認できます。

実際の受託案件の水準も公開しています。Walkersの概算は、Webサービス・アプリ開発が200万〜500万円、業務効率化システム開発が200万〜800万円（いずれも税別・要件定義費用は別途）、AI導入支援（FDE型伴走支援）が完全月額制で月額50万〜100万円（税別）です(walker-s.co.jp/pricing)。この幅の中でどこに位置するかは、先の加算要素の組み合わせで変わります。

内訳を先に公開するのは、発注者が加算要素を自分で確認できる状態のほうが、契約後の認識齟齬が起きにくいからです。金額の根拠を尋ねられて答えに詰まるやり取りは開発会社側のコストでもあり、先に開示しておくことは双方の手間を減らします。

机の上に並んだ3社の見積書は、金額を見比べただけでは順位が決まりません。順位がつくのは、同じ10問を投げて返ってきた答えを並べたときです。数字が返ってこない見積書は、最も安くても、安いかどうかを確かめる手段がありません。もっとも、数字が揃った2社のどちらが着地に近いかまでは、書面からは決まりません。それは過去にどれだけ見積を外してきたかの話であり、見積書には書かれていません。

FAQ

見積書に「一式」としか書かれていない場合、断ってもよいのか

「一式」という表記そのものは、慣行として広く使われているため、それだけで発注を断る理由にはなりません。判断材料になるのは、前述の質問リストを投げたときに、工程別の配分や人月単価を具体的な数字で答えられるかどうかです。答えが曖昧なまま金額だけを押される場合は、内部に積算根拠がない可能性を考えたほうがよいでしょう。

内訳を聞いたら「企業秘密なので出せない」と言われた。どう考えればよいか

単価表そのものを外部に出せないという説明は、営業上の理由としてあり得ます。ただし、その場合でも、工程ごとの費用配分（割合）や、投入人数と期間の目安までは説明できるはずです。割合の説明すら避ける場合は、内訳を尋ねる行為自体を歓迎していない可能性が高いです。

AI開発は工数が読みにくいと言われるが、見積の内訳は普通のシステム開発と同じ考え方でよいのか

要件定義、設計、実装、テスト、保守運用という工程区分自体は、AIを組み込む開発でも変わりません。異なるのは、実装工程にAIモデルの選定やチューニング、出力精度の検証が加わり、テスト工程にAI特有の異常系検証が加わる点です。工程区分を保ったまま、AI関連の作業がどの工程に何時間配分されているかを確認すれば、通常のシステム開発と同じ枠組みで比較できます。

相見積で一番安い会社を選ばない方がよいのはなぜか

金額だけを比較すると、保守費用が含まれているか、権利関係がどちらに帰属するか、仕様変更時の追加費用の算定方法が明文化されているかといった、契約後に効いてくる条件が見落とされやすいです。総額が安い提案が、保守費用を開発費に含めず、権利も開発会社側に残す契約になっていれば、中期的な総コストは逆転することがあります。金額と合わせて、体制、保守、権利、変更対応の4軸を確認したうえで比較する必要があります。

見積の内訳を聞くと関係が気まずくならないか

内訳の確認は、価格交渉ではなく、契約後に何が起きるかを事前にすり合わせる作業です。信頼できる開発会社であれば、工程別の配分や算定根拠を説明することを、発注者の理解を助ける機会として受け止めます。質問への回答を渋る、あるいは不機嫌になる会社があるとすれば、それ自体が発注先選定における判断材料になります。

最終更新日: 2026年8月28日