プロポーザル

Gemini APIによる動画解析とScreen Time APIを組み合わせ、「腕立て100回が自然に続けるアプリ」を開発しました。
筋トレ継続の課題は、「習慣化の難しさ」と「記録の面倒さ」。
これを解決するため、カメラで撮影した筋トレ動画から回数を自動カウントするAIと、アプリを自動制限するScreen Time APIの融合でこの課題に挑戦しました。

特に注力したのが、プロンプトエンジアリングによるAI精度の改善。
以下の6ステップでプロンプト実装を進めていきました。

① 期待アウトプットの定義
② シンプルなプロンプト作成
③ 単一映像での検証
④ ズレの特定と修正
⑤ 別映像での汎化確認
⑥ 複数プロンプトの統合

この手法により検出精度が40％から95％へ飛躍的に向上し、動画内に音声を含めることでさらなる改善を実現しました。

また、Screen Time API（DeviceActivity, ManagedSettings, FamilyControls）を組み合わせ、目標未達成時に娯楽アプリを自動ブロックする機能を実装。
ユーザーの意志力に頼らず、強制力のある習慣化を実現しました。

本LTでは、AIの利活用に役立つ
プロンプトエンジアリングの実践的アプローチと、Screen Time APIのリアルな活用知見を実際にリリースしたアプリを元にお話しします。

「生成AI 」で新しいユーザー体験を作りたい方に、具体的なヒントを持ち帰っていただける内容です！

現代のServer-Sideにおいて、Observability（可観測性）は必須の存在です。マイクロサービスやCQRSなどの分散システム、サーバーレスモデルでは、ログ・メトリクス・トレースを集約して観測できることが運用上必須となっています。
Server-Side Swiftを採用する際、主軸として使う場合でもマイクロサービスの一部として導入する場合でも、OpenTelemetryなどの業界標準との連携は避けて通れません。
本トークでは、Apple公式のswift-log、swift-metrics、swift-distributed-tracingの役割と連携方法を解説し、OpenTelemetryを通じて様々な監視サービスと接続する方法を紹介します。

実践的なライブデモ
Vapor + AWS Lambdaを使用したCQRS/Event Sourcingシステムの実装を通じて、AWS CloudWatchとX-Rayによる分散システムの監視を実演します：

• 分散トレースによるリクエストの流れの可視化
• Lambda関数間の呼び出し追跡
• イベント処理の監視
• 処理速度のボトルネック特定

SwiftはiOSアプリ開発で培った型安全性と高いパフォーマンスをサーバーサイドでも活用できます。CQRS・Event Sourcing・Serverlessのような複雑な分散システムこそ、Swiftの強力な型システムとApple公式の監視ツールが真価を発揮します。
Server-Side Swiftの導入を検討している方、本格的な運用に向けて準備したい方に、実践的な監視システムの実装方法を提供します。一緒にServer-Side Swiftで本番環境に耐えうるシステムを構築する一歩を踏み出しましょう。

「アクセシビリティ機能を使用してこのコンピュータを制御することを求めています。」

macOSでアプリを初めて開いた際、このような許可ダイアログが表示されたことはないでしょうか。
ダイアログの内容からはどのような許可を求めているのか理解しずらいですよね。

実はこれ、かなり強力なコンピュータ制御の権限を得ようとしていることをご存知でしょうか。
この権限を使えばキーロガーや画面監視アプリなんて簡単に作れてしまいます。

そんなことを知らずに何気なく許可していた方は、本トークでmacOSのセキュリティリスクを再確認することができます。
アクセシビリティの許可をすることでどのような処理ができるのかをコードベースで理解し、そこからどのような危険性があるかを説明していきます。
ただし、危険とは言いつつも開発者としては非常に面白い機能も使えるようになるため、技術面でも興味深い内容となっています。

AIによって自動化が急速に進化する今だからこそ、コンピュータの制御を可能にするアクセシビリティの許可は正しく理解しておく価値があります。
きっとみなさんのMacにもアクセシビリティ許可をしているアプリがあるはずです。

ぜひご覧ください！

Apple Style Guide は、Apple 製品に関する用語や表現のガイドラインです。UI やドキュメントでどのような言葉、どのような表現を使うべきかが記載されています。

Apple のガイドラインといえば、Human Interface Guidelines があります。これは iOS アプリ開発者に必読のガイドラインとして知られています。一方 Apple Style Guide のほうは、よく知らない開発者も多いのではないでしょうか。しかし実はこれも知っておくべきガイドラインです。このガイドラインに従うことで、ユーザーの混乱を防止できます。

たとえば、「Apple ID」ではなく「Apple Account」が正しい表記です。Apple Style Guide を読めばこのような適切な表記がわかります。不正確な表記は、アプリやドキュメントの信頼感を損ねます。

また、「クラッシュ」という表現は UI やドキュメントでは避けるべきです。読者によっては、ハードウェアやソフトウェアの損傷を連想するかもしれません。代わりに「予期せず終了する」「応答しない」などの表現を使います。こうしたことも Apple Style Guide に記載されています。

Apple Style Guide は他にも、インクルーシブな記述、数値や単位の表記、コードなどの技術的な表現、国際的スタイルでの表記について書かれています。多くのユーザーにアプリやドキュメントを利用してもらうために、重要な内容です。

本トークでは Apple Style Guide から、iOS アプリ開発のために知っておきたい内容をピックアップして解説します。正確な表記やよりよい表現を知り、アプリの信頼性を向上させましょう。

Swift Testing は Swift 言語でユニットテストを行うためのフレームワークです。昨年リリースの Swift 6 に組み込まれました。本トークでは、既存プロジェクトに Swift Testing を導入し、実践的に活用していく方法を説明します。

Swift Testing は従来のテストフレームワークである XCTest と共存できるため、既存プロジェクトへの導入がしやすくなっています。新しくユニットテストを追加するタイミングが、最も Swift Testing を導入しやすい機会でしょう。あるいは、既存のユニットテストを Swift Testing で書き換えるのも難しくはありません。

しかし、XCTest と Swift Testing とでは挙動が異なる場合もあるので注意が必要です。例えば、Swift Testing ではデフォルトでテスト実行が並列処理となるため、単純な移行ではテストが失敗することもあります。また、非同期処理のテストにも考慮すべき点があります。これらの課題に対し、どのような注意が必要で、どう対処すれば良いかを具体的なコード例とともに解説します。

さらに、Swift Testing の特徴的な機能であるパラメトライズテストの導入方法と、それによって得られるメリットについても実例を交えて紹介します。効果的に活用することで、既存のテストコードを整理し、より保守性の高い形に進化させることができます。

本トークを通じて、Swift 6 時代のモダンなテスト手法を身につけ、iOS アプリ開発の品質と開発効率の向上につなげましょう。

「皆さん、もうMCPデビューしましたか？」
LLM活用の真価は、私たちの開発環境が持つ「コンテキスト」をいかに伝えるかにかかっています。
本セッションでは、その答えとなる「Model Context Protocol (MCP)」が、いかにしてiOS開発を根底から変革するかを、具体的な実践例と共にお話しします。

Figma MCPの連携より、デザインデータそのものをコンテキストとしてLLMに渡すことで、面倒な手作業による実装は過去のものとなり、デザインから実コードへの変換がシームレスに実現します。

ローカルMCPサーバーを実装し、あなたのMacをAIの忠実な"手下"に変える方法を解説します。
自然言語で指示を出すだけで、AIがgit操作、ビルド、UIテストといった定型作業を自律的に実行。あなたは創造的な作業にのみ集中すればよいのです。

MCPの可能性は無限大です。将来的にはGitHubのような外部サービスや、社内の内部管理画面ともMCPで連携し、開発に関わるあらゆる情報を繋ぎこんでいきます。

「世界をMCPで繋げる」

みなさまが抱えるプロダクトはSwift6へのマイグレーションが済んでいますか？
中には鋭意対応中の開発チームもいるかと思われます。
そんなあなたに「Take your time」と伝えたい...。

Swift 6.2では、Swift Concurrencyの機能が大幅に改善され、これまでのスレッドセーフなプログラミングの考え方がより簡潔になります。
このセッションでは、実際の開発現場でのマイグレーション経験をもとに、従来のSwift 6対応がSwift 6.2によってどのように変わるのかを詳しく解説します。

QA依頼、面倒だと思ったことはありませんか？

私たちのチームでは、PRごとにQA依頼を行っており、従来のフローは「ビルドの設定・配信」と「SlackでのQA依頼作成」という、手間の多い作業が分断された状態でした。しかも、どちらにも同じような情報を手動で入力する必要があり、非効率でミスも少なくありませんでした。

そこで私は、このフローをスクリプトとXcode Cloudを組み合わせて自動化することにしました。今では、スクリプトへ最低限の入力をするだけで、ビルド配信からSlackへのQA依頼投稿までが一気通貫で完了するようになり、手間もミスも激減しました。

ここに至るまでの経緯を失敗したパターンも含め紹介します。Xcode Cloudの導入を検討している方にとっても「どのくらいのことができるのか」「どこでつまずくか」などのリアルな参考になる内容をお届けできればと思います。

iOSアプリの配布方法というと「AppStoreで公開」か「社内配布（MDMやTestFlight）」の二択だと思っていませんか？ 実はAppleは、企業や団体向けに「Custom App（カスタムApp）」という第三の配布形態を提供しています。 この配布方法は、App Storeを利用しながら、あらかじめ指定した対象者のみにアプリを安全に届けることができる仕組みです。 業務アプリやパートナー限定アプリなどに非常に適していますが、認知度はまだ高くありません。

本セッションでは、AppStoreの配布方法の進化を振り返りつつ、Appleが提供する「パブリック」、「社内配布」、「プライベート（Custom App）」という3つの主要な配布手段の違いや選定基準、審査プロセス上の違い、組織的な利点や制約をわかりやすく整理します。 私が実際に全国約400店舗に向けた業務アプリの配布をCustom Appを用いて行ったので、それにまつわる経緯や運用方法を交えつつお話しできたらと考えています。

「社内用アプリだけどAppStore配信もしたい」「審査が不安」「配布先を限りたい」──そんな悩みを持つiOSエンジニアやIT管理者にとって、“Custom App”は強力な武器になります。あまり語られることのないこの配布手法の実際を、現場の視点でお届けします。

本トークでは、Kotlin Multiplatform (KMP) を利用したアプリ開発で、AndroidとiOS共通のビジネスロジックにおける状態管理とデータベース（DB）設計を、GitHub Copilotで効率化する方法を紹介します。

KMPはコード共通化の利点がある一方で、KotlinコードがiOSエンジニアには分かりづらく、状態やデータの流れが複雑になりがちです。また、ローカルDB導入時には、テーブル間のリレーションや各カラムの役割が不明瞭になる課題も多くのプロジェクトで直面します。

そこで本LTでは、Copilotを活用した2つのアプローチを提案します。

まず、Copilotを活用したDBのリレーションとカラムの役割の可視化について。既存のSQLスキーマやKMPデータクラスから、Copilotがどうリレーションを推論し、カラムの役割を可視化するのかを具体的なプロンプト例を交えて示します。これにより、複雑なDB構造を把握し、設計のボトルネックを早期に発見できます。

次に、Copilotによる既存の状態の可視化に焦点を当てます。KMPアプリの状態管理は様々ですが、時間の経過で状態遷移や依存関係が複雑化しがちです。Copilotが既存Kotlinコードから状態を解析し、状態遷移図や関連イベントの流れを提案・可視化する方法を探ります。これもCopilotへのプロンプト例を通じて、アプリの内部状態理解と予測可能な状態管理構築のヒントを提供します。

ウォンテッドリーのモバイルアプリでは、Kotlin Multiplatform（KMP）を使ってビジネスロジックを共通化しています。
一方で、iOSエンジニアにとってKotlinは馴染みが薄く、不安を感じる方も多いのではないでしょうか。
私自身、Swift中心の開発を続けながら、1年間KMPを導入したプロジェクトに関わってきて、「iOSエンジニアとしてKMPとどう向き合うべきか」を日々模索してきました。

本セッションでは、私自身がこの1年で得た、iOSエンジニアとしてKMPと関わるうえでの学びと工夫を、以下の3つの観点から共有します。

1. 設計の重要性
   ウォンテッドリーではビジネスロジックを担うReactorの設計書を書いてチーム内でレビューをしてから実装を行います。丁寧に設計を行うことで、出戻りや仕様のズレを防ぐことができ、KMPとiOS側の開発がスムーズに連携できるようになります。

2. Preview駆動開発との相性
   ロジックとUIの責務を明確に分けることで、Previewによる効率的な開発が可能となり、KMPの共通ロジックとも無理なく共存させることができます。

3. AI活用によるKotlinのキャッチアップ
   Kotlinに不慣れな立場でもAIを活用することで、レビューや仕様理解がしやすくなり、日々の開発に必要な知識を実践の中で補うことができます。

このセッションが、KMPの導入に不安を感じているiOSエンジニアや、導入を検討しているチームの方々にとって、実践的なヒントや前向きな視点とともに、成長の機会になると思えるきっかけになれば幸いです。

RxSwiftのコードを読んでいくと、Observerパターンやイベント伝播の考え方など、「プログラミングの基礎」に立ち返る瞬間があります。本LTでは、RxSwiftの代表的な要素（Observable, Observer, Subscribe, Dispose）を題材に、実際のソースコードを一部追いながら、そこにある基本的な仕組みを解説します。
たとえば、イベントの購読処理はどう保持され、どこで通知が発火するのか？この流れを理解することで、RxSwiftが単なるライブラリではなく、基礎的な設計原則に沿って構築されていることが分かります。
また、こうした理解は、CombineやSwiftUI（@State, @Publishedなど）の仕組みを学ぶ上でも大きな助けとなります。
リアクティブなコードに苦手意識を持つ方や、ライブラリの「中身」を通じてプログラミングを深く学びたい方に向けて、基礎を見直すきっかけとなるLTです。

「APIの開発が遅れていてアプリの開発が進めづらい…」

「このエッジケースの動作確認、どうやって確認しよう？」

「バグが検出されたけど、再現が難しい…」

多くのモバイルアプリ開発現場が、このような課題を抱えているのではないでしょうか。

これはエンジニアの開発作業だけにとどまらず、PdM やデザイナー、QAメンバーにとっても悩みの種となっていました。
アプリの最新仕様の動作確認がスムーズに行えないことで、仕様検討に時間がかかったり、デザイン作成やテスト設計において考慮漏れが発生したりすることがあります。

こういった問題により、職種間のコミュニケーションコストに悩まされ、結果として開発全体のリードタイム増大に繋がっていました。

この根深い課題を解決すべく、iOS / Android アプリで共通の仕組みで利用できる Mock 環境「Hobart」を開発しました。

「Hobart」はエンジニアだけでなく、PdM・デザイナー・QAメンバーなど他職種の方々の業務効率の向上に寄与しています。

下記を中心に、モバイルアプリ開発全体を支える Mock 環境についてお話します。

• モバイルアプリ開発における開発効率低下の要因
• 「Hobart」の仕組みとそれを支えるデバッグモードの全貌
• 生成AIを活用した Mock データ整備の高速化
• 「Hobart」導入後の成果と今後の展望

本LTでは、単体テストのフレームワークをXCTestからSwift Testingへ移行したいと考えている方向けに、具体的にどのようにSwift Testingへ移行するのかを経験談を交えて紹介します。

WWDC24で新たに紹介されたテストフレームワークであるSwift Testingも、紹介されてから1年以上経ち導入事例も増えてきていると思います。
そのような情勢もあり、まだXCTestで単体テストを行なっているチームでも、Swift Testingへ移行していきたいというモチベーションが高まっているところも多いでしょう。
しかし、実際にSwift Testingへ移行するときにどのように移行するのが良いのか、どれぐらい大変なのかが掴めないとなかなか踏み出しづらいです。

本トークでは、実際に担当しているiOSアプリプロジェクトの単体テストをXCTestからSwift Testingへ移行した経験をもとに、以下内容についてお話しします。

• 実際の単体テストをXCTestからSwift Testingへ移行した手順
• 移行時の工数感
• 移行時に困ったこと

新しいフレームワークを導入するにあたって、メンバーを巻き込んでいく必要がありますが、実際にどのように説得して、導入まで漕ぎ着けたかというところまでお話しします。

実際に移行した経験からSwift Testing移行のよりリアルな知見を共有できると思います！
Swift Testing移行を考えている開発者にとっては、移行を検討する上で大きなヒントになるはずです！

プログラマーの資本と聞いて、あなたは何を思い浮かべるでしょうか？

これまで読んだ技術書の厚み？
経歴書に書ける経験の長さ？
チーム開発でうまくやっていけるソフトスキル？

いいえ、違います。

腰です。
それも健康な、腰です。

プログラマーの真の敵は刻々と変わりゆく仕様ではなく、集中力を阻害する腰痛です。
そんなわけで、健康な腰の維持のために職場や自宅で昇降式デスクを使われている方も多いかと思いますが、本当に「昇」してますか？
スタンディングデスクなのに最後にスタンダップしたのがいつだったか思い出せない人も多いでしょう。
いいえ、あなたを責めているわけではありません。
人間の意志とは実に弱いもので、楽な方に流れていってしまいます。

しかし、ご安心ください。
立つことが億劫になってしまうのなら、スタンディングデスクに一定時間毎に自動で上昇する機能をつけて、仕組みで解決してしまいましょう。
本LTでは、昇降デスク FlexiSpot、コントローラーとなる M5Stack、サーバーとなる Raspberry Pi, スマートホームを実現するOSSのHomeAssistantとを組み合わせて、FlexiSpotをスマホやパソコンから操作したり、時刻やアクションをトリガーに自動で昇降する機能を実現する方法をご紹介します。

【あらすじ】

社内で突然始まった、Swift 6対応プロジェクト。

しかし、iOSエンジニアはたった2人。
そのうちの1人は、「自分でやるのは面倒だから」という理由で、すべてをもう1人に丸投げしてしまう。

重すぎる作業量を前に、残されたiOSエンジニアは1人で抱えきれないと判断し、他部署や他社のiOSエンジニアなど、あらゆるリソースに声をかけて助けを求めた。

「Swift 6対応を乗り切るためなら、手段は問わない」
そうして集まった応援メンバーの協力もあり、プロジェクトは加速度的に進んでいく。

しかしその裏で、誰にも気づかれぬまま、少しずつ歯車は狂い始めていた。

ようやく作業が完了し、落ち着いたかに見えたその時、そのiOSエンジニアの前に現れたのは、思いもよらぬ「代償」だった…！？

このLTは「てんとう虫コミックス ドラえもん5巻収録『ドラえもんだらけ』」のオマージュです。

本LTでは、テストでHealthCareデータの登録が必要だけど毎回面倒と思っている方に向けて、データの登録を簡易に行うアプローチを紹介します。

HealthKitを用いたiOSアプリでは、テストの際にHealthCareデータの登録が必要になるはずです。
しかし、テスト用にHealthCareデータの登録を簡易に行うためのツールはAppleから公式には出ておらず、手動で登録を行うケースも少なくないでしょう。
手動での登録は、テストごとに煩雑な操作を伴うため、特にE2Eテストの自動化においては大きな障害となり、結果的にテストの工数が増加する要因となります。
私の所属するチームでもその課題に直面したため、試行錯誤の末、CLIコマンド一つで指定の端末に必要なデータを自動登録するツールを作成しました。

本トークでは、実際にデータ登録自動化ツールを作成したことと、それを業務で運用してみた経験から、次のような内容についてお話しします。

• CLIでHelthCareデータを登録する仕組み
• CLIでHelthCareデータ登録を実現するときにハマったこと
• 業務で実運用してみての感想

ツールの実装は単なるシェルスクリプトではなく、XCTestやシェルスクリプトを組み合わせて行いました。具体的な実装方法について、ソースコードを交えながら詳しく説明します。

HealthKitを使った開発をしている、もしくはこれからしようとしている開発者にとっては、テストの工数を短縮する上で大きなヒントになる知見を共有します！

皆さんのアプリでは、依存性注入（DI）の仕組みを効果的に活用できていますか？
私たちの開発する大規模モバイルアプリ『GO』では、コンポーネントベースのアーキテクチャを採用しています。
しかし、現在採用しているアーキテクチャ標準のDI機能では、コンポーネントの追加やリファクタリングの際に大量の定型コード(ボイラープレート)を手動で修正する必要があり、生産性や開発者体験の低下が課題となっていました。

この課題を解決するため、新たなDIフレームワークの全面的な導入を決定。
導入にあたり以下の2つの大きな挑戦がありましたが、これらを乗り越え、約半年という短期間で導入を完遂しました。

1. 500以上あるコンポーネント間の複雑な依存関係を考慮した、段階的な導入計画の策定
2. 並行して進む大規模な新規開発プロジェクトへの影響の最小化

本トークでは、導入前の課題分析から、開発影響を最小限に抑えた導入計画の策定・実行プロセス、そして開発速度の向上を達成するまでの実践的なアプローチについてお話しし、アプリ全体に影響する大規模な技術刷新を計画・実行する上での勘所や注意点を共有します。
このトークでお話しする内容が、アプリ全体へのDIフレームワークの導入時の注意点や、アプリ全体に影響する大規模な導入時にどのような点を考慮するべきかなど、皆様のアプリ全体を見据えた改善活動を進める際の一助となれば幸いです。

会場でお会いしましょう！

WWDC 2025においてSwift製のContainerization Frameworkがオープンソースで公開され、主にバックエンドエンジニアの間で注目を集めました。
このセッションでは、普段Swiftを書くマジョリティであるネイティブアプリのエンジニアと、コンテナをよく知るけどSwiftはまだ勉強中の僕が交わる交差点として、Swiftで書かれたContainerization Frameworkの実装を深掘りします。
参加される皆さんがコンテナ技術やフレームワークの設計思想を理解することで、単にコンテナを立ち上げたり動かしたりするだけでなく、フレームワークを活かしたツールの制作などができるようになるかもしれません。
また、フレームワークの裏側で使われる幾つかのOSに近い部分や基礎技術要素についても触れることで、これまでのツールとの違いについても解説します。

チームでの実装・レビュー遅延やレビューコメントの反映漏れに悩んでいた経験から、Cursorを導入し「実装→レビュー→修正」の開発フローを効率化しました。本発表では、以下の８ステップでCursorを活用し、開発速度と品質を両立できたプロセスを技術的に解説します。

1. 実装方針をCursor上で共有し、建設的なイテレーションを回す
2. テストコードの叩きを用意し、細かく調整
3. ビルドエラー・テスト失敗を即座に把握して修正
4. 文言修正タスクへの迅速対応
5. ログ挿入→デバッグ→バグ修正サイクルの確立
6. チャットログから良い実装の振り返り・ナレッジ化
7. PRテンプレートによる統一された提出フロー
8. レビュー対応とCursorを使ったコメント反映の高速化

Cursor導入前後でiOS開発が如何ほど効率化されたか、導入を検討中のチームに即活用できる提案をお届けします。