GeminiをApple Foundation Models frameworkで使う導入判断：Firebase AI Logic、Xcode、App Store提出条件

このテーマをもう少し広げて見るなら、Gemini Enterprise Agent Platformの導入判断：Vertex AI移行、Agent Runtime、価格で確認すること と Google×KaggleのAI Agents Intensive Course：6月15日開始、参加前に確認すること も合わせて確認してください。Firebase AI LogicでVertex AI Gemini API側を選ぶ場合に、企業向け基盤と価格確認の続きとして読めるため。

3行まとめ

試せること

Firebase AI Logic経由で、AppleのFoundation Models frameworkからGeminiを使う導線が示された。

まだ待つこと

2026年6月14日JST時点ではpublic previewで、beta APIと次のXcodeのGA待ちが残る。

確認すること

Xcode 27 beta、Firebase Apple SDKのpreview branch、App Check、APIプロバイダ、対応モデルを順に見る。

話題性よりも、検証で使える範囲と本番提出に必要な条件を切り分けることが重要になる。

• GoogleはWWDC 2026に合わせ、Apple開発者がFirebase AI Logic経由でGeminiをAppleのFoundation Models frameworkから使える道筋を示した。
• ただしFirebase docsでは、この統合はpublic previewで、beta APIに依存し、次のXcodeがGAになってproduction submissionsをサポートするまでApp Store提出に使えないと明記されている。
• いま見るべき判断軸は、話題性よりも、Xcode 27 beta、Firebase Apple SDKのpreview branch、App Check、APIプロバイダ、対応モデル、GA後の再確認手順である。

WWDC 2026周辺では、AppleのFoundation Models framework、SiriやApple Intelligence、GoogleのGemini提供、Firebase AI Logicの開発者向け資料が同じ文脈で語られやすい。専門メディアや開発者動画でも反応が出ており、AppleアプリにクラウドLLMを組み込む導線として読者需要は強い。

ただし、この記事では「AppleとGoogleがAIで組んだらしい」という大きな話に広げすぎない。主題は、Apple開発者がGeminiをFoundation Models framework経由で試すとき、どこまで公式確認済みで、どこから本番投入待ちなのかを分けることだ。Apple PCCやConfidential AIの基盤側を確認したい場合は、先に<a href="https://googl-watch.blog.mo-gmo.com/googl-44-google-cloud-apple-pcc-confidential-ai/">Google CloudとApple PCCのConfidential AI</a>の記事を読むと、今回のFirebase実装との違いが見えやすい。

WWDC 2026後に何が試せるようになったのか

1. 2026年6月8日 Google Blog

   GeminiモデルをApple開発者に届けるという製品発表の入口になる。

2. 2026年6月9日 Firebase Blog

   Firebase Apple SDKとFirebase AI Logicを使う実装の流れを補足する。

3. Apple Developer WWDC26

   Foundation Models frameworkがLLM providerを受け入れる考え方を理解する補助線になる。

4. Firebase docs

   preview branch、App Check、対応モデル、本番提出条件などの実務条件を確認する場所になる。

大きなAI連携ニュースではなく、Firebase AI Logic経由でAppleアプリに入れる条件として読む。

今回の入口は3つある。Google Blogは2026年6月8日付で、Apple開発者がGeminiモデルをAppleのFoundation Models frameworkから呼べるようになると説明した。Firebase Blogは2026年6月9日に、Firebase Apple SDKとFirebase AI Logicを使う実装の流れを補足した。Apple Developer側には、Foundation Models frameworkへLLM providerを持ち込むWWDC26セッションがある。

ここで大事なのは、発表元ごとの役割を分けることだ。Google Blogは「GeminiをApple開発者に届ける」という製品発表の入口であり、Firebase BlogとFirebase docsは「Appleアプリに入れるには何を設定するか」の実装資料である。Apple Developerのセッションは、Foundation Models framework側がどのようにLLM providerを受け入れるかを理解する補助線になる。

Google、Firebase、Appleの発表を分けて読む

Google Blogでは、AppleがWWDCでFoundation Models frameworkを第三者のクラウドモデルプロバイダに開いたことを受け、GeminiモデルをFirebase Apple SDK経由で利用できると説明している。対象として挙がるOSはiOS 27、macOS 27、iPadOS 27、visionOS 27、watchOS 27だ。

Firebase側の資料では、より実装に近い表現になる。Firebase AI Logicを有効化し、Gemini API providerを選び、Firebase Apple SDKのpreview branchをSwift Package Managerで追加し、FirebaseAILogicとFirebaseAppCheckを使う。既存のFirebaseアプリなら入り口は近いが、通常の安定版SDK導入とは違う。

Apple側のWWDC26セッションは、Foundation Models frameworkへ新しいLLM providerを実装する考え方を扱う。記事本文ではAppleの実装詳細を追いすぎず、Apple API上の抽象化と、Firebase/Gemini側の提供条件を分けて見る。

Foundation Models frameworkからクラウドGeminiを呼ぶ意味

この統合の読みどころは、AppleのオンデバイスモデルとクラウドホストのGeminiを、同じFoundation Models frameworkのAPI面から扱えるようにする点にある。アプリ側は用途に応じて、ローカル推論とクラウド推論を切り替える設計を考えやすくなる。

Firebase docsは、オンデバイスモデルの利点を最大限のプライバシー、ゼロコスト、オフライン対応として整理している。一方、クラウドホストのGeminiは、大きなコンテキストウィンドウ、高度な能力、より強い推論力を使いたい場面に向く。

つまり、これは単純な「GeminiをiPhoneアプリから呼べる」という話ではない。短い補助、オフライン前提、プライバシー優先ならオンデバイス寄り。長文の理解、画像生成、高度な推論、クラウドモデルの更新速度を重視するならGemini寄り。アプリごとに、どちらを既定にするか、失敗時にどうfallbackするかを決める話になる。

いまは本番投入より検証枠で見る

項目	内容	見方
public preview		SLAやdeprecation policyの対象外で、後方互換性のない変更が起きる可能性がある。
beta API依存		SDK branch、APIの形、対応モデル、App Check手順が変わる前提で読む必要がある。
App Store提出不可		次のXcodeがGAになり、production submissionsをサポートするまで提出には使えない。
公開前の再確認		Firebase docsの更新、Xcodeの状態、対応モデル、提出条件をリリース前チェックに入れる。

単純な可否ではなく、検証用の段階と本番提出に進める段階を分けて管理したい。

この話題でいちばん誤解しやすいのは、「Foundation Models frameworkからGeminiを使える」と「App Storeに出す本番アプリへ今すぐ入れられる」を混同することだ。2026年6月14日JST時点のFirebase docsでは、この統合はpublic previewであり、beta APIに依存している。

本番アプリの開発者にとって、最大のゲートはここにある。Firebase docsは、次のXcode versionがGeneral Availabilityになり、production submissionsをサポートするまで、この統合を使ったアプリはApp Storeへ提出できないと説明している。PoC、社内検証、beta環境での動作確認には価値があるが、近日リリース予定のアプリへ組み込むなら待つ判断が自然だ。

public previewであることの意味

根拠

Firebase docsのpublic previewは、SLAやdeprecation policyの対象外で、後方互換性のない変更が起きる可能性があるという扱いだ。SDK branch、対応モデル、APIの形、App Store提出条件、App Check手順が変わる前提で読む必要がある。

注意点

このため、記事や社内メモでは「Firebase AI LogicでAppleアプリからGeminiを使える」とだけ書くのは足りない。「2026年6月14日JST時点ではpublic preview」「本番提出にはXcode GA後の再確認が必要」「Firebase docsの更新を公開前チェックに入れる」までセットで残したい。

App Store提出不可という最大のゲート

根拠

App Store提出不可は、本文の末尾に小さく置く注意書きではない。導入判断の中心に置くべき条件だ。開発者がこの制約を見落とすと、プロトタイプでは動いたのに、リリース工程で止まる。

確認項目

実務では、次の4点をリリース前チェックに入れるとよい。

• 次のXcodeがGAになり、production submissionsをサポートしているか。
• Firebase Apple SDKでwwdc26-preview branchが必要な状態か、安定版へ移っているか。
• Foundation Models framework向けGemini統合のpublic preview注記が変わっていないか。
• App Store審査向けに、外部AIモデル、データ送信先、ユーザー説明文、feature flag、停止手順を説明できるか。

試してよいケース、待つべきケース

評価基準

いま試す価値があるのは、beta OSやXcode betaを検証できるチーム、既存FirebaseアプリでAI機能のPoCを進めたいチーム、Foundation Models frameworkの抽象化に早めに慣れたい開発者だ。App CheckやFirebase consoleの設定も含めて検証すれば、GA後の移行判断が早くなる。

待つ判断

逆に、App Store審査が近いアプリ、SLAが必要な企業アプリ、規制業界、教育や医療などデータ説明が重い領域では、GAと公式docs更新を待つ方がよい。今の段階で「本番採用」と書くより、「検証で得た知見を残し、公開条件が整ったら再判定する」と扱うのが安全だ。

実装経路はFirebase AI Logicを中心に組む

1. 1Firebase projectを用意

   Appleアプリを登録し、Firebase AI Logicを有効化する。

2. 2APIプロバイダを選ぶ

   個人開発ではGemini Developer API、企業利用では管理要件に合う選択肢を検討する。

3. 3preview branchを追加

   Swift Package ManagerでFirebase Apple SDKのpreview branchを使い、必要なモジュールを入れる。

4. 4App Checkを組み込む

   FirebaseAILogicとFirebaseAppCheckを合わせて、呼び出し経路の保護を前提にする。

5. 5最小promptで確認

   LanguageModelSessionの初期化、応答表示、失敗時のエラー表示まで確認する。

バックエンド不要という説明は、保護設計や料金管理が不要という意味ではない。

実装の中心はFirebase AI Logicだ。Firebase AI Logicは、モバイルやWebアプリからGemini APIへ直接アクセスするためのクライアントSDK、プロキシサービス、Firebase連携を提供する。Apple向けにはSwiftのFirebase Apple SDKを使う。

Google Blogは、Firebase AI Logicを使うことで、iOS、macOS、iPadOS、visionOSアプリにGeminiを直接統合でき、別途バックエンドサーバーを構築・維持しなくてもよいと説明している。ただし、バックエンド不要という言葉は「保護設計が不要」という意味ではない。App Check、APIプロバイダ、料金、利用上限、ログ、ユーザー説明は別途見る必要がある。

Firebase projectとAPIプロバイダを選ぶ

条件

Firebase Blogの導入手順では、まずFirebase projectを作り、Appleアプリを登録し、Firebase AI Logicを有効化する。次にGemini API providerを選ぶ。個人開発や早期検証ではGemini Developer APIが入り口になりやすい。企業利用では、組織のクォータ、データ取り扱い、管理要件に合わせた企業向けの選択肢を検討する。

確認項目

ここでの判断は、単に「無料枠があるか」だけではない。社内プロジェクトでは、請求先、プロジェクト権限、APIキーや認証情報の管理、利用ログ、データ保持、国や地域の要件、監査対応まで見る必要がある。Google CloudやVertex AI側のモデル選定を深く確認する場合は、<a href="https://googl-watch.blog.mo-gmo.com/googl-35-gemini-35-flash-vertex-ai-checklist/">Gemini 3.5 Flashの導入判断</a>で扱ったモデルID、価格、移行前チェックの観点も近い。

XcodeとFirebase Apple SDKのpreview手順

前提条件

Firebase docsの前提条件では、最新のXcode 27 beta、対応するbeta OSのシミュレータまたは実機、新しいSwiftUIインターフェースのAppleプラットフォームアプリが挙げられている。初期リリースで対応するAppleプラットフォームはiOSとmacOSだ。

preview手順

SDK導入では、Swift Package ManagerにFirebase Apple SDK repositoryを追加し、Dependency RuleをBranchにしてwwdc26-previewを指定する。さらに、アプリターゲットへFirebaseAILogicとFirebaseAppCheckを追加する。これはpreview特有の手順であり、通常のFirebase Apple SDK導入と同じ感覚で進めると見落としやすい。

注意点

本文で長いコードを写す必要はない。公式docsにはFirebaseApp.configure()、FirebaseAI.firebaseAI(backend: .googleAI())、geminiLanguageModel、LanguageModelSessionを使う例がある。開発チームは、コードの写経よりも、どこがAppleのFoundation Models APIで、どこがFirebase/Gemini側の責務なのかを分けて理解したい。

Foundation Models API上の呼び出し方

呼び出しの境界

概念としては、Firebase AI Logic側でGeminiモデルを用意し、そのモデルをAppleのLanguageModelSessionへ渡す。テキスト生成ならrespond(to:)、ストリーミングならstreamResponse(to:)のようなFoundation Models側の呼び出しに乗せる。

残る設計課題

この形の利点は、アプリのAI機能をApple側の標準APIに寄せながら、クラウドGeminiの能力を選べることだ。一方で、呼び出し先がクラウドになる以上、ネットワーク、レイテンシ、コスト、入力データ、障害時のUI、地域やユーザー説明は別の設計問題として残る。

App Checkと認証・保護の考え方

1. 1App Check

   実際のアプリと改ざんされていないデバイスからのリクエストに寄せるための層になる。

2. 2App Attestとdebug provider

   検証ではdebug provider、本番に近づける段階では実デバイス向けproviderとenforcementを確認する。

3. 3認証と権限

   誰がどのAI機能を使えるかは、App Checkとは別にユーザー認証と権限で決める。

4. 4上限と停止手順

   利用上限、feature flag、kill switchを用意し、想定外の呼び出し増加に備える。

5. 5データ分類

   プロンプトに入る情報、ログ保持、ユーザー説明、削除依頼への対応を事前に決める。

AI機能では入力内容と呼び出し回数が品質、コスト、リスクに直結する。

Firebase docsは、Firebase AI Logicに関連するAPIを保護するためにFirebase App Checkを使うことが重要だと説明している。App Checkをenforceすると、実際のアプリと改ざんされていないデバイスから来たリクエストだけを許可する方向に寄せられる。Apple向けにはApp Attestなどのattestation providerを使える。

ただし、App Checkを万能のセキュリティ機能として扱うのは危ない。App Checkは、改ざんアプリや不正なクライアントからの呼び出しを抑える層であり、ユーザー認証、権限管理、課金上限、プロンプト設計、機密データの分類を置き換えるものではない。

App Checkは必須級の前提として扱う

保護できること

PoCの段階でも、App Checkを後回しにしない方がよい。最初はdebug providerで動作確認し、本番に近づける段階でApp Attestなどの実デバイス向けproviderとenforcementを確認する。後から入れると、AI機能そのものは動いているのに保護層のテストが足りない、という状態になりやすい。

追加で設計すること

特にAI機能は、リクエスト回数や入力内容がコストと品質に直結する。App Check、利用上限、feature flag、kill switchを分けて設計し、想定外の呼び出しが増えた時に止められるようにしたい。

個人開発と企業開発で選ぶものが違う

個人開発の入口

個人開発では、Firebase projectを作り、Gemini Developer APIで試し、App Check debug providerを使って最小のプロンプトを通すところから始めやすい。料金やクォータは小さく始められるが、公開前にはAPIキー、請求、App Check enforcement、ユーザー説明を改めて確認する必要がある。

企業開発の判断軸

企業開発では、別の観点が増える。どのFirebase projectを使うか、誰が管理者か、請求先はどこか、ログをどこまで残すか、ユーザー入力をどのデータ分類で扱うか、障害時に誰が止めるか。Gemini APIの便利さより先に、組織の運用設計が問われる。

クライアント直呼びのリスクをどう読むか

利点と境界

Firebase AI Logicは、モバイルやWebアプリからGemini APIへ直接アクセスしやすくする。これは開発速度の面で大きいが、クライアントからAI機能を呼ぶ以上、保護できる範囲とできない範囲を明確にする必要がある。

注意点

たとえば、App Checkは不正クライアント対策に効くが、ログに残すべきプロンプトの扱い、ユーザーごとの権限、生成結果のレビュー、課金上限、プロンプトインジェクションへの対策を単独で解決するわけではない。高リスクな用途では、Firebase AI Logicを使いつつ、サーバー側の追加審査やfeature flagを組み合わせる選択肢も残る。

使えるモデルとユースケースを先に絞る

項目	内容	見方
general purpose models		説明文生成、メール下書き、検索補助、チャット要約などのテキスト中心の用途を見る。
image-generating models		画像生成を入れる場合は、生成物の扱い、コンテンツポリシー、ユーザー説明まで確認する。
対象外のモデル		Gemini Live API modelsとImagen modelsは、Foundation Models framework向けGemini統合の対象外として扱う。
Gemini 2.5 models		技術的には対応していても、新規プロジェクトでは推奨されず、特別な設定が必要になる。
オンデバイスとの使い分け		端末内で閉じたい短い補助はオンデバイス、長い入力や画像生成はクラウドGeminiを候補にする。

モデル名にpreviewが含まれる場合は、モデルID、価格、提供条件、rate limit、利用地域を公開前に見直したい。

Firebase docsは、Foundation Models framework向けGemini統合でサポートされるモデルを分けている。2026年6月14日JST時点では、general purpose modelsとしてgemini-3.1-pro-preview、gemini-3.5-flash、gemini-3.1-flash-liteが挙がっている。image-generating modelsとしては、gemini-3-pro-image-preview、gemini-3.1-flash-image-preview、gemini-2.5-flash-imageが挙がる。

一方、Gemini Live API modelsとImagen modelsは対象外だ。さらに、Gemini 2.5 modelsは技術的には対応しているが、新規プロジェクトには推奨されず、このガイドで扱わない特別な設定が必要とされている。

対応Geminiモデルを一覧化する

対応範囲

アプリ企画の段階では、まず「使いたい体験」と「対応モデル」を結びつける。短い説明文の生成、メール下書き、検索補助、チャットの要約ならgeneral purpose modelsを見る。画像生成を入れるなら、image-generating modelsが候補になる。ただし、画像生成はコンテンツポリシー、生成物の扱い、ユーザー説明、年齢制限などの確認が増える。

previewモデルの注意点

名前にpreviewが含まれるモデルを本番要件に入れる時は、とくに注意したい。モデルID、価格、提供条件、rate limit、生成品質、利用地域、ポリシーは変わることがある。記事や仕様書には確認日を入れ、公開前にもう一度公式docsを見る。

オンデバイスAppleモデルとクラウドGeminiの使い分け

オンデバイスモデルは、ネットワークなしで短い補助をしたい、ユーザー入力を端末内に閉じたい、コストを抑えたい場面に向く。クラウドGeminiは、長い入力、複雑な推論、画像生成、モデル更新の速さ、アプリ外の知識や高度な能力を使いたい場面に向く。

両者を混ぜるなら、ユーザーに見える挙動も設計する必要がある。オフライン時はオンデバイスにfallbackするのか、Geminiが使えない時は機能を隠すのか、回答の品質差をどう説明するのか。Foundation Models frameworkの抽象化は便利だが、UX上の差が消えるわけではない。

失敗時のfallbackを設計する

確認項目

AI機能は、正常時のデモだけでは判断できない。Gemini呼び出し失敗、App Check失敗、ネットワーク断、モデル非対応、rate limit、SDK変更、preview API変更の時、アプリがどう振る舞うかを決めておく。

合格条件

最低限、利用者に見せるエラー文、再試行の有無、ローカル処理へのfallback、機能停止のfeature flag、ログに残す情報、個人情報をログへ残さないルールを用意したい。App Store提出が可能になる前に、この運用メモまで作っておくと、GA後の判断が速い。

開発チームが検証する最小チェックリスト

beta環境

Xcode 27 betaとbeta OSの組み合わせで、新規SwiftUIアプリを小さく起動する。

Firebase設定

Apple app登録、AI Logic有効化、APIプロバイダ選択、preview branch追加を確認する。

最小経路

Firebase初期化、App Check、モデル初期化、LanguageModelSession、レスポンス表示を通す。

失敗時の扱い

エラー表示、ログ、feature flag、停止手順を用意し、PoCの成功を本番コードに広げすぎない。

非機能要件

レイテンシ、コスト、データ分類、ログ保持、品質評価、誤回答への対応を表にしておく。

リリース条件

GA後のFirebase docs、Xcode、App Store提出条件、対応モデルを公開前に再確認する。

最初の合格条件は品質評価ではなく、検証経路が正しくつながることに置く。

検証は「Geminiの回答が出た」で終わらせない。Foundation Models framework経由でGeminiを使う場合、Apple側のbeta環境、Firebase project、AI Logic、App Check、対応モデル、エラー処理、リリース条件を一続きで見る必要がある。

まずは小さいPoCでよい。新規SwiftUIアプリを用意し、Xcode 27 betaとbeta OSの組み合わせで起動する。Firebase projectにApple appを登録し、AI Logicを有効化し、Gemini API providerを選び、Firebase Apple SDKのwwdc26-preview branchを入れる。FirebaseAILogicとFirebaseAppCheckを追加し、debug providerでApp Checkを通し、最小promptで応答を確認する。

まず動作確認する範囲

最初の合格条件

最初の合格条件は、AI機能の品質評価ではなく、経路が正しくつながることだ。Firebase初期化、App Check、モデル初期化、LanguageModelSession、レスポンス表示、失敗時のエラー表示を確認する。

注意点

この段階で、公式docsにあるコード例をそのまま本番コードに広げない。プロジェクト名、API provider、モデルID、App Check provider、ログ、feature flag、ユーザー説明を自分のアプリに合わせて分ける。PoCのコードが動いたことと、運用できることは違う。

本番化前に見る非機能要件

評価基準

GA後に本番化を考えるなら、次の非機能要件を早めに表にしておく。

• レイテンシ。オンデバイスとクラウドGeminiで、ユーザーが待てる時間は違うか。
• コスト。ユーザーごとの使用量、無料枠、上限、異常利用時の停止手順はあるか。
• データ。プロンプトに入力される情報の分類、ログ保持、ユーザー同意、削除依頼への対応を決めているか。
• 品質。モデルごとの差、生成失敗、誤回答、画像生成の制限をどこまで許容するか。
• 運用。feature flag、kill switch、問い合わせ窓口、障害時の社内連絡先を用意しているか。

注意点

preview時点の結果を、本番性能や将来の価格として断定しないことも大事だ。検証ログには、確認日、Xcode version、OS version、Firebase SDK branch、モデルID、API providerを書いておく。

Apple審査と社内承認のために残すメモ

審査で説明すること

App Store提出が可能になる段階では、審査や社内承認に向けて説明できる情報が必要になる。使っているSDK、モデル、クラウド送信の有無、ユーザー入力の扱い、生成AI機能の説明、ユーザーが機能をオフにできるか、問題が起きたときに止められるかを残す。

社内承認で見ること

企業アプリでは、さらにセキュリティレビュー、法務レビュー、データ保護レビューが入ることがある。Firebase AI Logicは導入を軽くするが、承認プロセスを消すものではない。早期検証の価値は、コードを先に書くことだけではなく、承認に必要な論点を早めに洗い出せる点にもある。

いま試す人、待つ人、次に読むもの

いま試す人

beta環境を触れる開発者、PoC担当者、既存FirebaseアプリのAI機能を調査しているチーム。

まだ待つ人

近日リリース予定の本番アプリ、SLA必須の企業アプリ、規制や監査の重い領域。

次に確認するもの

Firebase docs、XcodeのGA状況、production submissions対応、対応Geminiモデルの更新。

読み分ける観点

AppleのAI基盤全体ではなく、SwiftアプリにFirebase AI Logicで入れる条件として確認する。

期待値を上げる前に、public preview、beta API依存、App Store提出条件を読者の判断軸に置く。

今回のGeminiとApple Foundation Models frameworkの連携は、Appleアプリ開発者にとってかなり面白い。Apple標準のAI API面に寄せながら、クラウドGeminiを選べる可能性があるからだ。Firebase AI Logicを使えば、既存Firebaseアプリに生成AI機能を試す導線も短くなる。

ただし、2026年6月14日JST時点の結論は「本番投入ではなく検証枠で見る」だ。public previewであり、beta APIに依存し、App Store提出には次のXcode GAとproduction submissions対応を待つ必要がある。この条件を外してしまうと、読者に誤った期待値を渡す。

いま試す人は、beta環境を触れる開発者、PoC担当者、既存FirebaseアプリのAI機能を調査しているチームだ。待つ人は、近日リリース予定の本番アプリ、SLA必須の企業アプリ、規制や監査の重い領域、対応モデルが要件に合わないチームである。

Alphabet Watch JapanはGoogle、Alphabet、Firebase、Gemini、Google Cloudの公式発表を追う独立ブログであり、Alphabet、Google、Firebase、Appleとは非提携である。この記事は製品・サービスの確認情報であり、投資助言ではない。

---

次に読むなら

参照した主な情報源

• Google Blog: Bringing the latest Gemini models to Apple developers（2026年6月8日、確認日: 2026年6月14日JST）

https://blog.google/innovation-and-ai/technology/developers-tools/bringing-gemini-models-to-apple-developers/

• Firebase Blog: Gemini in Apple's Foundation Models framework（2026年6月9日、確認日: 2026年6月14日JST）

https://firebase.blog/posts/2026/06/apple-foundation-models-gemini/

• Firebase docs: Get started: Access the Gemini API through Apple's Foundation Models framework（確認日: 2026年6月14日JST）

https://firebase.google.com/docs/ai-logic/apple-foundation-models-framework/get-started

• Firebase docs: Gemini API using Firebase AI Logic（確認日: 2026年6月14日JST）

https://firebase.google.com/docs/ai-logic

• Firebase docs: Available capabilities when accessing the Gemini API through Apple's Foundation Models framework（確認日: 2026年6月14日JST）

https://firebase.google.com/docs/ai-logic/apple-foundation-models-framework/capabilities

• Apple Developer: Bring an LLM provider to the Foundation Models framework – WWDC26（確認日: 2026年6月14日JST）

https://developer.apple.com/videos/play/wwdc2026/339/

更新履歴

1. 2026年6月14日JST

   Google Blog、Firebase Blog、Firebase docs、Apple Developerの一次情報を確認して初版を作成した。

2. 次回の更新対象

   XcodeのGA状況、production submissions対応、Firebase Apple SDK、App Check、対応Geminiモデルを見直す。

preview統合は条件が変わる可能性があるため、公開前と更新時に公式docsを再確認する。

• 2026年6月14日JST: Google Blog、Firebase Blog、Firebase docs、Apple Developerの一次情報を確認し、初版を作成した。public preview、beta API依存、App Store提出不可、Xcode 27 beta、Firebase Apple SDKのwwdc26-preview branch、App Check、対応Geminiモデルを確認した。