プロポーザル

どこからでも触れられるシングルトンは、スレッド安全性を保証しないまま肥大化しがちです。結果として実行時のクラッシュや不具合の温床になり、保守コストを引き上げます。Swift6では strict concurrency checkingがデフォルトで有効化され、Sendable 準拠や @MainActor／actor の宣言によって静的にデータ競合を防げます。シングルトンもここに乗せれば「安全な共有状態」へ生まれ変われます。

しかしながら、シングルトンはその特性上、通常のクラスよりも修正による影響範囲が広くなってしまうので、Sendable / actor / @MainActor の方針選択が一筋縄ではいきません。さらに UI 層・ネットワーク層の処理・状態管理など巨大な責務を一身に抱えたいわゆる"神シングルトン"が存在している場合、MainActor と非 MainActor のコードが混在する等、方針選択をより複雑化します。問題の簡単化のため、リファクタリングでシングルトンを適切な単位に分解することは一つの手ですが、重要機能を担っている場合や改修コストをかけれない場合、現実的な選択肢として選びづらいことも多いかと思います。

本トークでは、シングルトンを実際に Swift 6 へ対応させた経験をもとに、シングルトンをシングルトンのまま安全にSwift6に対応させる上での工夫、知見を共有します。具体的には以下をお話しします
・シングルトンをSwift6対応させるための基本的な方針
・神シングルトンにありがちな状況と対応方針

皆さんのプロジェクトに眠るシングルトン達をSwift6の世界に安全にお連れするためのご参考になれば嬉しいです。

みなさん、ユニットテストを書いていますか？
今回は、私たちの会社でどのようにしてユニットテスト文化を社内に根付かせたか、そのプロセスと成果についてお話しします。

まず初めに、ユニットテストの重要性について簡単に触れ、なぜ私たちがこの取り組みを始めたのかを説明します。次に、具体的なステップとして、教育プログラムの実施や、社内でのベストプラクティスの共有方法について紹介します。また、チームメンバーの意識改革を促すための工夫や、実際に直面した課題とその解決策についてもお話しする予定です。

最後に、この取り組みの結果として得られた社内の変化や、プロジェクトの品質向上にどのように寄与したかについて詳しく説明します。皆さんの組織でもユニットテスト文化を根付かせるためのヒントを得られるセッションにしたいと考えています。

ぜひ、私たちの経験を通じて、ユニットテストの重要性とその効果について理解を深めていただければ幸いです。

Swift Macrosを日常の開発で活用できていますか？

Swift 5.9から導入されたマクロ機能は、Swiftコードをコンパイル時に生成できる仕組みで、定型的なコードの生成や、静的解析によるバリデーションが可能になります。
最近では、Swift公式からSwift Syntaxのビルド済みバイナリが提供されるようになり、これまで導入のハードルとなっていたビルド時間の問題も軽減され、より気軽にマクロを活用できる環境が整ってきました。

Apple自身も #Preview や @Observable、#expect（swift-testing）など、マクロを積極的に活用しており、実際のプロジェクトでも目にする機会が増えてきています。
また、サードパーティ製のOSSにおいても、Swift Macrosを活用したライブラリが次々と登場しています。例えば、イニシャライザの生成、プロトコル準拠の生成、文字列リテラルの静的検証など、ユースケースは多岐にわたります。

本トークでは、こうしたOSSにおける実際の利用事例をもとに、Swift Macrosがどのような課題を解決しているのかを分析し、活用パターンを体系的に分類します。そして、「自分のプロジェクトでどんなMacroを使えばよいか」「どう活用すれば開発効率を上げられるか」といった観点で、実践的な知見を共有します。

本トークを通して、皆さんがプロジェクトに最適なマクロを選択・活用できるようになることを目指します。

AI Agentの進化によって、「Design to Code」への期待値が大きく高まっています。

その動きを受けて、Figmaで作成されたデザインを元に、GitHub Copilot Agentを活用してSwiftUIコードを自動生成する取り組みを行いました。
精度向上のためにコンテキスト整備（ディレクトリ構造、コード規約、TCAの実装パターンなど）やプロンプト最適化（実装計画や注意事項の指示追加など）を試みましたが、リスト表示の消失やアイコンがそのまま残るなど、UIの再現度が著しく下がってしまい、期待通りにAgentが動いてくれないこともしばしばでした。

これらの課題をどのように解決し、どのような結果が得られたのか、AI Agentを使いこなすために得られたヒントをお話しします。

• The Composable Architecture（TCA）を用いた SwiftUI のコード生成は可能か
• デザイン再現性を高めるための GitHub Copilot Agent 使いこなし術
• Figmaデザインデータの作り方と生成コードの品質は相関するのか

本セッションでは、Flutterで開発されている出前館アプリにおいて、継続的かつ安定的なリリースを実現するために導入した「リリーストレイン」の運用設計と、運用初期に直面した課題・工夫について実践的な知見をお届けします。
さらに、App Store / Google Play への申請時に発生したイレギュラーケース（審査の長期停止、日本国外からのアクセス制限によるリジェクト、プライバシーポリシー指摘など）にどのように対応したのか、その事例を共有します。

開発現場でリリース業務に携わるなか、多くの関係者が関わるアプリのリリースや、ストア審査の不確実性に対して、再現性のあるプロセスを設計・維持することの難しさを日々感じています。
現場での実践を通じて得た知見を共有することで、同じ課題を持つアプリ開発チームに役立てていただけたら幸いです。

1. 出前館アプリの開発体制とリリースの課題

   • Flutter製の大規模アプリとしての特徴
   • リリースの不安定さ・調整コスト

2. リリーストレイン導入の経緯と設計

   • なぜリリーストレインを選んだのか
   • 月2回のリリーススケジュールと周辺業務の整備

3. リリーストレイン運用の工夫と課題

   • 開発チーム・QA間の連携改善
   • 運用安定化までに乗り越えた壁とその対応

4. ストア申請時のイレギュラーケースとその対応

   • App Storeの審査が長時間止まった事例
   • 国内限定サービスが審査に与えた影響
   • Google Playでのライブラリ由来のプライバシーポリシー指摘対応

想定する対象者

• モバイルアプリのリリースを担当しているFlutter/iOS/Androidエンジニア
• 複数の関係者と連携しながら、継続的なアプリ運用を行っているPM・EM・技術リーダー

―「最近アプリがもっさりしてきた」「なんだか動作がもたつく」―
こうしたパフォーマンスに関するフィードバックを一度は受け取ったことがあるのではないでしょうか。
しかし、この「もっさり」は一体なにが原因で、どれくらい遅いのか？定性的な印象だけでは、改善の手がかりがつかめません。
弊社が開発しているアプリでも、特に利用頻度の高いユーザーから「もっさりする」といった声が寄せられていました。
そんな見えない「もっさり」の正体を明らかにし、改善につなげるためにMetricKitを活用しました。

このトークで話すこと

本トークでは、ユーザーの「アプリがもっさりする」という定性的な問題を、MetricKitを使って定量的に分析し、改善した方法を紹介します。

• MetricKitの概要と選定理由
• MetricKitを使ったパフォーマンスの見える化
  • メトリクスの収集プロセス
  • メトリクスの分析手法と整理方法
• メトリクスの分析から見えたボトルネックとなっていたCoreDataの処理
• 実際に行った改善アプローチとその効果
  • CoreDataの処理の最適化
  • 計算量を意識した実装
  • 結果：処理時間を大幅短縮し、ユーザー満足度も向上
• コードのパフォーマンスを測定する方法

あなたのアプリにも、ユーザーがまだ言葉にしていない「もっさり」が潜んでいるかもしれません。
パフォーマンス改善の第一歩は、現在の状態を正しく測ること。つまり、「定量化」です。
本トークを通じて、ユーザーの体感を数字で捉え、改善へつなげる方法を知ることができます。
ユーザーから「アプリが軽くなった！」という喜びの声を聞く方法を一緒に学びましょう！

​Swiftは安全性と効率性を両立する言語ですが、従来の画像処理APIであるvImage_BufferはObjective-C時代から存在しており、ポインタ操作やメモリ管理の難しさ、型の安全性に課題がありました。これらの問題を解消するために登場したのがvImage.PixelBufferです。

​本セッションでは、vImage_BufferからvImage.PixelBufferへ移行した実体験をもとに、以下の観点から、Swift時代のモダンな画像処理の設計と実践を解説します：

・ vImage.PixelBufferとvImage_Bufferの使用感とAPI設計の違い
・ 型安全性・自動メモリ管理による利点と、移行時に直面したギャップ
・ 安全性とパフォーマンスのバランス：PixelBufferを活用した効率的な画像処理パイプラインの構築
​・ vImage.PixelBuffer導入・リファクタリングの実践Tipsと注意点

​対象は、Swiftで画像処理を行っているiOSアプリ開発者や、vImage.PixelBufferの導入を検討しているエンジニアです。Cの壁を越えて、Swiftらしい表現で画像処理をより安全に、より簡潔に扱うための道筋を共有します。

エッジ AI とは、スマートフォンなどのエッジデバイス上で行う AI 関連処理のことです。

近年のハードウェア (特に GPU や Neural Engine) の進化により、アプリでより高性能なエッジ AI を実現できるようになりました。

iOS をはじめとする Apple プラットフォームも例外ではなく、 Core ML というエッジデバイスに最適化された AI フレームワークを提供してきました。近年では、 Apple Intelligence や WWDC 2025 で発表されたばかりの Foundation Models により、学習済みモデルを用意せずともアプリにエッジ AI 機能を搭載できるようになる未来も見えてきました。

また、 Apple だけでなく PyTorch といった有名な AI フレームワークも、エッジ AI 関連のサポートを強化しており、著名な学習済みモデルのアプリへの組み込みについても可能性が広がってきました。

AI 関連技術が世界的に注目を浴びる中、本トークではエッジ AI をキーワードにスマホアプリとエッジ AI の可能性について、実機での動作検証結果を交えてご紹介します。

アジェンダ

• エッジ AI とは 〜 エッジ AI とクラウド AI
• エッジ AI の活用事例 〜 自動運転やスマホアプリでの活用
• CoreML 〜 エッジ AI に最適化された機械学習フレームワーク
• サードパーティ製ライブラリのエッジ AI 用フレームワーク 〜 PyTorch と ExecuTorch
• Apple プラットフォームにおけるエッジ AI の今後 〜 アプリでの Apple Intelligence と Foundation Models の活用

Swiftで非同期処理といえば、かつてはClosure一択。ですが、複雑なネストや可読性の低さに悩んだ経験はありませんか？
本LTでは、若手エンジニアである私が「Closure地獄」から抜け出すきっかけとなった個人開発でのasync/await体験をもとに、チーム内での技術導入に挑戦した実話をお話しします。
私は学習の一環でFirebaseとSwiftUIを使ったチャットアプリを開発していました。そこではじめてSwiftのasync/awaitを本格的に使い、kotlinライクなtry-catch構文処理の見通しやすさ、エラーハンドリングの明快さに衝撃を受けました。
「これ、業務でも絶対に使える」
そう確信し、上司やチームの理解を得るために比較資料を作成し、サンプルコードを用意して小さなPull Requestから導入を開始しました。反対意見や不安の声もありましたが、自分で課題を見つけ、自分で提案し、自分でコードを書いて示すことで、徐々に受け入れられていきました。
今では、チームの新しいコードには自然にasync/awaitが使われるようになり、非同期処理の可読性が大きく改善されました。
この経験を通じて実感したのは、「仕事は与えられるものだけじゃない。自分で作ることもできる」ということです。
若手でも、技術の力でチームを変えられる。その一歩を踏み出す勇気を、このLTで少しでもお伝えできたら嬉しいです。

iOSDC と同い年の OS が Apple のプラットフォームにはあります。
それが watchOS です。
watchOS は、Apple Watch と一緒にリリースされ、そのわずか6週間後の WWDC 2015 において最初に公式プレビューされました。
それ以降、iOS、 macOS などの OS とともに毎年アップデートが行われ、多くのユーザー、開発者に愛されてきました。

このセッションでは、10歳を迎えた watchOS の歴史を5分に凝縮し、ユーザー体験の向上や開発者向け機能の拡充といった具体的な進化のポイントについて説明します。
我が子の成長を見るように、暖かく見守っていただければ幸いです。

私が現在開発に携わっている iOS アプリでは、 iOS Deployment Target が 15 に上がったことを機に、今年から本格的に SwiftUI の導入を開始しました。

現状、機能・UI 共にシンプルな画面への対応が中心ということもあり、 MVVM パターンに近い設計方針で実装が進められています。しかし、複雑な画面でも設計が適用可能かどうかなど、今後へ向けた課題も抱えています。

また、 SwiftUI はバージョンが上がるごとに機能追加が行われていますが、一方で iOS Deployment Target によって使用可能な機能に制限が生じることから、プロダクトのサポート方針を考慮し、長期的なメンテナンス性維持の観点から SwiftUI の導入を進める必要があります。

本トークでは、 画面の複雑度 と iOS Deployment Target (本トークは 15 以上を対象とします) という 2 つの変数を元に、ケーススタディや実際のアプリの事例を交えて最適な設計方針について検討した結果をご紹介します。

アジェンダ

• iOS Deployment Target から見た SwiftUI
• 画面の複雑度から見た SwiftUI
• 画面実装ケーススタディ 〜 iOS Deployment Target 15 から 18 まで
• 画面実装ケーススタディ 〜 単機能な画面から複数の API 呼び出しを伴う画面まで

世の中にはBuy Me a Coffeeのように、クリエイターが寄付・投げ銭を受け取るためのサービスがあります。
しかし、そうしたサービスはユーザーを決済可能なWebページに誘導することになるため、iOSアプリにそれらのリンクを掲載することはAppleの規約により禁止されています。

それを踏まえると、「広告を載せるのはアプリの世界観に影響を与えるから避けたい。でも収益源が無いからせめて寄付や投げ銭を受け取りたい」と考える開発者は、アプリ内課金で似た仕組みを作る必要があります。

本トークでは、個人開発アプリに実際にユーザーから寄付・投げ銭を受け取るためのアプリ内課金を実装し、今年約50のユーザーに課金していただいた私が、その実装と実績を振り返ります。
具体的には特に工夫した三点（金額設定UI、ライティング、課金に対するフィードバック）について、その意図と実装、および実際に運用して感じた良かった点と改善点を共有します。

それぞれの詳細は以下の通りです。
・課金額の設定UIについて：ユーザーがどのように課金額を決定できればスムーズかを考える
・ライティングについて：ターゲットとするユーザー層によっては「コーヒーをn杯贈る」というよくある表現が、その分の投げ銭を意味するということが伝わらないのでは？という疑問から考える
・課金直後にユーザーに返すフィードバックの必要性について：消耗型課金だが、何かアイテム数のようなものが変化するわけでもない課金のフィードバックはどうあるべきか、Buy Me a CoffeeやYouTubeのSuper Chatの体験から考える

本セッションは、位置情報アプリを開発しているエンジニア、あるいは位置情報データの効率的な扱いに関心のあるエンジニアを対象とし、アプリ開発の現場で直面する課題をもとに、位置情報の取り扱いに必要なデータ構造やアルゴリズムの実践知識を紹介します。

位置情報アプリでは、ユーザーの位置をもとに地図上に線や領域を描画したり、特定の場所が移動禁止エリア内にあるかを判定する機能が求められます。しかし、これらの処理は地図データの量が膨大であること、位置情報が連続的かつリアルタイムで変化することから、パフォーマンスやデータ効率の観点で多くの課題に直面します。

本セッションでは、こうした課題を解決するための具体的な技術として、以下の内容を解説します。
• Google Mapsで使われている「Encoded Polyline algorithm」：ポリラインやポリゴンを効率的に表現し、データ転送量を削減する方法
• Point in Polygonアルゴリズム：特定の位置がポリゴン内に含まれるかどうかを判定する仕組み
• 位置をポリゴン外に押し出すための最短距離計算アルゴリズム：ポリゴンの外にある「最近傍点」を求めるための幾何計算手法
• 凸包アルゴリズム：簡易的に複数のポリゴンを合成する手法

これらの技術は、単なる理論ではなく、アプリ開発の現場で実際に役立つ知識として紹介します。ポリゴン内判定の最適化や地図上でのオーバーレイ描画の工夫など、具体的な課題解決の実例を交えながら、技術の必要性と効果をわかりやすく伝えます。

聴講後には、位置情報アプリのデータ構造・アルゴリズムの実践的な知識が身につきます。

光学式マウスの仕組みを知っていますか？
マウスの底にあるLEDで机の表面を照らし、その模様の変化を毎秒数百〜数千回のスピードで撮影。
画像同士を比較して「どっちに動いたか」を計算し、カーソルを動かしているんです。

カメラと画像処理で動きを検出する、まさに小さな画像認識システム。
これってiPhoneでもできそうですよね？
そう思い、意気揚々と始めた「iPhoneを光学式マウスにするアプリ」の開発。
このトークではその過程で得た様々な知見を皆さんに共有します。

このトークを通じて、iPhoneの新たな可能性を探る楽しさを一緒に感じていただければ幸いです。

本セッションでは、位置情報アプリを開発しているアプリエンジニア、または位置情報技術に興味を持つ方を対象とし、位置情報の「精度」や「時刻の取り扱い」について解説します。
スマートフォンで取得できる位置情報は、地図アプリ、交通サービス、IoT、防災など、日常生活を支える多くのアプリで活用されています。しかし、その位置情報がどのような仕組みで得られているのか、特に時刻情報がどのように関わっているのかについては、普段意識することが少ないかもしれません。

本セッションではまず、古代より人類がどのように時刻を求めてきたかを述べ、位置と時刻を求める人類の挑戦として、18世紀イギリスで制定された「経度法」と、それにより始まった経度問題の解決に向けた競争、そしてジョン・ハリソンによる海洋クロノメーターの開発を振り返ります。次に、電波を使った測位方法の歴史と、GPSをはじめとするGNSS（全地球測位システム）の基本原理を解説し、衛星信号を用いて端末の位置を特定する仕組みを解説します。

さらに、GNSSの生データを取得・解析するための専用ツール「GNSS Logger」と「GNSS Analysis」を活用し、端末が捕捉している衛星の数や種類、方向、信号強度といったデータを可視化します。これにより、都市環境でのマルチパス反射、大気遅延（電離層・対流圏）、衛星の配置や補足数不足といった精度劣化要因が、どのようにデータに現れるのかを具体的に解説します。

最後に、センチメートル級の高精度測位の仕組みと、それがもたらす未来の可能性についての展望を語ります。
聴講後には、位置情報と時刻情報の本質的な関係を理解し、位置特定にまつわる歴史と技術の知識が身につきます。

多言語対応をしていると、いつかはRTL（Right To Left）言語、つまり右から左に書く言語への対応が必要になる場面に出会います。私が担当しているiOSアプリでもその対応が求められました。

ではRTL言語対応って具体的に何をすべきかご存知でしょうか？iOSでは、OSやフレームワークによってある程度「自動対応」がされます。しかし、UIの崩れ、画像の反転、レイアウトの意図しない挙動など、エンジニアが「手動対応」しなければいけない場面も存在します。

このトークでは次のような観点から、私が調査、実装をしたRTL言語対応の知見を共有します。

• そもそもRTL言語対応とはどんなものか
• RTL言語対応に関するAppleの公式情報をおさらいしてみる
• OS、フレームワーク側が「自動で」してくれるRTL言語対応
• エンジニアが「手動で」頑張るRTL言語対応
  • レイアウト修正
  • 画像修正
  • その他思わぬ落とし穴
• 対応状況をどのように確認するか

このトークを聞けば、初めてRTL言語対応に取り組む方でも迷わず対応できるでしょう。逆向きUIの世界、覗いてみませんか？

SwiftUIでテキストに意味や見た目の属性を与える「修飾」には、
Modifierを重ねる従来の手法、
iOS15以降のAttributedStringでの部分的なスタイル指定、
さらにiOS17以降のMarkdown記法の活用と、さまざまな選択肢が増えています。

しかし実際には、

• 差分更新の仕組み
• アニメーションとの相性
• Unicode結合文字や多言語での動作
• 複雑なハイライトや部分スタイルの表現力

など、見た目だけでは分からないハマりどころが多く、
どの方法を選ぶべきか迷うことも少なくありません。

このトークでは、SwiftUIのレンダリング仕様（Viewツリーの構造や再評価のタイミング）や、
状態管理との連携（State/Bindingと修飾の適用順序の関係）といった基礎を踏まえながら、
Modifier・AttributedString・Markdownという3つの修飾手段を深く比較し、
それぞれの得意・不得意を整理していきます。

さらに「一文中の一部だけ色を変える」「異なるフォントの混在」「多言語テキストの表示」など
実践的なユースケースをデモで比較し、
保守性やパフォーマンスの違いを体感していただきます。

SwiftUIのText修飾を極め、効率的で実用的なUI構築の知見をお持ち帰りください。

内容：

• SwiftUIにおけるText修飾の基礎と進化
• Modifier・AttributedString・Markdownの仕様と特徴
• Unicode結合文字・多言語・複雑ハイライトの落とし穴
• 「部分装飾」「複数フォント」「Markdown混在」の比較デモ
• 差分更新・保守性・パフォーマンスの観点での比較
• 最適な選択をするための判断基準とTips

.bold() や .foregroundColor() などの一般的なModifierと、
iOS15以降に導入されたAttributedStringを用いた柔軟で強力な部分装飾。

SwiftUIでテキストを装飾するこの2つのアプローチは、
見た目こそ似ているものの、その仕組みや設計思想は大きく異なります。

• 差分更新のメカニズム
• アニメーションの動作特性
• パフォーマンスの特性
• 複雑なハイライトを含む表現力

など、見た目だけでは気づけない現場でハマりがちな落とし穴を徹底的にひも解きます。

このトークでは、SwiftUIのレンダリング仕様をもとに、
ModifierとAttributedStringの得意・不得意を余すことなく比較し、
実装サンプルやデモを交えてわかりやすく紹介します。

「同じUIを作るならどちらが最適か？」を迷わず選べる軸をお持ち帰りください。
普段なんとなく選んでいる人こそ、きっと新しい発見があるはずです。
初心者から中級者まで楽しめる、SwiftUIテキスト表現の探究にお付き合いください！

内容：

• SwiftUIにおける文字列装飾の基礎
• Text Modifierの仕様と強み・弱み
• AttributedStringの仕様と強み・弱み
• 同じ見た目を2通りで構築する比較デモ
• 差分更新・パフォーマンス・アニメーションの挙動の比較
• 適切な選択をするための判断基準

ある日、ユーザーから「画面をスワイプしてもカルーセルビューが動かない」との報告が届きました。

調査の結果、Xcode 16への開発環境とiOS 18への端末のアップデートを契機に、SwiftUIのジェスチャー優先順位に仕様変更があり、親ビューであるScrollViewとその子ビューであるカルーセルビューのジェスチャーが競合し、結果としてカルーセルビュー側のDragGestureが正しく検知されなくなっていたことが判明しました。

本セッションでは、ユーザー体験に大きな影響を与えうる、SwiftUIフレームワークのジェスチャーの仕様変更によって、どのようなViewの構成で問題が発生したのかを再現しつつ、発見から解決までの過程を丁寧に解説します。さらに、今後も仕様変更に耐えられるUI設計のヒントを共有します。

• iOS 18からSwiftUIのジェスチャー優先順位にどんな変更が加えられたのか？
• ジェスチャー競合によって引き起こされた問題とその解決の道のり
  • ScrollView vs .highPriorityGesture() の相互作用
  • DragGesture(minimumDistance:) による競合の回避とその副作用
  • UIGestureRecognizerRepresentableによる本質的な競合解消
• まとめ：再発を防ぐ設計と、変化に強いUIをどう作るか

Model Context Protocol（MCP）は、自然言語によるユーザーのプロンプトから、AIがツールを呼び出す際のリクエストを構造化し、外部サービスやアプリと連携できるようにするためのプロトコルです。

最近では、さまざまなアプリや開発ツールでもこの仕組みが使われるようになりつつあり、Swiftエンジニアにとっても無視できない存在になってきました。

本トークでは、
「MCPって聞いたことはあるけどよく分からない…」
「MCP Serverって何ができるんだろう…」
そのような方でも、SwiftでMCP Serverを構築する第一歩を踏み出せるように、わかりやすく、実践的にご紹介します。

具体的には以下のような内容を扱います：

1. MCP Serverとは
   • MCPとはどのような役割を持つプロトコルなのか、どのように利用されているのかわかりやすく説明します。
2. Swiftを用いてMCP Serverを構築する
   • MCP公式SDKを使用したMCP Serverの構築、IoTデバイスの操作、AIとの連携について解説します。
3. Swiftで構築したMCP Serverから実際にデバイスを操作してみる
   • 入力したプロンプトがどのようにMCP Serverを通じて処理され、デバイスが動作するのかを実演します。
4. 実際に構築して明らかになったこと
   • MCP Serverを実際に構築してみてわかった課題と今後の展望について共有します。

「AIと連携できる仕組み」をSwiftで体験しながら、MCPの世界に楽しく入門してみませんか？