WWDC2026速報|iOS開発者が今おさえておきたい注目の新技術7選
先日、WWDC2026のセッション動画をひととおり見終えて、正直「今年は例年よりチェックすることが多いな」と感じました。私は普段Swift/SwiftUIでアプリを作っているのですが、今回はAI関連のフレームワークがごっそり入れ替わっていて、公開されたばかりのXcode 27のベータ版を触りながら「これ、今のアプリの作り方が変わるかもしれない」と手が止まる場面が何度もありました。
この記事では、2026年6月8日に開催されたWWDC2026で発表された「iOS 27」を中心に、個人開発者やインディーズのアプリ開発者が押さえておきたい新技術を7つに絞って紹介します。単に「新機能が増えた」だけでなく、去年までと比べて具体的に何がどう変わったのか、そしてすでに似たような技術がサードパーティにある場合はAppleの技術を選ぶメリットは何か、という視点も添えてまとめました。
リリーススケジュールをまずおさらい
WWDC2026の基調講演で発表されたiOS 27は、当日から開発者向けのベータ版(Developer Beta 1)が公開されました。一般ユーザー向けの正式版は、例年どおり秋の新型iPhone発売と同じタイミングになる見込みです。今回はOSのバージョン番号がiOS・iPadOS・macOS・watchOS・visionOSすべてで「27」に統一されたのも地味に大きなポイントです。
1. Foundation Models framework:「テキストだけ・Appleのモデルだけ」からの脱却
これまでとの違い
Foundation Models framework自体は、実は今回が初登場ではありません。1年前のiOS 26(WWDC25)で導入された時点では、あくまでテキストベースのモデルで、リクエストに応じてテキストを生成するだけの機能でした。使えるモデルもApple純正のオンデバイスモデルのみで、サーバー側のモデルを選ぶ選択肢はありませんでした。
これがiOS 27では、Apple公式の開発者向けガイドによると次のように拡張されています。
画像をテキストと一緒に渡せる「マルチモーダルプロンプト」に対応し、写真を読み取って判断するような処理が書けるようになった
Apple純正モデルだけでなく、ClaudeやGeminiのようなクラウドモデル、さらには「Language Modelプロトコル」に準拠する任意のプロバイダーのモデルも、同じSwift APIから呼び出せるようになった
モデル・ツール・指示内容をセッションの途中で動的に切り替えられる「Dynamic Profiles」が追加された
OCRやバーコード読み取りなど、Visionフレームワークの機能をモデルが自分で呼び出せる「ツール」として使えるようになった
つまり「テキストしか扱えない、Apple製モデル限定のAPI」だったものが、「画像も扱えて、好きなAIプロバイダーを差し込める共通の窓口」へと役割が変わった、というのが今回のアップデートの本質です。
サードパーティのAPI(OpenAI・Google Cloud APIなど)と比べたメリット
これまでアプリにAIを組み込む場合、OpenAIやGoogle CloudのAPIのように、外部のクラウドAPIを呼び出すのが一般的でした。この方法には通信の遅延、利用量に応じたコスト、そしてユーザーデータを外部に送信することへのプライバシー懸念が常につきまといます。
ここで整理しておきたいのが、「オンデバイスモデル」「Appleのサーバーモデル」「Claude・Geminiなど第三者モデル」の3つは、それぞれ処理される場所が違うという点です。
オンデバイスモデル(SystemLanguageModel):端末内で処理が完結する、Apple純正のモデル
サーバーモデル(Private Cloud Compute):オンデバイスモデルでは処理しきれない要求向けに、Apple独自の「Private Cloud Compute」というセキュアな基盤上で処理される、こちらもApple純正のモデル。ユーザーデータをモデルの学習に使わない、処理後にデータを保持しないといった強いプライバシー設計はされていますが、処理自体はAppleのサーバー側で行われるため、データは端末の外に送信されます
Claude・Geminiなど第三者モデル:AnthropicやGoogleが提供するSwiftパッケージ経由で呼び出しますが、処理はそれぞれAnthropic・Googleが自社で管理するサーバー上で行われます。Anthropicが公開しているドキュメントには「リクエストはアプリからClaude APIへ直接送られ、Appleはそのリクエスト経路に含まれず、プロンプトも応答も見えない」と明記されており、Appleのサーバー(Private Cloud Computeを含む)を経由するわけではありません
以下のメリットが当てはまるのは、この中でもオンデバイスモデルを選んだ場合です。
オフラインで動く:インターネット接続がなくてもAI機能を提供できる
データが端末の外に出ない:処理がすべて端末内で完結するため、プライバシー保護の面で有利。医療や金融のような機微なデータを扱うアプリでも採用しやすい
利用量に応じたコストが発生しない:クラウドAPIのようにトークン数に応じた課金がなく、サーバーを自前で用意する必要もない
サーバーモデル(Private Cloud Compute)は通常のクラウドAPIよりプライバシーへの配慮は強いものの、「データが完全に端末内で完結する」わけではありません。またClaude・Geminiのような第三者モデルは、Apple自身のインフラすら経由しない、まったく別のクラウドで処理される点も区別しておきたいところです。
さらに、Swiftとネイティブに統合されているため、外部APIのようにHTTPリクエストを組み立ててJSONをパースして…という定型作業が要らず、わずか数行のコードでAI機能を呼び出せる手軽さも実務上のメリットとしてよく挙げられています。
一方で、オンデバイスモデルには「モデルの学習時点までの情報しか持たない」「大規模な計算処理には向かない」という弱点もあります。精度や最新情報が必要な処理は外部APIに任せ、定型的な処理はオンデバイスで、という使い分けが現実的な落としどころになりそうです。
トークン量とApp Store Small Business Programの関係
もう一つ実務上おさえておきたいのが、モデルごとに扱える**トークン量(コンテキストウィンドウ)**が大きく違う点です。
オンデバイスモデルは、iOS 26登場時点ではApple公式ドキュメントによると最大4,096トークンという制限がありました(日本語は1文字=1トークン換算に近いため、実質的にはさらに少なく感じられます)。その後iOS 26.4で8,192トークンまで拡大され、コンテキストサイズやトークン数を事前に確認できるAPIも追加されています。長文の要約や資料の一括読み込みのような用途には、依然として心もとない容量です。
これに対してサーバーモデル(Private Cloud Compute)は、コンテキストウィンドウが32,000トークンとオンデバイスモデルよりかなり余裕があります。そしてApple公式のPrivate Cloud Computeページには、次のように明記されています。
Available for App Store Small Business Program developers with enhanced AI capabilities and longer context windows. (App Store Small Business Programの開発者向けに、より高性能なAIと、より長いコンテキストウィンドウを提供)
つまり、このサーバーモデルの拡張されたトークン量は、App Store Small Business Program(初回ダウンロード数が累計200万未満の開発者向けプログラム)に登録していることが前提になっています。登録要件は次の3つです。
App Store Small Business Programに登録していること
累計初回ダウンロード数が200万未満であること
アカウントにPrivate Cloud Computeのエンタイトルメントが付与されていること
さらに注意したいのが、現時点では「対象外の開発者は有料でPCCを使う」という選択肢自体が用意されていないと報じられている点です。複数の開発者向けメディアが、2026年6月14日に公開されたApple公式ドキュメントをもとに、サードパーティ向けのPrivate Cloud Computeアクセスが実質的にSmall Business Programの対象者に限定されていると伝えています。対象アプリが後からダウンロード数200万を超えた場合も、6か月以内に別の方法へ移行するよう求められるとのことです。
大きめの規模のアプリを運営している場合、この「サーバーモデル+拡張トークン」の恩恵を受けられない可能性がある、という点は、モデル選定の際に頭に入れておいたほうがよさそうです。
2. Core AI:Core MLの後継、そしてMLXとの住み分け
これまでとの違い
Core MLは2017年に登場して以来、画像分類や自然言語処理のような「決まった形の入力を、決まった形で分類・予測する」タイプのモデルをオンデバイスで動かすために使われてきました。しかし大規模言語モデル(LLM)が主流になるにつれて、Core MLの設計の古さが目立つようになっていました。
Core MLはもともと1回ごとの推論(バッチ推論)を想定した設計で、LLM特有の「1トークンずつ生成していく」処理や、ストリーミング応答、複数ターンにわたる会話、ツール呼び出しのような使い方には向いていなかったためです。実際、去年公開されたFoundation Models frameworkも、Core MLの上に積み重ねる形ではなく、別立てで開発せざるを得なかったと報じられています。
iOS 27で登場したCore AIは、このLLM時代に合わせてゼロから設計し直されたフレームワークです。Apple Silicon特有のユニファイドメモリ構成やNeural Engineに最適化されており、自己回帰的なトークン生成やKVキャッシュの管理、ストリーミング出力などがネイティブにサポートされています。
MLXとの違い、サードパーティ製ランタイムと比べたメリット
「オンデバイスでLLMを動かす」という点では、Appleが公開しているMLXフレームワークや、iOSアプリでよく使われるllama.cpp・ONNX Runtimeのようなサードパーティ製ランタイムもすでに存在します。ではCore AIを選ぶ意味はどこにあるのでしょうか。
エンジニアによる有志の実機ベンチマーク(iPhone 17 Pro、Qwen3系モデルで検証)によると、次のような傾向が報告されています。
小さめのモデルをウォームな状態(2回目以降の呼び出し)で動かす場合、Core AIはMLXよりおよそ1.6倍高速だった
モデルサイズが8Bクラスまで大きくなると、Core AIとMLXの速度差はほぼなくなり、1.05倍程度の差にとどまった
長時間の連続実行ではGPUが発熱で速度を落としやすく、そうした場面ではCore MLとNeural Engineの組み合わせのほうが性能維持や消費電力の面で有利になることもある
MLXはもともと研究・学習・ファインチューニング寄りに作られた、Metal GPUとユニファイドメモリに特化した汎用フレームワークです。それに対してCore AIは「決められたモデルを、本番のアプリの中で安定して動かす」ことに寄せて設計されている、という違いがあります。自分でモデルを学習・改良し続けたい場合はMLX、完成したモデルを省電力・低レイテンシで動かしたい場合はCore AI、という住み分けになりそうです。
サードパーティ製ランタイムと比べたメリットとしては、変換・量子化パイプラインを自分でメンテナンスし続ける必要がなく、Apple Siliconのハードウェア更新にあわせてApple自身が最適化を続けてくれる点が大きいと思います。
※Core MLからCore AIへの具体的な移行手順や互換性については、現時点でApple公式の詳しいドキュメントがまだ少なく、今回の記事では確認できた範囲にとどめています。この点は続報として追いかけたいと思います。
3. SwiftUI・Swiftのアップデート:コードを変えずに速くなる部分と、書き方が変わる部分
これまでとの違い
これまでSwiftUIアプリのパフォーマンスを改善するには、状態管理の置き場所を工夫したり、リストの並べ替えUIを自前で(あるいはUIKitのUICollectionViewを使って)実装したり、スクロールを滑らかにするための遅延読み込みを手作りで実装したりと、開発者側の工夫が必要な場面が少なくありませんでした。
iOS 27のSwiftUIでは、次の点が変わっています。
コードを変更しなくても速くなる部分:状態の初期化やレイアウトの描画が効率化され、既存コードのままアプリの体感速度が向上するとされています
書き方自体が変わる(簡単になる)部分:リストやグリッド内でコンテンツを並べ替えられる「reorderableコンテナ」が標準搭載され、これまで自前で実装していた並べ替えUIをフレームワーク側の機能で置き換えられます。サブビューを遅延読み込みし、あらかじめ内容をプリフェッチする仕組みも標準で使えるようになりました
ドキュメントベースのアプリをディスクへ直接アクセスする形で、高性能に構築できるようになりました
また、Swift 6.4では警告を特定範囲だけ抑制できるようになったほか、テストの標準がXCTestからSwift Testingへと完全に移行しました。これから新規にテストを書くなら、Swift Testingを使うのが推奨ルートになります。
4. Xcode 27:エージェント型コーディングの強みと、まだ届いていない部分
これまでとの違い
これまでAIを使ったコーディング支援を受けたい場合、CursorやClaude CodeのようなサードパーティのAIコーディングツールを、Xcodeとは別のウィンドウで開いて併用するのが一般的でした。
Xcode 27では、Apple純正のFoundation Modelsに加えて、Claude・Gemini・OpenAIとの連携がIDEに標準で組み込まれました。ローカルで動くAIとサーバー側のAIを同じSwiftのAPI経由でまとめて扱え、複数のAIエージェントを組み合わせたワークフローを組める「Dynamic Profiles」や、UIのスクリーンショットを渡すとSwiftUIのコードを生成してくれるビジョン入力対応も追加されています。
サードパーティのAIコーディングツールと比べたメリットと限界
Xcodeにネイティブ統合されているメリットは、Apple SDKのドキュメントやシミュレーター、Instrumentsといった開発環境の情報とAIが同じ場所でつながっている点です。別ウィンドウでツールを切り替える手間がなくなり、Apple独自のAPIやプライベートフレームワークまわりの文脈もIDEが把握した状態でAIに相談できます。
一方で、海外の開発者向けメディアでは「Xcode 27はCursorやClaude Codeのような専用ツールとの差を縮めたが、まだ完全には埋めていない」という見方も出ています。特に長時間にわたって自律的にタスクをこなし続けるような使い方では、専用ツールに軍配が上がるという評価もあり、日常のちょっとした修正はXcode内で、大きめの自律タスクは専用ツールで、といった使い分けが当面は現実的かもしれません。
5. Liquid Glassのさらなる進化
昨年のiOS 26で導入された半透明の「Liquid Glass」デザインは、当初は透明度が固定されていました。iOS 27では、ユーザー自身が透明度をスライダーで調整できるようになったほか、SwiftUI・UIKit・WidgetKitのすべてで、マテリアルやタイポグラフィ、タブ・ナビゲーションバーが刷新されています。見た目が変わるということは、既存アプリのUIが意図しない見え方になっていないか、ベータ版で早めに確認しておく価値があるということでもあります。
6. App Intents×Siri:「呼ばれたら1つ実行する」から「文脈を理解して複数動く」へ
これまでとの違い
App Intents自体はiOS 16の頃から存在し、対応しておけばSiriから自分のアプリの特定の操作を呼び出してもらえる仕組みでした。ただしこれまでのSiriは、あらかじめ決められた1つのアクションを、ほぼそのまま実行するだけの「台本通りに動く」タイプのアシスタントで、画面に何が表示されているかを理解したり、複数のアプリをまたいで手順を組み立てたりすることはできませんでした。
iOS 27では、Siriが再構築され、画面上の情報やユーザーの文脈を理解しながら、複数の手順をまたいだ操作を実行できるようになりました。App Intentsで定義した個々の機能が、この新しいSiriにとっての「部品」として組み合わされ、より複雑な依頼にも対応できるようになった、というのが今回の大きな変化です。
なお対応機種には段階があり、基本機能はiPhone15 Pro/15 Pro MaxとiPhone16以降で使えますが、声のカスタマイズや高精度な文字起こしといった一部の高度な機能は、iPhone17 Pro・17 Pro Max・iPhone Airの3機種に限られる点は、対応を検討する際に押さえておきたいポイントです。
自前のチャットボットと比べたメリット
サードパーティのAI APIを使って、アプリ内に独自のチャット機能やアシスタントを作ることもできますが、それはあくまで「そのアプリを開いている間だけ使える機能」です。App Intentsに対応させておけば、ユーザーがアプリを開かなくても、OS標準のSiriから直接アプリの機能を呼び出してもらえます。「iPhoneの入り口」そのものに自分のアプリの機能を差し込めることが、システムレベルで音声アシスタントを提供しているApple自身の技術ならではの強みだと言えます。
7. ゲーム開発まわりの新機能
アプリ開発だけでなく、ゲーム開発に関わる新機能も発表されています。これまでは、対応言語ごとにアセットを手作業で分割し、ビルド設定を組む必要がありましたが、新しい「Managed Background Assets」を使うと、プレイヤーの言語設定に応じて必要な言語のアセットだけを自動でダウンロードでき、インストールサイズを抑えられます。また、PC向けゲームをiOS・iPadOS・macOS・tvOS・visionOS向けに移植しやすくする「Steam Asset Converter」という変換ツールも登場しました。Unityのアセット管理システムのようなサードパーティ製の仕組みと比べて、App Storeの配信の仕組みそのものと直接統合されている点が、Apple純正ツールを使うメリットになりそうです。
まとめ:まずは何から触ればいい?
今回のWWDC2026は、単に「新機能が増えた」というより、去年のiOS 26で種をまいたAI関連の仕組みが、今年になって「テキストのみ→マルチモーダル」「Apple製モデル限定→好きなプロバイダーを選べる」「Core MLでは対応しきれなかったLLM需要→Core AIで正面から対応」というように、それぞれ一段階成熟した年だったという印象です。
もしこれから何かひとつ触ってみるなら、個人的にはまずFoundation Models frameworkから試してみるのがおすすめです。追加のAPIキーも通信コストも不要で、Xcode 27のベータ環境さえあればすぐに動作を確認できます。App Intentsへの対応は少し腰を据えた作業になりますが、Siriがアプリへの入り口になっていく流れを考えると、早めに設計を検討しておいて損はないはずです。
正式版のリリースはまだ先ですが、ベータ版のうちに触っておくと、秋の正式リリース時にあわてずに済みます。この記事が、皆さんが何から手をつけるかを決める材料になればうれしいです。
ここから先は
¥ 100
この記事が気に入ったらチップで応援してみませんか?
