9月14日の iOS 27 で、Gemini API の呼び出しは1行も変わりません — 変わるのは選択肢のほうです

9月9日のイベントの録画を、自宅の iMac で夜に見返しておりました。iOS 27 の配信が9月14日に決まった、という一行のところで手が止まりました。

頭に浮かんだのは新しい Siri のことではなく、自分のアプリの中で Gemini API を叩いている数箇所のほうでした。

——あそこは、来週から動かなくなるのでしょうか。

結論から書きますと、動かなくならないのです。ただ、その理由をきちんと言葉にできるようになるまで、私はしばらくかかりました。同じ場所で足を止めている方のために、確かめた順番のまま書き残します。

まず結論です。9月14日に壊れるものはありません

事実の側から並べます。

iOS 27 は 2026年6月8日の WWDC で発表され、Apple は9月9日のイベントで配信日を 9月14日 と示しました。目玉は刷新された Siri で、これが Google の Gemini をベースに構築されていることは、Apple と Google の双方が公表しています。

ここまでは、ニュースとして読んで終わりの話です。開発者にとっての意味は、その次にあります。

あなたのアプリが generativelanguage.googleapis.com に投げているリクエストは、Apple の更新とはまったく別の経路を通っています。エンドポイントも、API キーも、モデル ID も、OS が上がったから変わるということはありません。9月14日の朝に慌てて確認すべきコードは、原則としてないのです。

端末の中で賢くなるものと、自分が課金して呼ぶものは、別の勘定です。 この一行を最初に置いておくと、これから出てくる情報の仕分けがずいぶん楽になります。

混ざりやすい三つの層を、呼び出し口で分けます

最初のうち、私はこの三つを「iPhone の AI」とひとまとめにして考えていました。結果は芳しくありませんでした。仕様の話が出るたびに、自分のコードのどこが影響を受けるのか即答できず、確認だけで半日を溶かした日があります。

いまは、次の表のかたちで分けて考えるようにしております。

層	誰が動かすか	開発者から見た入口	費用の出どころ
Siri AI（OS 内蔵）	Apple	App Intents で自分のアプリの機能を差し出します	発生しません
Foundation Models framework	端末内、または Private Cloud Compute	Swift の API から呼びます	条件により無償枠があります
Gemini API	自分のアプリ、または自分のサーバー	HTTPS と API キー	自分の従量課金です

App Intents は、Siri AI に対して「うちのアプリではこれができます」と差し出すための枠組みです。iOS 27 では、個人的な文脈の理解、アプリの操作、画面上の内容の認識といった Siri AI 側の能力に、アプリ側の機能を接続できるように更新されています。差し出す側であって、呼び出す側ではない——ここが三層目とはっきり違うところです。

コードの側でも、同じ分け方をしておくと迷いが減ります。私はアプリ内の文章生成の入口を一つの protocol に集めて、その裏で実装を差し替えられるようにしています。

import Foundation
 
protocol TextGenerator {
    func generate(prompt: String) async throws -> String
}
 
enum GeneratorError: Error {
    case http(status: Int, body: String)
    case emptyResponse
}
 
struct GeminiGenerator: TextGenerator {
    let apiKey: String          // Keychain などから取得します。ソースに直書きしないでください
    let model: String
 
    func generate(prompt: String) async throws -> String {
        let url = URL(string: "https://generativelanguage.googleapis.com/v1beta/models/\(model):generateContent")!
        var request = URLRequest(url: url)
        request.httpMethod = "POST"
        request.setValue("application/json", forHTTPHeaderField: "Content-Type")
        request.setValue(apiKey, forHTTPHeaderField: "x-goog-api-key")
        request.httpBody = try JSONSerialization.data(withJSONObject: [
            "contents": [["parts": [["text": prompt]]]]
        ])
 
        let (data, response) = try await URLSession.shared.data(for: request)
        guard let http = response as? HTTPURLResponse else {
            throw GeneratorError.emptyResponse
        }
        guard (200..<300).contains(http.statusCode) else {
            throw GeneratorError.http(
                status: http.statusCode,
                body: String(data: data, encoding: .utf8) ?? ""
            )
        }
 
        let decoded = try JSONDecoder().decode(GeminiResponse.self, from: data)
        guard let text = decoded.candidates?.first?.content?.parts?.compactMap(\.text).first,
              text.isEmpty == false else {
            throw GeneratorError.emptyResponse
        }
        return text
    }
}
 
struct GeminiResponse: Decodable {
    struct Candidate: Decodable {
        struct Content: Decodable {
            struct Part: Decodable { let text: String? }
            let parts: [Part]?
        }
        let content: Content?
    }
    let candidates: [Candidate]?
}

呼び出し側は、実装を知りません。

let generator: TextGenerator = GeminiGenerator(
    apiKey: ProcessInfo.processInfo.environment["YOUR_API_KEY"] ?? "",
    model: "gemini-3.8-flash"
)
let caption = try await generator.generate(prompt: "この壁紙に付ける短い説明文を1文で書いてください。")

なぜこう書くかと申しますと、9月14日以降に別の実装を足したくなったとき、変更が TextGenerator に準拠する型を一つ増やすだけで済むからです。画面のコードにも、保存処理にも手を入れずに済みます。境界を先に引いておくと、外側の変化がアプリの内側まで届きません。

Foundation Models framework が「どのモデルでも」を受け入れた意味

6月の発表で、私がいちばん気になったのはここでした。

Foundation Models framework は、マルチモーダルなプロンプトに対応し、Language Model プロトコルに準拠するプロバイダであれば、Apple のモデル以外も受け入れるかたちになりました。あわせて、カスタムスキルとサーバー側でのモデル実行が加わっています。

つまり、アプリ内の機能について「Apple のモデルか、Gemini か」という二択で考える必要が薄れたのです。入口を Apple 側の枠組みに寄せておいて、その裏側でどのモデルを使うかは別に決める——そういう組み方が視野に入ります。

ただし、これはアプリの中の話に限られます。私が Gemini を使っている場面のうち、いくつかはアプリの外側にあります。画像のカテゴリ分けをまとめて処理する部分や、ストア向けの説明文を多言語で整える作業は、端末ではなく手元のスクリプトから走らせています。そこは Apple の枠組みの外に居続けますし、居続けてよいと考えております。

無償枠の条件と、それでも Gemini API を残す判断

個人開発者として見過ごせない条件が一つ案内されています。

App Store Small Business Program に登録していて、累計の初回ダウンロードが 200万未満 のアプリであれば、次世代の Apple Foundation Models を Private Cloud Compute 上でクラウド API 費用なしに利用できる、というものです。条件に当てはまるかどうかは、ご自身のアプリの実績で確認してください。

無償と聞くと、全部そちらへ寄せたくなります。私も一瞬そう考えました。それでも、Gemini API を残す理由を三つ書き出してみると、簡単に片付く話ではないと分かりました。

一つめは、同じ機能を Apple 以外のプラットフォームにも出す場合です。片方だけ別の仕組みで作ると、出力の傾向が揃わず、後から辻褄を合わせる作業が増えます。

二つめは、モデルを自分で選んで固定できることです。どのモデルが GA でどれが preview かを見てから決める習慣は、こちら側に主導権があるからこそ続けられます。この見分け方については一番強いモデルが preview で、安いモデルが GA ですに書きました。

三つめは、端末を介さないバッチ処理です。夜間にまとめて走らせる類の仕事は、そもそもアプリの中に居場所がありません。

ですから、私の答えは「どちらか」ではありませんでした。機能ごとに置き場所を決めて、両方を持ったまま使い分けます。 費用の見通しを立てるときは、単価だけでなく呼び出し回数の増え方も併せて見ておくと安全です。この点はGemini 3.8 Flash は単価が据え置きでも、請求が増えることがありますで扱いました。

9月14日までに私が済ませておくこと

残りは4日です。大掛かりなことはできませんので、次の四つに絞りました。

モデル ID の棚卸し。コードに散らばっている gemini- で始まる文字列を、設定の1箇所へ集めます。差し替えが必要になったときの作業量が、ここで決まります。
失敗時の振る舞いの確認。配信直後はネットワークが混みます。生成に失敗したとき、画面が空白のまま止まらないかどうかだけ見ておきます。
最小 iOS バージョンの据え置き。新しい API を使いたくなっても、配信直後に対応範囲を狭めると、更新していない利用者を置き去りにします。急がなくてよいところです。
問い合わせ文面の下書き。OS が上がった直後は、レビューと問い合わせが増えます。「Siri が変わったのに、このアプリは何も変わらないのですか」という趣旨の質問は、来るものとして返信の型を先に作っておきます。

四つめは技術の話ではありませんが、当日いちばん時間を持っていかれるのがここでした。先に一度書いておくだけで、その日の落ち着きがまるで違ってきます。

まだ確認が取れていないこと

正直に線を引いておきます。

Siri の裏でどの Gemini モデルが動くのか、推論がどこで走るのか、そしてそれが開発者から見えるのか——このあたりは、公表された範囲では確定していません。契約の規模についても報道が先行しています。

ですので、私は記事でも社内向けのメモでも、確認が取れていない部分は「報じられています」で止めるようにしております。断定を一つ混ぜるだけで、他の正しい記述まで疑わしく見えてしまうからです。急いで書きたい話題ほど、この線は太く引いておきたいと感じています。

まずは、コードの中に散らばっているモデル ID の文字列を1箇所へ集めるところから始めていただければと思います。私も、それだけを先に済ませて9月14日を迎えるつもりでおります。

お読みいただき、ありがとうございました。