Code Along：Foundation Modelフレームワークによる、アプリへのオンデバイスAIの組み込み

こんにちは Naomyです 本セッションでは SwiftUIと オンデバイスのAIについて詳しく解説します このCode Alongでは 便利な新機能を Foundation Modelフレームワークを使って アプリに追加する方法を紹介します ステップごとに例を示しながら 旅行のプランニングに役立つ アプリを作成します Foundation Modelフレームワークを使うと Appleのオンデバイスの大規模言語モデルに 直接アクセスできるので アプリ構築における可能性が まさに無限に広がります すべてがオンデバイスで実行されるため データのプライバシーも守られます モデルはオフラインであり OSに組み込み済みです アプリのサイズが増えることもありません このフレームワークを使うことで 強力かつプライバシーに配慮した 高性能の機能をmacOS、iPadOS、 iOS、visionOSに導入できます 友達との旅行を計画する際は 行き先や現地でのアクティビティについて ヒントがあるとありがたいですね 旅の計画は大変ですが Foundation Modelフレームワークの利用は簡単です このフレームワークでアプリを構築し 計画を全部お任せしましょう 今回作るのは次のようなアプリです ランディングページには 注目の観光名所が表示され スクロールして確認できます 面白そうな木がありますね ジョシュアツリー国立公園を選びます をタップすると モデルが処理を始めます モデルによる旅程作成のプロセスでは ツールの呼び出しも行われ 選んだ観光名所における おすすめスポットが自動選択されます 友達にも気に入ってもらえそうな このアプリを作ってみましょう Foundation Modelフレームワークの使用には いくつかのステップがあります まずはプロンプトエンジニアリングです XcodeのPlaygroundを使って プロンプトを仕上げる方法を紹介します 次に ツール呼び出しを使用して モデルが外部のソースにアクセスして おすすめスポットを取得できるようにします 次に 出力をストリーミングし モデルが生成した旅程を 順次表示していきます 仕上げに アプリをプロファイリングし 最適化を行って Foundation Modelフレームワークでの パフォーマンスを強化します 優れたプロンプトは 良好な結果を得るための鍵です プロンプト作成は面倒なことが多く 大量の反復作業が必要です アプリを実行して出力を調べ プロンプトを変更して再実行する作業を 繰り返すこともできますが 終日その作業に拘束され 旅行を計画するための時間がなくなります そんな時に役立つのが アップデートされた XcodeのPlaygroundです まず キャンバスが有効になっているか 確認します

SwiftUIのプレビューと似ていますが こちらでは Swiftコードのフィードバックが 即座に得られます Playgroundは プロジェクト内の どのファイルにもインポートできます

#Playgroundと記述すれば コードを反復処理できます

基本から始めましょう FoundationModelsをインポートし

セッションを作成して

リクエストを作成します

プロンプトは「Create an itinerary （旅程を作成して）」にします 入力し終わると すぐに自動で実行され 結果をキャンバスで確認できます

指示が少しあいまいだったようですね 場所を追加してみましょう

はるかに良いプロンプトです 今度は旅程が生成されました とりあえずこれで良しとしますが プロンプトは後からいつでも微調整できます Foundation Modelフレームワークを 使い始めるのがどれほど簡単かを プロンプトを入力して 文字列を出力させることで紹介しました とはいえ 構造がより明確な 旅程にしたいというのが本音です 自前のデータ構造を使って 結果が表示されるようにしたいのですが モデルの出力の解析に 煩わされたくはありません この場合 ガイド付き生成を使用すれば ニーズに合ったデータ構造を モデルが自動的に作成してくれます そのためには @Generableという注釈を付けます 実際にやってみましょう モデルに生成させたい旅程の構造は このようなものです まず FoundationModelsをインポートし

@Generableという注釈を追加します

@Generableの要件は1つだけ プロパティの型もGenerableであることです 幸い stringなどの一般的な型は もともとGenerableです このDayPlanのように ネストされた型がある場合は それらをGenerableにするだけです これで すべてGenerableな 型の階層ができたので 次は モデルの回答として 旅程の構造を生成させましょう 出力をより高度に制御したい場合は @Guideマクロを使用すれば プロパティの値に制約を設けられます 例えば 説明付きのガイドを追加できます このように タイトルの説明などができます

プロパティを既知の値のみに 制限することもできます

例えば countを追加して

daysの配列の要素の数が 必ず3つになるように制限できるほか 1つのプロパティに 複数のガイドを使用することもできます プロパティに追加する ガイドの数を増やしてみましょう

ガイドによる説明は モデルへの指示を行う もう1つの優れた方法です これについては Deep Diveのビデオをぜひご覧ください ガイド付き生成について Louisが詳しく解説しています 以上でプロンプトと Generable型を作成できたので これらを組み合わせましょう

このItineraryPlannerにFoundation Modelの すべてのロジックが格納されます

セッションを作成し

指示を与えます Builder APIを使用すれば 簡単に指示を作成できます このクロージャでは 複数の文字列や Generable型のインスタンスを渡せます 指示は よりハイレベルな形式のプロンプトです これにより モデルのタスクを定義できます

生成させるのは旅程であるため 選択した観光名所に関する情報を モデルに提供します

どのような回答を求められているのか モデルが理解しやすいように 例を含めると良いでしょう

次に Itineraryの構造体のインスタンスを 渡しますが これは下部のコードで 日本への旅行として定義します

Itineraryの構造体はGenerableなので Foundation Modelフレームワークにより モデルが理解できるテキストに 自動的に変換されます これで Generable型を出力とする リクエストを実行する準備が整いました

プロンプトにより モデルに旅程の作成を明示的に指示します

すべてを出力に統合するために モデルからの回答を旅程として設定します

最後のステップはUIへの表示です ItineraryPlannerをObservableにして 旅程が生成された際に UIが認識できるようにします

次に これをLandmarkTripViewに Stateプロパティとして追加して Plannerの内容が変更されると ビューが更新されるようにします

ここでPlannerを初期化すると ビューが画面に表示されない場合でも ビューが無駄に再作成されてしまい パフォーマンスに悪影響が生じます そこで taskモディファイアを使用して オブジェクト作成を遅延させます taskを追加して この箇所でPlannerを初期化します

これは ビューが表示された時に 一度だけ呼び出されます モデルから旅程を受け取ったら 表示できるようになります

ここで ItineraryViewという 別のビューを使用します このビューにタイトルを表示します

スタイルも設定しましょう

説明についても同様にします

根拠も同様にしましょう

続けて 旅程のその他のプロパティを 他のビューを使用して同様に表示します ここまでうまくいきました モデルが記載された説明に従って 基本的な旅程を生成できるようになりました 次のステップに進みます Foundation Modelフレームワークでは 柔軟なツールプロトコルを介して モデルが回答の生成に 外部の情報を利用できます 創造の幅が大きく広がり スマートフォン内の連絡先、 カレンダーのイベントのほか オンラインコンテンツまで活用できます モデルは ツールを呼び出すタイミングや頻度を 自律的に判断します 旅行計画アプリをより有用にするために MapKitを呼び出すことで 観光名所のおすすめスポットを 取得するツールを作成しましょう ツールを作成するには そのツールの プロトコルに準拠する必要があります

具体的には ツールを識別するための固有名、 自然言語による ツール呼び出しのタイミングの記述、 ツールを呼び出す手段であるcall関数と そこで使用される 独自定義の引数などが必要です では ツールの作成を始めましょう FoundationModelsをインポートし

MapKitもインポートします

ツールのプロトコルに準拠したデータ構造に

名前と

説明を記述します

これらの文字列は フレームワークによって 自動的に指示に取り込まます これにより モデルがツールの役割を理解し 呼び出す場面を判断できるようになります ツールは 選択した観光名所などの ユーザーによる入力も取得できます

ツールが多様なおすすめスポットを 取得できるように enumを追加します

モデルは世界に関する自らの知識に基づいて 当該の観光名所に適したカテゴリを 判断します 例えば グレートバリアリーフの周辺で マリーナが見つかる確率は ジョシュアツリー国立公園のような 乾いた砂漠地帯で探すより高いはずです このenumはモデルが生成するので Generableである必要があります

次は enumを使用するArguments構造体を 自然言語によるクエリと一緒に定義します

この実装にはcallメソッドを使用します

これは モデルが自らの判断に基づいて ツールを呼び出す際に用いるメソッドです 先ほど MapKitのロジックを記述しました

これは MapKitへのリクエストを行います

このリクエストでは モデルが生成した 自然言語によるクエリを入力として使用し モデルが選択したカテゴリを併用することで 観光名所の座標から20kmの範囲内にある おすすめスポットを取得します

指定した制約に基づいて検索が行われ

結果が返されます

これで callメソッドを 実装できるようになります MapKitを呼び出して

検索結果を絞り込み

出力を返します

MapKitから情報を取得するツールの定義に 必要な作業はこれだけです 連携させるために ItineraryPlannerに戻りましょう

これは 先ほど作成したセッションです ツールのインスタンスを作成して ユーザーが入力として選んだ 観光名所を指定します

次に ツールを セッションのイニシャライザに渡します

モデルにツールを呼び出させるには これで十分ですが プロンプトを追加して 呼び出しの頻度を増やすこともできます 使用するツールとカテゴリは 明示的にモデルに指示できます

準備は以上です テストに移りましょう テスト用のデバイスが 手元になくても大丈夫です 開発用マシンで最新のmacOSを実行していて Apple Intelligenceが有効であれば iPhoneとVision ProのSimulatorで 手軽にテストできます ジョシュアツリー国立公園を選択して 旅程の生成を指示します

少し時間がかかると感じるかもしれません これは モデルがすべての出力を 一度に返そうとしているからで 結果全体が生成されるまで 個々のアクティビティは表示されません ご心配なく 後ほど この時間を短縮する方法を紹介します さて 楽しげな旅程が表示されました

しかし 大事なことを忘れているようです ここでは オンデバイスの基盤モデルが 常に利用可能だと想定していますが 実はそうとは限りません モデルの可用性は Apple Intelligenceの可用性に依存しますが 使用デバイスで Apple Intelligenceが サポートされていない、 無効にされている、 準備が整っていないなどの場合もあります そこで重要なのが モデルの状態をチェックして UIで必要な対処を行うことです 物理的なデバイスでテストしたり または 考えにくいことですが テストのためだけにApple Intelligenceを 無効にしたりする代わりに Xcodeの便利なスキームオプションを 利用できます

このスキームには 基盤モデルの可用性を オーバーライドする設定があります 現在はオフです これら3つのオプションはいずれも デバイスでモデルを使えない理由になります 1つを選択して 旅程を生成させてみると アプリで何が起きるか見てみましょう

これはいけません エラーが表示されるだけで 解決法も示されません アプリでモデルを利用可能にする方法を 戻って検討する必要があります 先ほど言及した 3つのケースを考えてみましょう デバイスがApple Intelligenceを サポートしていない場合は 旅程生成のボタンを表示しても無意味です 観光名所を選択したユーザーには その場所の簡単な説明だけ表示されるように アプリ内のオフラインデータを使用します 2つ目は デバイスはApple Intelligenceを サポートしているけれども 単に有効になっていないケースです この場合 Itinerary Plannerが使えないのは Apple Intelligenceが無効だからだと ユーザーに伝え 機能を有効にして 利用するか判断してもらいます 3つ目の「モデルの準備ができていない」は モデルのダウンロードが 未完了という意味です この場合 少し待ってから再試行すれば 機能を利用できることをユーザーに伝えます

アプリの動作を設計できたので 可用性に関するAPIを活用して デバイスにおけるモデルの可用性を 判断できるようにしましょう このビューで 新しい変数を使用中のモデルに追加します ここではSystemLanguageModelです

このモデルで 可用性の状態の オーバーライドをオンにします

モデルが利用可能なら これまで通り動作するようにします

Apple Intelligenceが有効でないなら ユーザーに通知するようにします

また モデルの準備ができていないなら 後で再試行するよう伝えます

それ以外なら旅程生成のボタンを非表示にし その観光名所の情報のみを表示します

先ほど Foundation Modelフレームワークの スキームの オーバーライド設定で を選択しました この状態で再度試してみます

ずっと良くなりました 観光名所の情報だけが表示され 旅程生成のボタンは消えているので デバイスがサポートしていない機能に ユーザーが誘導されることはありません 先ほど説明したように このアプリは旅程が全部生成されるまで UIには何も表示されません そこで モデルが生成する旅程を 順次ストリーミングすれば おすすめ情報をすぐに読み始められます ストリーミングを使用するには 呼び出す応答のメソッドを変更します

取得の対象を 旅程全体ではなく 旅程の一部にします PartiallyGeneratedという データ構造を使用できます これは自動的に作成されます Generableな構造ですが プロパティはすべてオプションです では 旅程において想定される型を 変更しましょう

結果は新しい非同期シーケンスになり 出力はPartiallyGenerated型になります

ストリームの各要素は 段階的に更新される旅程の各バージョンです 例えば 最初の要素にはタイトルがあっても 旅程の他のプロパティは nilであったりします 2つ目の要素には タイトルと説明が あるかもしれませんし そうして徐々に すべての情報を備えた旅程が 生成されていきます これらのプロパティをビューで アンラップする必要があります その際 どのプロパティなら他の要素と 別のタイミングで表示できるかを 考えると良いでしょう この例では 旅程にはタイトル、説明、各日の予定があり この順番は意図的なものです そこで Itineraryを PartiallyGeneratedにして

タイトルをアンラップします

説明もアンラップします

根拠もアンラップします

次は各日の予定です

部分的に生成された予定も 表示する必要があります PartiallyGeneratedの構造体は 自動で識別されるので IDの自己管理が不要なことも優れた点です PartiallyGeneratedの構造体には SwiftUIのforEachを使用できます

実に簡単ですね 旅程に応じた アニメーションも追加しましょう

さらに プロパティに コンテンツの遷移を追加します

これにより ビューへのストリーミングが スムーズになります

続けて他のプロパティを すべてアンラップすると いよいよ完成間近です 私のスマートフォンでテストしてみましょう 先ほどと同じリクエストを実行します

今度は UIへのストリーミング出力が すぐに始まります ユーザーが初日の予定を読んでいる間に コンテンツが生成されていきます

しかし 最初のフィールドが 表示されるまでのわずかな遅延が 気になったかもしれません これを修正するための 大きな手がかりになるのが 裏側で起きていることについての情報です

ここで役立つのが Foundation Model フレームワークの 新しいInstrumentsです パフォーマンスに影響する要因を 詳細に把握できます アプリのプロファイリングで 何がわかるか試してみましょう 先ほど説明した通り アプリはSimulatorで実行できます これは機能のテストには便利ですが パフォーマンスについては 正確な結果が得られないことがあります 例えば M4 MacのSimulatorでは 旧式のiPhoneより高速な結果になり得ます パフォーマンスを確認する際は そうした違いに 常に留意しておくことが重要です ここでは実機のiPhoneを使います

まず MacでInstrumentsアプリを起動し スマートフォンを接続します

次に Foundation Modelフレームワークの 新しいInstrumentsを追加して

記録を開始してから旅程を生成します

のトラックは モデルの読み込みに要した時間を示します システムのデフォルトの言語モデルと ガードレールが読み込まれました 青色ののトラックも 表示されます

紫色のバーは ツール呼び出しに要した時間です 旅程の生成に要した総時間に加えて 入力トークン数もトラッキングできます 入力トークン数は 指示とプロンプトのサイズに比例します この最初の部分の遅延は システムの言語モデルの 読み込みにかかった時間です これを高速化する方法はいくつかあります 今見たように 初期の遅延が確認された部分は のトラックでした オンデバイスの言語モデルは OSによって管理され システムが他の重要な機能を実行していると メモリに保存されなかったり 一定の期間 使用されなかったりします session.respondを呼び出した時に モデルがメモリ上にない場合には OSはモデルを読み込みます リクエストに先立ちモデルを事前に読み込み ウォームアップしておけば 短時間でセッションを開始できます これを実行する最適なタイミングは アプリが比較的アイドルな状態で ユーザーがセッションを利用する 見込みが大きい時です 例えば ユーザーがプロンプトに関連する フィールドへの入力を開始した時などが 絶好のタイミングと言えます このアプリでは ユーザーが観光名所をタップした時は かなりの確率で 間もなくリクエストが行われます そこで ユーザーが旅程生成のボタンを押す前に あらかじめモデルを読み込んでおくと ユーザーが説明を読み終える頃には モデルの準備が整っています

2つ目の最適化は リクエスト時に追加できます Response関数の引数である generatingを覚えているでしょうか ここではItineraryを使用しました Foundation Modelフレームワークによって データ構造の生成スキームが プロンプトに自動的に挿入されますが これによりトークン数が増え 遅延とコンテキストのサイズが増大します リクエストが行われる前に モデルが応答の形式を完全に把握していれば IncludeSchemaInPromptを falseに設定することで パフォーマンスを向上させることができます

この最適化を適用できるのは 1つ目のケースは 類似したリクエストを 連続してマルチターンの会話で行う場合です セッションの初回リクエストで プロンプトにスキーマが含まれているため ガイド付き生成のためのコンテキストが 既に提供されています そのため セッションの以降のリクエストで コンテキストの提供は必要ありません 2つ目のケースは スキーマの完全な例が 指示に含まれている場合です 先ほど 指示の中で旅程の例を渡しましたが このアプリではこれで十分です 旅程の構造に オプションのプロパティがないからです

スキーマに オプションのプロパティがある場合は 入力済みとnilのいずれの場合も含め すべてのオプションのプロパティについて 例を提供する必要があります 考慮すべき最後の点として IncludeSchemaInPromptを falseに設定すると ガイドに追加した説明は失われますが 詳細な例を提供していれば 問題にならないはずです では 最適化をテストしてみましょう リクエストにおいて IncludeSchemaInPromptのオプションを falseに設定します また 観光名所の説明を表示している間に セッションをウォームアップしておきます 簡単なラッパーを作って

セッション内で呼び出します

さて どうなるでしょうか 結果を再度記録したので確認してみましょう 生成ボタンを押す前から のトラックに 既に複数のアクティビティが存在します 入力トークンの数が大幅に減っていて 応答の総所要時間が短くなっています これらの最適化により 数秒にも及ぶ節約ができたことで 余裕をもって空港に向かえそうです これで旅行の準備は万端ですね

セッションを終える前に おすすめのセッションを紹介します 「Meet the Foundation Models framework」を未視聴の方は フレームワークの概要がわかるので ご覧ください 「Deep dive into...」ではより高度な内容を 「Explore prompt design & safety...」では プロンプト作成の ベストプラクティスを確認できます ご視聴ありがとうございました