アプリ開発の費用｜発注先6類型を実名・実サイトで比較する。見積もりが数倍ぶれる場所はどこか

アプリ開発の見積もりを3社に頼むと、金額が3倍違うことがあります。よくある説明は「会社によって単価が違うから」ですが、単価表を見比べても3倍の差は説明できません。

今日は、アプリ開発の費用がなぜ数倍ぶれるのか、どの発注先だとどう決まるのか、という話をしていこうと思います。この記事は、発注先を6つの類型に分けます。そして類型ごとに、代表的な会社の公式サイトの実物（ファーストビューのスクリーンショット）と、各社が自分で書いているディスクリプション（検索結果に出す自己紹介文）を並べて比較します。紹介記事の伝聞ではなく、各社が自分のサイトで名乗っている言葉を一次情報として使います。あわせて、費用のぶれ幅の大きさを、公開されている調査データの実数で確かめます。

先に結論を一行だけ置きます。アプリ開発の費用を動かしているのは、時間あたりの単価ではなく、仕様が決まるまでの往復の回数です。 6つの類型は、この「決まっていない量」をどう扱うかで分かれています。

① 費用を動かしているのは、単価ではなく「決まるまでの往復」。

費用の式は、どの会社でもほぼ同じです。人数 × 期間 × 単価。式そのものは正しいものです。ところが、この式には「期間」を膨らませる変数が隠れています。仕様が決まるまでの往復の回数です。

アプリの開発では、プログラムを書き換えるたびに、いつ・どのファイルを・何回直したかが履歴として残ります。発信元（ARCHECO）の開発記録にある実測を1つだけ引きます。着手前に決めごとを文書化せずに作った機能では、関連ファイルの変更が362回に達しました。一方、同じチーム・同じ道具でも、結果が変わった機能があります。作る手順を10段階に割り、確かめる項目を31個書き出してから着手したもので、こちらは25回で完了しています。362回と25回。単価は同じでも、費用は十数倍の差になります。

つまり、見積もりを比較する前に見るべきなのは、単価の欄ではありません。「決まっていない項目を、誰が、どの工程で、何回の往復で決めるか」の扱いです。6つの類型は、ここへの答え方がそれぞれ違います。

② 公開データで、ぶれ幅がどれくらいかを確かめる

感覚の話に留めないために、一次資料（調査元が直接公表した資料）を2つ置きます。どちらも無料で全文が読めます。

IPA（独立行政法人情報処理推進機構）の『ソフトウェア開発分析データ集2022』は、5,546プロジェクトの定量データを分析したものです。2022年9月26日公開。企業の業務システムの実績値が、工数・工期・規模・生産性の別に載っています。

工数から見ます。単位は人時で、1人が1時間働く量を1と数えます。データのある1,444件で、プロジェクト全体の工数の中央値は7,395人時でした。1人が1日8時間働くとして、およそ920日ぶんです。

ただし、中央値ではなく、ばらつきが本題です。件数を小さい順に並べて4等分したとき、下から4分の1の地点（第1四分位）が3,105人時、上から4分の1の地点（第3四分位）が20,446人時でした。極端に小さい案件と極端に大きい案件を捨てて、真ん中の半分だけを取り出しても、上下で6.6倍の開きがあるという意味になります。

工期にも同様のばらつきがあります。1,396件で、工期の中央値は10.1か月。第1四分位が6.0か月、第3四分位が15.0か月です。IPAはこの中央値について「2014年度〜2019年度と比較して、1ヶ月多くなっている」と書いています。つまり、3社の見積もりが3倍違うのは異常値ではありません。公開されている実績のばらつきの範囲に、きれいに収まっています。

もう1つ。JUAS（日本情報システム・ユーザー協会）の『企業IT動向調査2025』は、2024年度の調査結果を2025年4月10日に公表したものです。こちらは規模を人月で区切っています。業務アプリを1本作る規模なら、たいてい、いちばん小さい100人月未満の区分に入ります。

工期が「予定どおり完了」した割合は、その100人月未満のプロジェクトで31.0%でした（回答694件）。100〜500人月未満では393件のうち16.0%、500人月以上では245件のうち11.0%。規模が大きくなるほど、予定どおりに終わらなくなります。 そして、いちばん小さい区分でも、予定どおり終わったのは3件に1件です。JUASは「10年間（15〜24年度）の推移では、すべてのプロジェクト規模で『予定どおり完了』の割合が低下傾向にあり、24年度においても改善の兆候は見られない」と書いています。

ここで、同じ工期を扱う2つの資料に大きな差が出ます。IPAの集計では、開発した側の自己評価で工期が「ほぼ計画以内」だったプロジェクトが約90%ありました。同じ工期の話で、IPAは90%、JUASは31.0%です。差を生んでいるのは実態ではなく、問いの立て方です。費用の議論も同じで、何を数えるかを決めないうちは、どの数字も正しく見えます。

③ 発注先は6類型に分かれる。分ける軸は「決まっていない量」。

発注先の候補は、規模や国ではなく、「決まっていない量をどう扱うか」で分けると選びやすくなります。この記事では6つの類型に分けます。

A. グローバル総合型 ── 決まった大規模要件を、統制をかけて確実に動かす。
B. プロダクトエンジニアリング型 ── 変え続けても壊れない設計で作る。
C. デザイン起点型 ── 使う人の行動から、作るものの形を決める。
D. オフショア・ラボ型 ── 決まった仕様を、単価あたりの投入量で量産する。
E. ローコード／ノーコード型 ── 標準部品で「作らずに済む範囲」を先に確かめる。
F. AI活用の共創型 ── 決める工程そのものに入り、往復の回数を減らす。

④ 6類型の比較表

類型	代表的な会社	強い場面	噛み合わない場面
A. グローバル総合型。	アクセンチュア、TCS、インフォシス、NTTデータ。	止められない大規模業務、監査対応。	小規模案件（統制の分まで払う）。
B. プロダクトエンジニアリング型。	Thoughtworks、EPAM、Globant。	長く変え続ける製品の設計。	何を作るか未定の段階。
C. デザイン起点型。	IDEO、グッドパッチ。	「動くのに使われない」の防止。	大量の実装・運用体制。
D. オフショア・ラボ型。	FPTソフトウェア。	仕様確定後の量産。	仕様が固まる前（往復が高くつく）。
E. ローコード／ノーコード型。	OutSystems、Mendix、Power Apps。	標準業務の高速立ち上げ。	標準から外れた業務、利用料の累積。
F. AI活用の共創型。	ARCHECO。	決まっていない段階からの伴走。	決まりきった大規模量産。

以下、類型ごとに実在の会社を置きます。スクリーンショットは各社の公式サイトのファーストビュー（2026年8月取得）、引用文は各サイトのディスクリプションの原文です。 記述は公開情報に基づく整理であり、契約前には必ず各社へ最新の内容を確認してください。

⑤ A. グローバル総合型 ── 規模と統制

数千人が使うシステムを、決めた期日に、決めた品質で動かす類型です。強いのは、止められない業務を載せられること。基幹システムとの連携や、法令対応の継続も含めて引き受けられます。見積書に「非機能要件の定義とテスト計画」という行が立っていたら、この類型の作法です。一方で、小規模案件とは噛み合いません。統制の作り込みそのものに工数がかかるため、要らない安全装置の分まで払うことになります。

アクセンチュア

公式ディスクリプション:「アクセンチュアは、ストラテジー & コンサルティング、テクノロジー、オペレーションズ、インダストリーX、ソングの領域でサービスを提供する総合コンサルティング企業です」。

日本TCS（タタ・コンサルタンシー・サービシズ）

公式ディスクリプション:「日本TCS(Tata Consultancy Services Japan)は、世界的なITサービス企業であるタタコンサルタンシーサービシズの一員として、日本企業に向け先進性・合理性を兼ね備えたITサービス・ソリューションを提供しています」。インド発で、世界有数の技術者数を抱えます。

インフォシス

公式ディスクリプション:「Infosys is a global leader in next-generation digital services and consulting.」。訳すと、次世代デジタルサービスとコンサルティングのグローバルリーダー。同じくインド発の大手です。

NTTデータ

公式ディスクリプション:「NTTデータグループのウェブサイトです。NTTデータグループのビジョン、経営戦略、ニュース、IR、サステナビリティなどの情報をご覧いただけます」。国内最大手にあたります。

4社のサイトを並べると、共通点が見えます。製品の画面ではなく、変革・戦略・産業の言葉が先頭に来ることです。個別のアプリを作る話より前に、業務全体を引き受ける立て付けで書かれています。この名乗り方が、そのまま見積もりの構造（統制と体制の費用が乗る）に対応しています。

⑥ B. プロダクトエンジニアリング型 ── 変え続けても壊れない設計

他社の製品開発を丸ごと引き受けるソフトウェア専業の類型です。強いのは、あとから変えることを前提に作れること。アプリは作った瞬間がいちばん単純で、そのあと必ず複雑になります。5年後に触れる状態で残っているかどうかは、最初の設計で決まります。弱いのは、そもそも何を作るかが決まっていない段階です。設計の力は、対象が定まってから効きます。

Thoughtworks

公式ディスクリプション:「We are laser-focused on transforming your digital journey so you can make extraordinary impact.」。訳すと、お客様のデジタルの旅の変革に集中し、並外れたインパクトを生み出す。『リファクタリング』の著者マーティン・ファウラーが、Chief Scientist（最高科学責任者）として在籍しています。ファウラーは2001年の「アジャイルソフトウェア開発宣言」の起草者の1人です。

EPAM Systems

公式ディスクリプション:「Since 1993, we’ve helped customers digitally transform their businesses through our unique blend of world-class software engineering, design and consulting services.」。訳すと、1993年以来、世界水準のソフトウェアエンジニアリングとデザインとコンサルティングの組み合わせで顧客のデジタル変革を支援してきた。米国企業で、東欧に大きな開発拠点を持ちます。

Globant

アルゼンチン発のソフトウェア専業で、他社の製品開発を丸ごと引き受ける点は上の2社と同じです（公式サイトは自動アクセスを遮断する設定のため、スクリーンショットは掲載していません）。

3社に共通するのは、エンジニアリングという言葉を会社の名乗りの中心に置いていることです。A類型が「変革」を名乗るのに対し、この類型は「作る技術」を名乗ります。打ち合わせで「このデータの持ち方は、3年後に足かせになります」という指摘が出たら、この類型が重視する視点です。

⑦ C. デザイン起点型 ── 使われる形にする力

画面の見た目を整える類型ではありません。使う人の行動を調べたうえで、製品の形そのものを決める類型です。強いのは、「動くのに使われない」を防げること。作る前に、使う人の行動を確かめにいきます。提案の冒頭に「まず利用者に10人ほど話を聞かせてください」と置かれたら、この類型です。一方で、主戦場は体験の質なので、大量の実装や運用体制まで同じ体制で担うかは案件によります。

IDEO

公式ディスクリプション:「We envision new businesses and brands, and we design the experiences and capabilities that bring them to life.」。訳すと、新しい事業とブランドを構想し、それを実現する体験と組織能力をデザインする。人間中心設計を広めた米国のデザインファームです。

グッドパッチ

公式ディスクリプション:「新規事業立ち上げやプロダクトのUI/UX改善など、戦略策定〜グロースフェーズまで一気通貫でパートナーとして並走します」。国内で、デザイン会社として初めて上場した企業です。

2社とも、サイトの先頭に製品ではなく人と体験を置いています。UI/UXデザイン会社の比較はUI/UXデザイン会社18社を言葉で解析して3つに分けたで別途行っているので、この類型を検討する場合はあわせて読んでください。

⑧ D. オフショア・ラボ型 ── 単価あたりの投入量

オフショアとは、人件費の安い国の拠点に開発の作業を出すこと。ラボ型とは、その拠点に専任のチームを一定期間まるごと確保しておく契約の形です。強いのは、仕様が確定したあとの量産。画面数が多い、対応端末が多い、多言語が要る。決まっているものを大量に作る場面では、これ以上の解がありません。弱いのは、決まっていない案件です。距離と時差の分だけ1往復にかかる時間が伸びるので、固まる前に投入すると逆に高くつきます。

FPTソフトウェア

公式ディスクリプション:「FPT Software is a global technology solutions provider, headquartered in Vietnam.」。訳すと、ベトナムに本社を置くグローバルテクノロジーソリューション企業。同国最大手のIT企業で、ラボ型契約で世界各国の開発を請け負っています。

見積書が「画面数 × 単価」の形で組まれていたら、この類型が得意な見積もりの組み方です。数えられるものを基準に見積もるため、数えられないもの（決まっていない仕様）が混ざると見積もりが崩れます。オフショア開発の往復の実測はオフショア開発の記事に別途あります。

⑨ E. ローコード／ノーコード型 ── 作らずに済ませる範囲

ローコード／ノーコードとは、プログラムをほとんど書かずに、画面や処理を用意された部品の組み合わせで作れるようにした道具のことです。強いのは、作る前に「作らなくて済む範囲」を確かめられること。標準機能で動く部分を先に動かし、足りない部分だけを作る順番が取れます。弱いのは、標準から外れた瞬間です。自社にしかない業務はたいてい標準機能の外側にあり、外側の部分は結局ふつうに作ることになります。そのうえで、道具そのものの利用料は使い続けるかぎり毎年かかります。

この分野の評価としてよく参照されるのが、米国の調査会社ガートナー（Gartner）が毎年出す「マジック・クアドラント」です。企業向けローコード基盤の2025年版では、OutSystems、Mendix、Microsoft Power Apps を含む6社が「リーダー」に入りました。OutSystems と Mendix は、いずれも9年連続です。

OutSystems

公式ディスクリプション:「OutSystems combines a low-code foundation with AI-driven software development to deliver enterprise-grade applications.」。訳すと、ローコード基盤とAI駆動のソフトウェア開発を組み合わせ、エンタープライズ級のアプリケーションを提供する。サイトは同意設定の画面が常時表示されるため、スクリーンショットは掲載していません。

Mendix

公式ディスクリプション:「Mendix is the fastest and easiest low-code platform.」。訳すと、最速で最も簡単なローコードプラットフォーム。ドイツの産業機器大手シーメンスの傘下にあります。

Microsoft Power Apps

公式ディスクリプション:「Microsoft Power Apps は、プロセスを効率化し、組織全体の生産性を向上させるカスタムビジネスアプリを作成できるローコードアプリビルダーです」。

提案で「標準機能で8割、作り込みは2割です」と言われたら、残りの2割の中身を確かめてください。その2割が自社にしかない業務かどうかで、総額が変わります。

⑩ F. AI活用の共創型 ── 決める工程に入り、往復を減らす

最後の類型は、この記事の発信元（ARCHECO）が属する類型です。贔屓が入る可能性があるので、そのつもりで読んでください。他の類型と同じ条件で、公式サイトの実物とディスクリプションを置きます。

ARCHECO

公式ディスクリプション:「ARCHECOは新規事業コンサルティングと生成AI導入支援を軸に、AIエージェント開発・UX/UIデザインまで統合的に提供。戦略設計からプロダクト開発まで、ビジネスの成長を支援します」。

この類型は、発注する側の企業と組んで、業務の中身を決めるところから入り、動くところまで一緒に作ります。強い軸は決まるまでの往復を短くすること。1往復あたりの日数を縮めるのではなく、往復そのものの回数を減らします。やり方は3つです。第一に、決まっていない項目の質問を着手前に出し切ること。第二に、決めていない項目を、AIで作った動く画面にして見せること。発信元の記録では、画面を1日で12枚作って見せる速度が出ており、文章で往復するより判断が速く正確になります。第三に、決まった範囲から作り始めて、残りは動くものを見ながら決めること。

噛み合わないのは、仕様が完全に決まりきった大規模案件の量産です。それはA類型かD類型の土俵で、この類型が入る余地はあまりありません。

⑪ 立場によって、最初に見る類型が変わります

止められない基幹業務に載せる ── A類型から。統制の費用は保険料と考えます
長く育てる自社プロダクトを作る ── B類型から。設計の質は後から買えません
使われるかどうかが不安 ── C類型から。作る前に行動を確かめます
仕様書が既にあり、量が多い ── D類型から。単価あたりの投入量で選びます
標準的な業務で、早く動かしたい ── E類型から。作らない範囲を先に確かめます
何を作るか自体がまだ決まっていない ── F類型から。決める工程を一緒にやります

①で見た362回と25回の差の大半は、発注前のこの確認で防げます。どの類型でも、見積書を受け取ったら最初に確かめることは同じです。「要件定義の工数が、この金額に入っているか」。 入っていないなら、何回の打ち合わせを想定し、超えたときどう精算するかまで聞く。即答できる相手は、往復の見込みを持って値付けをしています。

まとめ ── 相場表ではなく、名乗りと往復で選ぶ

IPAの5,546プロジェクトの実測では、真ん中の半分だけを取り出しても工数に6.6倍の開きがありました。JUASの調査では、いちばん小さい規模でも予定どおり終わるのは3件に1件です。この現実の前では、「アプリ開発の相場は◯◯万円」という1行は、ほとんど意味を持ちません。

代わりに使えるのが、この記事で並べた2つの一次情報です。各社が公式サイトで名乗っている言葉は、その会社がどの類型で戦っているかを正直に映します。そして決まっていない量をどう扱うかが、最終的な費用を決めます。相場表を探すより、自社の案件の「決まっていない量」を数えるほうが、見積もりのぶれは確実に小さくなります。

よくある質問

Q. アプリ開発の費用の相場はいくらですか？ A. 一律の相場は存在しません。IPAの5,546プロジェクトの実測で、極端な案件を除いた真ん中の半分だけでも工数に6.6倍の開きがあります。相場表の1行より、発注先の類型と「決まっていない量」で見積もりの前提を揃えるほうが、比較として機能します。

Q. 見積もりが安い会社を選んではいけませんか？ A. 安さ自体は問題ではありません。ただ、確かめるべきは、その金額に要件定義（作る機能や条件を決める工程）が入っているかです。入っていない見積もりは、決まるまでの往復が始まった時点で膨らみます。

Q. オフショア開発は結局安いのですか？ A. 仕様が確定している案件なら、単価あたりの投入量で他の類型より安くなります。仕様が固まっていない案件では、距離と時差のぶん往復が高くつき、逆転することがあります。

Q. ローコードで作れば開発会社は不要になりますか？ A. 標準機能の範囲なら大きく減らせます。ただし自社にしかない業務はたいてい標準の外側にあり、そこは結局作ることになります。また、道具の利用料は使い続けるかぎり毎年かかるので、総費用は数年単位で比べてください。