月: 2025年8月

OS 26 beta 5 の Foundation Models framework アップデート内容

Foundation Models の開発者からこんな投稿があったのでチェック。

  • ガードレイルに permissiveContentTransformations オプションが追加
    • 要約やスタイル調整といったユースケースにおいて原文にセンシティブなトピックを含む可能性があるケースを想定（政治記事など）
    • 含んでいてもテキスト応答にへ関することを許容し、LanguageModelSession.GenerationError.guardrailViolation エラーを投げないガードレイル設定
    • permissiveContentTransformations | Apple Developer Documentation
  • 新しい「拒否」エラーの追加
  • #Praiground 使用時にフィードバックボタンを追加
    • Xcode 上で直接、モデル動作に関するフィードバックを送信可能に
  • GeneratedContent を透明化（“no longer opaque”）
    • GeneratedContent.Kind が追加され、任意の生成コンテンツを表示するビューの構築が可能
    • プリミティブ型、配列、構造化オブジェクトを含む、JSON互換のデータ種類を表す
      • .array([GeneratedContent]), .bool(Bool), .number(Double), .string(String), .structure(properties: [String.: GeneratedContent], orderedKeys: [String]), .null
    • ユーザーが設定可能な生成スキーマの取り扱いに有用
  • 推論スタックの最適化が含まれており、トークンの処理速度が向上

聴講メモ：SPARKS #1 – AR/AI Glass Hands on!

MESONさん主催の新企画・XR/空間コンピューティング系ミートアップの第1弾が開催されたので参加してきた。

イベントページ：https://meson.connpass.com/event/362171/

今回特に期待していたのは、トークセッションやクリエイターLTも然ることながら、さまざまなARグラスが集結し、体験できるというハンズオンが設けられているということだった。特にここ最近はAR系の新製品が目まぐるしい勢いで登場し、それぞれが高額なのもあってまったくキャッチアップできていなかったので、大変ありがたかった。

共催４社の代表４名によるトークセッションは、AI時代におけるARデバイスのありかた、HMDとグラス型との対比に関するトピックが主軸。（以下、４名の登壇者の発言が混在しているので、どんなトピックが話されたかの参考程度）

最近注目しているグラスデバイス

  • Even G1
    • １日中着用可能、Apple Watch をつけなくなった、食事中スマホ見なくなった
    • デフォの時計：商談中コミュニケーションが分断しない
    • 通知、時計機能メインで利用
      • マイク x AI の機能はあるが、使ってない
      • デフォルトは精度高くない、3rd Party がアプリ開発可能
    • Even G1 のような AR グラスは、カメラ相性が良さそう
      • 視界のコンテクストを共有できることが重要、言葉で説明せず指示語が使える
  • XREAL One Pro
    • ディスプレイ使用。視野角狭いことでかえって目の前の作業に集中できる
    • 映像で使うシーンがライフスタイルにない
      • これから出てきそう？
  • カメラの要不要はデバイス将来を決定づける分岐点
    • マイクスピーカーだけで良いか、映像含めたマルチモーダルか、まだ未知数
    • AIの精度を上げるためには、コンテクストとしての映像、カメラが必要
    • 気づかないものにAIが先に気づいてヒントを与えてくれる世界（ゼルダの妖精）
    • AIのパーソナル化、パーソナルアシスタントとしての機能性
      • データ量が重要、ユーザーどこでなにをしたか、AIグラス経由でスキャンできることで収集

HMD vs Glasses

  • HMD は「やるぞ」のモードが必要 → グラスは日常でカジュアルに利用可能
    • HMD：企業向け、家、仕事使い
    • グラス：日常使い
  • コンテンツの作りやすさでは HMD ＞ グラス
  • 来年は AR グラスがますます浸透する
  • HMD とグラスとで、ユースケースが収斂し始めている
    • 技術登場当初から社会に受け入れられるまでに形態は変化する
    • 例）電話：ラジオ的な 1toN から、1to1 の受話器型へ
    • スクリーンレス、AIとの融合、へ収斂するのでは
  • 現状 AVP はディスプレイの代替になっていっている
    • 目や手の操作の快適性は企業に刺さってない
    • それよりもディスプレイの高精細さ

ビッグテックのグラス戦略

  • 「ディスプレイいらない」となりそう
  • リアルタイム性とファッション性、マルチモーダル（マイクスピーカーカメラ）の形態が普及しそう
    • その後、AR Glass「Pro」で、ディスプレイ付きが普及する？
  • 普及のしやすさで言えば、カメラなし、ディスプレイあり
  • ハードウェア側のエコシステムが整うことで、クリエイターが未来創造の速度が加速する
  • コンシューマー側は 3D を扱うための学びのハードルが高い
    • 普及するまでの時間は予想よりも長引く（グラス型の普及期が長く続く）かも
トークセッションの様子
“聴講メモ：SPARKS #1 – AR/AI Glass Hands on!” の続きを読む

WWDC25：Make a big impact with small writing changes

UXライティングに関するセッション。Don’t use をまとめるのは良さそう。

0:00 – Introduction

  • UX ライターによる、アプリの文章を改善するための 4 つの小さな変更について紹介：簡素化が重要
  • Apple の新しいデザインシステムを考える際に、文章も見直す絶好の機会
  • 4 つの修正を提案：フィラーワードの削除、繰り返しの回避、why を先に述べる、word list の作成
  • これらの小さな変更がアプリに大きな影響を与える

1:18 – Remove fillers

  • アプリには最小文字数がないため、不要な単語を削除することが重要
  • 副詞（easily, quickly）や形容詞（fast, simple）は多くの場合 filler として機能
  • 例：「Simply enter your license plate number to quickly pay for parking」→「Enter your license plate number to pay for parking」
  • 感嘆詞（oops, oh no）や丁寧語（sorry, thank you, please）も意味を追加しない場合は削除
  • 配達遅延の通知例：「Uh oh. We’re running late」→「We’re running late」
  • 各単語に付加価値があるかを確認し、そうでない場合は削除

6:12 – Avoid repetition

  • 繰り返しの言語も filler の一種
  • 同じことを異なる方法で言うことで空きスペースを埋めようとしない
  • 例：「Your delivery driver won’t make it on time」→「We’re running late」は同じ意味。「Delivery delayed 10 minutes」のように 1 つの文にまとめる
  • UX writing は言語の経済性が重要
  • 利用可能なスペースを繰り返し情報で埋めようとしない

7:13 – Lead with the why

  • メッセージは、次のステップを取ることが楽しい、興味深い、有益である理由を最初に伝えると最も効果的
  • 「To do or get one thing, first do another thing」のパターン
  • 例：「Enter your phone number to get reservation updates」→「To get reservation updates, enter your phone number」
  • エラーメッセージ、プッシュ通知、指示文でよく見られる
  • 利益を文の最後ではなく最初に移動することで、メッセージの影響力を向上

9:23 – Make a word list

  • アプリで使用する単語と使用しない単語をリスト化
  • 開発の初期段階で行うのが理想的だが、どの段階でも可能
  • 表形式で、使用する単語、使用しない単語、簡単な定義を整理（Use / Don’t Use / Definition）
    • 例：ゲームアプリで「alias」を使用し、「Handle, User Name, Title」は避ける
  • 包括的な word list を作成することに圧倒されず、まずは一度に 1 つの単語を追加
  • Apple Style Guide を参考にすることも推奨
  • ボタンラベルなども word list に追加することで一貫性を保つ
    • 同じアクションに同じボタン名（e.g. Next）
    • 一貫性により、アプリを使用する人々に明確さを提供

Foundation Models の RAG に Core Spotlight を活用できそうか超簡単な実験

WWDC24：Support semantic search with Core Spotlight で記したように、日記データを処理するオンデバイス LLM の実験のために Foundation Models の活用を検討しており、エントリ検索のための RAG として Core Spotlight が使えないか考えている。

ユーザー質問を受けた Foundation Models 側で、適切なクエリを生成できることが分かれば何かは作りだせそう。しかし以前の反省のとおりいきなりモデルの実装をし始めるのは悪手。まずは Foundation Models に対し自然言語でやりとりをし、狙う用途を満たす知識や能力があるかを先に検証するべき。

ということで、次のプロンプトを投げてみた。

あなたはCore Spotlightにインデックスされた日記データをもとにユーザーからの質問に答える役をします。Core Spotlightから情報を引き出すためには、ユーザーの質問を解釈し、Core Spotlightに投げるクエリを考える必要があります。ユーザーから「最後に散髪したのはいつ？」と尋ねられたら、どんなクエリを投げますか？

返ってきた答えは以下。

「最後に散髪したのはいつ？」という質問に対して、Core Spotlightに投げるクエリを考えるには、以下のようなアプローチが考えられます。このクエリは、ユーザーの行動履歴や、関連するキーワードを考慮して作成されます。

```plaintext
Core Spotlight Query:

- Type: Query
- Language: Natural Language
- Query: 最後に散髪したのはいつ？

- Context:
  - Keywords: 散髪、カット、美容室、ヘアスタイル、ヘアサロン
  - Date Range: 最近までの履歴を考慮

- Filters:
  - Category: Personal Care
  - Action: Haircut
  - Location: Salon/Barber Shop
  - Date: Last occurrence

- Constraints:
  - Language: Japanese
  - Language Preference: Japanese

```

このクエリは、ユーザーの行動履歴を基に「散髪」に関連するキーワードを特定し、最近までの履歴を考慮して「最後に散髪したのはいつ？」という質問に応答します。また、日付範囲を最近のものに限定し、具体的な場所やアクションを強調することで、より正確な情報 retrieval を促進します。

Context / Filters / Constraints をクエリ設計に含めているあたり、同じ Apple の技術である Core Spotlight のコンセプトを理解できているのかは怪しいが、少なくとも質問内容から的確にキーワード抽出ができそうなことは分かった。（まあここはさすがにLLMの得意分野だろう、、）

WWDC25：Principles of inclusive app design

インクルーシブデザインの中でも障害（disability）に焦点を当てたセッション。インクルーシブデザインやアクセシビリティデザインの文脈において、身体的に永続的な障害に目が向けられがちだが、環境要因で誰しもその状態に当てはまりうることは常々意識したい。またインクルージョンへの考慮は果てしないものだと思っていたが、現状理解と計画を持って解決していくこと、ギャップをイノベーションの機会と捉え取り組むことというメッセージに心に火がついた。

0:00 – Introduction

  • アクセシビリティデザイナーによる、障害を持つ人々を含むインクルーシブなアプリデザインについて紹介
  • 世界の約 7 人に 1 人が何らかの障害を持っており、障害は人間の普遍的な部分
  • 障害をデザインに含めることで、より多くの人々にアプリを提供し、創造性も向上
  • インクルーシブデザインにはアプリ多言語の翻訳、人種、民族への影響への配慮、世界中の文化の包摂などの観点もあるが、今回は障害に絞る
  • 大音響後の一時的難聴、大声の会話ができない、多言語環境に身を置くといった環境的要因で障害を経験することもある
  • Vision, Hearing, Motor, Speech, Cognitive の 5 つのカテゴリで障害を考える
    • 障害の有無は全か無かだけでなく、その間の「いくらか」の程度が存在する

3:55 – The inclusion gap

  • 障害は身体や心の特性ではなく、環境に大きく依存
  • 社会が期待することと個人が実際にできることの間にギャップが生じる
    • 生まれて死ぬまでの能力の曲線は人により様々
    • この「インクルージョンギャップ」が障害を生み出す
  • 人のできることは、環境のデザイン、構築により左右される→「できる力」を与えるモノ作り
    • エレベーター、マイク、メガネ、curb cuts など、多くのイノベーションがこのギャップから生まれた
  • 「Nothing about us without us（私たちのことを私たち抜きに決めないで）」の原則で、障害を持つ人々を意思決定に参加させる重要性
  • アプリをよりインクルーシブにするための4つの実践を紹介

8:55 – Support multiple senses（複数の感覚に配慮する）

  • 複数の感覚を通じてアプリとインタラクションできる方法を提供
    • 動画のキャプション、視覚的な情報、音声での体験など、様々な方法で情報にアクセス可能に
  • 情報の取得方法、入力方法を多様化（視覚、聴覚、触覚、声、認知能力）することが、インクルージョンギャップを埋める第一歩
    • Accessibility Reader の例：視覚的テキスト、音声読み上げ、ハイライト付き読み上げの 3 つの方法
    • Crouton アプリの例：画像、カメラ、テキスト、Hands Free モードなど多様な入力方法

12:36 – Provide customization（カスタマイズ性を持たせる）

  • UI とインタラクションを個人のニーズに合わせてカスタマイズ可能に
    • Accessibility Reader の例：テキストサイズ、色、フォント、音声設定の調整
    • Carrot Weather の例：データ豊富なレイアウトからシンプルなインターフェースまでカスタマイズ可能
  • アプリが人に適応するのではなく、人がアプリに適応することを期待しない

14:27 – Adopt Accessibility API（Accessiblity API を採用する）

  • アシスティブテクノロジーと連携するために Accessibility API を採用
  • VoiceOver, Switch Control, Voice Control, Larger Text などの機能をサポート
  • Accessibility API により、開発者が独自に実装することなく、障害者インクルージョンを簡単にサポート
  • アクセシビリティリーダー：Accessibility API を統合、スイッチコントロールにより画面に触れずに操作可能（iPhone とペアリング可能な物理ボタンにアクション割り当て）
  • Blackbox ゲームの例：オーディオや触覚デザインに加えて VoiceOver API で視覚障害者もパズルを解けるように設計

18:46 – Track inclusion debt

  • インクルージョンは旅であり、一度限りのものではない
  • inclusion debt（インクルージョン不足）を認識し、計画を立てて意識的な決定を行う
  • アプリに存在するギャップを理解し、障害を持つ人々と協力してギャップを埋める
  • インクルージョンギャップは創造性とイノベーションの機会
  • App Store でアプリのアクセシビリティをハイライトすることで、ユーザーが重要な機能をサポートしているかを知ることができる

WWDC25：Design foundations from idea to interface

デザインに関するセッション。情報設計が主な内容。普遍的な内容なので開発者やデザイナーだけでなく、プロダクトに携わるあらゆるロール・ポジションが把握するべき内容。

0:00 – Introduction

  • デザインエバンジェリズムチームによる、アイデアからインターフェースまでのデザイン基盤について紹介
  • アプリが「うまく動作する」体験と「動作しない」体験の違いを理解し、シームレスな体験を構築する方法を説明
  • 構造、ナビゲーション、コンテンツ、ビジュアルデザインの 4 つの基盤要素を体系的に解説

1:11 – Structure

  • 次の質問に明確に答えられるか？
    • Where am I?：現在地と、どう辿り着いたかがすぐに分かる
    • What can I do?：動作は明確で理解しやすく、推測が不要である
    • Where can I go?：次のステップを明確に意識できる
  • 情報アーキテクチャの重要性：情報を整理し、優先順位をつけて、ユーザーが必要なものを簡単に見つけられるようにする
  • 1 List every feature：アプリの機能、ワークフロー、ニーズをリストアップし、ユーザーの使用シーンを想像して整理（ここでは省かない）
  • 2 Learn from peaple：ユーザーがどう使うかを想像する。いつどこで？ルーチンにどう合わせる？助けや邪魔になるもの。答えをリスト化
  • 3 Organize insight：本質的でない機能を削除し、明確でないものを名前変更し、自然にグループ化
  • 明確な構造により、ユーザーが「どこにいるか」「何ができるか」「どこに行けるか」を理解しやすくなる

4:55 – Navigation

  • Tab bar コンポーネントを使用して主要機能へのアクセスを提供
    • What deserves a tab?：タブ数を最小限に抑え、本質的な機能のみをタブに配置
    • アクション（Add）はタブではなく、使用される場所（Records）に配置
    • 迷ったら HIG に立ち返る
    • SF Symbols を使用して視覚的に一貫性のあるアイコンを提供
  • Toolbar でスクリーン固有のアクションを配置し、ユーザーの方向感覚を向上
    • タイトルと画面の名称を表示：画面が明確になり、移動やスクロール時の方向感覚を維持
    • アクション：タブバーの代わりに使用
  • Where am I? / What can I do? が明確化

8:19 – Content

  • コンテンツを重要度順に整理し、ユーザーが期待する順序で表示
  • Progressive disclosure（段階的開示）で、必要最小限の情報から始めて、インタラクションに応じて詳細を表示
    • Disclosure control の使用
    • 遷移前後でレイアウトを一致させ、前後の繋がりを与える
  • Grid の代わりに List コンポーネントを使用して構造化された情報を効率的に表示
  • コンテンツを時間、進捗、パターンでグループ化して整理
  • Collection を使用して画像やビデオのグループを動的に表示

13:28 – Visual Design

  • カラフルな要素にまっさきに目がいってしまう
  • 視覚的階層でユーザーの視線を重要な要素から順に誘導
    • 重要なものを大きく、コントラストを高く
    • テキストを長く、大きくしたり、言語を変えて検証：柔軟性が重要
    • System text styles を使用して一貫した階層と可読性を実現
    • テキストと画像の重なりでは、グラデーションやブラーで可読性を確保
  • 必要なのはまとまりのあるビジュアルスタイル（Use a cohesive style）
    • アプリの個性を表現する色パレットとビジュアルスタイルを確立
    • Semantic colors（label, secondarySystemBackground など）を使用して動的な色の変化に対応（外観でなく目的にちなんで命名）
      • コントラスト設定、画面環境、ダーク／ライトモード…

This website stores cookies on your computer. These cookies are used to provide a more personalized experience and to track your whereabouts around our website in compliance with the European General Data Protection Regulation. If you decide to to opt-out of any future tracking, a cookie will be setup in your browser to remember this choice for one year.

Accept or Deny