LASSIC Media らしくメディア

LASSIC IT事業部｜プライムベンダーとしてシステム保守・運用を受託

Androidアップデート対応外注とは、OS更新に伴う動作維持・新要件適合を担う委託である

Androidアップデート対応外注とは、Android OSのメジャーバージョン更新やGoogle Playのポリシー変更に伴い必要となる、既存アプリの動作検証・互換性修正・対象APIレベル更新・公開審査対応を、外部の開発パートナーに委託する取り組みを指す。Google Playの対象APIレベル要件では、新規アプリと既存アプリのアップデートはAndroidの最新メジャーバージョンのリリースから1年以内にそのAPIレベルをターゲットにすることが求められており^*1、対応を怠るとアプリが新規ユーザーから見えなくなる影響が出る。

対応が後回しになる背景：Google Playの対象APIレベル要件と毎年のOSメジャー更新

Androidアプリ運用の現場では、Google Playの対象APIレベル要件と、毎年公開されるOSメジャーバージョンの両方に追随することが求められる。Google Playの公式ヘルプによれば、新規アプリとアプリアップデートは最新メジャーバージョンのリリースから1年以内に該当のAPIレベルをターゲットにすることが必要で、要件を満たさない場合は新しいOSが搭載されたデバイスでGoogle Playのユーザーがアプリを見つけられなくなる^*1。さらに更新のない既存アプリは、最新メジャーバージョンのリリースから2年を過ぎてもAPIレベルを更新していない場合、それ以降のOSを搭載したデバイスの新規ユーザーからアクセスできなくなる扱いが続いている^*1。

OS側の更新サイクルも対応の負荷を高めている。Googleは公式に、Pixelデバイス向けの新OS・新機能・セキュリティ強化を含むソフトウェアアップデートを定期的に配信しており^*2、Android Open Source Projectのセキュリティ情報も毎月公表されている^*3。アプリ提供者は毎年のメジャーバージョン公開と毎月のセキュリティパッチの双方を踏まえ、検証・修正・公開審査対応を継続する必要がある。

こうした背景があるため、社内のリソースだけでアップデート対応を維持しようとすると、新機能開発と保守作業の競合が起きやすい。外注を検討する出発点は「いつ何の対応が必要になるかを正しく把握し、必要な工程に必要な工数を配分できる体制を持つこと」にある。

アップデート対応で外注を検討する4つの状況：期限直前・OS不具合・脆弱性追従・体制縮小

以下では、Androidアップデート対応で外注が検討されやすい代表的な状況を整理する。実在の特定企業の事例ではなく、現場で繰り返し見られる状況パターンとして仮説形式で記述する。

パターン1：APIレベル要件の期限直前に対応が間に合わず公開停止リスクが顕在化

Google Playの対象APIレベル要件では、2025年時点で毎年8月末（8月31日）に新しい締切が設定される運用が続いている^*1。新機能開発を優先したまま夏前の検証着手が遅れた状況では、リジェクトの繰り返し・実機検証の遅延・期間延長申請の手続きなどが重なり、公開停止リスクが顕在化する。期限直前の状況では、APIレベル変更に伴う権限取得方法やバックグラウンド処理の差分への対処が短期間に集中するため、外部リソースで集中的に消化するパターンが多く見られる。

パターン2：年次のOSメジャーバージョン公開後に互換性不具合が複数のユーザーから報告

Googleは毎年Androidの新メジャーバージョンを公開しており、Pixelには新OS・セキュリティ強化を含むソフトウェアアップデートが定期的に提供される^*2。OS更新後にユーザー端末で挙動が変わり、社内に不具合報告が集中する状況では、原因がOS仕様変更によるものか自アプリのコード由来かを切り分ける必要がある。社内に新OSの検証端末がない場合や、過去のリリースから時間が空いている場合は、原因切り分けと改修を一括して外部に委ねるケースが見られる。

パターン3：セキュリティパッチ追従が滞り脆弱性対応の判断遅延が発生

AOSPはAndroid Security Bulletinを毎月公開している^*3。利用しているライブラリやSDKがセキュリティパッチに連動して更新される一方、自アプリ側の対応が滞ると脆弱性に関する社内判断が遅れる。情報セキュリティ部門との連携が必要な状況で、開発部門の人員に余裕がない場合に、月次の追従作業を外部委託する形が選ばれることがある。

パターン4：社内開発体制の縮小により継続的なアップデート対応の担い手が不在

当初の開発を担ったメンバーが異動・退職した状況では、社内にAndroidネイティブ実装の継続知見が残らない。新たに対応するたびに調査負荷が大きくなる。新OSや新APIへの追従が場当たり対応になる場合、設計意図を外部パートナーと共有して定常的な保守体制を構築する選択が取られるパターンがある。

つまずきやすい注意点：審査・権限・互換性の3領域で何が起きるか

アップデート対応を進める際に、つまずきやすい領域はおおむね3つに集約される。

注意点1：公開審査リジェクト時の対応コストを見積もりに含めないと工期が崩れる

Google Playの審査では、対象APIレベル要件・権限の使用説明・ストア掲載情報の整合性が確認される^*1。リジェクトを想定せずスケジュールを組むと、再申請・追加対応のための工数が確保できず、公開期限を守れない状況が生まれる。事前にリジェクト時の差し戻し対応工数を、スケジュールに織り込む必要がある。

注意点2：権限・バックグラウンド処理の仕様変更を見落とすと既存機能が停止する

新しいAPIレベルでは、位置情報・通知・バックグラウンド実行・写真ピッカーなどの権限取扱いが変わることがある^*1。実装変更の影響範囲はアプリの機能横断に及ぶため、影響調査を実装作業に先立って独立工程として実施することが、機能停止リスクの抑制につながる。

注意点3：実機検証カバレッジを下げると本番環境で初めて不具合が判明する

OS更新後の挙動はメーカー・機種・OSバージョンの組み合わせにより差が出る。社内の検証端末だけでは網羅できないケースもある。検証対象機種をリリース計画段階で定義し、必要なら外部の検証サービスやレンタル端末を組み合わせる対応が求められる。

委託先選定で見るべき評価軸：実績・対応スピード・継続体制

Androidアップデート対応を外注する場合の委託先選定では、以下の評価軸を比較材料にする。

評価軸を整理することで、価格だけで判断する状況を避けられる。とくにアップデート対応は「単発の修正」ではなく「毎年・毎月の継続対応」のため、継続体制の評価がのちのちのコスト・品質に効いてくる。

自社で着手するときの実践ステップ：影響調査からリリースまで

ステップ1：対象APIレベル・OSの差分整理 — Googleの公式情報で対応範囲を確定

まずAndroid Developersや対象APIレベルに関するヘルプを参照し、自アプリのAPIレベルから最新要件までの差分を整理する^*1。整理対象は権限・ストレージ・通知・バックグラウンド・写真ピッカーなど、APIレベル変更で挙動が変わる項目である。影響範囲の一覧を作ったうえで、対応の優先順位を決める。

ステップ2：影響調査と修正方針策定 — 機能停止リスクの大きい箇所から着手

差分整理を踏まえ、自アプリのコードベース・SDK・サードパーティライブラリの依存関係を調査する。位置情報・写真選択・通知などユーザー体験への影響が大きい機能から修正方針を決定し、改修の優先順位を確定する。

ステップ3：実装と単体テスト — 検証カバレッジを事前に定義

修正方針に従って実装を進めながら、機能横断のテスト計画を作る。検証対象のOSバージョン・機種・利用シナリオを事前に定義することで、本番環境での不具合発生を抑えられる。

ステップ4：実機検証とリグレッション確認 — 過去仕様の維持を併せて確認

新OS・新APIレベルでの動作確認と並行して、既存ユーザーが利用するOSバージョンでの挙動も検証する。回帰テストの工数を初期計画に含めることで、リリース直前の手戻りを防げる。

ステップ5：公開審査と本番リリース — リジェクト発生時の差し戻し工数を確保

Google Playへの審査提出後、リジェクト発生時に追加対応できる工数とスケジュールバッファを確保しておく。公開後はクラッシュレポート・ストアレビュー・サポート問い合わせを観測し、必要に応じて修正リリースを実施する流れになる。

内製と外注の比較：必要スキル・工数・継続性をどう判断するか

Androidアップデート対応を内製で完結させるには、Android SDK・Kotlin（Androidの主要なアプリ開発言語）・Gradle（Androidのビルド管理ツール）・Google Play Console・Android Studioに加え、対象APIレベル要件の継続的なキャッチアップが必要である^*1。年次・月次の追従作業を、新機能開発と並行して回す体制を整える必要がある。

一方で外注する場合は、評価軸（実績・対応スピード・継続体制）の比較に時間を要する半面、社内人材の異動や退職に左右されにくい継続性を確保しやすい。経済産業省・IPAが公開する「情報システム・モデル取引・契約書」では、企画段階は準委任契約（仕事の完成ではなく業務の遂行を約束する契約形態）、開発工程は請負契約（仕事の完成を約束する契約形態）とするモデルが提示されており、保守運用編も整備されている^*4。アップデート対応の継続性を担保するには、保守運用編の考え方を踏まえた契約設計が役立つ。

判断の出発点は「年次・月次の継続対応を、新機能開発と分けて回し続けられるか」である。回せる体制が社内にあれば内製、回し続ける負荷が大きい場合は外注を中心に検討する流れになる。

まとめ：Androidアップデート対応外注の3つの判断軸

Androidアップデート対応外注の判断軸は3点に整理できる。1点目は、Google Playの対象APIレベル要件・毎年のOSメジャーバージョン公開・毎月のセキュリティ情報という3つの追従対象を継続して回す体制の有無である^*1*2*3。2点目は、審査・権限・互換性という3領域への備えであり、影響調査・実機検証・差し戻し対応を独立工程としてスケジュールに組み込めているかで差が出る。3点目は委託先の選定基準で、実績・対応スピード・継続体制を評価し、経済産業省・IPAのモデル契約を踏まえた契約形態を選ぶ^*4。アップデート対応は単発作業ではなく年次・月次の継続業務であり、この追従を新機能開発と分けて回し続けられるかが、内製と外注の分岐点となる。

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Google「Google Play アプリの対象 API レベルに関する要件」（2025年）
2. *2　出典：Google「Google Pixel にソフトウェア アップデートが提供されるタイミング」（2025年）
3. *3　出典：Android Open Source Project「Android Security and Update Bulletins」（2025年）
4. *4　出典：独立行政法人情報処理推進機構（IPA）「情報システム・モデル取引・契約書（第二版）」（2020年公開・2025年4月更新）

Tweet