トーク

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

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

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

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

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

Swiftでのサーバー開発の可能性について考えてみませんか？
また、iOSエンジニアであっても、サーバーまで網羅するフルスタックエンジニアへの跳躍を考えたことはないでしょうか？

Swiftでのサーバー開発にチャレンジしてみます。Server Side Swiftプロジェクトは長い間開発されてきましたが、実際のサービスで使われている例はまだ多くはありません。ぜひ、わたしといっしょにVaporを体験し、Server Side Swiftのエコシステムをいっしょに育てていけたらうれしいです。

今回のトークセッションでは、WWDCでも何度か紹介されてきたVaporフレームワークに注目し、簡単なサーバーアプリを一緒に作ってみます。プロジェクトの初期化から、実際のWebやアプリでの使い方、Dockerを使ったサーバーのデプロイまで、一つのTODOアプリを作りながら解説します。クライアントからサーバーまで全てを網羅するSwiftエンジニアになりませんか？

＜アジェンダ＞

• Swift開発者の新境地！Vaporで開くサーバーサイドの世界
• Vaporプロジェクト、立ち上げガイド
• APIの設計と実装
• サーバーとDBの賢い連携術
• Webコンテンツの表示ロジック
• Dockerコンテナ化とデプロイの秘訣
• Swiftで広がる可能性：次なる挑戦へ

iOS18でQRコードが生成できない───ッ！？

この事件は、文字列として扱われる16進数を、QRコードにData型として渡せるようにそのまま16進数に変換する際に、nilが返ってくるようになっていたことで起こっていました。
この事件の真相とは如何に。そしてこの問題を解決する過程で得たデータ変換のテクニックとは───

また、第2の事件も勃発します。表示はできるけど読み取れない───ッ！？

QRコードには様々な仕様が存在し、仕様が満たせないと読み取ることができないのです。
しかしiOSにおいてQRコードの生成には一般的にCIFilterのCIQRCodeGeneratorを使用しますが、これはQRコードに含めるデータと誤り訂正レベルしか指定することができません。
どのようにQRコードの仕様を満たせば良いのか───そのテクニックを紹介します。

話すこと

• 16進数関連のデータ型変換
• Foundationの実装変更による影響
• QRコードの仕様を満たすためのデータ変換

Flutter を扱う上でもっとも悩まされる要素のひとつに「状態管理」が挙げられます。

Flutter にはローカルな状態を扱う StatefulWidget とグローバルな状態を扱う InheritedWidget という仕組みが標準で用意されているのですが、これだけでは対処しづらいアプリ開発の課題と解決策が長年議論されてきました。その結果、 Riverpod や Bloc をはじめとするサードパーティのパッケージ（ライブラリ）が開発・公開され、ざっと挙げただけでもその数は 50 をゆうに超えています。

一方で SwiftUI に目を向けると、@State や @EnvironmentObjectをはじめとする標準の property wrapper で状態管理を簡潔に行えるため、追加でライブラリを導入するということは少ないようです。

そんな状況の違いはあれど、「不要になったデータを適切に破棄したい」「非同期処理を伴う状態を過不足なく表現したい」「状態の生成・更新処理を抜き出してテストしたい」といった、「状態管理」という共通の観点において発生する課題には共通する部分も多いはずです。そしてその課題を解決するためのアイデアは多く知っておいて損はありません。

「数え切れないほどのパッケージが存在する」ということは、「数え切れないほどの議論とアイデアがそこで生まれてきた」ことを意味します。このトークでは、そんな Flutter が時間と労力をかけて議論してきた状態管理の課題とその対処法を、「50 を超えるサードパーティのパッケージ」のドキュメントとソースコードを私が読んで得た知識と経験を元に整理して共有します。

それにより、アプリ開発において発生し得る課題と対策案を先回りして知ることができる、そんな発表を目指します。

UIKitで作られたアプリにSwiftUIを導入する際の具体的な方法を知りたくありませんか？
開発中のUIKitプロジェクトにSwiftUIを取り入れた経験をお話ししたいと思います。
私たちのプロジェクトでは、ローカル地図機能(NaverMapSDK)を使うために、主要な部分をUIKitで構築する必要がありました。しかし、SwiftUIについて学ぶうちに宣言的UIの魅力に惹かれ、現在のアプリにどう適用できるかを模索しました。
試行錯誤の末、UIKitとSwiftUIを適切に組み合わせた「ハイブリッドな構造」を考案し、幾度かの設計改善を経て、プロジェクトへのSwiftUI導入に成功したのです。
本トークセッションでは、導入にあたっての課題や試行錯誤、そして実際に得られた知見について、実践的な観点からお話しさせていただきます。

<アゼンダ>

• Shucleアプリの概要
  • 使用した技術スタック
  • プロジェクトの構造
• プロジェクトへのSwiftUI導入
  • アプローチ案
  • 最終デザイン案
  • 試行錯誤を含む開発秘話

普段開発でCoreLocationを使っていますが、常に位置情報を更新すると多くのバッテリー消費をしてしまいアプリ削除される要因になってしまいます。逆にバックグラウンド時は何もしないと位置情報を扱うアプリでは思うように位置情報の取得ができずに体験を損なうことになります。そこでバッテリーを抑えつつ、必要な情報を取得するTipsをお話できればと思います。具体的に、ジオフェンスの入出、LocationPushの活用、速度に応じたDistanceFilterの可変、AppDelegateのLaunchOptionを活用したバックグラウンド起動時の工夫について詳しく解説します。

iOS アプリで位置情報トラッキングを実装する際、意識すべきなのがバッテリー消費の効率化です。
位置情報を扱うには Core Location フレームワークの利用が欠かせませんが、デフォルトパラメータのまま使用すると、1時間で20%以上のバッテリーを消費することがあります。
特に位置情報をバックグラウンドでトラッキングするような常駐アプリでは、バッテリー消費はユーザー体験に大きな影響を与えるため、チューニングが必要になってきます。

チューニングにあたってはアプリのユースケースに応じた適切なアプローチを選択することが重要です。
例えば、目的地に近づいたら通知を出すようなアプリの場合、位置情報の精度を落とすことでバッテリー消費を低減できますが、精度によっては反応が遅れたり、通知されない問題が出てきてしまいます。

本セッションでは、ユースケースごとにバッテリー消費を抑えつつ位置情報をトラッキングするための最適な方法を、これまでの開発で得た知見を交えてご紹介します。

内容:

• Core Location の基本実装とバッテリー消費のメカニズム
• バッテリー消費を抑えるためのアプローチ
• ユースケース別の実装方法
• バッテリー消費を半減させたチューニング事例

対象者:

• 位置情報を使った iOS アプリを開発している、またはこれから開発を始めようと思っている方
• 位置情報アプリのバッテリー消費に課題を感じ、改善策を探している方

SwiftはiOSやmacOS開発だけでなく、サーバーサイドやLinux環境でも活用されています。このトークでは、そのSwiftを用いてオープンソースゲームエンジンGodotを活用する方法を紹介します。

Godotは軽量でありながら本格的な2D/3Dゲームエンジンです。iOS、Linux、macOS、Windowsプラットフォームへのエクスポートが可能です(※)。Godotの標準言語は独自スクリプト言語GDScriptおよびC#ですが、GDExtensionという仕組みを通じてほかの様々な言語でも開発が可能です。SwiftGodotは、このGDExtensionによってGodotのAPIにアクセスできるようにした「言語バインディング」です。Swiftで直接ゲームロジックを記述できるため、型安全性やモダンな言語機能を活かしながらのゲーム開発が可能になります。
(※ Godot自体はWebや各種コンソール機へのエクスポートも可能ですが、現時点でSwiftGodotを利用した場合での確認がされていないものについては列挙を避けました。)

実際に開発したカジュアルゲームのコードとデモを通じて、SwiftGodotの導入方法や基本的な使い方を解説し、ゲーム開発に踏み出す第一歩をお手伝いします。Swiftの新たな活用方法として、マルチプラットフォームなゲーム開発という選択肢を探ってみましょう。

Siri、Spotlight、ショートカット、Widget…。近年のiOSでは、アプリのUIに触れなくても機能を呼び出す手段が増えています。
その中心にあるのが「App Intents」です。
本セッションでは、App Intentsの基本的な仕組みとiOS 18以降で広がった用途を紹介しながら、「今、自分のアプリでどう使えるのか」がイメージできるようになることを目指します。

App Intentsはアプリの機能やデータを構造化して、Siri・Spotlight・ショートカット・Widgetなどから呼び出せる形で公開できるApple公式のフレームワークです。
自然言語や検索、トリガー操作を通じて、アプリを“意図”で動かすための仕組みと言えます。

本セッションは「App Intentsを実際に導入したことがない」iOSエンジニアを主な対象とし、以下の内容をお話しします：

・App Intentsの実装方法
・SiriやSpotlightなど、各文脈でのIntentの使われ方
・iOS 18やiOS 26で追加された新たな統合先（Apple Intelligence・Widgetなど）
・実装時につまづきやすいポイントと回避方法

App Intentsはまだ一般的とは言えませんが、Apple Intelligenceとの統合が進む中でアプリの呼ばれ方・見つけられ方を根本的に変える技術です。
今後、App Intentsを書くことが“公開インターフェース”の設計になる時代に備えて、まずは基本と導入の第一歩を押さえてみませんか？

iOS 17以降に登場したAssistive Accessは、主に認知障がいのある方々に向けて設計されたアクセシビリティ機能です。
Appleらしい洗練されたUIを保ちながらも、情報量を制限し、最も重要な機能にフォーカスするこの仕組みに触れて、多くの開発者が「UIにおける認知負荷」について再考するきっかけを得たのではないでしょうか。

本セッションでは、認知にやさしいUIとは何か？という問いを出発点に、Assistive Accessが示した設計原則やSwiftUIによるアプリ実装の手法を通して、日々のアプリ開発に活かせる設計の考え方を掘り下げます。
また、iOS 26から導入されたAssistiveAccessシーンタイプやaccessibilityAssistiveAccessEnabled環境値を活用した表示分岐など、SwiftUIでAssistive Accessを取り入れる具体的な方法も紹介します。

さらに本セッションでは、Assistive Accessの背景にある設計思想を心理学やHCI研究の文脈から深掘りします。
認知負荷理論やヒックの法則を手がかりに、「選択肢を絞る」「明確な誘導を行う」といったAssistive Accessの設計要素を理論的に捉え直します。

また、非言語表現の設計や状態変化の制御といった細部にも注目します。
例えば、「アイコン＋ラベル」の併用による視認性向上、操作不能なジェスチャーの排除、破壊的なアクションへの再設計など、認知的ハードルを下げる工夫は通常のアプリ設計にも多く応用可能です。

このセッションを通して、認知に配慮したUIとはどうあるべきかを理論と実践の両面から捉え、支援技術の知見を一般アプリの設計改善へと活かす視点を得ていただければと思います。

Swift 6の導入に苦労している現場が多い中、Swift言語はすでに次のステップへと進み始めています。
Swift 7では5つの「Upcoming Feature Flags」がデフォルトで有効化され、型システム、モジュール設計、並行性の挙動において重要な変化が生じます。
本セッションでは、これらの変更がどのような文脈で導入されようとしているのかを、Swift Evolutionの提案に基づいて読み解きます。

（現時点で）対象とする機能は以下の5つです。
・ExistentialAny
・InternalImportsByDefault
・MemberImportVisibility
・InferIsolatedConformances
・NonisolatedNonsendingByDefault

それぞれの機能は、単なる文法変更ではなく、型安全性・依存性の明示・並行性制御といった観点で、Swiftの設計上の一貫した方向を示唆するものと捉えられます。
本セッションではそれぞれの提案が登場した背景や、過去の関連するSwift Evolutionとの関係性を整理しながら、言語仕様の変化を体系的に理解する手助けを目指します。

また、これらのUpcoming Feature Flagsを事前に有効化する方法として、SwiftPMやXcodeでのフラグ指定方法についても簡潔に紹介します。
日々の開発に無理なく取り入れながら、将来の言語仕様変更に備える知識を得られる構成です。

将来のSwiftを正確に予測することはできなくとも、これらの仕様変更を通じて言語が解決しようとしている課題や、設計上の一貫性を読み解く視点は、日々のコード設計にも役立つはずです。
Swift 7の未来を一歩先取りし、変化を安心して迎えるための材料を共有します。

Actor境界はSwift concurrencyにおいてデータ競合を防ぐための強力な概念ですが、実際のアプリ開発においてはこれが障壁となることがあります。Actor境界を跨ぐデータの受渡は通常非同期で行われますが、これを同期的に行わなければならないことがあります。例えばレガシーなスレッドベースのAPIを使う場合、引数として渡すコードブロックにおいて、そのActor context外のデータに同期的にアクセスすることが必要になることがあります。

このトークでは、AVFoundationを用いてサウンドを再生する例を題材にして、こうしたケースにおいてもActor境界を安全かつ同期的に跨ぐ方法について説明します。Custom actor executorや、OSAllocatedUnfairLockやMutexといったロックAPIを用いることで、unsafeキーワードを用いることなくActor境界外のプロパティにアクセスし、Swift 6でコンパイル可能な実装方法を紹介します。
Swift concurrencyとともに、どんなAPIも安全かつ効果的に利用できるようになりましょう。

このセッションでは、継続的デリバリーの理想と現実の狭間で、マンガアプリのリリースプロセスに刻まれた
「シュプール」(雪面に残る軌跡) のような、私たちの改善の歩みを実例とともにお伝えします

• Branch Policy
  • Git Flow から Trunk Based Development への移行の過程とそのメリット
  • Code Review と CI の連携を最適化するために実施した取り組み
  • Feature Flag の管理と運用方法の改善
• Versioning Strategy
  • 優先度変更による Version の混乱を乗り越え、わかりやすく迷わない、Calendar Versioning を採用した経緯
  • Release Note 作成の自動化と情報共有の方法
  • Slackbot を活用した差分出力の簡素化
• Release Cycle
  • Release Train を用いた安定的で計画的なリリース
  • 属人化を避けるためのリリースフローとその実施例
  • 予期せぬ事態でも慌てない Hotfix 対応の実践

本セッションでは「あすけんiOSアプリ」における実践事例をもとに、テスト戦略をどう立て、どう現場に根づかせたのかを紹介します。
当社では、テスト運用が属人化していたり、テストが不足していたり、テスト書くこと自体が目的になってしまっていました。
ただ、ユニットテスト、UIテスト、E2E、さらにはスクリーンショットテストとCI/CDの連携など、全部網羅的にやることは現実的ではないです。
そのため、今の自分たちにとって、本当に必要なテストだけを選び取り、属人化を減らしてチーム全体で理解・運用しやすいテスト戦略を目指しました。
昨今の生成AIとの協働も考慮しつつ、テストの設計や現場で工夫したことなど、運用を見直すヒントを提供します。
例えば、AIを活用して、ユニットテストのコードを生成する取り組みなどをやりました。

ただし、試行錯誤は続いているのでうまくいっていない部分も語っていきたいと思います。 「テストはあるけど、なんとなく不安」「CIが形骸化している」「リリースのたびにUI崩れが怖い」
そんな現場にとって、戦略的にテストを設計・運用する事例や考え方を提供する内容になっています。

アジェンダ

1. 背景と課題
2. テスト戦略の再設計
3. テスト運用方法や手法
   • テスト設計
   • スクリーンショットテスト
   • CI/CDなど
4. 生成AIとの協働
   • テスト設計・運用におけるAIの活用例
5. 継続的な試行錯誤と課題

皆さんはIn-App Purchases(以下IAP)を提供するサービスに関わっていますでしょうか？
IAPによってサービスは継続的に収益を得ることができ、StoreKit 2によって以前よりも簡単に実装が可能です。

IAPを公開するためにはapp、メタデータなどを用意し審査に出す必要がありますが、色々と注意点・問題点が存在します。
・配信国が1つも設定されていないとrejectされます。
・IAPは審査通過した後自動で公開されるため、配信日時をコントロールすることが不可能です。公開日より前に審査だけ通したくても意図せずApp Storeに提供予定の機能が公開されることになります。

・公開されたIAPは配信国を0にすることでApp Storeより削除できますが、Account Holderしか配信国を削除することができず、権限を持つ人の状況次第で対応が遅れる懸念があります。
など…

では、これらの事象に対して我々は何ができるのでしょうか。

このLTではIAPを申請するために必要なこと・注意点を共有します。
またWWDC25の現地labでこれらの課題に対して質問してきた内容を実際に用いた資料も併せて共有します。

果たして解決策は得られたのか？皆さんに多くの最新情報を共有できたら幸いです。

ゴール:

・IAPの申請に準備が必要な情報や申請作業内容がわかる
・申請時に起こりうる問題とそのワークアラウンドを得られる

・本件についてのlabの回答内容を共有できている

アジェンダ:
・IAP申請に必要な準備
・申請後、実際に起こった問題・ワークアラウンドの紹介
・WWDCのlabで聞いてみた&回答について

対象者：

・IAPをリリース予定のエンジニア・非エンジニア
・IAPについてあまり詳しくないが興味がある方

・labの様子や回答内容が知りたい方

筆者はIT企業でiOSアプリ開発をする傍ら、国立弓削商船高等専門学校（以下、弓削商船高専）の情報工学科教員としてプロダクトやシステム開発に関する講義を行なっています。

弓削商船高専のような国立高専では卒業生が身につけるべき知識や能力の到達目標として「モデルコアカリキュラム（以下、MCC）」が定められています。
特に情報系分野では、プログラミング/アルゴリズム/コンピュータの仕組みといった知識・技能に加え、それらを統合して課題解決にあたる「創造性・デザイン能力」の育成が重要視されています。

筆者はSwiftとAppleエコシステムは現代の「ものづくり」のプロセスと非常に親和性が高く、以下のような理由からMCCが目指す能力を育む上で多くの利点を持つと考えています。

• 学生が日常的に使うiPhoneやiPadで動作するアプリケーション開発は、学習への強い動機付けとなる
• SwiftUIとXcodeのプレビュー機能はコードの変更が即座にUIに反映されるため、手を動かしながら試行錯誤することを多く体験できる
  • MCCで求められている「エンジニアリングデザイン能力」 の育成に適している

本セッションではこのMCCの理念である「ものづくり」を通じた社会実装教育を、SwiftとAppleエコシステムを使って実現するためのアプローチを考察します。

• 直感的なSwiftによるプログラミング基礎教育
• SwiftUIのパフォーマンス改善といった実践的課題から学ぶアルゴリズムとデータ構造
• LLVMを基盤とするSwiftの特性を活かしたコンパイラへの理解

本セッションを通して高専教育のカリキュラムや授業構成に関する問題点や新たな可能性を見つけ、未来のiOSアプリエンジニアを育てるためのより実践的なカリキュラムや授業の作成に繋げたいと思います。

「バイブコーディングでAIにコードを書かせたけど、本当に動くの？」そんな不安を解消する、AI駆動の自動開発・自動検証システムを構築しました。本セッションでは、Claude CodeなどのAIコーディングアシスタントが生成したモバイルアプリのコードを、AIが自動的に動作確認する仕組みを紹介します。

具体的には以下のような内容をカバーします：

• AIによるコード生成後の自動動作確認フローの構築
• 生成されたUIコンポーネントの自動スクリーンショット検証
• AIが書いたコードに対する自動E2Eテストの生成と実行
• 問題検出時のAIへのフィードバックループの実装

「AIがコードを書き、AIが検証し、AIが修正する」完全自律型の開発サイクルはどこまで実現可能なのか？実際の開発事例とデモを通じて、AIによる自動コーディングの品質保証という新たな課題への挑戦をお見せします。

生成AIの進化により、Stable Diffusionをはじめとする画像生成技術が急速に注目を集めています。その流れを受けて、iOSアプリでも画像生成・加工の技術を取り入れたいというニーズが高まりつつあります。
iOSアプリで画像処理を実装しようとした場合、Core Image、Metal、CoreML、サーバサイド処理、さらには生成AI関連のAPIなど、選べる技術は多岐にわたります。

便利な選択肢が増える一方で、「結局どれを使えばいいのか分からない」「画像処理は難しそう」と感じて手が止まってしまう方も多いのではないでしょうか。

本トークでは、画像処理技術を利用してiOSアプリで独自の画像アニメーションを構築した経験をもとに、各技術の特徴と使いどころを整理します。
トークでは、独自アニメーションを実装するための要件を起点に、各要素技術（Core Image / Metal / CoreML / サーバサイド処理 / 生成AI関連のAPI）を使いながらアニメーションを構築していく過程を、実践的な形式で紹介します。
単に技術を羅列するのではなく、アニメーションの実際の動作を見せながら、「どのような場面でその技術を選ぶべきか」といった選定の観点を中心に、各要素技術を比較・検討していきます。

画像処理に興味はあるけど、何から手をつければいいか分からない。そんな方に向けて、iOSで使える技術やアプローチを実例とともに紹介します。
実は私自身も画像処理の専門家ではありません。でも、様々な技術を試す中で「意外と面白い」「ポイントさえ押さえれば自分でも作れる」と感じました。
本トークを通じて、画像処理は「難しそう」ではなく「ちょっとやってみたい」と思えるような、そんなきっかけを届けられたら嬉しいです。

このセッションでは、ビルド高速化のノウハウをまだ持っていないAppleプラットフォーム開発者向けに、具体的にどのようにビルド速度を改善できるのかを解説します。

アプリ開発中は、実装やCI/CD等で沢山ビルドすると思います。
ビルドの時間が遅いと、単純に開発者にとってストレスになるだけでなく、開発のテンポが悪くなり実装内容に見合わない大きなコストがかかることになります。
WWDCのセッションビデオや公式ドキュメントより、Xcodeのビルドシステムの仕組みを見てみると、ソースコードの量やマシンスペック以外にも様々な原因でビルド速度のボトルネックになる要因があることがわかりました。
皆さんの関わっている、プロジェクトのビルド設定やソースコード自体がビルド速度のボトルネックになっていることが、あるかもしれません。

本トークでは数あるビルド時間が伸びてしまう原因のうち、解消したときに短縮できるビルド時間が大きいと思われるものを3つに厳選して、重要なチェックポイントと修正方法をそれぞれ解説します。
具体的には、次の内容に関連した原因についてお話しします。

• 並列ビルドの最適化ができていない
• 依存ライブラリのコンパイル時間が長い
• コンパイル時の型推論時間が長い

例えば、Xcodeでは並列に複数のビルドタスクを進めることができますが、プロジェクトの依存関係によっては並列で処理できない部分が発生することがあります。
このような問題をどのようにして発見し、どうやって改善するのかそれぞれ詳しく説明します。
サンプルコードや、実際のプロジェクトで取得したビルド時間のベンチマークを比較して、実際どれぐらい早くなるのか、も見ていきます。

業務、プライベート問わず、普段の開発でビルド時間に悩まされている開発者にとって、是非聴いていただきたい内容です！

アプリ開発において、UIの品質担保は誰しもが一度はぶつかる課題だと思います。
解決策として、E2Eテストやスナップショットテスト、実機テストが挙げられます。
その中でも、swift-snapshot-testingを使ったビジュアルリグレッションテスト(以降VRTと呼ぶ)に焦点を当てていきます。
※VRTとは、変更前と変更後のコードで対象画面のスナップショットを比較することで、UIのデグレを検知するテストです。

「UIテストは運用コストが高い」と、諦めた経験のある人はいませんか？
導入初期は運用できていたものの、少しずつ放置されていき、運用されなくなってしまった経験はありませんか？

本トークでは、そんな運用コストの課題を
CursorやClaude Code Github Actionsを使って解決した方法をお話しします。
また、以下のテーマに触れながら進めていくので、検証から運用まで具体的にイメージすることが出来ます。

• 技術選定の内容と理由
• ChatGPTが提案するコードのセキュリティの問題
• CIの実行時間の課題
• カバレッジ計測の自動化
• テスタブルなUI設計
• Cursor, Claude Code Github Actionsの活用方法

導入後の現在も、品質や設計・自動化面で改善を続けており、
それらを余すことなくお伝えできればと思います。

「VRT導入時、どのようなことを考慮したら良いかよくわからない」
「VRTの導入を検討しているが、実際にチームで運用し続けられるか悩んでいる」
「運用が止まってしまっている」
そんな方々に参考になるセッションとなれば幸いです。