iOSとAndroidの同時開発で費用は2倍になるのか｜見積書を1回・2回・その中間に分ける

「iOSとAndroidの両方を作りたい」と伝えたときに返ってくる見積もりは、会社によって振れ幅が大きくなります。片OSぶんの1.2倍で出てくることもあれば、素直に2倍で出てくることもある。どちらも「間違い」ではありません。問題は、その倍率がどの作業に掛かっているのかが見積書に書かれていないことです。

この記事は、iOSとAndroidの同時開発の費用を「2倍か、そうでないか」で議論するのをやめて、見積書の行を3つに仕分けて判断するための手順書です。OSが2つでも1回で済む作業、OSごとに2回発生する作業、そのどちらでもない作業を分けます。判断の根拠には、AppleとGoogleが公開している審査ガイドライン・ストア費用・OS対応期限を使い、いずれも取得日を明記しました。

TL;DR｜「2倍」も「1.2倍」も、行を分けないと検証できない

• 費用は3つに分かれます。 ①OSが2つでも1回で済むもの（要件定義・サーバーサイド・プロジェクト管理）、②OSごとに2回発生するもの（実機試験・OS固有機能・ストア審査対応）、③その中間（画面の実装とデザイン）。総額の倍率ではなく、この3つの内訳を聞いてください。
• 確実に2倍にならないのは①だけです。 アプリの裏側にあるサーバーやデータベース、要件定義、進行管理はOSの数と関係しません。ここが総額に占める割合が大きい案件ほど、両OS対応の追加分は小さくなります。
• クロスプラットフォームを使っても②は減りません。 1つのコードベースから両OS向けに作る方式でも、実機試験、ストアへの申請、OSアップデートへの追随は2つぶん残ります。iOS向けのビルドにMacが必要な点も変わりません。
• 審査は2つの別々の規約で受けます。 AppleのApp Store Review Guidelinesは5つのセクション構成で、そのうち1つは「Design」です。「デザインは共通だから安く済む」は、審査の観点では半分しか当たりません。
• リリース日は、遅いほうの審査で決まります。 2社が公開している審査時間の数字は統計の性格が違うため速さの比較には使えません。同時公開が要件なら、両方の審査が終わるまで公開できない前提で計画してください。
• 判断は4状態で行います。 高い・安いではなく、説明済み／要確認／高リスク／判断不能のどれかへ仕分けます。記事末尾に、ベンダーへそのまま送れる確認質問9問を置きました。

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

両OS対応のアプリ見積書で、最初につまずくのはこの形です。

2行目の「アプリ開発（iOS/Android）」には、少なくとも3通りの読み方があります。

同じ1行が、3通りに読める

読み方1：iOS向けの開発費とAndroid向けの開発費を足した金額。 それぞれ別々に作る前提です。この場合、片OSだけに絞れば、この行から片方ぶんが丸ごと抜けます。

読み方2：1つのコードベースから両OS向けに作る前提の金額。 クロスプラットフォームと呼ばれる作り方です。片OSに絞っても、この行はあまり下がりません。作るもの自体は1本だからです。

読み方3：片OSを作り、もう一方へ横展開する前提の金額。 「iOSを作ってからAndroidへ移植」といった進め方です。横展開ぶんを何割で見込んだかで金額が変わりますが、その割合は見積書に書かれていないことがほとんどです。

この3つは、見積書の上ではまったく同じ1行になります。 そして、3つのどれなのかによって「片OSに絞ったら、いくら下がりますか」への答えが変わります。読み方1なら半分近く、読み方2ならほとんど下がらない。同じ質問に対する答えが正反対になる以上、この行が3つのどれなのかを確定させないまま金額を比較しても、比較になりません。

2社の見積書が比較不能になる、よくある組み合わせ

1社目が読み方1で書き、2社目が読み方2で書いたとき、総額だけを並べると2社目が安く見えます。しかし、2社目の見積もりに実機試験とストア申請の行が入っていなければ、その差額は作り方の差ではなく含まれている作業の差です。

この記事がやるのは、「アプリ開発一式」をOSの数という軸で分解することです。商品数・画面数・店舗数といった数量が費用に効くかどうかを判断する共通の枠組みは数量課金のシステム費用は妥当かにまとめてあり、OSの数はその枠組みで言えば「試験・検証に効く数量」にあたります。

費用を3つに分ける｜1回で済むもの、2回になるもの、その中間

ここがこの記事の核です。見積書の行を、次の3つのどれかへ入れてください。総額ではなく、行ごとに仕分けます。

A：OSが2つでも、1回で済む作業

• 要件定義・業務フローの整理：何を作るかを決める作業です。OSが2つでも、決めることは1回ぶんです
• 情報設計・画面遷移の骨格：どの情報をどの順で見せるかの設計。OS別の作法の差は後述のCへ入りますが、骨格は共通です
• サーバーサイド・API・データベース：アプリから呼ばれる裏側です。iOS用とAndroid用にサーバーを2つ作ることはありません
• 管理画面（多くはWebで作られます）：運用側が使う画面です。アプリのOSとは無関係です
• プロジェクト管理・進行管理：会議も課題管理も1本です。OSが2つになると管理対象は増えますが、2倍にはなりません
• 受け入れテストの支援・マニュアル・研修：業務としては1回です

この区分が総額に占める割合が大きい案件ほど、「両OS対応」の追加分は小さくなります。 逆に言えば、サーバー側の作り込みがほとんどない単機能アプリでは、Bの比重が上がるため追加分が大きく見えます。「アプリの種類によって倍率が違う」と言われる理由の多くはここにあります。

B：OSごとに、2回発生する作業

• 実機での動作確認（以下、実機試験）：iPhoneでの確認とAndroid端末での確認は、別の作業です。1台で両方は確認できません
• OS固有の機能の実装と確認：プッシュ通知、アプリ内課金、生体認証、位置情報のバックグラウンド取得、権限の確認ダイアログなど。実装の枠組みがOSごとに違います
• ストアへの申請と審査対応：App StoreとGoogle Playは別々の規約で、別々に審査されます（後述）
• ストア掲載物の作成：スクリーンショットの必要サイズ、説明文の文字数、年齢レーティングの回答は、ストアごとに別です
• OSアップデートへの追随：AppleとGoogleが別々の期限で要件を更新します（後述）

クロスプラットフォームを採用しても、このBはほとんど減りません。 ここが、見積もりの比較で最もよく抜ける区分です。

とくに実機試験は、1つのコードベースから作っても2回ぶん残ります。 コードが1本になっても、確認する端末は減らないからです。むしろ、1つのコードベースが2つのOSで同じように動くかを確かめる必要がある分、確認の観点はネイティブ開発より増えることもあります。

見積書に「動作検証 一式」とだけ書かれている場合、確認する端末の台数と機種名、OSバージョンの下限を書面で出してもらってください。 台数が書かれていない検証費は、数量が読めない費用です。同じアプリの見積書でも、アプリ開発の費用は画面数で決めてよい？が扱うのは画面数という軸で、この記事が見るのは台数と回数のほうです。どちらも「掛け算の片方の数が伏せられている」という同じ構造の問題ですが、掛かる数が違います。

C：1回でも2回でもない作業

• 画面のUI実装：ネイティブで別々に作れば2回に近づき、1つのコードベースから作れば1回に近づきます。ただし後者でも、OSごとの表示崩れの調整は残ります
• デザイン：配色・書体・アイコンといった骨格は1回です。一方で、戻る操作の作法、標準的な部品の見た目、画面遷移の慣習はOSごとに異なるため、差分の設計は2回ぶん発生します

Cは「何割で見ているか」を必ず数字で聞いてください。 見積書の中でここだけが、ベンダーの見立てによって1回寄りにも2回寄りにも振れる区分です。

そして、この3つが1行に同居している見積書では、対応OSを変えたときの増減が誰にも計算できません。 「アプリ開発（iOS/Android）一式」を片OSに絞ったら総額がいくら下がるのか、発注側が計算できないだけでなく、受注側も内訳を持っていないため答えられないからです。この記事の残りは、その行をどう分けさせるかの手順です。

「共通率は◯割です」と言われたときに確認すること

両OS対応の見積もりで、しばしば口頭で出てくるのが「共通化できるのは8割くらいです」という説明です。この数字は、何を分母にしているかで意味がまったく変わります。

分母が3通りある

発注側が意思決定に使えるのは3つ目だけです。 コードの行数で8割が共通でも、残り2割に実機試験・ストア申請・OS固有機能が集中していれば、金額としての共通率は8割になりません。

数字ではなく、引き算で確かめる

共通率の数字そのものを検証するのは、発注側には困難です。代わりに引き算で確かめてください。

「片OSだけに絞った場合、総額はいくらになりますか」と聞いて、その金額を総額から引きます。差額が、そのベンダーが見込んでいる「2つ目のOSの費用」です。共通率が高いという説明が正しければ、この差額は総額に対して小さくなります。説明と差額が合わないときは、説明のほうが概算です。

さらに、「片OSを先に出して、あとからもう一方を追加する場合、追加時点の費用はいくらですか」も聞いてください。同時に作る場合の差額より、あとから追加する場合の金額が大きくなるのが普通です。 その差が、同時開発によって節約できている金額にあたります。この2つの数字が出てくれば、同時に作るか順番に作るかを、費用の面から比較できるようになります。

「共通率」が変動する要因

見積もり時点の共通率が、開発の途中で下がることがあります。下がる要因は、要件の側にあります。

• OSごとの標準的な見た目や操作作法に合わせる要望が、途中で追加された。 「iPhoneではこう動くべき」という指摘は、実機を触ってから出てきます
• 審査での指摘に対応した。 前述のとおり、Appleのガイドラインにはデザインを扱うセクションがあります。片方のOSでだけ修正が必要になることがあります
• OS固有の機能を、あとから要件に足した。 生体認証やウィジェットのように、後から「あると良い」と気づく種類の機能です

この3つは、見積もり時点で「起きた場合の扱い」を決めておける項目です。 変更管理の手順（誰が判断し、いくらで、いつまでに合意するか）を契約書か見積書の前提条件に書いておけば、発生したときに揉めません。

「2回になる」側の中身を、公式資料で確認する

Bの区分が本当に2回ぶんなのかを、AppleとGoogleが公開している資料で確かめます。ここに挙げる数字はすべて2026年8月31日に各公式ページから取得したもので、金額の相場ではなく「作業が2回発生する根拠」として使います。

審査は、構成の違う2つの規約で受ける

Appleの「App Store Review Guidelines」（2026年6月8日更新、2026年8月31日取得）は、冒頭で自らこう説明しています。ガイドラインは Safety・Performance・Business・Design・Legal の5つのセクションに整理されている、と。中項目は番号としては30あり、うち1つ（4.6）は「Intentionally omitted.（意図的に省略）」と明記されているため、内容を持つのは29項目です（数え方は記事末尾の根拠資料の適用条件に書きました）。

一方のGoogle Playは、「Policy Center」（2026年8月31日取得）に、カテゴリ別のポリシーページを並べる構成をとっています。Restricted Content、Intellectual Property、Privacy, Deception and Device Abuse、Use of SDKs In Apps、Malware、Impersonation、Mobile Unwanted Software、Monetization and Ads、Store Listing and Promotion、Spam, Functionality, and User Experience といったカテゴリです。

注目すべきは、Appleの5セクションのうち1つが「Design」であることです。 Google Play側は、同ページのカテゴリ一覧に「Design」という名前のカテゴリを置いておらず、機能や利用体験に関わるものは「Spam, Functionality, and User Experience」に含まれています。つまり、同じアプリを出しても、見られる観点の切り分け方が2社で違います。

このことは見積もりに直結します。「デザインは共通だから、その分は安くなります」という説明は、制作物の作成という意味では正しくても、審査対応という意味では半分しか当たりません。Apple側にはデザインを扱う章があり、そこでの指摘は個別に対応する必要があります。

審査のリードタイムは「速いほう」ではなく「遅いほう」で決まる

両社は審査にかかる時間について、それぞれ数字を公開しています。

この2つを並べて「Appleのほうが速い」と読んではいけません。 片方は分布、もう片方は例外時の上限で、統計の性格が違います。比較できるのは、次の一点だけです。

同時公開が事業要件なら、公開日は遅いほうの審査が終わった日になります。 キャンペーンの開始日、店舗への導入日、プレスリリースの日付が決まっている案件では、この待ち時間そのものがスケジュールリスクです。見積書に「ストア申請対応」の行があるとき、そこに含まれるのは1回ぶんの提出作業なのか、リジェクト（差し戻し）が起きたときの修正と再申請まで含むのかを確認してください。両社とも、差し戻しの理由に応じて修正が必要になります。

ストアの費用は、金額よりも「課金の形」が違う

金額そのものは、開発費と比べれば小さな額です。重要なのは形の違いのほうです。 見積書に「ストア登録料」という行が1つだけあるとき、それは初期費用なのか、毎年かかる費用なのかで、5年間の総額が変わります。片方が毎年で片方が一回限りである以上、この行は本来1行にまとまりません。

（ここから1段落は、公開資料に基づく記述ではなく、実務上よく問題になる確認観点です。価格の根拠ではありません。）金額より重いのが名義です。ストアのアカウントを発注側の名義で作るのか、ベンダー名義で作るのかで、アプリの管理権限と、ストア上の掲載主体が変わります。ベンダー名義のまま公開されたアプリは、契約を終えるときに移管の交渉が必要になります。見積書に「ストア登録料」の行があるなら、金額と一緒に名義も書面で決めてください。

通貨と減免についても、両社のページの記載量は同じではありません。

• Apple側：「or in local currency where available（利用可能な地域では現地通貨で）」の記載があり、非営利団体・教育機関・政府機関がfee waiver（免除）の対象になりうるとも書かれています
• Google側：現地通貨・減免のいずれについても、記載を確認できませんでした
• 消費税の扱い：いずれのページにも記載がありません

公開されている金額は、いずれも米ドル表示です（Apple側は現地通貨の場合ありと記載）。円換算する場合の前提（適用する為替レートと基準日）は、見積書側で確認する項目になります。

「同じ1機能」が、片方のOSにだけ追加作業を生むことがある

App Store Review Guidelinesには、片方のOSにだけ実装作業を生む条項が明文で置かれています。 代表的なものが 4.8「Login Services」です（Google Play側の個別ポリシー本文は本記事では確認していないため、Googleに同等の要件が無いという意味ではありません）。

原文の要件はこうです。第三者のログインサービスやソーシャルログイン（Facebook Login、Google Sign-In、Log in with X、Sign In with LinkedIn、Login with Amazon、WeChat Loginなどが例示されています）を使って、そのアプリでの主たるアカウントを作成または認証するアプリは、同等の選択肢として、次の3つの特徴を持つ別のログインサービスも提供しなければならないとされています。

1. そのログインサービスが収集するデータを、利用者の氏名とメールアドレスに限定していること
2. アカウント作成の一環として、利用者がメールアドレスを非公開に保てること
3. 同意なく、広告目的でアプリ内の操作履歴を収集しないこと

そのうえで、別のログインサービスが不要になる除外条件が5つ挙げられています。自社独自のアカウント登録・サインインの仕組みだけを使う場合、マーケットプレイス固有のログインを使う代替アプリマーケットプレイス（およびそこから配布されるアプリ）の場合、既存の教育機関・企業アカウントでのサインインを必要とする教育／企業／業務アプリの場合、政府または業界が支える市民識別システムや電子IDで認証する場合、そして特定の第三者サービスのクライアントであり利用者がそのサービスへ直接サインインする必要がある場合です。

経営判断として押さえるべき点は1つです。 「ソーシャルログインを入れる」という要件定義上の1行が、iOS側にだけ追加のログイン手段の実装・テスト・審査対応を発生させる可能性がある、ということです。そして上の5つの除外条件のどれかに当てはまるなら、その追加は発生しません。自社のアプリが除外条件に当たるかどうかの判断材料は、要件定義の段階で揃います。 最終的に判定するのは審査側ですが、材料が揃っていれば、見積もり時点でこの行の要否を議論できます。

もう1つ、2.5.6には、Webをブラウズするアプリは適切なWebKitフレームワークとWebKit JavaScriptを使う必要があり、EUと日本では代替のブラウザエンジンを使うためのentitlement（利用許可）を申請できるという記述があります。Webサイトをアプリの中で表示する構成を検討している場合は、この行が見積もりに影響します。

実機試験の範囲は、対応OSバージョンの下限で決まる

Appleは、App Storeで取引のあった端末を対象にしたOSの利用状況を公開しています。2026年6月7日時点の測定で、iPhoneについては次の数字が示されています（2026年8月31日取得）。

この数字の使いどころは、対応OSバージョンの下限を決める議論です。 下限を古いバージョンへ広げるほど、実装と検証の作業は増えます。iOS側については、この公開データを根拠に「どこまで遡るか」を数字で議論できます。

Android側について、同じ性格の公式な配信シェアのデータは、今回は取得できませんでした。そのため本記事では、両OSの普及状況を比較する書き方はしていません。 Android側は、対応する端末・OSバージョン・画面サイズを見積書へ具体的に列挙してもらう形で確認してください。

OSアップデートへの追随は、年に2回、別の期限で来る

両社は、アプリが対応すべきOSやSDKの水準を、それぞれの期限で引き上げます。期限が揃っていないことが、実務上いちばん効きます。

この作業は、開発が終わったあとも毎年発生します。 そして期限は別々に来るため、年に1回ではなく年に2回、対応の波が来ることになります。

なお、OSアップデートへの対応が保守契約に含まれるのか、追加開発として別費用になるのかは、この記事の範囲を越えます。契約範囲としての線引きはシステム保守契約の範囲で扱っているので、保守見積もりを受け取る段階でそちらを確認してください。ここで押さえるのは、開発の見積もりを取る時点で「この作業が毎年あること」を知っておくという点だけです。

クロスプラットフォームで下がる費用と、下がらない費用

1つのコードベースから両OS向けのアプリを作る方式を採ると、見積もりの何が変わるのか。下がる側と下がらない側を、分けて書きます。

下がるのは、Cの区分だけです。 Cにあたるのは、画面のUI実装とデザインの差分実装です。Aはもともと1回なので下がりません。そしてBは、前節で見たとおり2回のまま残ります。 実機試験、2つのストアへの申請と審査対応、ストア掲載物、OSアップデートへの追随、ストア費用。方式を変えても、この5つは減りません。

「クロスプラットフォームなら費用が◯割下がる」という率については、公開されている一次資料を見つけられませんでした。この記事では率を書きません。 代わりに、見積書の側でこう確認してください。「ネイティブで両OSを作った場合と比べて、下がるのはどの行ですか。その行はいくらから、いくらになりますか」。 率ではなく行で示せるベンダーは、内訳を管理しています。

そしてもう1つ、iOS向けのビルドにはMacが要ります。 Appleが公開しているXcodeのシステム要件（2026年8月31日取得）は、Xcodeのバージョンごとに「Supported macOS Versions（対応するmacOSのバージョン）」を示す形式になっています。つまりXcodeはmacOS上でしか動かず、App Store Connectへ提出するアプリはそのXcodeでビルドされている必要があるため、iOS向けのビルドにはmacOSが動く機材が要ります（バージョンごとの対応表は記事末尾の根拠資料を参照してください）。

さらにAppleは「Upcoming Requirements」ページで、2026年4月28日以降、App Store Connectへアップロードするアプリは Xcode 26 以降を使い、iOS 26 世代のSDKでビルドされている必要があると記載しています（2026年8月31日取得）。開発機のmacOSとXcodeを一定の新しさに保つこと自体が、要件になっているということです。

この機材と環境の費用は、クロスプラットフォームを採用しても消えません。 発注側が自社で開発機を持つのか、ベンダーの機材を使うのかは、見積書の前提として確認する項目です。

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

ここまでの内容を、仕分け用の表にまとめます。

この表の使い方は1つです。 見積書の各行を上から順に、A・B・Cのどれかへ入れてください。どれにも入れられない行が、質問すべき行です。

この見積もりが「2倍」で合理的なケース

倍率が2倍に近いこと自体は、不当な見積もりのサインではありません。次の条件に当てはまる案件では、2倍に近い見積もりのほうが正確です。

ケース1：OS固有の機能が要件の中心にある。 カメラや各種センサーを継続的に使う、バックグラウンドで位置情報を取り続ける、端末の性能を前提とした処理を行う、といった要件です。この場合、共通化できる部分が小さくなります。

ケース2：OS標準の見た目と操作作法への追随が要件になっている。 「iPhoneらしい操作感」「Androidらしい戻る操作」を要件として明記している場合、Cの区分が2回ぶんに寄ります。この要件は、社内の誰かが決めたはずのものです。要件として本当に必要かを見直せば、費用の議論が動く余地があります。

ケース3：同時リリースが事業要件になっている。 片OSを先に出して反応を見てから横展開する進め方が使えないため、両OSぶんの作業を並行させる必要があります。この場合の追加費用は、事業判断の対価です。 逆に、同時である必然性がなければ、片OS先行は費用を後ろ倒しにする有力な選択肢になります。

ケース4：既存のアプリが両OS別々に存在する。 改修案件では、既存のコードが2本ある以上、作業も2本になります。ここを共通化する提案が出ている場合は、それ自体が別の工数です。

ケース5：試験環境をベンダー側で用意する。 実機・回線・ストアアカウント・テスト用の課金環境をベンダー側が持つ場合、その費用は見積もりに入ります。発注側で用意できるものがあれば、その分を切り分けてもらうという交渉ができます。

これらのケースでは、見積書に「iOS分」「Android分」が分かれて書かれているほうが正しい状態です。 1行に丸めた見積書のほうが、読めません。

確認が必要なケース｜4状態への仕分け

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

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

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

過小見積もりのサイン｜安いのではなく、抜けている

この記事群では、高すぎる見積もりと同じくらい、必要な作業が抜けた見積もりを警戒します。両OS対応のアプリでは、次のサインが出ます。

1. 実機試験の行が無い、または「動作検証一式」で台数の記載が無い。 検証の数量が読めません
2. ストア申請対応の行が無い。 申請は2回あり、差し戻しへの対応も発生します
3. 差し戻し時の再申請対応が、有償とも無償とも書かれていない。 契約時に決めておかないと、リリース直前に揉めます
4. OSアップデートへの追随が、開発にも保守にも書かれていない。 前掲のとおり、両社の期限は毎年来ます
5. 対応OSバージョンの下限が書かれていない。 下限が古いほど作業は増えます。書かれていない見積もりは、この作業量を握っていません
6. 移行の行が無い。 既存アプリからの入れ替えなら、利用者のデータとログイン状態の引き継ぎが必要です
7. プロジェクト管理の行が無い、または極端に小さい。 OSが2つになるとリリース調整の手間は増えます

1つでも当てはまるなら、それは「安い見積もり」ではなく「まだ完成していない見積もり」です。

同じ「両OS対応」でも、見積書はここまで違う

同じ要件を3社に出したときに起こりうる違いを、行構成だけで示します。金額は伏せてあります。ここで見てほしいのは、金額ではなく行の有無です。

丙社がいちばん安く見えます。 しかし丙社の見積書には、実機試験・ストア申請・ストア費用の行がありません。この3つはアプリを公開する以上、誰かが必ず行う作業です。 見積書に無いということは、対象外なのか、一式に含まれているのか、まだ検討されていないのかのいずれかで、どれなのかは見積書からは読めません。

一方、乙社は共通部分までiOS分とAndroid分に割り付けているため総額が高く出ています。割り付けの根拠を聞いた結果、共通部分まで2倍していたのであれば、そこは交渉の余地があります。 逆に、両OSをネイティブで別々に作る前提が要件に基づくものなら、乙社の書き方のほうが実態に近いことになります。

総額の順位は、行構成を揃えるまで意味を持ちません。

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

ここからはコピーして使える部分です。9問すべては多いという場合は、1・2・4・6・9の5問に絞ってください。 この5問で、共通とOS別の分離・横展開の割合・検証の数量・審査対応の範囲・増減の効き方という骨格が埋まります。

依頼メールの文面

件名：アプリ開発お見積もりについての確認（iOS／Android の分担まわり）

株式会社◯◯
◯◯様

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

お見積もりをありがとうございます。社内で予算の承認を得るにあたり、
iOS と Android の両方に対応することで増える費用の内訳を確認させてください。
金額の値下げをお願いする趣旨ではなく、対応OSを変更した場合に
何がどれだけ変わるのかを、社内で説明できるようにするためです。

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

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

1. 見積書の「アプリ開発（iOS/Android）」を、片OSぶんの金額と、もう一方へ広げる分の金額に分けて記載していただけますか。 「共通化できるのは◯割」というご説明をいただいている場合は、その◯割の分母（コードの行数／機能の数／見積金額のどれか）も併せて教えてください。
2. 今回はネイティブでそれぞれ作る前提でしょうか、1つのコードベースから両OS向けに作る前提でしょうか。 後者の場合、その方式を採ることで金額が下がるのは具体的にどの行で、いくらからいくらになりますか。
3. OSが2つでも1回で済む作業（要件定義・サーバーサイド・管理画面・プロジェクト管理）と、OSごとに発生する作業を、見積書上で分けていただけますか。
4. 実機試験は、何台・どの機種・どのOSバージョンで行いますか。 対応するOSバージョンの下限も教えてください。
5. OS固有の機能として、今回どの機能を想定していますか。 プッシュ通知、アプリ内課金、生体認証、バックグラウンドでの位置情報取得などについて、iOS側とAndroid側の作業量に差があるものを教えてください。
6. ストアへの申請対応は、それぞれ何回ぶんを見込んでいますか。 審査で差し戻しがあった場合の修正と再申請は、この見積もりに含まれますか。含まれる場合は何回までですか。
7. ソーシャルログインや第三者のログインサービスを使う予定はありますか。 ある場合、iOS側で追加のログイン手段の提供が必要になるかどうか、および不要と判断する場合はその理由を教えてください。
8. Apple Developer Program と Google Play の費用は、どちらの名義で契約し、どちらが負担しますか。 見積書に含まれる場合、年額の費用と初回のみの費用を分けて記載してください。円換算しているものについては、適用したレートと基準日も教えてください。
9. 片OSだけに絞った場合、金額はいくら変わりますか。 また、片OSを先にリリースしてからもう一方を追加する進め方にした場合、追加時点の費用はいくらになりますか。

回答をどう読むか

• 1と3に即答が返る：共通とOS別を内訳として管理しています。説明済みの可能性が高い状態です
• 1で分母が「コードの行数」と返る：それは実装工数の話で、金額の共通率ではありません。要確認。分母を見積金額に置き換えた数字を出してもらってください（本記事「共通率は◯割です」の節）
• 2で「下がる行」を示せる：方式の違いによる差額を管理しています。逆に「全体的に安くなります」としか返らない場合は要確認です
• 4で台数も機種も出ない：検証の数量が定まっていません。要確認のまま契約へ進まないでください
• 5で機能名しか返らない：iOS側とAndroid側で作業量に差がある機能を名指しできるかどうかが分かれ目です。差が無いと言うなら、その理由も一言もらってください
• 6で「一式に含む」とだけ返る：差し戻し時の負担がどちらにあるかが未定です。回数を書面にしてもらってください
• 7で「不要です」とだけ返る：不要と判断した理由（自社アカウントのみを使う、業務アプリである、など）を一言添えてもらってください。理由が示されれば説明済みへ移ります
• 8で「弊社名義で取得します」と返る：それ自体は珍しくありません。契約終了時にアカウントとアプリをどう移管するかを、条件と手順まで書面にしてもらってください
• 9で「片OSでも総額はほとんど変わりません」と返る：1つのコードベースから作る前提なら、その回答は整合します。ネイティブで別々に作る前提でこの回答が返ってきたら、要確認です
• 「その粒度では出せない」と返る：直ちに問題ではありません。要件が固まっていない段階なら妥当な回答です。その場合は、確定見積もりへ移行する条件と時期を書面にしてもらってください

回答が返ってこないこと自体も情報です。 共通とOS別を分けられないということは、社内でも内訳を管理していない可能性があります。

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

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

この記事で扱ったのは構築時に一度だけ発生する費用です。稼働後の月額では、OSの数の効き方が変わります。

「作って終わり」にならないのは、この最後の行が理由です。 前掲のとおり、両社の対応期限は別々に来ます。その対応が保守契約に含まれるのか、追加開発として別費用になるのかは、システム保守契約の範囲で確認してください。

根拠資料と適用条件

この記事で使った資料と、それぞれの適用条件です。

この記事で扱っていないもの：両OSの開発費の金額レンジ、クロスプラットフォーム採用による削減率、フレームワークごとの優劣。いずれも公開されている一次資料で裏付けられなかったため、記事の柱にしていません。金額のレンジについては開発費用の相場と見積もり妥当性の判断を参照してください。

よくある質問