▣ アプリ開発/2026-06-14中級

オンデバイス推論はどこまで無料で粘れるか — Foundation Models と Gemini の分かれ目を測る

WWDC 2026 で Apple Foundation Models の無償枠が広がり、端末内推論を選びやすくなりました。ただ「無料だから全部オンデバイス」とすると品質が足りない場面に当たります。端末内で粘る範囲とクラウドの Gemini に渡す範囲を、推測ではなく計測で決める手順をまとめました。

Apple Foundation Models⁴ iOS 27² オンデバイス推論 Gemini⁹ フォールバックコスト管理⁶ 個人開発⁷¹ 計測

✦ プレミアム記事

WWDC 2026 のあと、私自身が手元の小さなアプリで、試しに要約機能をオンデバイス推論に寄せてみました。無償の枠が広がったので、これまでクラウドに払っていたぶんを端末内に移せないかと考えたのです。

短い文章の要約は、驚くほど自然に端末内で完結しました。ところが、専門用語の混じった長文や、複数の話題が入り組んだ文章を渡すと、要約が表層をなぞるだけで芯を外すことが増えました。

「無料だから全部オンデバイスに」という最初の期待は、ここで一度崩れます。かといって「品質が不安だから全部クラウド」に戻すと、せっかく広がった無償枠を使わずに、短い要約にまでネットワークの往復を払うことになります。

ここでも答えは、どこまで端末内で粘り、どこからクラウドへ渡すかの線引きです。そしてこの線は、感覚で引くと必ずどちらかに寄りすぎます。計測して引くべき線です。

三つの物差しで分かれ目を見る

オンデバイスとクラウドのどちらを使うかは、ひとつの基準では決められません。私は三つの軸を分けて見るようにしました。

ひとつめは品質です。端末内モデルの出力が、そのタスクで実用に足りているか。ここは数字にしづらい部分ですが、後で触れる比較で代理の指標を作れます。

ふたつめはレイテンシです。意外に思われるかもしれませんが、短いタスクではオンデバイスのほうが速いことがよくあります。ネットワークの往復がない分、最初の一文字が返るまでが速い。逆に長い生成では、端末の処理能力が頭打ちになり、クラウドのほうが速くなる場合があります。タスクの長さで逆転する、という感覚が大事です。

みっつめはコストです。オンデバイスは無償枠の範囲なら実質ゼロ。クラウドは呼ぶたびに積み上がります。ただし「無料」を最優先にして品質を犠牲にすると、ユーザーが離れて結局高くつきます。コストは単独で見ず、品質とセットで見るべき軸です。

この三つを、自分のアプリの代表的なリクエストに対して一度きちんと測ると、「この種類のタスクは端末内で十分」「この種類はクラウドに渡したほうがいい」という分かれ目が、推測ではなく根拠を持って見えてきます。

一度だけ、自分のアプリで測る

三つの軸は、頭で考えるより一度測ったほうが早く腑に落ちます。難しい計測は要りません。代表的なリクエストを10件ほど用意し、端末内とクラウドの両方に同じ入力を渡して、処理時間と出力を並べて記録するだけです。

// 同じ入力を両方に渡し、レイテンシと出力を記録する一回限りの計測
func benchmark(_ inputs: [String]) async {
    for text in inputs {
        let t0 = Date()
        let local = try? await onDevice.summarize(text)
        let localMs = Date().timeIntervalSince(t0) * 1000
 
        let t1 = Date()
        let cloud = try? await cloudFallback.summarize(text)
        let cloudMs = Date().timeIntervalSince(t1) * 1000
 
        let faster = localMs < cloudMs ? "端末内" : "クラウド"
        print(String(format: "len=%4d 端末内=%.0fms クラウド=%.0fms 速い=%@",
                     text.count, localMs, cloudMs, faster))
    }
}

私のアプリでこれを回したとき、入力が短いうちは端末内が一貫して速く、目安として 800 文字を超えたあたりからクラウドが追い越しました。品質のほうは、出力を10件並べて読み、端末内で芯を外したものに印を付けるだけで、どの長さから危うくなるかの感覚がつかめます。

この計測は、線を引く前に一度やればよく、毎回は要りません。数字を手元に持っておくと、後の閾値調整が「なんとなく」ではなくなります。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること

✦オンデバイス推論とクラウド呼び出しの分かれ目を、品質・レイテンシ・コストの3点で計測する判断手順

✦端末内で答えきれないリクエストだけを Gemini へ回す、信頼度ベースのフォールバック実装例

✦無償枠でどこまで賄えているかを後から振り返るための、フォールバック率の集計スクリプト

Stripe による安全な決済 · いつでもキャンセル可能

✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または

メンバーシップなら全記事が読み放題 →

信頼度でフォールバックを切り替える

線引きが見えたら、それを実装に落とします。ここで避けたいのは、タスクの種類で固定的にどちらかへ振り分けてしまうことです。同じ「要約」でも、短く平易な入力なら端末内で十分、長く複雑な入力ならクラウドが要る。種類ではなく、一件ごとの難しさで切り替えたいのです。

そこで、まず端末内で試し、その結果に自信が持てないときだけクラウドへ回す、という二段構えにします。

import FoundationModels
 
// オンデバイスで試し、信頼度が低いときだけ Gemini へ回す
struct AdaptiveSummarizer {
    let onDevice: SystemLanguageModel
    let cloudFallback: GeminiClient
 
    func summarize(_ text: String) async throws -> Summary {
        // まず端末内で試す
        let local = try await onDevice.summarize(text)
 
        // 信頼度が十分高ければ、そのまま採用（クラウドを呼ばない）
        if local.confidence >= 0.7 && !needsCloud(text) {
            return Summary(text: local.text, source: .onDevice)
        }
 
        // 自信が持てない、または明らかに端末向きでない入力だけクラウドへ
        let cloud = try await cloudFallback.summarize(text)
        return Summary(text: cloud.text, source: .gemini)
    }
 
    // 入口で「明らかに端末では厳しい」入力を弾く軽い判定
    private func needsCloud(_ text: String) -> Bool {
        let longEnough = text.count > 1_200
        let manyTopics = text.components(separatedBy: "\n\n").count > 6
        return longEnough && manyTopics
    }
}
 
enum SummarySource { case onDevice, gemini }
struct Summary { let text: String; let source: SummarySource }

ここで二つの判定を組み合わせています。needsCloud は入口での粗いふるい分けで、長くて話題が多い入力を、端末内で試す前にクラウドへ回します。明らかに端末では厳しい入力に、わざわざ一度オンデバイス推論を走らせてから捨てるのは無駄だからです。confidence はその後の細かい判定で、端末内で試した結果が頼りないときにクラウドへ落とします。

この二段構えのおかげで、クラウドを呼ぶのは「本当に端末内では足りなかったリクエスト」だけに絞られます。短く平易なリクエストはネットワークに触れずに完結し、難しいリクエストだけが無償枠の外側へ出ていきます。

どれだけ無償枠で賄えたかを振り返る

フォールバックを入れたら、それが意図どおりに効いているかを後から確かめたくなります。クラウドへ回った割合が高すぎれば、端末内の信頼度の閾値が厳しすぎるのかもしれませんし、逆に低すぎて品質の苦情が来るなら、閾値が甘いのかもしれません。

そこで、要約のたびにどちらで処理したかを記録し、定期的に集計します。

// フォールバックの実績を記録し、無償枠でどこまで賄えたか振り返る
actor FallbackMeter {
    private var onDevice = 0
    private var cloud = 0
 
    func record(_ source: SummarySource) {
        switch source {
        case .onDevice: onDevice += 1
        case .gemini:   cloud += 1
        }
    }
 
    func report() -> String {
        let total = onDevice + cloud
        guard total > 0 else { return "まだ実績がありません" }
        let onDeviceRate = Double(onDevice) / Double(total) * 100
        return String(
            format: "端末内 %.1f%%（%d件） / クラウド %.1f%%（%d件）",
            onDeviceRate, onDevice, 100 - onDeviceRate, cloud
        )
    }
}

私の小さな要約機能では、この値を見ながら閾値を一度だけ調整しました。最初は confidence >= 0.85 と厳しめにしていて、クラウド側が約40%まで膨らんでいました。出力を読み比べると、端末内の 0.7 台の要約でも実用には十分なものが多く、閾値を 0.7 に下げたところ、クラウド呼び出しが体感で約50%まで減りました。品質の苦情も増えませんでした。

大事なのは、この閾値を一度決めたら固定でよいわけではない、という点です。端末内モデルは OS の更新で性能が変わりますし、扱うコンテンツの傾向も時間とともにずれます。集計を手元に残しておけば、フォールバック率が静かに上がってきたときに気づけます。これは本番運用で効いてくる注意点で、気づいた時点で閾値を調整すれば回避できます。