MVVM、それはSwiftの誕生前から、人気のアーキテクチャの一つ。そしてSwiftUIが登場して6年経った今もなお、その人気っぷりがなかなか衰えを見せません。

ところが、あなたは本当にMVVM、もっと言えばViewModelのことを分かった上で使っていますか？
「みんなが使っているから、私も使おう」
「画面のテストが書けるから、私もViewModel入れよう」
「プレゼン層とドメイン層を繋げるために、ViewModelが必要」
そんな単純な思いで、MVVM使っていませんか？

はっきり言いましょう、そんなあなたは、別にViewModel、もっと言えばMVVMなんて本当は必要としていないです。むしろある意味、SwiftUIとMVVMは、相性が非常に悪い組み合わせだと断言します。

このトークは、ある程度SwiftUIでの開発が慣れているエンジニアをターゲットとし、以下の内容を含める予定です：

• なぜあなたが必要なのはViewModelではないと私が言うのか
• なぜSwiftUIはMVVMと相性が悪いのか
• ViewModelを無くしたら、どのようにしてViewの処理を保証すればいいのか
• MVVM使わないなら、どんなアーキテクチャがいいのか

このトークを聞いて、ぜひ一度SwiftUIの原点に立ち戻って、SwiftUIに適したアーキテクチャを再考してみませんか？

UIKit ベースで長年開発されてきたアプリを、SwiftUI + Observation を取り入れながら段階的にリアーキテクチャしている最中の現場から、移行と共存のリアルな取り組みをご紹介します。

なぜリアーキテクチャに取り組むのか、どのようにアーキテクチャを考えていったのか、結果どのようなアーキテクチャになったのか、、

そして、実際にプロダクトに実装して見えた改善点など、理想と現実のギャップに向き合い改善を進めている、リアルな“今”のストーリーをお届けします。
「SwiftUI に切り替えたいが、現実的にどう始めればいいかわからない」「SwiftUI を取り入れたが、既存アーキテクチャと相性が悪そう」「Observation を使った実践例が知りたい」といった悩みを持つ開発者にとって、同じ課題に直面した私たちのプロセスはきっと参考になるはずです。

2017年に発売されたiPhone 7以降、iPhoneにはNFCリーダー/ライターが搭載されるようになり、NFCは私たちの生活にとってより身近な技術になりました。
AppleからもCore NFCフレームワークが公開され、我々開発者はNFCタグの仕様を深く知らずとも、アプリを簡単に開発できます。

弊社でもNFCタグを用いたプロダクトの開発が進められており、
ある日私は「パスワードで保護されたNFCタグを使った新機能」を開発することになりました。
しかし、その技術検証の過程で、NFCタグの仕様を深く理解していなかった私はさまざまな壁にぶつかります。

「パスワード認証ってどうやるんだろう？それっぽい専用のAPIは見当たらないけど...」
「どうにかパスワード認証できたぞ！あれ、データ読み込みがエラーになるな...」

結局、この壁を乗り越えるために、NFCタグにまつわる幾つかの技術仕様を基礎から学び直すことになりました。

本トークでは、検証の過程で学んだNFCタグの技術仕様の説明を交えつつ、どのようにこの機能を実現したのかをお話しします。
Core NFCが普段どのような処理をラップしてくれているのか、その裏側をちょっと覗いてみませんか？

話すこと

• NFCタグ(NTAG215)にまつわる技術仕様
  • NDEF Message/Record
  • NFCタグのデータ構造
  • MiFareコマンド
  • TLV形式
• パスワードで保護されたNFCタグからデータを読み取る方法
  • sendMiFareCommandを用いたパスワード認証・データ読み取り
  • 読み取ったデータのNFCNDEFMessageへのパース

比較的高額な決済機能を有する金融サービスでは、犯罪収益移転防止法に基づく本人確認の実施が義務付けられています。

私たちが提供する『AI家計簿アプリ ワンバンク』では、 "eKYC" と呼ばれるオンライン形式での本人確認フローを自前で構築し、サービスの成長を支えてきました。その運用の過程ではユーザー体験や堅牢性の向上、ガイドラインへのさらなる準拠などさまざまな改善を積み重ねてきました。

また、近年は不正利用も深刻化する中で従来の書類と顔写真の撮影を伴う本人確認方式は廃止の流れにあります。ICチップの読み取りによる信頼度の高い方式への移行が求められ、私たちのサービスでも対応を進めてきました。

このトークでは、私たちがこれまで本人確認フローに積み重ねた改善にフォーカスし、さまざまな観点での工夫やTipsを紹介していきます。そして、JPKI方式（公的個人認証サービスを利用したマイナンバーカードによる本人確認）への対応など、環境の変化へ追従するための直近の取り組みにも触れていきます。

【内容（予定）】

・自前で構築した本人確認フローの運用の中で積み重ねた改善
・本人確認フローの突破率を最大化するための試行錯誤
・撮影機能が依存するライブラリ（ML Kit -> Vision.framework）の安全な移行に向けた工夫
・従来の本人確認方式の廃止を伴う法令改正に備えたJPKI方式対応などの直近の取り組み

2020年にリリースされたApp Clipは、今年の秋に6年目を迎えることになります。
以前よりは少し知名度が上がったとはいえ、WWDC25では2年連続でセッションがなく、未だに存在の薄さが否めないApp Clip。

「アプリの一部をコンパクトにしたもの」
「完全版のアプリの一部として管理」
このような性質上、決して"主役"にはなれないものの、アプリの体験を裏から補強するそのポテンシャルは、はたしてどれだけの人やビジネスを動かしたのでしょうか。

このトークでは、App Clipが生まれてから今日に至るまでの5年に至る歴史を紹介していきます。
App Clip 自体のアップデートや、国内外での各業界（飲食、小売、交通、ゲーム等）における実用例を振り返りつつ、その進化と残された課題について見ていきます。

App Clipを待つのは夜明けか、それとも日没か。
5年経った今だからこそ見えるその可能性に迫っていきませんか。

iOSのWidgetは、アプリを開かずに静的な情報を即座に確認できる便利なUIコンポーネントとして発展してきました。

従来は「見る」だけの体験が中心でしたが、iOS 17から導入された Interactive Widget によって、ボタンやトグルを用いた直接操作が可能となり、よりリッチで能動的なユーザー体験が実現しました。同バージョンではアニメーション表現のサポートも追加され、動的かつ魅力的な情報提示が可能に進化しています。さらにWWDC25で発表された WidgetKit Push により、サーバーからのプッシュ通知を活用したリアルタイム更新が可能となり、ユーザーに最新情報を即座に届けられるようになりました。

このトークでは、これら最新技術を活用したWidget開発の実践的なアプローチと設計上の要点を技術的視点で深掘りします。

フィーチャーフラグは新機能の段階的リリースやA/Bテストを可能にする強力な手段ですが、一方で乱立・肥大化すると管理が複雑化しやすく予期せぬバグやインシデントが発生しやすくなります。

今回、私は株式会社ヤプリが提供するノーコードアプリプラットフォームのiOS基盤に、長期ブランチの滞留やインシデントの復旧遅延を解消するためにフィーチャーフラグを導入しました。

しかし、その導入は容易ではなくノーコードアプリプラットフォームならではの課題に直面しました。

まず、一つのコードベースから多数のアプリをビルドするために、従来のフィーチャーフラグ手法ではアプリごとの条件分岐や設定管理が膨れ上がり現実的な運用が難しくなってしまいます。

次に、1つの不具合が多数のアプリ全体に波及するインシデントへと直結するため、リリースコードに少しでも変更があればQAの実施が必須となっています。

最後に、開発チームでは過去に何度か検討されながら「すでにあるアプリ編集機能で十分では？」という意見も多く、導入意義をチームで合意する必要がありました。

このような課題に対して、私は丁寧に「フィーチャーフラグ」についてチームのコンセンサスをとりながら、安全に導入するためにSwift MacrosとBuild tool pluginを用いた仕組みを設計しました。

1. 宣言的なフラグ定義により全体のフラグ状態を静的に把握
2. Swift MacrosとユニットテストでQA工数を抑制しながら「動かないコード」を撲滅
3. コード自動生成で対象外フラグをビルド時に無効化する仕組みを構築

例えば、この設計でコード内で個別アプリごとの条件分岐が不要になっています。

このトークではこれらのアーキテクチャとワークフローを具体的なコードとともに紹介しながら、導入に伴う成功と失敗の両面から皆さんに共有します。

SwiftUIが利用可能となって6年が経過し、今では500個以上のAPIが存在します。iOS 13でのリリース以降、毎年開催されるWWDCで新しいAPIが追加され続けています。それにも関わらず、私はiOS 13からiOS 15で利用可能となった基本的なAPIに留まり、新機能への追従ができていませんでした。

この現状を打破するため、「SwiftUI未使用API100本ノック」と称し、自分が使ったことがないAPIをひたすら学習・検証する活動を行いました。それにより、従来の複雑な実装がより簡潔に、そしてレンダリングに優しい書き方に変えられることを学びました。本トークでは、100本ノックで発見した便利なAPIを実際のコードに適用した事例を紹介します。GeometryReaderの代わりに containerRelativeFrame(_:alignment:) を使う方法や、 onGeometryChange(for:of:action:) による効率的な値の監視など、実践的な改善パターンをお見せします。

このトークのゴールは、より効率的でメンテナンスしやすいSwiftUIコードを書くための具体的な方法を学んで持って帰っていただき、日々の開発に役立てていただくことです。

対象聴衆は以下の方です。

• iOS 16からiOS 18までのSwiftUIのAPIを使いこなせていないと感じている方
• 既存のプロジェクトでコード改善を考えている方
• SwiftUIコードの可読性向上を目指している方
• GeometryReaderを多用している方

visionOSの登場により、従来のARKitでは難しかった高精度で安定した空間アンカリングが実現可能になりました。インテリア配置アプリ、教育・トレーニング、設計支援など、様々な分野でデジタルオブジェクトを物理空間に正確に配置し続ける需要が高まっており、「一度配置したらずっとそこにある」という体験の重要性が注目されています。
この体験を実現する技術がvisionOSのWorldAnchorです。WorldAnchorを活用することで、ユーザーが一度配置したオブジェクトを物理空間に「永続化」し、まるで現実世界に存在するかのような「ずっとそこにある」体験を実現できます。

本セッションでは、実際に開発したデモアプリの事例をもとに、WorldAnchorの実装から期待されるユースケースまで、実践的な観点で解説します。WorldAnchorの活用方法を知りたい開発者の参考になるような内容を目指します。

具体的な内容

• WorldAnchorとは何か？
• 基本的な実装方法（作成・保存・復元の流れ）
• 実際のデモアプリで見る「永続化」の体験
• 今後期待される新しいユースケースの展望

このセッションを通じて、WorldAnchorの可能性を理解し、「物理世界とデジタル世界が融合した新しい体験」を自分のアプリで実現するための具体的なイメージを持っていただけます。

対象者

• visionOS開発に興味があるiOS開発者
• Spatial Computingの具体的な活用方法を知りたい方

2023年にApple Vision ProとともにvisionOSが登場し、iOSエンジニアにとって空間コンピューティングという3Dコンテンツを交えた開発がより身近なものになりました。

SwiftUIやRealityKitといった馴染みのある技術を活用できる一方で、3Dモデリングに関する用語や概念に戸惑いを覚える方も多いのではないでしょうか。

中でも「マテリアル」は、オブジェクトの見た目や質感を左右する重要な要素でありながら、iOSアプリ開発ではあまり馴染みのない概念です。

RealityKitには用途に応じた多様なマテリアルが存在し、それぞれに特性があります。しかし、「どれを選べばよいかわからない」「そもそも何が違うのか」と感じる場面も少なくありません。

本セッションは、RealityKitのマテリアルを網羅的に解説し、どのユースケースでどのようなものが用いることができるかの全体像を把握できるものとなっています。

以下のような観点から解説を行います。

• マテリアルとは？ ：
  光沢、粗さ、透明度など「色」だけでは語れない見た目の要素を分解して解説。
• RealityKitで使える全マテリアルAPIの解説と実例：
  SimpleMaterialでの基本表現、PhysicallyBasedMaterialによるリアルな質感、VideoMaterialでの動画埋め込みなど、現在RealityKitで提供されているAPI全ての特徴とユースケースを紹介。

本セッションを通じて、visionOSで利用可能なRealityKitのマテリアル全体をユースケースと合わせて理解し、空間コンピューティングならではの新しい体験づくりのヒントを得ていただければ幸いです。

マップを活用したiOSアプリは、建物や道路といった屋外の情報を扱うことが多いですが、建物にズームしたときに、その建物内のフロアマップが表示されるような機能を兼ね備えたアプリも存在します。

みなさんは、ショッピングセンターや空港といった施設内の位置情報を定義できるフォーマットをご存知でしょうか？Appleは、Indoor Mapping Data Format (IMDF) というフォーマットを提唱しています。これを使うと、フロア内の部屋の領域だけではなく、消化器や机といった屋内にある備品の位置情報も定義することができます。

IMDFで定義した屋内フロアマップは、MapKitを使って表示することができます。IMDFで定義した屋内マップを地図上に表現することで、屋内の場所をわかりやすく表示したり、施設内の情報を表示する機能なども提供できます。

このセッションでは、Appleが提唱している建物内の位置情報を定義できる IMDF についての仕様や定義の仕方について紹介をします。また、このフォーマットに則って実際に建物内の位置情報を定義して、MapKitを使って屋内のフロアマップ実装例について紹介します。

話すこと:

• Indoor Mapping Data Format の概要
  • 位置情報を定義できるJSON「GeoJSON」とはなにか？
  • 各フォーマットでどのような情報を定義するべきなのか
  • Indoor Map Data Formatの制約について
• MapKitで屋内フロアマップの表示をする実装例
  • MKGeoJSONDecoderによるGeoJSONのデコード
  • 屋内フロアマップを地図の上に表示
  • フロアマップ内で位置を選択して施設内の情報を表示する機能

現代のモバイルアプリ開発において、ネットワーク通信は不可欠な要素となっています。
そして、ネットワーク通信機能を実装する時に合わせて必要になるのが、エラーハンドリングの実装です。

よくあるエラーハンドリングのパターンの1つに挙げられるのが、アラート表示です。
アラートはiOSアプリでよく利用されるコンポーネントであり、データの取得などに失敗してもエラーの発生を簡単にユーザーに通知することができます。
また、デザイン等で考慮することが少なく、表示の実装も簡単であるため、特に小規模なアプリではエラーハンドリングとしてよく採用されがちです。

しかし、皆さんはアラート表示の落とし穴に気づいていますか？
アラートは同時に1つしか画面に表示することができないため、複数のAPIで同時にエラーが発生した場合に、アラートが重なってしまいます。
アプリで同時に複数のAPIと通信することは珍しくなく、また仕様追加によって当初想定されていない部分で複数のAPIを実行する仕様になることもよくあります。

エラーハンドリングは一度実装するとアプリ全体で共通エラーハンドリングとして扱われることが多いです。
そのため、アプリ開発の初期から長期運用を目指した設計を行うことが非常に大切になります。

このトークでは、以下の内容についてお話しします。

• エラーハンドリングをアラート表示で行うことについての問題点
• 場面に応じたAPI通信エラーの表示パターンの紹介
• エラーハンドリングのパターンに合わせた、API通信中のローディングの表示パターンの紹介

近年は長期運用されているモバイルアプリが多いという背景もあり、エンジニアがエラーハンドリングについての設計や共通部分の実装を行う機会は少なくなっているように感じます。
だからこそ、この機会に改めてエラーハンドリングについて考え直してみましょう！

私は元々Androidエンジニアとしてキャリアをスタートし、現在はiOSエンジニアとして開発に携わっています。両プラットフォームを経験したからこそ、Xcodeの常識がAndroid Studioでは通用せず、逆にAndroid経験者としての当たり前がiOS開発では壁になる、という両方の戸惑いを実体験として持っています。このトークでは、そんな自身の経験を元にiOSエンジニアがAndroid Studioを前にした時の「これ、どうやるの？」という疑問を解消し、スムーズにAndroidの世界へ入門できるよう、Xcodeとの比較を交えながら実践的な使い方を解説します。

「KMPプロジェクトで共通ロジックを触りたい」「ちょっとAndroid側の実装を確認したい」などiOSエンジニアでもAndroidプロジェクトを確認したいことがあると思います。しかし、いざ勇気を出してプロジェクトを開いてみたものの…

・「そもそもプロジェクトってどう開くの？ .xcodeproj にあたるファイルはどこ？」
・「デバッグ実行したいけど、Scheme みたいなビルド設定はどこで切り替えるんだっけ？」
・「ライブラリの依存関係は？ Package.swift のようなファイルはどれ？」

といった Xcode の常識が通じない壁にぶつかり、単に挙動を確認したいだけなのに、環境構築や操作方法の調査で時間を溶かしてしまった…という経験はないでしょうか？
本トークでは、基本操作に加えファイル検索や呼び出し階層の確認などのショートカット、Xcode・AndroidStudio特有の便利機能について、私の実体験を交えながら一つずつ話していきます。

概要

GitHub Copilot, Cursor, Devin, Claude Code ... 次々と登場する AI ツール。 「結局どれを使えばいいの?」という疑問があると思います。
アプリ開発業務でいくつかの AI サービスを使ってきた経験から、それぞれの AI サービスの「得意技」と「苦手分野」を解説。
さらに、それぞれの特性を活かした「ハイブリッドAI開発」の実践方法をお伝えします。

話す内容

• 各 AI ツールの特徴と強み
  • GitHub Copilot: インラインコード補完
  • Cursor: コンテキスト理解に優れたエディタ一体型
  • Devin: 自律的なタスク実行が可能なAIエンジニア
  • Claude Code: 大規模リファクタリングと設計支援
• シーン別 AI ツール使い分け術
  • 新機能実装時のペアプログラミング
  • レガシーコードのリファクタリング
  • テストコード生成とカバレッジ向上
  • コードレビューでの活用
• 併用することで見えてきた開発効率化の限界と可能性

対象者

• AI ツールの導入を検討している開発者
• 複数の生成 AI ツールの使い分けに悩んでいる方
• チームでの生成 AI 活用を推進したいリーダー

iOSアプリ開発におけるCI/CDの遅さに悩んだことがある方は多いでしょう。ビルドに10分以上かかる、キャッシュのダウンロードが遅い、そんな経験をお持ちではありませんか？私たちのチームもこれらの課題に直面し、試行錯誤を経てたどり着いたのが「Namespace.so」という高速CI実行基盤です。
Namespace.so を導入することで、ビルドやテスト時間を約2〜3倍短縮し、従来20分弱かかっていた実行時間を8分弱にまで改善することができました。本セッションでは、その導入プロセスと得られた成果、さらに実際に活用してわかったベストプラクティスや注意点をお話しします。

■ セッションの構成

• CIが遅くなる理由とボトルネックの整理（キャッシュの重さ、ランナー性能、依存関係の再インストールなど）
• Namespace.so の紹介、とそのSaaSにおける速度改善の要点
• 実際の導入方法とその効果（導入前後の所要時間比較、導入時の工夫と課題）

■ 対象者

• CIの速度を改善したい方
• CIのコストを削減したい方
• CIについて興味のある方

■ 得られる知見

• Namespace.soのキャッシュ戦略とmacOSランナー活用法（Apple Siliconによる高速起動など）
• CI/CD高速化がもたらす具体的なメリットと導入のインパクト（2〜3倍の時間短縮など）
• チームに浸透させる運用設計やプロファイル構成のベストプラクティス、即実践できるTips

このセッションを通じて、CI/CD改善に関する実践的なアイデアと手段を提供し、すぐに自チームで活用できることを目指します。

概要

「プライベートリポジトリの SDK、アプリの CI でビルドが通らない...」そんな経験はありませんか?

本セッションでは、OpenID Connect 認証 SDK の開発を通じて得たプライベートリポジトリ配布の完全自動化手法を紹介します。Swift Package Manager でのバージョン管理、GitHub Actions による自動リリース、そしてアプリ側 CI での依存解決まで、実際に動くコードと設定ファイルを交えながら、明日から活用できる実践的なノウハウを提供します。

さらに、AI ツール (Cursor) を活用した効率的な SDK 開発フローや、DocC による自動ドキュメント生成など、モダンな開発手法も紹介。社内 SDK の開発・配布・メンテナンスに関わる全ての悩みを解決します。

話すこと

• 「プライベートリポジトリあるある」から始める課題整理
• リリースフローの自動化
• プライベートリポジトリ認証の設定方法
• アプリ側 CI の実装パターン
• TestFlight はどうする?
• AI ツールを活用した効率的な SDK 開発フローとガードレール

話さないこと

• OpenID Connect の詳細な仕様説明

対象者

• 社内向け iOS ライブラリを開発している方や、これから開発を始めたい方
• セキュアな認証ライブラリの実装に興味がある方

みなさん一度は実践するであろう自作コンパイラ。触ったことがない人に取っては何をすればいいのか、何をしているのか理解されていないと思います。
現在、オープンソースで多くのコンパイラのコードはあり、仕組み自体理解することはおそらく可能でしょう。
時には自分の手でコンパイラを作ってみることも重要だと私は思います。しかも好きなプログラミング言語で。
一度その仕組みを理解し、自身の手に触れてみることは、プログラミング言語やコンピューターサイエンスへの理解を格段に深める貴重な経験となります。

このセッションでは、Swift言語を用いてC言語のサブセットをコンパイルするミニマルなコンパイラーを自作した経験から得られた知見を共有します。
実装を通して直面した課題と解決策、そしてコンパイラの各フェーズが実際にどのように動作するのかを、実践的な視点でお伝えします。
また、Swiftの表現力を活かしたコンパイラ開発の魅力も感じていただければ幸いです。

セッション内容:

1. コンパイラとは何なのか
2. 字句解析 ？
3. 構文解析 ？？
4. 抽象構文木 ？？？
5. コード生成 ！？
6. デバッグ ！！

Apple Intelligence の登場により、App Intent はアプリの機能を外部に公開する重要な基盤となります。しかし、「どのような機能を App Intent として提供すべきか？」という問いに多くのデベロッパーが直面しているのではないでしょうか。

本セッションでは、この課題に対し、Interactive Widget を「App Intent 活用の足掛け」と捉え、アプリを開くことなくウィジェット上で処理を完結させるための具体的な実装方法を解説します。
多くのwidgetでは必要な情報を表示するため活用されたり、アプリへのショートカット導線が提供されているケースが大半です。
Interactiveなwidgetがあれば、ユーザーはアプリ本体を起動せずにタスクを完遂でき、よりシームレスな体験を提供できます。

本セッションではAppIntent の基本的な仕組みや概要には深く触れませんが、Interactive Widget を通じて AppIntent を実践的に活用することで、将来的な Apple Intelligence 対応にも繋がる知見を得られるでしょう。Widgetだけですべてが完結する、新しいユーザー体験の構築に挑戦してみませんか？

このセッションで話すこと

• Widgetでユーザーインタラクションを実現するには？
• Widgetから呼び出すための AppIntent の設計と実装
• Widgetからアプリ本体の機能を呼び出すためには？
• Widget特有のAppIntentの制約とその対応策
• ControlWidgetへの応用

「暑い日にスマートフォンを使っていて、アプリの動作が遅くなった…」そんな経験、ありませんか？
特に屋外で利用されるアプリにとって、端末の温度はユーザー体験を大きく左右する重要な要素です。スマートフォンが熱を持つと、アプリのパフォーマンスが著しく低下したり、一部の機能が制限されたりすることがあります。このような影響を把握しておくことは、快適なサービス提供のために非常に重要です。

本トークでは、Foundationフレームワークに含まれる ProcessInfo.ThermalState API に注目します。このAPIを使うことで、デバイスの熱状態を4段階で把握することが可能です。
今回は実際に屋外で使われるモビリティアプリにおいて、ThermalState が季節や時間帯、アプリの状態などによってどのように変化するのかなど、実測データとともに詳しくご紹介します。
さらに、熱状態に応じてアプリが取ることができる対策についても解説します。

スマートフォンを「熱中症」から守り、夏でもクールで快適なユーザー体験をお届けしましょう！

皆さん、サーバ側で時間がかかる処理のハンドリングや、進捗を表示する際、ついポーリングで実装していませんか？
弊プロダクトでもポーリングを採用するケースが多かったのですが、これからのプロダクトの進化に備えてSSE通信基盤をモバイルアプリで構築し、全面的に採用しました。
本セッションでは、Server-Sent Events(SSE) という2009年から存在する歴史の長い技術について詳しく説明し、ポーリングと比較した際のメリット、生成AIを活用したプロダクトにおけるUX向上の実例も交えて解説します。

• SSEの技術的な説明
• ポーリングとSSEの比較
• 生成AIとSSE
• プロダクトでの活用事例

「ポーリング以上、WebSocket未満」
そんな立ち位置のServer-Sent Events(SSE) がこの大LLM時代の流れに乗って知名度が上がり、普及されることを祈ってお届けします。