iOS 27のFoundation Models：ツール呼び出しの制御

iOS 26では、アプリにオンデバイスの大規模言語モデル、@Generableによる型安全な出力の取得方法、そして生成の途中でモデルがコードを呼び出せるToolプロトコルが提供されました¹。いつツールを使うかはモデルが判断し、ツール自体は開発者が書きます。できなかったのは呼び出しの挙動そのものを制御することであり、逆に必ずやらなければならなかったのは、どのアプリにも必要なものまで含めてすべてのツールを手作業で書くことでした。iOS 27はこの2つのギャップをともに埋めます。GenerationOptions.ToolCallingModeを使えば、リクエストごとにモデルとツールの関わり方を制御できます²。さらにVisionフレームワークにはOCRToolとBarcodeReaderToolという2つのすぐ使えるツールが用意され、認識処理のコードを自分で書かずにセッションへ取り付けられるようになりました³⁴。この2つが揃うことで、フレームワークが始めたエージェント的なループが完成します。何をするかはモデルが決め、それをどこまで積極的に許すかは開発者が決め、物理世界を読み取る知覚ツールはAppleが供給する、という構図です。

ここから先は、フレームワークのリファレンスに重ねるiOS 27の層についてです。LanguageModelSessionやToolプロトコル、ガイド付き生成にまだ触れたことがなければ、まずFoundation Modelsフレームワーク解説から読んで、それから戻ってきてください。

TL;DR

• GenerationOptions.ToolCallingModeはiOS 27で新たに登場した構造体で、ツール使用に関するモデルの挙動を記述し、GenerationOptionsを通じてリクエストごとに設定します²。Appleは3つのモードを文書化しています。
• フレームワークは最初のツール呼び出しの後にモードを変更でき、これによってモデルはツールの呼び出しをやめて最終的な応答を生成します。これが1回のリクエストにおけるツール動作の上限となります²。
• OCRToolは画像内のテキストを認識し、読み取った内容をすべて含む文字列を返します。有効にするには、LanguageModelSessionにOCRToolのインスタンスを設定します³。
• BarcodeReaderToolは機械可読コードをスキャンし、Barcodeの結果の配列を返します。各結果にはデコードされた内容とシンボル体系の種別が含まれます。有効にする方法は同じで、インスタンスをセッションに設定します⁴。
• どちらのVisionツールも既定の名前と説明を上書きできるため、モデルが各ツールをどう識別し、どう使うかを開発者が制御できます³⁴。
• 本稿の内容はすべてiOS 27ベータ（および対応するiPadOS、macOS、visionOSのベータ、3つのシンボルのうち2つについてはwatchOSベータ）が対象です²³⁴。

iOS 26とiOS 27で何が変わったか

iOS 26のフレームワークは、APIの表面ではツール呼び出しを二者択一として扱っていました。セッションに一連のツールを渡すと、それ以降は呼び出すかどうか、どのくらいの頻度で呼び出すかをモデルだけが判断します。単発の参照ならこれで十分です。ところが、1つのセッション内でリクエストごとに異なる挙動を求めた途端、扱いづらくなります。あるプロンプトではモデルに必ずツールを参照させたいのに、別のプロンプトでは往復を省いて文脈から答えてほしい、といった場合です。

iOS 27は、その判断を開発者の手に委ねます。ToolCallingModeはGenerationOptionsを通じて渡す値で、これはすでにデコードを制御しているのと同じオプションオブジェクトです²⁵。そしてモードはセッションではなくリクエストのプロパティです。組み込みのVisionツールは、もう一方の側を変えます。OCRパイプラインやバーコードスキャナーを書いて自前のTool準拠でラップする代わりに、Appleの実装を取り付け、労力はプロンプトに注げばよいのです。

GenerationOptions.ToolCallingMode：呼び出しの舵取り

ToolCallingModeはGenerationOptionsの下に位置する構造体で、iOS 27、iPadOS 27、Mac Catalyst 27、macOS 27、visionOS 27、watchOS 27の各ベータで利用できます²。Appleの概要は一文です。ツール使用に際してのモデルの挙動を記述するために使う値、というものです²。宣言はこれ以上ないほど簡潔です。

// iOS 27 beta
struct ToolCallingMode

Appleのドキュメントによれば、ツール呼び出しモードは3つのモードをサポートします²。それぞれの名前を示すであろう解説テキストは、執筆時点のリファレンスでは一部が省略されています。そのため識別子を推測するのではなく、フレームワークが挙動について文書化している内容を説明します。設計を実際に左右するのはそこだからです。

Appleが明確に述べている挙動はこうです。フレームワークは最初のツール呼び出しの後にモードを変更でき、それによってモデルは最終的な応答を生成できます²。この一文こそが要となる部分です。つまりリクエストは、モデルがツールを呼び出せる（あるいは呼び出さなければならない）姿勢から始められ、最初の呼び出しが返ってくると、フレームワークがモードを切り替えてモデルがそれ以上ツールに手を伸ばさず答えに踏み切る、という流れになります。実際の効果は、1回のリクエストにおけるツール動作に上限を与えることです。コンテキストウィンドウを使い果たすまでループでツールを呼び続けるモデルに振り回されることはありません。

モードは、すでにrespond(to:)に渡しているオプションオブジェクトを通じて設定します。

import FoundationModels

let session = LanguageModelSession(tools: [FindContacts()])

// A request where you want to govern tool-calling behavior explicitly.
var options = GenerationOptions()
options.toolCallingMode = .someMode   // one of the three documented modes
let response = try await session.respond(
    to: "Draft a dinner invite to three of my contacts.",
    options: options
)

.someModeの正確な綴りは、文書化された3つのケースから来ます。重要なのは仕組みであり、その仕組みとは、挙動がリクエストごとに決まりGenerationOptionsによって運ばれる、という点です。このオブジェクトは、デコード戦略やモデルが出力トークンを選ぶ方法、そして暴走しがちな冗長さに歯止めをかけたいときだけ手を出す任意の応答トークン上限を司る、iOS 26の同じ構造体です⁵。ツール呼び出しモードは、すでに使っている制御面に加わった新しい次元であって、コードに通し直す新しいオブジェクトではありません。

この制御がセッションではなくリクエストのレベルに置かれているのは、ツールの必要性が会話ではなく問いの性質だからです。チャットセッションでは、本当に連絡先の参照を要する1ターンと、すでに保持している内容からモデルが言い換えで済ませられる次のターンが混在しうるのです。2つ目のターンでツール呼び出しを強制すれば、往復が無駄になり、共有のコンテキストウィンドウには割く余地のないトークンを浪費します⁵。リクエストごとのモードなら、各ターンが自らの姿勢を宣言できます。

組み込みのVisionツール：OCRToolとBarcodeReaderTool

iOS 27の物語の後半は、Foundation Modelsのツールとして公開されたVisionフレームワークから来ます。Appleはいまや、自前のツールと同じようにLanguageModelSessionへ取り付けられる2つのツールを提供しています。ただし認識処理のコードはいっさい書く必要がありません。

セッション241でAppleは、BarcodeReaderToolとOCRToolを、視覚情報についてモデルがネイティブにはできない形で推論する能力を高める組み込みのシステムツールとして紹介しています。⁷

OCRTool

OCRToolは画像内のテキストを認識します。Appleの概要はまさにそのままで、契約については解説が正確です。このツールは画像から認識したすべてのテキストを含む文字列を返します³。有効にするには、LanguageModelSessionにOCRToolのインスタンスを設定します³。宣言はこうです。

// iOS 27 beta, Vision framework
struct OCRTool

取り付け方は、どのツールとも同じ形です。セッションにとっては、これもまた1つのToolにすぎないからです。

import FoundationModels
import Vision

// Configure the session with an OCRTool instance to enable it.
let session = LanguageModelSession(tools: [OCRTool()])

let response = try await session.respond(
    to: "Pull the total and the date off this receipt image and summarize them."
)

プロンプトが画像からのテキストを必要としているとモデルが判断すると、OCRToolを呼び出してツールが読み取ったすべての内容を文字列として受け取り、開発者が書いたツールの結果を織り込むのと同じように、その文字列を答えに織り込みます³。Visionのリクエストも処理コードも書いていません。ツールを取り付け、仕事を説明しただけです。

Appleは既定の名前と説明を上書きできるようにしており、モデルがツールをどう識別しどう使うかをカスタマイズできます³。このフックが、モデルがOCRに手を伸ばすタイミングに対して開発者が持つ唯一のレバーです。アプリがレシートを読み取るなら、ツールの説明をレシートの言葉で書けば、レシートらしいプロンプトでは呼び出すよう、画像が装飾的なだけのプロンプトでは呼び出さないよう、モデルを偏らせられます。説明はモデルが読む関数ドキュメントなので、そのつもりで書いてください。

BarcodeReaderTool

BarcodeReaderToolは画像内の機械可読コードをスキャンします⁴。OCRToolが平坦な文字列を返すのに対し、バーコードツールは構造を返します。機械可読コードを含む画像にモデルが出会うと、このツールを呼び出してそれらをデコードでき、ツールはBarcodeの結果の配列を返します。各結果にはデコードされた内容とシンボル体系の種別が含まれます⁴。宣言と取り付けはOCRToolを映したものです。

// iOS 27 beta, Vision framework
struct BarcodeReaderTool

// Configure the session with a BarcodeReaderTool instance to enable it.
let session = LanguageModelSession(tools: [BarcodeReaderTool()])

let response = try await session.respond(
    to: "Scan this label and tell me what product it is and which standard the code uses."
)

各Barcode結果に含まれるシンボル体系の種別こそ、構造化された戻り値の価値を生む細部です⁴。QRコード、食料品のEAN-13バーコード、運転免許証のPDF417は、いずれも機械可読コードですが、アプリにとって意味するものはそれぞれ異なります。ツールがデコードしたペイロードとともにシンボル体系を返してくれるため、モデル（そして下流のコード）は、内部のバイトだけでなくコードの種類に応じて分岐できます。OCRToolと同じく、既定の名前と説明を上書きして、モデルがツールをどう識別しどう使うかを舵取りできます⁴。

どちらのツールも同じベータでの提供状況です。両方ともiOS 27、iPadOS 27、Mac Catalyst 27、macOS 27、visionOS 27で、BarcodeReaderToolはさらにwatchOS 27にも記載されています³⁴。

ループを組み立てる：知覚と制御された呼び出し

この2つの機能は、それぞれ単独でも興味深いものですが、組み合わせるとさらに優れています。両者は1つのエージェント的リクエストの対極に位置するからです。Visionツールは知覚であり、画像に向けたモデルの目です。ToolCallingModeはガバナンスであり、その目にモデルがどれだけ頼るかを握る開発者の手です。

食料庫の補充機能を思い描いてみましょう。ユーザーが棚を撮影します。セッションには両方のVisionツールと、自前のツールが1つ、アプリのカタログにアクセスするLookUpProductが取り付けられています。1回のリクエストで、品目を識別して再注文リストを作成するようモデルに依頼します。モデルは見えているラベルをデコードするためにBarcodeReaderToolを呼び出し、きれいなコードのない品目についてはOCRToolで印字されたテキストを読み取り、デコードした各ペイロードをカタログのエントリへ解決するためにLookUpProductを呼び出します。3つのツール、1つのプロンプト、1つの一貫した答えです。

import FoundationModels
import Vision

let session = LanguageModelSession(tools: [
    OCRTool(),
    BarcodeReaderTool(),
    LookUpProduct(),     // your own Tool conformance over the app catalog
])

var options = GenerationOptions()
options.toolCallingMode = .someMode   // govern how the model sequences the calls
let response = try await session.respond(
    to: "Identify everything on this shelf and build a reorder list.",
    options: options
)

これこそ、フレームワークが目指して築いてきたループです。iOS 26は、ランタイムモデル、ガイド付き生成、そして自由テキストを解析せずにオンデバイスモデルがコードを呼び出せるToolプロトコルを提供しました¹。このクラスターのアーキテクチャ記事は、そのランタイムモデルと、開発者がアプリを書くためにClaude Codeで動かすツール用のLLMとの線引きをし、Foundation ModelsのTool、App Intent、MCPツールを3つの薄いアダプターを介して1つのSwiftドメイン関数で支える主張を展開しました⁶。iOS 27はその図のランタイム側に収まります。組み込みのVisionツールはAppleが書き、開発者が取り付けるドメイン関数であり、LookUpProductは開発者が書いたドメイン関数であり、モデルがそれらすべてを編成し、ToolCallingModeがその編成のスロットルです。

信頼境界は動きません。OCRToolとBarcodeReaderToolは、自前で書いたツールと同じサンドボックスとプライバシーの姿勢のもと、ユーザーの画像に対してオンデバイスでアプリプロセス内で動作します。Appleが実装を供給することで変わるのは、誰が認識処理のコードを保守するかであって、誰がその機能に責任を負うかではありません。プロンプト、セッション、利用可否のチェック、そしてユーザーの前にカメラを置くという判断は、依然として開発者のものです。

各モードとツールをいつ使うか

上記の契約から導かれるいくつかのルールです。

ツールの必要性がリクエストごとに変わるときはToolCallingModeに手を伸ばしましょう。 セッション内のすべてのターンが同じツール挙動を必要とするなら、既定で十分であり、モードはノイズにすぎません。モードが活きるのは、あるリクエストでは必ずツールを参照させ、別のリクエストでは文脈から答えさせたいとき、あるいはフレームワークの最初の呼び出し後の切り替えによって、放っておけばループしかねないリクエストに上限を与えたいときです²。制御はそこにあるので、セッションに対して一度ではなく、リクエストに対して設定してください²。

答えが画像の中に閉じ込められたテキストであるときはOCRToolに手を伸ばしましょう。 レシート、看板、手書きのメモ、テキストのスクリーンショットなどです。このツールは読み取ったすべてを1つの文字列で返すので³、レイアウトではなく言葉についてモデルに推論させたいプロンプトに合います。バウンディングボックスや行ごとの信頼度が必要なら、それはこのツールではなく、より低レベルのVisionリクエストです。

画像が機械可読コードを含み、コードの種類が重要なときはBarcodeReaderToolに手を伸ばしましょう。 商品ラベル、チケット、ID、在庫タグなどです。構造化された戻り値、すなわちデコードされた内容にシンボル体系を添えたもの⁴こそ、バーコードを汎用のテキストとして扱うよりこれを選ぶ理由です。自前のツールや後処理の中で、シンボル体系に応じて分岐しましょう。

アプリが汎用ツールに特定の仕事を与えているときは、いつでも名前と説明を上書きしましょう。 どちらのVisionツールも既定では汎用の素性を持ち、モデルは説明も手がかりにしてツールを選びます³⁴。レシートしか読み取らないアプリなら、OCRツールの説明にそう書くべきです。そうすれば、たまたま文字が写っているだけのあらゆる写真でモデルがそれを呼び出すことはなくなります。

FAQ

iOS 27のGenerationOptions.ToolCallingModeとは何ですか？

iOS 27ベータで新たに登場した構造体で、特定のリクエストに対するツール使用まわりのモデルの挙動を記述します。respond(to:)に渡すGenerationOptionsを通じて設定するので、ツール呼び出しの挙動はセッション全体ではなく各リクエストのプロパティになります。Appleは3つのモードを文書化しています²。

Appleは何種類のツール呼び出しモードを文書化していて、それぞれの名前は何ですか？

Appleのドキュメントによれば、ツール呼び出しモードは3つのモードをサポートします²。各モードを個別に名付けるリファレンスのテキストは執筆時点で一部が省略されているため、識別子を推測するのではなく、文書化された挙動を説明します。Appleが明確に述べている挙動はこうです。フレームワークは最初のツール呼び出しの後にモードを変更でき、それによってモデルは最終的な応答を生成し、これが1回のリクエストのツール動作に上限を与えます²。

Appleの組み込みOCRツールはどうやって有効にしますか？

どのツールとも同じように、LanguageModelSessionにOCRToolのインスタンスを設定してください³。するとモデルは、プロンプトが画像からのテキストを必要とするときにそれを呼び出し、ツールは認識したすべてのテキストを含む文字列を返します。OCRToolはVisionフレームワークにあり、iOS 27ベータで利用できます³。

BarcodeReaderToolは何を返しますか？

Barcodeの結果の配列を返し、各結果にはデコードされた内容とシンボル体系の種別が含まれます⁴。シンボル体系があれば、QRコードとEAN-13とPDF417を見分け、ペイロードだけでなくコードの種類に応じて分岐できます。有効にするには、LanguageModelSessionにBarcodeReaderToolのインスタンスを設定します⁴。

モデルが組み込みのVisionツールを使う判断のしかたを変えられますか？

はい。OCRToolもBarcodeReaderToolも、既定の名前と説明を上書きして、モデルがツールをどう識別しどう使うかをカスタマイズできます³⁴。説明は、モデルがツールに手を伸ばすタイミングを左右するレバーなので、アプリ独自の言葉で書けば、正しい呼び出しへとモデルを偏らせられます。

組み込みのVisionツールは画像をデバイスの外へ送りますか？

いいえ。OCRToolとBarcodeReaderToolはFoundation Modelsのツールであり、自前で書くツールと同じサンドボックスとプライバシーの姿勢のもと、オンデバイスでアプリプロセス内で動作します¹³⁴。Appleが認識処理のコードを供給することで変わるのは、誰がそれを保守するかであって、どこで動くか、誰がその機能に責任を負うかではありません。

Apple Ecosystemクラスターの全体像です。Foundation Modelsフレームワーク解説、オンデバイスLLM、ランタイムLLMとツール用LLMの区別、カスタムアダプター、型付きのApp Intents、新しいApp Intents iOS 27のバックグラウンド実行と同期、MCPツールに対するルーティングの問い、Visionフレームワーク、Core MLの推論、3つのサーフェス。ハブはApple Ecosystemシリーズにあります。AIエージェントを伴うiOSのより広い文脈については、iOSエージェント開発ガイドをご覧ください。