この記事の要点
- プッシュ通知とは、アプリを開いていなくても、サーバ側から端末へ知らせを届ける仕組みです。自社のサーバが端末へ直接送るのではなく、Apple の APNs や Google の FCM などの通知サービスを経由して届けます。
- 端末を宛先として指定するために、アプリは通知サービスからトークン(APNs ではデバイストークン、FCM では登録トークン)を受け取り、自社のサーバに渡しておきます。
- 端末側が一定の間隔でサーバに新着を問い合わせるポーリングと違い、新着があるときにサーバ側から知らせるため、無駄な問い合わせを減らせます。
- モバイル2級の出題カテゴリ「モバイルインターネットとモバイルコンテンツ技術」(公式の比率は20%)に当たる範囲です。
プッシュ通知とは、一言でいうと何なのか?
一言でいうと、「サーバ側から始める知らせ」を、OSの通知サービスに仲立ちしてもらって端末に届ける仕組みです。メッセージの着信、予約の確認、配送の状況など、利用者が画面を開いていないときに知らせたい用途で使われます。
スマホは電池を長持ちさせるため、使っていないアプリの動作や通信を制限することがあります。各アプリがばらばらにサーバとつながり続けると電力も通信も余計にかかるため、通知は OS の提供者が運営する通知サービスを通して届けるのが基本の形です。
通知サーバを介して、どんな順番で届くのか?
APNs・FCM に共通する流れを、当サイトが4段階に整理しました。
- トークンの取得:アプリが端末上で通知サービスに登録し、その端末のそのアプリを表すトークンを受け取る。
- トークンの登録:アプリがトークンを自社のサーバ(プロバイダ、アプリケーションサーバ)に送り、利用者と結び付けて保存する。
- 送信の依頼:知らせたいことが起きたら、自社のサーバがトークンと本文を付けて通知サービスに送信を依頼する。
- 配信と表示:通知サービスが端末へ届け、OS が通知を表示する(またはアプリにデータを渡す)。
| 項目 | APNs | FCM | Web プッシュ |
|---|---|---|---|
| 運営・規格 | Apple | Google(Firebase) | IETF の RFC 8030 など |
| 宛先の指定 | デバイストークン | 登録トークン | 購読(サブスクリプション)の URI |
| 送る側 | プロバイダサーバ | 信頼できるサーバ環境(Admin SDK など) | アプリケーションサーバ |
| 送る側の認証など | トークン方式(JWT)または証明書方式 | サーバの認証情報 | VAPID(RFC 8292)で送り手を示せる |
| 補足 | HTTP/2 で送信を依頼する | Apple の端末へは APNs を通して届ける | iOS・iPadOS では 16.4 からホーム画面の Webアプリで利用可 |
← 表は横にスクロールできます →
Firebase の公式ドキュメントは、FCM が実際の配信を各プラットフォームの経路に任せ、Android 端末には Android の転送層、Apple の端末には APNs、Web には Web プッシュのプロトコルを使うと説明しています。つまり、FCM で iPhone に送る場合も、最終的には APNs を通るという点が取り違えやすいところです。
ポーリングとは、何が違うのか?
ポーリングは、端末側が一定の間隔でサーバに「新しい知らせはありますか」と問い合わせる方式です。仕組みが単純な反面、新着がなくても問い合わせが発生し、間隔を短くすると電力と通信が増え、長くすると知らせが遅れます。
| 項目 | プッシュ通知 | ポーリング |
|---|---|---|
| 通信を始める側 | サーバ側(通知サービス経由) | 端末側 |
| 新着がないとき | 送らないので通信は発生しない | 問い合わせの通信が発生する |
| 知らせの速さ | 新着が出たときに届けられる | 問い合わせの間隔しだいで遅れる |
| 必要なもの | 通知サービスへの登録とトークン | 問い合わせ先のサーバだけ |
| 向く場面 | いつ起きるか分からない知らせ | 決まった間隔で状態を確かめたい場合 |
← 表は横にスクロールできます →
IoT の分野で使われる MQTT も、送り手と受け手の間を仲介役(ブローカ)が取り持つ点でプッシュ通知と考え方が似ています。違いはMQTTとはで整理しています。
Android 13(API レベル33)以降、アプリが通知を出すには実行時の権限(POST_NOTIFICATIONS)が必要になりました。仕組みとして届けられても、利用者が許可しなければ表示されない点も押さえておきましょう。
モバイル2級では、どの範囲で、どう問われそうか?
MCPC の公式ページの図では、モバイルシステム技術検定 2級(100問・100分・4者択一)の出題カテゴリの一つ「モバイルインターネットとモバイルコンテンツ技術」の比率が20%と示されています(2026年9月27日確認)。当サイトでは、公式テキスト『モバイルシステム技術テキスト 第11版』の第9章「モバイルインターネットとコンテンツ技術」がこの範囲に当たると推定しています(章名からの当サイトの判断で、公式の対応表ではありません)。
4択での問われ方は、次のような型が考えられます。出題頻度の公式データはありません。
- 流れの順序:トークンの取得・登録・送信の依頼・配信の順番を問う。
- サービス名と提供者:APNs と FCM がどの会社の、どのOS向けのサービスかを問う。
- ポーリングとの違い:通信を始める側や、新着がないときの通信の有無を問う。
- Web プッシュ:ブラウザ向けの通知の仕組みと PWA の関係を問う。
ブラウザの通知を支える Service Worker はPWAとは、通知の権限を含むOSの仕組みはAndroidとiOSのアーキテクチャの違いで扱います。試験全体はモバイルシステム技術検定2級とはへ。
どこで取り違えやすいのか?
選択肢を読んだら、「誰が誰に送るのか」を矢印で書き出すと取り違えが減ります。
| 取り違え | 正しい考え方 | 確認する問い |
|---|---|---|
| 自社サーバが端末へ直接送る | 自社サーバは通知サービスに送信を依頼し、通知サービスが端末へ届ける | 端末へ届けるのは誰か |
| FCM で送れば iPhone でも APNs は不要 | FCM は Apple の端末へは APNs を通して届ける | 最後の配信の経路はどこか |
| トークンは利用者のパスワード | トークンは端末上のアプリを宛先として表す値 | 何を識別する値か |
| プッシュは端末が定期的に問い合わせる | 定期的に問い合わせるのはポーリング | 通信を始めるのは端末か、サーバか |
| 届けば必ず表示される | Android 13 以降は通知の権限を利用者が許可する必要がある | 権限の条件が書かれていないか |
← 表は横にスクロールできます →
確認問題1:通知が届く順番を並べられるか?
スマートフォンのアプリでプッシュ通知を届けるまでの流れとして、最も適切な順番はどれか。
- 自社サーバが端末へ直接送信 → アプリがトークンを取得 → 通知サービスへ登録 → 端末で表示
- アプリがトークンを取得 → 自社サーバへ登録 → 通知サービスへ送信を依頼 → 端末へ配信
- 通知サービスが端末へ配信 → 送信を依頼 → アプリがトークンを取得 → 自社サーバへ登録
- アプリが一定間隔で自社サーバに問い合わせ → 新着を取得 → 通知サービスへ転送 → 端末で表示
正解:2。アプリが通知サービスからトークンを受け取って自社サーバに渡し、自社サーバがそのトークンを付けて通知サービスに送信を依頼し、通知サービスが端末へ届けるのが基本の流れです。
1は自社サーバが端末へ直接送るとしている点と、トークンの取得より先に送信している点が誤りです。3は配信が最初に来ており、宛先のトークンがないまま送ることになります。4はポーリングの流れで、通知サービスを経由するプッシュ通知とは違います。
確認問題2:ポーリングとの違いを説明できるか?
プッシュ通知とポーリングに関する記述として、最も適切なものはどれか。
- プッシュ通知は、端末側のアプリが一定の間隔でサーバに新着を問い合わせる方式である
- ポーリングは、通知サービスから受け取ったトークンがなければ一切利用できない方式である
- プッシュ通知は、新着がなくても一定の間隔で端末へ通信が発生するため電力を多く使う
- ポーリングは、新着がなくても端末からの問い合わせが発生し、間隔しだいで知らせが遅れる
正解:4。ポーリングは端末側が一定の間隔でサーバに問い合わせるため、新着がなくても通信が発生し、間隔を長くすると知らせが遅れます。
1はポーリングの説明をプッシュ通知に当てはめた誤りです。2はトークンが必要なのはプッシュ通知の側で、ポーリングは問い合わせ先のサーバがあれば使えます。3はポーリングの性質をプッシュ通知に当てはめた誤りで、プッシュ通知は新着があるときに送ります。
確認問題3:Web プッシュの仕組みを選べるか?
IETF の RFC 8292 で定められた VAPID の説明として、最も適切なものはどれか。
- アプリケーションサーバが、署名したトークンを使ってプッシュサービスに自らを示す仕組み
- ブラウザが、受け取った通知の本文を画面に表示するときの文字の大きさを決める仕組み
- プッシュサービスが、端末の位置情報をもとに、通知を届ける順番を並べ替える仕組み
- 利用者が、通知を受け取る時間帯をブラウザの設定画面で指定するための共通の仕組み
正解:1。RFC 8292(2017年11月)は、アプリケーションサーバが署名付きのトークン(JWT)と公開鍵を使って、プッシュサービスに自らを自主的に示す方法を定めています。これにより、プッシュサービスは送り手を区別し、購読を特定のサーバに限ることなどができます。
2は表示の見た目の話で、送り手の識別とは関係がありません。3の位置情報による並べ替えは、VAPID の目的ではありません。4は利用者側の設定の話で、サーバとプッシュサービスの間の仕組みではありません。
同じ「モバイルインターネットとモバイルコンテンツ技術」の問題を本番と同じ4択で試すなら、登録不要のモバイル2級の無料お試し20問で解説まで確認できます。
よくある質問
APNs と FCM は、どちらか一方だけ覚えればよいですか?
両方の役割を区別できるようにしておくのが安全です。APNs は Apple の端末向けの通知サービス、FCM は Google(Firebase)の通知サービスで、Apple の端末へ送るときは APNs を通して届けます。名前と提供者の組合せを入れ替えた選択肢に注意してください。
Web プッシュの登場人物は誰ですか?
RFC 8030 は、通知を受け取るユーザーエージェント(ブラウザなど)、通知を届けるプッシュサービス、配信を依頼するアプリケーションサーバの3者を定めています。スマホアプリの「端末・通知サービス・自社サーバ」と同じ形で整理できます。
プッシュ通知は必ず届きますか?
必ず届くとは限りません。端末の電源や通信の状態、利用者の通知の許可、OS の省電力の制御などによって、届くのが遅れたり表示されなかったりします。選択肢の「必ず」「確実に」には注意してください。
出典・参考
- [1]MCPC モバイルシステム技術検定[2級]CBT方式(出題カテゴリの図・形式)確認 2026-09-27
- [2]MCPC 検定テキスト(モバイルシステム技術テキスト 第11版)確認 2026-09-27
- [3]Firebase: FCM architectural overview 確認 2026-09-27
- [4]Apple Developer: Setting up a remote notification server(APNs)確認 2026-09-27
- [5]IETF RFC 8030: Generic Event Delivery Using HTTP Push(2016年12月)確認 2026-09-27
- [6]IETF RFC 8292: Voluntary Application Server Identification (VAPID) for Web Push(2017年11月)確認 2026-09-27
- [7]Android Developers: Notification runtime permission(Android 13)確認 2026-09-27
- [8]WebKit: Web Push for Web Apps on iOS and iPadOS(2023年2月)確認 2026-09-27
本番と同じペースで腕試し
記事の次は、本番形式の問題で。
公式の出題カテゴリの比率どおりに組んだ無料お試しを、登録不要・カード不要で解けます。続きの模試と章別ドリルは買い切りで、月額はかかりません。
あわせて読みたい
当サイトは、モバイルコンピューティング推進コンソーシアム(MCPC)とは関係のない個人が運営する非公式の学習教材です。掲載している問題はすべて当サイトのオリジナルで、実際の試験問題・過去問題・再現問題ではありません。試験の日程・受検料・出題範囲は公式サイト(https://www.mcpc-jp.org/license/ )で必ず確認してください。合格を保証するものではありません。合格の目安は当サイトの推定です。技術・制度の記述は「最終確認日」時点のものです。