← すべての記事

Image Playground API：SwiftUIシート、プログラムによるImage Creator、そしてスタイル制御

2分で読めます

更新（2026年6月11日）： Appleは本稿で扱うプログラム的な経路であるImageCreatorを提供終了します。iOS 27、iPadOS 27、macOS 27、visionOS 27では動作しなくなります。本稿の残りで扱うシートベースのAPIは引き続きサポートされる経路です。タイムラインと移行については提供終了に関する記事全文をご覧ください。

Apple IntelligenceのImage Playgroundは、アプリに2つの統合経路を公開しています。SwiftUIのimagePlaygroundSheet()モディファイアは、システムが提供するユーザー向けの画像生成UIを表示します。開発者は出発点となるコンセプト（テキストまたは画像）を渡し、ユーザーがシート内で反復し、結果がアプリに返されます。ImageCreator APIは同じ生成パイプラインをプログラムで実行します。開発者はImagePlaygroundConceptオブジェクトの配列とスタイルを与え、フレームワークはUIを表示することなく生成された画像を返します1。この2つの経路は異なるユースケースを対象としています。ユーザーに反復させるべき場合はシート統合が適しており、アプリが特定の生成リクエストを持ち結果を直接表示する場合はプログラム的な統合が適しています。

本稿では、Appleのドキュメントに沿ってAPIを追っていきます。着眼点は「どの統合経路がユーザーのメンタルモデルに合致するか」です。経路を誤って選ぶと、ユーザーから制御を奪いすぎる（ユーザーが反復したかったのにプログラム的に処理してしまう）か、逆に制御を与えすぎる（ユーザーが一発の結果を期待していたのにシートを表示してしまう）UXになってしまうからです。

TL;DR

  • imagePlaygroundSheet(isPresented:concept:sourceImage:onCompletion:onCancellation:)は、システムのImage Playgroundシートを表示するSwiftUIモディファイアです。ユーザーが反復し、アプリはonCompletionを通じて選択された画像のURL（非オプショナルなURL）を受け取ります。キャンセル時にはonCancellationが発火します2。
  • ImageCreator().images(for: [ImagePlaygroundConcept], style: ImagePlaygroundStyle, limit: Int)はプログラム的な経路です（iOS 18.4以降）。このメソッドはImageCreator.CreatedImageの結果をAsyncSequenceとして返します3。
  • ImagePlaygroundConceptは、モデルが使用する入力を運びます。テキスト記述（.text("a watercolor of a cat")）、ソース画像（.image(...)）、描画（.drawing(...)）、またはリファレンスから抽出されたコンセプト（.extracted(from:title:)）などです。
  • ImagePlaygroundStyleは視覚的な美的スタイルを選びます。アプリはImageCreator().availableStylesを照会して、デバイスがサポートするケースを把握します。
  • .imagePlaygroundPersonalizationPolicy(_:)は.automatic、.enabled、.disabledを受け取ります。.imagePlaygroundGenerationStyle(_:in:)は優先するスタイルと許可するスタイルのリストを取ります。プライバシーに配慮が必要な、あるいは美的に固定したいコンテキストでこれらを使いましょう。

2つの経路：シート vs プログラム

2つの統合経路をどう選ぶかは、誰が反復を制御するかという問題です。

シート統合は、システムの完全な画像生成UIをユーザーに委ねます。ユーザーはプロンプトを入力し、バリエーションを選び、最終的な画像を決定します。アプリの役割は、出発点となるコンセプトでシートを起動し、選択された結果を受け取ることです。次のような場合に使いましょう。

  • ユーザーがアプリには完全には予測できない創造的な意図を持っている場合。
  • そのインタラクションが創造的なワークフローの一部である場合（メッセージングアプリ、メモアプリ、プロフィールのカスタマイズフローなど）。
  • ユーザーが確定する前に反復することを期待している場合。

プログラム的な統合は、アプリにモデルを直接与えます。アプリはコンセプトを供給し、システムUIを表示することなく画像を受け取ります。次のような場合に使いましょう。

  • 生成が非インタラクティブなフローの一部である場合（システムが生成するアバター、レシピカード用の確定的なアセット、一発のイラストなど）。
  • アプリが特定の美的要件を持っている場合（常にイラストスタイル、常に1枚の画像など）。
  • ユーザーに反復を見せるべきではなく、結果こそが関心事である場合。

この2つの経路は同じ基盤モデルを共有し、ユーザーレベルの同じApple Intelligence設定を尊重します。選択は純粋にUXの問題です。

SwiftUIシート

imagePlaygroundSheetはView上にいくつかのオーバーロードのバリアントを持って提供されています。標準的な5引数の形式は、出発点となるコンセプト、オプショナルなソース画像のリファレンス、そして完了ハンドラとキャンセルハンドラを取ります2。

import ImagePlayground
import SwiftUI

struct ProfileEditor: View {
    @State private var showPlayground = false
    @State private var avatarURL: URL?

    var body: some View {
        VStack {
            if let avatarURL {
                AsyncImage(url: avatarURL) { image in
                    image.resizable().scaledToFit()
                } placeholder: {
                    ProgressView()
                }
            }

            Button("Generate Avatar") {
                showPlayground = true
            }
        }
        .imagePlaygroundSheet(
            isPresented: $showPlayground,
            concept: "a friendly cartoon avatar",
            sourceImage: nil,
            onCompletion: { url in
                avatarURL = url
            },
            onCancellation: {
                // user dismissed without choosing
            }
        )
    }
}

シートのUXはシステムが制御します。ユーザーにはAppleの標準的なImage Playgroundのインターフェース（プロンプト、スタイルピッカー、バリエーションのグリッド、「Done」ボタン）が表示されます。アプリの役割は出発点となるプロンプトを提供し、結果を受け取ることです。キャンセルは完了時のnil URLではなく、専用のonCancellationクロージャを発火します。onCompletionに渡されるURLは非オプショナルです。

単一の文字列よりも豊かな出発点のコンセプトを求めるアプリのために、兄弟関係にあるオーバーロードは[ImagePlaygroundConcept]を直接受け取ります。複数のコンセプトは組み合わさり、モデルはそれぞれを制約またはシグナルとして使用します。順序は重要です。テキストのコンセプトはプロンプトを確立し、画像のコンセプトは視覚的なリファレンスを確立し、描画のコンセプトはアウトラインを確立します。

ImagePlaygroundConceptのバリアント

AppleはいくつかのImagePlaygroundConceptコンストラクタを提供しています4。

.text(_:)。 短いテキスト記述です。最も一般的な出発点のコンセプトです。

.image(_:)。 ソース画像です（通常はURLまたはUIImage/NSImage）。モデルはこれをスタイルや構図の視覚的リファレンスとして使用します。

.drawing(_:)。 描画です。通常はPencilKitやカスタムの描画サーフェスからのものです。モデルはストロークを構造的なヒントとして解釈します。

.extracted(from:title:)。 分析された画像から抽出されたコンセプトです。この2引数の形式は、ソースのURL（または画像型）と、抽出内容を記述するtitleを取ります。フレームワークはオンデバイス分析を用いて、リファレンスから生成に適したコンセプトを導き出します。

コンセプトは組み合わさります。[text, image, extracted]をシートやImageCreatorに渡すことで、モデルは複数の制約を満たせるようになります。適切なパターンは「有用な出力を生み出すのに十分なほど具体的で、モデルに余地を残すほど緩い」ことです。すなわち、1つか2つの具体的なコンセプトに、必要に応じてリファレンス画像を添えるのです。

ImageCreator：プログラム的な経路

[更新：Appleは2026年6月11日付でImageCreatorを提供終了しました。iOS 27のタイムラインと移行方法については提供終了に関する記事をご覧ください。以下のセクションは、このAPIの歴史的なドキュメントとして残しています。]

ImageCreatorは、UIなしで生成を行いたいアプリのためのプログラム的なAPIです3。

import ImagePlayground

do {
    let creator = try ImageCreator()

    // Discover the styles the device supports
    guard let style = creator.availableStyles.first else {
        // Apple Intelligence unavailable on this device
        return
    }

    let stream = creator.images(
        for: [.text("a friendly cartoon avatar")],
        style: style,
        limit: 1
    )

    for try await result in stream {
        // result is an ImageCreator.CreatedImage
        await self.save(result)
    }
} catch {
    // ImageCreator() initializer can throw on unsupported devices
    print("Generation failed: \(error)")
}

images(for:style:limit:)メソッドは、ImageCreator.CreatedImageの結果をAsyncSequenceとして返します。非同期ストリーミングのモデルにより、アプリは部分的な結果（モデルの段階的な洗練）を表示することも、最終的な画像を待つこともできます。limit:パラメータはリクエストする画像の枚数に上限を設けますが、Appleはポリシーやデバイスの状態に応じてそれより少ない枚数を返すことがあります。

プログラム的な経路はiOS 18.4以降であり、機能が有効化されたApple Intelligence対応デバイスを必要とします。可用性チェックのパターンは次の通りです。tryの中でImageCreatorを構築し、続いてavailableStylesを読み取ります。空のavailableStylesコレクション（またはスローされたイニシャライザ）は、現在のデバイスで生成が利用できないことを示します。その場合、アプリは非生成的な経路（アセットライブラリ、ユーザーがアップロードした画像など）にフォールバックします。

ImagePlaygroundStyleのバリアント

styleパラメータは視覚的な美的スタイルを制約します5。

  • .animation。 Appleのアニメーションキャラクター風スタイルです（丸みのあるフォルム、太いアウトライン、簡略化された特徴）。アバター、マスコット、親しみやすいUIイラストに有用です。
  • .illustration。 ベクター調の美的なフラットなイラストスタイルです。インフォグラフィック、レシピカード、概念的なイメージに有用です。
  • .sketch。 鉛筆スケッチ風スタイルです（後のリリースで追加）。メモアプリ、ジャーナリング、手描き風の美的表現に有用です。

生成される画像全体で一貫した美的表現を求めるアプリ（すべてのアバターを.animationスタイルに、すべてのレシピカードを.illustrationスタイルに）は、生成呼び出しの中でスタイルを固定します。一方、選択肢をユーザーに提示したいアプリは、利用可能なケースに対応したスタイルピッカーを表示します。

パーソナライゼーションとポリシーのモディファイア

2つのSwiftUIモディファイアにより、アプリは自身のコンテキストでImage Playgroundの動作を制約できます6。

.imagePlaygroundPersonalizationPolicy(_:)。 ImagePlaygroundPersonalizationPolicyの値を取ります。.automatic（システムのデフォルト）、.enabled（明示的に許可）、.disabled（連絡先や写真などの個人的なコンテンツをシステムが参照することを禁止）です。プライバシーに配慮が必要なコンテキスト（医療、金融、匿名のコミュニケーション）のアプリでは.disabledを使いましょう。

.imagePlaygroundGenerationStyle(_:in:)。 優先するスタイルと、許可するスタイルの配列を取ります。ユーザーのスタイルピッカー（表示されている場合）は許可リストに制約され、優先するスタイルがデフォルトになります。アプリの美的表現が利用可能なスタイルの制約や固定を必要とする場合に使いましょう。

どちらのモディファイアも、システムレベルのApple Intelligence設定を下限として尊重します。アプリはシステムが無効化した機能を上書きすることはできず、さらに制約を加えることしかできません。

よくある失敗

Image Playground統合のログから見られる3つのパターンです。

イニシャライザのエラーをキャッチせずにImageCreator()を呼び出すこと。 Apple Intelligence非対応のデバイスでは、creatorは初期化時にスローします。tryしてキャッチしないアプリは、ユーザーに分かりにくいエラーを見せてしまいます。修正方法は、ImageCreator()をtryでラップし、availableStylesを検査し、失敗時にフォールバックの経路を用意することです（プレースホルダーを表示する、設定でApple Intelligenceを有効にするようユーザーに促す、機能を完全に隠すなど）。

統合経路をユースケースに合わせ損ねること。 ImageCreatorを使うプロフィールアバター生成機能は、ユーザーが調整できない一発限りのアバターを生み出します。一方、シートを使う一発限りのアバター生成機能は、摩擦を増やします。経路をユーザーの期待に合わせましょう。反復したいならシートを、結果が欲しいならプログラム的な経路を選びます。

システムのポリシーの下限を無視すること。 システムのApple Intelligence設定を回避しようとするアプリ（例えばユーザーがグローバルに無効化したコンテキストで画像を生成しようとする）は、ポリシーエラーに突き当たります。修正方法は、システム設定を尊重し、Apple Intelligenceが無効化されている場合は無言の失敗ではなく意味のあるエラーを表示することです。

このパターンがApple Intelligenceアプリにとって意味すること

3つの要点です。

  1. 統合経路はユーザーのメンタルモデルで選ぶ。 創造的な反復にはシートを、非インタラクティブなフローでの一発生成にはプログラム的な経路を。誤って選んだときのコストは、現実のUXの摩擦です。

  2. スタイルとパーソナライゼーションを意図的に制約する。 一貫したアバタースタイルを求めるメッセージングアプリは、単一の許可スタイルを.imagePlaygroundGenerationStyle(_:in:)に渡します。プライバシー重視のジャーナリングアプリは.imagePlaygroundPersonalizationPolicy(.disabled)を設定します。デフォルトは寛容（.automatic）です。意図的な制約こそが、機能を意図的なものに感じさせます。

  3. 常にImageCreator()のavailableStylesをチェックし（あるいはイニシャライザのエラーをキャッチし）、フォールバックを用意する。 Apple Intelligenceは特定のハードウェア（iPhone 15 Pro以降、MシリーズのMac）に加えてユーザーのオプトインを必要とします。可用性チェックなしにImage Playgroundに依存するアプリは、古いデバイスやApple Intelligenceが無効化されたデバイスで分かりにくく失敗します。

Apple Ecosystemクラスタの全体像は次の通りです。型付きのApp Intents、MCPサーバー、ルーティングの問い、Foundation Models、ランタイムとツーリングのLLMの区別、3つのサーフェス、単一の信頼できる情報源のパターン、2つのMCPサーバー、Apple開発のためのhooks、Live Activities、watchOSランタイム、SwiftUIの内部構造、RealityKitの空間的メンタルモデル、SwiftDataのスキーマ規律、Liquid Glassのパターン、マルチプラットフォームでの出荷、プラットフォームマトリックス、Visionフレームワーク、Symbol Effects、Core MLによる推論、Writing Tools API、Swift Testing、Privacy Manifest、プラットフォームとしてのアクセシビリティ、SF Proのタイポグラフィ、visionOSの空間パターン、Speechフレームワーク、SwiftDataのマイグレーション、tvOSのフォーカスエンジン、@Observableの内部構造、SwiftUIのLayoutプロトコル、カスタムSF Symbols、AVFoundationのHDR、watchOSのワークアウトライフサイクル、iOS 26のApp Intents 2.0の追加点、私が書くことを拒むもの。ハブはApple Ecosystemシリーズにあります。AIエージェントを伴うiOSのより広いコンテキストについては、iOS Agent Developmentガイドをご覧ください。

FAQ

Apple Intelligenceが利用できない場合に対処する必要はありますか？

はい、あります。Image Playgroundは、機能が有効化されたApple Intelligence対応デバイス（iPhone 15 Pro以降、MシリーズのMac）を必要とします。非対応のデバイスでは、シートは表示されず、ImageCreator()は初期化時にスローします。チェックのパターンは次の通りです。ImageCreator()をtryでラップし、availableStylesを検査します。空のコレクションやスローされたイニシャライザは、生成が利用できないことを示します。非対応のユーザーのために、非生成的なフォールバックを用意しましょう。

シートのUIをカスタマイズできますか？

いいえ、できません。シートはシステムが制御します。アプリは出発点となるコンセプトを供給して結果を受け取りますが、その間のすべてはAppleのUIです。カスタムUIが必要な場合は、ImageCreatorのプログラム的なAPIを使い、その周りに独自の反復インターフェースを構築してください。

ユーザーがシートを閉じたとき、生成された画像はどうなりますか？

5引数のimagePlaygroundSheetオーバーロードは、onCompletionとonCancellationという別々のクロージャを提供します。ユーザーが画像を選択するとonCompletionが非オプショナルなURLとともに発火し、ユーザーが選択せずに閉じるとonCancellationが発火します。一時的な画像データはシステムによってクリーンアップされます。画像を保持したいアプリは、完了ハンドラの中で自身のストレージに保存する必要があります。

Image Playgroundは写真の権限とどう関わりますか？

シート自体は写真ライブラリへのアクセスを必要としません。ユーザーがシート内で写真ライブラリを参照する場合（コンセプトとして使う画像を探す場合）、シートが内部で権限のプロンプトを処理します。アプリはImage Playground統合のために事前に写真の権限を要求する必要はありません。

バックグラウンドで画像を生成できますか？

ImageCreatorはフォアグラウンドで実行され、フレームワークが生成のためのシステムリソースを管理します。バックグラウンドでの画像生成を求めるアプリは、アプリをフォアグラウンドに保つ必要があります（あるいはwatchOSのワークアウトライフサイクルで扱ったワークアウトセッションのような、継続的な実行が許可されるセッションタイプに保つ必要があります）。

これはFoundation ModelsのLLMとどう関係しますか？

Image Playgroundのモデルは、Foundation ModelsのオンデバイスLLM（Foundation ModelsのオンデバイスLLMで扱っています）とは別物です。両者はApple Intelligenceフレームワークの基盤を共有しますが、異なる専門特化モデルを使用します。両者を組み合わせるアプリ（LLMが生成したプロンプトを画像生成に流し込む）は、2つのAPIを順番に構成します。

References

  1. Apple Developer Documentation: Image Playground. The framework reference covering the SwiftUI sheet integration plus the programmatic ImageCreator API. ↩

  2. Apple Developer Documentation: imagePlaygroundSheet(isPresented:concept:onCompletion:). The SwiftUI view modifier that presents the system Image Playground UI. ↩↩

  3. Apple Developer Documentation: ImageCreator. The programmatic API (iOS 18.4+) with the images(for:style:limit:) method returning an async stream of generated results. ↩↩

  4. Apple Developer Documentation: ImagePlaygroundConcept. The concept variants (.text, .image, .drawing, .extracted) that compose into generation requests. ↩

  5. Apple Developer Documentation: ImagePlaygroundStyle. The available style cases (.animation, .illustration, .sketch) for visual aesthetic control. ↩

  6. Apple Developer Documentation: imagePlaygroundPersonalizationPolicy(_:) and imagePlaygroundGenerationStyle(_:). The view modifiers for constraining personalization and locking the generation style. ↩

関連記事

GenmojiとNSAdaptiveImageGlyph：iOS 18+でのインライン絵文字

Genmojiは属性付きテキスト内でNSAdaptiveImageGlyphとして提供されます。TextKit 2を使用するUITextViewのアプリでは、supportsAdaptiveImageGlyphを有効にし、シリアライズに対応…

1 分で読める

AppleのTranslationフレームワーク：無料、オンデバイス、そして見た目以上に切れ味鋭い

AppleのTranslationフレームワーク——translationPresentationとTranslationSessionによる無料のオンデバイス翻訳、そしてデモが省略するオフラインダウンロードの落とし穴まで。

1 分で読める

ループ・エンジニアリング――検証が安いところでループは勝つ

ループ・エンジニアリングを、Boris Cherny の全文書き起こしと照合する。彼が名前を挙げるループはどれも検証が安い。その制約こそが、何を自動化すべきかを決める。

4 分で読める