アプリ開発の費用は画面数で決めてよい？共通部品・状態・権限で工数を確認する

アプリ開発の費用が「画面数20、1画面あたり◯万円」という形で提示されたとき、経営側が困るのは単価の高さではありません。その「20」が何を数えた20なのかが、見積書のどこにも書かれていないことです。同じアプリを2社に頼めば、片方は18画面、もう片方は34画面と書いてきます。数が違うのに、どちらも間違いではありません。

この記事は、画面数連動の見積書を読み解くための手順書です。「画面数で費用を決めるのは誤りだ」とは書きません。画面単価は実務で使われている見積もり手法であり、業界団体の研究会成果物にも手法の具体例として明記されています。ただし成立する条件があります。その条件を、公開されている一次資料の側から具体的に示します。

TL;DR｜画面数で費用を決めてよいのは、条件がそろったときだけ

• 「画面数課金はおかしい」という結論から入らないでください。 一般社団法人 日本情報システム・ユーザー協会（JUAS）の研究会成果物には、概算・詳細の両フェーズの見積もり手法の具体例として「画面×単価」が明記されています。画面単価は実在する正規の手法です
• 問題は、画面単価が使われる段階と、見積書に書かれている精度が合っていないことです。 同資料は見積もりを3フェーズに分け、超概算の精度目安を-50%〜+100%、詳細見積もりを-5%〜+15%としています。同じ「画面×単価」でも、機能一覧しかない段階の数字と、画面ごとの仕様を決めた後の数字では、意味がまったく違います
• 1画面の裏には、合意すべき仕様の束があります。 IPA（独立行政法人情報処理推進機構）の画面設計ガイドは、画面設計で合意すべき「工程成果物」を6種類定義し、そのうち3種類は画面ごとに作ります。画面ごとに作る1つ、画面入出力項目一覧だけで記述欄が15項目あります。画面という単位は、それ自体が中身の見えない箱です
• 画面数に比例して増える作業も、確かに存在します。 Googleが公開しているAndroidアプリの品質テストには、「From each app screen（アプリの各画面から）」という書き出しで始まるテストが4件あります。画面ごとに実施する検証は、点数がそのまま作業量になります
• 画面単価が成立するのは、共通ルールが先に決まっている、1画面あたりの想定工数が数字で示されているなど、5つの条件が揃ったときです。 逆に、共通ルールが未定のまま画面数だけが確定している見積書は、単価の高低ではなく前提の欠落を疑う対象になります
• 判断の型は4つです。説明済み／要確認／高リスク／判断不能。「高い・安い」で仕分けないでください

見積書の行を分解する具体的な観点は、開発見積書のAIレビュー（登録不要）でも確認できます。

「20画面」という数字は、数え方で変わる

最初に確認すべきなのは単価ではなく、分母です。画面数は客観的な数値に見えますが、実際には数え方のルールを決めて初めて確定する数字です。

画面一覧の行が、そのまま画面数になる

IPAのソフトウェア・エンジニアリング・センター（IPA/SEC）が2010年3月31日に公開した「機能要件の合意形成ガイド(ver.1.0) 分冊３ 画面編」は、画面設計で作る図表のひとつとして「画面一覧」を定義しています。その構成要素の1番目、項番2.1には次のように書かれています。

No. 画面一覧の通し番号（行番号）。本項目によって画面数を把握できる。

つまり画面数とは、画面一覧というExcel表の行数のことです。行の作り方が変われば、数も変わります。

同ガイドはこの点を、わざわざ独立した「コツ」として立てています。コツID 03D104「画面一覧が持つべき、画面の一覧性を活用し見やすくするには」の施策は、「一行」＝「一画面」となるように記述する、というものです。メリットとして挙げられているのは次の記述です。

発注者および開発者にとって、画面を識別する情報（画面名や、画面ＩＤ）が一列に並ぶことにより、全体把握がしやすくなる。行数が画面数に一致するため、画面数のカウントなども容易になる。

そして「×望ましくない例」として、機能名の行と画面の行が混ざった表が示され、こう説明されています。

画面－機能の階層表示を行うなど、画面以外の要素による行定義を行うと、画面一覧が持つ、画面の一覧性が阻害される。

わざわざコツとして書かれているということは、実務では「一行＝一画面」になっていない画面一覧が普通に存在するということです。ベンダーが提示した画面数が、機能グループの見出し行を含んでいるのか、含んでいないのかで、数字は簡単に変わります。

数える前に、書面で確定させること

見積書の「画面数◯」を受け取ったら、単価の議論に入る前に、次を書面で確定させてください。上4つはIPAの同ガイドが構成要素または合意形成のコツとして扱っている項目、最後の1つはスマートフォンアプリ固有の論点です。なお同ガイドのコツのうち、表に挙げた03T004・03T005は「発注者が〜する」という書き方で、発注側の作業として記述されています（第３部「１．言い切る／聞き切るためのコツ」）。ベンダーへの要求ではなく、発注側が先に決めておく事項として読んでください。

最後の行は、アプリの見積書で最初に割れる論点です。 見積書に「画面実装（iOS/Android） 20画面」とだけ書かれているとき、20が両OS合計なのか片OSあたりなのかで、実装対象の枚数は20と40に分かれます。片OSぶんの数字であれば、次に「もう一方のOSへ横展開する分は何割で見ているか」を聞いてください。共通化の度合いは案件によって大きく違うため、2倍とも1.2倍とも決めつけないことです。

4つ目の「分類」も重要です。原典は、分類を記入する理由を「後で画面の共通化を検討するために」と明記しています。分類が付いていない画面一覧は、そもそも共通化の検討をしていない画面一覧です。それに一律単価を掛けた金額は、共通化による削減余地を織り込んでいません。

なお同ガイドはコツ03D103として「画面数が多くなる場合に、画面の重複および抜けもれを防ぐには」という項目も立てており、施策は「メニュー階層別、分類別、機能別等に画面一覧を分割し、分類した項目で並べ替えをする」です。画面数が多い案件では、重複と抜け漏れが起きる前提で設計されているということです。

見積書では、どう書かれているか

画面数連動の見積書は、おおむね次のような書かれ方をします。典型的な書式を本記事で再構成したもので、特定の見積書を引用したものではありません。

この書式の何が問題かというと、画面数という数量が入っている行が1行しかないことです。画面数は本来、設計・実装・テスト・レビューのそれぞれに違う効き方をします。それが「画面実装」の1行にだけ現れていると、次のどちらなのかが判定できません。

• 設計とテストは画面数と無関係に一式で見ている（＝画面が増えても設計とテストは増えないという前提）
• 設計とテストの画面数ぶんの工数を、「一式」の中に暗黙で含めている（＝画面が減っても一式の金額は下がらない）

前者なら、画面が増えたときにテスト費が後から追加されます。後者なら、画面を減らしても総額はほとんど下がりません。どちらも発注側にとっては望ましくない挙動ですが、見積書の見た目からは区別できません。この1点だけでも、確認する価値があります。

もうひとつよく見る書式が、「画面数◯〜◯の場合 ◯◯万円」という段階料金です。この場合は、段階の境目でなぜ金額が変わるのかを聞いてください。境目の理由が「画面が5枚増えるから」であれば単なる比例の刻みですが、「その規模から画面遷移の管理方式を変えるから」であれば、それは後述の「階段状に効く費用」で扱うコストであり、根拠のある段階です。

見積もりのどの段階なら、画面×単価が使われるのか

ここが、この記事でいちばん伝えたい部分です。画面単価は正規の見積もり手法ですが、使われる段階によって、期待してよい精度がまったく違います。

一般社団法人 日本情報システム・ユーザー協会（JUAS）の「システム開発・保守QCDs研究会2025」成果物（2026年4月9日公開）の分科会①は、見積もりを3つのフェーズに分け、それぞれの手法と精度目安を整理しています。同資料の該当箇所を、画面数に関わる部分だけ抜き出すと次のようになります。

3つの見積もりフェーズと、そこでの画面数の扱い

表に出てくる手法名は、次の意味で使われています。パラメトリックは、画面数などの数量に工数の係数を掛けて全体規模を出す方法です。ボトムアップは、作業を細かく分けて一つずつ積み上げる方法です。前者は数量さえ決まれば早く出せますが、係数の当てはまり具合で精度が決まります。

なお、この精度目安はJUASが実測した誤差率ではありません。同資料の参考資料に収録された「■Copilotによる評価」が、PMBOK・ISO21500の一般値として示し、本編のシートへ反映された数値です（出所の詳細は末尾の根拠資料と適用条件に記載しました）。プロジェクトマネジメントの標準的な文献における一般値として読んでください。日本のアプリ開発案件を集計した統計ではありません。それでも、超概算と詳細見積もりで期待できる精度が桁違いに違うという構造そのものは、見積書を読むうえで有効です。

この表から読み取れることは3つあります。

1つ目。画面×単価は、超概算だけの手法ではありません。 概算にも詳細にも登場します。「画面単価で出しているから雑な見積もりだ」とは言えません。

2つ目。同じ画面×単価でも、詳細見積もりでは三点見積によるリスク調整が併用されています。 同資料は三点見積の期待値の式を「期待値=(楽観+4×再可能＋悲観)÷６」と記載しています（「再可能」は原文の表記で、同じシートの具体例欄および参考01の記述では「最可能」となっています）。つまり詳細フェーズの画面単価は、画面あたりの工数を楽観値と悲観値の幅で押さえたうえで期待値を取る、という前提です。この調整が入っていない画面単価は、詳細見積もりの精度を名乗れません。同資料は詳細見積もりのボトムアップ見積の「理由」欄に、端的に「リスクを織り込まないと遅延」と書いています。

3つ目。詳細見積もりのレビュー観点として、「1画面PGが上級者基準か確認」が挙げられています。 誰が作る前提の1画面なのか、で単価は変わるということです。上級者を前提にした工数係数で見積もり、実際には経験の浅い担当者が実装すれば、そのぶん期間が伸びます。

そして、同資料のまとめには次の実務アクションが書かれています（ROMは Rough Order of Magnitude の略で、要件が固まる前のごく初期の概算段階を指します）。

ROM段階でも「機能リスト（ハイレベル）」を作成し、機能ごとに代表的な工数係数を適用する（例：画面×◯人日、帳票×◯人日）。不明点には必ず「不確実性フラグ」を付け、見積もりレンジに反映する。

画面×人日の係数を使うこと自体は推奨されています。 ただし同時に、不明点への不確実性フラグとレンジ反映がセットになっています。画面数に単価を掛けた1つの数字だけが出ていて、レンジも不確実性の記載もない見積書は、この手順の後半が落ちている状態です。

1画面の裏に、いくつの状態があるか

画面という単位が扱いにくいのは、それが中身の量を表さない単位だからです。ここは公開資料で具体的に確認できます。

外部設計で合意する成果物は6種類、うち3種類は画面ごとに作る

IPAの前掲ガイド（画面編）は、画面について発注者と開発者が合意するために作る「工程成果物」を6種類定義しています。このうち画面レイアウト・画面入出力項目一覧・画面アクション明細の3種類は、書誌情報に画面IDを持ち、画面ごとに作成します。画面一覧はシステム全体で1つ、共通ルールは「個別画面に依らず」定めるものです。

それぞれの「構成要素」欄に並ぶ記述項目の数を、原典から数えると次のとおりです（各表の「2.構成要素」に列挙された項番のみを数えており、全表に共通する「0.共通情報」「1.書誌情報」は含めていません）。

いちばん重い画面入出力項目一覧の15項目は、識別ID／表示用のラベル／部品の種類／有効／入力／表示桁数／入力桁数／データ型／文字種／入力制約／初期表示有無／初期表示内容／出力仕様／必須／補足です。画面に入力欄を1つ置くだけで、外部設計として決めるべき欄が15あるということです。同ガイドは画面レイアウトに配置する画面部品の種類も10種類（テキストボックス、リストボックス、コンボボックス、チェックボックス、ラジオボタン、ボタン、ラベル、罫線、表、画像）挙げています。

見積書に「画面 20」とだけ書かれているとき、この20という数字は、入力欄が3つの画面も、入力欄が40ある画面も、同じ1として数えています。

「ログイン画面」という1画面の中身

同ガイドの画面アクション明細には、表記例が載っています。対象は画面ID「S-05-01」の「ユーザログイン画面」、つまり画面一覧では1行を占める1画面です。そこに定義されているアクションは2つ（ログイン／ユーザ登録）で、ログイン側の「アクションの処理詳細」は次のように分岐します。

1. UsernameとPasswordの入力チェック
2. 検索処理（顧客情報テーブルから該当するユーザを検索する）
3. 検索結果に応じた分岐
   • 合致するデータが存在した場合 → ペットストアポータル画面(S-00-01)に遷移する
   • 合致するデータが存在しなかった場合 → エラーメッセージを表示する

教科書的な最小構成のログイン画面ですら、3ステップの処理と、その最後の正常系・異常系の2分岐を持っています。 実際のアプリのログイン画面には、これに加えてパスワード再設定、生体認証、SNS連携、通信失敗、アカウントロック、初回起動時の同意取得などが乗ります。画面一覧では、それでも1行です。

画面遷移の構成要素にも、項番2.11として「異常系」が定義されています。記述内容の説明は「例外処理等の正常系処理を実行できない場合の処理方法を記述する」です。異常系は、後から出てくるおまけではなく、外部設計の合意事項として最初から想定されています。

ローディング・空・エラー・権限別

経営判断のために覚えておくべきなのは、次の構造です。1画面の工数は、その画面が取りうる状態の数でおおむね決まります。

読み込み中について、Apple「Human Interface Guidelines」のLoadingは「Show something as soon as possible（できるだけ早く何かを表示する）」とし、読み込み中に見せるプレースホルダーのテキスト・図版・アニメーションの検討を挙げています。進捗表示は、所要時間がわかる場合とわからない場合で使う部品が異なります。エラー表示については、IPAガイドの共通ルール 構成要素2.6「エラー表示方法、エラーメッセージ」が「メッセージの可変部と固定部の配置」まで合意対象にしています。「あとで足す」ものではなく、外部設計で決める対象です。 一方でデータが0件のときの表示は、同ガイドに直接対応する構成要素がありません。合意事項として明示されにくいぶん、見積書からも落ちやすい項目です。

権限別の扱いは、見積書でもっとも見落とされます。IPAガイドの画面入出力項目一覧は、部品ごとに「有効」（○常に有効／△条件つきで入力可／×常に無効／－対象外）と「入力」（○常に入力、選択可／△条件つきで入力、選択可／×常に読取専用／－対象外）を記述させます。この「△：条件つき」が付いた部品の数だけ、条件の定義と、条件ごとの表示確認が発生します。

管理者・一般利用者・未ログインの3ロールがある画面は、画面一覧では1行ですが、実装と確認では3通りの見え方を持ちます。ロールが5つに増えれば5通りです。画面数は変わらないのに工数は増える、という現象はここから来ます。

端末設定でも、同じ1画面が何通りにもなる

状態表の最後の行について補足します。スマートフォンアプリ特有の増え方があります。利用者の端末設定によって、同じ画面が複数の見え方をするという点です。ここもプラットフォーム提供元の公開資料で数えられます。

AppleのHuman Interface Guidelinesのタイポグラフィの仕様表（2026年8月25日取得）によると、iOS・iPadOSの文字サイズ設定は次の2群に分かれています。

• Dynamic Type sizes：xSmall／Small／Medium／Large（既定値）／xLarge／xxLarge／xxxLarge の7段階
• larger accessibility type sizes：AX1／AX2／AX3／AX4／AX5 の5段階

合わせて12段階です。アクセシビリティの項では「Ideally, give people the option to enlarge text by at least 200 percent（理想としては、文字を少なくとも200%まで拡大できる選択肢を提供する）」（watchOSアプリでは140%）とされています。文字が2倍になれば、1画面に収まっていた要素は収まらなくなります。

さらにダークモードについて、同ガイドラインは次のように書いています。

Ensure that your app looks good in both appearance modes.（明暗どちらの表示モードでもアプリの見た目が良好であることを確認する）

そして検証の例として、ダークモードで「Increase Contrast」と「Reduce Transparency」を有効にした状態を、both separately and together（それぞれ単独でも、両方同時にも）試したときに見つかる問題を挙げています（原文は「For example」で始まる例示です）。

これを掛け合わせると、1つの画面に対して明暗2×文字サイズ12＝24通りの見え方があり、そこにコントラストと透明度の設定の組み合わせが重なります（この掛け算は本記事による組み合わせ計算で、Appleが示している数字ではありません）。すべてを個別に実装するわけではありませんが、確認の手間は画面数に比例して増えます。

同ガイドラインは、独自の外し方も用意しています。「In rare cases, consider using only a dark appearance in the interface（まれなケースでは、インターフェースをダークな外観のみにすることを検討する）」——没入型のメディア視聴アプリなどが例として挙げられています。逆に「Avoid offering an app-specific appearance setting（アプリ独自の外観設定を提供することは避ける）」とも明記されており、アプリ側に独自のテーマ切り替えを付けるのは推奨されていません。

見積書に「ダークモード対応」「アクセシビリティ対応」の行が無い場合、それが対応しないという合意なのか、画面単価に含まれているつもりなのかを確認してください。前者なら発注側の判断として記録すればよく、後者なら、後から表示崩れの修正費として現れます。

画面数に比例してよい費用｜画面ごとに繰り返す検証

ここまで「画面という単位は中身を表さない」と書いてきましたが、画面数がそのまま作業量になる領域も実在します。画面の実装そのものが枚数に比例するのは当然として、見落とされやすいのはその後ろ側、テストと検証です。

Googleが公開しているAndroidの「Core app quality guidelines」（2026年8月21日 UTC 更新、2026年8月25日取得）は、後半に「Tests」というセクションを持ち、テストIDが付いた検証項目を64件定義しています。このうち、記述が「From each app screen（アプリの各画面から）」で始まるものが4件あります。

加えてT-Consistent_UXは、対象範囲を次のように指示しています。

Navigate to all parts of the app—all screens, dialogs, settings, and all user flows. （アプリのすべての部分——すべての画面、ダイアログ、設定、すべてのユーザーフロー——に移動する）

そのうえで、テスト中に通知や着信などの割り込みを入れること、ネットワーク接続やバッテリー、GPSの可用性、システム負荷といった端末の状態を変化させることを求めています。T-Theme_Supportは、明暗どちらのテーマでもすべてのテキストが読めることの確認を求めています（原文：Verify that all text is readable in light and dark themes.）。

つまりGoogle自身が、画面ごとに繰り返す検証項目を公開しています。 画面が20から40に増えれば、これらの検証工数はおおむね2倍になります。ベンダーが「テストは画面数に比例する」と説明してきた場合、それは根拠のある主張です。

逆に言えば、画面数連動の見積書でテストが「一式」1行になっているのは、説明の粒度が合っていません。画面数に本当に比例するのは実装よりむしろこちら側だからです。

画面数に比例しない費用｜1回作れば全画面から使われる

一方で、画面数が増えても基本的に増えない費目があります。これらが画面単価の中に溶け込んでいると、画面を減らしたときに減るはずのない金額まで減った見積書が出てきて、後から不足します。

APIの見積もりは、それ自体が別の数量課金の論点になります。API連携の開発費用では、「1本いくら」という本数課金を作業へ分解する手順を扱っています。

階段状に効く費用｜ある枚数を越えると作り方が変わる

3つ目の型が、いちばん見えにくく、いちばん金額が跳ねます。画面数に比例もしないし無関係でもなく、ある枚数を越えたところで一段上がる費用です。

跳ねる原因は主に2つあります。画面同士の行き来の経路と、画面をまたいで持ち回るデータです。後者は、ログイン状態、入力途中の内容、検索条件、カートの中身といったもので、画面が増えるほど「どの画面がどのデータを持ち、いつ捨てるのか」が絡み合います。枚数が少ないうちは、必要になるたび場当たりに書き足しても動きます。ある枚数を越えると、その作り方が破綻し、経路とデータの管理方式を入れ直す作業が必要になります。ここが階段です。

この2つが、次の3つの場面で表面化します。

「画面が増えたので比例して上がりました」という説明と、「この枚数から作り方を変えるので上がりました」という説明は、まったく別のものです。 後者であれば、境目の手前で画面を止めるという選択肢が発注側に生まれます。前者だと思い込んでいると、その選択肢に気づけません。

段階料金の見積書を受け取ったときは、段階の境目がどこにあり、境目でなぜ作り方が変わるのかを聞いてください。答えが「そのあたりから工数が増えるので」だけであれば、それは階段の説明ではなく、比例の刻みに階段の見た目を付けただけです。

なお、何枚で階段が来るかに一般的な目安はありません。本記事の調査では、画面数と設計方式の切り替え点を示した公開データを確認できませんでした。 枚数は、アプリの種類・チームの標準・採用技術によって変わります。だからこそ、境目の位置はベンダーごとに聞く必要があります。

見積書の画面行を3分類する早見表

ここまでの内容を、見積書の各行を仕分けるための表にまとめます。見積書全体で「比例する／しない」を決めるのではなく、行ごとに3つのどれかへ入れてください。

3つが混ざった1行が、いちばん読めない行です。 「アプリ開発一式」や「画面実装 20画面」の中にA・B・Cが同居していると、画面を1枚減らしたときに何がいくら下がるのかを、発注側も受注側も答えられません。

画面単価が成立する条件

以上を踏まえると、画面単価が妥当な見積もり方法として機能する条件を、具体的に書けます。次の5つが揃っているときです。

条件1：共通ルールが先に決まっている。 IPAガイドのコツ03D600は「個別画面に依らず、共通して合意すべきことは、画面レイアウト共通ルールとして定義する」であり、そのメリットとして「開発者にとって、品質、生産性、保守性の向上に寄与する」「発注者および開発者にとって、レビュの時間を短縮できる」を挙げています（「レビュ」は原文の表記）。共通ルールの構成要素は8項目——ページの構成要素／配色／文字フォント・サイズ／全体構造とナビゲーション／画面遷移パターン／エラー表示方法・エラーメッセージ／ユーザの定義／制約事項——です。この8項目が決まっていれば、個別画面ごとに議論する量が減り、1画面あたりの工数がばらつきにくくなります。

条件2：画面が分類され、同一分類の中で単価が設定されている。 画面一覧の構成要素2.4「分類」は、メニュー・入力フォーム・一覧表示といった種類を記入する欄で、記入する理由は「後で画面の共通化を検討するため」と明記されています。分類ごとに違う単価が付いている見積書は、共通化を検討した形跡がある見積書です。 全画面が単一単価の見積書は、その検討をしていない可能性があります。

条件3：画面ごとの状態数が単純で、そのことが合意されている。 権限が1種類、通信が同期的、エラー処理が共通ルールに収まっている画面群であれば、画面あたりの工数は安定します。逆に、権限別表示・オフライン対応・リアルタイム更新のいずれかが入る画面が混ざっている場合、その画面だけは単価から外して個別に見積もるのが自然です。

条件4：同じ画面の定義で、実績データを持っている。 JUASの資料は、見積もりが上手くいかない原因の分類のひとつに「実績データ・見積手法関連」を挙げ、その例として「類似案件実績がない／蓄積不足」「パラメトリックや指標の未整備」「見積基準がバラバラ」を並べています。画面単価は、そのベンダーが同種のアプリを何本か作った実績の上でだけ意味を持ちます。 初めて作る種類のアプリに、他分野の実績から持ってきた画面単価を当てるのは、係数の流用です。

条件5：1画面あたりの想定工数が、数字で示されている。 JUASの資料でも、詳細見積もりシートへの改善提案として「WBSレベルの統一基準の例示がほしい」「例：『1画面＝何時間が標準なのか』」「これを定義しないと属人化リスクが残る」という指摘が挙げられています（参考01のCopilotによる評価コメント内の記述で、JUASが標準時間を示しているわけではありません）。単価だけがあって、その裏の想定時間が無い状態は、属人化した見積もりです。 「1画面◯万円」の内訳が「◯人日×◯円」まで示されていれば、担当者が変わっても検証できます。

この5条件が揃っているなら、画面単価は発注側にとってむしろ扱いやすい見積もりです。画面を1つ減らせば金額がいくら下がるかが事前にわかり、スコープ調整の判断が速くなります。

4状態への仕分け｜説明済み／要確認／高リスク／判断不能

受け取った見積書を、金額の高低ではなく説明の状態で仕分けます。

「高い」「安い」で仕分けないでください。 適正な設計・品質・責任範囲には相応の費用がかかります。判定すべきなのは、その費用が何と結びついているかが説明されているかどうかです。

「画面数が多いのに安い」見積書のほうが危ないことがある

数量課金の記事で見落とされがちなのが、過大見積もりではなく過小見積もりの側です。JUASの資料は、見積もりリスクを過大・過小の両方向で整理し、過小見積もりのリスクとして次を挙げています。

• 品質面：テスト不足・手戻り増加で品質低下、顧客クレーム増加
• コスト面：追加コスト発生（追加人員・残業・外注）、利益圧迫
• 納期面：納期遅延や納品失敗、契約違反によるペナルティ
• 経営・対外面：信頼喪失

（過大見積もりの側も同様に整理されており、「過剰品質や不必要なプロセス導入で効率低下（無駄な作業）」「競争力低下による受注喪失」などが挙げられています。この資料は、見積もりを作る側の視点で書かれています。）

画面数が多い案件で、次の行が見積書に無い場合は、削られた側になっている可能性があります。

1. 画面ごとの検証：前掲のAndroid各画面テスト4件に相当する作業。画面数に比例するはずの費目が「テスト一式」に丸まっていないか
2. 表示バリエーションの確認：明暗テーマ、文字サイズ拡大、端末サイズ違い。iOSでは文字サイズ設定が12段階あります
3. 異常系の実装：通信失敗、権限不足、データ0件。IPAガイドが「異常系」として外部設計の合意事項に含めているもの
4. プロジェクト管理：画面数に連動しませんが、画面が増えるほど並行作業と関係者が増え、必要な調整量は増えます

削られていること自体が悪いわけではありません。 発注側が「初回リリースではダークモード対応をしない」と決めたなら、それは合理的な判断です。問題は、決めたのか漏れたのかが記録に残っていないことです。決めたなら見積書の対象外欄に書いてもらい、漏れているなら追加してもらってください。

同じ「20画面」でも、見積書はここまで違う

架空の2社の見積書を、同じアプリ（会員制の予約アプリ、画面数20）に対して並べます。金額は伏せ、構造だけを比較します。

A社の総額がB社より高くても、A社のほうが判断できる見積書です。 A社は画面を減らしたときにいくら下がるかが計算でき、対象外にした範囲も記録に残ります。B社は、画面を減らしても総額がどう動くかわからず、ダークモードや権限別表示が含まれているかも不明です。

比較の場では、総額ではなく「同じ前提に揃えたときの差額」を見てください。 前提を揃える作業そのものが、発注側にとっての一次成果物になります。複数社の見積もりを同じ条件へそろえて確認する手順は、開発費用の相場と見積もり妥当性の判断でも扱っています。

ベンダーへそのまま送れる確認質問10

ここからはコピーして使える部分です。文面はそのまま送れる形にしてあります。10問すべては多いという場合は、1・2・4・6・10の5問に絞ってください。 この5問で、数え方・OSの数え上げ・状態・比例と非比例の分離・増減の効き方という骨格が埋まります。

依頼メールの文面

件名：アプリ開発お見積もりについての確認（画面数まわり）

株式会社◯◯
◯◯様

お世話になっております。◯◯株式会社の◯◯です。

お見積もりをありがとうございます。社内で予算の承認を得るにあたり、
画面数に連動している費用の根拠を確認させてください。
金額の値下げをお願いする趣旨ではなく、画面数を調整した場合に
何がどれだけ変わるのかを、社内で説明できるようにするためです。

お手数ですが、下記10点について書面でご回答いただけますでしょうか。
現時点で確定していない項目は「未確定」とご記載いただければ、
そのまま前提条件として扱います。

確認質問10（コピペしてそのまま使えます）

1. 見積書の「画面数◯」は、何を1と数えた数字でしょうか。 画面一覧をご提供いただけますか。ポップアップやダイアログ、モーダルシートは画面数に含まれていますか。
2. この画面数は、iOS・Androidの合計でしょうか、片OSあたりでしょうか。 片OSあたりの場合、もう一方のOSへ横展開する分は何割で見込んでいますか。
3. 画面ごとの単価は一律でしょうか、条件によって変わるでしょうか。 新規作成・既存画面の改修・変更なしの内訳と、画面の種類（メニュー／一覧表示／入力フォーム／情報表示／完了通知など）ごとの単価差を教えてください。一律の場合は、その理由もお願いします。
4. 画面単価には、読み込み中・データ0件・エラーの各状態の実装が含まれていますか。 含まれる場合、1画面あたり何状態を想定していますか。
5. 利用者の権限（ロール）は何種類を想定していますか。 権限によって表示や操作が変わる画面は何画面あり、その差分は画面単価に含まれていますか。
6. 画面数に比例して増える費用と、画面数によらず一定の費用を、見積書上で分けていただけますか。 具体的には、共通ルール・デザインの整備、認証や通知の基盤、サーバーサイドとAPI、ストア申請、プロジェクト管理の扱いを教えてください。
7. テスト費用は画面数に連動していますか。 各画面での回転・戻る操作・状態保持・他アプリからの復帰といった確認は、どの行に含まれていますか。
8. ダークテーマへの対応、文字サイズ拡大時のレイアウト確認は対象に含まれますか。 含まない場合は、対象外として見積書に明記していただけますか。
9. この見積もりは、どの段階の見積もりでしょうか。 概算であれば想定している誤差の幅を、確定見積もりであれば工数の根拠（画面ごとの工数表など）を教えてください。
10. 画面を5画面減らした場合と、5画面増やした場合、金額はそれぞれいくら変わりますか。 増減で単価が変わる境目（この枚数を越えると作り方が変わる、といった点）があれば、その位置も教えてください。

回答をどう読むか

• 1・3に即答が返る：画面一覧が既にあり、分類と内訳を管理している。説明済みの可能性が高い
• 2で「合計です」とだけ返る：横展開の割合が示されなければ要確認。片OS実装後の作業をどう見込んだのかを聞く
• 4・5に「含まれています」とだけ返る：状態数とロール数が明示されていなければ要確認のまま。数を書いてもらう
• 6でテストと共通基盤が「一式に含む」とだけ返る：画面を減らしても金額が下がらない構造。要確認。減額シミュレーションを求める
• 9で誤差の幅も工数根拠も出ない：確定見積もりを名乗れる状態ではない。契約前に高リスクとして扱う
• 10で「5画面減らしても総額は変わりません」と返る：画面単価が実質的に総額の割り付けになっている。要確認。何が下がらないのかを行単位で示してもらう
• 10で境目の位置が示される：階段を把握している見積もりです。説明済みの可能性が高く、境目の手前でスコープを止めるという選択肢も検討できます
• 「その粒度では出せない」と返る：直ちに問題ではありません。要件が固まっていない段階なら妥当な回答です。その場合は、確定見積もりへ移行する条件と時期を書面にしてもらってください

回答が返ってこない場合も、それ自体が情報です。 画面一覧を出せないということは、画面数の根拠が社内にもない可能性があります。

見積書のどの行を質問へ変換すればよいか整理しきれない場合は、開発見積書を行項目ごとに確認する（登録不要）もご利用ください。結果の閲覧までメールアドレスの入力は不要です。

開発時と稼働後で、画面数の効き方はどう変わるか

最後に、この記事の範囲を明示しておきます。ここまで扱ったのは構築時に一度だけ発生する費用です。稼働後の月額では、画面数の効き方が変わります。

画面数は、開発時よりも稼働後のほうが効きやすい数量です。 OSが更新されるたびに全画面を見直す必要があり、その回数は年単位で発生し続けるからです。保守見積もりで「画面数◯」が根拠として出てきたときは、開発時とは別の基準で読んでください。

画面数だけでなく、商品数・店舗数・利用者数・連携本数でも、同じ「比例する／階段状／連動しない」の構造が現れます。数量で費用が段階的に上がる見積もりの読み方は、数量課金の見方で数量軸をまたいで整理する予定です。商品点数の場合の具体例はECサイトの開発費は商品数で上がるのかにまとめています。

根拠資料と適用条件

本記事で引用した公開情報は次のとおりです。資料や価格は改定されるため、実際の判断では取得日以降の最新情報を各発行元でご確認ください。

各機関・各社が公表した内容と、koromo編集部が整理した確認観点は区別して記載しています。前者は出典と取得日を明示し、後者は「確認観点」として提示しています。

あわせて、次の3点にご注意ください。

アプリの画面単価の「相場」は、本記事では示していません。 画面あたりの金額について、提示条件と除外範囲がセットで公開されている単価表を、本記事の調査では確認できませんでした。検索結果に出てくる画面あたりの金額や1画面あたりの人月の目安は、各社が自社の受注や紹介案件をもとに提示しているもので、公的な相場ではありません。

引用したガイドラインは、それぞれの手法や事業者を推奨するものではありません。 1画面という単位の裏に何があるかを示すために引用しています。

IPAの画面設計ガイドと、スマートフォンアプリの間には想定のズレがあります。 同ガイドは2010年公開でWebベースの業務アプリケーションを想定しており、タッチ操作、端末の回転や折りたたみ、OSの表示設定といった論点は扱っていません。本記事ではその部分をAppleとGoogleの公開ガイドラインで補っています。この組み合わせ方は本記事による整理であり、いずれかの発行元が推奨しているものではありません。

なお本記事は、法的・会計的・技術的な最終判断を提供するものではありません。契約解釈や費用の会計処理については、それぞれの専門家にご確認ください。

よくある質問