Foundation Modelsエージェントワークフロー：アプリ内 vs ツールLLM

iOS 26のSwiftアプリには、まったく異なるレイヤーで関わる2つのLLMがあります。1つはユーザーがアプリのLanguageModelSessionを介して動かすオンデバイスモデル。もう1つは、開発者がそのアプリを最初に書くためにClaude CodeやCursor、Codex CLIを通じて動かしたエージェントです。この2つのLLMを混同することは、エージェント型Apple開発で繰り返し起きるアーキテクチャ上の誤りです。これらは同じ問題ではなく、セキュリティモデルも、デプロイの物語も共有していません。一方で機能するパターンは、もう一方では積極的に失敗します。

ランタイムLLMはユーザーに出荷される機能です。ツールLLMは開発者が手にするスタイラスです。ランタイムモデルは、ユーザーのプライバシー期待、システムの可用性チェック、App Storeレビューの背後に存在します。ツールモデルは、開発者のAPIキー、IDEのファイルシステム権限、開発者が責任を負うコードレビューの背後に存在します。この2つのスタックが交差することは稀ですが、交差する場合（開発者が開発中にアプリのドメインを操作するために使うMCPサーバーで、ランタイムアプリがエンドユーザー自動化のために公開する可能性もあるもの）、信頼境界が動き、アーキテクチャはそれを認識しなければなりません。

本記事では、その区別と、それに続くルーティングの問い、つまりどのLLMがどの能力を担うべきか、そしてそれぞれがユーザーに何を負うのかを名指しします。

TL;DR

• ランタイムLLMはFoundation Models（SystemLanguageModel.defaultとToolプロトコル）です。推論はローカルで行われ、モデルはOSと共に出荷され、アプリはユーザーの代わりに呼び出しを実行します。¹
• ツールLLMは開発者が選んだもの、つまりClaude Code内のClaude、Cursor内のGPT、Swift向けのCodex CLIなどです。推論はリモート（Anthropicのインフラまたは設定されたClaudeプロバイダー、OpenAIなど）で行われ、モデルはホストが配置した場所にあり、開発者がエージェントを駆動します。
• 2つのLLMは、セキュリティ、デプロイ、レイテンシ予算、説明責任を共有しません。一方のレイヤーで意味をなす能力は、もう一方のレイヤーでは多くの場合、誤った形をとります。
• 開発者がClaude Codeセッション中に使う同じMCPサーバーが、自動的にエンドユーザーのエージェント自動化に適したサーフェスになるわけではありません。信頼境界が変わり、開発者が制御していたツールは、ユーザー（またはシステム）が制御するツールへと変わります。

2つのスタック、同じ単語「LLM」

衝突はこのような会話で起こります。誰かが「アプリにLLMを追加すべきだ」と言ったとします。それがユーザーが呼び出す機能（瞑想の要約を書いて、この下書きを磨いて、この写真を分類して）を指すのか、開発者が自身の反復ループに組み込むツール（Claude Codeにマイグレーションを書かせる、Cursorにビューをリファクタさせる）を指すのかは、その文からは明確ではありません。どちらもLLMの追加です。しかし、同じエンジニアリング上の決定ではありません。

Foundation Modelsは1つのスタックです。モデルはSystemLanguageModel.defaultに存在し、固定コンテキストウィンドウを持ち、Apple silicon上で動作し、デバイスを離れることはなく、ユーザーのApple Intelligence適格性によってゲートされます。¹ アプリ開発者は@Generable型で入力を制約し、Toolプロトコルでアプリの能力を公開し、機能がトリガーされたときにモデルを呼び出すバイナリを出荷します。ユーザーが機能を呼び出し、OSがモデルを供給し、アプリが両者を縫い合わせます。

Claude Code、Cursor、Codex CLI、その他のエージェント型IDEは、別のスタックを形成します。モデルはホストLLMプロバイダーが動かしている場所（ClaudeならAnthropicのサーバー、GPTならOpenAIなど）に存在します。IDEがホストです。MCPサーバーはホストのモデルが呼び出せるツールです。開発者のマシンはファイルシステムアクセス、シェルアクセス、その他IDEが公開することを選んだあらゆるものを持ちます。開発者がエージェントを呼び出し、エージェントが開発者のファイルシステムに手を伸ばし、出力が開発者のプロジェクトに着地します。²

同じ単語「LLM」、まったく異なる影響範囲です。

2つのスタックが分岐する6つの軸

6つの特性が、その分岐を具体化します。

信頼境界の行が荷重を支える行です。ランタイムLLMはユーザーのプライバシー期待のもとアプリのサンドボックス内で動作し、ツールLLMは開発者の権限のもと開発者のマシン内で動作します。LLMにシェルコマンドを実行させるようなパターンは、ツールでは普通であり（Claude CodeはBashツールを通じて常にこれを行います）³、ランタイムでは論外です。Foundation ModelsにはBashツールはなく、Toolプロトコルはアプリ開発者が書きレビューする型付きSwift関数です。¹

誤用コストの行は、信頼境界を誤った場合の帰結です。ユーザーデータをサーバーに送信するランタイムLLMはプライバシー違反であり、ガイドライン却下対象です。開発者のソースコードをLLMプロバイダーに送信するツールLLMは、開発者の契約次第で、期待された動作かリークかのどちらかです。両方とも重要ですが、それぞれ異なる理由で重要なのです。

境界に位置するMCPサーバー

境界の動きを最も明確に見られるのは、両方のスタックで単一のMCPサーバーが使われるときです。Get Bananasは、買い物リストの操作（項目の読み取り、追加、完了マーク）を公開するMCPサーバーを出荷しています。同じサーバーが2つの場所で動きます。⁴

反復作業中の開発者のClaude Codeセッションでは、MCPサーバーは、開発者のエージェントが開発者自身のリストを操作するために呼び出すツールです。サーバーはiCloud Drive内のJSONファイルに対して動作します。開発者はMCPホスト設定にサーバーを組み込み、ホストはそれを呼び出すことを知り、エージェントはより大きな開発タスクの一部として買い物項目を読み書きします。

エンドユーザーのエージェントサーフェス（共有リストを指す外部のClaude Desktopユーザーなど）では、同じMCPサーバーは異なる責務を負います。呼び出し元はもはやファイルシステムへの完全な信頼を持つ開発者のBlakeではなく、認証、認可、意図の精査が開発者の責任ではないエンドユーザーです。MCPサーバーは、そのサーフェスが安全になる前に、それらのガードレールを強制（または公開を拒否）する必要があります。

同じJSON-RPCメソッドadd_itemが、認証なしのローカルstdioトランスポートで開発者に提供される場合は適切な形です。認証なしで任意のエンドユーザーに代わってインターネット到達可能なホストに提供される場合、データ整合性の危険となります。MCPサーバーは同じコードであり、周囲のデプロイメントがすべてを変えるのです。

これがエージェント型Apple開発におけるMCPサーバーのルーティングルールです。サーバーはドメイン上の型付き契約です。スタック内のどこに位置するか（開発者ツールかエンドユーザーサーフェスか）はデプロイ上の決定であり、プロトコル上の決定ではありません。デプロイをコードレビューしてください。プロトコルの寛容なデフォルトが、デプロイの正しいデフォルトであるとは仮定しないでください。

オンデバイスのToolプロトコルはMCPサーバーではない

よくある混乱があります。Foundation ModelsにはToolプロトコルがあり、MCPにもツール呼び出しがあります。同じものでしょうか。違います。そしてその違いはルーティングにとって重要です。

Foundation ModelsのToolプロトコルは、アプリ開発者が実装するSwift APIです。¹

struct WaterEntryLookup: Tool {
    let name = "lookup_water_entries"
    let description = "Look up water intake entries for a given date range."
    @Generable struct Arguments { ... }
    func call(arguments: Arguments) async throws -> String { ... }
}

ツールはアプリプロセス内で動きます。ツールが提供するモデルはデバイスのSystemLanguageModelです。引数と出力はSwift型です。開発者が実装をレビューし、App Storeがアプリをレビューします。ユーザーが機能を呼び出し、アプリのセッションがツールを呼び出し、ローカルモデルが結果を使います。

MCPツールは、ホストLLM（Claude、GPTなど）が接続する別プロセスであるMCPサーバーが公開するJSON-RPCメソッドです。²

{
  "name": "add_item",
  "description": "Add an item to the shopping list.",
  "inputSchema": {"type": "object", "properties": {"name": {"type": "string"}}}
}

ツールはエージェントのプロセス外で、開発者が選んだ任意の言語で、stdioまたはStreamable HTTP上でJSONを話して動きます。モデルはホストが配置した場所にあります。引数はスキーマに対して検証されたJSONです。説明責任はMCPサーバーをデプロイした人にあります。

2つのプロトコルは、重なり合う問題を異なるスコープで解決します。

ルーティングルールは単純です。能力がエンドユーザー向けにアプリ自身のLLM機能を提供するなら、Foundation ModelsのToolに入れます。能力がプロセスをまたいで動作する外部エージェント（開発者またはエンドユーザー）に提供されるなら、MCPツールに入れます。両方を必要とするアプリもあります。同じSwift関数が両方のアダプターを支えることもできますが、アダプターは異なるスタックレイヤーに位置し、異なるリリースサイクルで出荷されます。⁵

フックはツールLLMがその場所を獲得するところ

ツールLLMの影響範囲が、フックを荷重を支える安全プリミティブにします。Claude Codeのフックシステムは、ライフサイクルイベント（PreToolUse、PostToolUse、UserPromptSubmit、SessionStart、Stop）でスクリプトを実行します。⁶ Claude Codeを使うiOS開発者がフックを設定するのは、エージェントが悪意あるからではなく、エージェントの権限が広いから、つまりファイルシステム書き込み、シェル実行、gitコミット、pushがあるからです。

エージェント型Appleワークでフックの枠を獲得するパターンは次のとおりです。

明示的な承認なしにxcodebuildまたはxcrunにマッチするBashコマンドに対するPreToolUseブロック。 Claude Codeは、許せばビルドの実行、シミュレーターの消去、署名やエクスポート手順の呼び出し、生成されたプロジェクト状態の変更まで行えます。フックは「エージェントがビルドを実行した」を「エージェントがビルド実行を依頼してyesをもらった」に変えます。不可逆なアクションでエージェントを減速させることは、開発者の信頼にとって正しいトレードオフです。

.pbxprojファイルに対するすべてのEditまたはWriteツール呼び出しに対するPostToolUseバリデーター。 Xcodeプロジェクトファイルは人間が編集するものですが、エージェントには有害です。1行間違えるだけで、チームのすべての開発者にとってビルドが静かに壊れます。コミット前にすべての.pbxproj書き込みに対してplutil -lint（または同様の構造チェック）を実行するフックは、「エージェントが5分でマイグレーションを書いた」と「エージェントがマイグレーションを書き、git bisectに45分」の差です。

エージェントがタスクを完了と宣言する前にswift build（または適切なビルドコマンド）を実行するStopフック。 エージェントは会話における「完了」がどう見えるかで訓練されています。フックは「完了」を「ビルドがまだコンパイルできる」と意味するように変えます。これは出荷にとって唯一意味のある定義です。

ランタイムLLMはこれらを必要としません。Foundation Modelsには、シェルもgitもプロジェクトファイルもMCPサーバー設定もありません。オンデバイスのToolはアプリ開発者が書いた任意のSwift関数であり、ユーザーが機能を呼び出し、アプリ自身のTool実装がそうしない限り、何もアプリのサンドボックスやエンタイトルメントを逃れません。

非対称性こそが要点です。ツールLLMはより多くの権限を持ち、より多くのガードレールを必要とします。ランタイムLLMは構造的にはより少ない権限しか持ちません。AppleがランタイムLLMを安全にする仕事をしました。開発者はツールLLMを安全にする仕事を担います。

アーキテクチャのルール

ランタイム/ツールの区別から、3つのアーキテクチャルールが導かれます。

アプリごとではなく、能力ごとにレイヤーを選ぶ。 瞑想アプリは、アプリ内要約のためにFoundation Modelsを使い（ランタイムLLM、オンデバイス、アプリと共に出荷）、同時に反復作業中にセッション履歴を一括インポートするために開発者がClaude Codeで使うMCPサーバーを公開するかもしれません。2つのLLMは異なるレイヤーで異なる仕事を担います。これらを1つの決定として扱うと、2つの決定として扱うよりも両方のレイヤーで悪い結果を生みます。

ツールLLMの到達範囲をコードレビューする。 完全なファイルシステムアクセスとリモートMCPサーバーを持つClaude Codeセッションは、強力な開発環境であり、寛大な攻撃面です。緩和策は「エージェントを信頼する」ことではなく、フック、スコープ付き権限、差分を読む開発者です。エージェントはあなたのために働きますが、エージェントはあなたではありません。

ランタイムLLMのToolセットを安定したAPIとして出荷する。 Foundation Modelsツールはアプリのバイナリ契約の一部です。リリース間でツールを削除または改名することは、その機能に依存していたユーザーにとっての挙動変更です。ツール定義は内部ヘルパーではなく、UIアフォーダンスのように扱ってください。

自分のスタックで違うやり方をするとしたら

クラスターのアプリが既に出荷しているか、出荷したかったと思っているパターンが2つあります。

ドメインレイヤーを最初に作り、ランタイムツールとツールMCPサーバーが同じSwift関数をラップするようにする。 App Intents vs MCPからのデュアルアダプターパターンは、ランタイムLLMツールへ自然に拡張されます。logWater(amount:caller:)ドメインメソッドは、AppIntent（Apple Intelligenceサーフェス）、MCPツール（外部エージェントサーフェス）、Foundation ModelsのTool（アプリ内ランタイムLLMサーフェス）でラップされます。3つのプロトコルアダプター、1つのドメイン関数、3つの異なる責務を持つ3つの呼び出し元クラス（システムエージェント、外部エージェント、オンデバイスモデル）です。関数はどの呼び出し元が呼び出したかを知らず、アダプターが信頼シグナルを運びます。

エージェントのMCPサーバーを設定ではなくコードとして扱う。 iOSプロジェクトで参照される.mcp.jsonは、スコープと優先順位の信頼サーフェスです（The Repo Shouldn’t Get to Vote on Its Own Trustで扱っています）。Claude CodeはMCPサーバーのスコープをローカル > プロジェクト > ユーザーの順で解決し、プロジェクトスコープのサーバーは使用前に開発者に承認を求めます。エージェントは設定を読み、開発者が承認したサーバーに接続します。開発者は設定とサーバーをレビューします。プロジェクトにMCPサーバーを追加することは、設定の調整ではなく、コードレビューです。

Foundation Modelsが正しい場合とツールLLMが正しい場合

クラスターの記事が収束する決定木です。

Is the capability a feature an end user invokes inside your app?
├── Yes → Runtime LLM (Foundation Models or cloud LLM behind an Apple Intelligence-aware surface)
│         Use the Tool protocol for app-internal tool calls.
│         Use App Intents for capabilities the system agent should reach.
└── No → It is part of the developer's iteration loop.
          ├── Is the capability local to one developer's machine? → Tooling LLM
          │     Use Claude Code, Cursor, or Codex CLI directly.
          │     Wrap shared utilities as MCP servers behind hooks.
          └── Is the capability shared across the team? → Tooling LLM with shared MCP servers
                Deploy the MCP server somewhere the team can reach.
                Code review the server like production code; gate dangerous tools behind explicit approval.

決定が引き分けになることは稀です。引き分けになる場合（同じ能力がエンドユーザーと開発者の両方を正当に提供できる場合）、答えは1つの共有サーフェスではなく2つのアダプターです。なぜなら、信頼姿勢と更新サイクルが十分に異なり、両方を提供しようとする1つのサーフェスは両方で妥協することになるからです。

このパターンがiOS 26+で出荷するアプリにとって意味すること

3つの要点です。

1. 2つのLLM、2つのスタック。 ランタイムLLM（Foundation Models、オンデバイス）は、アプリ内でユーザーのデータに対して動作するユーザーのエージェントです。ツールLLM（Claude Code、Cursor、Codex CLI）は、アプリを構築するために開発者のマシン上で動作する開発者のエージェントです。これらは「LLM」という単語を共有し、それ以外はほとんど何も共有しません。

2. 信頼境界がアーキテクチャである。 モデルが動く場所、誰が動かすか、何に触れるかが責務を定義します。一方の境界に合うパターンは、もう一方の境界では積極的に失敗します。

3. MCPサーバーが境界を運ぶ。 同じサーバーが、あるデプロイでは開発者ツールであり、別のデプロイではエンドユーザーサーフェスです。プロトコルは変わりません。デプロイが変わり、デプロイこそがエンジニアリングの注意を必要とする部分です。

Apple Ecosystemクラスター全体は次のとおりです。Apple Intelligence向けの型付きApp Intents、クロスLLMエージェント向けのMCPサーバー、両者間のルーティングの問い、オンデバイスLLMとToolプロトコル向けのFoundation Models、ワークロード適合と専門化の兄弟記事としてユースケースとカスタムアダプター、iOSロック画面ステートマシン向けのLive Activities、Apple Watch上のwatchOSランタイム契約、フレームワーク基盤向けのSwiftUI内部、visionOSシーン向けのRealityKitの空間メンタルモデル、永続化向けのSwiftDataスキーマ規律、ビジュアルレイヤー向けのLiquid Glassパターン、デバイス横断のリーチ向けのマルチプラットフォーム出荷。ハブはApple Ecosystem Seriesにあります。より広いAIエージェント付きiOSのコンテキストについては、iOS Agent Development guideをご覧ください。

FAQ

アーキテクチャの観点からFoundation ModelsとClaude Codeの違いは何ですか？

Foundation Modelsはランタイム機能です。LLMはiOS 26と共に出荷され、SystemLanguageModel.defaultを通じてユーザーのデバイス上で動作し、アプリのLanguageModelSessionがトリガーされたときに呼び出されます。アプリはユーザーの代わりに呼び出しを実行します。Claude Codeは開発ツールです。LLMはAnthropicのインフラ（または設定されたClaudeプロバイダー）で動作し、開発者のマシンがIDEをホストし、エージェントは開発者のファイルシステム、シェル、MCPサーバーへのアクセスを持ちます。開発者がエージェントを駆動し、エージェントがアプリの構築を支援します。

同じMCPサーバーが私のエージェントとエンドユーザーの両方に提供されるべきですか？

おそらく違います。同じJSON-RPC契約が両方にとって正しい形になることはありますが、デプロイは異なります。認証なしの開発者側stdioは開発者ツールにとっては普通ですが、エンドユーザーサーフェスにとっては危険です。プロトコルは再利用可能ですが、デプロイはそうではありません。同じサーバーを両方に公開する場合、1つのサーフェスを両方の聴衆に提供するのではなく、1つのコードベースの背後にある2つのデプロイとして扱ってください。

なぜツールLLMにはフックが必要で、ランタイムLLMには必要ないのですか？

ツールLLMは開発者のマシン上でファイルシステムアクセス、シェルアクセス、MCPサーバー、任意のコード実行権限を持ちます。ランタイムLLM（Foundation Models）はアプリのTool実装が公開するもの、アプリのサンドボックス内、シェルなしで持つだけです。影響範囲は非対称です。フックは、その広い権限に対して開発者に実行前レビューと実行後検証を与えます。ランタイムLLMは構造的に権限が制約されているため、フックを必要としません。

単一のSwiftドメイン関数がランタイムとツールの両方のLLMユースケースを提供できますか？

はい、それが正しいパターンです。デュアルアダプターアプローチ（1つのSwift関数、複数のプロトコルラッパー）は、App Intents vs MCPからFoundation Modelsツールを含むように拡張されます。関数はどの呼び出し元が呼び出したかを知らず、アダプターがスキーマ、信頼シグナル、プロトコル固有の責務を運びます。3つのアダプター、1つのドメインメソッドです。

ホスト型クラウドLLM（OpenAI、Anthropic API直接）はこの絵のどこに収まりますか？

実行時にアプリ内から呼び出されるクラウドLLMは、第3のカテゴリーであり、オフデバイス推論を伴うランタイムLLMです。「アプリがユーザーの代わりに呼び出しを実行する」というFoundation Modelsの信頼姿勢を共有しますが、オンデバイスのプライバシー物語とOS供給の可用性物語を失います。決定木は拡張されます。クラウドランタイムLLMは、オンデバイスモデルのエンベロープを真に超える能力（大規模コンテキスト、フロンティア推論、大規模マルチモーダル）に適切で、ユーザーのプライバシー期待に受容可能（透明な開示付き）です。Foundation Modelsはワークロードが適合する場合のデフォルトであり、クラウドはそうでない場合のエスカレーションです。

References