iOS 27のFoundation Modelsにおける画像入力

iOS 26では、テキストを読み、テキストを書くオンデバイスの大規模言語モデルがアプリに与えられました。iOS 27は、その同じモデルに目を与えます。WWDC26でAppleは、オンデバイスのシステム言語モデルが「Vision機能も獲得しつつあり、これによってまったく新しいカテゴリーのアプリケーションが開かれます」と明言しました¹。そしてその機能に到達する方法は、拍子抜けするほど単純です。画像を言葉の隣に、添付としてプロンプトへ入れ、質問するだけなのです。別個のVisionパイプラインも、モデルの切り替えも、新しいセッション型も要りません。これまで文字列を運んでいたプロンプトが、今や画像も運び、モデルは両方について答えます。

なぜこの小さな表面積こそが見出しになるのか。画像入力はFoundation Modelsに後付けされたサイドカー的なAPIではありません。Appleはこれを「既存のプロンプトビルダーの自然な拡張」と表現しています¹。つまり、iOS 26で学んだあらゆる概念（セッション、ガイド付き生成、Toolプロトコル）が、プロンプトがマルチモーダルになった瞬間も、変わることなく機能し続けるということです⁴。まだLanguageModelSessionに出会っていない方は、Foundation Modelsフレームワーク解説から始めて、また戻ってきてください。

TL;DR

• iOS 27のオンデバイスモデルは画像入力を受け付けます。画像の添付をテキストとともにプロンプトへ挿入すると、モデルが画像に関する質問に答えます¹²。
• 画像の添付はさまざまな型から作成できます。UIImage、NSImage、CGImage、Core Imageの各型、CoreVideoのピクセルバッファ、そしてファイルURLです¹。
• モデルはあらゆるサイズとアスペクト比の画像をサポートするため、特定の形にクロップしたりパディングしたりする必要はありません。ただし、画像が大きいほど多くのトークンを消費し、レイテンシも増えます¹。
• Foundation ModelsはLLMに画像に対する幅広い汎用性を与え、Visionフレームワークは固定された高速かつ微調整済みの分析を提供します。Appleの指針は、どちらかを選ぶのではなく、ツール呼び出しを通じて両者を組み合わせることです²。
• Private Cloud Computeのサーバーモデルも画像入力をサポートし、32Kのコンテキストウィンドウ（オンデバイスの4Kに対して）を備えています。そのため、テキストに加えて複数の画像を運ぶマルチモーダルなプロンプトにも余裕があります³。

何が変わったか：プロンプトに画像が加わった

セッション241でのAppleの説明は的確です。オンデバイスモデルは「より知的になり、論理とツール呼び出しが向上しました」。そしてその知性の上に、今やVisionが加わります¹。デモでは折り紙の写真についてモデルに尋ねます。「画像の添付をプロンプトへテキストとともに挿入するだけです。これで、モデルは画像に関する質問に答えられます」¹。順序が重要です。テキストと画像は同じプロンプトの中に存在し、モデルはプロンプト全体を読み、答えは両方を踏まえて推論されます。

ソースの型の集合は十分に広く、自分で何かを変換する必要はほとんどありません。Appleは6つを挙げています。画像の添付は「UIImage、NSImage、CGImage、Core Imageの各型、CoreVideoのピクセルバッファ、そしてファイルURLを含むさまざまな型から作成できます」¹。PhotosPickerから直接得たUIImage、すでにレンダリング済みのCGImage、カメラからCVPixelBufferとして取り出したフレーム、ディスク上のファイルをURLで指定したもの、いずれも有効な入力になります。トランスクリプトは入力の型を挙げていますが、添付のイニシャライザの正確なシグネチャまでは示していません。ですから型のリストを契約とみなし、iOS 27のSDKに移行したら、呼び出し箇所はXcodeの補完に任せましょう。

戦わずに済む制約が一つあります。形です。「モデルはあらゆるサイズとアスペクト比の画像をサポートするため、特定の形にクロップしたりパディングしたりする必要はありません」¹。縦長のレシート、横長のパノラマ、正方形のサムネイル、いずれもそのまま受け入れられます。コストは、トークン予算を持つどんなモデルでも予想されるとおりのものです。「任意の画像サイズが許可されていますが、画像が大きいほど多くのトークンを消費し、レイテンシも増える点に留意してください」¹。画像は無料のコンテキストではありません。テキストと同じ予算から支出するのです。これはマルチモーダルが課す最初の設計判断であり、コンテキストサイズ（後述）が要となる理由でもあります。

画像入力は既存のプロンプトビルダーに乗るため、iOS 26の仕組みはそのまま生き続けます。ガイド付き生成は依然として出力を@Generable型へと整形します。Toolプロトコルは依然としてモデルにコードを呼び出させます。ストリーミングは依然としてストリーミングします。モデルは感覚を一つ得たのであって、新しいプログラミングモデルを得たわけではありません。

画像理解との連携：Foundation ModelsとVisionは競合しない

セッション237「画像理解の新機能」は、画像を分析する二つの方法の間にAppleが線を引く場所であり、その区別は、何を作るかを決めるうえでどちらの講演においても最も役立つものです。冒頭が物語っています。発表者の議題が見当たらなくなり、彼女は付箋を撮影し、「大規模言語モデルに議題を生成してもらう」よう頼みます。「これはFoundation Modelsフレームワークで非常に簡単に行えます。ありがたいことに、今年Foundation Modelsは画像入力をサポートしています」²。これがマルチモーダルの記述的な側面の売り文句のすべてです。画像にキャプションを付ける、部屋の写真からインテリアの改善案を提案する、冷蔵庫の写真からレシピを生成する。LLMが輝く場所についての発表者の結論はこうです。「モデルは記述的なタスクをうまくこなす傾向があります」²。

続いて正直な比較が来ます。「Foundation Modelsフレームワークは大規模言語モデルを活用し、これはほとんど何でも頼めば応えてくれます。それに対して、Visionのような従来の画像処理フレームワークは、固定のコンピュータビジョンAPI群を使います。Vision APIは特定のタスクに微調整されており、それを実に巧みにこなします。そしてVisionは高速です。多くの場合、動画のフレームをリアルタイムで分析できるほど高速です」²。これをルーティングのルールとして読みましょう。静止画についての制約のない質問で、言葉が返ってきてほしいなら？Foundation Modelsです。動画のフレームレートでの特定の明確に定義されたタスク（顔検出、姿勢、サリエンシー、セグメンテーション）なら？Visionです。LLMは考える汎用家、Vision APIは走る専門家なのです。

Appleの結論は、選ぶ必要はないということです。「画像を分析するのに、VisionとFoundation Modelsのどちらかを必ず選ばなければならないわけではありません。ツール呼び出しを使って、Visionの専門性をFoundation Modelの汎用性とともに活用する方法があります」²。iOS 27のツール呼び出しは、画像の引数をサポートするようになりました。モデルが自分では何かを識別できないとき（講演では植物の識別を例に使っています）、モデルはツールを呼び出し、「画像全体を引数として渡すのではなく、画像への参照を渡します」²。その参照、すなわちImageReferenceは「現在のチャットセッションにある既存の画像への参照である必要があります」²。ツールはこれをセッションの履歴を通じて添付へと解決し、分析の準備が整います。制御ループと組み込みのOCRToolおよびBarcodeReaderToolは、姉妹編であるiOS 27のツール呼び出し制御の主題です。ここでの要点はもっと限定的です。画像入力と画像引数ツールは、同じマルチモーダルスタックの二つの層であり、互いに組み合わさるのです。

Private Cloud Compute上のマルチモーダル：同じプロンプト、より広い部屋

セッション319は、マルチモーダルの物語の両半分を一度に確認することから始まります。オンデバイスモデルは「いまや画像入力をサポートしており、指示への追従性が向上し、カスタムツールの呼び出しも改善されました」³。そしてより重い用途には、Private Cloud Compute上の新しいサーバーモデルがあります。マルチモーダルとPCCが同じ会話に属する理由はコンテキストサイズです。Appleは数値を率直に述べています。「オンデバイスモデルは4kを提供し、PCCでは32Kが得られます」³。画像はその予算からトークンを支出します¹。ですから、テキストに加えて複数の画像を運ぶプロンプトは、まさに4Kを圧迫し、32Kには快適に収まる種類のペイロードなのです。

要約デモがその収まり具合を具体的に示します。「ここにPCCモデルを使って記事を要約するアプリがあります。markdownファイルを選択でき、私たちはテキストと画像を取り込んでLanguageModelSessionに渡し、要約を生成します。これはPCCが提供する大きなコンテキストサイズと相性抜群です」³。テキストと画像、一つのセッション、一つのプロンプト。オンデバイスからサーバーへの移行コストは1行です。Appleは「たった1行のコードを変えるだけで、PCC上の新しいサーバーモデルに切り替えられます」と示しています³。なぜなら「Foundation Modelsフレームワークは、どのモデルと対話しているかに関わらず、統一されたSwift APIを提供する」からです³。Generableによるガイド付き生成とツール呼び出しは「オンデバイスモデルと同じように、PCCモデルでもまったく同じに機能します」³。

PCCは推論を加えます。オンデバイスにはないものです。そして推論にはマルチモーダルに関わるコストがあります。「推論はモデルが生成する追加のテキストです。ですからトークンを使います。これはコンテキストサイズの上限に算入されます」³。深い推論と、一つのプロンプト内の数枚のフル解像度画像を組み合わせると、32Kの予算を両端から支出することになります。より深い詳細（三つの推論レベル、quotaUsageとisLimitReachedによる日次上限の処理、開発者サイトで申請するエンタイトルメント）はPrivate Cloud Compute徹底解説に属します。マルチモーダルの要点は、同じ画像を含むプロンプトが両方のモデルで動くこと、そしてプロンプトがデバイスの容量を超えたときのためにサーバーモデルが存在することです。

画像入力を採用する

上述の契約から導かれる短いチェックリストです。

オンデバイスで始め、計測し、それから判断する。 Apple自身の助言は、モデルを「雰囲気ではなくデータに基づいて」選ぶことであり³、「特定のタスクで、特に今年更新されたモデルでは、オンデバイスモデルの性能の高さに驚くかもしれません」と注意を促しています³。キャプションや「これは何の物体か」という問い合わせには、PCCがまったく要らないかもしれません。プロンプトが複数の画像を運ぶとき、あるいは4Kのオンデバイスウィンドウを超える長いテキストを運ぶときに、サーバーモデルへ手を伸ばしましょう³。

自分のパイプラインに最も安価なソース型を選ぶ。 モデルにはUIImage、NSImage、CGImage、Core Imageの型、CVPixelBuffer、またはファイルURLを渡せます¹。フレームがすでにカメラからのピクセルバッファとして、あるいはディスク上のファイルとして存在するなら、UIImageを経由して往復させるのではなく、直接渡しましょう。

画像解像度を品質のダイヤルではなく予算のつまみとして扱う。 あらゆるサイズとアスペクト比が許されるので¹、形のための過度なクロップは避けましょう。ただし、画像が大きいほどトークンとレイテンシのコストがかさむため¹、タスク（この標識を読む、これは何の部屋か）がすべてのピクセルを必要としないなら、48メガピクセルの写真はプロンプトに入る前に縮小しましょう。

反射ではなくタスクで振り分ける。 記述的で、制約のない、言葉が出力される仕事はFoundation Modelsへ。固定された、高速な、リアルタイムのコンピュータビジョンの仕事はVisionへ。両方が必要なら、Foundation Modelsのツールの内側からVisionを呼び出しましょう²。二つのフレームワークは補完的な層であり、画像引数ツールは両者を結ぶ継ぎ目です。

可用性チェックを維持する。 画像入力は同じモデルに乗り、そのモデルは「Apple Intelligence対応デバイスでのみ利用可能」です³。可用性APIを確認し、Apple Intelligenceがない場合は優雅にデグレードしましょう³。

FAQ

iOS 27でFoundation Modelsのモデルに画像を送るには？

既存のプロンプトビルダーを使って、画像の添付をテキストとともにプロンプトへ挿入し、モデルに応答を求めます。AppleはこのAPIを「既存のプロンプトビルダーの自然な拡張」と表現しています。セッションを作成し、「画像の添付をプロンプトへテキストとともに挿入するだけ」で、「モデルは画像に関する質問に答えられます」¹。別個のVisionパイプラインも、新しいセッション型も関与しません。

Foundation Modelsにはどんな画像の型を渡せますか？

画像の添付はUIImage、NSImage、CGImage、Core Imageの各型、CoreVideoのピクセルバッファ、そしてファイルURLから作成できます¹。トランスクリプトはこれらのソース型を列挙していますが、すべてのイニシャライザのシグネチャを綴ってはいません。ですから、正確な呼び出し箇所はiOS 27のSDKに供給させましょう。

送る前に画像をリサイズしたりクロップしたりする必要がありますか？

いいえ。「モデルはあらゆるサイズとアスペクト比の画像をサポートするため、特定の形にクロップしたりパディングしたりする必要はありません」¹。トレードオフは合法性ではなくコストです。「画像が大きいほど多くのトークンを消費し、レイテンシも増えます」¹。ですから、タスクがフル解像度を必要としないなら、非常に大きな写真を縮小するのは予算上の判断です。

画像に対してVisionをFoundation Modelsの代わりに使うべきなのはいつですか？

固定された、明確に定義された、速度が重要なタスクにはVisionを使いましょう。AppleはVisionが「固定のコンピュータビジョンAPI群を使い」、「特定のタスクに微調整されており」、「多くの場合、動画のフレームをリアルタイムで分析できるほど高速」であるのに対し、Foundation Modelsは「ほとんど何でも頼めば応えてくれ」、記述的なタスクに秀でていると述べています²。両方が欲しいときは、ツール呼び出しを通じてFoundation ModelsのセッションからVisionに支えられたツールを呼び出しましょう²。

画像入力はPrivate Cloud Computeのサーバーモデルでも動きますか？

はい。Appleはオンデバイスモデルが「いまや画像入力をサポートしている」と確認しており³、PCCのデモはドキュメントの「テキストと画像」を要約のためにLanguageModelSessionへ渡します³。同じ統一されたSwift APIが両方のモデルで動くため、同じ画像を含むプロンプトが、1行の変更でオンデバイスでもサーバーでも動きます。PCCの32Kコンテキスト（オンデバイスの4Kに対して）は、複数画像のプロンプトにより多くの余地を与えます³。

Apple Ecosystemクラスターの全体：Foundation Modelsフレームワーク解説、オンデバイスLLM、iOS 27のツール呼び出し制御、そしてPrivate Cloud Compute徹底解説。ハブはApple Ecosystemシリーズです。AIエージェントを伴うiOSのより広い文脈については、iOSエージェント開発ガイドをご覧ください。