WWDC26:Craft clear names for features and labels in your app

アップルの命名に関する意思決定を垣間見ることができる貴重なセッション。

Craft clear names for features and labels in your app


0:00 – Introduction

  • 命名はアプリ体験を形作る最も強力なツールの一つでありながら、見落とされがち
  • ヒーロー機能からメニュー・設定・タブバーまで、あらゆる命名の選択がユーザー体験に影響する
  • 良い命名のための 3 つのツール:基準(criteria)・プロセス(process)・評価(evaluation)

1:18 – Criteria

  • 優れた名前が持つ 3 つの特質
    • ふさわしさ、他すべての名前と調和(Belong in the app)
    • わかりやすさと信頼、期待を裏切らない(Set the right expectation)
    • どこでも通用し、どの言語や市場、コンテクストでも破綻しない(work everywhere)
  • すべてを満たせるとは限らない、絶対的なルールではなく指針
    • トレードオフは自分で判断する

5:25 – Process

  • まずターゲットを特定する
  • 「Think・Feel・Do」フレームワークを使ってアイデアを発散させる
    • ユーザーにどう思って欲しいか(e.g. 便利、簡単、気が利いている)
    • ユーザーにどんな気持ちを感じて欲しいか(驚き、安全)
    • ユーザーに何をさせようとしているか(場所の共有)
  • 全部書き出したら俯瞰する
    • 言葉は異なるが同じ感覚の繰り返しを発見できる → グルーピング
    • グループごとのテーマが見つかる(e.g. 手軽さ、ワクワク、安心感)
      • それぞれの感覚を伝える言葉は?上記基準に合わない言葉を取捨選択
        • らいくない、曖昧など
        • 実際に読んだり話したりしてみて違和感があるものを排除

10:34 – Evaluation

  • 自分の命名の良し悪しをどう判断するか
  • 生成した命名案を基準に照らし合わせてレビューする
  • すべての名前がすべての基準を満たす必要はない
  • 機能のコンテキストが、どの基準が最も重要かを決める
  • 命名ひとつひとつの小さな決定が、その後に続くすべてのパターンを設定する
  • ユーザーが容易かつ心地よくアプリをナビゲートできるようになる

聴講メモ:WWDC26 Recap – Japan-(region).swift

去年に引き続き、東京会場である Apple Japan にて参加してきた。

今年もLTの内容盛りだくさんで、比較的 AI 周りのテーマが多かった。このテーマはキャッチアップしていたので良い復習や、もうすでに具体的に取り入れたケースを知れて良かったし、その他のテーマもまだ追いきれていないので有意義だった。

今年は、ネームカードとストラップがひとりずつ準備されていたり、各ご当地お菓子が用意されていたりと、至れり尽くせりだった。各会場を配信でつなぎあい、それぞれの空気感が伝わり一体感あったのもよかった。

イベントページ:WWDC26 Recap – Japan-(region).swift · Luma

以下手元のメモを、あまり直していないので備忘録程度に。途中メモしていないセッションもあったのでそこは省いている。登壇された方が公開しているプレゼン資料も貼らせていただいた。


Visual Intelligence を使ったアプリ内の類似データ検索

  • Visual Intelligence とは:スクショ画像から特定アプリにクエリを投げる
  • セッションのコードベースで説明
  • スクショプレビューで Intelligence → アプリにクエリ投げる → 結果返る
  • 類似画像検索
    • 選択画像を pixelBuffer に変換に、アプリ内データとパターンマッチング
    • FeaturePrintObservationで特徴量を見る
“聴講メモ:WWDC26 Recap – Japan-(region).swift” の続きを読む

WWDC26:Principles of great design

Human Interface Guidelines に今年復活した Design Principles をひとつひとつ解説。ひとつひとつの要素は、あるべきデザインとして強い目新しさこそは感じなかったものの、体系的にまとめられたことでデザインを検討する時の強力な指針になると感じた。特に、Craft はコスト制約の中ではおざなりになりがちだが、、それがユーザーとの信頼関係を失うことはその通りだと思った。あと、「喜び」に満ちた体験を提供するにあたって、ユーザーにどんな感情を呼び起こしたいか?これを特定することの重要性は、チームや組織でものを作りにあたってはちゃんと言語化しながら意識していきたいと思った。

Principles of great design


0:00 – Intro

  • デザインとは美観や動作だけでなく、意図を持って何かを作ること
  • あらゆる機能はユーザーの時間・注意・信頼を要求する
  • 何を作らないかを選ぶことは、何を作るかと同じくらい重要

1:08 – Purpose(目的)

  • 本当にユーザーの役に立つ体験を設計すること
  • ユーザーの生活を尊重し、適応する設計
  • 明確で考え抜かれていて、最良の状態では純粋に喜びを感じられるもの
  • コードを一行書く前に、作ろうとしているものに本当の目的があるか、ユーザーが真に価値を感じるものかを問う

1:52 – Agency(主体性)

  • ユーザーをコントロールの主体に置く
  • 選択肢を提供することは、主体性をもたらす最良の方法
    • 自分のペースで探索できるようにする自律性を提供
    • 決められた経路に誘導しない
      • → 体験をコントロールできると、より深く関わろうとする
  • 失敗への寛容さを組み込む
    • 簡単な取り消し (undo)
    • 破壊的な操作への確認(大きな間違いをしそうな場合にのみ限定すべき)
    • 自由に試せるという安心感(回復できる自信)が主体性につながる

3:38 – Responsibility(責任)

  • プライバシーを人権として尊重する
  • 必要なものだけを、使用目的を明確にした上で、適切なタイミングで要求する
  • 機能がどのように害を引き起こしうるか(どう悪用されるか、どう防げるか)を事前に想定する
    • 特に AI において、悪い結果からユーザーを守る
  • リスクが価値を上回る場合は機能を削除する

6:04 – Familiarity(親しみ)

  • 既存の知識を設計に応用できるようにする
  • メタファーを使う際は、具体すぎず抽象すぎない塩梅に
    • 良いメタファ=人が知っていることを引き出し、何をするか予測を手助けする
  • 一般的な操作には確立されたメタファに従う(e.g. お気に入り、共有、ロック)
  • 外見が同じものは同じように動作させる(一貫性)

8:52 – Flexibility(柔軟さ)

  • 様々なコンテキスト・デバイス・能力に適応する設計
    • 音楽を聴く環境(e.g. 家でスピーカー、ラインニング中、車の運転中)
    • 各プラットフォームの強みを活かす
  • ユーザー層の多様性を考慮する(年齢、言語、習熟度、アクセシビリティの必要性)
    • はじめからすべてには対応できない、インクルーシブな体験を検討
    • 一つの解決策ではカバーできない場合はパーソナライズを許容する
  • 柔軟性はコストはかかるが価値があること

11:13 – Simplicity(シンプルさ)

  • シンプルさとは:
    • デザインの核心にある目的を輝かせること
    • ミニマリズムではなく摩擦を除去し直感的であること
  • 簡潔な言語・強い視覚的ヒエラルキー・明確なアフォーダンスが重要
  • 明確さでユーザーが必要なものを努力なく見つけられるようにする
    • 階層(順序、余白、コントラスト)によって、最も重要なものに誘導する
  • すべての要素はその存在を正当化する必要がある
    • 複雑の情報のグラフ化、情報の要約などで、重要な情報に集中できる
  • 要素・コンテキストを加えることでインターフェースがよりシンプルに感じられる場合もある

13:42 – Craft

  • クラフトとは妥協のない細部へのこだわりによって信頼を築くこと
    • 寄せ集めの様な品質だと、プロダクトの生み出す結果の品質まで疑ってしまう
  • クラフトは高品質の素材から始まる
    • 美しいタイポグラフィ・レスポンシブなアニメーション・堅牢なパフォーマンス
  • 継続的な改善への取り組みが「自分たちが気にかけている」ことを示す
  • 優れたデザインには長寿命がある——プラットフォームとユーザーのニーズの変化に合わせ進化し続ける

15:47 – Delight(喜び)

  • 喜びに満ちたインターフェイスとは、飾りを付け足すことではない
  • ユーザーにどんな感情を感じてほしいかを特定し、デザインでそれを強化する(リラックス、自信、ワクワク)
  • ここまですべての原則の総和によって自然に得られる結果

WWDC26:What’s new in Shortcuts

Shortcuts のアップデート。通知トリガーにその内容を元に挙動をハンドリングできたり、Cloud モデルで Web 検索も含めた推論を取り込めたり多機能化。がなによりう、ストレージ機能でデータを永続化できる様になったのは驚き。簡単なユースケースならもはやアプリにする必要すらなくなった。

What’s new in Shortcuts


0:01 – Introduction

  • Shortcuts の役割:アプリのアクションを組み合わせ、Siri・コントロールセンター・アクションボタンなどシステム全体に公開
  • 2026 年の 3 つの主要強化点を解説

0:57 – Automations

  • iOS 26 でオートメーションが Shortcuts エディタからより発見しやすくなった
  • 3 つの新しいオートメーショントリガー
    • スクリーンショットの撮影時
    • 外部キーボード接続の接続状態変化時
    • 特定アプリからの通知受信時
      • 通知コンテンツに対するキーワードフィルタリングで細かい条件設定が可能
  • オートメーションとうまく連携する通知を構築するためのポイント
    • 通知の本文にマシンリーダブルなキーワードを含める設計が重要

3:25 – Use Model

  • 「Use Model」アクションが最新の Apple Intelligence モデルにアクセス可能になった
    • Web 検索との統合も利用可能
  • 期待通りの結果を返さなかった → モデルが何を見ていたかを知ることができる
    • モデルトランスクリプトインスペクターで、アプリの AppEntity エンティティからモデルに渡されるデータを確認できる(Shortcuts アプリ上でダイアログ表示)
    • 意図した情報が正しく渡っているかデバッグに活用(エンティティのプロパティが不足している、など)

6:58 – Storage

  • Storage 機能でショートカットの実行間にデータを永続化できるようになった
    • Get・Set・グローバルストレージ値の 3 つの操作
      • e.g. 毎日のコーヒーをカウントする
    • iCloud 経由でユーザーの全デバイスに同期
  • 活用例:「Use Model」アクションに「記憶」を持たせる
    • e.g. 毎朝特定トピックの豆知識を流す
    • 前回実行の結果をストレージに保存し、次回の入力として渡す(前回流した豆知識とは違う豆知識を流す)
  • AppEntity と Storage を組み合わせる場合の注意点
    • デバイスをまたいで正しく認識されるよう、安定した・デバイス間で一貫した識別子を使用する必要がある
    • SyncableEntity の採用が推奨

WWDC26:Code-along: Make your app available to Siri

App Schema によって Siri と自然言語でアプリコンテンツとのインタラクションを実現する方法のコードベース解説。前回前々回の良い復習になった。

Code-along: Make your app available to Siri


0:00 – Introduction

  • ピクニックシナリオを通じた実演:イベント検索、時間の更新、参加者へのテキスト送信、会話形式での質問応答
  • 既存アプリを Siri 対応にする流れをコードアロング形式で体験

1:43 – App Schemas and the plan

  • App Intents によるシステム連携の仕組みと App Schemas の役割を整理
    • App Schemas はコンテンツとアクションを Siri が理解できる形で記述する
    • トレーニングフレーズ不要で Siri との連携が成立する
  • サンプルアプリ CometCal で calendar ドメインを採用する 2 つの目標
    • コンテンツの理解(エンティティ)
    • アクションの実行(インテント)

3:44 – Build the CalendarEntity

  • @AppEntity(schema: .calendar.calendar) マクロでスキーマ準拠の AppEntity を作成
  • idUUID 型で指定
  • IndexedEntity に準拠して Spotlight へのインデックスを有効化
  • @Dependency でデータアクセスを注入
    • App Intent が共有リソースをインテントやクエリに注入する仕組み
    • インスタンスの再生成をせず、既に登録したオブジェクトを提供 
  • EnumerableEntityQuery を採用してすべてのカレンダー allEntities を列挙可能に
  • displayRepresentation でタイトルや画像を設定して Siri や Shortcuts での表示名を定義
  • IndexedEntity はインデックスされるコンテンツの形状を定義、コンテンツ更新に従って再インデックスが必要
    • CSSearchableIndex.indexAppEntities(_:) でエンティティを提供
    • 同様に updateAppEntities, deleteAppEntities

8:00 – Build the AttendeeEntity

  • @AppEntity(schema: .calendar.attendee) から構築
  • TransientAppEntity に準拠(IndexedEntity ではなく)
    • 参加者はイベントを通じてのみアクセスされ、一時的なエンティティであるため、識別子・クエリ・インデックスが不要
    • 同じ人が複数イベントへの参加を表明する場合、仮に参加ごとにインデックスを作成すると Spotlight で重複した結果が生じる
  • IntentPerson 型(システム標準の人物表現)と参加者のステータス・種別用の @AppEnum を導入

10:30 – Build the EventEntity

  • @AppEntity(schema: .calendar.event) から構築する中心的な IndexedEntity
  • タイトルやメモの質問に対応するセマンティックインデックスをサポート
  • CalendarEntity[AttendeeEntity] を合成して構造化
    • Siri は AppSchema 二よりこれらの構造を理解
  • Calendar.RecurrenceRule によりイベントの繰り返しルールを定義
  • 場所・アラームのユニオン値 EventLocation、イベントステータス EventEntityStatux, スパン EventSpan

14:34 – Open events with OpenIntent

  • Siri からアプリのメイン画面が開くだけでなく、対象のイベントを開いて欲しい
  • system.open スキーマに準拠した OpenEventIntent を実装
    • EventEntity を受け取り NavigationManager でイベント詳細画面へ遷移
  • Spotlight や Siri でイベントをタップすると直接詳細画面が開くようになる

15:30 – Onscreen awareness

  • 2 つのビューモディファイアでオンスクリーン認識を有効化
    • .appEntityIdentifier:イベントリストの各行に付与
    • .userActivityEntityIdentifier 付き):詳細ビューに付与
  • 「このイベント」「3 番目のイベント」のようなタイトルを言わない参照が解決できるようになる

17:18 – Create events with Siri

  • calendar.createEvent スキーマに準拠した createEventIntent を実装
    • パラメータ型を設定し @MainActor @Dependency を追加
    • perform() 内でスキーマのパラメータ(場所のユニオン値、繰り返しルール)を解決して EventEntity を返す
  • 自然言語の解釈・確認・曖昧さの解消は Siri が担当

19:24 – Update events

  • UpdateEventIntentCreateEventIntent と対称的な構造で、パラメータはオプショナル
  • IntentParametervalueState が重要なポイント
    • .set(値あり):変更を意図
    • .setnil):クリアを意図
    • .unset:リクエストに含まれていない(変更しない)

21:30 – Custom snippet views

  • インテントの戻り値型に ShowsSnippetView を追加し、カスタム SwiftUI ビューを返す
    • EventSnippetView を返すことで Siri のデフォルトカードをアプリ独自のデザインに置き換え

22:30 – Delete events

  • DeleteEventIntent は最もシンプル(イベント+繰り返し用のオプショナルなスパン)
  • 確認や曖昧さの解消は Siri が自動的に処理する

WWDC26:Build intelligent Siri experiences with App Schemas

前回の内容をコードベースでより掘り下げながら、App Schema への準拠によってアプリ固有アクションを Siri に理解させ自然言語でも実行可能にする方法れていた。App Entity、App Intent、App Schema、色々出てきてこんがらがってきた。
WWDC26:Explore advanced App Intents features for Siri and Apple Intelligence

Build intelligent Siri experiences with App Schemas


0:00 – Introduction

  • App Intents によってアプリを Siri に対応させる仕組みを解説
  • Apple Intelligence により Siri がより有能・文脈理解・パーソナルに進化

1:06 – What’s new in Siri

  • Siri が新たに得た 3 つの能力
    • アプリのエンティティへのアクセス(コンテンツの把握)
    • インテントを通じたアクションの実行
    • オンスクリーンコンテキストの理解

4:06 – Contributing content with App Entities

  • アプリのコンテンツを AppEntity としてモデル化する
  • AppEntities が表現するもの
    1. 何であるか(nouns)
      1. 識別方法
      2. 重要なプロパティ(タイトルなど)
  • これらを Siri が理解できるようにするために AppSchema に準拠する
  • スキーマは @AppEntity(schema: .messages.message) のように指定

6:21 – Entity resolution and IndexedEntity

  • エンティティを特定するにおいても、人は必ずしも正確に話すわけではない(概念や説明を話す)=完全一致ではない
  • IndexedEntity に準拠し、セマンティック検索やコンテンツ Q&A を実現する
    • @Property(indexingKey: \.textContent) でインデックス対象プロパティを指定
  • データセットが巨大など、事前インデックスが難しいデータには EntityStringQuery を使用
    • entities(matching:) で文字列に基づくリアルタイム検索を実装

9:49 – Making actions available

  • App Intents を定義すると、システムにアプリのアクションが公開される
    • Shortcuts、Spotlight、Widgets 様ざな場所に表示され、必ずしも Siri がなくともアクションを実行できるようになる
  • エンティティを App Schema に準拠させることで、そのアクションを Siri が理解できるようになり、自然言語で実行可能になる(App Schema = App Intent の特化版)
  • 複数のインテントを App Schema ドメインにグループ化することで Siri が関連アクションを把握

12:03 – Adopting a schema domain in UnicornChat

  • Messages ドメインの sendMessage スキーマを採用するエンドツーエンドの実装デモ
  • スキーマドメイン採用により Siri との会話が自然に成立する

15:39 – Moving content across apps

  • エンティティに Transferable を採用することで他アプリがそのコンテンツを操作可能になる
  • IntentValueRepresentation を使って他のアプリへの書き出し・書き込みを制御

16:00 – Working across apps: onscreen awareness

  • NSUserActivity またはビューアノテーションでビューをエンティティに紐付ける
    • NSUserActivity:単一のプライマリエンティティをビュー全体に関連付け
    • .appEntityIdentifier モディファイア:リスト内の各行など個々のビューに紐付け
  • Siri が「これ」「あれ」などの参照を解決できるようになる
  • IntentValueQuery でクロスアプリのコンテンツマッチングを実装
    • values(for:)IntentPerson などのシステム型から、既存のアプリ内エンティティへマッピング
  • IntentValueRepresentationimporting: クロージャを追加すると、一致するコンテンツが存在しない場合に新規作成も可能

21:09 – Best practices

  • スキーマセットを完全に採用することで Siri との会話が完結するように設計する
  • Xcode がビルド時に不足している関連スキーマを指摘してくれる

24:18 – Testing your integration

  • 段階的な検証アプローチ
    • AppIntentsTesting フレームワークによって、Siri 不要でプログラマティックにロジックのテストが可能
    • Shortcuts アプリでパラメタや入力の調整をしながら、アクションのユーザーへの見え方(インテントの形)を検証
    • Spotlight でエンティティのインデックスされていて発見可能かを確認
    • 最後に Siri でエンドツーエンドテスト

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

  • DisplayRepresentationtitlesubtitleimage を設定すると応答画面や 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.appEntityIdentifiersEntityIdentifier の配列を設定
    • Now Playing では最も具体的なものから順に複数の EntityIdentifier を指定
    • Alarm Kit の AlarmConfigurationappEntityIdentifier パラメータとして渡す

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

  • DurationPersonNameComponents のネイティブサポートが追加
    • 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をタッチ&トライした高田馬場のコワーキングスペース CASE Shinjuku では、30周年記念モデルだけでなく、HHKBパームレスト界の頂点に君臨する松葉製作所のパームレストも試用していた。このときのフィーリングが忘れられず、HHKB 30周年キーボードと組み合わせて是非使いたくなってしまった。

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

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

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

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

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

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年以上毎日を共にしたキーボードに何を感じるかが楽しみだ。