プロポーザル

音声でアプリの入力が完結したらとても便利だと思いませんか？

音声入力の代表格である Siri は2011年に iPhone に登場して以来年々進化を遂げ、「声で操作する」という動作は当たり前のものになりました。
音声入力をアプリに組み込む方法としては Speech framework があり、日本語もサポートされており、音声をそのままテキストに変換ができます。
しかしアプリの入力は、テキストだけではありません。
トグルやピッカーなど、テキスト以外のアプリ入力としては Speech framework 柔軟性に欠けていました。

ところが、WWDC25 で発表されたオンデバイスLLM Foundation Modelsを使うと状況が一変します。
@Generableマクロを使うことでプロンプトから任意のSwift型のデータを出力できるようになったのです。
つまり Speech frameworkで音声入力をしてテキストに変換し、Foundation Modelsのプロンプトとして渡せば、アプリの入力を音声で完結できるようになりました。

このトークではSpeech frameworkとFoundation Modelsでアプリの入力を簡便にする方法を発表します。
Todoアプリを例に実装例やオンデバイスLLMでの効果的な利用方法をお話します。

「目次」
・Foundation Modelsとは？対応機種や制限は？
・Speech frameworkと組み合わせる実装例
・効率の良いプロンプト作成方法
・実際のユーザーの評価とフィードバック

あなたのアプリもキーボード中心の UX を“声だけの入力”へアップグレードしてみませんか？

皆さんのアプリでは、分析ログを正確かつ漏れなく収集できていますか？
私たちのサービスでも多くのログを送信していますが、かつては実装漏れやデグレによる送り漏れが頻発し、効果測定ができず仮説検証に大きな支障が出ていました。
とはいえ、少人数チームかつiOS・Androidの両対応、さらに限られた予算の中で、導入できる手段には制約がありました。

そこで私たちは、「ログ送信箇所にテストコードを追加する」方針をとることにしました。
この実践により、徐々に実装漏れがなくなり、デグレによるログ欠損も減少しました。

テストコードといえば通常はビジネスロジックに対して書くものという認識があるかもしれません。
「なぜそこにテストを？」と思われるかもしれませんが、設計を工夫すればログ送信にも十分活用でき、ビジネス上の価値も高いと感じています。

本トークでは、ログ送信に対してテストを書くことの効果や実例、そして設計上の工夫についてご紹介します。
ログ品質の担保に課題を感じている方に、実践的なヒントをお届けいたします。

iOS/iPadOSアプリを作る上で、開発者としての基本姿勢はAppleの標準APIを使ってUIを実現することです。
Appleが用意した高レイヤーのAPIを使うことで、簡単にリッチなUIを実現できます。

しかし、そういったAPIは高レイヤーがゆえに、時には小回りがきかないことも事実です。
そのような場合に、UIViewからフルスクラッチでカスタムUIを作ることが選択肢になります。
Appleが提供するAPIにはない表現を実現することができ、みなさんのアプリの世界観にピッタリなカスタムUIを提供できます。

ただ、カスタムUIを実際に作るとなると、標準APIがカバーしてくれていた多くのことを自前でカバーする必要が出てきますが、そのコストは過小評価されがちです。
アニメーション、ジェスチャー、インタラクション、パフォーマンス、入力デバイス、アクセシビリティ...
開発者はこれら全てに対して、Appleが用意した標準のUIと並んでも違和感がないレベルまで実装し、メンテナンスし続ける「覚悟」が求められます。

このトークでは実際に自分が作ったカスタムUI、作らなかったカスタムUIを題材に、以下の流れで話をします。

• どういう場合にカスタムUIを作るべきか、作らないべきか
• カスタムUIを実装する時、どのような点に注意すればいいのか
• 実装されたカスタムUIに対して何を確認したらいいのか
• カスタムUIを導入する際の覚悟

このトークを通じて、みなさんがiOS/iPadOSアプリ開発者として、適切にカスタムUIと向き合えることを目指します。

みなさんの開発チームにiOSエンジニアは何人在籍していますか？
中には少数のエンジニアで開発・運用しているケースもあるかと思います。

少人数体制では、チームにかかるリリース作業の負荷が大きくなりやすく、どうしてもリリース間隔が空いてしまい、頻度が低下しがちです。
しかしリリース頻度の減少は、ユーザーからのフィードバックを得る機会 = 仮説検証を通じたサービスの成長・改善機会の減少にもつながるため、可能な限り避けたいものです。

私が開発・運営に携わっているグルメサービス「Retty」のアプリチームは、iOSエンジニア2名を含む全3名という小規模チームながら原則「毎週リリース」を実現し、直近1年間のiOSアプリのリリース回数はのべ50回に達しました。

この継続的かつ高頻度なリリースによって、仮説検証や機能の軌道修正を機動的に行うことができ、ビジネス視点でも大きなメリットを得られていると実感しています。
もちろん、これは気合で成し遂げているわけではなく、開発メンバーの負荷を最小限に抑えながら「楽々」達成できるよう、さまざまな工夫とテクニックを活用しています。

本トークでは、毎週リリース実現のため、我々が実践してきた開発・運用手法や工夫についてわかりやすくご紹介します。
また高頻度リリースを実践するうえでの注意点や、直面した課題・失敗事例についてもお話しいたします。

「たくさんリリースして、たくさん学んで、たくさん成長する」
そんなアプリ開発・運用を目指す方にとって、きっと参考になる内容です。ぜひ本発表をご覧ください。

トーク内容

• 毎週リリースのメリット
• Retty iOSアプリでのリリース実績
• ブランチ・リリース戦略
• アプリ・API設計の工夫
• 自動化・CI/CDの活用
• リリースフローの最適化
• 毎週リリースでの注意点・失敗事例

iOSアプリ開発において、状態監視の実装方法は時代と共に多様化しています。従来のDelegateやKVOから、単純なクロージャ、Combine、AsyncSequence、そしてSwiftUIのObservationに至るまで、現在では開発者には数多くの選択肢が与えられています。

しかし、きちんと仕組みを理解せず「最新技術だから」「手軽に書けそうだから」といった理由で技術選定を行うと、思わぬ罠を踏み、結果としてプロジェクトに不適切な実装を生むことにもなりかねません。加えて、既存の手法を用いる場合でも、Swift Concurrencyへの対応という現代的な課題は避けて通れません。

本発表では、各状態監視手法の特徴や長所・短所を整理し、どのような場面でどの技術を選択すべきか、その実践的な指針を提案します。皆さんが日々の開発で自信を持って技術選定できるよう、その一助となれば幸いです。

ユーザーが投稿した写真を公開情報として提供するサービスでは、映り込みによるプライバシーの問題への対処が必要となることがあります。
私が開発運営に携わるグルメサービスRettyでも、店の雰囲気を伝える手段として飲食店の店内で撮影された写真を収集していますが、店員や他のお客さんが映った写真が投稿されてしまうことが大きな課題でした。
写真を適切に加工することでこの問題は回避可能ですが、外部アプリでの加工はアプリ間の移動が煩雑であり、さらに手動で人の顔に加工を施す作業負荷も高いため、これが店内写真の投稿率を下げる要因となっていました。

そこでRettyでは、アプリ内で加工が完結できるよう新たに「顔ぼかし」機能の提供を開始しました。
これは被写体を判別し、顔の部分だけにぼかしを入れる機能で、本機能によってユーザーは気兼ねなく内観写真を投稿することができるようになりました。
本機能の実装にはVisionFrameworkを用いており、オンデバイス判定による高速かつ高精度な顔判別と加工を行っています。
Apple標準のAPIのみを使用しているため、専門知識も不要でシンプルながらも必要十分な設計で実現することができました。

本トークではRettyでの「顔ぼかし」の企画からリリースに至るまでの流れをお話しながら、技術選定、設計、対処した課題についてご紹介します。
VisionFrameworkの活用事例として、みなさんのサービス開発にも役立てていただける内容となっています。

トーク内容

• Rettyの写真投稿と内観写真における課題
• VisionFrameworkについて
• ぼかし機能の設計と仕様
• リリースまでに発生した課題と対策
• 企画からリリースまでの総括

APIが新しいSpeechフレームワークでは大きく改善されたことをご存知でしょうか？AppleはSiriやキーボードに音声入力のインターフェイスを統合しています。新しいSpeechフレームワークはこれまで内部にあったAppleの音声入力の機能を公開することで、より高精度の文字起こしが簡単に、手軽に実装できるようになりました。

また、音声入力の価値は、LLMの登場によって再評価されています。ノートアプリや通話アプリでは、ミーティングノートを自動で作成することが次世代の標準機能とされつつあります。さらに、ライブ配信では文字起こしを活用したリアルタイム翻訳が増えてきており、音声入力がアプリのコア機能として位置づけられることが予想されます。

しかし開発者として、音声入力をアプリに持ち込むことを考えた時にどのようにアプリ全体を設計したら良いのか悩むことが多くあります。どのようにまず音声を取得するのか、リアルタイムと録音済みでの考慮する点の違いはあるのか、抽象化の観点はどうすべきか、Speechフレームワーク以外に同様の機能を提供するフレームワークは何があるのか、どのようにLLMと連携すべきなのか、など開発してみないと考えにくい観点がたくさん挙げられます。

本トークではこれらの疑問を解消してアプリに音声入力を持ち込むために必要な知識を包括的に提供します。

1. iOSで音声を扱うための基礎知識であるAVFoundationについて
2. 新しいSpeechフレームワークができること
3. 音声入力のWhisperKitとSpeechフレームワークの比較
4. 実例で学ぶSpeechフレームワークを使った音声入力アプリの実装方法

このトークを通じて、音声入力を活用したアプリの実装に挑戦してみましょう！

アプリ開発では、アプリと別のプロセスで動作する App Extension を開発できます。昔からある仕組みですが、近年特にアプリの機能をOSに渡すことでリッチな動きを実現する Widgets や Apple Intelligence (App Intents) で利用する機会が格段に増えています。この仕組みではアプリ本体とは別プロセスで動作するため、データの一貫性や安全な共有が求められます。しかし、 UserDefaults や FileManager、 Core Data、 Keychain など、共有・永続方法は多岐にわたります。また AppExtension は利用できるメモリにも上限があり、正しく設計しなければクラッシュやデータ破損、一貫性を損なうバグの原因にもなりかねません。

本トークでは、 App Extension を利用する際に安全かつ効率的にデータを扱うための指針について紹介します。基本的な設計に加え、実践的なTipsを幅広く紹介します。たとえば、起動処理で必ず行われるセットアップ処理に関する罠や、 App Extension 特有の制約に伴う DB のマイグレーションの扱い、 App と App Extension 間で発生したイベントをどのように通知しあうか、等です。

App Extension の活用が進む中、「データの正しい共有設計」はますます重要になります。 Widgets や Apple Intelligence にこれから対応しようとしている方にも、すでに導入済みで改善のヒントを得たい方にも役立つ内容です。

visionOS 26 で発表された「Apple Projected Media Profile（APMP）」 は、MP4／MOV ファイルに拡張メタデータを付与し、180°・360°映像を標準映像と同じ操作感で扱えるようにする新しい仕組みです。

高価な専用カメラが必要な「Apple Immersive Video」とは異なり、APMP ならGoProやInsta360など、個人でも手軽に入手できるカメラで撮影した映像を、そのまま Vision Pro の没入空間で再生できます。

本講演では、APMP の基本構造から具体的な変換手順までを次のトピックで解説します。

• APMP と Apple Immersive Video の違い
• APMP が扱える映像フォーマットの種類
• QuickTime コンテナ内「vexu」ボックスの仕組み
• Comfort Mitigation（VR 酔い対策）の仕組み
• 標準映像をAPMP対応ファイルへ変換する方法

更に、 APMP映像はSafari／WebKitベースのブラウザでも再生可能です。
Apple Vision ProのSafariではAPMP映像がどのように没入表示へ切り替わるのか、デモ動画を交えて紹介します。

最後に、個人開発している visionOS 2向け 360°動画アプリをAPMP対応へ移行した際に、どのような修正が必要だったのかを、差分ソースコードを示しながら詳しく解説します。

visionOS 26 で発表された「Apple Projected Media Profile（APMP）」 は、MP4／MOV ファイルに拡張メタデータを付与し、180°・360°映像を標準映像と同じ操作感で扱えるようにする新しい仕組みです。

高価な専用カメラが必要な「Apple Immersive Video」とは異なり、APMP ならGoProやInsta360など、個人でも手軽に入手できるカメラで撮影した映像を、そのまま Vision Pro の没入空間で再生できます。

本講演では、APMP の基本的な構造を説明し変換手順までを次のトピックで解説します。

• APMP が扱える映像フォーマットの種類
• QuickTime コンテナ内「vexu」ボックスの仕組み
• 標準映像をAPMP対応ファイルへ変換する方法

最後に、個人開発している visionOS 2向け 360°動画アプリをAPMP対応へ移行した際に、どのような修正が必要だったのかを、差分ソースコードを示しながら詳しく解説します。

ツールやビジュアライザなど大量データを扱うアプリでは、ユーザー操作によるメモリ不足でアプリの応答性が下がったり、Jetsamイベントによる強制終了が起こり、最悪の場合ユーザーデータの損失に繋がる可能性があります。クラッシュしてしまう前に防いだり、ユーザーに気付いてもらうためにはどうすると良いでしょうか。このトークでは、iOS・iPadOSのメモリやメモリワーニングの仕組みや、メモリ不足による強制終了を防ぐ知見について以下のような内容で紹介します。

• Jetsamイベントとは
• メモリワーニングによるメモリ不足の検知
• iPadOSのEntitlement(Increased Memory Limit, Extended Virtual Addressing)
• 実践例や失敗例の紹介

オープンデータとは、誰もが自由に使えるよう公開されたデータのことです。
気象、人口、交通、選挙など、行政機関が提供するオープンデータには、社会の課題や動きを読み解くヒントが詰まっています。
しかし、多くはCSVや表形式のまま放置され、活用されずに埋もれています。

このセッションでは、iOS 16以降で使える Swift Charts を活用し、こうしたオープンデータをアプリで「伝わる形」に変える方法を紹介します。

実際に気象データや交通データ、選挙・人口統計などを例に、データの取得、整形、そしてインタラクティブなチャート表示までをデモを交えて解説します。
たとえば、気象データを棒グラフで表示したり、通勤手段の変化をエリアチャートで見せたり、投票率を地図上にヒートマップで可視化したり。

「Swift Chartsを使ってみたくなる」「地域や社会のことをアプリで伝えてみたくなる」

そんな感覚を持ち帰っていただけるセッションです。

iOSアプリ開発においても、AIコーディングツールを活用して開発効率を向上させる事例が増えています。日々の業務でもさまざまな開発タスクでAIを活用していますが、私はその中でも特にFigmaのデザインデータをもとにSwiftUIコードを自動生成する取り組みに挑戦しています。

とはいえ、AIに「コードを生成してほしい」と指示を出すだけでは、期待どおりのコードを得ることは難しいのが実情です。特に独自のDesign Systemライブラリを使用しているような場合、適切なコンポーネントを使った狙いどおりのコードを生成させるにはいくつかの工夫が必要です。

このトークでは、安定的に品質の高いSwiftUIコードを生成するために行なった、以下のような試みについてお話しします。

• MCP Serverを用いてFigmaからデザインデータを正確に取得する
• Claude Code を使って既存のコードからSwiftUIとDesign Systemの関連性を学習し、ナレッジとして蓄積させる
• 生成されたSwiftUIのスナップショット画像とFigmaからエクスポートした画像データを比較し、AI自身に誤りを検知させ、自己修正を行わせる
• 自己修正と開発者からのフィードバックをもとにナレッジを自己更新させる
• AIを使ったコード生成における、学習 → 生成 → 検証 → 改善 のループの重要性
• 現時点における限界、理想と現実

AIコーディングツールの進化は非常に速く、追いかけるのが大変ですが、このトークを通じて、AIを活用した開発のヒントやアイデアを得て、日々の作業に取り入れるきっかけになれば幸いです。

概要:
「Apple Walletって何ができるの？」「どんな工程でカードが追加されるの？」「自分のアプリに使えるかな？」
そんな疑問を5分で一気に解決してみせましょう！
このLTでは、PassKitの全体像を爆速でキャッチアップできるよう、要点を絞ってお話しします！

やること:

• Apple Walletへのカード追加フロー解説
• こんなこと、できるんだよ！の紹介

やらないこと:

• 実装の詳細説明（時間の都合上、概要のみ）
• WWDC 25のNDA対象内容

こんな方におすすめ

Apple Wallet未経験で「何ができるか知りたい」方
導入検討中で「うちのアプリに合うか」判断したい方
キャッチアップ時間を短縮したい忙しい開発者

5分後、あなたはPassKitを「知らない技術」から「できるきがするぞぉぉぉぉぉおおお！」に変えられます！
キャッチアップ時間の激減を体感してください！
PassKitの可能性にワクワクしましょう！

本業iOSエンジニア、副業で弓削商船高専の教員の私が、iOS開発経験ゼロの高専生5名と共に全国高等専門学校プログラミングコンテストのテーマ「ICTを活用した環境問題の解決」に挑みます。
開発期間は6月から10月までのわずか4ヶ月。
この無謀にも見える挑戦のリアルタイムな奮闘記をお話しします。

本トークでは、以下の3つの視点から、私たちの挑戦の過程を共有します。

1. 社会課題からiOSアプリ構想へ
   紙の大量消費と個人情報漏洩という2つの社会課題を同時に解決するため、どのようなアイデアを経てiOSアプリの構想に至ったのか。
   そして、4ヶ月で開発を完遂するため、いかに機能を最低限の最低限まで絞り込んだのか、その要件定義のプロセスをお見せします。

2. ほぼオフライン環境のデモンストレーションを乗り越える技術設計
   コンテスト本番は運営側が用意しているインターネット環境は不安定、作品のデモンストレーションに使えるスペースも机一個分という縛りあり。
   そんな環境でも安定したデモンストレーションを実現するため、基本的な機能はローカル（サーバ含め）で完結するアプリ設計に舵を切りました。
   通常のアプリ開発とは一味違う、制約の多い環境下での技術選定やアーキテクチャ設計の勘所を解説します。

3. iOS初心者チームの育成とリアル
   iOS開発を知らない学生たちを、いかにして4ヶ月でiOSアプリを開発できるチームへと導くのか。
   技術コーチとして、PMとして若手育成の壁とそれを乗り越えるための工夫を、リアルな経験談としてお伝えします。

セッション当日は、10月のコンテストに向けて学生は最も修羅場の時期。
開発の最前線で"今"起きているたくさんの「つらみ」や学びを、熱量高くお届けする予定です。

※ なお6月末時点、プロダクトコードは1行も用意できてません。

「Write once, run everywhere」 - それはアプリケーション開発において、多くの開発者が追い求めてきた夢です。
モバイルアプリ開発の世界では、Androidの公式言語であるKotlinも例外ではありません。
Compose Multiplatform for iOSがStableとなり、アプリケーションの大部分をKotlinだけで開発する選択肢が現実的な視野に入ってきました。

しかし、過去の歴史が示すように、マルチプラットフォーム技術は常に諸刃の剣です。
技術選定とは、輝かしい未来を選ぶだけの行為ではないのです。チーム体制、事業フェーズ、プロダクトの性質によって、いつかその技術から「撤退」する日が来るかもしれません。
使用されていた技術の影響により部分的撤退が叶わなかったアプリも見受けられます。
本セッションでは、この予期せぬ「撤退戦」までを考慮に入れることの重要性を提起します。

本セッションではKotlin Multiplatformを主軸に、この「撤退戦略」を深掘りします。
まず、なぜKotlin NativeがネイティブAPIを直接呼び出し、ネイティブらしい振る舞いを実現できるのか解説します。そして、この特性が撤退時にどう活きるのかを明らかにします。
最後に、プラットフォームの専門家が変化の時代で自らの強みを最大限に発揮するための技術選定の指針を考察します。

トーク内容

• マルチプラットフォームにおける「共通化」の功罪
• なぜ技術選定で「撤退戦」を考慮すべきなのか？
• Compose MultiplatformとKotlin Multiplatformの現在地
• 撤退シナリオから見る、Kotlin Nativeの真価 Kotlin+UIKitの組み合わせ
• 変化の時代における、プラットフォーム専門家が活きる技術選択の指針

Swift TestingはWWDC2024でアナウンスされたテストフレームワークです。マクロを活用したAPIで、記述量を抑えつつ、parameterized testsやテストの並行実行もサポートされるものです。XCTestからのマイグレーションドキュメントも公式に準備されており、プロジェクトをSwift 6にさえできていれば、デメリット小さく良いテスト体験を享受できます。

一方で、課題になるのは「既存のテストをどう書き換えていくか」ではないでしょうか？プロジェクトによってはXCTestで記載されたもののみでなく、Nimbleのようなライブラリを用いて記載されたテストもあるでしょう。
これらの既存のテスト資産を効率よく、そしてより効果的なテストに変換することを皆さんは意識できていますか？マイグレーションドキュメントはXCTestとの対応表に過ぎず、「どう書き換えるか？」については焦点を当てていません。また、数個の単体テストを書き換えても、テスト実行時間の削減には大きな影響はなく、書き換える事自体のモチベーションが下がり、Swift Testingに置き換える事自体が後回しになっていないでしょうか？

そんな後回しになってしまう課題について、このトークではMCP ServerとこれをコントロールするAI Agentを導入することで、無駄な後戻りを小さくおおよそ自動でテストのマイグレーションを実行したケーススタディを紹介します。既存のswift-testing-revolutionaryやSwiftFormatのpreferSwiftTestingといったツールをそのまま使うのではなく、MCP Serverとして提供することのメリットについても触れ、Swift Testingに移行するモチベーションを上げる具体的なアクションの一つを皆さんと共有できればと思います。

10年前に誕生したUIKitアプリは、さまざまな課題を抱え保守性が悪い状態になっていました。状態管理のenumやフラグを抱えコードの見通しが悪くなったFat ViewController、ロジックを分離したが機能が積み上がるにつれて責務が混在したManager──そんなレガシーなアプリが生み出すバグと格闘する日々が続いていました。

本セッションでは、レガシーアプリを改善するためにアプリに生じるバグの傾向を分析し、「コードの見通しの悪さ」を生む構造的な原因に向き合う中で、SSOT(Single Source of Truth)を実現するための Store、状態管理であることを明確にするための ViewState など、iOSDC2023で紹介された「SVVSアーキテクチャ(Store・ViewState・View)」に辿り着くまでの過程をお話しします。

Fat ViewControllerからの段階的な分離、SwiftUI移行を見据えた土台作り──SVVSをスモールステップで導入するプロセスと、それによって得られた改善効果についてお話しします。

• レガシーUIKit MVC アプリが抱える課題
• アプリで頻出するバグの傾向分析
• 取り組む課題と実現したいことの整理
• Fat ViewController を段階的に改善した作戦
• SVVS になった後の SwiftUI 導入

位置情報を活用したアプリは便利である一方、権限ハンドリングやバッテリー消費といった数多くの課題が存在します。本セッションでは、実際のプロダクト開発で遭遇した問題とその解決策を具体的なコード例とともに紹介します。これにより、参加者が安全かつ効率的に CoreLocation を活用できるスキルを身につけることを目指します。

【話すこと】

• 位置情報のステータスの違いとリクエスト方法
• 位置情報変更時の効果的なデバッグ方法
• 位置情報によるアプリ起動のライフサイクル管理
• 移動経路取得のための実現方法と注意点
• バッテリー消費を抑えるための実践的手段

【対象者】
位置情報機能を実装予定の開発者、既存アプリの改善を考えている方、CoreLocationの課題に直面した経験を持つ開発者

CoreLocationに潜む課題を理解し、安心して位置情報を活用したアプリを開発できるスキルを身につけましょう！

AIエージェントの発展により、プログラミングの敷居は大幅に下がりました。プロンプトを書けばコードが生成され、どんどん実装を進めることができます。しかし、開発速度を上げることだけがAIエージェントの利点でしょうか？

AIエージェントを使えば未知の領域のプログラミングも十分な品質で実装が可能になります。
それまでは諦めていた不慣れな分野のプログラミングもアプリに取り込み、結果としてユーザー体験をよりよいものにできるでしょう。

私は7年間個人開発として風水アプリを開発を続けています。
このトークではその風水アプリにCursorを使って国際標準地球磁場 (IGRF-14)をSwiftへ実装し、MapKitを利用した偏角計算画面により風水アプリのUXを劇的に改善したプロセスを紹介します。
AIエージェントとの対話によって、IGRF-14モデルのPythonコードの理解からSwiftへのリファクタリングまでを一気通貫で実現し、リリースまで漕ぎ着けた一連の取り組みを解説します 。

「目次」
・地磁気モデル（IGRF）とは？
・IGRFモデルによる偏角の計算プログラムをCursorでSwiftへの変換
・生成されたコードの品質担保戦略
・OSSの公開とアプリ設計、Swiftらしいコードへのリファクタリング
・AIエージェント利用時の課題と解決策

AIエージェントの利用を考えている方へ具体的な事例を示し、Vibe codingの先にある、やりたいことをやり切る方法を具体的にお伝えします。