Foundation Modelsのユースケース：generalとcontentTaggingの使い分け

AppleのSystemLanguageModelドキュメントは、まずベースモデル、次にユースケース、そしてアダプターという順序で構成されています。SystemLanguageModel.defaultがベースモデルであり、SystemLanguageModel.UseCaseにはgeneralとcontentTaggingが記載されています。カスタムアダプターは開発者が学習させる経路で、別途扱われています。¹²³

Toolプロトコルに関する以前の投稿では、デフォルトモデルに有用な仕事をさせる方法を取り上げました。本記事で答えるのは、その次の問いです。プロンプティングとツールを組み合わせたデフォルトモデルで十分なのはいつか、そしてAppleの.contentTaggingユースケースが採用に値するのはいつか、という問いです。カスタムアダプターについては別記事で扱います。開発者が管理するライフサイクルは扱う範囲が広く、判断基準と一緒に語るには情報量が多すぎるからです。

TL;DR

• SystemLanguageModel.UseCaseはstructで、静的プロパティは.generalと.contentTaggingの2つだけです。³ それ以外のユースケースはドキュメント化されていません。
• .generalがデフォルトです。まずはこちらを使いましょう。プロンプティング、インストラクション、ガイド付き生成、ツール呼び出しはすべて.generalの上に成り立っており、特化は最後の手段です。
• .contentTaggingはAppleのコンテンツタグ付けガイドに属するものです。入力テキストからトピック、アクション、オブジェクト、感情を識別し、Appleが明示する境界に当てはまらない場合は.generalにフォールバックします。⁵
• 第3の路線（カスタムアダプター、Adapter型、エンタイトルメント、ツールキット）には運用上の複雑さが集まっています。これは別の記事で扱います。

SystemLanguageModelとは何か

AppleはSystemLanguageModelを、テキスト生成タスク向けのオンデバイス言語モデルと説明しており、defaultがベースモデルとなります。利用可否はランタイムの状態であり、デバイスの対応状況、Apple Intelligenceの設定、モデルの準備状態のすべてが、アプリがモデルを使ったUIを表示する前の判断材料となります。¹

Appleのドキュメントには対応プラットフォーム（iOS、iPadOS、Mac Catalyst、macOS、visionOSのすべて26.0以降）と、現行のモデルバージョンが2つ（OS 26.0〜26.3向けと26.4向け）記載されています。Appleは通常の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の一般ガイドによると、オンデバイスモデルは以下のタスクでテキスト生成と理解をサポートしており、これにはGenerate tags from textも含まれます。⁴

Appleの「避けるべき」リストは別にあります。基礎的な数学、コード生成、論理推論です。⁴

注目すべきは、「テキストからのタグ生成」がgeneralモデルの得意な用途の表に含まれている点です。これは後述する特化判断にとって重要なコンテクストとなります。

generalの路線は、Appleがプロンプト、インストラクション、ガイド付き生成、ツール呼び出し、生成オプションをドキュメント化している場所です。⁴

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

第2の路線：.contentTagging

SystemLanguageModel.UseCaseはstruct（enumではありません）として記述されており、静的プロパティは2つです。³

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

ドキュメント化されているケースはこれ以外にありません。記事や解説で第3のユースケースが挙げられていたら、それは作り話です。

.contentTaggingは.generalとは性質が異なります。Appleのガイドではcontent taggingモデルを「入力テキスト中のトピック、アクション、オブジェクト、感情を識別する」モデルと説明しており、タグは「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がデフォルト値を持っていることを示唆しています。

content taggingモデルは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が挙げている挙動上の注意点はこうです。「非常に短い入力クエリでは、トピックと感情のタグ付けインストラクションが最良の結果を生みます。アクションやオブジェクトのリストは具体的になりすぎ、クエリ中の単語をそのまま繰り返してしまう可能性があります」。⁵ さらにcontent taggingモデルは「インストラクションがなくても望ましい出力フォーマットを尊重する」とされており、冗長なシステムプロンプトよりもGenerableの形のほうが大きな意味を持ちます。

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

Appleは判断ルールを直接示しています。アクション、オブジェクト、感情、トピック以外のタグ、ハッシュタグ、ツール呼び出しを伴うタグフロー、そしてmaximumCountを超える制約には.generalを使う、というものです。⁵

Appleのcontent taggingガイドにある正確な4つの文は以下の通りです。⁵

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

.contentTaggingを選ぶのは、テキストタグ付けがAppleの定めた4カテゴリに収まり、出力制約がmaximumCountに収まるときだけです。.generalにも.contentTaggingにも当てはまらない場合、カスタムアダプターを使う判断はアダプターのライフサイクルに関する記事に委ねましょう。⁵

Appleが公開していないこと

Appleは.contentTaggingをコンテンツタグ付け用に適応されたモデルと記述していますが、適応のメカニズム、ベンチマークの差分、追加のUseCase静的プロパティは公開していません。generalとcontentTaggingを超える情報は、developer.apple.comでドキュメント化されるまで未確認のものとして扱いましょう。³⁵

バージョニングについてのApple自身の見解はこうです。「AppleはオンデバイスモデルのアビリティとパフォーマンスをするためにSystemLanguageModelを通常のOSアップデートで定期的に更新します」。¹ このサーフェスはバージョン管理されているものとして扱いましょう。

要点

1. ドキュメント化されているユースケースは2つ。 AppleのUseCaseページはgeneralとcontentTaggingを記載しています。第3の値があると思い込まないでください。³
2. .generalをデフォルトに。 プロンプティング＋ツール＋ガイド付き生成で、オンデバイスモデルが想定するユースケースのほとんどに対応できます。特化は最初ではなく最後の手段です。
3. .contentTaggingはAppleの想定する形に当てはまるときだけ選ぶ。 トピック、アクション、オブジェクト、感情。1〜数語の小文字タグ。maximumCountレベルの制約。それ以上はフォールバックです。
4. Appleの「generalを代わりに使う」ルールを読む。 content taggingガイドにある具体的な4つの文です。⁵ それぞれが現実の境界線です。
5. カスタムアダプターの選択は別の判断。 サーフェスエリア、ライフサイクル、記事のいずれも別物です。

Apple Ecosystemクラスター全体としては、フレームワークの基本要素を扱うオンデバイスLLMとToolプロトコル、アプリ内と開発者ツーリングのLLMsの間のエージェント的ワークフローの分割、3者すべてにまたがるルーティングの問題を扱うApp Intents vs MCPがあります。ハブはApple Ecosystem Seriesにあります。AIエージェントを伴うiOSの広いコンテクストについては、iOS Agent Developmentガイドをご覧ください。

FAQ

SystemLanguageModel.UseCaseの値はいくつありますか？

現時点でドキュメント化されている静的プロパティは2つです。.generalと.contentTaggingです。³ チュートリアルやLLM生成の回答で第3の値が引用されていたら、採用前にdeveloper.apple.comと照合してください。

.generalにプロンプトを与える代わりに.contentTaggingを使うべきなのはいつですか？

タスクが入力テキスト中のトピック、アクション、オブジェクト、感情を識別し、短い小文字のタグを返すものである場合に.contentTaggingを使ってください。Appleのガイドは、.generalが正解となる4つのシナリオを挙げています。前述の4カテゴリに当てはまらないタグ付け、ハッシュタグ生成、ツール呼び出しを経由するタグパイプライン、そしてmaximumCountより複雑なタグ付け制約です。⁵

content taggingモデルはgeneralモデルと同じように任意のインストラクションを受け付けますか？

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

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

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

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

Appleはinit(useCase:guardrails:)をドキュメント化しつつ、SystemLanguageModel(useCase: .contentTagging)を呼び出すcontent taggingのサンプルコードを公開しています。デフォルト値が設定されたguardrailsパラメーターについては、iOS 26 SDKに対してコンパイルして検証してはいません。¹⁵

参考文献