アプリ開発会社の選び方【2026年版】アプリ固有の7つの選定軸と、会社タイプ別の向き不向き

「アプリ開発会社の選び方を調べても、『おすすめ20選』ばかりで決め手が分からない」——アプリの外注を初めて検討する方から、こうした相談をよく受けます。どの記事も実績数と費用相場を並べるだけで、自社の案件にどう当てはめればよいかが書かれていない。かといって技術の目利きができるわけでもない。結局、見積もりの安い順に並べて決めそうになる、というところで手が止まります。

結論から言うと、アプリ開発の会社選びは、システム開発一般の選び方に7つの軸を足して判断します。開発方式(ネイティブかFlutter・React Nativeか)の提案根拠、ストア申請と審査対応の経験、UI/UXを誰が担うか、プッシュ通知、App内課金とサブスク、OSバージョン対応を含む継続保守、アナリティクス計測の7つです。この7つは、業務システムの発注では出てこない、アプリだけの関門にひもづいています。

アプリはWebサイトと違い、ストア審査という第三者の関門を通らなければ世に出せません。OSは年1回更新され、課金はプラットフォームの規約に縛られ、計測はSDKに依存します。つまり問われるのは「作れるか」ではなく、「出せるか」「出し続けられるか」です。実績件数や見積もりの総額は、この3つを区別してくれません。

本記事では、アプリの会社選びが業務システムと違う5つの理由、アプリ固有の選定軸7つと確かめる質問、会社タイプ別(大手SIer・アプリ特化・受託中小・オフショア・フリーランス)の向き不向き、発注前に聞く15の質問と実装担当が社員か協力会社かの確認、当社の位置づけと向かない案件、よくある質問の順に解説します。費用の相場と見積もりの読み方は別記事に譲り、ここでは選定軸に絞ります。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。アプリの相談で聞く失敗は、たいてい2つに集約されます。この記事を読み終えるころには、商談で何を聞けばよいか、自社の案件にどのタイプの会社が合うかが判断できるはずです。

アプリ開発の会社選びが、業務システムの会社選びと違う5つの理由

開発会社の選び方には、実績・提案力・体制・見積もりの透明性・保守という共通の基準があります。そこは業務システムでもアプリでも変わりません。変わるのは、アプリだけが通らなければならない関門が5つある点です。この5つを知らないまま「開発実績が豊富な会社」を選ぶと、作れたのに出せない、出せたのに続けられない、という事態になります。まず前提として押さえてください。

アプリだけにある5つの条件——審査、OS更新、課金、UI、計測

この5つは、どれも「作る技術」ではなく「出す・出し続ける実務」に関わります。だから、ポートフォリオの画面の美しさや、実績件数の多さだけを見ても判別できないのが実情です。

「作れるか」ではなく「出せるか・出し続けられるか」で選ぶ——私が見てきた失敗2つ

私は2018年からホーチミンで約100社の開発体制の相談に乗ってきましたが、アプリの失敗相談は2つの型に集まります。1つ目は「画面は作れたのに審査で落ちた」ケースです。サブスクの解約導線と価格表示がストアの規約に合わず、課金まわりを設計からやり直して2か月遅れました。実装力の問題ではなく、審査の勘所を持っていなかったのが原因です。

2つ目は「リリースの1年後、OS更新で動かなくなったが直せない」ケースです。納品時に保守契約を結んでおらず、当時の担当エンジニアはすでに退職。ソースコードは受け取っていたものの、設計の意図を知る人がいないため、他社に見積もりを出すと新規開発に近い金額になりました。

どちらも、契約前に「出せるか」「出し続けられるか」を確かめていれば避けられたものです。次章では、その確かめ方をアプリ固有の選定軸7つとして整理します。

アプリ固有の選定軸7つ——確かめる質問と、危ない答え

ここからが本題です。アプリ開発会社を比べるとき、共通の基準(類似実績・提案力・体制・見積もりの範囲・保守)に加えて、次の7つの軸を当ててください。7つは「作る前」「作る間」「出したあと」の3フェーズに並びます。技術の目利きができなくても、質問の形と「危ない答え」の型を持っていれば判別できます。商談で1つずつ聞き、答えをその場でメモしてください。

選定軸7つの一覧表——なぜ効くか、確かめる質問、危ない答え

7つのうち、1と3は発注前に決めるべきこと、4と5は実装の経験値、2と6と7はリリース後の体力です。候補各社に同じ質問をして、答えの具体性を並べると差が出ます。なお、実績の見方は件数ではなく担当範囲です。「要件定義から入ったのか、実装だけを請けたのか」を必ず聞いてください。

軸1 開発方式——ネイティブ、Flutter、React Nativeのどれを、なぜ勧めるのか

ネイティブ開発はiOSをSwift、AndroidをKotlinで別々に作る方式で、OSの新機能や端末機能への追随が速く、描画性能を引き出せます。クロスプラットフォーム(FlutterやReact Native)は1つのコードで両OSを賄う方式で、画面周りの開発量を減らせます。ただし、決済・通知・カメラ・位置情報といった端末機能は結局OSごとの作り込みとテストが要るため、「費用が半分になる」という説明は要注意です。

見極め方は単純で、「なぜその方式を勧めるのか」「逆の方式なら何が変わるのか」の2問です。要件(対応OS、更新頻度、端末機能の使用、将来の内製化)と対応づけて答えられる会社は、方式を道具として扱えています。自社の得意な方式しか提案しない会社は、要件が外れたときに無理が出ます。

軸2 ストア申請・審査とリリース運用——アカウント名義、リジェクト時の責任、リリース頻度

ストア周りは、技術よりも契約と運用の論点です。確認するのは3つ。App Store ConnectとGoogle Play Consoleのアカウントを誰の名義で作るか(自社名義を強く推奨します)、リジェクトされたときの対応は誰の責任で、追加費用が出るのか、そしてリリース作業を月に何回まで契約に含むかです。

継続的に改善するアプリでは、リリース頻度が実力に直結します。毎月あるいは隔週で配信している会社は、審査の待ち時間を織り込んだ進め方を持っています。逆に「年1回の大型リリース」しか経験がない会社に、週次の改善を求めると噛み合いません。

軸3・軸4 UI/UXを誰が担うか、プッシュ通知の実装と配信基盤

UI/UXは、社内にデザイナーがいるか、プロトタイプを作って触れる状態で合意するか、の2点で判断します。画面設計を発注側の支給に任せる会社は、実装は安く上がりますが、設計の相談相手がいないため、作り直しのリスクを発注側が全部背負います。

プッシュ通知は「実装できます」という答えでは足りません。配信基盤(FirebaseのCloud Messagingや配信SaaS)をどう選ぶか、ユーザーの属性や行動でセグメントを切れるか、通知の許諾率をどう上げるか、開封や再訪をどう測るかまで含めて初めて機能します。ここを運用の話として語れる会社は、リリース後の伴走を前提にしています。

軸5 App内課金・サブスクの実装経験——レシート検証、復元、解約、Web課金との使い分け

課金は、アプリ開発で最も事故が起きる領域です。デジタルコンテンツの販売は原則としてApp内課金を使う必要があり、手数料も価格の刻みもプラットフォーム側の規約に従います。実装では、購入内容を検証するレシート検証、機種変更時の購入復元、サブスクの更新と解約、価格改定時の扱いといった論点が並びます。

確かめる質問は「サブスクのレシート検証と購入復元をどう実装しますか」の1問で十分です。サーバー側での検証を前提に具体名を挙げて答えられるか、経験がなく「調べます」になるかで、実力の差が出ます。当社が担当した決済アプリでは、Stripe連携に加えて二要素認証、ウォレット、PDF出力までを実装し、新規開発から週次の保守運用へ移行しました。決済は仕様よりも例外処理の設計で工数が動く領域です。

軸6・軸7 OSバージョン対応を含む継続保守、アナリティクス計測の設計

保守契約では、「不具合対応」と「OSバージョン対応」を分けて書いてもらってください。前者だけの契約だと、毎年のOS更新やSDKの期限切れへの対応が都度見積もりになり、結果として保守費が読めなくなります。年間の想定工数と、対応が必要になったときの判断の主体(会社側から提案が来るのか、発注側が気づいて依頼するのか)まで決めておくのが安全です。

計測は、Webの感覚のまま「後から入れられます」と答える会社に要注意です。アプリの計測はSDKを組み込んだ状態で配信する必要があり、後付けはユーザーの更新を待つことになります。初回リリースの時点で、見たい指標とイベント設計を誰が担当するかを決めてください。当社では日本人PMが設計レビューを行い、Gitのプルリクエストによるコードレビューとリリース前のダブルチェックを標準にしています。仕組みで品質を担保しないと、人が替わったときに水準が落ちるからです。

7つの軸に共通するのは、「作れます」で止まる答えを許さないことです。作れるかどうかではなく、出すまでと出したあとをどう回すかを聞く。これだけで、候補は1社に絞り込めます。

会社タイプ別の向き不向き——大手SIer、アプリ特化、受託中小、オフショア、フリーランス

「アプリ開発会社」と一括りにされますが、実態は5つのタイプに分かれ、強い工程も費用感もまったく違います。上位の比較記事が会社名を並べるのに対して、ここではタイプごとの向き不向きを整理します。自社の予算と要件の固まり具合を当てはめれば、候補を絞る前にタイプを絞れます。他社の特徴は各社が公開している情報の範囲で中立に書き、費用感は金額ではなくタイプ間の相対的な高低として示します。これは当社が約100社の相談を受けるなかで見てきた傾向を整理したもので、外部の相場調査を引いたものではありません。

5タイプの比較表——費用感、強い工程、向く案件、向かない案件

タイプの違いは優劣ではなく、得意な工程の違いです。1社ですべてを賄おうとすると、上流に強い会社に長期の運用を頼んで割高になるか、実装に強い会社に企画を頼んで空回りするか、のどちらかになります。

予算と要件確定度でタイプを当てる——3つのよくあるケース

判断は、予算と要件の固まり具合の2軸で足ります。ケース1、予算1,000万円前後で企画から相談したい一般ユーザー向けアプリなら、アプリ特化型か受託中小が第一候補です。上流の設計に投資する価値が大きい案件だからです。

ケース2、すでにアプリがあり、機能追加とOS対応を継続したい場合は、オフショアか受託中小が向きます。必要なのは企画力よりも、毎月動き続ける実装の手と、保守を含む契約です。ケース3、検証用に小さく作りたいが課金を含む場合は、フリーランスより受託中小かオフショアを勧めます。課金と審査は経験値の差が最も出る領域で、1人体制だと詰まったときに止まるからです。

費用の桁感を先に押さえたい場合は「アプリ開発 費用」の記事を、見積書の読み方は「システム開発 見積もり 内訳」の記事をあわせてご覧ください。本記事では相場表は扱いません。

複数タイプの組み合わせも選べる——UI/UXは特化型、実装はオフショア

見落とされがちですが、タイプは組み合わせられます。UI/UXの設計をアプリ特化型に発注し、実装と継続開発をオフショアのラボ型で持つ、という形は実際によくあります。設計の成果物(画面設計とプロトタイプ、デザインデータ)を自社の資産として受け取れる契約にしておけば、実装側を後から替えることもできます。

当社の場合、公開単価は実務3年目安のエンジニアで1,500USD(約22.5万円 / 1USD=150円換算目安)、5年で2,000USD、10年目安・ブリッジSEで3,000USDです。最小構成は日本人PMフロント+2〜3人月で月額約80万円〜になります。国内の受託中小に同じ人数を頼む場合と比べて、月額のレンジが変わるため、上流だけ国内、実装は海外という分け方が成立します。

では、候補のタイプが絞れたとして、商談では何を聞けばよいのでしょうか。次章で15の質問に落とします。

発注前に聞く15の質問と、実装担当が社員か協力会社かの確認

候補のタイプが決まったら、次は商談です。ここで効くのは、全社に同じ質問をして答えを並べることです。質問が揃っていないと、提案書の見た目や担当者の印象で決めてしまい、後から「そんな話は聞いていない」が起きます。以下の5項目の整理と15の質問は、そのまま商談のメモ用紙として使える形にしました。

相談前に整理する5項目——目的、利用者、必須機能、予算、公開希望時期

要件をすべて固めてから相談する必要はありません。ただし次の5項目を整理しておくと、提案と見積もりの精度が上がります。1つ目は目的(アプリで何を変えたいのか、成功をどの数字で測るのか)。2つ目は利用者(一般ユーザーか、社員か、取引先か)。3つ目は必須機能を「必須」「できれば」「将来」の3段階に分けたもの。4つ目は予算(初期開発だけでなく、年間の保守とストア・サーバー費用を含む上限)。5つ目は公開希望時期と、その時期である理由です。

この5項目を1枚にまとめて各社へ同時に渡すと、前提が揃い、見積もりを比べられる状態になります。提案依頼書の形にまとめたい場合は「RFP 書き方」の記事を参考にしてください。

商談で聞く15の質問——体制、開発方式、ストア、課金、保守、契約

15問すべてに即答できる会社は多くありません。大事なのは即答の可否ではなく、分からないことを「持ち帰って確認します」と言えるか、その回答が何日で返ってくるかです。回答の速さと正確さは、開発が始まってからのやり取りの速さとほぼ一致します。

実装担当は社員か協力会社か——商流を1問で確かめる

15問のうち、最も効くのはNo.2です。開発会社の見積もりが数倍違う理由の多くは、技術力ではなく商流にあります。受注した会社が自社で作るのか、協力会社に出すのか、その先にもう一段あるのか。階層が増えるほど各段で費用が乗り、現場に届く金額は目減りします。修正の依頼も階層を経由するため、レスポンスが遅くなるのが実情です。

再委託そのものが悪いわけではありません。問題は、どの工程を誰が担当し、品質と情報管理をどう統制するかが説明されないことです。だから聞き方は「再委託していますか」ではなく、「実装は貴社の社員が行いますか。協力会社に出す工程はどこですか」にします。工程を名指しで答えられる会社は統制が効いています。商流の見抜き方は「オフショア開発 中間マージン」の記事、契約での書き方は「業務委託 再委託」の記事で詳しく扱っています。

当社の場合は、2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインする形で、協力会社や紹介経由の仲介マージンが入りません。単価を公開できるのも商流が1段だからです。既存のアプリを別会社から引き継ぐ場合の進め方は「開発会社 乗り換え 引き継ぎ」の記事にまとめています。

5項目を整理し、15問を同じ条件で聞き、最後に商流を確かめる。この順序で進めれば、提案書の厚さや担当者の印象ではなく、体制と根拠で選べます。

当社(TALENTBASE VIETNAM)の位置づけと、向かない案件

ここまでの選定軸に当社を当てるとどうなるかを、他社と同じ基準で書きます。当社はベトナム・ホーチミンを拠点に、日本国内法人との契約でオフショア開発の体制を提供しています。5タイプで言えばオフショアに当たり、強みが出るのは「リリース後も手を止めずに改善を続けたい」案件です。逆に向かない案件もはっきりしているので、最後に正直に書きます。

人財データベースからの直接アサインと、公開単価・最小構成

当社は2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から、案件ごとに直接アサインします。協力会社や紹介経由が入らないため、仲介マージンがありません。単価は公開しており、実務3年目安のエンジニアが1,500USD(約22.5万円)、5年で2,000USD、10年目安・ブリッジSEで3,000USDです(1USD=150円換算目安)。当社調べで市場相場の約2分の1にあたります。

体制は2パターンあり、日本人PMまたはブリッジSEをフロントに置いてエンジニアを組むパターンA(推奨)と、エンジニアのみのパターンBです。最小構成は日本人PMフロント+2〜3人月で月額約80万円〜。1名から契約でき、開始は最短2週間、増員は約1週間、縮小と交代は1か月単位です。進め方は、打ち合わせ→アサイン(約1週間)→候補者面談(約1週間)→開始という流れで、契約・支払いは日本国内法人・日本法準拠のため海外送金は不要です。ベトナムとの時差は2時間で、日中の時間帯がほぼ重なります。

アプリの実績と、品質を仕組みで担保する3点

アプリ関連では、決済アプリを新規開発から継続保守まで担当しています。Stripe連携、二要素認証、ウォレット機能、PDF出力までを実装し、リリース後は週次の保守運用に移行しました。ほかに、LLMを使った24時間対応のAIチャットボット、採用管理機能を含む求人プラットフォーム、ヘッドレスCMSのWebサイトなどを手がけています。

継続開発の例としては、介護記録SaaS「CareViewer」があります。日本語対応のブリッジSE1名とフルスタックエンジニア2名の体制で、週次で優先順位を判断しながら開発を続け、コストは従来の半分以下になりました。担当者からは「想像以上にエンジニアのレベルが高い」という評価をいただいています。品質は3点で担保しています。日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックです。加えてAIを活用した開発体制を取り、インフラはAWS認定11冠のメンバーが設計します。

当社が向かない案件——要件確定の単発、ゲーム・高頻度描画、国内常駐

正直に書くと、当社に向かない案件もあります。1つ目は、要件が完全に固まっていて一度きりの納品で終わる短期案件です。月額の専属体制は継続的な改善で効くもので、単発なら国内の受託中小に請負で出すほうが、管理の手間が少なく済みます。2つ目は、ゲームや高頻度の描画・3D表現が中心のアプリです。専門の制作会社のほうが適任で、当社の得意領域ではありません。3つ目は、発注元のオフィスに常駐して進める必要がある案件です。

また、ストアのアカウント名義や審査対応の分担は案件ごとに決めています。App内課金・サブスクの実装範囲を含め、契約前の打ち合わせで担当範囲を文書にしてお渡しします。合わない案件にはその旨をお伝えするので、まずは要件をお聞かせください。

アプリ開発会社の選び方でよくある質問

アプリの発注を検討している方から、商談の前後で繰り返し聞かれる質問を5つにまとめました。社内で選定理由を説明するときの材料としてもお使いください。

Q1. 開発会社は何社くらい比較すればよいですか?

社数に決まった正解はありません。増やすほど打ち合わせと評価の負担が増え、比較の質はかえって落ちます。先にタイプ(大手SIer・アプリ特化・受託中小・オフショア・フリーランス)を絞り、同じ資料と同じ15の質問で提案を受けてください。前提を揃えない相見積もりは、金額を比べても意味がありません。

Q2. ネイティブとクロスプラットフォーム、どちらを勧める会社を選ぶべきですか?

方式で会社を選ばないでください。見るべきは「なぜその方式か」を要件と対応づけて説明できるかどうかです。端末機能を深く使う、描画性能が要る、OSの新機能に早く追随したい場合はネイティブが有利で、画面中心のアプリを両OSへ同時に出したい場合はクロスプラットフォームが効きます。どちらか一方しか提案しない会社は、要件が外れたときに無理が出ます。

Q3. ストア審査でリジェクトされた場合、責任はどちらにありますか?

契約の書き方によって変わります。審査対応を委託範囲に含めるか、リジェクト時の修正を無償の範囲とするか、追加費用とするかを契約前に明文化してください。あわせて、ストアのアカウント名義を自社にしておくと、会社を替えるときも配信を止めずに済みます。

Q4. リリース後の保守費用はどのくらい見ておくべきですか?

会社と範囲によって幅がありますが、判断の軸は金額よりも範囲です。「不具合対応のみ」か「OSバージョン対応を含む」かで内容がまったく違います。年間の想定工数と、対応が必要になったときにどちらから提案するのかを契約に書いてもらってください。継続的に改善する前提なら、月額の専属体制のほうが費用を読みやすくなります。

Q5. 同じ要件なのに見積もりが数倍違うのはなぜですか?

理由は主に2つで、見積もりの範囲の差と、商流の差です。要件定義・デザイン・テスト・ストア申請・保守のどこまでを含むかで総額は大きく動きます。もう1つは、受注した会社が自社で作るのか、協力会社へ出すのか。階層が増えるほど各段で費用が乗ります。範囲を揃えたうえで「実装は誰が行うか」を聞く。これが金額差を読み解く最短の手順。

まとめ: アプリ開発会社は「作れるか」ではなく「出せるか・出し続けられるか」で選ぶ

アプリ開発の会社選びは、システム開発一般の基準に7つの軸を足して判断します。開発方式(ネイティブかFlutter・React Nativeか)の提案根拠、ストア申請と審査対応の経験、UI/UXを誰が担うか、プッシュ通知の実装と配信基盤、App内課金とサブスクの実装経験、OSバージョン対応を含む継続保守、アナリティクス計測の設計の7つです。この7つは、ストア審査という第三者の関門、OSの年次更新、課金を縛るプラットフォーム規約という、アプリだけにある条件から生まれています。

進め方は3段階です。まず会社タイプ(大手SIer・アプリ特化・受託中小・オフショア・フリーランス)を予算と要件の固まり具合で絞る。次に候補各社へ同じ資料を渡し、15の質問を同じ条件で聞く。最後に「実装は貴社の社員が行いますか。協力会社に出す工程はどこですか」で商流を確かめる。見積もりの金額差は、多くが範囲の差と商流の差です。当社は2,000名以上の人財データベースから直接アサインし、仲介マージンなしで単価を公開しています。実務3年目安で1,500USD(約22.5万円 / 1USD=150円換算目安)、最小構成は日本人PMフロント+2〜3人月で月額約80万円〜、1名から最短2週間で開始できます。

一方で、要件が確定した一度きりの納品案件、ゲームや高頻度描画が中心のアプリ、国内常駐が必要な案件は、当社よりも適した相手がいます。費用の桁感はアプリ開発の費用相場、汎用の開発会社の選び方はシステム開発会社の選び方もあわせてご覧ください。現在の体制と要件をお聞かせいただければ、どのタイプの会社が合うかの判断と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。