カテゴリー: 聴講メモ

Apple Japan 開催の WWDC Recap イベントに今年も行ってきた。去年も何度も足を運んだ Cafe Macs だが、今年はなんと撮影可能となっていた（と思ったのだが去年も撮影可能だったとも聞いた）。

セッションの内容は、大きくアプリの体験を向上する要素（Intelligent / Integrated / Adaptable / Tools）を軸に、今年発表された内容の詳細を紹介するものだった。Intelligent、つまり Siri AI や Foundation Models については個人的には注目しキャッチアップしていたので良い復習になった。Integrated が興味深く、特に App Intents についてはそろそろきちんと学びたいと思っていたところ、やはり Siri AI の登場で真価を発揮する機能だと再認識した。というか、App Intents がシステム提供のサービス基盤とアプリとを繋ぐエンドポイント的役割、という説明が非常にしっくりきた。

WWDC で実施され、オンラインでも配信されていた「Group Lab」という取り組みを物理的に再現くださって、たくさんの質疑応答に Apple Japan のプレゼンターらが答えるコーナーもとても内容が充実していて良かったし、中でも今年の発表内容を受けて各自アプリ提供者がマストで対応するべきことも整理されて良かった。Liquid Glass 対応や UIApplicationDelegate の利用廃止ばかり注目されているが、何気にプラットフォーム横断でアプリが使えることによる「リサイズ対応」も、対応マストながら完全に見落としポイントだった。

メモもしたが超雑多で聞き取れない箇所は不正確の可能性もある、あくまで備忘録として書き残しておく。

---

• Intelligent
  • 3つの条件
    • 条件1: Anticipate（先読み）
    • 条件2: Accelerate（短縮）
    • 条件3: Unlock（可能性を解放）
  • Apple Intelligence / Foundation Models
  • マルチモーダルで画像分析もできるようになった（e.g. 画像のキャプション生成）
    • Foundasion Models vs Vision
  • Private Cloud Compute / 要Small Business Program
    • 問題を段階的に処理するリーズニングにも対応
  • カスタムモデル
    • LLM 提供者の Swift パッケージから導入可能
    • そのほかのローカルのモデルも使える
    • MLX：新しいモデルのトレーニング
  • モデルの活用
    • フェーズごとのモデルの使い分け
      • ブレインストーミングなどの創造性を要するのでサーバーサイド
      • 計画：深い推論を要するのでサーバーサイド
      • レビュー：速応性が必要なのでオンデバイス
    • コンテクストを共有し、ハンドオーバーする複雑性の解決：Dynamic Profies
  • モデルの評価
    • Evaluations framework
• Integrated：システムとの統合
  • e.g. Widget, Control Center, Live Activities, Spotlight…
  • 声だけでアプリを操作できるSiri AI
  • App Intents framework
    • システムの様々なサービスに対する共通基盤（Siri, Spotlight, Shortcuts…）
      • WebサイトでいうところのAPI的な役割
    • 基礎となるデータを Entities として用意する（予定の内容、メールの内容、写真）
    • App Schema と Entities を組み立てることで、Siri が共通概念を理解できるようになる（e.g. 各データに対して、連絡先、会話といったようにマッピングして理解できるようにする）
    • アクションも定義（インテントの実行）
      • Entities = データ、Intents = アプリができる機能（動詞）
  • 画面上のコンテクスト理解（On-screen awareness）
    • エンティティごとにアノテーションをつけることでSiriが理解可能になる
      • “the third” → View ごとにアノテーションをつける
  • ひとつのタスクを複数のアプリをまたいで流れるような体験が実現可能
    • Maps でピン留めしたレストラン→Note でメモ
  • Siri に学習させるラーニング機能
    • e.g. Send a mesage → Which app do you mean?
    • アプリが Siri に対して利用傾向を donation する（IntentDonationManager）
  • どこから始める？Domainから（system, phone, mail, clock… ドメインごとに事前に用意されたスキーマがある）
  • system.search というスキーマで、アプリの中のサーチに直接アクセスすることができる
• Adaptable
  • Liquid Glass
    • なじみやすさ（Familiality）
      • UI layer / Content layer
    • Brand Indentity
      • 色、タイプ、コンテンツ、、
      • iOSのデザイン言語を活かす
        • e.g. gentler streak, moon lit
      • ティントカラー
        • e.g. Slack: トップバーをコンテンツレイヤーに落とした（Color scrolls away）
      • Icon Composer
  • Platform
    • iPhone → iPad → iPhone mirroring on Mac
    • リサイズが可能に：Xcode 27 でビルドし直した時点でリサイズ可能なモードが有効に
  • まず Xcode 27 で再コンパイル
• Tools
  • プロンプトテクニック
    • Be specific：具体的に
    • Give stylistic cuse：スタイルの手がかりを入れる（どんな感情やムードを呼び起こしたいのか、コーヒーショップの雰囲気、紙の質感）
    • 必ず複数のオプション・可能性をリクエストする
      • 「XXX種類のバリエーションで作成してください」
    • 「Swift Preview と固有の名前をつけてください」
  • エキスパートスキルが組み込まれているから活用して（ローカライズ、アクセシビリティ、、）
  • Figma, GitHub から提供されるプラグインを使って Xcode に指示

Q&A

• Siriは一般ユーザーに使いこなせる？Siri AI は音声のみ？
  • 海外だと意外と気軽に使われている
  • Siri AIの呼び出し：Spotlight のサーチがなくなりテキストで話しかけ
  • テキストは日本語でもいける
• 今年のアップデートで今後やらなければならないこと
  • UIKit, UIApplicationDelegate 使っていたら移行すること
  • LaunchScreen を追加すること
• 自分のアプリが既存の App Intent Scheme に当てはまらない場合
  • ドメインがジャンルに当てはまらなくても OK
  • 写真を扱っていたら、写真のドメインに用意されている entity や intent を使ってOK（たとえばECで画像投稿とかは、photo 配下にあるので使ってOK、カレンダーでなくても calendar のエンティティ使っていい）
  • system.search は、アプリに検索機能があれば、XXXを探しての変数部分がアプリにそのまま転送されるので、なるべく入れると良い。Siri経由で検索ができるようになる
  • スキーマなしの intent 作って、AppShortcutProvider 使うことができ、従来は厳密にそのワードと一致する必要があったが、今回のSIriで少しだけ柔軟性が上がっている
• Mac, iPad でも iPhone アプリが動くので崩れないよう対応必要？
  • デザインの対応が必要
  • リファレンス：Apple のアプリは Xcode 27 でビルドしているものが多いので、iPhone Mirroring で動かしてみると良い
    • 天気とか株価とか Lnadscape 対応している
• アプリアイコンに企業ロゴを使用していて変更できないがどう対応するべき？
  • 屈折入れない判断もあり
• リサイズの禁止はできる？
  • ないが、iPad 26 までで deprecated になった UIRequiredFullScreen が（iOS 27 のみで）役割が変わって復活、有効になる。縦横の比率を保ったまま拡大縮小ができる、という意味になるので、それを Info.plist に入れることで担保できる（Modernization UIなんとかというUIKitのセッションで説明されている）
• iOS 26.2以降のメモリ不足によるクラッシュについて
  • Foundation Models のバージョンアップが26.4で行われた
• 会話コンテクストは Siri AI のコンテクストに保持される？それとも独立？
  • 会話は Siri AI のセッションに残っている
  • 機能登録した〜は引っ掛けられる、技術的には Index entity にして、Core Spotlight にデータを送る（カレンダーを登録した段階で Spotlight に送ることで、変更日時も登録される）
• リサイズは縦横の切り替えお必須？
  • 基本的には考える必要あるが、UIRequiredFullScreen を有効にすればOK
• さまざまなサイズに対応しない場合の不都合
  • リサイズ可能な状態になるとレイアウトが崩れるのでまずい
• On-device model の性能を Gemini 比較で
  • Apple Machine Learning Research というブログサイトを見て欲しい
  • 性能についての記載おある（2つモデルがあり、上位機種は上のモデルで動く。その詳細が書かれている）
    • 6/8 のIntroducing 3rd generation … 記事

去年は当日スタッフとして参加した try! Swift だが、今年は一般参加してきた。

try! Swift Tokyo 2025 にスタッフ参加した話

去年に引き続き、実は今年もスタッフで参加する気満々で、申し込みも書き上げあとは送信するだけという状態だったが、そもそもここ数年を振り返るとこうしたカンファレンスにまともに終日参加したことがないことを思い出した。iOSDC は例年個人的な都合により物理参加できていないし、try! Swift は前職の都合上午前だけ、とが部分的に、といった参加の仕方に留まっていた。それが1年半前に現職に転職してからは、そうした制約がなくなり、であれば久々にフルで聴講してみたいし、界隈の友人知人ともコミュニケーション取りたいと思ったのだった。

---

今年の会場も、去年に引き続き立川ステージガーデン。同じ会場だが、その雰囲気はがらりと変わっていた。これは本当に驚いたのだが、会場後方、ステージと反対側の壁がオープンになり、外（スポンサーブースエリア）と繋がることで、開放感はもちろん、聴講しながらもホール外のコミュニケーションが伝わってくることで、肩肘張らない自由さも感じることができた。

セッションに関してはまた別に投稿しようと思うが（会社のブログで書くかもしれない）、Day 2 最後 Klemens Strasse 氏のアクセシビリティに関するトークは今も心に残り続けているし、Day 3 は元 SwiftUI チームのエンジニア Natali Panferova 氏のプレゼンテーションに Apple 内のプロセスを垣間見られて興味深かった。他にもLTでは、ルビ描画や Embedded Swift、CRDT に関するトークが面白かった。

また個人開発者の登壇も多く（今年こそはアプリリリースするぞと毎年言っているが）改めてインスピレーションを受けた。

話は遡るが、Day 1 のワークショップは Paul Hudson 氏の 「High-Performance Swift」に参加してきて、デンマーク（確か）から来日したエンジニアとペアを組んでサンプルプロジェクトの性能改善に取り組んだ。限られた時間しかない中で原因特定するにはかなり頭を使ったし、Instruments の使い方は知識だけでなく実際のシーンに即したワークだったので、さっそく仕事で活かせる応用力が身についたと思う（というか、よっぽど性能課題ないと Instruments を使おうという発想にならなかったが、ワークショップを経てちょっとした違和感をきっかけにどんどん活用していこうと思えた）。

---

スポンサーブースもよりどりみどりで、今年はスタンプラリー完走、豪華景品もいただいた。

今年は目論見通り、ほぼ全セッションを聴講できたので学びや刺激多く、何より既知の方、新しく知り合った方と、多くの方とお話しできたのも嬉しかった。ただ、、せっかくの国際カンファレンスの場なのに、筆者のなんちゃって英語力だと表面的なコミュニケーションに留まってしまう点、そろそろ卒業したいと痛感した三日間でもあった。というわけで来年に向けて「ちゃんと」英語力を上げていきたい。

最後に、カンファレンスを支えたスピーカー、オーガナイザ、スタッフの方には心から感謝！

前回初開催だった、五反田.mobile の第二回はデザインがテーマ。間違って前回の開催場所だったウェルスナビさんに行ってしまい、1セッション目は間に合わなかった。

AIコーディング時代におけるデザインとの連携をどう滑らかにするか？を考えてはいるものの、エンジニアサイドは自発的に様々な工夫をする一方で、デザイン側との接点については手探り感があった。今回そのヒントがいくつか得られて良かった。

パネルディスカッションは、プレゼンター以外の社員さんの参加もあってエピソードが豊富だったし、またプレゼンテーションという粒度外の話もてんこもりで（そういえば、みたいな思い出しもあり）素敵な試みだった。

イベントページ：https://gotanda-mobile.connpass.com/event/382518/

---

Figmaを使ったAI駆動モバイルアプリ開発

@naoele_dev さん

• よくある失敗例
  • レイアウト設計（Auto Layout, Constraints）
  • コンポーネント設計（Components, Variant）
  • トークン設計（Color, Theme）
• 失敗原因：Figma の設計が曖昧だから
  • Frame 名が初期値のまま→意味のある命名がされている
  • 手動配置されている、色が直接指定されている；Auto Layout や Variants を使っている
  • コンポーネントを使ってない
• レイアウト設計の悪い例、良い例
  • 重要なのは、レイヤー構造がコード構造になる（Auto Layout, Constraints）
  • 意味のある名前をつける
    • → Figma のデザインデータそのままで生成される（クラス名や変数名にも反映される）
  • Auto Layout = Stack, Column
  • Figma の Constraints: サイズが変わった時に、中のTalkで部品がどの様に振る舞えウカを決める（寄せ方）
• コンポーネント設計の悪い異例、良い例
  • 状態ごとに別コンポーネントになっているのは悪い例
  • 一つのコンポーネントに Variants が指定されていて、状態管理されている
  • UI部品をメインコンポーネント化し、Variants に切り出すと、その差分をAIが理解してくれる
• 絶対ルール
  • 数値を直接書かない、Design Token 化する
  • AIのためでも、将来の自分たちのためでもある
• Figma は絵を描く場所ではない、恒常を定義する場所
• チェックリスト
  • Auto Layout を使っているか
  • Frame 名に意味があるか(ListItem みたいな名前になっているだけでも違う)
  • Variantsで差分を表現しているか
  • Token を参照になっているか

iOSデザインシステムとデザイナーと連携した取り組み

ひなっこ さん

“聴講メモ：五反田.mobile Vol.2 – モバイルアプリデザイン最前線” の続きを読む

久々のイベント物理参加。冒頭から高密度なAI活用に関する発表が続いて、AIの勉強会かと錯覚した。が、それほどにAI活用が「AIすごい！」を超え、エンジニアのコーディングにとどまらずQAや顧客対応にも浸透していると感じた時間だった。発表の中で、Claude Code/Copilot/Devinの使い分けの勘所に言及されていて参考になった。仕様駆動が当たり前の様に語られていて、弊社でも実践している。ただ「仕様駆動」で満足するだけでなく、いかに効率性や確実性を高められるかに、世の中の関心ごとが移っていることは明らか。こうした会を通じて各社のナレッジに触れられるのは大変ありがたい。

イベントページ：https://mobiletechflex.connpass.com/event/381976/

---

AIとなら実現できる事業と品質のシン化の両立

@a_key_bako さん

• シン化とは？
• AIによる外部環境の変化（CodexでSoraが28日で）
  • 専門のAndroidチームがいたわけではなかった
  • 爆速で使えるが、品質要求は自ずと高いものが要求される
  • 各社のAI活用法や課題共有に価値がある
• 現状
  • Deploys/Developer/Day 指標の変化推移
  • デプロイされた数を、開発者x営業日で割る
  • 1を超えた：かなり高い
    • Mobileはデプロイを意識しない：masterブランチへのマージ数をdeployとカウント
  • 変わったこと
    • ジュニア：アウトプット出しながら学習（先輩への質問以外という選択肢）
    • シニア：自身の知識が生産性に直結（ボイラープレートをAIに任せる）
  • 役割での使い分け
    • コーディングはCC、レビューはCopilot、越境はDevin（テストケースを尋ねたり、いろんな職能が使う）
    • CC：低コストでペア作業
      • CLAUDE.md、git worktree、ghコマンド（巨大PRの分割もスムーズ）
    • Devin：
      • 専門街プラットフォーム越境に便利（mobile→BE）
      • 作業プロセスがチームに見える
• これからの課題
  • 課題1：技術的夫妻
    • 返済はできない
  • 課題2：AI活用の限界
    • 今のプロセスだとせいぜい一人ができることの効率化で限界がある（2倍にはなってもそれ以上には）
  • 納期ベース下での事業と品質のトレードオフ
    • リソースが潤沢でないと大規模リファクタリングができない
    • 課題をブレストすると、課題の洗い出しと優先度づけをした（重要度、漸進可能性、楽しさ）
      • 重要度：プロダクトへの影響度→やらざるを得ない
      • 漸進可能性：少しずつ進められるか（Viewごとに進められる？画面ごと？or一気に置き換え必要？）
        • 高いものはAIによる自律的置き換えに向いている
      • 楽しさ：学びの多さ、賞味期限→投資効果が高い
• AI支援によって、専門外でも一定品質でコード生成可能に
  • ガードレイルの重要性が増す
  • 原理原則をガードレイルにする

OSアップデート：年に一度の「大仕事」を乗り切るQA戦略

@Myamaguchi75201 さん

---

• OSアップデートはなぜ大仕事なのか
  • リリースが多く、クライアントによって機能の紐付け設定が多様
  • OSアップデートによる調査工数が増大
  • リグレッションテストケースが肥大化
• 現状のテスト戦略の課題
  • テストケースが肥大化しQAリソースが不足
  • 機能仕様の理解の属人化（QA担当者が一番詳しい）
  • 担当者による観点粒度に差分
• 対策
  • 観点粒度を汎用的にし、テストケースを見直し
  • テスト自動化（勉強会を開催し共有）
  • ↑アウトプットのテストコードをGitHubで一元管理
  • 相互機能影響をAIで抽出（過去実施のテスト観点や実装PRを用いて）

“レビュー”だけだったAI活用から半年。ヤプリのiOS開発・運用はどう変化したか？

@ko_yack さん

• 活用深化と活用領域のマッピング
  • チームでの半年前はコーディングとレビュー
  • CCに設計テストレビューするまで全て行っている
  • アプリビルドはDevin経由
  • 問い合わせ調査はAtlassian Rovoでエンジニアが一時解凍できる様に
• CCの活用における課題
  • コンテクストの枯渇：AIが参照不要な情報を読み取ろうとし、コンテクスト枯渇し忘却する
  • AI用ドキュメントをどこに置くか：CLAUDE,mdだとツール入れ替えた時にスイッチできない
  • 広い範囲の修正をしたい
  • メンバー習熟度の違い
• 課題の解決
  • ドキュメントの構造化：root.instructions.mdを起点として、アーキやコーディングプラクティスを記載する
  • ドキュメントは読むべきタイミングと参照先をセットで管理し、無駄な参照を防ぐ
• Spec-Driven Development (SDD) の導入
  • Proposal phase, Research & Planning phase, Implementation phase, Retrospective phase
  • フェーズごとにsubagentで分ける
  • 例: Swift移行のために、設計やマイグレーションのナレッジを構造化
  • 例: iOSで作った設計ドキュメントをもとにAndroidでもなぞらせた
• Snapshotテストを導入
  • UIテストもAIに自律的に修正させる
• Skills の活用
• 問い合わせチケット切られたらRovo AgentにJiraなどの情報をRAG経由で参照させ、回答させる

謎現象の解決手段を発見して プチ英雄になりました

@shiosioco40 さん

• Androidだと、React移行後JSInterface経由のインタラクションができなくなった
• zod: プロパティアクセスと呼び出しの分離が原因
  • 参照と実行顔同時でないとJSInterfaceのメソッドをWeb側が実行できない
• 回避策：JSInterfaceの参照を無名関数でラップする（アクセス実行の寸前まで触れない）

Claude × Markdown で仕様書をいい感じに管理したい

@AtriaSoft さん

• Claude Code を使った仕様書作成管理の便利さと課題
• 仕様書の老朽化問題（Confluenceの最終更新が2年前、、）
  • メンバー入れ替わりでメンテナンスが宙ぶらり
  • エンジニアに書くモチベーションがない、余裕がない
• サブエージェント4体
  • reader, writer, reviewe, simpler(簡潔に書き換える)
  • 自然言語で指示したら、readerが既存仕様書やコードベースを読み解いて、writerに渡して仕様書を作成、更新。reviewrがその仕様書の生合成をチェックし、simplerが仕様書を簡潔に書き換える
  • エンジニアがレビューしてPR、レビュー、マージ
  • honkitを利用して、mdファイルは見やすい形にエクスポート
• 良かったこと
  • 「書く」でなく「レビューする」で知り的ハードルが激減
• 課題
  • 出力が冗長になりがち、コンテクスト共有に最適化されていない、図表表現に限界（Mermain導入したい）

Kotlin Multiplatform + iOS アーキテクチャの実践

株式会社ディップ 権 さん

• KMPの実運用での使い分け
• ビジネスロジックをKMP共有、UIは各OSネイティブ
  • Presentationは書くOS
  • sharedで、Domain/DataをKMP共有
  • modelはPure domain model
  • データ変換フローは、
    • Entity
    • DTO
    • Model
• iOS側のUIアーキテクチャ
  • 画面ごとの状態管理がバラバラだと、状態遷移の追跡とKMP連携の責務分離が難しくなる、自作アーキテクチャ(Store Pattern)を採用（Intent(ユーザー操作)/Store/State/View）
  • iOS側はMVIをStore Patternで実装し、Android MVIと読み方揃t、チーム認知を統一
  • ObservableでState変更を購読
• Store Patternのメリット
  • 複雑な機能にスケールしやすい：小規模から大規模まで設計を継続可能
  • チーム運用しやすい：Androidと似た設計で読み方統一、UIイベントの扱い方を共有化でき、レビュー観点揃えられる
• KMPのSwift側の呼び出し体験をSKIEで改善
  • 今後、Swift Exportで、Obj-Cヘッダ経由の負荷を減らせる可能性があり、experimentalだが、よりSwiftらしいAPI公開に期待

バイトルiOSアプリのリアーキテクト / SwiftPMとAIルールで実現するモジュール設計

株式会社ディップ 宮川さん

• 20年以上続くシステム課題の解消
  • ドメイン駆動設計、AI前提の開発プロセス、AIネイティブな体制
• SwiftUI、デザインシステム、KMP、Strinct Concurrency Checking…
• Swift Package Managerによるパッケージ管理
  • 分割の基準、機能画面ごと、外部依存の隔離(Firebase, KMPなど)、再利用性の担保(UI components, design system)
  • 全体構成が把握しやすくなり、循環参照を抑止できた
• SwiftPMにおける課題
  • KMPなど外部に依存している状態で、SwiftUI Previewが不安定（タイムアウト）
  • 外部サービス依存のモジュールを限定的にし、protocolやmockのみを定義したInterfaceモジュールを定義し、中間に挟む様にし、KMPなどへの直接依存を回避した
    • poinfree / swift-dependencies により実現
• AIコーディングによる課題（CC）
  • 意図しないモジュールにコードが生成される
  • モジュールごとに定めた依存関係のルールを守らない
  • CLAUDE.mdに全ルールを記述していたが、コンテクスト肥大化するため、.claude/rules/を活用して最適化した
  • レイヤー概念を導入してルールをシンプル化：モジュール数の増大で依存関係が複雑化する、AIにとっての認知負荷も増大するため、モジュールの責務ごとにグルーピングしたレイヤーを導入した（同じレイヤーは、同じ依存ルールに則る）
  • ruleファイル自体が設計ドキュメントとして機能

2026年初めての勉強会参加は、英語話者向けのモバイル勉強会、Mobile Dev Japan。記念すべき10回目の開催に初参加してきた。

イベントページ：https://mobiledev-japan.connpass.com/event/376753/

会場はU-Nextさん。LTは、git worktree の紹介や、React Expo と AI によるアプリ開発、そしてマップサービスの抽象化OSS開発について。LTの数自体は少なく、会社紹介とネットワーキングがメイン。会場内は当然英語話者が多く、何人かと技術やお互いの仕事について話したのだが、筆者の拙い英語にも熱心に耳を傾けてくださったおかげで、楽しい時間になった。

ここ最近は英語で話す機会がめっきりなかったので、大丈夫だろうかと不安だったが、日本人の知り合いや登壇者とは日本語で話したし、日本語話せる方とは途中で日本語にスイッチしたりしたので、100%英語というわけではなかった。

いつか英語でプレゼンしてみたいと思っているのだが、このイベントはおよそ2か月おきに開催されているようなので、今年中には英語登壇できるように頑張りたい。

Yappli さん本社に遊びに行きたい！という一心で PdM という畑違いの勉強会に参加してきた。

イベントページ：https://yappli.connpass.com/event/373235/

畑違いとはいえ、いちサービス開発に関わる身としては頭にいれておくべき内容で良かった。特に、AI 活用してリーンに MVP 開発するというプロトタイプ思考は、Vibe Coding 時代だからこそあらためて実践したいと思った。

素敵すぎるボトル。

元起業家PdM、AIで”爆速MVP検証”を実現した話

リャオス さん

• クロスセル、価値拡大は 0→1
  • エンジニアリソースを使って検証する余力なく、一発で当てたいが、検証なしで始めるリスクは大きい
  • 小さく始めてしまう
• 1週間でMVPプロトタイプ
  • 競合調査：DeepResearch
  • (MAツールの)代表的な機能リストを作成：Cursor
    • 機能イメージができてくる
  • プロトタイプ構築：v0
  • MVP検証
  • ユースケース検証
• 0→1の壁が消えた
  • リーン：顧客に聞け、正解は顧客が知っている（マーケットイン）
  • 0 to 1：顧客に聞くな、競合せず独占しろ（プロダクトアウト）
  • AI エンジニアを使って、エンジニアが作ったのと同等の精度で検証可能
• 顧客の優しい嘘
  • アイデアに対して「ぜひ欲しい！」と、使う立場としてのニーズは違う
  • MVP いきなり作って渡すことができる
  • 顧客ヒアリングの時間が取れない問題
  • 「リアルな拒絶」を早めに引き出す
• 開発フローの再定義
  • リーンスタートアップにおけるBMLループのどれもはしょれず、ただ爆速になっただけ
  • 「学習」もサボれない：なおいっそう頑張るポイント

Yappli流！「プロダクト改善」の進化といま

仲道 さん

• プロダクト改善の推進
  • 要望、アイデア、技術負債の解消
• 改善がなかなか進まない
  • チケットが減らず増える
  • 工程が進まないチケット
  • プラットフォームごとのリリースがばらける
  • 問い合わせに追いつかない
• チケットが進まない原因：量、優先度、担当者不在、何度、リソース不足
  • 改善要望がリリースよりも多くなりやすく、避けにくい。この溝が深くなると、
  • 改善されていないことでチャーンする
  • 多部署からの信頼低下
  • 開発チームのモチベ低下
• 解決方法
  • チケット残数の把握、認識を揃える、担当者を把握するなど、PdMがチケット診断者になる
  • チケット状況を把握する
    • PdM内で対話型の確認会（一人では無理）、判断軸をログとして記録して残す
  • やらないものを決める
    • 一定期間経っている、要望の熱が冷めている（要望が出続けているものはニーズ高いと判断）
    • 呼応数見積により区分分け、大規模開発は「改善」から移動。アサイン待ちになってしまうため
• ブラックボックス化していたチケットボードをPdMがハブになり要望の集約、状況確認、共有
  • 優先順位、増減傾向が明確
  • やるべき　のみがあるチケットボードの健全化
  • 他部署連携がスムーズになり、調整コストを減らせた
• フロー整備だけでなく、社内周知でメンバーへの浸透も

先日の visionOS TC でお話しくださった方がXで登壇を宣言されており、存在を知った本イベント。これは行かねばと突発的に参加してきた。初手からシホさんの「喋る胸像」プレゼンが面白すぎた。visionOS TC でも感じたことだが、映像系の発表が充実していたり、ハッカソン成果物の体験づくりや、作りかけの進捗報告もあり、幅があって楽しかった。

懇親会で、例の喋る胸像を実際に動かしているところを見させていただいたが、アイデアが個人的に刺さりまくった。物理オブジェクトのツインを作ってまるっきり重ねることで、現実と仮想を行き来しても、オブジェクトを起点に連続性が担保されたり、オブジェクトに魂が吹き込まれるような感覚があって、色々と考えさせらる作品だった。

LODGE XR でも特に Tech に焦点を当て、非定期に開催しているとのこと。比較的小規模で（visionOS TC 参加者に限らずXR界隈の常連が集っている感じ）和気藹々とし、次回は筆者も登壇してみたいと思った。

イベントページ：https://vrtokyo.connpass.com/event/376905/

---

喋る胸像体験「AlbusTalk」の作り方

@41h01 さん

• アルバートくん
• 現実の鏡像が動き出して会話を始めるMRタイプ
• Unity 6.2 + Polyspatial
• ObjectTrackingで3Dプリント胸像に3D鏡像モデルを被せる
  • 公開モデルをBlenderで編集
  • FlashPrint にデータ取り込み、プリント中に崩壊しないよう支柱を設定
  • Avatar maker Pro 利用してリップシンク対応モデル作成
    • BlendShape が自動で作られる
  • 瞳孔用テクスチャを当てて目を作成
    • BlendShape でランダムに瞬き
  • uLipSync + BlenderShape で口パク
• トラッキング
  • KiriEngine で胸像3Dスキャン、Core ML で学習、Refarence Object Library に設定
  • ARTrackedObjectManager 経由で、認識タイミング、位置、角度が取得可能
    • 動きに対してはトラッキング遅延あり
• OpenAI Realtime API (gpt-realtime)
  • 入力音声をbase64stringに変換、API連携
    • uLipSync 月の AudioSource に流して口パク
  • Instruction で人格定義
• 体験の流れ
  • タイトルロゴ〜目覚め〜会話〜就寝〜エンドクレジット
  • しゃべりっぱなしでない
  • 胸像を触り目覚めをトリガー
    • 現実の鏡像位置に3Dモデルを配置しているので、コライダー設定して接触判定
  • ユーザー起因でないスクリプトは固定テクストプロンプトを OpenAI に流す
    • 流れを指定することで、そのままでなくとも守ったセリフを喋ってくれる

360°動画をVision Proで没入再生する新フォーマット実装 — Good Sleeperアプリの移行事例

@tochi_jp さん

“聴講メモ：LODGE XR “Tech” Talk #2 – visionOS” の続きを読む