昨日に引き続き、extension DC Day 2 に参加。Liquid Glass デザインの話から、ショートカット の話までさまざま。Foundation Models のプロンプトテクニックが素晴らしそうで、発表者の Fujimon さんにお話伺おうと思っていたが、筆者がすっかりお友達と話し込んでいるうちに時間が来てしまった。明日の Day 3 もいらっしゃるそうなので、チャンスがあれば。
イベントページ:https://sansan.connpass.com/event/362403/
SpeechAnalyzerによる音声文字起こしの罠
Musa さん
- speech-to-text技術
SFSpeechRecognizer- Siri 有効化必須がデメリット
- オンデバイス・クラウド どちらでもOK
- 長さ制限あり
SFSpeechRecognizer- 遠距離可能
- オンデバイスのみ
- リアルタイム、音声ファイル 両方OK
- 事前のモデルダウンロードが不要
- 純正アプリで使用されている
- 精度比較
SpeechAnalyzerの方が検出文字数多い- 音の拾いやすさ、検出精度は圧倒的に向上、文字起こし品質も向上
- 横文字、専門用語も対応
SpeechAnalyzerの罠- リアルタイムもファイルも可能だが、リアルタイムは音の拾いやすさが致命的に悪い
- 机の向こう側とか声も取れない
- ファイル起こし →
SpeechAnalyzerに渡すことで劇的改善
- リアルタイムもファイルも可能だが、リアルタイムは音の拾いやすさが致命的に悪い
- 現状、ネット上ではこの問題が報告されていない
- オーディオファイルからの speech-to-text 実装紹介
- LLM のように asyc でインクリメンタルに結果が返ってくる
Liquid GlassとAppIntentsについての考察
touyou さん
- LiquidGlasss により実現される真のアクセシビリティ
- コンテンツファースト
- 最低限で使う(not 装飾)
- つまり、Liquid Glass を控えるところ=コンテンツ/使い所=操作するUI
- 『UIから「白」が消える日』の記事
- UIの透明化が現実に e.g. TabBarMinimizeBehavior
- App Intents
- Intent = 動詞、Entity = 名詞
- UIを経由せずに、機能や中身にたどり着ける
- これを象徴する新機能:Visual Intelligence
- アプリを開かずにアプリの中身を表示する体験
- UIの存在感が薄くなり、アプリとOSの境界が解ける
- これを象徴するアップデート:透明化したアプリアイコン
- なぜ色を残さない?アプリの存在感を薄くするという意味では
- 最低限で使う(not 装飾)
- 一貫性
- visionOSの透明感のあるUIを、他デバイスに統一
- 多様性 x 一貫性 = 真のアクセシビリティ
- 「誰もが自分に合ったやり方で、同じコンテンツにたどり着ける」
- どうアプリを作っていくべきか?
- App Intents 中心に設計し、モデルベースUIで作る
- Entiry(名詞)を棚卸し、Intent(動詞)を設計し、各機能に設定
- App Intents はアプリのUI以外だけでなく、iOS 17 以降ではButton.init(intent:) でも受けることができる
- Apple が全機能を App Intent に乗せることを推奨するセッションも
Foundation Models を活用するための Tips
RioFujimon さん
- FMの概要、得意不得意
- 前回:ローカル OCR
- “Apple 標準APIでオンデバイスで可能な実装の幅が広がる”
- まだ活用事例が少ない
- 活用すべき/適さない場面、プロンプト運用の工夫、リードタイム短縮の工夫
- サンプルアプリ:名刺の曖昧検索
- 利用する部分を見極める
- 検索条件パラメータの生成抽出にFMを利用→ローカルDBを検索
@Generiableと@Guidedで、検索条件の全パラメータ生成させる?- すべてのパラメータを生成する必要があるか?→ Foundation API で取れるものはそちらに任せるべき
- e.g. 電話番号、メルアド、住所、URL、、
- これらは
NSDataDetector(NSTextCheckiingResult) で可能
- プロンプトの運用改善
- 人物名、会社名、部署、役職、、
- プロパティが増加するたびに、
- プロンプト修正が必要。加えて指示、禁止事項が競合、
- プロンプトが長くなることで可読性の低下
- 複数のプロンプトに分割、
Generableを付与した型を複数生成する- 人物名専用、会社名専用の型、のようにプロンプトを分離する
- 他と干渉しないので、独立性メンテナンス性が向上
- レスポンス生成からフィードバックまでの時間を短縮
- セッションを属性個分作り、
asyncで走らせ並列実行する
- セッションを属性個分作り、
- 生成結果
- 名前や役職は苦手そう(例を入れても抽出難しい)
- 会社名や部署はうまく取ってこれた
- 固有名詞の推論・抽出に弱い
- アプリ上での利用を考える
- 現状は、FMの生成結果を条件に使う場合、その条件を緩める必要がある
- 論理積よりも論理和にあてはめ、ヒットする状態を作る
- 現状は、FMの生成結果を条件に使う場合、その条件を緩める必要がある
SwiftSyntaxとIndexStoreを組み合わせてSwiftコードベースの理解を深めるツールを開発しよう!
Ockey さん
- Xcode: Jump to definition
- どこで定義されているかだけでなく、参照も探せるが、、型に使えない
- 静的構造も見たいし、依存関係遡りたい。
- Swiftコードから依存関係を抽出したい
SwiftSyntaxxIndexStore
SwiftSyntax- コードに忠実な構文機を扱うライブラリ
- 構文木とは:
DeclSyntaxが宣言、nameがプロパティ名DeclSyntax: 宣言を表すノードの型が決まっている- 宣言抽出の流れ
- swif-syntax
SwiftParserのparseに文字列を渡す - SwiftSyntax の
Visitor.walkで探索visit→visitPost
- swif-syntax
IndexStore: 依存関係のお抽出- ソースコード中のシンボル情報を保管し、Xcode の定義ジャンプで使われているはず
Unit: 入力ファイルやオプションを保持Recordシンボルの出現位置や識別し、役割(definition,reference)
- USRが同じで、
definition/referenceの役割が異なることで参照関係はわかるが、 - 誰に参照されているかは、スコープ単位でしかわからないし、関数内の定数変数の
definitionもわからない IndexStoreからわかること/わからないこと- わからない:参照位置/参照側が誰か、関数内の定数・変数
- わかる:出現位置と定義範囲
- →
SwiftSyntaxならその定義位置を特定できる
- →
- ソースコード中のシンボル情報を保管し、Xcode の定義ジャンプで使われているはず
- 組み合わせる
SwiftIndexStoreを使った実装の紹介DIctionaryとKeyPathを活用でアクセスを早くでき便利
extension 現場で使えるXcodeショートカット一覧
とんとんぼ さん
- ショートカットの Deep な話
- カスタムショートカットについて
- 設定 > Shortcutrs
- Shortcut set に、セットファイルを保存できる
- ファイルどこにある?
/UserData/KeyBindings/.idekeybindings
- ファイル管理されている→リモート管理も可能
- GitHubでファイル管理
- 例
- command+P → 今日日プリントしないだろ → Refresh Canvas
- commadn+Enter → Show Editor Only
今中途半端なSwift 6対応をするより、Default ActorやApproachable Concurrencyを有効にしてからでいいんじゃない?
y.imajo さん
- Swift 6 対応完了とは、具体的に何を意味する?
- 24.9 月の時点でSwift 6.0
- だが、language mode v5 を使っているはず
- language mode v6 だとは会的変更
- → v6 対応のこと?時代によって文脈が変わっている
- WWDC25
- Default Actor Isolation: MainActor 設定
- Approachable Concurrency の Upcoming Feature Flag
- disable outward actor iso infrerence
- … それぞれの説明
- 最終局面でやった方が効果的
SpeechAnalyzer による Speech to Text の進化を探る
- 家電の音声コントロール
SpeechAnalyzerSpeechModueprotocol に準拠しているモジュールを追加SpeechTranscriberDictationTanscriberSpeechDetector
SFSpeechRecognizervs.SpeechTranscriber- 進化ポイントについて
- マイクから離れた位置からでも精度担保
- Siri の有効化が不要 → 運営負荷下がった
SpeechDetectorはまだSpeechModueprotocol に準拠していない
KMP の Swift export
pihero さん
- Objective-C を介さず、Swift から Kotlin を呼び出す
- .swift → .kt の間に、.kt を Apple framework に変換して呼び出す
- objc ヘッダになっている
- KMPの定義元を見ると、objc コードが登場
- objc export
- 全てのインターフェイスがひとつにまとまっていたり、Swift らしくなかったり、問題あり
- Swift export の登場
- 2026年安定版のリリース目指す
- objc export との違い
- トップレベルファンクションをファイル名を介さずそのまま呼び出せる
- マルチモジュール定義により、モジュール間の命名が競合しない
- パッケージサポート
- enum で名前空間を表現
- Experimental
「聴講メモ:extension DC 2025 Day2 @Sansan」への1件のフィードバック