Foundation Modelsのユースケース：特化すべきとき、ただプロンプトを書くだけでよいとき

Foundation Modelsのオンデバイスモデルは、単一のものではありません。Appleは、汎用プロンプティング向けのデフォルトのSystemLanguageModelと、コンテンツタギング向けのApple管理下の特化版を1つ提供しています。¹ このフレームワークでは、開発者が独自のアダプターをトレーニングしてロードすることもできます。² 3本のレール、1つの判断ツリー、そして正確に2つのUseCase値を名指しで挙げているドキュメントページ、というわけです。

Toolプロトコルに関する以前の記事では、デフォルトモデルに有用な仕事をさせる方法を扱いました。本記事が答える問いは次のものです。プロンプティングとツールを備えたデフォルトモデルで十分なのはどのような場合で、Appleの.contentTaggingユースケースが選ばれるのはどのような場合なのか。カスタムアダプターのパスは別の記事に譲ります。開発者管理のライフサイクルは表面積が大きすぎて、判断ルーブリックと同じ記事で扱うわけにはいきません。

TL;DR

• SystemLanguageModel.UseCaseは、.generalと.contentTaggingという2つのstaticプロパティを持つ構造体です。³ 他のユースケースはドキュメント化されていません。
• .generalがデフォルトです。まずはこれに手を伸ばしてください。プロンプティング、instructions、ガイド付き生成、tool callingはすべて.generalの上に乗っています。特化は最後に引くレバーです。
• .contentTaggingは1つの仕事のために専用設計されています。入力テキストの中からトピック、アクション、オブジェクト、感情を識別し、1語から数語の小文字のタグを返すというものです。⁴ Apple自身のガイドに、代わりに.generalを使うべき場面が書かれています。
• 3本目のレール（カスタムアダプター、Adapter型、エンタイトルメント、ツールキット）は、運用上の複雑さが集中するところです。これは別の記事で扱います。

SystemLanguageModelとは何か

SystemLanguageModelは、FoundationModelsフレームワーク内のfinal classであり、iOS 26.0以降、iPadOS 26.0以降、Mac Catalyst 26.0以降、macOS 26.0以降、visionOS 26.0以降で利用できます。¹ Appleはこれを「テキスト生成タスクに対応できるオンデバイスの大規模言語モデル」と説明しています。

使い方を方向づける事実が2つあります。1つ目は、SystemLanguageModel.defaultがモデルのベース版を返すことです。¹ 特化されていないあらゆる用途のエントリポイントとなります。2つ目は、AppleがOSアップデートでモデルを更新する点です。執筆時点では、Appleのドキュメントにはモデルのバージョンが2つ列挙されています。1つはiOS、iPadOS、macOS、visionOSの26.0〜26.3向け、もう1つは26.4向けです。¹ アプリは特定のバージョンをピン留めしません。フレームワークが返すのは、その時点でOSが実行しているモデルです。

可用性はランタイムでチェックします。SystemLanguageModel.availabilityはAvailability列挙型であり、Appleのサンプルコードに記載されているケースは次のとおりです。¹

struct GenerativeView: View {
    private var model = SystemLanguageModel.default

    var body: some View {
        switch model.availability {
        case .available:
            // Show your intelligence UI.
        case .unavailable(.deviceNotEligible):
            // Show an alternative UI.
        case .unavailable(.appleIntelligenceNotEnabled):
            // Ask the person to turn on Apple Intelligence.
        case .unavailable(.modelNotReady):
            // The model isn't ready because it's downloading or because
            // of other system reasons.
        case .unavailable(let other):
            // The model is unavailable for an unknown reason.
        }
    }
}

isAvailableはシステムが完全に準備できているときのみtrueを返す便利なゲッターです。¹ 呼び出す前に必ずチェックしてください。

第1のレール：generalモデルにプロンプトを送る

Appleはデフォルトモデルを、幅広いタスクに対する適切なツールとして位置づけています。フレームワークの汎用ガイドは、Appleがオンデバイスモデルでうまく扱えるとしている能力を列挙しています。⁴

Appleはまた、オンデバイスモデルが向いていないことについても明示しています。⁴

「テキストからのタグ生成」が、generalモデルの得意分野の表に含まれている点に注目してください。これは、後述する特化の判断にとって重要な文脈となります。

デフォルトのレールでは、ツールキット一式が利用できます。instructions、prompts、Generableによるガイド付き生成、Toolプロトコルによるtool calling、temperatureなどの生成オプションです。Foundation Modelsを採用するアプリの大半は、このレールで完結し、ユースケース指定子に触れることはありません。

コンテキストウィンドウは、システムモデルで4,096トークンです。⁴ Appleは、英語、スペイン語、ドイツ語のような言語では1トークンが3〜4文字に対応し、日本語、中国語、韓国語のような言語では1文字あたり1トークンになると述べています。instructions、prompts、出力のすべてが上限にカウントされます。セッションが上限を超えると、フレームワークはLanguageModelSession.GenerationError.exceededContextWindowSize(_:)をスローします。⁴

第2のレール：.contentTagging

SystemLanguageModel.UseCaseは、列挙型ではなくstructとしてドキュメント化されており、staticプロパティは2つです。³

static let general: SystemLanguageModel.UseCase
static let contentTagging: SystemLanguageModel.UseCase

ドキュメントに記載されているケースは他にありません。第3のユースケースを名指しで紹介している記事があれば、それは創作です。

.contentTaggingは.generalとは形が違います。Appleのガイドは、contentTaggingモデルを「入力テキスト中のトピック、アクション、オブジェクト、感情を識別する」モデルと説明し、出力するタグは「1語から数語の小文字」だとしています。⁵ このモデルは、会話的に応答するのではなく、入力を評価するために作られています。「これは人からの問い合わせに応答する典型的な言語モデルではありません。代わりに、与えられた入力を評価してグループ化します」。⁵

.contentTaggingでモデルをロードするには次のようにします。

let model = SystemLanguageModel(useCase: .contentTagging)
let session = LanguageModelSession(
    model: model,
    instructions: """
        Provide the two tags that are most significant in the context of topics.
        """
)

ドキュメント化されている便利なイニシャライザはinit(useCase:guardrails:)です。¹ Appleのサンプルコードはguardrails引数なしで呼び出しており、これは呼び出し側でguardrailsにデフォルト値が設定されていることを示唆しています。

contentTaggingモデルはGenerableと統合されているため、欲しいタグの形をSwiftの型で定義できます。

@Generable
struct ContentTaggingResult {
    @Guide(
        description: "Most important actions in the input text.",
        .maximumCount(2)
    )
    let actions: [String]

    @Guide(
        description: "Most important emotions in the input text.",
        .maximumCount(3)
    )
    let emotions: [String]

    @Guide(
        description: "Most important objects in the input text.",
        .maximumCount(5)
    )
    let objects: [String]

    @Guide(
        description: "Most important topics in the input text.",
        .maximumCount(2)
    )
    let topics: [String]
}

let response = try await session.respond(
    to: prompt,
    generating: ContentTaggingResult.self
)

Appleのガイドには有用な挙動上の注意が含まれています。「非常に短い入力クエリでは、トピックと感情のタギング指示が最も良い結果を与えます。アクションやオブジェクトのリストはあまりにも限定的になり、クエリ内の単語を繰り返す可能性があります」。⁵ contentTaggingモデルは「instructionsがなくても、希望する出力フォーマットを尊重します」とも述べられており、冗長なシステムプロンプトよりもGenerableの形のほうが重みを持つことがわかります。

判断ツリー（Apple自身の言葉で）

ユースケースAPIの興味深いところは、Appleのドキュメントがいつ特化すべきでないかを明示している点です。contentTaggingガイドより。⁵

1. 「アクション、オブジェクト、感情、トピック以外のコンテンツをタグ付けする場合は、代わりにgeneralを使用してください」
2. 「ソーシャルメディア投稿のハッシュタグのようなコンテンツの生成にはgeneralモデルを使用してください」
3. 「tool calling APIを採用していて、タグを生成したい場合は、generalを使用し、Toolの出力をcontent taggingモデルに渡してください」
4. 「タグ付けに対して、taggingモデルのmaximum countサポートよりも複雑な制約セットがある場合は、代わりにgeneralを使用してください」

この4つを合わせて読んでください。contentTaggingモデルのスコープは狭く絞られています。トピック、アクション、オブジェクト、感情です。それ以外のすべて（ハッシュタグ生成、tool callを含むタグパイプライン、maximumCountより豊かな制約を伴うタグ出力）はgeneralモデルの担当となります。

タギングを使いたいと考えるアプリのための実用的な判断ルーブリックは次のとおりです。

まずは.generalをデフォルトにする。 Appleの表が説明する「テキストからのタグ生成」を含む幅広い生成タスクをこなせます。ほとんどのアプリはここで止まります。

.contentTaggingに手を伸ばすのは、 入力がテキスト形であり、出力がAppleの4カテゴリ（トピック／アクション／オブジェクト／感情）にきれいに収まる、1〜数語のタグの小さな集合であり、制約がmaximumCountに収まる場合のみです。Appleが挙げる例がパターンです。投稿ごとのタグでトピックダッシュボードを駆動したいソーシャルアプリ、自動ラベリングが欲しいメールクライアント、集約的なトレンドシグナルが欲しいコンテンツストアといったところです。

カスタムアダプターを検討するのは、 どちらのレールも合わず、特定のシステムモデルバージョンに紐づくアダプターのトレーニングと配信の運用コストを吸収できるだけの高い価値がユースケースにある場合のみです。カスタムアダプターのパスは別途ドキュメント化されています。ライフサイクルの複雑さ（ツールキットのバージョン、再トレーニングサイクル、配布）は、独自に扱うに値します。

Appleが公表していないこと

憶測されているけれども、ドキュメント化された範囲には含まれていないことがいくつかあります。

• Appleが.contentTagging向けにモデルを特化させるために用いている仕組み。AppleのcontentTaggingガイドは、フレームワークが「コンテンツタギングに特化された、適応されたオンデバイスのシステム言語モデル」を提供すると説明しています。⁵ Appleは特化の仕組みを公表しておらず、この文中の「適応された」という動詞を、開発者管理のSystemLanguageModel.Adapter型と混同してはいけません。後者は別のレールです。
• 他のユースケース値。現在のドキュメント時点で構造体には2つのstaticプロパティしかありません。3つ目のケースが登場するなら、将来のOSアップデートで提供される必要があります。
• .generalと.contentTaggingが常に共存し続けるという保証。Appleは「Apple will periodically update SystemLanguageModel in routine OS updates to improve the on-device model’s abilities and performance（Appleは定期的なOSアップデートでSystemLanguageModelを更新し、オンデバイスモデルの能力とパフォーマンスを改善します）」と述べています。¹ この表面はバージョン管理されていると考えてください。
• タギングのベンチマークでの.contentTagging対.generalの具体的な品質数値。Appleはこの選択を品質ランキングではなく、用途への適合として位置づけています。

ある記事（本記事を含めて）が、developer.apple.comに記載のないアダプターの仕組みについて定量的な主張をしている場合、その主張はデフォルトで誤りだとみなしてください。

2本のレールが実際に提供してくれるもの

第2のレールは「モデルが良くなる」ことではありません。「モデルが1つの仕事のために作られていて、それを選ぶべきタイミングをAppleがドキュメント化している」ことです。これは経済性を変えます。

1. タギングタスクのプロンプトエンジニアリングの表面積が小さくなる。 contentTaggingモデルは「instructionsがなくても、希望する出力フォーマットを尊重します」。⁵ generalモデルが必要とする数段落のプロンプトの代わりに、@GenerableとmaximumCountに頼ることができます。
2. 意味的な形が制約される。 モデルは入力された語の間の類似性を見つけ出し、意味的に一貫したタグを生成します（Appleの例：「hi」「hello」「yo」に対するトピックタグとして「greet」が出てきます）。⁵ これは、ユーザー生成コンテンツに対する集約的な分析に必要なものそのものです。
3. ドキュメント化された判断ルーブリック。 Appleは自社の特化が合うときと、フォールバックすべきときを示しています。このルーブリックがユースケースAPIの最も価値ある部分です。アプリ開発者がそうでなければ第一原理から議論することになる問いに対する、意見の入った答えだからです。

コストも明確です。.contentTaggingは1つのタスク形に縛られます。その形から外れるものはすべて.generalに戻り、プロンプトとGenerableの設計次第で決まります。

要点

1. 今日は2本、将来はもっと増えるかもしれない。 .generalと.contentTaggingは、Appleがドキュメント化している唯一のUseCaseのstaticプロパティです。他のものを前提とするコードを書かないでください。
2. .generalをデフォルトにする。 プロンプティング＋ツール＋ガイド付き生成は、オンデバイスモデルが想定している大半のユースケースをカバーします。特化は最後のレバーであって、最初のものではありません。
3. Appleがドキュメント化した形に合うときだけ.contentTaggingを選ぶ。 トピック、アクション、オブジェクト、感情。1〜数語の小文字タグ。maximumCountレベルの制約。それ以上は、フォールバックしてください。
4. Appleの「代わりにgeneralを使え」ルールを読む。 contentTaggingガイドにある4つの具体的な文です。⁵ それぞれが現実の境界線になっています。
5. カスタムアダプターのパスは別の判断。 表面積も、ライフサイクルも、記事も別になります。

Apple Ecosystemシリーズの全体像はこちらです。フレームワークのプリミティブを扱うオンデバイスLLMとToolプロトコル、アプリ内と開発者ツールのLLMの間にあるエージェント型ワークフローの分割、そして3つすべてにまたがるルーティングの問いを扱うApp Intents対MCP。ハブはApple Ecosystem Seriesにあります。より広いiOSとAIエージェントの文脈については、iOS Agent Development guideを参照してください。

FAQ

SystemLanguageModel.UseCaseの値はいくつあるのですか？

現在ドキュメント化されているstaticプロパティは2つです。.generalと.contentTaggingです。³ チュートリアルやLLM生成の回答で3つ目の値が参照されているのを見かけたら、採用する前にdeveloper.apple.comで検証してください。

.generalにプロンプトを書くだけではなく、.contentTaggingを使うべきなのはいつですか？

タスクが入力テキスト中のトピック、アクション、オブジェクト、感情を識別し、短い小文字のタグを返すものであるとき、.contentTaggingを使ってください。Appleのガイドには代わりに.generalが正解となる4つのシナリオが挙げられています。4カテゴリに合わないタギング、ハッシュタグ生成、tool call経由のタグパイプライン、そしてmaximumCountより豊かなタギング制約です。⁵

contentTaggingモデルは、generalモデルのように任意のinstructionsを受け付けるのですか？

instructionsは受け付けますが、モデルの設計はユーザー風のクエリに応答するのではなく、入力を評価することです。Appleのガイドは、contentTaggingモデルが「instructionsがなくても、希望する出力フォーマットを尊重する」と述べています。したがって、長いプロンプトではなく、@Guideアノテーション付きの@Generableの形が制約を担います。⁵

オンデバイスモデルのコンテキストウィンドウはどのくらいですか？

システムモデルでは4,096トークンです。⁴ トークンと文字の比率は、英語／スペイン語／ドイツ語ではおおよそ1トークンあたり3〜4文字、日本語／中国語／韓国語では1文字あたり1トークンです。セッションが上限を超えると、フレームワークはLanguageModelSession.GenerationError.exceededContextWindowSize(_:)をスローします。

なぜAppleのサンプルコードは、SystemLanguageModel(useCase:)をguardrails:なしで呼び出しているのですか？

ドキュメント化された便利なイニシャライザはinit(useCase:guardrails:)です。¹ AppleのcontentTaggingガイドはguardrails引数なしで呼び出しており、これは呼び出し側でguardrailsにデフォルト値が設定されていることを示唆しています。2引数の形がドキュメント化された表面で、1引数の形はAppleが公開しているサンプルコードに登場する形です。

参考文献