Apple Foundation Models の無償開放 — 壁紙アプリに組み込む機能を3つの基準で絞り込む

WWDC 2026 の Platforms State of the Union を追いかけていて、いちばん長く手が止まったのは新モデルの性能グラフではなく、料金に関する一文でした。初回の App Store ダウンロードが累計 200 万に満たない開発者は、Apple Foundation Models を Private Cloud Compute 上のモデルまで含めて無償で利用できる、という発表です。

私が個人開発で運用している壁紙アプリは、この枠に収まります。つまり今回の発表は、自分のアプリにとって「AI 機能の原価がほぼ消えた」ことを意味します。ただ、原価が消えた途端に何でも組み込みたくなるのが個人開発の悪い癖でもあります。そこで週末を使って、候補を書き出して仕分けすることにしました。

無償開放の中身を、運用する側の目で確認する

まず発表の要点を、機能の羅列ではなく「運用にどう効くか」の観点で整理します。

対象は初回ダウンロード累計 200 万未満の開発者で、オンデバイスのモデルだけでなく Private Cloud Compute 上の大きなモデルも無償枠に含まれます
Foundation Models が画像入力に対応しました。壁紙アプリにとってはここが本命です
同一の Swift API から、サーバーサイド統合で Claude や Gemini も呼び分けられるようになりました
フレームワークは今夏オープンソース化される予定です

注意したいのは、無償枠の「外側」がまだ詳細待ちであることです。200 万ダウンロードを超えたときの課金体系や、Private Cloud Compute 側のレート制限は、現時点の発表だけでは判断材料が足りません。私はここを「小さく検証を始めるには十分。ただし無償枠の継続を前提にした機能設計はしない」と読みました。撤退できない場所に無償枠を置かない、という線引きです。

「無料だから入れる」をやめるための3つの基準

原価ゼロの機能追加でいちばん危ないのは、追加するかどうかの判断基準まで一緒にゼロになることです。私は次の3つの質問で仕分けすることにしました。

基準1: オフラインで完結して価値が出るか。 壁紙アプリは電車の中や寝る前など、通信が不安定な場面でもよく使われます。オンデバイスで閉じる機能は体験が安定するだけでなく、サーバー障害という運用リスクからも自由になります。

基準2: 外れたときの実害が小さいか。 AI の出力は必ず一定の割合で外れます。外れた結果がレビュー欄に直撃する場所、たとえば課金導線やプッシュ通知のそばには置かないことにしました。外れても「並び順が少し変わる」程度で済む場所を選びます。

基準3: 運用の固定費を増やさないか。 個人開発では、機能を作る時間より面倒を見続ける時間のほうが高くつきます。OS バージョンごとの分岐、モデル更新のたびの挙動確認、プロンプトの手直し。この固定費が小さい機能から始めるのが現実的です。

壁紙アプリの組み込み候補を仕分けする

この基準で、思いついた候補を4つ並べてみます。

画像のスマートタグ付け — 画像入力対応がそのまま効く本命です。オンデバイスで完結し、外れてもタグが少し的外れになるだけで UI は壊れません。検索とカテゴリ分類の精度向上に直結するため、第1候補にしました。

自然言語での壁紙検索 — 「静かな夜っぽいやつ」のような曖昧な言葉で探せる検索です。魅力的ですが、タグ付けの品質が土台になるため、第1候補の上に載せる第2段と位置づけました。

通知やウィジェットのおすすめ文言生成 — 基準2で見送りです。文言の外れは目立ちますし、通知は外したときの実害がいちばん大きい場所だと考えています。

チャット型のコンシェルジュ — 基準3で見送りです。期待値管理という終わりのない固定費を抱えることになります。壁紙アプリに会話体験を求めている利用者がどれだけいるか、という根本の疑問もあります。

仕分けの結論はシンプルで、まずオンデバイスのタグ付けだけを作る、というものです。Private Cloud Compute もサーバーサイド統合も、第1段では使いません。

試作の形 — 出力の「器」を型で固定する

タグ付けを試作するうえで最初に決めたのは、モデルの出力を自由文で受けないことです。自由文をパースする実装は、外れ方に上限がありません。Foundation Models には出力を Swift の型に固定する仕組みがあるので、タグの「器」を先に型で決めておきます。

import FoundationModels
 
// 壁紙画像のタグを構造化して受け取る器
@Generable
struct WallpaperTags {
    @Guide(description: "画像の雰囲気を表す日本語タグ。3〜5個")
    var moods: [String]
 
    @Guide(description: "主要な被写体や題材。1〜3個")
    var subjects: [String]
}
 
let session = LanguageModelSession()
let tags = try await session.respond(
    to: "この壁紙の雰囲気と被写体をタグにしてください",
    generating: WallpaperTags.self
)

こう書いておくと、外れ方の上限が決まります。最悪でも「配列の中身が少し微妙」で済み、JSON のパース失敗やキー欠落でクラッシュする系統の事故は型のレベルで消えます。なお、画像入力まわりの API 形状は今回の発表で広がった部分なので、正式なドキュメントと今夏のオープンソース公開を確認しながら詰める前提でいます。

サーバーサイド統合は「次の段」に置く

同一の Swift API から Claude や Gemini をサーバーサイドで呼び分けられる統合は、発表の中でも特に野心的な部分です。ただこれは、どの処理を端末に置き、どの処理をクラウドに出すかという層の設計問題をアプリ側に持ち込みます。この境界の考え方は Managed Agents API を動かして考えた、クラウド実行と手元実行の境界線で書いた整理がそのまま使えると感じています。私は、端末で完結する第1段を出してから、必要が生まれた時点で検討する順番にしました。

下調べはエージェントに任せ、判断は手元に残す

週末の下調べでは、壁紙アプリ側のコードベースから画像パイプラインのフック地点を洗い出す作業を Antigravity のエージェントに任せました。どの画面でどの解像度の画像が確定するか、タグを保存するならどのモデル層が適切か、という地図づくりです。10年前の SKPaymentQueue を StoreKit 2 へ — 壁紙アプリ4本の課金コードを Antigravity と移し替えた記録のときと同じ進め方で、調査の足回りは任せつつ、どの機能を入れるかという判断だけは手元に残しています。原価がゼロになった今、個人開発者の差が出るのはこの判断の部分だと考えています。

次のアクションとしては、まずご自身のアプリが無償枠に該当するかを確認し、組み込み候補をいったん全部書き出してから、3つの基準で1つに絞ってみてください。「全部は入れない」と決めることが、この無償開放をいちばん安全に活かす方法だと私は考えています。お読みいただきありがとうございました。