Foundation Modelsが使えない場合は？2026年のトラブルシューティングガイド

Foundation Modelsが使えない場合は、まずSystemLanguageModelのavailabilityを読み、端末の対象外、Apple Intelligenceの設定、モデル未準備を分けて処理してください。生成APIの呼び出しで失敗した場合は、availabilityの確認だけで解決したと判断せず、生成時のエラーを別に調べます。シミュレーターやビルドの成功は、対象端末でモデルが動く証明にはなりません。

iOSアプリにApple Foundation Modelsを組み込み、モデルが利用できず困っている独立開発者向けです。
macOSアプリで異なるOSやモデル状態への対応を進めている開発者にも役立ちます。
リリース前に代替経路まで確認したい小規模チームも対象です。

最終更新：2026年11月1日。AppleのFoundation Models利用ガイドとavailabilityの状態定義を中心に、関連するAPI資料を確認しています。

「AI機能が動かない」だけでは、端末要件、ユーザー設定、モデル状態、アプリの呼び出し処理のどこで止まっているか判断できません。最初に、アプリがモデルを呼び出す前にavailabilityが利用不可なのか、利用可能と判定された後の生成処理で失敗するのかを分けます。Appleの利用ガイドも、モデルを使う前の利用可否確認と、使えない場合のフォールバックを案内しています。

最初の調査では、次の情報を同じ記録に残します。個人情報や入力内容をログへ含める場合は、ユーザーへの説明とデータの扱いを先に確認してください。

• [ ] 実行した端末とOSのバージョン
• [ ] アプリのビルド、利用中のSDK、呼び出した機能
• [ ] Apple Intelligenceの設定状況を確認できる範囲
• [ ] SystemLanguageModelから取得したavailabilityと理由
• [ ] エラーが発生したAPI、再現する入力、発生したタイミング
• [ ] 同じ操作で通常機能や代替経路が使えるか

この記録があれば、「モデルを利用できない状態」と「生成要求が失敗した状態」を混同しにくくなります。availabilityは確認時点の状態を示す情報であり、その後のセッションや生成要求が必ず成功する保証として扱わないでください。

AppleのAPI資料では、モデルの利用可否に関する状態と、生成時に発生するエラーが別々に説明されています。以下の表を使い、状態に応じて確認先とユーザー向けの動作を切り替えます。

availabilityの状態と利用不可理由を照合すると、端末が対象外の状態、機能が有効でない状態、準備待ちを切り分けて扱えます。端末が対象外なのに再起動や再試行だけを促すと、解決しない操作をユーザーに繰り返させるため、状態に応じた案内が必要です。

端末が対象外の場合

deviceNotEligibleは、現在の端末がモデル利用条件を満たさない場合の分岐です。アプリの最低OSバージョンを満たしていることと、Foundation Modelsを利用できる端末であることは別の確認事項です。AppleのApple Intelligence対応要件を参照し、対応範囲を推測でアプリの案内に書かないようにします。

ユーザーに端末の変更を求める前に、生成機能がない場合でも完了できる主要操作を明確にしてください。たとえば文章の下書きで生成を使えないときは、手入力や既存テンプレートを選べるようにします。モデルが使えないユーザーをアプリの基本機能から締め出さない設計が、障害時の影響を抑えます。

Apple Intelligenceが未有効の場合

設定がオフであることは、端末が対象外であることと同じではありません。状態を見分けたうえで、必要であればシステム設定を確認するよう案内します。ただし、アプリがユーザーに代わってApple Intelligenceを有効化できると説明したり、設定変更を必須にしたりしてはいけません。

案内文は「利用するには設定を確認してください」といった任意の表現にし、今は有効にしない場合の操作も同じ画面から選べるようにします。生成AIの機能を利用できないときの選択肢や期待値については、Appleの生成AI向けデザイン指針も参照できます。

モデルが準備中の場合

modelNotReadyは、モデルがまだ利用可能になっていない状態として扱います。AppleのmodelNotReadyに関する説明を確認し、準備待ちを示す表示、ユーザー操作による再確認、生成機能を使わない経路を組み合わせます。

実装では、画面を開いたまま要求を連打する設計を避け、状態が変わらない場合にユーザーが待機を打ち切れるようにします。また、availabilityでmodelNotReadyと確認された場合と、生成APIの呼び出し後にアセット関連エラーを受けた場合は、観測場所が異なります。表示やログで同じ「準備中」にまとめず、どの段階で起きたかを残してください。

注意：availabilityを確認した直後に生成が成功するとは限りません。確認結果と生成結果を別々に記録し、片方の成功で他方の状態を決めつけないようにします。

利用可能なのに生成できない場合

availabilityが利用可能でも、セッションの作成や生成要求の途中で失敗する可能性があります。まず、失敗が起きた段階、エラー型、対象OS、再現する入力を記録し、モデル利用不可の分岐とは独立して調査します。LanguageModelSessionの資料でセッションと要求の扱いを確認し、利用中のSDKに対応するAPIと照らし合わせてください。

特にアセット関連のエラーは、モデルのavailability状態と同じものとして扱わないでください。現行のassetsUnavailableエラー説明と、LanguageModelSessionにおける生成エラーの説明を確認します。エラーの型や扱いがOSのバージョンによって異なる可能性があるため、生成エラーと移行情報を読み、対象のデプロイ範囲でコンパイルと実行の両方を確かめます。

Xcode 27でビルドが通ることは、ソースコードやビルド設定の確認にはなりますが、対象端末でモデルが使えることの確認にはなりません。シミュレーターで画面遷移やエラー表示を検証できても、Apple Intelligenceを使った対象端末上の実行確認とは分けて記録します。

次の手順で、実行条件とフォールバックの境界を確認します。

1. 確認対象を固定する
   対象のOS、端末、アプリのビルド、利用するFoundation Models APIをテスト記録に残します。Appleの要件が更新される可能性を考慮し、端末の対応可否は公開前に公式資料で再確認します。

2. availabilityを画面に反映する
   モデルを使う直前にavailabilityを取得し、利用不可理由ごとに画面表示と処理を分けます。特定の状態を推定して動作を決めず、実際に取得した状態をもとに分岐します。

3. 未有効時の案内を確認する
   Apple Intelligenceの設定を案内する場合は、設定を変更しない選択肢も用意します。案内を閉じた後も、アプリの主要操作が続けられるかを確かめます。

4. 未準備時の再確認を確認する
   modelNotReadyの画面で待機が続きすぎないか、ユーザーが再確認できるか、待たずに別の方法へ進めるかを確認します。再試行を止める条件も実装とテストで明確にします。

5. 生成段階の失敗を分けて確認する
   availabilityが利用可能な状態から生成要求を行い、セッション作成と生成処理のどこでエラーが起きたかを記録します。アセット関連エラーを含む失敗時に、入力の再編集や通常機能へ戻れるかも確認します。

6. 対象端末で最終確認する
   実際に利用する端末上でavailability、生成処理、フォールバックを確認します。実機テストを実施していない場合は、シミュレーターやビルドの結果をモデル実行の検証結果として報告しないでください。

このチェックを使うと、コードやビルドの問題と、端末・ユーザー設定・モデル状態による利用不可を切り分けられます。遠隔のMacはXcodeプロジェクトのビルドやコード経路の確認には使えますが、対応するiPhone上でのモデル実行を代わりに証明するものではありません。遠隔Macで行った確認と、実機で行った確認は、リリース記録でも別項目にしてください。

deviceNotEligibleが返った場合の扱い

この状態では、現在の端末がモデルの利用条件を満たさない可能性があります。モデルを再取得する操作や再起動を何度も促すより、モデルなしでも主要な操作を完了できる経路を示してください。端末要件とアプリの最低OS要件は別々に確認し、対象範囲はAppleの最新資料を基準に案内します。

Apple Intelligenceを有効にしても利用不可になる理由

設定が有効でも、availabilityが利用可能とは限りません。端末の条件やモデルの準備状態など、返された状態をあらためて確認してください。アプリ内の案内は設定変更を強制せず、ユーザーが機能を有効にしない場合にも、生成を使わない操作へ進める構成にします。

modelNotReadyのときに再試行する方法

一時的な状態として後から再確認できるようにする一方、自動で要求を繰り返し続ける設計は避けます。ユーザーに準備中であることを伝え、再確認の操作と、待機しない場合の代替経路を用意してください。availability上の状態なのか生成後のエラーなのかも、ログで区別します。

assetsUnavailableが生成時に発生したときの確認点

生成要求の段階で起きたエラーとして、発生したAPI、エラー型、OSとSDK、再現条件を記録します。availabilityが利用可能だったという理由だけで、生成処理の問題を端末の対象外と結論づけないでください。対象OSに対応するAppleのエラー資料を確認し、再試行や代替処理を実機で検証します。

手元の開発環境だけで運用すると、ストレージや実行環境をほかの作業と共有するため、ビルドやコード経路の再確認が滞ることがあります。一方、共有CIだけに寄せると、実行環境を細かく調べたい場面や再現条件を保った検証で制約が出る場合があります。こうした負担を減らす目的なら、Xcodeプロジェクトの構築やコード分岐の確認用にMac環境を一時利用する選択肢があります。

JEXCLOUDのリモートMac利用案内で利用方法を確認し、必要な期間だけ使う場合はMac利用プランを比較できます。ただし、レンタルMacでのビルド成功をFoundation Models対応端末での実行結果として扱うことはできません。モデルの可否と生成動作は、対象となる実機で別途確認してください。