SwiftPMとAIルールで実現するモジュール設計 バイトルiOSアプリのリアーキテクト 

宮川 昌高 ● 2024年12月にディップ株式会社に中途入社 ● SIer -> デジタル地図制作会社 ->オンライン イベント企画・開発会社を経て現職 ● 神奈川県茅ヶ崎市に住んでいます ディップ株式会社 ソリューション開発本部/プロダクト開発統括部 /バイトルエンジニアリング部/スマートフォン アプリ課 iOSエンジニア 趣味： サーフィン、格闘技観戦、キャンプ 

バイトルのリアーキテクトの概要 20年以上続くバイトルのシステム課題の解消・事業成長を加速さ せるための取り組みです。 ⚫ ドメイン駆動設計を根幹としたアーキテクチャの再設計 ⚫ AIを前提とした開発プロセス ⚫ 変革を推進するAIネイティブな体制 詳しくは弊社CTOの記事「20年超レガシー『バイトル』をAI駆動 で再設計！事業成長を実現するリアーキ戦略」を御覧ください！ 

バイトルiOSアプリ でのリアーキテクト の主な取り組み ⚫ SwiftUIへのリプレイス ⚫ デザインシステムの導入 ⚫ iOS/Android共通ロジックにKotlin Multiplatformの 採用 ⚫ Strict Concurrency Checking対応 ⚫ SwiftPMを利用したモジュール管理 

従来のマルチモジュール手法との比較 観点 従来: Xcodeターゲット (.xcodeproj) ※ SwiftPM モジュール定義形式 .pbxproj Swiftコード (Package.swift) コンフリクト Xcodeプロジェクトファイルの肥大化 →頻発しやす (XCodeGenでの回避) テキストベースのため起きにくい ライブラリ統合 Pods/Carthage/SwiftPM SwiftPMに統一 ※詳しくは「バイトルiOSアプリにおけるリアーキテクト 〜マルチモジュール化について〜」を参照 

モジュール構成 分割の基準 ⚫ 機能単位で分離（画面ごと、ドメインごと） ⚫ 外部依存の隔離（KMP, Firebase, 外部SDK） ⚫ 再利用性の確保（ UIComponents, DesignSystem） 

SwiftPM採用後の改善点 ⚫ Package.swift モジュール・依存関係をSwiftコードで宣言的に記述できるようになり、全体の 構成が把握しやすくなった。 ⚫ 循環参照の抑止 モジュール間の循環参照をコンパイラレベルで検出してくれる。 ⚫ Xcodeプロジェクトファイル(.pbxproj) プロジェクトファイルのコンフリクト問題からの解放。 ⚫ 外部ライブラリ パッケージ管理ツールをSwiftPMに統一できた。 

直面した課題と解決策 

[課題]SwiftUIのPreviewが動かない Kotlin Multiplatformや外部サービスに直 接依存している状態で、SwiftUI Preview が不安定・動かない問題に遭遇・・ エラーログを見ると、Firebase、Google Maps、Realm など数多くの外部パッケー ジのリンクに加え、KMP (XCFramework) への依存もあり、Preview がタイムアウト していました。 

[対策] SwiftUIのPreviewが動かない ⚫ Kotlin Multiplatformや外部サービス関連が依存する モジュールを限定的にする ⚫ SwiftUI/UIKitのViewを持つFeaturesモジュールから外 部サービスを持つモジュールには直接的に依存しない （protocol/mockのみを定義したInterfaceモジュール を中間に挟む） 

[対策] 依存解決 依存解決にはpointfree製の swift-dependencies を利用しています。 TestDependencyKeyでPreview/テスト用の軽量な値を、DependencyKeyで本番用の実装を定義します。 これにより、Preview/テスト時は重い依存（KMP他）のビルド・リンクをスキップできます。 実装モジュール インターフェースモジュール ※ 公式ドキュメントの「Separating- interface-and-implementation」の章を 参考にしています 

[課題] AIコーディング上の課題 バイトル開発において、アプリ実装部分をClaude Codeに任せることで効率化 を図ろうとしています。 実装負荷の軽減という意味で一定の効果を得ていましたが、一方で以下のよう な課題を抱えていました。 ⚫ 機能を実装する際、意図しないモジュールにコードが生成される ⚫ モジュールごとに定めた依存関係のルールを守ってくれない 手動修正・レビュー負荷の増大 

[対策1] rulesの導入 当初は ./CLAUDE.md に全ルールを記述していたため、コンテキストの肥大化 によりAIが処理可能な情報量を無駄に消費していたと考えています。 .claude/rules/ を活用することで、ファイルパスに関連するルールのみがコン テキストとしてメモリ上に読み込まれるように最適化を図りました。 ディレクトリ構成： Rulesの記述例 

[対策2] レイヤー概念の導入でルールをシンプルに 今後もモジュール数の増加による依存関係 の複雑化が予想されるため、「レイヤー」 という概念を導入しました。 ⚫ 責務ごとにモジュールをグルーピング ⚫ 同一レイヤー内のモジュールは同じ依存ルー ルに従う 例 Features Layer: CoreInterface / Foundation のみ依存可（Core直接依存は 禁止） Foundation Layer: 上位レイヤーへの依存禁止（循環依存防止） 

効果 ⚫ 適切なモジュールへの実装 「どのモジュールに」「どの依存関係で」実装すべきかをAIが自動で判断 できるようになってきました。 ⚫ 禁止パターンの抑止 ルール違反のコードを生成しにくくなったことで、アーキテクチャ観点での レビュー負荷の軽減につながってきていることを実感しています。 ⚫ 設計ドキュメントとして機能 ルールファイル自体が設計ドキュメントとして、新規参画者への導入資料や技術面での 意思決定のログとして、機能していくことを期待しています。 

まとめ ⚫ SwiftPMでのモジュール分割 pbxprojのコンフリクト解消、依存関係をコードで宣言的に管理 ⚫ Interface分離 依存ルールをシンプルに保ちつつ、重い依存を隔離 ⚫ Claude Codeルール コンテキストの最適化とレイヤーの概念を導入し、モジュール依存関係のルールを シンプルに 

ご清聴ありがとうございました!!