2025年7月 – ページ 3 – long forgotten now…

Foundation Models は追加学習できるらしい

Foundation Models について、セッションメモや実践についていくつかまとめてきた。

これらを通して筆者は、Foundation Models のコンセプトは Apple の用意したモデルを受動的に使うもので、追加学習する方法は提供されていないものだと理解していた。実際、Foundation Models の API には、外部情報と連携する tool calling の仕組みはあっても、モデルをファインチューニングする手段は提供されていない。

それが、先日参加した WWDC25 Recap イベントにて、近くの方から「できる」という情報をいただいて驚いた。その後、Apple の Technology Evangelist の方にも確認したところ、やはりできるとのこと。以下のページにその手順がまとまっていると教えてくださった。

Foundation Models adapter training – Apple Intelligence – Apple Developer

Adapters are an advanced technique that *adapt* a large language model (LLM) with new skills or domains. With the adapter training toolkit, you can train adapters to specialize the on-device system LLM’s abilities, and then use your adapter with the Foundation Models framework.

トレーニングには Adapter training toolkit なるものを用いるらしい。ローカルマシンと Python コードでトレーニングし、別途 Entitlement をリクエストする必要がある。また、マシンスペックもメモリ32GB以上とそれなり。事前学習させたモデルをアプリに組み込むので、例えばユーザー生成コンテンツをもとに Foundation Models のレスポンスを生成することはできないだろう。

Foundation Models は OS と共にバージョンアップされ続けるが、聞いた話ではその都度学習がリセットされ、その度に再学習させ直す必要があるとのこと。

ちなみに、このアダプターについてはセッション内に言及あったようで、それをいちからビデオを見直して探すのは大変なので、これまで見たセッションの transcript を溜めていたフォルダから Cursor に探させた。その答えが以下。

「Meet the Foundation Models framework」セッション

該当箇所: 3:47〜3:57付近

内容要約:

「特定のユースケース（例：コンテンツタグ付け）向けに、モデルの能力を最大化するためのspecialized adapters（専用アダプター）を提供している」と明記。

さらに「今後もモデルを継続的に改善していく」と述べており、アダプターを使った拡張性やカスタマイズ性に触れています。

原文抜粋:

> For certain common use cases, such as content tagging, we also provide specialized adapters that maximize the model’s capability in specific domains.

ついでに ChatGPT o3 に解説させた。

https://chatgpt.com/share/686d278b-cf78-8005-a273-061117f3d216

WWDC25：Create icons with Icon Composer

前回に続き、新たなアイコンデザインを出力するための Icon Composer の使い方。視覚的効果や配色は Icon Composer で完結。デザイナーがこのツールにキャッチアップするのももちろん良いが、開発者も触ってみてどのような調整が可能かを理解するのも重要そう。

0:51 – Overview

アイコン作成の歴史的変遷：従来は様々なサイズで作成が必要だったが、解像度向上によりひとつの解像度で完結するよう簡素化
2025年、ダークモード・ティントモードの拡張により、再度プロセス簡素化の転換点
Icon Composer により、1つのファイルで全てのプラットフォーム・外観に対応可能
- 図解的、複雑なアイコンは従来通り個別画像でXcodeにアップロード可能：鏡面ハイライトが自動適用
よりグラフィックなアイコンは Icon Composer で Liquid Glass の新機能を活用可能
- アートワークひとつから、各プラットフォームで一貫したデザインが提供可能
- 動的なグラスプロパティを活かした、リアルタイムな見た目の確認
- 6種のアピアランスのチェック（Default, Dark, Clear light/dark, Tinted light/dark）

3:55 – Design

ベクターツール（SVG出力可能）の使用を推奨
Apple Design Resources からアイコンテンプレート（Figma、Sketch、Photoshop、Illustrator対応）をダウンロード
- iPhone、iPad、Mac は 1024px、Watch は 1088px のキャンバスサイズ
- グリッドは共通、デザインの流用が容易
レイヤー設計：Z深度で背景から前面へ積層、色分けも重要
- レイヤー分け、色分けをしておくと、Icon Composer でコントロール可能な幅が広がる
- 例：Translate アイコンでは吹き出しとテキストを別レイヤーに分離 → レイヤごとのぼかし・影を、鏡面、透過度／不透明度と同様に、動的プロパティで設定
グラフィックエッセンスを重視（フラット、不透明、制御しやすい状態）

6:10 – Export Layers

レイヤーをSVG形式でエクスポート（Z順で番号付けしネーミング）
Illustrator 用のレイヤー → SVG自動変換スクリプトを提供。
背景色・グラデーションは Icon Composer で直接追加するためエクスポート不要
テキストはアウトライン化してからエクスポート（SVGではフォント維持できない）
カスタムグラデーション・ラスター画像はPNG形式でエクスポート（透明な背景も維持可能）
角丸矩形・円形マスクは含めない（後で自動トリミングされるため）

7:22 – Icon Composer

3つのパネル構成：左側（キャンバス・グループ・レイヤー）、中央（プレビュー）、右側（インスペクター）。
背景色設定：システムプリセット（最適化済み）またはカスタム色・グラデーション
グループ：最大4つまで（視覚的複雑さの適切な範囲）
外観モード：Default、Dark、Mono
Liquid Glass プロパティ：レイヤーレベルとグループレベルで制御可能
プロパティ設定：外観別・全体共通の設定が可能
- Color
- Composition
- モードを跨いで一貫性を保つために予備設定してあるが、詳細コントロールも可能
シャドウ：Neutral（汎用）とChromatic（色付き）から選択
- CHromaticで、素材の明るさや物理特性が際立つ
Dark モード：フィル・不透明度・ブレンドモードの調整で最適化
Mono モード：少なくとも一番目立つ／みやすい要素を白に設定
プラットフォーム間調整：Watch 用の円形と他の角丸矩形の光学調整
- Composition で円形に合うよう見た目の調整

13:16 – Delivery

.icon ファイルとして保存し、Xcode にドラッグ&ドロップ
プロジェクトエディターでアイコンを選択
ビルド・実行でプラットフォーム・外観への適応を確認
Icon Composer はベータ版で提供、Feedback Assistant でフィードバック可能

聴講メモ：WWDC25 Recap – Japan-\(region).swift

昨日に続き、WWDC25 Recap イベントへ @Apple Japan。全国５会場を繋いでのLT10本立てで、多岐にわたるテーマが並び充実した時間だった。各拠点の盛り上がりが映像を通して伝わったのも温もり感じられて良かった。また、Twitter でアイコンは知っているが面識なかった方々とお会いでき、懇親会含めてちゃんとお話できたのが嬉しかった。

Liquid Glass を Metal で再現するテーマで、登壇者の方がガラスルーペなるものを購入され（Apple のデザインチームと同様に）実際に見え方を自身の目で試されていたのが、非常に良かった（筆者もその場で注文した）。

あと Foundation Models について、追加学習はできないものだと思い込んでいたが、Adapter training という手法を用いることで可能なことを参加者の方に教えていただいた。これは試してみよう、、

イベントページ：https://japan-region-swift.connpass.com/event/353002/

Liquid Glass を Metal Shader で描きたいだけの人生だった…

temoki さん

実際にガラスルーペ買って再現してみた
Alan Dyeの言葉 → それってMetalのこと？
作ってみた
layerEffect modifier を使う
光の屈折を distortion effect で実装
他にも、、
- 光の反射のハイライト
- ガラスの種類
- 液体のような近接形状の融合
- 背景ブラー
大変なので、Gemini CLI、liquid_glass_render に頼る
Metal への移植を Gemini にやってもらった
- Metal の Geometry Functions に Liquid Glass 向けっぽい関数（物理ベースのレンダリングが必須）
- アーキテクチャをドキュメント化してもらった
Demo

動画エフェクトに関する新技術の紹介

ShomaKato さん

聴講メモ：MOSA2025：夏のTech Dive! Follow WWDC25

昔から一度参加してみたかった、MOSA主催のイベントにようやく参加することができた。しかも会場は Apple Japan。今年2月にも、大阪でMOSA主催のイベントがあり、粒揃いのセッションテーマの中でも特に「キューティマスコットを作り直してみる」という二度とはお目ににかかれないセッションは是非拝聴したく大阪に飛ぶ覚悟もあったのだが、予定が被り叶わなかった。

全体を通して牧歌的（？）で、思い思いに技術や未来予想（妄想？）を語らう空気感がとても心地よかった。筆者が福岡時代によく通っていた Apple Users Group や、各地で開催されていた AUGM の雰囲気を思い出して、懐かしくもあった。

今回はWWDC25のフォローアップイベントということで、特に Liquid Glass のテーマが多く取り扱われていたが、その他さまざまなアップデートについても多面的に取り扱われていた。今回、大谷さんのキーノートのために参加応募したようなものだったが、Apple プロダクトの歴史を遡った上で、今回の Liquid Glass というデザインシステムのアップデートから Apple の今後を説かれており、非常に説得力があった。浮遊するUIマテリアルに関しては個人的にも、（グラス型に限らず）フォルダブルなど多様なデバイス環境を予期したものだろうと思っていたが、、グラス型にフォーカスして語られるともはや、その布石であるとしか思えなくなってしまった。しかも WWDC25 という発表タイミングは、グラス型登場の前仕込みの段階であるという推測も、、Apple やその歴史を熟知されている大谷さんだからこその見解で、目から鱗だった。

Apple 豊田さんからの Recap セッションは、ひととおりセッションビデオを観た上でもなお有用だったし、Liquid Glass の解説については先の大谷さんのセッションと並べて聞けたことも幸運だった。

他にも、Yoshikawa さんによる Claude Code によるいわゆる Vibe Coding の実践談は手法が具体的で、取り入れるイメージが湧いたし（Cursorメインで使っている）、いけださんによる Foundation Models のデモでは、筆者も実践しながら再現性をなんとなく感じていた＜ローカライズはプロンプト言語に依存＞＜ただし出力言語が一定しない（説）＞を裏付けてくださり、興味深かった。

中野さんの発表に被せるかたちで、iPad の Full screen 対応や Liquid Glass 対応のリミットに関して Apple 豊田さんによる追加補足があり、Xcode 26 の次のバージョン以降では猶予がないという温度感だった。現実的に、開発者としてはその猶予は数年は伸びそうだと思いたいのだが、、

しかし本日さまざまな登壇者が言及していたように、Liquid Glass の目指す方向性はその見た目の「新しさ」ではなく、将来登場する新たなフォームファクタ含め、多様なデバイスに対し、いかにソフトウェアやコンテンツを溶け込ませるかにあると考えている。なので、開発者が Liquid Glass への移行を余儀なくされるのは、その見た目が古いかどうかではなく、新しいデバイス上では使い勝手が悪いから、という理由で対応圧が迫るのではないかと予想する。

イベントページ：https://mosa.connpass.com/event/354216/

Liquid Glassから見えるAppleの未来戦略

なぜLiquid Glassのアイコンの丸みはデバイスに合わせてあるのか？

大谷和利 さん

小さいことに見えて未来戦略から見ると大きいのでは？
デジタル環境と現実との折り合いの付け方：その最新成果だと言える
- Liquid Glass は visionOS 26 には採用されていないのはなぜか？
- Alan Dye「ハードウェアとソフトウェアを緊密に統合する」
- 年代別の統合の変遷
  - OS + ソフト + ハード（’80-’90）
  - → サービス（’00）：iTunes, iCloud, Apple Music
  - → シリコン（’20）：Mチップ
  - → 現実の統合（24~）
- UIの変遷
  - スキューモーフィズム（現実の模倣）
    - コンピュータを身近に感じさせる
    - GUIの歴史：比喩を使うことで、使い方が最初から分かる
  - フラットデザイン（現実との線引き）
    - ユーザーがデジタル環境に慣れ、画面の中だけでの完結
    - ユーザーも進化した
  - Liquid Glass（現実との融合）
    - Rを同じにした。装置と画面内との境界線を意識状で無くしていくポリシーが含まれているのでは
    - Vision Pro では現実と仮想の区別がそもそもつかない
    - それ以外はデバイスを手にするので現実仮想が区別される → Rを一致し（透明にし）一体化させることで意識状は現実と仮想の境界をなくし融合する、のではないか。
  - 半透明表現やグラスモーフィズムは、これまでも段階的に取り入れられていたが、本質的に異なる（e.g. Control Center）
    - 透明度が高いだけでなく、場所を取らないようにしている（従来的なMax幅表現でなく、寄せることで背景コンテンツの存在を多く見せている）
    - → UIがコンテンツを邪魔しない：意識の上で透明化していく
      - Vision Pro だと現実の風景
  - Alan Dye「（ガラスの工学的特性と）Appleにしか実現できない流動性を組み合わせ」
    - 他社プラットフォーム上の模倣はあくまで静的なもの、本質的な模倣ではない
    - Liquid Glass
      - 物理法則に従う、すべてに実体がある感覚（Appleは「素材」と表現）
      - 従来の拡散だけでなく、反射や屈曲もシミュレート
      - Liquid Glass の動き自体で情報を見せている
      - 背景が透けていることが重要：今は画面上だが、Vision では現実世界。そこに「素材」が浮かんでいる見せ方
      - visionOS 26 で組み込まれていないのは、まだ煮詰めができていない？隠し球になっている？
    - Material 3 Expressive
      - スケール・高さ・空間の変化に軸足を置く構造的な情報設計、動きが構造の理解を助ける。フラットをベースに奥行きと触覚フィードバックで補助
      - Expressive（表現力）を売り
      - 例：壁紙カスタマイズ機能
        
        カスタマイズ、パーソナライズの多様性
        
        天気エフェクト：現実の天気と同期するわけではない、現実とデバイスとが分離する（Appleはこれはやらない）
  - Alan Dye「将来の新しい体験を生み出す基礎」
    - visionOS 表現がヒントになったが、visionOS に採用しているわけではない
    - 固定的デバイスよりも考えることが多くあり、実現に至っていない、その段階で他社に模倣されることを避けるために隠し球としている？
    - なぜトランスルーセント？→ より多くのコンテンツを見せるため（Visionなどグラスデバイスでは、現実世界）UI の主張が強いと、その先のものを隠してしまう。
    - Android XR のライブデモ
      - 準備中にヘッドバンド部分を擦っていた：タッチコントロールがありそう
      - 現段階では、UI が単なる透明かつ枠付き（ほとんどデザインされておらず、情報をそこに表示しているだけ）
      - Material 3 Expressive とは関係ないつくり、UI がまだ固まっていなさそう
    - Apple は、かならず来たるグラス型デバイスを、Mac や iPhone ユーザーが迷いなく使えるよう準備している、今のうちから現実との融合を図る新しいデザイン基盤に慣れてもらうための仕込みが Liquid Glass と思われる（視界を遮るUIにはならないだろう）
    - M3 Expressive は主張を強めてしまい、XR では暫定的な作りになっている可能性
  - デバイスの進化の方向性
    - Jonathan Ive：OpenAI とのプロダクト開発。
      - 自らの過ちはスマートフォンを作ったこととする内省。みなスマホばかり見ている。
      - → スマホ漬けから人々を解放するために（グラスではなく）ポケットのなかに入れたまま使えるものを開発
    - Apple Glass は、AirPods や Watch と併用により、最大限機能活用できるだろう
      - ソーシャルメディアを追うデバイスにせず、周辺デバイスと分散的に機能を補い合い、スマホ漬けから脱却する
      - Liquid Glass の発表により、登場は近いだろう
      - Android XR は Gemini によるアプリ間連携できるが、Siri ではできない：WWDC25で Siri Shortcuts などでのアプリ関連系の補強が発表された

WWDC25 Recap

Apple WWDR Design Evangelist 豊田さん

WWDC25：Say hello to the new look of app icons

Liquid Glass に対応したアイコンデザインについて。「等間隔になった」デザイングリッドについて、たしかに以前はそうでなかったことを思い出した。レイアウトがしやすくなりそう（どれだけのデザイナーが従来のグリッドを尊重してデザインしていたかは不明だが、、）これまで自社アプリはダークテーマにも対応できてない状態だったが、強制的に Liquid Glass の視覚効果が与えられることによって従来のままではやや不恰好に見えてしまっている。Icon Composer も用意され、これを機に自社他社問わず、放置されていたアイコンの最適化が促進されるかもしれない。

0:00 – Intro

visionOS のレイヤーアイコンと実際のガラス特性を研究して生まれた「Liquid Glass」マテリアル
エッジハイライト、曇り(frosty)、透過性を組み合わせて奥行きと内側からの照明効果を実現
iOSホーム画面ではジャイロ入力に基づいて光が動き、周囲の世界を反射しているような感覚
新しい外観モード：
- モノクロガラス（ライト・ダーク）
- ティントモード（ダーク・ライト）
  - ダーク：前傾にカラー
  - ライト：背景ガラスにカラーが注入
全ての外観モードが iPhone、iPad、Mac で利用可能。Apple Watch でもライトモードアイコンが更新された外観で表示
App Store 商品ページでも更新されたアイコンが反映

2:20 – Design System

統一されたアイコン言語により、デバイス間でのデザインが容易になった
角丸四角型 (macOS, iOS)：1024px キャンバスで、よりシンプルで均等に配置され余裕のあるデザイングリッド、より同心円状で丸い角半径
- macOS では従来、アイコン形状から一部はみ出すケースがあった
- 形状がキャンバス形状がマスクとして機能し、不規則な形状を回避
- 既存のアイコンは自動的にリサイズ、マスクまたは拡張されて、新しいマテリアルを適用
円型 (watchOS)：1088px キャンバスで、角丸矩形よりも広く、プラットフォーム間の一貫性を実現しやすい
新しいテンプレート（Figma、Sketch、Photoshop、Illustrator対応）をApple Design Resourcesで提供

5:18 – Drawing Icons

レイヤリング：背景と前面レイヤーの基本構造、複数レイヤーの積層で奥行きを表現
- 1枚の背景レイヤーと、1枚以上の前面レイヤーで構成可能
  - Messages: 背景1枚、前面1枚
  - Podcasts: 背景1枚、前面3枚として立体感ある奥行きを実現
シンプルさの重視：複雑な3Dオブジェクトや遠近法は避け、フロントビューとフラットな外観を推奨 (e.g. Chess)
透過性：新しいマテリアルでの透過性とブラー効果で軽やかさと奥行きを追加
「少ないほど良い」原則：重複を減らし、Liquid Glass の効果を活かす（透明感、レイヤーごとの影やスペキュラハイライト）e.g. Photos
レイヤーの数を減らし、形状に丸みを持たせ、視覚的効果を削除 → Liquid Glass の処理にゆだねる (e.g. Home)
細部の配慮：鋭いエッジや細い線を避け、丸い角を使用して光の流れを滑らかに → 要素端の光の動きが滑らかになる (e.g. Settings の歯車)
背景：ソフトな明暗グラデーションに加え、白黒背景の代わりに使えるシステムライト・ダークグラデーションを用意
- グラデーションは、上から下に、明 → 暗
- 色付き背景を推奨。ライト・ダークモード間の区別を明確にできる

WWDC25：What’s new in SF Symbols 7

SF Symbols アップデート。もはや高機能すぎて数年前から使いこなせる気がしていない、、が Draw 機能によって、ものによっては Lottie に依存する必要がなくなったかもしれない。グラデーションもシンプルながら表現力を底上げできるので嬉しい。

2:19 – 描画（Draw）

新機能「Draw」追加。手書き風アニメーションでシンボルをパスに沿って描画
Draw On（登場）と Draw Off（消失）の2つのアニメーションプリセット
- それぞれ既存の再生オプションをサポート
  - By Layer：デフォルト、レイヤーごとに開始時点が異なる
  - Whole Symbol：すべてのレイヤーをまとめて描画、各パスのアニメーションが同時開始終了し、素早い
  - Individually：新しいオプション、レイヤーごと逐次的にアニメーション実行する
シンボルごとに描画方向を柔軟に設定可能（例：左右、中心から外など）
複雑なシンボルもサポート
- 例：矢印の矢を遷移沿って移動させる
Variable Draw（進捗や強度を描画で表現）も新たに追加
- 例：ダウンロードやワークアウトの進捗、温度計
- SF Symbols app で確認可能

6:02 – マジック置換

Magic Replaceが強化され、関連シンボル間のアニメーション遷移がより滑らかに
同じエンクロージャ（囲い）を持つシンボル間で、囲いを維持しつつ他の部分を置換
Drawアニメーションと組み合わせて、より表現力豊かな遷移が可能に

7:01 – グラデーション

シンボルにグラデーション（線形グラデーション）を適用可能に
- 光が当たっているような印象を与えられる
すべてのレンダリングモードで利用可能
特に大きなサイズで立体感や奥行きを強調したい場合に有効

8:02 – カスタムシンボル

カスタムシンボルにもDrawやグラデーションなど新機能を活用可能
Drawアニメーションには「ガイドポイント」を描画パス上に配置して描画経路を指定（パスに少なくとも２つ必要）
ガイドポイントには開始点・終了点に加え、中間点を加えて複雑なパスを構成する
ガイドポイントには複数種類があり、複雑なパスや複数サブパスにも対応
- 複数のサブパスで開始・終了点を共有
- コーナーポイント：急カーブや鋭い角に特別な処理が求められるため指定
複数パスが存在する場合は、それぞれに描画パスと方向のルールセットを指定
中心からアニメーションする場合、双方向描画をアノテート
- 開始点の両側にガイドポイントを配置するとシステムが自動的に双方向性を認識する
適応型（addaptive）エンドキャップ
アタッチメント（例：矢印の先端）も火病が要素としてガイドポイントに紐付けてアニメーション可能
重なり合うパスや複雑な形状にも柔軟に対応するための詳細設定が用意
カスタムシンボルは Regular、Ultralight、Black の3つのウェイトでガイドポイントを設定すれば、他のウェイトは自動補間される
- Regular 以外でガイドポイントが不正になった際調整が必要、その時ガイドポイントの順序に注意（ポイント番号を表示可能）
可変描画（Variable Draw）もカスタムシンボルで利用可能

20:52 – 新しいAPI

SwiftUIでは symbolEffect モディファイアで Draw アニメーションを適用
- .symbolEffect(.drawOn, isActive: isHidden)
- .symbolEffect(.drawOn.indicidually, …)
AppKit・UIKit でもDraw On/Off を指定してアニメーション可能
Variable Draw やグラデーションも API で簡単に指定可能
- .symbolVariableValueMode(.draw)
- .symbolColorRenderingMode(.gradient)
コード例は SF Symbols アプリの「Copy Code」ボタンから取得可能
新機能を活用するには SF Symbols 7 ベータ版のダウンロードと、カスタムシンボルの再設計・注釈付けが推奨

WWDC25：Explore large language models on Apple Silicon with MLX

以前 Foundation Models framework を実際に使ってみたという投稿をした。

Foundation Models framework の最大のメリットはオンデバイスのLLMを非常に手軽に扱えるという点だが、一方で高度な推論に不向きであったり、独自データによる追加学習といった高度なユースケースには~~対応していない~~ → できるらしい。（追記: 2025/07/08）オンデバイスかつ手軽に追加学習を行いたい場合には、このMLXを使えばよさそう。

0:00 – イントロダクション

MLX は Apple Silicon 向けに設計されたオープンソースの機械学習ライブラリ
Apple Silicon 上で大規模言語モデル（LLM）の推論とファインチューニングを実行可能
Metal を使用して GPU で高速化し、統一メモリを活用して CPU と GPU が同時に同じデータで動作可能
Python、Swift、C++、C の API を提供
DeepSeek AI の6700億パラメータモデルを4.5ビット量子化で380GBのメモリを使用して実行可能（M3 Ultraの512GB統一メモリを活用）

3:07 – MLX LMの概要

MLX LM は MLX 上に構築された Python パッケージで、大規模言語モデルの実行と実験に特化
コマンドラインツールを提供し、コードを書かずにテキスト生成やファインチューニングが可能
Python API も提供し、生成やトレーニングプロセスなど詳細な制御を実装可能
Hugging Face と密接に統合されており、数千のモデルをダウンロード可能
インストールは pip install mlx-lm で簡単

3:51 – テキストの生成

コマンドライン:
- mlx_lm.generate コマンドで Hugging Face のモデルまたはローカルパス、テキストプロンプトを指定して生成
- サンプリング温度、top-p、最大トークン数などのフラグで動作を調整可能
- mlx_lm.generate —help
Python API:
- load 関数でモデルとトークナイザーを読み込み、設定
- generate 関数でトークン生成ループを実行し、出力テキストを返す
- モデルは完全に構造化された MLX ニューラルネットワークで、層の構造やパラメータを検査・修正可能
  - print(model)
  - print(model.parameters()) で学習した重みづけを確認
会話の維持:
- Key-Value Cache（KV Cache）を使用して複数ターンの会話を中間結果として維持
  - キャッシュを再利用し、時間と処理を節約、マルチターンの会話に有効
- make_prompt_cache 関数でキャッシュを作成し、generate 関数に渡すことで履歴を保持

8:42 – 量子化

目的: モデルの精度を落とすことでメモリ使用量削減と推論速度向上（多くは品質に影響しない）
MLX LMの利点: 量子化が組み込まれており、追加ツールや変換スクリプトが不要
使用方法:
- mlx_lm.convertコマンドで Hugging Face からモデルをダウンロード、変換、ローカル保存を1ステップ実行
- 例: 16ビットMistralモデルを4ビットに量子化して大幅にサイズ削減
Python APIでの細かい制御:
- quant_predicate を使用。例: 埋め込み層と最終投影層を6ビット、その他を4ビットに設定可能
  - 最後の埋め込み投射層は量子化の影響を受けやすいため高精度を維持したい
- 品質と効率のバランスを最適化

11:39 – ファインチューニング

目的: 大規模言語モデルを特定のドメインやタスクに適応させる
MLXの利点: クラウド不要でローカルMac上でファインチューニング可能
- 外部で実行するコストがかからない
- データがデバイスから出ない
2つのアプローチ:
- 完全ファインチューニング: 事前学習済みモデルの全パラメータを更新。最大の柔軟性だがリソース消費量増える
- 低ランクアダプター（LoRA）: 少数の新しいパラメータを追加し、元のネットワークを凍結したままそれらのみをトレーニング。高速、軽量、メモリ効率的
実装:
- mlx_lm.lora コマンドでひとつでファインチューニング開始
- 量子化されたモデルのアダプタをトレーニング可能（メモリ使用量を劇的削減）
- 設定ファイルで学習率、オプティマイザー設定、評価間隔などを細かく制御
アダプターの融合:
- mlx_lm.fuse コマンドでアダプターをベースモデルに融合
- 単一の自己完結型モデルを生成し、配布と使用が容易
  - --upload-repo に Hugging Face のリポジトリ名を指定するだけでアップロード可能

17:02 – MLXSwiftでのLLM

Swiftでの実装: 例: 28行のコードで量子化Mistralモデルを読み込み、テキスト生成を実行
主要コンポーネント:
- ModelContainer: モデルとトークナイザーへの並行アクセスを安全に管理するアクター
- プロンプトのトークン化
- 生成ループの実行
会話履歴の維持:
- Key-Value Cacheを明示的に作成。
  - GenerateParameters の生成
  - キャッシュの抽出
  - TokenIterator を使用して生成をステップバイステップで制御
利点: Pythonと同じワークフローと機能を、Swiftで完全にネイティブに実現

WWDC25：Explore spatial accessory input on visionOS

visionOS 26 におけるスタイラスやゲームコントローラへの対応について。コントローラには興味なかったが、近い将来 Apple Pencil が 6DoF 対応し、Vision Pro でも利用可能になる伏線と見てチェックした。

実は、XRコンテンツにおけるコントローラ／ハンドトラッキングの是非については過去にも（当時）Oculus Quest での体験をもとに考察したことがあった。

Oculus: ハンドトラッキングに感じる課題

パススルーしない没入型VRコンテンツ内において、コンテンツへ対しての触覚やグリップ感を違和感なく表現するにはコントローラが優位だと考えた。ハンドジェスチャーにはその正確さや、触覚を伴う繊細なフィードバックに限界があるので（コントローラ一辺倒な体験設計は好ましくないだろうが）空間アクセサリを伴うユースケースの充実に期待したい。

0:00 – スタート

visionOSでは「目と手」による入力が基本だが、より細かい制御、ボタン入力、触覚フィードバックを可能にする空間アクセサリのサポートを追加。
サポートされるアクセサリ：
- PlayStation VR2 Sense controller: ゲームに適したボタン、ジョイスティック、トリガーを搭載。標準ジェスチャー（タップなど）でシステムナビゲーションも可能
- Logitech Muse: 先端とサイドボタンで可変入力が可能なフォースセンサーと強力な触覚フィードバックを搭載。生産性・クリエイティブアプリに適した精度
アクセサリは full space アプリ、shared space アプリの両方で使用可能。
Apple Vision Proのカメラとアクセサリのセンサーを組み合わせて位置と回転をトラッキング

2:41 – 彫刻アプリの構築

セットアップ:
- Xcodeの機能エディタで「Spatial Gamepad」にチェックを入れて空間ゲームコントローラーサポートを追加
- アプリのplistで「Accessory Tracking Usage」の説明を記述（例：「Tracking accessory movements to carve into virtual clay」）
アクセサリの接続:
- GameController フレームワークを使用して空間アクセサリとの接続を検出
- GCController（ゲームコントローラー）と GCStylus（スタイラス）の両方がGCDevice プロトコルに準拠。
- 接続・切断イベントをリッスンし、productCategory が「Spatial Stylus」または「Spatial Controller」かどうかを確認
仮想コンテンツの表示:
- full space / shared space 両方で使え、プライバシー保護のため認証されたアプリのみ動き追跡可
- AccessoryAnchoringSource を作成し、アクセサリの「aim」位置にターゲット
- AnchorEntity を作成し、accessory ターゲット、aim 位置、トラッキングモードを指定
- トラッキングモード：
  - predicted: 低遅延だが急激な動きでオーバーシュートする可能性。
  - continuous: 高精度だが高遅延
インタラクションの実装:
- SpatialTrackingSession に .accessory を追加してアクセサリの AnchorEntity のトランスフォームを取得。
- 実装例
  - アクセサリが粘土に入った時に素材を削除し、触覚フィードバックを発生

13:37 – ARKitによるアクセサリのトラッキング

ARKit AccessoryAnchorの4つのプロパティ：
- handedness: アクセサリを握っている手（左/右）
- relativeMotion: 空間内での相対的な動き。
- relativeRotationalMovement: 空間内での相対的な回転運動。
- trackingState: トラッキング品質（センサーやカメラのカバレッジが低下すると品質も低下）
RealityKitとARKitの連携:
- SpatialTrackingSession が実行中で設定されている場合、RealityKit AnchorEntity から ARKit AccessoryAnchor を取得可能
- AnchorEntity の ARKitAnchorComponent にアクセスし、ARKitAnchorを取得して AccessoryAnchor にキャスト
リアクティブツールバーの表示:
- アクセサリアンカーからheld chirality（利き手）を取得。
- 左利きの場合は正のX方向、右利きの場合は負のX方向にツールバーを表示

14:45 – デザインに関する考慮事項

UIとの相互作用:
- ビューにゲームコントローラー入力（ボタンやトリガー）をジェスチャーの代わりに受信するよう指示可能
- 標準の手ジェスチャーとゲームコントローラーの両方を入力として処理可能
- SwiftUIビューで .receivesEventsInView 修飾子を設定してジェスチャーイベントも受信
没入感の向上:
- 完全空間アプリでは .persistentSystemOverlays APIでホームインジケーターを非表示
- .upperLimbVisibility APIで上肢とアクセサリを非表示
適応的サポート:
- 空間アクセサリと手の両方に対応することで、より多くのユーザーをサポート
- ARKit は今年さらに高速で手をネイティブトラッキング
App Store バッジ:
- 「Spatial game controller support」: 空間アクセサリトラッキング付きゲームコントローラーをサポート
- 「Spatial game controller required」: 空間アクセサリトラッキング付きゲームコントローラーが必須

2025年7月
月	火	水	木	金	土	日
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30	31