プロポーザル

LLMの台頭は、これまで実現困難と見なされていた領域を一気に射程内へ引き寄せ、新たな価値創出の幅を大きく広げました。

その流れを受け、家計簿アプリを提供している弊社は昨年、LLMを活用したAIレシート読み取り機能をリリースしました。ユーザーがレシートを撮影すると、Vision frameworkが領域を検出してOCRを行い、抽出テキストをLLMで構造化することで金額・日付・店名を瞬時に取り出し、家計簿へ自動反映する体験を提供しています。

高精度を担保するために、カメラ映像からレシートを検出・追跡し、座標のブレが閾値以下になった瞬間に自動シャッターを切る仕組みを導入したり、得られたテキストは前処理してからLLMに入力することで推論の誤判定を低減しました。さらにInstrumentsでボトルネックを解析して処理レイテンシを最適化し、結果として他社アプリと比べても際立った読み取り精度を実現しています。

本トークでは、このようなレシート読み取り処理を構築する中で直面した課題と、それらを解決していく中で得られた実践的なノウハウを余すところなく共有します。
さらに発展的な内容として、WWDC25で発表されたRecognizeDocumentsRequestを活用したさらなる精度向上の展望と、Foundation Models frameworkによるオンデバイスで完結するレシート読み取りの可能性についてお話しします。

本トークが、ドキュメントOCRの更なる最適化やLLMをうまく活用した機能開発のための具体的なヒントとなりましたら幸いです。

長年にわたり、みてねiOSアプリにおいて、写真/動画のアップロード中にアプリを開き続けていないとアップロードが中断されてしまう課題に直面してきました。
具体的にはiOSのバックグラウンド実行の30秒制限により、アプリが中断されるとアップロードが停止してしまう問題です。このトークでは、アプリをバックグラウンドに遷移させてもアップロードを完了まで継続できるようにするために実施した解決策、経緯、そして今後の展望について紹介します。

解決策としては、アップロード中にバックグラウンドに遷移した際、ピクチャインピクチャ機能を活用してアップロード進捗を表示することで、バックグラウンド制限を突破しました。このトークでは、そこに焦点を当ててつつそこまでの経緯/苦戦したところ/制限についてお話しします。

• 正攻法であるBGProcessingTaskをなぜ採用しなかったのか
• ピクチャインピクチャによるアップロードの制限
• ピクチャインピクチャのUIカスタマイズの限界
• バックグラウンド遷移時に自動的にピクチャインピクチャを表示するための方法 / 苦戦したところ
• Appleのレビューを通過するための検証
• 特許の出願
• iOS26のBGContinuedProcessingTaskへの移行の可能性とその準備

このトークを通じて、同様の課題に直面している開発者の皆様に有益な情報を提供できれば幸いです。

Swift File数1700超のSansan iOSアプリでは、コーディングスタイルの乱れが開発効率を阻害する大きな要因となっていました。
この課題を解決するために、Sansanではフォーマッターによる数万行単位の大規模なフォーマットを不具合を発生させることなく完了し、今も一貫したスタイルが守られ続けています。
この取り組みから得られた、デグレのリスクを抑えて安全にフォーマットを進める方法を共有します。

トーク内容
1: スタイルの乱れが生産性に与える影響や統一することによる具体的な生産性向上効果の説明
2: フォーマットによって処理が変わってしまう具体的な事例や危険性の紹介
3: 数万行の差分をデグレリスクを抑えて安全に取り込むための戦略的アプローチ

対象となる方
・ チームの生産性向上に取り組んでいる中堅・リードエンジニアの方
・ コードフォーマットツールの導入を検討している方

Pull-Requestのレビューを依頼された際、レビューのために手元で作業中の内容を一旦スタッシュし、レビュー対象のブランチをpullして、Xcodeでプロジェクトをビルドするような経験はありませんか？

頻繁にブランチを切り替え、動作確認のためのビルドを行うと、数えきれないほどの時間がレビューのために使われることになります。

この課題解決のために動作確認用のTestflight版アプリを用意することも多いと思いますが、その場合もアプリのArchiveとアップロード、Testflight上で配信可能になるまで時間がかかります。
Testflight側のレートリミットも存在するため、Pull-Requestの内容が更新されるたびにTestflightにバイナリをアップロードするといったワークフローは組みづらいでしょう。

私たちのチームではこの課題に対して、手元でビルドすることなく、Testflightで配布可能になるのを待つことなく、Pull-Request上にコメントされたリンクをクリックするだけで動作確認できるワークフローを用いて大幅に時間と手間を削減しています。

本トークでは、私たちのチームで導入している動作確認を簡単に行えるようになるワークフローを他のチームでも導入できるように、以下の内容について紹介します。

• iOSにおけるビルド成果物の種類について
• 動作確認用のテストアプリの準備方法について
• Shopify製のツール「Tophat」を用いて、App Bundleを用いたシミュレーター上での動作確認方法について
• 検証したい対象と、それに応じたテスト版配布方法のプラクティスについて

このセッションを通して、Pull-Requestのレビュー体験を改善し、チーム全体の開発効率を飛躍的に向上させるヒントを得ていただければ幸いです。

StoreKit 2の登場により、アプリ内課金の実装は以前のStoreKitと比べるとかなり簡単に行えるようになりました。StoreKit ConfigurationやStoreKit Testingといったデバッグ・テスト環境も整備され、開発効率は大きく向上しています。

それだけに留まらず、WWDC 23ではアプリ内課金実装に利用できるSwiftUI向けのコンポーネントやModifierも発表され、UIの実装も提供されているものを使うだけ可能になりました。

その中でも SubscriptionStoreView というSwiftUIコンポーネントを使うことで、サブスクリプションプランの一覧表示からプランの契約まで、複雑な課金処理のビジネスロジックを開発者が書かずともサブスクリプション機能を提供できるようになりました。

このLTではStoreKit Configurationファイルを用いてテスト用の課金アイテムを用意し、SubscriptionStoreViewを用いたサブスク機能の実装を5分の制限時間の中でライブコーディングを行います。

StoreKitの進化を一緒に体感してみましょう。

iOS 26ではSpeechAnalyzerという革新的な文字起こしAIが登場し、プライバシーを守りながら高精度な音声認識をすることが可能になりました。
この技術は、Appleの音声技術やApple Intelligenceに支えられた強力なライブラリです。

このトークでは、以下の内容に焦点を当てます。
1: SpeechAnalyzerによる文字起こしの仕組みやアーキテクチャについての簡単な説明

• SpeechAnalyzer, SpeechTranscriber, AssetInventoryなどの構成技術と、音声データがテキストに変換される流れを解説します。
  2: iOS 10以降で使用可能だったSFSpeechRecognizerと比較を通じて、どれほど性能が向上したかを解説
• 音声認識の精度や処理速度だけでなく、長い音声データや距離のある音源への対応、オンデバイスでの動作など、できることの幅も大きく広がりました。

トークの対象
・ Apple IntelligenceやAppleの最新技術に興味がある方

*NDAに配慮し、公開されたWWDCや公式ドキュメントなどの情報を元にトークを展開する予定です。

音楽とプログラミングはまったく違うもの。芸術と情報工学の間に、共通点などない。
……と思われている方も多いようです。
しかしながら、それは大きな誤解なのです。
なぜなら、音楽は数学だから！
「ド ド# レ レ# ミ ファ ファ# ソ ソ# ラ ラ# シ」、誰もが知っているこの音の並びを生み出したのは、古代ギリシャの数学者ピタゴラス、と言われています。

プログラマと音楽は相性が良いのです。
私自身も、平日はプログラマ、週末はアイドルなどへの楽曲提供をする作曲家です。

プログラミングはコード(code)を書き、作曲はコード(chord)を使います。

この「コード」を中心にプログラマなりの作曲を考えてみましょう。
コードネームから構成音を求めるプログラムを作ることができます。
コード進行にはパターンがあり、デザインパターンやライブラリのように利用することができます。
コード進行からメロディを導き出して作曲していくことができます。

本トークでは

1. 作曲とはなんなのか
2. コードの仕組み
3. コード進行はパターンである
4. コード進行を演奏するiOSアプリを作る
5. コード進行から曲を作る

についてお話しします。

皆さん、The Swift Programming Language（通称TSPL）をご存じでしょうか。TSPLは、Swiftの主な特徴や主要な機能を詳しく解説した公式ドキュメントです。

一見すると、Swiftをこれから学び始める方のための入門書のように思われるかもしれません。しかし、実際にはSwiftの深い考え方や、意外と知られていない機能についても学ぶことができます。

Swift6.2のリリースに合わせて、TSPLにはSwiftユーザーがSwiftをより深く理解するための更新が行われています。これにより、現在TSPLに注目しておくことは非常に有益です。

私は2021年にTSPLの日本語版を作成し、それ以降も原文に合わせて継続的に更新してきました。ありがたいことに、私の翻訳はSwift.orgにもリンクされています。
このトークでは、TSPLの構成について詳しく説明するとともに、私がこの経験を通じて感じた、ビギナー、ミドル、シニアエンジニアそれぞれに適したTSPLの読み方について紹介します。

このトークを通じて、「Swiftともう少し仲良くなれそう」と皆さんに感じていただけることを目指しています。ぜひご参加ください。

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の機能が大幅に改善され、これまでのスレッドセーフなプログラミングの考え方がより簡潔になります。
このセッションでは、WWDC25の基調講演と実際の開発現場でのマイグレーション経験をもとに、従来の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です。