アプリのリニューアルで作り直す前に｜維持費と使われ方から判断する4つの選択肢

2026-09-21 2026-09-20

公開から数年が経ったアプリについて、社内で話題が出はじめる。ダウンロード数は伸びていないのに保守の請求は毎月届く。OSが新しくなるたびに改修の見積もりが来る。サービス終了するのか、このまま低調に継続するのか、リニューアルするのかの判断は誰かがしなければならない。

この段階で、「アプリ リニューアル」や「アプリ 作り直し」といった方向で情報収集を始めることが多いのですが、実際に必要なのは作り直しとは限りません。運用の体制を変えるだけで済むこともあれば、アプリという形をやめたほうがいい場合もあります。

この記事では、作り直しを決める前に見ておきたい判断材料と、そこから選べる4つの道筋を整理します。WebやLINEミニアプリへの移行もそのうちの1つとして扱い、置き換えにくいケースもあわせて書きます。

アプリのリニューアルを考えるきっかけ

ご相談の入口は、だいたい次のどれかです。

• 維持費が重い　機能が増えていないのに、保守の費用だけが続いている
• 使われていない　ダウンロードはされたが、その後に開かれていない
• 改修が進まない　小さな変更を頼んでも、見積もりが大きく、期間も長い
• 作った会社と離れた　担当者が変わった、あるいは連絡が取りづらくなった
• OSの更新に追いつけない　毎年の対応がそのまま費用になっている

このうち「維持費が重い」と「使われていない」が同時に起きているとき、リニューアルの検討が始まりやすくなります。ただ、この2つは原因が違います。前者は作り方と体制の問題で、後者は使われ方の問題です。ここを分けずに「全部作り直す」と決めると、同じことがもう一度起きます。

作り直す前に見ておきたい4つのこと

判断の材料になるのは、次の4つです。どれも社内で調べられます。

1　ダウンロード数ではなく、アクティブ率と継続利用

累計ダウンロード数は、過去の獲得規模を示す数字であり、現在使っている人数とは一致しません。判断するときは、サービスの利用頻度に合わせて、直近1か月または3か月に起動した人数を確認します。

月に何度か使う前提のサービスなら、月間の実際の利用者数（MAU）に加えて、会員数に対するアクティブ率や、期間内に複数回利用した人の割合を見ます。年に数回しか使わないサービスでは、1か月だけで判断せず、前年同期などとも比較します。ここが想定より小さい場合は、機能不足だけでなく、インストールや会員登録の途中で離脱していないかも確認します。

2　1人あたりにかかっている維持費

年間の維持費を、過去12か月の月間利用者数（MAU）の平均などで割ります。総額だけを見ていると「高い」としか言えませんが、1人あたりに直すと、他の方式と比較しやすくなります。比較するときは、毎年同じ期間と人数の定義を使うことが大切です。

ただし、1人あたりの維持費が高いだけで、終了すべきとは判断できません。1人あたりの売上や粗利、問い合わせの削減、店舗や社内業務の短縮など、アプリが生んでいる価値と並べて見てみないと見誤ります。

維持費の内訳そのものについては「アプリの維持費は開発費の15%が相場って本当？」と「アプリリリース後にかかる保守費用の相場と削減方法」で詳しく解説しています。

3　直近1年、何に費用を使ったか

保守の請求書を1年分並べて、改修の中身を分類します。

• OSやライブラリの更新に伴う、機能が増えない対応
• 不具合の修正
• 利用者に見える改善や機能追加

利用者に見える改善や機能追加がほとんどないまま費用が続いているなら、利用者が実感できる改善ではなく、現在の機能を維持するための対応に費用の多くが使われている状態です。これは作り直しても変わらないことがあります。ネイティブアプリでは、OSの大きな更新に合わせた動作確認が例年必要になり、仕様変更や不具合が見つかった場合は改修も発生するためです。

4　ネイティブアプリである必要性が高い機能を使っているか

カメラや位置情報、通知は、WebやLINEミニアプリでも一部利用できます。一方で、位置情報やセンサーの継続取得、安定したバックグラウンド処理、通信できない環境での本格的な利用、独自機器との連携などは、ネイティブアプリが向く領域です。

確認したいのは、機能を使っているかどうかだけではありません。どの頻度・精度・安定性で必要なのかまで整理します。実際に使われているのが店舗検索、クーポン、会員証の表示などに限られているなら、WebやLINEミニアプリに移せる可能性があります。

選択肢は4つある

リニューアルの相談は「作り直すかどうか」の二択で来ることが多いのですが、実際には次の4つが並びます。

運用体制を変えて続ける

使われているアプリなら、作り直さずに体制だけを変える選択があります。改修が遅い、費用の根拠がわからないといった不満は、アプリそのものではなく開発体制に原因があることがあるためです。

Enlyt（エンライト）でも、他社が開発したアプリやシステムを引き継いで、運用保守と機能追加を続けている案件があります。前の会社の資料が足りない場合は、動いているものから仕様を読み解いて資料化するところから始めます。プロダクト・システム運用保守サービスのページにまとめています。

作り直す

土台を含めて全面的に作り直す「リプレース」が必要になるのは、1つ機能を足すだけでも既存コードの調査や改修に大きな時間がかかる状態です。近年はFlutterやReact Nativeのように、iOSとAndroidを1つのコードから作る選択肢もあり、2つを別々に保守する構成より運用の負担を抑えられる場合があります。

この判断については「Flutterとは？メリット・デメリットと開発事例」と「クロスプラットフォームとは？」で整理しています。

WebやLINEミニアプリに寄せる

使っている機能が限られているなら、アプリという形をやめて、WebやLINEミニアプリに移すことを検討できます。LINEミニアプリは、利用者がインストールをしなくてもLINEの中から使えるサービスです。日本人の大多数が使っているLINEなので、ダウンロードという段階がなくなるぶん、入口での離脱を減らせる可能性があります。

方式ごとの違いと費用の比較は「LINEミニアプリ vs ネイティブアプリ vs Webアプリ」にまとめてあります。

公開を終了する

使われておらず、同じことがWebや公式アカウントでできているなら、公開を終える判断もあります。ただし、会員データの扱い、利用者への案内、有料機能が残っている場合の精算など、決めておくことがあります。利用者が突然使えなくならないよう、終了日や代わりの利用方法を事前に案内し、移行期間を設ける必要があります。

ネイティブアプリはもう選ばれないのか

「ネイティブアプリはオワコンか」という言い方を見かけますが、一律には言えません。数百万人規模の利用者を抱えるサービスでも、利用頻度や必要な機能によっては、ネイティブアプリが重要な接点になります。Enlytでも、そうした数百万人規模のユーザーが使用するアプリの運用保守と機能追加を継続して担当している案件があります（飲食チェーンのiOS・Androidアプリの開発事例）。

ネイティブアプリを選ぶときは、実現したい機能だけでなく、利用者にインストールしてもらえるか、公開後の保守費用を継続して負担できるかも確認する必要があります。

いま、ネイティブアプリが選ばれやすいのは次のような場合です。

• 利用者が毎日のように開く前提のサービス
• カメラを使った連続撮影や画像処理、センサーや位置情報の継続取得など、端末の機能を深く使う
• 通信が不安定な場所でも動く必要がある
• 通知を自社のタイミングで届けることが、サービスの中心にある

逆に、月に数回開くかどうかというサービスでは、インストールしてもらう段階で躊躇されることが多いため、この場合は、アプリでない形のほうが使われることがあります。

公開を続けるだけでも発生すること

機能を増やさなくても、App Store や Google Play でアプリの配信を続けるために、定期的な確認や対応が必要です。

iOSとAndroidでは例年、大きなOS更新があります。そのたびに動作確認が必要になり、仕様変更があれば改修も入ります。ストア側の審査基準やプライバシー関連の申告項目も更新されるため、提出内容の見直しが求められることがあります。開発者としての登録も、AppleとGoogleそれぞれに必要です。

長く更新していないアプリには、別の問題もあります。Appleは、過去3年間更新されておらず、かつ直近12か月のダウンロードが極めて少ないアプリを削除の対象としています。対象になると開発者に通知が届き、90日以内に更新を提出しなければ、App Storeからの配信が止まります。すでにインストールしている利用者はそのまま使い続けられるとされていますが、新しく入れてもらうことはできなくなります（>App Store Improvements）。

Google Playにも、似た仕組みがあります。アプリが対応しているAndroidのバージョンには「目標APIレベル」という水準が定められていて、これを満たさないアプリは、アプリが対応していないより新しいAndroidを使っている端末では、新規の利用者に提供されなくなります。すでにインストールしている利用者は、引き続き見つけて再インストールし、使い続けられるとされています（目標APIレベルの要件｜Google Play Console ヘルプ）。

つまりiOSとAndroidのどちらも、更新を止めたアプリは、いまの利用者には残るものの、新しい利用者には届かなくなっていきます。

「使われていないから、しばらく放っておく」という状態は、意図しない形で終わる可能性があるということです。続けるにしても畳むにしても、方針と期間を決めた上で管理しておかないと、思い出したときには配信が止まっているということも可能性としてはあります。

Web・LINEミニアプリへ移行するとき、実務で何が起きるか

置き換えを検討する段階になると、比較表では見えない作業が出てきます。あらかじめ知っておくと、見積もりの中身を読みやすくなります。ここでは、特にLINEミニアプリへ移行する場合を中心に説明します。

既存の会員IDをどうつなぐか

いまのアプリに会員登録があるなら、その会員情報とLINEアカウントを結び付ける必要があります。この仕組みをID連携と呼びます。

初回に既存サービスへのログイン、ワンタイムコード、会員番号と追加情報などで本人確認し、既存の会員IDとLINEアカウントを結び付ける方法があります。それ以降は、LINEアカウントを使って入れるようにします。ここを設計しないまま移すと、利用者が新規登録をやり直すことになり、移行の途中で離脱が起きます。詳しくは「LINEのID連携の仕組みとは？」で解説しています。

プッシュ通知の代わりをどうするか

置き換えの相談で、見落とされやすい部分です。

ネイティブアプリでは、利用者の許可とOS・ストアのルールの範囲内で、事業者が設定したタイミングにプッシュ通知を送れます。LINEミニアプリでは、同じことはできません。ミニアプリから送れるサービスメッセージは、認証済みのミニアプリで利用でき、利用者が操作したことへの応答として送る仕組みで、1回の操作につき送れる回数にも上限があります（サービスメッセージ｜LINE Developers）。予約完了や受付番号の連絡には向きますが、販促のお知らせを任意のタイミングで送る用途には使えません。

任意のタイミングで届けたい場合は、LINE公式アカウントからのメッセージ配信を使うことになります。こちらは配信数に応じた費用がかかるため、通知を多く送る運用では、その分を見込んでおく必要があります。費用の考え方は「LINEミニアプリの料金相場」にまとめています。

また、LINE公式アカウントから配信するには、利用者に友だち追加してもらう導線と同意の設計が必要です。既存アプリで取得している通知の許可を、そのままLINEへ引き継ぐことはできません。

つまり、通知の設計は「そのまま移す」のではなく、何をサービスメッセージで送り、何を公式アカウントから送るかを分け直す作業になります。

既存システムとの接続をどうつなぎ直すか

いまのアプリが基幹システムやポイントシステムとつながっている場合、その接続先は変わらないことが多く、つなぐ側だけを作り直す形になります。とはいえ、既存のAPIがアプリ専用に作られていると、そのままでは使えないこともあります。

Enlytでも、小売業のLINEアプリで既存システムと連携した案件があり、バーコードを扱うAPIの実装では、2つのシステムをまたぐ例外的な処理の洗い出しに時間をかけました（小売スーパーのLINEアプリの開発事例）。連携がある場合、この調査の工数を見積もりに含めているかどうかで金額が変わります。連携の方法については「LINEミニアプリと既存システムの連携方法」で解説しています。

現在のアプリの公開終了をどう進めるか

切り替えの当日にストアから消す進め方は、利用者にとって不親切になります。実際には、しばらく両方を動かし、アプリ側から移行の案内を出し、そのうえで新規のダウンロードを止め、最後に配信を終える、という段取りになります。

この期間は両方の保守が必要なので、費用は一時的に増えます。両方の保守や段階的な移行に伴う調整費用を見込まずに計画すると、途中で予算が足りなくなります。

ストアで新規配信を止めても、すでにインストールされているアプリが利用者の端末から自動で消えるわけではありません。そのため、バックエンドをいつ止めるのか、ログインやデータの閲覧をいつまで可能にするのかも別に決めます。

有料会員や自動更新の購読、アプリ内購入がある場合は、販売と更新の停止、返金や問い合わせへの対応も確認します。会員データの移行方法や保存期間、削除依頼への対応、利用規約やプライバシーポリシーの更新も終了計画に含めます。

LINEミニアプリに置き換えにくいケース

すべてのアプリが置き換えられるわけではありません。次のような場合は、慎重に考えたほうがよいと思います。

• オフラインで使う必要がある　通信できない場所で主要機能を継続して使う必要がある場合は、WebやLINEミニアプリへの置き換えが難しくなります
• バックグラウンドでの処理が中心　アプリを開いていない間に動き続ける仕組みは、置き換えが難しくなります
• 端末の機能を深く使っている　センサーの常時取得や、独自のハードウェアとの接続などが該当します
• 利用者がLINEを使っていない　業務用の端末や、対象の利用者層によっては前提が成り立ちません
• ブランドの体験そのものが価値になっている　LINE内の導線やガイドラインを前提に設計する必要があります。OSと一体になった操作や独自の画面遷移・演出を重視する場合は、ネイティブアプリのほうが向くことがあります

この場合は、ネイティブアプリを作り直すか、体制を変えて運用を続けるほうが合理的です。判断を急がず、いまのアプリのどの機能がこれに当たるかを先に洗い出しておくと、比較が早くなります。

判断のために、社内で確認しておきたいこと

開発会社に相談する前に、次のことを調べておくと、出てくる提案の精度が上がります。

• サービスの利用頻度に応じたアクティブユーザー数、アクティブ率、継続利用率
• 年間の維持費と、その内訳
• 直近1年の改修で、利用者に見える改善がどれくらいあったか
• 実際に使われている機能と、ほとんど使われていない機能
• 会員データをどこで管理しているか、他のシステムとつながっているか
• ソースコードと設計資料が、いま手元にあるか

最後の項目は見落とされがちですが、作り直す場合も引き継ぐ場合も、ここが揃っているかで初期の工数が変わります。手元になければ、開発会社に確認しておくと話が早くなります。

これらが揃っていない段階でも、相談はできます。Enlytでは、現状を一緒に確認するところから受けています。

Enlytでは、運用継続・作り直し・移行を支援しています

Enlytでは、ネイティブアプリの開発と運用保守、クロスプラットフォームでの開発、LINEミニアプリの開発を、いずれも受託しています。複数の方式を扱っているため、現在の利用状況や必要な機能を基準に、運用継続・作り直し・WebやLINEミニアプリへの移行を並べて検討できます。

実際にお受けしている形は、こうしたものです。

• 他社が開発したアプリを引き継いで、運用保守と機能追加を続ける
• 古くなったアプリを、iOSとAndroidを1つのコードで作る形に作り直す
• いまのアプリの機能を整理して、LINEミニアプリに移す
• どれを選ぶべきかの判断から、一緒に整理する

進め方は、受注前に「要件まとめ」を作り、そこから概算見積もりと提案書をお出しする形です。この段階で、どこを新しく作りどこを既存のもので賄うか、既存システムとの連携があるか、公開後に誰がどう運用するのかまで整理します。

ほかの案件は開発実績の一覧に、サービスの内容はサービス紹介ページにまとめています。開発の進め方や費用の考え方をまとめた資料はお役立ち資料からご覧いただけます。

まとめ

アプリのリニューアルは、作り直すかどうかの二択ではありません。運用体制を変えて続ける、作り直す、WebやLINEミニアプリに寄せる、公開を終える。この4つを並べたうえで選ぶほうが、判断を誤りにくくなります。

判断の材料になるのは、ダウンロード数ではなく実際に使われている人数、1人あたりの維持費、直近1年の改修の中身、そして、ネイティブアプリである必要性が高い機能を使っているかどうかです。ここを見ずに作り直すと、同じ状態がもう一度来ます。

LINEミニアプリへの置き換えを選ぶ場合は、会員IDのつなぎ方と、通知の設計をやり直す作業が必要になります。特に通知は、ネイティブアプリと同じようには扱えません。一方で、オフラインでの動作やバックグラウンドの処理が中心のアプリは、そもそも置き換えに向きません。

どれを選ぶかは、いまのアプリが何に使われているかで変わります。社内で答えが出ない段階でも、現状の確認から一緒に進められます。

金子 遼平

フィリピンの語学学校スタッフとして5年間勤務後、Enlytに参画。 現在はフィリピン在住で完全リモートにて、開発ディレクター・PM・デザイナーとして複数プロジェクトを担当。 UI/UX設計とプロジェクトマネジメントを横断できる点を強みとし、リモート環境下でも安定した品質とスピードを実現している。

View More