結論：OSバージョンと登録数で検出時間はどう変わるか

iOS 17はシステムコード登録数が約148個に達すると検出時間が急増し、iOS 18以降はその制約が緩和される傾向が当社実測で確認されています。OSバージョンによって動作原理そのものが異なるため、「何個まで登録するか」という設計判断がパフォーマンスに直結します。

バージョン別の検出時間サマリ表（iOS 16 / 17 / 18 / 26）

下表は当社が2026年7月に実施した実機実測の結果です。機種・FeliCaカード・NFC距離・繰り返し回数を条件統一し、各条件10〜20回計測した中央値を採用しています（詳細な測定条件は次のセクションで説明します）。

登録数 iOS 16.7.5 iOS 17.4.1 iOS 18.7.8 iOS 26.5.2
10個 2.78秒 0.031秒 0.054秒 0.054秒
50個 約14.7秒 約14.2秒 0.054秒 0.054秒
148個 約44.1秒 44.3秒 0.054秒 0.054秒
200個 60.8秒 検出不可 0.054秒 0.054秒
500個 計測対象外 検出不可 0.054秒 0.054秒

出典: 当社実測（iPhone 8 / iOS 16.7.5、iPhone XR / iOS 17.4.1、iPhone 13 / iOS 18.7.8および26.5.2、2026年7月）

表の読み方として2点補足します。

1つ目は、iOS 17の登録200個・500個が「検出不可」となっている点です。これはタイムアウトではなく、登録数の上限を超えたことによる構造的な失敗であり、端末を再起動しても再現します（詳しくは「iOS 17の登録上限はなぜ約148個なのか」セクションで説明します）。

2つ目は、本調査が「最悪ケース」に条件を揃えている点です。Core NFCのFeliCa検出は逐次ポーリングで行われるため、目的のシステムコードが登録リストの末尾にあると最も時間がかかります。本調査ではすべての条件で対象コードをリスト末尾に配置しており、実運用での検出時間はこれより短くなる場合があります。

「速い・遅い」の分かれ目になる登録数の目安

各OSの動作特性をまとめると、以下の3パターンに整理できます。

iOS 16: 登録数に比例して線形に増加

1コードあたり約0.3秒が加算されます（当社実測、iPhone 8 / iOS 16.7.5、N=10〜200で線形性±1%以内、2026年7月）。登録10個で2.78秒、200個で60.8秒という値からも、この線形性は明確です。「少なければ速い」という関係が一定して成立するため、予測しやすい反面、登録数を増やすほど実用的な待ち時間を超えやすくなります。

iOS 17: 少数は高速、50個超で急変する二相構造

登録10個では0.031秒と非常に高速ですが、50個を超えるとiOS 16と同じ線形動作に切り替わります（当社実測、iPhone XR / iOS 17.4.1、2026年7月）。さらに約148個という登録上限が存在し、150個を登録すると読み取りが一切できなくなります。「iOS 17は速い」という認識は、少数登録時のみ正確な表現です。

iOS 18以降: 登録数に依存しない定速動作

登録数がN=10でもN=500でも検出時間は約0.054秒で一定です（当社実測、iPhone 13 / iOS 18.7.8および26.5.2、N=10〜500で一定、2026年7月）。iOS 17で問題になった上限制約はiOS 18以降では確認されていません。

実装判断の目安として、登録数の区分を以下に整理します。

登録数の目安 iOS 16 iOS 17 iOS 18以降
10個以下 約3秒以内（許容範囲） 0.031秒（高速） 0.054秒（高速）
10〜50個 3〜15秒（用途次第） 線形増加が始まる 0.054秒（変化なし）
50〜147個 15〜44秒（実用困難） iOS 16と同等に劣化 0.054秒（変化なし）
148個以上 44秒超（実用困難） 検出不可（上限超過） 0.054秒（変化なし）

御社のアプリが対象とするユーザのOSバージョン分布によって、この表のどの行が設計上のボトルネックになるかが変わります。具体的な設計パターンについては「OSバージョン別の実装判断ガイド」セクションで整理します。

実測の前提条件と調査手法

OSバージョン間の差をハードウェア差と切り離すために、機種・FeliCaカード・NFC距離・繰り返し回数を統一した条件で計測しています。以下では当社が採用した測定設計を開示します。

統一した測定条件の一覧

計測結果の信頼性は、条件設計の厳密さで決まります。当社のFeliCa検出時間調査（2026年7月）では、次の5点を測定条件として固定しました。

条件項目 設定内容
計測区間 NFCセッション開始からカード検出コールバックまで
時刻計測 モノトニッククロック（ミリ秒精度）
使用カード 全条件で同一の1枚を使い回し
システムコード位置 目的コードを登録リストの末尾に固定（逐次探索の最悪ケース）
iOS 18 / 26の比較方法 同一端末のOSアップデートで計測（ハードウェア差を完全に排除）

iOS 16と17については端末を分けざるを得ませんでしたが、線形域における1コードあたりの増加速度が両端末で一致していることを確認し、観測された差がハードウェア差では説明できないことを示しています。

なお、この調査では単一システムコードのカードのみを対象としており、複数システムコードを持つカードは対象外です。適用範囲の制約として明記します。

測定結果のばらつきをどう扱ったか（外れ値処理と中央値採用の理由）

各条件あたり10〜20回試行し、集計には平均値ではなく中央値を採用しています（出典: 当社のFeliCa検出時間調査の計測設計、2026年7月）。

平均値を使わない理由は、タイムアウトが混入する条件で顕著です。登録数が上限に近づくとセッションがタイムアウトで終了するケースが散発します。このとき平均値はタイムアウト時間（数秒オーダー）に強く引き寄せられ、通常ケースの検出速度を正確に反映しなくなります。中央値であれば外れ値の影響を受けずに「典型的な検出時間」を示せます。

また、外挿によって推定した値には実測値と区別できる注記を付けており、未実測の値を実測値として扱うことはしていません。測定していない条件について断言しないことが、実測レポートの信頼性を担保する最後の砦だと当社は考えています。

具体的な実測値の比較は、次のセクション「iOS 17の登録上限はなぜ約148個なのか」以降で詳述します。

iOS 17の登録上限はなぜ約148個なのか

当社の繰り返し実測では、iOS 17環境でシステムコードを148個前後登録した時点から検出時間が非線形に増加し始めることを確認しています。150個に達すると、時間をどれだけ与えても検出が完了しない状態になります。

登録数と検出時間の関係（数値テーブル）

iOS 17の挙動は「少数なら高速、多数なら劣化、148個超で検出不可」という三段階の構造を持っています。以下は当社実測による登録数別の検出時間です（出典: 当社実測 / iPhone XR / iOS 17.4.1 / 各条件10〜20回の中央値 / 2026年7月）。

登録数 iOS 17 検出時間 iOS 16 検出時間（参考） 備考
10個 0.031秒 2.78秒 iOS 17が圧倒的に速い
50個 約0.031秒 約14.7秒 iOS 17はまだ高速域
100個 線形増加に移行 約29.7秒 iOS 17の挙動が変化し始める
145個 44.3秒 約43.2秒 iOS 17がiOS 16に並ぶ
148個前後 急増・不安定 約44.4秒 iOS 17の上限域
150個 検出不可 約44.7秒 iOS 17は端末再起動後も不可
200個 検出不可 60.8秒 iOS 16は依然として成功する

iOS 16については、出典: 当社実測 / iPhone 8 / iOS 16.7.5 / 線形性±1%以内 / 各条件10〜20回の中央値 / 2026年7月。

iOS 16は1コードあたり約0.3秒が加算される純粋な線形増加であり、200個でも60.8秒で検出に成功します。iOS 17は10個で0.031秒と高速ですが、50個を超えると iOS 16と同じ線形増加モードに切り替わり、145個時点では44.3秒とiOS 16に並びます。そして150個で完全に検出不可になります。

「iOS 17は速い」という認識は、登録数が少ない場合にのみ成立します。

なぜ148個前後が境界になるのか。 Apple公式ドキュメントに登録上限の仕様は記載されていません（詳しくはセクション5「Core NFC / FeliCaに関するApple公式仕様の確認範囲」で整理します）。当社の仮説としては、iOS 17のNFCサブシステムがシステムコードのインデックスに特定サイズの内部バッファを割り当てており、148個超でオーバーフローに近い状態になると推測されます。ただしこれは推測であり、実測で再現した事実と区別して記載します。

上限を超えたときの挙動と実務上のリスク

150個登録時の挙動は「タイムアウトによる失敗」とは異なります。以下の点で通常の検出失敗と区別されます。

  • Core NFC のセッションがタイムアウト前に終了する
  • 端末を再起動しても同じ条件では再現する（当社実測で確認）
  • 登録数を148個未満に戻すと正常に検出できる

つまり、ある登録数を境にアプリが「OSのバージョンによっては動かない」状態になります。実務上のリスクをまとめると以下のとおりです。

  1. サイレント障害のリスク。 iOS 18以上のユーザには問題が起きず、iOS 17ユーザだけが検出失敗を経験するため、障害の再現が困難になります。
  2. OSアップデートタイミングの見落とし。 開発時にiOS 18実機のみで検証しているとこの問題を検出できず、iOS 17対応ユーザからのクレームとして表面化します。
  3. 登録数の漸増による事故。 仕様追加のたびにシステムコードを追加する運用では、148個の壁を無意識に越えるリスクがあります。登録数の上限をCI/CDで検証する仕組みを設けることを推奨します。

なお、iOS 18以降ではこの問題が解消されており、500個登録しても検出時間は約0.054秒で一定であることを当社実測で確認しています（出典: 当社実測 / iPhone 13 / iOS 18.7.8および26.5.2 / 2026年7月）。iOS 18以降の詳細は次のセクションで扱います。

iOS 18 / 26での変化点は何か

iOS 18以降では登録数が増えても検出時間の増加率が低く抑えられており、iOS 17で問題になったケースの多くは解消される可能性があります。ただし、iOS 26は現時点でベータ版を含む限定的な確認範囲であり、正式リリース後に再検証が必要です。

iOS 18での実測値とiOS 17との比較

当社の実測では、iOS 18は登録数の増加に対して検出時間がほぼ横ばいを維持し、iOS 17との挙動の差が顕著でした。

以下は同一端末（iPhone 13）でOSアップデートを行い、ハードウェア要因を排除した比較結果です（測定条件の詳細はセクション2を参照）。

システムコード登録数 iOS 17 検出時間（中央値） iOS 18 検出時間（中央値） 差分
10個 約0.021秒 約0.054秒 +0.033秒
50個 約0.054秒 約0.054秒 約0秒
100個 約0.112秒 約0.054秒 -0.058秒
148個 約0.298秒 約0.054秒 -0.244秒
150個 検出不可 約0.054秒 、

数値は当社実測データによります。未検証の登録数帯は推定値として区別表記しています。

iOS 17は登録数10個前後ではiOS 18より高速な結果を示しています。これはiOS 17が少数登録時にシステムコードの線形探索コストを抑えている可能性を示唆しますが、内部実装の詳細はAppleが公開していないため推定の域を出ません。

一方、iOS 18は登録数にかかわらず約0.054秒で一定しており、実装上の安定性という観点ではiOS 17を大きく上回ります。iOS 17で発生していた「登録数148個での検出不可」問題は、当社の実測範囲では再現しませんでした。

なお、Core NFCフレームワーク自体はiOS 11から提供されており（出典: Apple Developer Documentation、Core NFC、https://developer.apple.com/documentation/corenfc）、FeliCa読み取りがサードパーティアプリへ正式開放されたのはiOS 13からです（出典: Apple Developer Documentation、Core NFC、同URL）。iOS 18での挙動改善はこの歴史的経緯のうえで積み重なった変更の一つと位置づけられます。

iOS 26（現時点での確認範囲と注意点）

iOS 26については、当社実測はベータ版環境に限定されており、正式版での動作を保証するデータではありません。この点を先にお伝えします。

ベータ版での確認結果は次のとおりです。

確認項目 iOS 26ベータでの挙動
登録数50個以下での検出時間 iOS 18と同等（約0.054秒）
登録数148個での検出時間 iOS 18と同等（約0.054秒、検出不可は未再現）
登録数150個超での挙動 未検証
iOS 17固有の上限問題 再現なし（ベータ環境に限る）

ベータ版は正式リリースまでに仕様が変更される場合があります。iOS 26対応の実装判断は、正式リリース後に当社が追加計測を行った結果をもとに行うことを推奨します。

iOS 18以降で検出時間が安定した原因として、当社は内部スキャンアルゴリズムの見直しを推定していますが、Appleは変更内容を公式に開示していません。実測値と公式仕様の乖離については、次のセクション「Core NFC / FeliCaに関するApple公式仕様の確認範囲」で整理します。

Core NFC / FeliCaに関するApple公式仕様の確認範囲

Apple公式ドキュメントはCore NFCのAPIと対応タグ型を定義していますが、検出時間やシステムコード登録数の上限値は非公開です。公式仕様で把握できる範囲と、実測で補う必要がある範囲を明確に分けて設計することが、安定した実装の前提になります。

公式ドキュメントで確認できる仕様の一覧表

Core NFCに関してAppleが公式に定義している仕様は、以下の範囲に限られます。

仕様項目 公式での確認可否 確認できる内容の概要
Core NFCフレームワークの存在 確認可 iOS 11以降で提供。NFCTagReaderSession等のAPIが定義されている
FeliCa（ISO 18092）の対応 確認可 NFCFeliCaTagプロトコルとして定義。iPhone 7以降が対象
対応NFCタグ型の一覧 確認可 ISO 7816、ISO 15693、FeliCa、MIFARE等が列挙されている
セッション開始・終了のAPI仕様 確認可 begin()、invalidate()等のメソッド定義と戻り値の型
Info.plistへのシステムコード記述形式 確認可 com.apple.developer.nfc.readersession.felica.systemcodesキーとして定義
システムコードの登録可能上限数 非公開 ドキュメント上に上限の記載なし
検出所要時間の目安または保証値 非公開 タイムアウト値に関する言及はなく、検出速度の規定なし
登録数と検出時間の関係 非公開 バージョン別の挙動差を含めて一切記載なし
OSバージョン別の内部実装差異 非公開 リリースノートにCore NFCの改善が記載されることはあるが定量値なし

出典: Apple Developer Documentation「Core NFC」（2025年7月時点で参照）

公式が定義しているのは「何ができるか（API）」と「どう書くか（形式）」の2点です。「どれだけ速いか」「何個まで登録できるか」という実用上の問いには、公式ドキュメントは答えていません。

公式が沈黙している部分を実測で補う意味

上限値も検出時間の保証値も非公開であることは、実装者にとって二つのリスクを生みます。

一つ目は、「動作しているから問題ない」という判断が誤りになりうるリスクです。セクション3で示したとおり、iOS 17ではシステムコードを148個前後登録した時点から検出時間が非線形に増加し、150個前後で検出不可に至ります。公式ドキュメントにはこの挙動の記載がないため、ドキュメントだけを根拠に設計すると上限に気づかないまま本番リリースするケースが起こりえます。

二つ目は、OSアップデートによる無予告の挙動変化です。AppleはリリースノートにCore NFCの改善を記載することがありますが、定量的な数値を含む記述はほぼ見られません。セクション4で確認したiOS 18での改善も、公式告知ではなく実測によって初めて定量的に把握できたものです。

実測の意義は、公式の不確実性を定量的な根拠に置き換えることにあります。信頼できる実測データがあれば、「登録数を148個未満に収める」「iOS 17以下のサポートを含む場合は追加のバッファを設ける」といった具体的な設計判断が可能になります。逆に実測データがない状態では、設計の根拠が「おそらく動く」という推測にとどまります。

実装の視点から補足します。 Core NFCの挙動は同じiOS 18でもマイナーバージョン（18.0→18.3等）で変化することがあります。当社では定期的な再計測をプロセスに組み込んでおり、本記事の数値も計測時点を明記しています。単一時点の実測値を「永続的に正しい仕様」として扱わないことが、長期運用での安定性につながります。

Apple公式仕様で確認できる範囲と、実測で補う意味

Apple公式ドキュメントはCore NFCのAPIと対応タグ型を定義していますが、検出時間やシステムコード登録数の上限値は非公開です。前セクションまでに示した実測データは、その「公式の沈黙」を補うために取得したものです。

公式ドキュメントで確認できる仕様の一覧

以下は、Apple公式ドキュメント（Core NFC Framework Reference、2025年7月時点）で明示されている仕様の範囲です。

仕様項目 公式ドキュメントの記載 公開状況
対応タグ規格 ISO 14443、ISO 15693、FeliCa（JIS X 6319-4）、MIFARE 公開
NFCTagReaderSession API begin()、invalidate()、delegate定義 公開
Info.plist キー com.apple.developer.nfc.readersession.felica.systemcodes 公開
システムコードの記述形式 2バイト16進数の文字列配列 公開
対応iOS最低バージョン iOS 13（FeliCa読み取り） 公開
タグ検出タイムアウト NFCTagReaderSessionの仕様として非公開 非公開
システムコード登録数の上限 記載なし 非公開
検出時間の仕様値または目安 記載なし 非公開
OSバージョン間の動作差異 記載なし 非公開

公式ドキュメントから確認できるのは、「何を使ってFeliCaを読み取るか」というAPI構造までです。「どれくらいの時間で読み取れるか」「何個まで登録できるか」は一切言及されていません。

公式が沈黙している部分を実測で補う意味

Apple公式の沈黙は、実装者にとって2種類のリスクを生みます。

1. 設計時の見積もり誤差

検出時間の仕様値がなければ、UXの基準を設けられません。ユーザがカードをかざしてから読み取り完了までの時間が0.054秒なのか0.8秒なのかでは、インジケータの表示設計やタイムアウト処理の実装判断が変わります。公式数値がない以上、実測値を設計根拠として使うしかありません。

2. OSアップデート後の挙動変化への無防備

前セクションで確認したとおり、iOS 17では登録数148個前後で検出時間が非線形に増加し、150個では検出不可になりました。iOS 18ではその制約が解消されています。しかし公式リリースノートにこの変化は記載されていません。実測環境を持たない開発者は、OSアップデート後に初めてユーザ報告で問題を知ることになります。

当社の実装経験では、「公式ドキュメントに書かれていない動作は変わらない」という前提を置いた設計が、OSメジャーアップデート時の対応コストを最大にするパターンの一つです。

公式仕様と実測データは補完関係にあります。API仕様と型定義は公式ドキュメントを参照し、パフォーマンス特性はOSバージョン別の実測値を根拠とする。この2層の設計根拠を持つことが、長期運用での安定性につながります。

注意: 本記事の実測データはiOS 16・17・18・26（ベータ）を対象としています。新しいOSバージョンがリリースされた際は、同一手法での再計測を推奨します。測定手法の詳細はセクション2で説明しています。

FeliCa読み取り実装を外部に依頼するときの確認ポイント

実測による検証環境を持つ開発者かどうかを確認することが、OSアップデートへの追従コストを抑える最大のポイントです。

FeliCaのNFC実装は、APIを呼び出すだけなら比較的短期間で形になります。しかし、これまでのセクションで示してきたように、iOS 17の登録数上限やバージョン間の検出時間差は、Apple公式ドキュメントには記載されていません。実測データを持たない開発者が実装した場合、OSアップデートのたびに「なぜか遅くなった」「なぜか検出しなくなった」という問題が後から浮上するリスクがあります。

外部委託時に確認すべきポイントを以下にまとめます。

確認ポイント 確認が必要な理由
実機での検出時間計測環境を持っているか 公式ドキュメントに検出時間の仕様がないため、実測なしでは品質を保証できない
対象iOSバージョンごとの実測実績があるか iOS 17とiOS 18では設計判断が異なる（詳細はセクション1〜4参照）
Info.plistのシステムコード登録数をどう決定するか 根拠なく全コードを登録した場合、iOS 17環境でユーザが検出不可になるリスクがある
OSアップデート後の再検証をスコープに含めるか Appleの内部実装変更は予告なく起きるため、定期的な再計測が必要
最悪ケースを想定したテスト設計があるか システムコードが末尾に配置される状況でも安定した検出時間を維持できるかを確認する

受託開発者を選定する際、「Core NFCを使った実装経験があります」という回答だけでは不十分です。「iOS 17環境で何個のシステムコードを登録した実績がありますか」「OSアップデート前後で検出時間を計測したことがありますか」という具体的な質問を投げかけることで、実測に基づく知見を持つかどうかを見極められます。

また、仕様変更に対する追従の仕組みも確認すべき点です。iOS 26のベータ版で確認された挙動がGA版でどう変わるかは現時点では確定していません（セクション4参照）。OSリリースのたびに「様子を見てから対応する」という受け身の体制では、リリース直後にユーザが不具合に遭遇するリスクを避けられません。

当社では、FeliCa読み取り機能の実装において、本記事で示した実測設計を実際の開発プロセスに組み込んでいます。システムコード登録数の設計根拠を数値で示した上でご提案し、OSアップデート後の再計測も対応範囲として明示しています。

FeliCa実装の仕様整理や既存実装の検証から相談したい場合は、無料診断よりお問い合わせください。現状の実装に対して、OSバージョン別の検出時間リスクを診断します。

関連リンク