Expo SDK 56で刷新された開発体験と新機能の全体像と注目ポイント

Expo SDK 56で刷新された開発体験と新機能の全体像と注目ポイント

Expo SDK 56は、React Native 0.85.2およびReact 19.2.3を採用し、ネイティブモジュール開発からアプリ配信まで広い領域で改善を盛り込んだメジャーアップデートです。ベータが先行公開されており、安定版に向けて検証が進んでいる状況にあります。本章では、リリース時期の位置づけ、技術基盤の刷新内容、stable昇格となったライブラリ群、開発者体験を変える主要アップデート、そしてエコシステムが進む方向性までを段階的に整理します。

Expo SDK 56ベータ公開時期とリリースサイクルの位置づけの整理

Expo SDK 56は、2026年5月にベータ版が公開されました。ベータ期間はおおむね2週間が予定されており、開発者は本番環境への影響を確認しながらフィードバックを送れる仕組みになっています。Expoは年3回のメジャーリリースを基本サイクルとして運用しており、SDK 56はSDK 55に続く位置となるリリースです。リリース直後はExpo Goアプリの配信側でApp Store審査の影響を受けやすく、過去のバージョンでも審査待ちの状態が一定期間続いた経緯があるため、即時導入が難しい場面も想定されます。

SDK 56のベータ版にはReact Native 0.85.2およびReact 19.2.3が同梱されています。ベータ期間中は破壊的変更が追加で投入される可能性があるため、本番プロジェクトでの全面採用は安定版リリース後を推奨する判断が妥当です。検証用のサブプロジェクトや新規プロジェクトでベータ版を試し、課題を早期に把握しておく運用が現実的でしょう。

React Native 0.85.2とReact 19.2.3採用の技術基盤刷新

SDK 56の技術基盤の中心はReact Native 0.85.2とReact 19.2.3への引き上げにあります。SDK 55ではReact Native 0.83系が採用されていましたが、SDK 56で2世代分進む形となり、エンジンやコア層の挙動に影響する変更を含む構成です。React 19.2系の採用により、最新のReactパターンに対応した記述が可能となり、エラーバウンダリやSuspenseまわりの取り扱いが整備されています。

大きな変化として、Hermes V1がデフォルトのJavaScriptエンジンに切り替わりました。SDK 55ではuseHermesV1フィールドによるオプトイン扱いでしたが、SDK 56ではHermes V1が標準となり、起動時間の短縮とランタイム性能向上、メモリ使用量の削減が見込まれます。Hermes V1から戻したい場合はexpo-build-propertiesのuseHermesV1設定で切り替えられる構成です。

加えて、Metroバンドラもバージョン0.84.4へ引き上げられ、@expo/metroパッケージは56.0.0へ揃えられました。バンドル処理やリゾルバの挙動が更新されるため、独自プラグインやカスタムリゾルバを利用しているプロジェクトは挙動の差分検証が欠かせません。React Native自体もNew Architectureへの統合が進んだバージョンとなっており、旧来のBridge前提で書かれたネイティブ拡張は移行や検証の対象になります。

stable昇格した3つのライブラリと刷新されたAPI設計方針の整理

SDK 56では、expo-calendar、expo-media-library、expo-contactsの3つのライブラリが正式にstableへ昇格しました。これら3つは、いずれも次期APIがオブジェクト指向設計に再構築されたうえで安定版扱いとなった点が特徴です。従来は連絡先1件やメディア資産1件を取得する際に大きなオブジェクト全体を読み込む必要がありましたが、新APIでは取得したいプロパティを絞ったきめ細かい取得が可能です。

クエリやフィルタリングについてはBuilderパターンが採用され、複雑な絞り込みも読みやすい形式で記述できるようになっています。クラスとして個別のレコードを扱える設計は、テストの分離やキャッシュ層の構築といった応用にも適しており、保守性の向上が期待できます。SDK 55のα段階で公開されていたiOS向けExpo Widgetsもsable扱いに移行し、ホーム画面ウィジェットを正式機能として組み込めるようになりました。

開発者体験向上に直結するSDK 56の主要アップデート5項目の要点

SDK 56では、日々の開発作業に直結する改善が複数同時に投入されています。まず、インラインモジュールの型生成ツールが整備され、Swiftで書いたインラインモジュールの隣に対応するTypeScript定義が自動生成される仕組みが追加されました。create-expo-moduleコマンドはリニューアルされ、安定性と機能の両面で強化されています。

主要なアップデートを整理すると、以下のような点が挙げられます。

• React Native 0.85.2およびReact 19.2.3への対応によるランタイム刷新
• expo-calendar・expo-media-library・expo-contactsのオブジェクト指向API化とstable昇格
• インラインモジュールに対応した型生成CLIの追加とcreate-expo-moduleの改善
• iOS向けExpo Widgetsの安定版化とウィジェット実装の本格運用対応
• expo/fetchのデフォルト化およびbsdiff差分配信のデフォルト有効化

これらは個別に見れば小さな変更ですが、組み合わせるとプロジェクトの初期構築から実機検証、配信までを通して効率を底上げする内容です。日常の繰り返し作業に対する手数を減らす方向への投資と捉えられます。

SDK 56が示すExpoエコシステムの中期的な進化方針と方向性

SDK 56は、Expoが中期的に何を重視しているかを読み取りやすいリリースです。ネイティブモジュールAPIのオブジェクト指向化は、JavaScript側からネイティブ機能を扱う際の認知負荷を下げる方向の意思決定であり、TypeScript型生成の整備と合わせて型安全な開発をデフォルトに引き上げる狙いが見えます。Expo Widgets for iOSの安定版化は、純粋なアプリ画面以外の体験を提供する領域へExpoが踏み込む姿勢の表れです。

差分更新を実現するbsdiff配信のデフォルト有効化や、@react-navigation/*をexpo-routerのエントリーポイントに集約する変更など、配信効率とパッケージ境界の整理も並行して進められています。Expo GoはあくまでビギナーとデモのためのツールとされDevelopment Buildへの誘導が一段と強くなっており、商用プロジェクトはDevelopment BuildとEAS UpdateやEAS Buildを前提とする運用へ収れんしていく流れです。

Expo SDK 56が要求するReact NativeとOSバージョン要件の詳細整理

Expo SDK 56で押さえるべき要件は、最低OSバージョンの引き上げ、ReactとReact Nativeのバージョン整合、およびAndroid側のSDKレベルの3点に集約できます。これらを満たさないと、ビルド失敗や実行時クラッシュにつながりかねません。本章では、iOS・macOS要件、Android compileSdkVersion、React Native 0.85.2・React 19.2.3との互換条件、旧端末切り捨ての判断基準、開発環境の推奨バージョンを順に整理します。

SDK 56で必須となる最低iOS 16.4とmacOS 13.4の要件

SDK 56では、最低iOSおよびtvOSバージョンが16.4へ、最低macOSバージョンが13.4へ引き上げられました。SDK 55までの最低iOSは15.1でしたので、SDK 56では一段切り上がる形となります。ビルド時のdeploymentTargetとアプリ実行端末の両方に影響する変更です。これに合わせて、expo-build-propertiesで明示的に指定する場合のiOS deploymentTargetも16.4に揃えるのが標準的な構成となります。

iOSの最低バージョン引き上げの背景には、Apple側のXcode SDK要件と新APIの利用可能範囲があります。iOS 16.4以降の機能を前提としたネイティブモジュールが増えることで、SDK全体としても旧バージョンを切り上げざるを得ない判断となります。Expo公式によると、SDK 56でサポート対象から外れる端末はiPhone 7 / 7 Plus、iPhone 6s / 6s Plus、初代iPhone SE、iPad mini 4、iPad Air 2が該当機種です。ストア側のサポートポリシーも考慮しながら、対応OSの引き上げをユーザー告知とセットで行う運用が安全です。

macOS側はExpoのビルド環境としても影響します。CIや開発端末のmacOSが13.4未満のままだと、ローカルビルドで失敗する場面が増えるため、開発環境の足並みも合わせて更新する必要があります。

表のとおり、SDK 56はOS要件・ランタイム・ビルド層のいずれにおいても引き上げが行われています。要件確認はネイティブビルド前段で行い、対応端末の範囲を運用ポリシーと突き合わせる作業を欠かさないようにします。

Android向けcompileSdkVersionの設定値とSDK 36基準

Android側では、SDK 56向けにcompileSdkVersion 36、targetSdkVersion 36、buildToolsVersion 36.0.0を指定する構成が標準的な選択肢となります。expo-build-propertiesプラグインを利用して、これらの値をapp.jsonまたはapp.config.jsで明示する方法が公式に案内された構成です。compileSdkVersionはGradleにどのAndroid SDKでコンパイルするかを伝える値であり、新しいAPIを利用するためにはこの値の引き上げが前提となります。

targetSdkVersionはGoogle PlayストアやAppleの審査要件と直接結び付く項目であり、ストア側が定期的に最低値を引き上げる傾向にあります。新規アプリの登録や既存アプリの更新で必要なAPIレベルが満たされていないと、提出そのものが拒否される場面も少なくありません。SDK 56への移行は、ストア側のAPIレベル要件への追随という観点でも合理的な判断となります。

ネイティブモジュールが古いcompileSdkVersionに依存している場合、ビルドがKotlinコンパイルエラーで失敗するパターンが発生します。サードパーティ製モジュールを多用しているプロジェクトでは、各モジュールのバージョンを併せて引き上げる検討が必要です。

React Native 0.85.2・React 19.2.3との互換性条件と注意点

SDK 56はReact Native 0.85.2およびReact 19.2.3を前提に動作するよう構成されています。Expo SDKのパッケージは、対応するReact Nativeバージョンと組み合わせて利用することが想定されており、原則として古いReact Nativeを採用したまま最新Expo SDKだけを引き上げる運用は推奨されていません。

互換性確認のポイントは大きく2つに分かれます。1つ目は、自社で開発しているネイティブモジュールがReact Native 0.85.2のNew Architecture周辺の変更に追随できているかという点。2つ目は、利用しているサードパーティライブラリが該当バージョンのReact NativeとExpo SDK 56に対応しているかという点です。reactnative.directoryやライブラリ各社のリリースノートと組み合わせて、対応状況を順に確認していく流れになります。

React 19.2.3側では、コンカレント機能やuseの挙動など、19系で導入された機能が前提となるため、関数コンポーネントの実装やState管理の見直しが必要なケースがあります。サスペンスを活用したデータ取得やストリーミングUIを採用している場合、React 19.2.3の挙動を踏まえた再検証が望まれます。

SDK 56で旧端末を切り捨てる判断基準と影響範囲・移行判断軸

iOS 16.4・macOS 13.4が最低要件となるため、それ以前のOSしかサポートしないアプリにとってSDK 56は実質的に旧端末切り捨ての契機となります。判断軸としては、稼働中ユーザーのOSバージョン分布、業務ドメインで要求される対応端末の範囲、ストアのAPIレベル要件、セキュリティアップデート提供状況の4つが挙げられます。

稼働ユーザーのうちiOS 16.4未満を利用している割合が小さく、ストアのレビューサイクルも近い場合は、SDK 56への移行と同時に最低OS引き上げを案内するのが現実的です。法人向けアプリなど特定のOSバージョンに張り付いた利用者が多い場合は、SDK 55系を維持しつつDevelopment Buildで運用を続け、利用者の更新を待つ判断もあり得ます。

影響範囲を見極めるうえでは、ストア側の最低API要件、Apple Pushの認証要件、Google Play Servicesのバージョン依存といった外部要件もチェックポイントになります。Expo SDKだけを基準に判断するのではなく、ストアと外部APIの要件を含めた多面的な視点が必要です。

開発機材として必要なXcode・Node.jsの推奨バージョン要件

SDK 56でiOSビルドを行うには、最低Xcode 26.4が必要です。SDK 55の最低Xcode 26.2から1段引き上がっています。Apple公式が提供する最新の安定版Xcodeを利用するのが基本方針となり、ベータ版のXcodeは検証用途に限定するのが安全です。CIサービスを利用している場合、利用中のmacOSイメージとXcodeバージョンの組み合わせがSDK 56の要件を満たすかを確認します。

Node.jsについては、React Native 0.85がEOL（end-of-life）のNode.jsバージョンと20.19.4未満の利用を切り捨てる方針を取っています。SDK 55ではNode.js 20.19.x系が最低要件でしたが、SDK 56では20.19.4以降を採用するのが安全です。古いNode.jsを使い続けると、依存パッケージのインストール時にエンジン警告が出たりビルドスクリプトが正常に動かなかったりする原因となります。プロジェクトのpackage.jsonにenginesフィールドを設定し、CIとローカルでNode.jsのバージョンを揃える運用が有効です。

Android Studio、Java Development Kit、CocoaPodsといった周辺ツールも、利用するExpo SDKバージョンに合わせて整える必要があります。各種ツールのバージョン差はビルドエラーの原因として上位を占める領域であり、開発ガイドの「Tools for development」を参照しながらセットアップを定期的に見直す姿勢が安全です。

Expo SDK 56で導入された新APIと既存ライブラリの再設計内容

SDK 56で導入された新APIは、いずれも長らくExpoの基本ライブラリとして利用されてきたものの再設計版です。連絡先・カレンダー・メディア資産といった頻出領域のAPIが、オブジェクト指向設計とBuilderパターンを取り入れた形に変わりました。並行して、HTTP通信のexpo/fetchがデフォルト化され、iOS向けのウィジェット機能も正式提供となります。本章では、それぞれの変化が実装にどのような影響を与えるかを順に整理します。

expo-calendarがstable昇格しオブジェクト指向APIへ刷新された点

expo-calendarは、SDK 56でオブジェクト指向APIを採用した次世代版が正式にstableへ昇格しました。従来のフラットな関数群中心のAPIから、カレンダーやイベントといった概念がクラスとして表現される形に変わっています。クラスベースの設計に切り替わったことで、特定のカレンダー1件に対するイベント追加や属性更新を直感的なオブジェクト操作として書けるようになっています。

新APIの大きな利点は、クエリ時に取得するプロパティを絞り込めるきめ細かい取得に対応したことです。従来は1件のイベントを取得する際にすべての属性を読み込む必要がありましたが、新APIでは必要な項目のみを指定する形に最適化できます。大量のイベントを扱うアプリでは、取得時のメモリ消費とレスポンス時間の両面で改善が見込めます。

Builderパターンを使ったクエリ構築も新APIの特徴です。期間指定、カレンダーID指定、属性条件などをチェーン形式で組み合わせ、複雑な絞り込みを読みやすく表現できます。チームで保守する際にもクエリの意図が伝わりやすくなる点が実務的なメリットです。

expo-media-libraryのBuilderパターン採用と取得処理の効率化

expo-media-libraryもSDK 56で次世代APIへの移行が完了しました。メディア資産がクラスとして表現されることで、写真や動画1点ごとに付随情報をまとめて取り扱えるようになっています。MediaAssetをオブジェクトとして渡したり、属性更新後にもう一度取得したりする操作が一貫した文法で書ける構造です。

Builderパターン採用の実務的な意味は、フィルタや並び順の指定が宣言的になることにあります。撮影日時範囲、メディア種別、アルバム指定、ページサイズなどを組み合わせるクエリを、追加と置換が容易な形で記述できます。検索条件を動的に組み立てるアプリでは、可読性とテスト容易性の両面で改善が期待できる仕組みです。

大量のメディアを扱うアプリでは、グラニュラーな取得が重要な改善点となります。サムネイル一覧表示時にはメタデータの最小セットだけを取得し、詳細画面で初めてフルデータを読み込むといったレイテンシ志向の設計が書きやすくなります。古いAPIから新APIへの移行時には、フィールドの命名や非同期処理のシグネチャが変わっている部分があり、置き換えは公式ブログで案内された変換ガイドを参照しながら段階的に進めるのが安全です。

expo-contactsで個別連絡先がクラス表現される新構造

expo-contactsの新APIでは、個別の連絡先がクラスのインスタンスとして表現される構造になりました。1件の連絡先オブジェクトに対して、電話番号の追加、メールアドレスの更新、写真の置き換えといった操作をメソッド呼び出しの形で実行する設計です。連絡先1件を中心にした処理が一貫した型で書けるため、ドメインモデルとの対応が明確になります。

クエリ側もBuilderパターンが導入されており、名前検索、グループ指定、ソート、ページネーションを組み合わせた問い合わせを宣言的に書けます。連絡先1件の取得時にも、必要なフィールドだけを指定するきめ細かい取得が可能となっています。住所録の規模が大きいユーザーを抱えるアプリでも、無駄な属性読み込みを抑えながらレスポンスを返せる設計です。

権限まわりの取り扱いも、新APIへの移行を機に整理されています。連絡先アクセスは慎重な取り扱いが求められる領域のため、権限要求のタイミングと粒度を再検討する好機ともいえる場面です。新APIに合わせてプライバシーポリシーや権限案内文の文言を見直しておくと、ユーザー側の納得感を高められます。

expo/fetchがデフォルトfetch実装として標準化された変更

SDK 56では、expo/fetchがデフォルトのfetch実装として標準採用されました。これまでReact Nativeのグローバルfetchを利用していた箇所が、Expoの提供するexpo/fetch経由のfetchに置き換わります。HTTPストリーミングやキャンセルなど、Web標準のfetch仕様に近い挙動を提供するための変更であり、サーバ送信イベントやストリーム応答を扱うアプリでメリットが顕著です。

従来のReact Native組み込みfetchではWebのストリーム仕様と完全には一致しない部分があり、AIチャットや大規模データ取得を行うアプリで実装側の工夫が必要でした。expo/fetchがデフォルトになることで、これらのユースケースの実装難易度が下がり、ライブラリ側の互換性も整備されていく流れが期待できます。

注意すべきは、独自実装のXMLHttpRequestやfetchパッチを採用しているライブラリとの相互作用です。HTTPリクエストをモニタリングするデバッガや、リクエスト書き換えを行うミドルウェアを利用している場合、expo/fetchのデフォルト化に伴う挙動差を検証する必要があります。POSTやPATCH、PUTのbodyなしリクエストの取り扱いといった細かな挙動も、SDK 56で改善されている領域に含まれます。

Expo Widgets for iOSがstable昇格して利用可能となる実装範囲

SDK 55でアルファ版として公開されていたExpo Widgets for iOSは、SDK 56で正式にstableへ昇格しました。SwiftUIを用いたiOS純正のウィジェット実装を、Expoプロジェクトのワークフロー内で扱える点が中心的な価値です。アプリの主要なデータをホーム画面やロック画面に常駐表示するUXが、Expo前提のプロジェクトでも本番運用しやすくなりました。

実装範囲としては、SwiftUIベースのウィジェット定義、データ供給用のタイムラインプロバイダ、Expoモジュールとの値共有といった要素が公式にサポートされています。アプリ本体とウィジェット間のデータ受け渡しには、共有コンテナや専用のストレージ仕組みを利用する設計が前提です。フィードバックを反映した安定化が進んだ結果、アルファ期間に発生していた既知の不具合や使いづらさが解消され、本番投入を判断しやすい完成度に達しています。

Android側のホーム画面ウィジェット対応や、@expo/uiのSwiftUI APIなど周辺機能も並行して整備が進んでおり、ウィジェットを軸にした体験設計はSDK 56以降のExpoプロジェクトで重要なテーマとなっていきます。

Expo SDK 56で進化したインラインモジュールと型生成ツールの活用

SDK 56におけるインラインモジュールの強化は、ネイティブ機能を取り込みたい開発者にとって最も注目すべきテーマの1つです。SwiftやKotlinで小規模なモジュールをプロジェクト内に直接書ける仕組みに対して、TypeScript型を自動生成するCLIが整備され、Swift側とTypeScript側の往復が大幅に減ります。本章では、概念整理から実装手順、create-expo-moduleの新コマンドまでを順に整理します。

インラインモジュールの基本概念とSDK 55からSDK 56への進化点

インラインモジュールは、SDK 56で新たに導入された、別パッケージに切り出さずにプロジェクトのソースツリー内で直接ネイティブモジュールを書ける仕組みです。Expo公式の説明によれば、アプリをインラインモジュール対応に整えれば、KotlinやSwiftのファイルを開いて追加設定なしでExpoモジュールを書き始められます。prebuild時にiOSのXcodeプロジェクトとAndroidプロジェクトの設定が自動更新され、ビルドへの組み込みとオートリンクが進む構造です。

SDK 55までは、独立したライブラリとしてExpoモジュールを切り出す前提が中心でした。SDK 56でインラインモジュールとTypeScript型生成ツールが揃うことで、プロジェクト内に小規模なネイティブ機能を素早く組み込めるようになっています。CLIウォッチャーが起動中、Swiftインラインモジュールの隣に対応するTypeScriptインターフェースを自動生成し、変更があるたびに更新する仕組みが提供されます。Swiftのインラインモジュールが、Android Studio、Xcode、その他IDEから扱える点もSDK 56で加わった特徴です。

クラス化されたAPI、Builderパターンを採用した次世代ライブラリ群とも噛み合う方向の進化であり、Expoプロジェクトの中で「型情報がそのまま開発の手綱になる」体験が強まる位置づけといえます。

CLI watcherによるTypeScript型定義の自動生成の仕組みと利点

SDK 56で追加されたCLIコマンド群は、インラインモジュール用に専用設計されたものです。ウォッチャーモードでCLIを起動しておくと、Swift側のインラインモジュールに変更を加えた瞬間にTypeScript型定義が再生成される仕組みになっています。型定義は「自動生成部分」と「安定部分」に分割される構成のため、開発者が独自に書き加えた型は維持しつつ、自動生成領域だけを差し替える運用が可能です。

この仕組みの利点は、型定義の鮮度を意識せずにネイティブ実装に集中できる点にあります。引数の追加や戻り値の変更があっても、TypeScript側のシグネチャが自動的に追随するため、コンパイル時に型差分が即座に通知される仕組みです。手動で生成したい場合にもコマンドが用意されており、CIに組み込んで型生成の整合性をチェックする使い方もできます。

運用上の注意点として、自動生成領域に手を加えるとウォッチャー再生成時に上書きされるため、独自の型はあらかじめ安定部分に書く規約を整える必要があります。プロジェクトのコーディング規約として、生成領域と手書き領域の境界を明確に文書化しておくとチーム開発での齟齬を防げます。

Swiftインラインモジュールから始める実装手順と最小構成例

SDK 56のインラインモジュールを試す最も手軽な経路は、新規プロジェクトをcreate-expo-moduleのリニューアル版で生成し、Swift側に小さな関数を1つ加えるところから始めるパターンです。CLIウォッチャーを起動しておけば、Swift変更の直後にTypeScript側の定義が自動生成されます。

初学者が押さえておくべき手順は、おおむね次の流れになります。

1. SDK 56対応のExpoプロジェクトを用意し、必要に応じてnpx expo install --fixを実行する
2. create-expo-moduleの新コマンドでインラインモジュール用のスケルトンを生成する
3. Swiftファイルを開き、関数や定数など最小限の機能を実装する
4. CLIウォッチャーを起動して、TypeScriptインターフェースが自動生成されるのを確認する
5. JavaScript側で対応する関数を呼び出し、ホット再ロードで挙動を確認する

このサイクルを1度回しておくと、ネイティブ実装と型生成の関係が体感的に把握できます。本格的な機能を作る前に、最小例で「自動生成された型」と「自分で書いたTypeScript」の境界を整理しておくと、後の保守でも迷いにくくなります。

インラインモジュールの生成部分と安定部分を分離する型管理の基準

インラインモジュール周辺の型情報は、自動生成部分と安定部分に分けて取り扱う構成が前提になっています。自動生成部分はネイティブ実装に追随して書き換わる領域であり、開発者が直接編集する場所ではありません。安定部分は、開発者が手書きしてアプリ側のドメインに合わせた型として整える領域です。

この分離により、ネイティブ側の変更でTypeScript型が壊れるリスクを最小化しつつ、アプリ側で必要な抽象化を独立して保てる構造になります。たとえば、ネイティブAPIの戻り値をそのまま使うのではなく、アプリで扱いやすいユニオン型やドメインオブジェクトに変換するロジックは安定部分に書く方針が明快です。

判断基準として有効な観点を整理すると、ネイティブ実装の都合だけで決まる型は自動生成部分、UIやドメインの意図が含まれる型は安定部分、と覚えておくと振り分けに迷いません。プロジェクトの規模が大きくなるほど、この境界線の運用ルールが品質を左右します。

create-expo-moduleのリニューアル内容と新コマンドの活用法

SDK 56では、create-expo-moduleが大幅にリニューアルされ、安定性と機能の両面で改善が入りました。テンプレート構成が見直され、SDK 56の前提に沿ったプロジェクト構造を最初から得られるようになっています。インラインモジュール向けのCLIコマンド群もここで提供され、ウォッチャー起動や明示的な型再生成が手元のターミナルから実行できます。

新コマンドはインラインモジュール開発者にとって日常的に使う場面が多く、ホット再ロードと並行して常駐させる前提の設計になっています。CIで型差分を検証する用途にも使いやすく、プロジェクトのpackage.jsonにスクリプトとして登録しておくとチーム共有が容易です。

create-expo-moduleの活用シーンは、独立したライブラリとしての切り出しと、プロジェクト内インラインモジュールの2系統に分かれます。前者は再利用性とパッケージ管理を重視するケース、後者はアプリ固有の機能を素早く実装するケースに向きます。今後はAIエージェント向けのcreate-expo-moduleスキルの整備も予告されており、コード生成支援との組み合わせで実装効率がさらに底上げされる見込みです。

Expo SDK 55からSDK 56への変更点と実務影響の比較整理

SDK 55からSDK 56への変更を実務目線で見ると、ランタイムの世代交代、最低OS要件の引き上げ、配信メカニズムの既定値変更、ライブラリ群の昇格・廃止が組み合わさった複合的なアップデートとなっています。本章では、過去2世代との比較表、最低OSの数値推移、bsdiff既定化の影響、ライブラリ整理、3軸での影響度判定を順に整理します。

SDK 54・55・56のReact Nativeバージョン対応の比較表整理

過去3世代のSDKを並べて比較すると、ExpoがReact Nativeのアップデートにどう追随しているかが読み取れます。React Native自体が年数回のリリースサイクルへ移行しており、Expo SDKは原則として2回に1回のペースで採用バージョンを上げる方針です。

表のとおり、SDK 56はReact Native 0.85系とReact 19.2系の組み合わせを採用しています。SDK 54でLegacy Architecture対応が終了し、SDK 55以降はNew Architecture前提となった経緯を踏まえると、SDK 56はNew Architecture時代の安定運用を進めていく位置づけです。React 19系で導入されたコンカレント機能やuseに対応した記述スタイルが標準となり、サスペンスを活用したUI設計が引き続き進化していくと見込まれます。

SDK 55とSDK 56の最低OS要件比較とサポート端末の数値的推移

最低OS要件に関しては、SDK 56でiOS / tvOSが16.4以上、macOSが13.4以上に引き上げられました。SDK 55までは最低iOS 15.1という構成でしたので、SDK 56は約2世代分の引き上げに相当します。Apple側のOSサポートポリシーや、CocoaPods・Xcode SDKの整備状況と歩調を合わせる狙いが背景にあります。

Android側はcompileSdkVersionおよびtargetSdkVersionが36推奨という構成で、これはSDK 55の値と同水準です。新規プロジェクトでは初期設定の段階で36を採用しておくのが標準路線となります。targetSdkVersionはGoogle Playストアの提出要件と直接結び付く項目であり、ストア側が定期的に最低値を引き上げる傾向にあるため、SDK 56への移行は審査要件への追随という観点でも合理的です。

サポート端末という観点では、Expo公式ブログによるとSDK 56の引き上げに伴いiPhone 7 / 7 Plus、iPhone 6s / 6s Plus、初代iPhone SE、iPad mini 4、iPad Air 2はサポート対象から外れます。一方でiOS 16.4はおおむね2018年以降に発売されたiPhone・iPadで動作する範囲です。macOS 13.4は近年のMacBookシリーズ全般で問題なく動作する水準であり、開発端末側の制約は限定的と言えます。業務用に長期運用されている古いiOS端末を抱える組織では、影響範囲をよく見極める必要があります。

bsdiffPatchSupportのデフォルト挙動変更による実務影響

SDK 55ではenableBsdiffPatchSupportというオプトイン項目として導入されたbsdiff差分配信が、SDK 56でデフォルト有効化されました。この変更は、EAS Updateを利用したJSバンドル配信の効率化に直結する内容です。差分配信が有効になることで、ユーザー端末がダウンロードする更新サイズが縮小し、回線が細い環境でも更新完了までの時間が短くなる効果が見込めます。

実務影響としては、EAS Updateのアップデートグループに対してbsdiff方式のバンドル差分が自動的に提供される点が大きな変化です。Update Detailsページから配信状況を確認できる仕組みも整備されており、運用側で差分配信が動いているかを可視化できます。独自のアップデートサーバーを利用しているプロジェクトでは、サンプル実装が公開されているexpo/custom-expo-updates-serverのブランチを参照しながら同様の機能を組み込めます。

注意したいのは、配信側だけでなく端末側のロジックがbsdiff前提になる点です。古いネイティブクライアントから新しい配信形式へ移行する過程では、ロールバックや旧ビルドとの整合確認を慎重に行う運用が望まれます。検証環境で十分にバンドル更新の挙動を確認したうえで、本番への展開を段階的に進めるのが安全です。

stable昇格・deprecation・removalされたライブラリの一覧整理

SDK 56におけるライブラリ整理は、利用中のパッケージにそのまま影響する重要トピックです。stable昇格と並行して、SDK 55で予告されていた削除がSDK 56で実行された領域があります。とくにメディア処理周辺で、後継ライブラリへの置き換えが必要となるケースが発生します。

整理しておくべき変化を列挙すると、以下のような項目になります。

• expo-calendar・expo-media-library・expo-contactsの新APIがstableに昇格し、旧APIは非推奨扱いに移行
• iOS向けExpo Widgetsがアルファからstableに昇格し、SDK 56でWidgets・Live Activitiesが事前レンダリング不要になる改善
• Expo UI（Jetpack Compose / SwiftUI）のネイティブAPIがstable化、ユニバーサルコンポーネントAPIも追加
• @expo/vector-iconsが非推奨化され、@react-native-vector-icons/*の各アイコンセット個別パッケージへ移行を案内
• expo-video-thumbnailsはSDK 55で非推奨化・更新停止が告知され、後継としてexpo-videoのgenerateThumbnailsAsyncを利用

これら以外にも、changelogの「Breaking changes」「Deprecations」セクションに細かな変更が並んでいます。プロジェクト内で利用しているExpoパッケージを一通り洗い出し、それぞれのCHANGELOGを参照しながら影響を確認する作業が、移行プロジェクトの初動として有効です。

機能追加・破壊的変更・非互換変更の3軸で整理した実務影響度の判定

SDK 56の変更を実務に落とし込むには、機能追加・破壊的変更・非互換変更の3軸で整理する見方が役立ちます。機能追加は、利用しなければ既存コードに影響しない部分であり、リスクを負わず採用できる領域です。たとえば、新しいインラインモジュール周辺の型生成ツールは、利用するかどうかを開発側が選べる類の変更となります。

破壊的変更は、プロジェクトのコードを書き換えなければビルドや実行が通らなくなる変更です。@react-navigation/*をexpo-routerに置き換える対応や、最低OS要件の引き上げに伴うdeploymentTargetの調整が代表例にあたります。リリース前に確実に対応する必要があるため、SDK 56への移行プロジェクトでは最初に着手する領域です。

非互換変更は、コードを書き換えなくてもビルドは通るものの、挙動や性能が変わる類の変更です。expo/fetchのデフォルト化やbsdiffの既定有効化は、この区分に近い性質を持ちます。明示的な対応は不要でも、検証フェーズで挙動差を確認しておかないと、本番環境で予想外のトラブルにつながる可能性があります。これら3軸を分けて記述したチェックリストを用意し、移行作業全体の進捗管理に活用するのが現実的なアプローチです。

Expo SDK 55からSDK 56へのアップグレード手順と検証ポイント

SDK 56への移行作業は、依存関係の整理、Expo CLI経由のパッケージ更新、ネイティブビルドの再生成、検証ツールの実行、最後に実機での動作確認という流れに分解できます。本章では、事前準備から検証フェーズまで、現場で迷いやすいポイントを順に整理します。

事前準備として確認する依存関係・ロックファイル・バックアップ

アップグレード作業の質は、事前準備でほぼ決まります。最初に行うべきは、現在のプロジェクトで利用中のExpoバージョン、React Nativeバージョン、各種Expoパッケージの一覧を整理することです。npmやyarnのロックファイルが正しい状態でコミットされているかも確認し、必要に応じて整合性を取り直します。

次に、SDK 55までのプロジェクトをいつでも再現できるようにバックアップ用ブランチを切る運用が安全です。Continuous Native Generationを利用している場合、androidディレクトリやiosディレクトリは生成物のため大きな問題になりませんが、独自パッチを当てているケースではpatch-packageやEAS Build時のhookを含めてバックアップ対象とします。

サードパーティライブラリのリリースノートも事前に通読し、SDK 56もしくはReact Native 0.85系への対応状況を把握しておきます。reactnative.directoryやライブラリのGitHubリポジトリで最新バージョンの動作報告を確認し、移行計画へ反映する手順です。利用しているネイティブモジュールが多いプロジェクトほど、この事前確認の重みが増します。

npx expo install –fix を含む公式アップグレード手順5段階

公式の標準的なアップグレード手順は、以下の流れに整理できます。

1. expoパッケージ自体のバージョン範囲を更新する。npmまたはyarnを利用して、対象SDKに合うバージョン範囲、たとえばexpo@^56.0.0を指定してインストールする
2. npx expo install --fixを実行し、Expo SDKに同梱される他のパッケージ群もまとめて整合バージョンへ揃える
3. Continuous Native Generationを使っているプロジェクトでは、ローカルに生成済みのandroidディレクトリ、iosディレクトリを削除する。次回のビルドで自動的に再生成される
4. iOSのCocoaPods管理が必要なプロジェクトでは、npx pod-installを実行して依存を再構築する
5. npx expo-doctor@latestを実行し、依存関係の不整合や設定ミスがないかを最終チェックする

このフローは、アップグレード対象のSDKバージョンが変わっても基本的に共通です。SDK 56への移行でも同じ手順を踏みつつ、SDK 56固有のチェックポイント（@react-navigation/*の置き換え、最低OS要件、ネイティブモジュールの互換）を併走で確認することになります。

アップグレード後に確認すべきexpo-doctorとビルド検証手順

expo-doctorはアップグレード後の整合性チェックの主役となるツールです。npx expo-doctor@latestを実行すると、依存関係の整合性、app config項目とネイティブディレクトリの整合性、React Nativeディレクトリとの不整合などを検査してくれます。問題が見つかった場合は説明と推奨対応が表示されるため、この出力に沿って修正を進めるのが王道です。

doctorがクリーンな状態を確認できたら、開発ビルドを起動してホット再ロードで主要画面の動作を見ます。次に、iOSとAndroidそれぞれでクリーンビルドを実行し、Kotlinコンパイルエラー、Swiftコンパイルエラー、CocoaPods関連のエラーがないかを確認します。これらのビルドエラーは互換性問題を最初に教えてくれる重要なシグナルです。

EAS Buildを利用している場合は、対象プロファイルでビルドが通ることを確認したうえで、EAS Updateを利用したOTA配信の挙動も検証します。bsdiff差分配信のデフォルト化と組み合わせて、Update Detailsページから差分が提供されているかを確認しておくと、運用フローの整合確認まで完了できます。

アップグレード時に発生しやすい依存関係エラーの解決パターン例

アップグレード途中で頻出するのが「expoパッケージが期待するバージョンと実際にインストールされているバージョンの不一致」です。このタイプの警告は、npx expo install --fixまたはnpx expo install [パッケージ名]で多くが解決します。expo-cliが提案するバージョンは、原則としてExpo Goとの互換性も考慮した保守的な値となっています。

もう1つよくあるのが、Kotlinコンパイル時のシグネチャ不一致です。expo-modules-coreが新しいReact Native APIを期待しているのに、ネイティブモジュール側がそれに追随していないケースで発生します。このパターンでは、対象モジュールのバージョンを上げる、もしくはSDK 56対応のフォーク版に切り替えるといった対応が必要になります。

iOS側では、Pod installが解決できない依存ツリーでつまずく場面が代表的です。Podfile.lockを削除して再生成し、CocoaPodsとXcodeのバージョンを最新に揃えるアプローチで多くは解消します。残るエラーがある場合、各ライブラリのGitHub IssueやExpoのDiscordフォーラムが具体的な解決ヒントの宝庫であり、エラー文言で検索するだけで類似事例にたどり着けることが多い領域です。

development buildによる実機検証とExpo Goでの動作確認の使い分け

SDK 56時代の検証では、Development BuildとExpo Goの役割分担を明確にしておくことが重要です。Expo Goは、教育目的やデモ用の最小構成で素早く動作確認するためのツールという位置づけが一段と強くなっています。本番アプリの開発検証は、Development Buildで行うのが標準路線です。

Development Buildを使う最大のメリットは、プロジェクトに含まれるネイティブモジュールやインラインモジュールがすべてそのまま動作する点です。Expo Goには含まれない追加モジュールや、独自にビルドプロパティを変更している構成でも、本番に近い形で動作確認ができます。EASを利用すれば、Development BuildをEAS BuildとEAS Updateで素早く配布する運用も整えられます。

Expo GoはApp StoreやPlay Store側の都合で最新SDKに追随するまで時間が空くこともあるため、SDK 56向けのExpo Goが整う前にプロジェクトを移行したい場面でも、Development Buildを使えば足止めされません。新規プロジェクトでもまずDevelopment Buildを前提に環境を整えるアプローチが、長期的には保守工数を抑える選択肢となります。

Expo Router・React Navigation関連のSDK 56破壊的変更と対応

SDK 56で最も影響範囲が広い破壊的変更の1つが、Expo Routerと@react-navigation/*パッケージの取り扱いの整理です。アプリケーションコードから@react-navigation/*を直接importする運用が禁止され、expo-routerが提供する対応エントリーポイント経由のimportに置き換える必要があります。本章では、変更内容、対応マッピング、自動移行コマンド、ライブラリ向け互換シム、無効化判断までを順に整理します。

@react-navigation/*の直接インポートを禁止する仕様変更

SDK 56以降、Expo Routerはアプリケーションコードからの@react-navigation/*パッケージのimportをサポートしなくなりました。@react-navigation/nativeからThemeProviderを読み込む、あるいは@react-navigation/material-top-tabsからcreateMaterialTopTabNavigatorを読み込むといった、SDK 55までの慣例的な記述はバンドラエラーの対象となります。

変更の背景には、Expo Routerが提供するルーティング基盤と、React Navigationの個別パッケージのバージョン整合を強制する意図があります。Expo Routerは内部でReact Navigationの一部機能をラップしながら独自のファイルベースルーティングを提供しており、importの経路を統一することで依存関係のずれによるバグを防ぐ設計に切り替えています。実行時のAPIそのものは変わっておらず、import元のモジュール指定だけを変更する対応で済む点は救いです。

SDK 55でアプリケーションコードを書いてきたチームにとっては、機械的な置き換え作業が中心となります。プロジェクト規模が大きいほど対象ファイル数も増えるため、自動化と手動確認を組み合わせた進め方が必要です。

expo-routerエントリーポイントへの置き換え対応表の整理

具体的な置き換え先は、Expo公式ドキュメントの「Migrate Expo Router from SDK 55 to SDK 56」で対応表として公開されています。プロジェクト内で利用しているimportを洗い出し、表に従って置き換えていく流れになります。

表のうち、native-stackとdrawerはexpo-router側のレイアウトコンポーネントへ移行する形になります。これら2つは、ファイルベースルーティングのレイアウト設計から再構築する作業になるため、影響度が高い領域です。あらかじめ移行前にレイアウト構造の再設計案を作っておくと、移行作業がスムーズに進みます。

公式提供のcodemodを使った自動移行手順と実行コマンドの例

Expoは、import書き換えを自動化するためのcodemodを公式に提供しています。プロジェクトのルートで実行することで、対象ディレクトリ内の@react-navigation/*importをexpo-routerの対応エントリーポイントへ置き換えてくれます。

標準的な実行コマンドはnpx expo-codemod sdk-56-expo-router-react-navigation-replace srcで、最後の引数にアプリケーションコードを含むディレクトリやglobパターンを指定します。srcディレクトリにすべてのコードが収まっている構成なら、このまま実行するだけで多くの置き換えが完了する設計です。複数ディレクトリに分かれている場合は、対象ディレクトリを順に指定して実行するか、globパターンで一括指定します。

codemodは機械的な書き換えを行うため、結果の確認は人間が責任を持って実施します。importが書き換わったあとも、レイアウトコンポーネントの構造そのものは変わらないため、Stackやドロワーといった一部の項目は手動で再構築する必要が残る点には注意が必要です。codemodの実行直後にコミットを分けておくと、自動置換の差分が後から追跡しやすくなります。

node_modules内import自動書き換えの仕組みと無効化手段

サードパーティライブラリの中には、依然として@react-navigation/coreなどからimportしているものが少なくありません。このままではSDK 56で動かなくなるため、Expo CLIはnode_modules内のimportについて自動的にexpo-router経由に書き換える互換シムを提供しています。アプリケーションコードのimportは書き換えず、node_modules配下のみを対象とする設計のため、ユーザーが書いたコードに副作用が及ぶ心配はありません。

この仕組みは一時的な互換シムという位置づけで提供されています。将来的には、ライブラリ側がexpo-router経由のimportに対応する公式ガイドが整備された後で、自動書き換えは廃止される予定です。現時点では、サードパーティライブラリの対応待ちで困らないようにするための橋渡し機能と理解するのが正確です。

互換シムの存在は、開発者にとっては「SDK 56へ早めに移行してもサードパーティが追いつかずに動かなくなるリスクが低い」という安心材料となります。一方で、シムに依存し続けるとライブラリ更新の追跡が遅れるリスクもあるため、アプリケーションコードの置き換えと並行して、利用ライブラリのアップデート状況も継続的に確認する運用が望ましい姿です。

node_modules書き換え無効化用の環境変数と判断基準の整理

互換シムを無効化したい場合、環境変数EXPO_ROUTER_DISABLE_RN_NAVIGATION_CHECK=1を設定したうえでバンドラを起動します。具体的には、EXPO_ROUTER_DISABLE_RN_NAVIGATION_CHECK=1 npx expo startのように指定する形です。この設定を有効にすると、node_modules内の自動書き換えに加えて、アプリケーションコードが@react-navigation/*からimportしている場合のバンドラエラーも抑止されます。

無効化を選ぶ判断基準としては、SDK 56への移行作業を一括で進めたいわけではなく、特定の事情で@react-navigation/*の直接利用を残したいケースが該当します。たとえば、内製のラッパーライブラリで段階的に移行したい場合や、既存のテスト環境とビルド環境の整合を維持したい場合に検討する設定です。

実務的には、新規プロジェクトや大半の既存プロジェクトでは無効化せず、公式ガイドに沿って置き換えを進めるのが推奨される選択になります。互換シムが将来削除される予定である以上、無効化を恒久的に維持する運用は技術的負債を抱える方向であり、移行スケジュールを引いて完了させる前提で扱うべきオプションです。

Expo SDK 56導入時に発生しやすい失敗パターンと回避策の実例

SDK 56への移行で起こりがちなトラブルは、いくつかの定型的なパターンに分類できます。古い端末や古いネイティブモジュールに起因するもの、依存関係の解決失敗、Expo Goと開発ビルドの差異、配信周辺の挙動差など、代表的な失敗例を実例ベースで整理しておくと、移行プロジェクトでの判断スピードが底上げできるはずです。本章では、実務でつまずきやすいパターンと回避策を順に確認します。

旧iOS版・旧Android版端末での起動失敗とサポート対象判定

SDK 56では最低OS要件がiOS 16.4・macOS 13.4へ引き上げられたため、これらを満たさない端末ではアプリ自体が起動しない、またはストアからインストールできない状況が発生します。SDK 55時点までは動作していた古めのiPad、古めのMacBookで突然動かなくなったように見えるパターンが典型的です。サポート対象端末リストを更新せずに移行を進めると、ユーザーからの問い合わせ対応に追われることになります。

回避策として、まずアプリのアクティブユーザーのOSバージョン分布を確認し、サポート対象から外れる端末数とその割合を把握します。比率が許容範囲であれば、移行に先立ちアプリ内告知やリリースノートで明確に伝え、端末のOSアップデートを促す導線を整えるのが王道です。法人向けや特殊な業務アプリで古い端末が固定的に運用されている場合は、SDK 55系で運用を続けつつDevelopment Buildで提供する選択肢も検討します。

Androidについては、端末のOSバージョンに加えてGoogle Play Servicesの世代も影響する場合があります。古いAndroid端末でPlay開発者サービスが更新されていないケースでは、ストアの最低API要件と組み合わせて、サポート判断を多面的に行う必要があります。

ライブラリ依存解決でnpm・yarnが衝突するケースと解決法

移行作業で頻発するのが、依存解決時のバージョン衝突です。expoパッケージが期待するバージョンと、サードパーティライブラリが要求するバージョンが一致せず、npm installまたはyarn installでエラーが出るケースが代表例にあたります。peerDependenciesの不整合が原因のことも多く、警告レベルで止まる場合と完全な失敗として止まる場合の双方があります。

解決の第一歩はnpx expo install --fixの実行です。Expo SDKに含まれるパッケージ群を、SDK 56対応のバージョンへ一括で揃え直してくれます。これで解決しない場合、衝突しているパッケージを特定し、対象パッケージのGitHubリリースやCHANGELOGを確認して、SDK 56対応バージョンが存在するかを調べます。

パッケージマネージャ側のキャッシュが原因のこともあるため、node_modulesとロックファイルを一度削除して再インストールするアプローチも有効です。yarnであればyarn.lockを、npmであればpackage-lock.jsonを削除し、クリーンな状態で再インストールします。状況によっては、yarnとnpmが混在しているのを片方に揃えるだけで解決する場合もあり、ロックファイルの管理ポリシーを移行を機に整理しておくと再発防止につながります。

ネイティブモジュールが古いことによるビルドエラーの実例と対処

SDK 56で典型的に発生するのが、ネイティブモジュールが古いReact Native APIを参照していることに起因するビルドエラーです。Kotlin側で「Too many arguments」「Unresolved reference」といった内容のエラーが出たり、Swift側でAPI不在のシンボルが指摘されたりします。expo-modules-coreが新しいReact Nativeに合わせてアップデートされているのに、依存先のサードパーティモジュールが追随していない状態が原因です。

対処の基本は、エラーが指している原因モジュールを特定し、対応バージョンへ引き上げる作業です。ライブラリのGitHubリポジトリでReact Native 0.85系またはSDK 56対応の言及があるかを確認し、該当するリリースを取り込みます。対応版が出ていない場合、patch-packageで応急処置を施す、またはフォークして必要な修正を加えるといった対応が候補になります。

独自に書いたネイティブモジュールであれば、React Native 0.85系のモジュール仕様に合わせてシグネチャを更新します。インラインモジュールに移行できる規模のコードであれば、SDK 56で強化されたインラインモジュールへの再構築を機会と捉えるのも有効です。サードパーティ依存の整理と並行して、自社モジュールの保守体制も見直すきっかけにできます。

Expo Goで動作するがdevelopment buildで失敗する場面と原因

Expo Goでは正常に動作するが、Development Buildでは失敗するケースは、両者がカバーするネイティブモジュールの範囲差から発生します。Expo Goは限定的なネイティブモジュールセットを内蔵しているため、ホームウィジェットや独自ネイティブモジュールを含むプロジェクトでは、Expo Goでは見えない問題がDevelopment Buildで初めて顕在化することが少なくありません。

失敗パターンを整理しておくと、判断が早くなります。

• Expo Goに含まれないモジュールに起因するシンボル未解決エラー
• app.configやapp.jsonでネイティブビルドプロパティを指定しているが、再ビルドが行われていないケース
• iOSのCocoaPods依存が古いままになっており、Pod installで解決し切っていない状態
• 環境変数や鍵情報がDevelopment Build時にだけ参照されない問題

これらの多くは、Development Buildを最新の状態で再ビルドすれば解消します。Continuous Native Generationを利用しているプロジェクトでは、androidディレクトリとiosディレクトリを削除してから再生成することで、SDK 56の最新構成に合わせたネイティブプロジェクトが得られます。Expo Goでの確認はあくまで補助的な位置づけと割り切り、本番に近い検証はDevelopment Buildで行う方針が安全です。

bsdiffデフォルト化に起因するEAS Update関連の挙動変化

SDK 56でbsdiff差分配信がデフォルト有効化された結果、EAS Updateを利用するプロジェクトでは配信されるバンドルの形が変わります。具体的には、初回ダウンロードでは従来通りのフルバンドルが配布され、以降の更新では差分のみが配布される構成です。配信時のサイズが小さくなる代わりに、端末側のバンドル合成処理が前提となります。

挙動変化として注意すべきポイントは、ロールバックや段階配信の運用です。差分配信は前のバンドルがある状態を前提とするため、ロールバック後のフルバンドル提供や、特定のチャンネルだけに段階配信する運用では、Update Detailsページの表示内容と実機挙動を併せて確認しておく必要があります。

独自のアップデートサーバーを使っているプロジェクトでは、bsdiff差分の生成と配信の実装を整える必要があります。Expoはこのために、custom-expo-updates-serverリポジトリのブランチで参考実装を提供しており、自社サーバーへ取り込む際のベースとして利用できる形です。EAS Updateを使わない構成であっても、bsdiff前提の挙動に対応しておくことで、SDK 56以降の更新エコシステムと足並みをそろえられます。

Expo SDK 56へ移行する既存プロジェクトの判断基準と戦略

SDK 56への移行は、技術的な作業だけでなく、ビジネス影響と保守体制の観点も含めた意思決定の場面となります。移行のタイミング、移行の範囲、移行の進め方を判断するための軸を持っておけば、過剰な負荷を避けつつ計画的に進められるはずです。本章では、判断基準、業務影響、チーム規模、互換性チェック、運用見直しの5つの観点から、現実的な戦略を整理します。

即時移行・段階移行・据え置きを判断するための4つの基準と適用例

移行のタイミングは、即時移行・段階移行・据え置きの3パターンに大別できます。判断軸として有効なのは、利用OSの分布、利用ネイティブモジュールの規模、運用中アプリの重要度、開発リソースの余裕度の4点です。

1. 利用OSの分布：iOS 16.4以上のユーザーが大多数なら即時、未満が一定数いるなら段階、業務都合で旧OS固定なら据え置きを基本検討する
2. 利用ネイティブモジュールの規模：自社モジュールやサードパーティモジュールが少数なら即時、多数で互換確認に時間がかかるなら段階を選ぶ
3. 運用中アプリの重要度：ミッションクリティカルな業務アプリほど慎重な段階移行が向き、社内ツールやプロトタイプは即時移行が現実的
4. 開発リソースの余裕度：移行に専任を割けるなら即時、他プロジェクトと並行しているなら段階を選ぶ

これら4軸を組み合わせて判断すると、自分のプロジェクトに合った移行モードが見えてきます。完全な据え置きを長期間続けるのは技術的負債の蓄積につながるため、据え置きを選ぶ場合でも、いつまで据え置くかというデッドラインを併せて設計するのが望ましい考え方です。

業務影響範囲別に見たアップグレードのタイミング判定軸と検討材料

業務影響範囲の観点では、ストア提出スケジュール、決算期や繁忙期といった事業サイクル、関係する外部システムのリリース計画が判定軸となります。SDK 56への移行は、ネイティブビルドの再生成と検証を伴うため、リソース集中投下が必要なフェーズが発生します。繁忙期と重なるとリスクが跳ね上がるため、相対的に余裕のある時期に移行を計画するのが基本姿勢です。

検討材料として有効なのは、ストアのAPIレベル要件改定スケジュール、利用しているプッシュ通知サービスやアナリティクス基盤の対応状況、CI/CDの稼働状況などです。とくにストア側の最低APIレベル引き上げは、移行を後回しにできない強制力を持ちます。SDK 56でcompileSdkVersion 36が前提となる構成は、ストア要件への追随という観点でも合理的な選択肢です。

外部の連携先がある場合、相手側のリリーススケジュールと競合しないかの確認も大切です。SDKや認証ライブラリ、決済SDKといった重要モジュールの更新と同時期にExpo SDKを移行すると、トラブル発生時の切り分けが難しくなります。可能な限り、影響範囲の異なる更新を時期的に分散させる運用が現実的です。

チーム規模別に見た移行スケジュール設計の現実的な目安と工数感の把握

チーム規模ごとに、移行スケジュールの組み方は変わります。1人体制の小規模プロジェクトであれば、数日から1週間程度で集中的に移行と検証を回し切る計画が現実的です。Continuous Native Generation前提のプロジェクトであれば、ネイティブビルドの再生成とnpx expo-doctor@latestの実行を主軸に、最小限の手数で完結します。

数名規模のチームでは、役割分担を意識した計画が有効です。1人がexpoとネイティブモジュールのアップグレードを担当し、別の1人が@react-navigation/*の置き換えとUI回帰確認、もう1人がEAS BuildとEAS Updateの検証を担当するといった分担で進めると、並行作業による短縮効果が得られます。プルリクエストを小さく分けると、レビュー負荷も平準化できます。

大規模チームの場合は、SDK 56対応用のフィーチャーブランチを切り、各機能チームが順次マージしていくスタイルが現実的です。リリースカレンダーに移行の各マイルストーンを書き込み、QAと連携してリグレッションテストを計画します。工数感としては、関係者の合意形成や検証フェーズを含めて数週間規模になることが一般的であり、大幅に圧縮するよりも余裕を持って組むのが結果的に低コストな選択になります。

ライブラリ互換性チェックリストで確認すべき7項目とその実務的な意味

互換性チェックは網羅性が肝心です。以下のような項目を順に押さえると、見落としを減らせます。

• 各サードパーティライブラリのSDK 56・React Native 0.85系対応の有無
• ネイティブモジュールのcompileSdkVersionおよびdeploymentTargetの整合
• ナビゲーション関連で@react-navigation/*の直接importが残っていないか
• カレンダー・連絡先・メディアライブラリ系の旧API利用が残っていないか
• EAS Build・EAS Updateのプロファイルで利用するイメージやSDK指定が新基準か
• プッシュ通知の構成がexpo-notifications config plugin方式か
• Expo Go経由の動作確認に依存している箇所がないか

これらは、SDK 56で実際に問題が顕在化しやすい領域を反映した観点です。チェックリストはプロジェクト固有の事情に合わせて拡張しながら、移行作業のたびに更新していくのが運用上の良い習慣となります。リスト形式で残しておくと、次回の移行時にも再利用できる資産になります。

移行後の運用で押さえるべきEAS Update・配信戦略の見直し

SDK 56移行を済ませたあとの運用では、配信戦略の見直しを併走させておくと長期的な保守コストが下がります。bsdiffのデフォルト化に伴い差分配信が前提となるため、リリースチャンネルの設計、ロールバック手順、段階配信の運用ルールを再点検します。EAS UpdateのUpdate Detailsから差分配信の状況を可視化し、運用上のKPIに組み込む発想も有効です。

Expo Goへの依存度を下げ、Development BuildとEAS Buildを軸とした検証フローを整備しておくと、SDK更新時の影響範囲を抑えやすくなります。SDK 56以降のExpoは、Development Build前提の運用を一段と推奨する方針が明確であり、長期的にはこの方向に揃えることがエコシステムとの相性を高める選択になります。

OS要件の引き上げに伴うユーザーコミュニケーションも、移行後の運用に含めて設計しておくとトラブルを減らせます。リリースノート、ストア説明文、アプリ内告知の3点で、サポート対象OSの変更を一貫したメッセージで伝える運用が望ましい姿です。SDK 56への移行を「単発の技術タスク」で終わらせず、配信戦略・コミュニケーション・運用フローまで含めて一段引き上げる契機と捉えると、SDK 57以降の更新サイクルにも余裕を持って向き合えます。