2027年にAndroidアプリの品質要件が変わる — 来期の保守予算に積むもの | GH Media
URLがコピーされました

2027年にAndroidアプリの品質要件が変わる — 来期の保守予算に積むもの

URLがコピーされました
2027年にAndroidアプリの品質要件が変わる — 来期の保守予算に積むもの

数年前に外注して作ったAndroidアプリが、今も特に問題なく動いている。保守は月いくらかで最低限のことだけ見てもらっている。この状態の会社は少なくありません。

そこに来期、一項目増えます。Google Play がアプリの品質要件を見直し、2027年2月からメモリ使用量の基準2027年4月から機種変更時のログインに関する要件を段階的に適用するためです。発表は2026年8月26日で、適用まで1年以上の猶予があります。

猶予があるうちに整理しておきたいのは、技術的な対応方法よりも先に、これが誰の負担で、いつまでに終わっている必要があるかです。

基準を超えると何が起きるのか

まずメモリ側から。新しい基準では、アプリが専有するメモリの量や、画像データがバックグラウンドで保持され続けていないかといった複数の観点で、アプリのメモリ消費が評価されます。

重要なのは、この基準が審査で弾かれるという形だけではないという点です。基準値を超えたアプリは端末上での動作が悪化し、Android によって強制終了されやすくなります。つまり、ストアに出し直さなくても、利用者の手元で「よく落ちるアプリ」になっていく方向の変化です。

ここが従来の対象APIレベルの引き上げと性質が違うところです。APIレベルの要件は「更新を出すなら対応してください」という話でしたが、メモリ側は更新を出さずに放置していても、利用者の体験が劣化していく性質を持ちます。

もう一方の Zero-Tap Sign-In は、利用者が機種変更したときにアプリへのログイン状態を自動で引き継ぐ仕組みへの対応です。こちらは2027年4月からの適用となります。

発注側が最初に確認すべきこと

技術的な対応は開発側の仕事ですが、確認する順番を発注側が握っていないと、見積もりの妥当性を判断できません。 最低限、次の3つは自社で把握しておく価値があります。

1. そのアプリは現在も更新されているか。 数年間ストアに出し直していないアプリは、対応の作業量が読みにくくなります。ライブラリのバージョンが古く、まず土台を上げるところから始まるためです。

2. 画像を多く扱うアプリかどうか。 カタログ、物件情報、メニュー、施工事例といった画像中心のアプリは、メモリ側の基準で影響を受けやすい部類に入ります。逆に、フォーム入力と一覧表示が中心のアプリは相対的に余裕があります。

3. 現在の保守契約に何が含まれているか。 「障害対応」だけの契約なのか、「ストア要件への追随」まで含むのか。ここが曖昧なまま2027年を迎えると、対応が必要になった時点で追加見積もりの交渉から始まります。

更新を止めていても利用者の端末上で体験が劣化していく変化と、保守契約に追随範囲が含まれているかどうかの確認点を示した図

3番目が、実務でいちばん揉めるところです。契約書に「ストアのポリシー変更への対応」の記載が無い場合、それは含まれていないと解釈されるのが通例で、発注側が想定している「保守」と受注側の「保守」の範囲がずれています。

保守の範囲を、今のうちに言葉にしておく

要件の適用まで時間があるということは、契約や見積もりの前提を整理する時間があるということでもあります。

確認する項目曖昧なままにした場合先に決めておいた場合
ストア要件への追随適用直前に追加見積もりの交渉になる年次の保守枠に含めて計画できる
対応の判定基準「対応したかどうか」が主観になる計測して基準内かを確認する形にできる
対応後の確認出し直して様子を見ることになる対応前後の数値を比較して残せる

特に2行目の「判定基準」は、メモリのような数値で測れる要件だからこそ意味を持ちます。対応前と対応後のメモリ使用量を計測して残しておけば、追加費用が何に対して支払われたのかが後から説明できます。逆に、計測せずに「軽くしました」だけで受け取ると、実際に基準を満たしたのかが利用者からの不具合報告でしか分かりません。

このあたりの考え方は、外部要因でアプリの前提が変わったときの対応と共通します。ストア側のルール変更は自社の都合に関係なく来るため、来た時点で慌てないための枠を先に確保しておく話です。

作り直す判断が視野に入る場合

古いアプリを持っている会社では、対応を積み上げるより別の形に置き換えるほうが総額で安く済むケースがあります。

判断の分かれ目は、そのアプリがネイティブアプリである必然性です。プッシュ通知やカメラ、位置情報を深く使っているなら置き換えは現実的ではありません。一方、実質的に「社内向けの一覧と入力フォーム」であれば、Webベースの構成に寄せる選択肢がストア要件そのものから外れる道になります。ストアに出さなければ、ストアの要件変更にも追随し続けなくて済みます。

ここは、いま持っているアプリが何をしているかによって答えが変わる部分です。「対応する」と決める前に、そもそも何のために作ったアプリだったかを一度並べてみる価値はあります。

次にやること

保守を依頼している相手に、質問を一つ送ってください。「2027年2月からの Google Play のメモリ要件と、4月からの Zero-Tap Sign-In について、現在の保守契約の範囲に含まれますか」

含まれるという回答なら、来期の予算では何もしなくて構いません。含まれないという回答が返ってきたなら、そこからが交渉であり、時間がある今のうちに始められます。返ってこない、あるいは要件自体を把握していない場合は、それ自体が判断材料です。

Androidアプリの要件対応の見積もり妥当性、保守契約の範囲設計、ネイティブアプリからWebベースへの置き換え判断については、グリームハブの開発・AI・自動化のご相談で承っています。現在のアプリの構成によって取れる選択肢が変わるため、お問い合わせから個別にご相談ください。

Sources

URLがコピーされました

グリームハブ株式会社は、変化の激しい時代において、アイデアを形にし、人がもっと自由に、もっと創造的に生きられる世界を目指しています。

記事を書いた人

鈴木 翔

鈴木 翔

技術の可能性に魅了され、学生時代からプログラミングとデジタルアートの分野に深い関心を持つ

関連記事

「TECH」の記事一覧を見る