月: 2026年7月

WWDC26：Explore advanced App Intents features for Siri and Apple Intelligence

Siri のレスポンスを App Intents によってカスタマイズする方法。Spotlight のセマンティックインデックスによって、ざっくりした指示でもアプリコンテンツに対してインタラクションできるのは良さそう。

Explore advanced App Intents features for Siri and Apple Intelligence

0:00 – Introduction

  • Siri および Apple Intelligence との連携を洗練させるための高度なテクニックを解説
  • 扱うテーマ：Siri 会話のカスタマイズ、コンテンツ検出の改善、システム連携の活用

1:59 – Customize how Siri responds

  • Siri が返すレスポンスを、App Intents によって制御、カスタマイズし洗練させる
  • 空の結果を返すことで Siri に「見つからなかった」と応答させられる
  • ProvidesDialog プロトコルで応答文をカスタマイズ
    • IntentDialog(full:supporting:) で詳細な応答文（フル文字列）と短い応答文（サポート文字列）を使い分け
    • AirPods など音声読み上げではこのフル文字列が読み上げられる
  • $label.requestValue(...) でインテント実行途中に追加情報をユーザーに要求可能（e.g. 既に実行中のアラームラベルが存在していた場合、別の命名をするか尋ねる）

4:20 – Visual responses

  • DisplayRepresentation で title、subtitle、image を設定すると応答画面や Spotlight に反映される
  • ShowsSnippetView プロトコルで SwiftUI 製のカスタムスニペットビューを返すことが可能
    • アプリ独自のデザインで Siri の結果カードを表現できる

6:22 – Interaction donations

  • Siri がインテントを呼び出す前に追加の質問を挟むことが可能（e.g. メッセージ送信先を指定した時、コンタクトの類似した名前のうち誰が対象かを尋ねる）
  • IntentDonationManager.shared.donate(intent:result:) でユーザーの UI 操作をシステムにドネート
    • Apple Intelligence がユーザーの好みを学習し、継続中のアクティビティを追跡できるようになる
    • 過剰にドネートされるとシステムはそれらを無視することがある
  • システムインタラクション（Shortcuts 経由など）は自動的にドネートされる

9:46 – Confirmations and entity ownership

  • 副作用を持つインテントは Siri が自動的に確認を求める（e.g. 共用イベントの削除行為など）
  • OwnershipProvidingEntity プロトコルで所有権の状態を Siri に伝える
    • ownership プロパティで .unknown（自分のみ）や .shared（他のユーザーも関係）を返す、これに従って Siri がユーザーに確認を促すか判断する
    • 所有権情報を最新に保つことで Siri の確認フローが適切に動作する

11:59 – Semantic index with IndexedEntity

  • IndexedEntity に準拠し indexAppEntities で Spotlight へのインデックスを実装
    • CSSearcableIndex.indexAppEntities(_:) でセマンティックインデックスが入力
    • 意味ベースの検索でコンテンツが見つかるようになる
  • インデックスを最新に保つ仕組みと再インデックスのサポートが重要
    • ユーザーがコンテンツを追加したらインデックスを作成
    • 主要なプロパティが更新されたら再インデックス
    • コンテンツを削除したら、インデックスからもエントリを削除
  • IndexedEntityQuery を採用することで、再インデックスをサポートできる
    • ただし Core Spotlight レベルの API で再インデックスに対応していれば不要

13:32 – Structured search with IntentValueQuery

  • 大規模・サーバーサイド・頻繁に変化するコンテンツには IntentValueQuery を使用
    • e.g. アルバムはインデックスするが、含まれる曲はインデックスしない
    • values(for:) で構造化された検索入力を複数のエンティティ型にマッピング
  • AudioSearch のような入力型で検索クライテリアを受け取り、結果を返す

15:27 – In-app search

  • system.searchInApp スキーマを採用した AppIntent を実装すると、Siri 検索をアプリ UI で再実行可能
    • ドメイン採用やインデックス化の有無に関わらず利用できる汎用的なアプローチ
    • perform() 内でナビゲーション状態を書き換えてアプリの検索画面を開く

16:22 – Onscreen awareness

  • 表示中のコンテンツをエンティティに接続する 4 つのアプローチ
    • NSUserActivity ：ビュー全体に単一のプライマリエンティティを関連付け
      • View Annotation API .appEntityIdentifier モディファイア：複数エンティティが存在するビュー内の特定要素に付与
    • コレクションアノテーション：リストの選択状態をエンティティ ID にマッピング
      • .appEntityIndentifier(forSelectionType:) で選択IDを返し、画面外の選択肢に対してもアノテーションすることが可能
    • カスタムキャンバスアノテーション：独自描画領域内のエンティティを登録
  • これにより Siri が「このイベント」「あの曲」などの参照を解決できる

20:51 – Leverage existing integrations

  • ユーザー通知 UNMutableNotificationContent、Now Playing、Alarm Kit の設定にエンティティを添付可能
    • content.appEntityIdentifiers に EntityIdentifier の配列を設定
    • Now Playing では最も具体的なものから順に複数の EntityIdentifier を指定
    • Alarm Kit の AlarmConfiguration に appEntityIdentifier パラメータとして渡す

WWDC26：Discover new capabilities in the App Intents framework

App Intents に関する2026年のアップデートについて。実装未経験で未知の領域なのだが、アプリコンテンツをシステムが既知のデータ型として与えることが可能になったことでアプリ内の連携がより密になったり、システムによるアプリコンテンツの提案をよりユーザーのコンテクストベースで行えるようになったり、さらに Siri がデバイスまたいで会話継続できるようになったりで、よりアプリのコンテンツがアプリの箱から飛び出して生活に偏在できるようになった感がある。

Discover new capabilities in the App Intents framework

0:00 – Introduction

  • App Intents フレームワークの 2026 年アップデート概要
  • Siri、Shortcuts、Spotlight、Widgets、Apple Intelligence にわたる制御・柔軟性・開発体験の向上

2:40 – Share entities across apps with ValueRepresentation

  • ValueRepresentation でアプリのエンティティをシステムが理解できる構造化型に変換して共有
    • エンティティ自体が Transferable に準拠していれば、エンティティの情報を ValueRepresentation でシステムの理解する構造体に変換して transferRepresentation として返すだけ
    • 例：ランドマークを GeoToolbox.PlaceDescriptor として書き出し、Maps でナビゲーション可能にする
  • エンティティにすでに対応プロパティがある場合はキーパスで簡潔に記述可能
    • ValueRepresentation(exporting: \.placeDescriptor)

3:45 – Register relevant entities with RelevantEntities

  • システムに自アプリのコンテンツを登録する方法
    • 1. Spotlight にインデックスする：Siriで検索取得させたい場合
    • 2. インタラクションドネーション（IntentDonationManager API）：Siriとシステムにユーザーの使い方を学習させたい場合（繰り返しアクション）
      • → システムがパターンを学習し将来提案するようになる
    • 3. 未知のコンテンツの場合は？ Spotlight にインデクスされていないし、インタラクションもまだドネートされていない → ReleavantEntities でシステムにヒントを与える
  • RelevantEntities API で「いつ、なぜ」のコンテキスト付きでエンティティを提案
    • 例：ワークアウト開始時に再生中プレイリストを提案
  • updateEntities(_:for:) でコンテキスト付きエンティティを登録
  • コンテキスト・エンティティ・全体の 3 段階での削除 API が用意されている

7:05 – Handle entities efficiently with EntityCollection

  • 大規模なエンティティセットを効率的に扱うための EntityCollection 型
  • パラメータ型を [PhotoEntity] から EntityCollection に変更するだけ
    • perform() 内では photos.identifiers を使うことでフル解決を回避
    • 1000 枚の写真のタグ付けがほぼ瞬時に完了するほどのパフォーマンス改善

8:55 – Use entities across devices with SyncableEntity

  • OS 27 から Siri デバイスを跨いで会話を継続でき、エンティティも共有可能に
    • エンティティにはIDが採番されシステムはこれを鍵に特定するが、ローカル生成されたものかもしれない（ローカルID） → デバイス共通のIDが必要（安定ID） → SyncableEntity プロトコル
  • エンティティの ID がデバイスをまたいで安定している場合はプロトコル準拠を宣言するだけ
  • ローカル ID と安定 ID が異なる場合は SyncableEntityIdentifier でペアリング
    • サーバー UUID や Cloud Kit レコード ID などが安定 ID の典型例

11:01 – Richer parameter types

  • Duration と PersonNameComponents のネイティブサポートが追加
    • Siri、Shortcuts、Widgets でピッカー UI とローカライズが自動的に機能

12:38 – Union value parameters

  • @UnionValue 列挙型により 1 つのパラメータが複数の型を受け付けられるようになる
    • 例：ランドマークコレクションまたはフォトアルバムのどちらかを受け取るパラメータ
  • 各ケースの表示名を caseDisplayRepresentations で定義すると自動的にピッカーが生成される

13:26 – Extend execution with LongRunningIntent

  • LongRunningIntent で 30 秒の実行制限を超える処理が可能になる（e.g. アプリを開かずにウィジェット経由で大きな画像をアップロード）
  • performBackgroundTask ブロック内で progress を更新すると Live Activity として進捗を表示
  • CancellableIntent を組み合わせるとキャンセル処理（クリーンアップ）も実装可能
  • バックグラウンドでの GPU アクセスもサポート

15:27 – Target the right process with ExecutionTargets

  • allowedExecutionTargets でインテントの実行先プロセスを明示的に指定可能
    • .main：書き込み操作など、メインアプリが必要な場合
    • .appIntentsExtension：スタンドアロンのダウンロードなど、エクステンションで完結する場合
    • .widgetKitExtension：表示専用の読み取り操作
    • 複数指定でシステムに選択を委ねることも可能

松葉製作所 HHKB専用亀甲名栗木製パームレスト＆キーボードルーフを衝動買い

前回に続いて衝動買い。

HHKB 30周年記念モデルを衝動買い

昨日の記事にも記したが、HHKBをタッチ＆トライした高田馬場のコワーキングスペース CASE Shinjuku では、30周年記念モデルだけでなく、HHKBパームレスト界の頂点に君臨する松葉製作所のパームレストも試用していた。このときのフィーリングが忘れられず、HHKB 30周年キーボードと組み合わせて是非使いたくなってしまった。

HHKB亀甲名栗木製パームレスト＆キーボードルーフ | 松葉製作所

ということで、昨日衝動買いし、今日の昼に届いた。（ちなみに2026/07現在、松葉製作所さんの販売ページでは「ご注文をいただいてから７週間から９週間でお届け」と記載されているが、PFUのオンラインショップで購入したら当日発送だった。ありがたい。）

あらためて、抜群の安定感に舌を巻く。亀甲名栗という手法によって表面が処理されており、これによってパームレストにおいた手の甲がべたつかないし、何より手触り感が素晴らしい。そして想定外だったが木の香りが豊かなこと。外箱を開けた瞬間から香ってきたのだが、今使っていても微かに感じられる。手元で木を感じられて癒される。

あと実は一番の驚きだったのが、付属のゴム足の優秀さ。一般的なオフィスデスクの天板に対して、固定を通り越して固着していて、ちょっとやそっとではずれ動く気配がない。HHKBのゴム足を超えている。ちなみに、ゴム足は自分で貼る必要があるのだが、貼る前に底部を清潔にするためのアルコールティッシュ（健康診断の採血の時のような）まで付いているのは、親切すぎて感動した、、

CASE Shinjuku さんの紹介によると、付属のみつろうクリームで手入れをするとかなり味が生まれるそうなので、これを楽しみに月一でメンテナンスしたい。

松葉製作所「HHKB専用 亀甲名栗 木製パームレスト＆キーボードルーフ」の展示＆お試しを始めました！

HHKB 30周年記念モデルを衝動買い

先日Xを眺めていたところ、CASE Shinjuku という高田馬場にあるコワーキングスペースのとある投稿が目に留まった。

いちHHKBファンとして、PFUがHHKBの30周年を記念したモデルを発売したことも、それが伝統的なキー押下圧45gから30gにリニューアルしたものであることも当然知っていた。が、学生時代から使っているHHKB Professional 2 Type-S モデルが壊れないうちは他に乗り換えるつもりはまったくなかったので、こうしたニュースは気にも留めていなかった。（25周年モデルの雪もそうだが、どうせしばらくすれば通常ラインナップに並ぶだろうし、、）

が、30周年の各モデルが売り切れていくなかで、買わないにしてもこの30gという押下圧は、試せるうちに試しておかないと本当に幻になってからでは遅いと思い直し、週末 CASE Shinjuku に足を運んでみたのだった。

CASE Shinjuku は筆者の活動圏内にあり、先日もHHKBのユーザーミートアップ会場になっていたりしたことで認知したのだが、てっきり最近誕生したスペースかと思いきやインスタアカウントを遡ってみると、少なくとも10年は歴史がありそうだった。しかもHHKBの扱い自体も長い。

上の写真のとおり、HHKBの各シリーズやキーキャップが展示されていて、利用料金を払えば持ち込みのノートブックに繋いで試用することができる。しかも、写真には写っていないが、あの松葉製作所様の亀甲名栗パームレストも完備。これ4万円近くもするので試さずノールックで買うのは相当勇気がいるもので、何度も迷いつつ購入に至っていない一品だったので、二度嬉しい。

こんな感じで試用してみたのだが、、正直1打2打と触れただけで頭に電撃が走ったような衝撃を受けた。押下圧30gってこんなにも軽いのかと。さらにその静音性。この静音性は恐らく押下圧の差ではなくHYBRIDモデルになって改良された点だと思うが、長らくProfessional 2 Type-S を使い続けた身としては、ダブルでショックだった。と同時に、Pro 2 の静音モデルである Type-S とはいえども今となっては結構気になる打鍵音や、ちょっとしたストローク重さが、実は長年の愛着によって許せていただけで、ちゃんとストレスだったことに気がついてしまった。そうなるといてもたってもいられずにその場で注文。今日まで購入する気はまったくなかったので、まさに衝動買いだった。

これが土曜日の出来事で、翌営業日の月曜日に配送され今日の昼に自宅に届いたので、早速半日仕事で使ってみた。実は、HHKBは白一択と考えていて（もう1台、ほとんど使っていない Pro 2 無刻印モデルを所有）、注文時もまっさきに白US配列をカートに入れようとしたのだが既に売り切れており、今回初めて墨を選んでみた。

使用感はファーストインプレッションどおり、ほぼ文句なし。打鍵感は謳い文句通りの「フェザータッチ」。すいすいと入力できてしまう。

ただ、前評判で聞いていた通り、押下圧30gという軽さがミスタッチを誘発することは確かだった。ミスタッチといっても、タイピング最中の誤操作という類ではない。描くものが決まっていて筆が乗っている時にはあり得ないのだが、例えば考え事をしていたり画面に集中しているときなど、ふと気を抜いているとキーボードに置いた手が知らぬ間にキーを押下し続けていた、という現象はすでに何度も発生した（この記事を書いている間にも）。正直、これは慣れの問題だと思っている。

ここからは30周年というよりHYBRIDモデルへの感想になるが、まずゴム足の安定感。本体ががっちりとデスクに固定されるので手元の堅牢さが抜群。次に墨モデルのカラーリングも絶妙。筆者のデスクは白一色で、黒は浮くだろうという懸念から検討の視野に入れたことがなかったのだが、実際に配置してみるとそれは決して「黒」ではなく、じゃっかん青みがかったような、まさに硯の水で研いだ深い墨のよう。白い天板にも想定外に馴染んでくれたのだった。むしろ愛着の湧く風合い。

さて、こうなると13年近く使い続けた Pro 2 をどうしようか、ということだが、、学生時代から新卒を経て、いくつもの職場で（コロナ前も含めると物理的に）寄り添ってくれたいわば相棒をやすやすと引退させるわけにもいかない。とりあえずスタンドでも買ってしばらくは飾っておこうと思う。そして気が向いたらまた使ってあげたい。そのとき30gのキー荷重に慣れた手が、10年以上毎日を共にしたキーボードに何を感じるが楽しみだ。

WWDC26：Best practices for integrating visual intelligence in your app

Visual Intelligence による画像識別と、その結果のアプリへのハンドオフ実装について。

Best practices for integrating visual intelligence in your app

0:07 – Introduction

  • アジェンダ：コンテンツ定義・クエリ実装・クロスプラットフォーム対応・システムストア統合

2:02 – Defining your content

  • アプリコンテンツを AppEntity としてモデル化することで Visual Intelligence の検索結果に表示可能（AppEntity = アプリにおける名詞 e.g. アルバム）
  • AppEntity の設計ポイント
    • DisplayRepresentation：タイトル・サブタイトル・サムネイルを定義
    • 識別テキスト(displayRepresentation)は簡潔かつ過不足なく
    • 画像はサムネイルサイズで提供することで読み込みが早くなる

5:03 – Implementing a query

  • EntityQuery の実装：識別子から AppEntity を復元するロジック
  • IntentValueQuery で SemanticContentDescriptor のピクセルバッファから結果を返す
    • input: SemanticContentDescriptor から input.pixelBuffer を取得
  • 画像の類似度検索：Vision フレームワークの GenerateImageFeaturePrintRequest でオンデバイスで実現
    • 事前に計算済みの特徴プリントと距離閾値を使って高速に絞り込み
    • queryPrint.distance(to: entry.featurePrint) で距離を算出し maxDistance 以下のものを返す
  • パフォーマンス考慮
    • 特徴プリントは事前計算してキャッシュ（カタログ構築時に 1 度だけ実行）
    • 検索時は距離計算のみで素早く応答

8:18 – Opening results

  • 選択されたコンテンツに直接遷移する OpenIntent の実装
    • OpenIntent プロトコルに準拠し target パラメータに AppEntity を指定
    • perform() は軽量に保つ（アプリがフォアグラウンドになる際に実行されるため）
    • Visual Intelligence 専用の OpenIntent は作らず既存のものを再利用する

10:03 – Mac and iPad adoption

  • 同じ AppEntity・クエリ・OpenIntent を iPadOS と macOS でそのまま流用可能
  • プラットフォーム差異への対応
    • iOS：カメラ入力
    • Mac：スクリーンショット入力、ピクセルバッファが大幅に大きくなる
      • 処理前にリサイズを検討すること

12:27 – Returning multiple result types

  • @UnionValue 型で単一クエリから複数エンティティ型を返す
    • アプリは IntentValueQuery をひとつしか持てないため、代わりに各エンティティを並べてで定義できる @UnionValue enum を使用
    • アルバムエンティティとコンサートエンティティの両方を同時に返す例
    • ピクセルマッチだけでなく関連コンテンツも派生させると有益（e.g. アルバムアートワークで特定した同アーティストから近くのコンサートを検索）

12:56 – Continuing search in your app

  • すぐに検索結果が見つからない場合 semanticContentSearch スキーマでアプリ内の完全検索へ誘導（「もっと見る」）
    • @AppIntent(schema: .visualIntelligence.semanticContentSearch) を付与
    • perform() 実装でアプリの検索ビューに移動
  • 入力されたコンテキストに基づき、事前に検索が絞り込まれた状態でアプリの検索ビューが開く
  • フィルター・カテゴリ・より深いコンテンツへのランディングを提供できる

14:27 – System store integrations

  • Visual Intelligence がシステムストアにデータを書き込み、アプリはそれを読み取る
    • カレンダー：EventKit（EKEventStore）でイベントを読み取り
      • NotificationCenter（.EKEventStoreChanged）でストア変更を観察して自動更新
    • 連絡先：CNContactStore
    • 医療デバイス計測値：HealthKit（HKHealthStore）
  • 実装パターン（カレンダーの例）
    • 1. eventStore.requestFullAccessToEvents() でアクセス許可を要求
    • 2. predicateForEvents(withStart:end:calendars:) で検索範囲を指定
    • 3. イベントタイトルとカタログのアーティスト名を照合して関連イベントを抽出
    • 4. EKEventStoreChanged の通知を受けて再フェッチ

17:16 – Next steps

  • 2 つの統合ポイントのまとめ
    • Image Search：IntentValueQuery + AppEntity + OpenIntent
    • System stores：Event Kit・Contacts・Health Kit の変更通知を観察
  • iOS・iPadOS・macOS 共通のコードで対応可能

WWDC26：Debug and profile agentic app experiences with Instruments

Foundation Models で開発したエージェンティックな挙動のデバッグ手法。ツリー構造でツール呼び出しの内部的なプロンプトを詳らかにできるのは相当助かりそう。あと、タイムプロファイラの読み方も勘所が理解しやすかった。

Debug and profile agentic app experiences with Instruments

1:57 – LLM app development mindset

  • LLM アプリ開発特有の 3 つの課題
    • 確率的な出力：非決定的なレスポンスにより標準的なユニットテストが機能しない
    • モデル間通信：複数のモデルにわたるデータフローの調整が必要
    • オブザーバビリティ：マルチモデルパイプラインのどこで問題が発生したかを特定する難しさ
  • ツール呼び出しを含むループ、ステップが増えるほどレイテンシが増しと障害要員が増える

3:59 – Inspect and diagnose an agentic experience

  • デモアプリ：craft companion（ジャーナリングアプリ）
    • インタラクティブなブレインストーミング機能を持つ
    • 2 組の Dynamic Instructions を使用
      • GenerateCraftIdeaTool アイデア生成用
      • SwitchToTutorialModeTool チュートリアル作成用
    • いずれも Private Cloud Compute のサーバーモデルを使用

5:02 – Recording a trace with Instruments

  • Instruments でのプロファイリング手順
    • Foundation Models テンプレートを選択してセッションを記録
  • セキュリティ上の注意点
    • プロンプトなど機密データがトレースファイルに含まれるため取り扱いに注意

6:04 – Navigating the Instruments UI

  • Foundation Models インストゥルメントのレイアウト
    • タイムラインのトラックとレーン
      • instructions レーン：Dynamic Instructions の活動、指示とツールのセットがアクティブだった時間を示す（アクティブだったツールセットの個数を調べられる）
      • model inference レーン：各バーの色毎に推論の所要時間を表示
        • 黄色：システムが入力プロンプトの処理に要した時間
        • オレンジ：応答の生成に要した時間
  • ツリービューの階層構造
    • セッション → リクエスト → 推論 → ツールコール
    • 各レベルでのプロンプト・レスポンス・メタデータを確認可能
    • DynamicInstructions の toolsets に SwitchToTutorialModeTool を追加し忘れていたことが判明

12:07 – Performance metrics

  • LLM 体験のパフォーマンス計測に使う 3 つの主要指標
    • Time-to-first-token（最初のトークンが返るまでの時間）
      • プロンプトを短くすることで短縮可能
    • Tokens-per-second（全体的な生成速度）
      • プロンプト間でベンチマークを取って比較、リグレッション検出に使用
    • Total latency（全体のレイテンシ、ユーザーが最も体感する数値）
      • ストリーミングを活用することで部分的な結果を表示し、体感的な待ち時間を削減

WWDC26：Meet Core AI

Core AI を使ってオンデバイスに学習モデルの作成と改善のサイクルを回したり、オンデマンドにユーザーデバイス上でモデルをコンパイルできるらしい。そもそも、PyTorch から勉強したいと思った。

【入門編】PyTorchとは何か？インストールから実装までわかりやすく解説

Meet Core AI

0:33 – What is Core AI

  • Core AI は Apple Intelligence をオンデバイスで動かす推論フレームワークで、WWDC26 より開発者に公開
  • モデルデプロイのライフサイクル全体をカバー
    • モデルの最適化、コンバージョン、デバッグ、アプリへの統合の高速かつ反復的サイクルに対応
    • CPU・GPU・Neural Engineすべての Apple Silicon を活用
    • モダンな Swift API、Python ツールチェーン、専用デベロッパーツールを同梱
  • 主要コンポーネント
    • CoreAI Swift フレームワーク：アプリ側の推論実行
    • coreai-torch Python パッケージ：PyTorch モデルの変換
    • Core AI Debugger：数値デバッグ用スタンドアローンアプリ
  • 対応ニーズ例：話者分離モデル、カメラ映像をもとに質問へ回答、複雑なマルチステップタスク

4:57 – Model conversion

  1. モデル変換の手順
    1. PyTorchで行動予測モデルを試作
    2. ゲームを実行しトレーニングデータを蓄積
    3. PyTorchモデルをCore AIに変換（Core AI PyTorch extensions）：以下
  2. coreai-torch を使って PyTorch モデルを Core AI フォーマットへ変換する手順
    1. torch.export.export() でモデルをエクスポート、動的シェイプ（seq_len など）を指定
    2. run_decompositions() で Core AI 互換の分解テーブルを適用
    3. TorchConverter().add_exported_program() で Core AI グラフへ変換
    4. save_asset("SnakeTransformer.aimodel") で .aimodel ファイルとして保存
  3. 変換後の数値検証
    1. PyTorch の出力と Core AI の出力を numpy で比較し、最大誤差が 0.01 未満であることを確認

6:16 – App integration

  • 生成したモデルをアプリに統合→実行
  • Xcode のモデルビューアーで .aimodel を検査可能
    • 入出力のテンソル形状、関数名、サイズなどを確認できる
  • CoreAI Swift フレームワークの主要型
    • AIModel：.aimodel ファイルをロード
    • InferenceFunction：model.loadFunction(named:) で取得
    • NDArray：n 次元テンソルデータの入出力型
  • 推論の実行フロー
    • AIModel(contentsOf: modelURL) でモデルをロード
    • model.loadFunction(named: "main") で推論関数を取得
    • NDArray に入力データを書き込み
    • nextActionFunction.run(inputs:) で推論を実行し出力 NDArray を取り出す

10:48 – Profiling with Instruments

  • モデルのパフォーマンス改善
    • 例：時間経過と共に遅くなる問題の解決
  • Xcode に新設された Core AI インストゥルメントでモデルのレイテンシをプロファイル可能
  • Transformer モデルでシーケンス長が増えるにつれ、Key-Value の埋め込み再計算を実行する
    • → シーケンス長増大に応じて、推論時間が二次関数的に増大する問題
    • シーケンス各要素に計算済みの Key-Value キャッシュすることで解決

11:15 – Optimizing performance

  • KV キャッシュをステートフル入力として追加することで推論のスローダウンを解消
  • PyTorch 側の変更
    • register_buffer() でキーキャッシュ・バリューキャッシュをモジュールバッファとして登録
    • forward() でキャッシュの読み書きを実装
    • 再変換時に state_names=["keyCache", "valueCache"] を指定
  • Swift 側の変更
    • NDArray としてキャッシュバッファを確保し ModelPlayer の保存プロパティとして保持
    • InferenceFunction.MutableViews にキャッシュの MutableView を挿入して推論時に渡す
      • stateViews.insert(&keyCache, for: "keyCache") のように記述

14:13 – Additional features

  • coreai Python パッケージのリッチなオーサリング体験
    • 既存の変換・最適化 API に加え、モデルグラフの細粒度な操作が可能
  • Core AI Debugger
    • 変換済みモデルの数値デバッグ専用ツール
    • 中間テンソル出力の検査、PyTorch との差分確認
  • Xcode のデバッグゲージ
    • Xcode でアプリを実行中に Core AI の活動状況をリアルタイムにストリーミング監視

15:34 – Specialization

  • モデルの特化プロセス：Core AI がターゲットデバイス向けにモデルをコンパイルする処理
    • 初回ロード時に実行され、以後はキャッシュから即時ロード
    • かなり時間がかかる場合があるため、ユーザーフローの計画が必要
  • プログラム的なキャッシュ管理
    • AIModelCache.default でキャッシュの有無を確認
    • キャッシュがない場合にユーザーへ「AI 機能を準備中」と通知する UX パターン
    • AIModel.specialize(contentsOf:) で明示的にスペシャライゼーションを要求可能
  • SpecializationOptions でコンパイル動作をカスタマイズ
  • 特化で起こる2段階の変換
    • Compilation：コンピューティングを分割、計画し最適化
    • Excecutable generation：使用する計算ユニット向けのアーティファクト生成（デバイスとOSバージョンに紐付けられる）
  • Compliation ステップが大部分を占める → Core AI ツールチェインの事前コンパイル（Ahead-of-time, AOT compilation）で解決