個人開発で育てる「大規模設計の苗床」 - AI時代の1人開発から始める業務への知識接続 / The Seedbed for Large-Scale Design - From AI-Era Solo Projects to Professional Knowledge

登壇者名：酒井文也
登壇したイベントタイトル：第10回FlutterGakkai
登壇したイベントのURL：https://fluttergakkai.connpass.com/event/394706/

Transcript

1. 個人開発で育てる「大規模設計の苗床」 株式会社ビットキー 酒井文也 2026/07/17 AI時代の1人開発から始める業務への知識接続
2. 2 酒井 文也 Sakai Fumiya @fumiyasac 2016.09 2019.03 2023.01 30歳の誕生日からiOSアプリ開発の勉強をスタート この時はまだWebエンジニアをしていました ソーシャルゲームやWebサービスの開発に従事 仕事→iOSアプリ開発の勉強 or 勉強会参加の毎日 数社でiOSアプリ開発を経験した後に独立 iOSアプリ開発を軸に据えて様々な開発現場を経験 2021年からはAndroidアプリ開発にも挑戦 国内最大級のハンドメイドマーケットアプリの開発に シニアエンジニアとして従事 iOS＆Androidアプリ開発を中心に幅広く新機能開発や 既存機能改善に携わっていました Now 2026年2月にビットキーに入社 homehub開発部 homehub Mobileに所属 現在は「homehub」のモバイルアプリ開発を担当 Flutter歴 = 社歴 自己紹介 ※長いのでモバイルアプリエンジニアになってからを抜粋して紹介します
3. つなげよう。 人は、もっと自由になれる。 Bitkey Recruiting Book © Bitkey inc All rights reserved. Mission・Vision
4. 現在、事業展開している２つのプロダクト 現在は「暮らし」「働く」という２つの事業領域において、 hubシリーズ（プロダクト群）をリリースし、 様々なステークホルダーに対して、プラットフォーム・プロダクト・サービスを展開しています。 フレキシブル オフィス オフィス テナント テンポラリーユー ス ビル(オーナー) ワーカー 不動産管理会社 マンション オーナー 管理組合 デベロッパー 居住者 暮らしサービス デリバリー会社 対象カスタマー/ユーザー
5. 「暮らし」 homehubは「暮らし」に関わる様々な体験を実現する。 その中心にあるのがスマートロック
6. 今日お話しすること 6 本セッションでは、個人開発のミニアプリを活用して大規模設計の知見を養い、業務へ接続するアプローチについてお話しします。 1. 大規模開発の壁と苗床アプローチ - なぜ個人開発が業務を加速するのか 2. 一気通貫の実験場を作る意義 - APIからWidgetまでを見通すサンプルの価値 3. Claude Codeとの協働とガードレール設計 - 自律型AIを破綻させない仕組みづくり 4. ドキュメント整備が生む開発生産性 - AIと人間の双方にとっての最適解 5. 業務への知識接続 - 個人開発から持ち帰る「設計の引き出し」
7. 7 大規模開発の壁と苗床アプローチ なぜ個人開発が業務を加速するのか
8. 大規模開発で直面する全体像の迷子 大規模開発の壁と苗床アプローチ 8 • 全体像の迷子が起きるメカニズム • 具体的に見えにくくなるもの 大規模化 担当範囲の限定 「あそこを触れば、ここに響く」が把握できない 見えにくくなるもの 例 API → 状態の影響経路 エンドポイント変更が、どの画面のどの状態に波及するか 状態 → UIの波及範囲 Provider依存と、状態変更による Widgetの再描画経路 層をまたぐ横断的関心事 エラーハンドリング・認証が各層にどう絡み合うか 個々の実装は理解できても、 層をまたいだ繋がりを俯瞰する機会 が業務では得にくい。
9. 苗床アプローチとは 大規模開発の壁と「苗床」アプローチ 9 • 苗床アプローチの核心 • なぜ苗床なのか 特性 業務（大規模開発） 個人開発（苗床） コントロール範囲 担当領域に限定 全体を自分で把握 試行錯誤のコスト 高い（影響範囲大） 低い（リスクゼロ） フィードバック速度 遅い（レビュー・QA等） 速い（即座に確認） ミニアプリという引き算された環境であれば、 設計の成功体験と失敗の痛みを最短で体験 できます。 1人で全体を100%コントロールできる最小サイズの環境で、大規模設計の因果関係をシミュレーションする 全体像の迷子を防ぐ理想形とは？
10. 10 一気通貫の実験場を作る意義 APIからWidgetまでを見通すサンプルの価値
11. 実験場としてのサンプルアプリ 一気通貫の実験場を作る意義 11 • 私が個人開発で取り組む Flutterアプリサンプル構成概要 要素 採用技術 プロジェクト管理 Melos モノレポ（mobile + backend を一体管理） API通信 GraphQL（Apollo Server 4.x）+ 手書きHTTP POST 状態管理 Riverpod 3.x + @riverpod + riverpod_generator UI構築 MVVM + Repository パターンによる3層構造 テスト / カタログ mockito + ProviderContainer / Widgetbook DB Prisma + MySQL 8.0（Docker Compose） 参考リポジトリ: https://github.com/fumiyasac/travel_booking
12. なぜ旅行予約アプリを苗床に選んだのか 一気通貫の実験場を作る意義 12 • 旅行予約アプリが苗床に適している理由 観点 苗床としての価値 CRUD操作の網羅 一覧閲覧・詳細表示・予約作成・キャンセルで基本操作を一通り体験 複数データの関連 TravelPlan・Booking・Review・ItineraryDay等、9つのDBモデル間のリレーション 業務に近い UI要件 フィルタリング・ページネーション・お気に入り（ SharedPreferences） API〜UIの一気通貫 GraphQL → DataSource → Repository → ViewModel → Widget の全層を自分で構築 業務アプリに通じる現実的な複雑さ を持ちながら、全体を1人で把握できるサイズ に収まる。 これが「苗床」の条件です 🌱
13. 一気通貫で作る3つの価値 個人開発でわざわざ「 API通信〜状態管理〜UI構築」をすべて含むサンプルを作る意義を、 3つの観点から整理します。 • 価値1: アーキテクチャの因果関係を体感する ◦ あそこを触れば、ここに響くを 100%コントロール可能な環境でシミュレーション できる ◦ @riverpod のDIチェーン（HttpClient → DataSource → Repository → ViewModel）がUIにどう直結するか を最短で試せる ◦ モデルのフィールド追加や copyWithの設計変更が、状態管理や UI描画にどう波及するかを実験できる • 価値2: 業務コードを読み解く理解の補助線になる ◦ 小規模で得た設計知見が、 業務の大規模コードを読む際のガイドライン になる ◦ 「このパターンは個人開発で試したアレだ」という 既知の構造に落とし込める • 価値3: 新しい技術やパターンを安全に試せる ◦ 業務では試しにくい新パッケージ・新アーキテクチャを リスクゼロで検証 できる ◦ 失敗しても誰にも迷惑がかからない。 失敗こそが最大の学び 一気通貫の実験場を作る意義 13
14. 設計の因果関係を掴む: データフローの全体像 一気通貫の実験場を作る意義 14 旅行プラン一覧表示を例に、 APIからWidgetまでの一気通貫のデータフローを示します。 • 旅行プラン一覧表示のデータフロー（ MVVM + Repository）
15. 設計の因果関係を掴む : ここを変えると”どこ”に響く？ 一気通貫の実験場を作る意義 15 全層を自分で作ったからこそ、 変更の波及を実験的に確かめる ことができます。 • 変更の波及を体感できる実験例 変更箇所 波及先 得られる知見 DataSourceのErrorHandling変更 ViewModel の状態遷移 例外設計が上位層の UX（Loading・Error表 示）を左右する TravelPlan ModelにField追加 fromJson → Repository → ViewModel → UI 1フィールドの追加で何ファイル修正が必要か を体感 Provider DIチェーンの組み替え Widgetの再描画範囲 依存の切り方で不要な再描画が発生する /し ないを確認 Record型での複数値返却 Repository → ViewModelの責務境界 戻り値設計が層間の責務分離 にどう効くか 業務コードで同様のパターンに出会った時、 これは苗床で試したやつだ と即座に理解できる。
16. 16 Claude Codeとの協働とガードレール設計 自律型AIを破綻させない仕組みづくり
17. AI活用の進化 : 伴走者から相棒へ Claude Codeとの協働とガードレール設計 17 • AI活用のフェーズ変遷 フェーズ 関係性 AIの役割 人間の役割 Phase 1 AIは「辞書」 質問に答える 質問する Phase 2 AIは「伴走者」 一緒に考える 方向を決める Phase 3（現在） AIは「相棒」 自律的に実装する 制御する（ガードレール） • なぜ”制御”が必要になったのか • 何も考えずに丸投げすると、コードベースを瞬時に複雑化 させる • 設計思想を無視したスパゲッティコード を生み出すリスク • 既存のアーキテクチャ規約を破壊する可能性 がある だからこそ「ガードレール設計」が不可欠 ターミナル上で自律的に動作する AIツールは極めて強力だが、それと同時にリスクを孕んでいる。
18. ガードレール設計の全体像 Claude Codeとの協働とガードレール設計 18 • 3層のガードレール構造 • 各層の役割 下の層ほど機械的に強制 でき、上の層ほど文脈を伝える 役割を担う。 層 具体的な仕組み 守るもの Layer1 Dart静的解析の厳格設定、 custom_lintルール コード品質の最低ライン Layer2 レイヤードアーキテクチャの制約定義 設計の一貫性 Layer3 CLAUDE.md等のルールファイル 設計思想・文脈の共有 Layer 1: 静的解析・Lint → analysis_options.yaml の厳格化・custom_lint Layer 2: アーキテクチャ制約 → Riverpodの使い方ルール・レイヤー設計の規約 Layer 3: ルールファイル（Custom Instructions） → リポジトリの設計思想・禁止事項・推奨パターン 大雑把でも構わないのでルールを最 初に設ける事で開発の礎にする。
19. Layer 1: 静的解析の厳格化 Claude Codeとの協働とガードレール設計 19 • analysis_options.yaml（実際の設定） • なぜ静的解析がAI制御に効くのか • Claude Codeが生成したコードに対して、コミット前に自動でチェック が走る • riverpod_lint が Riverpodの誤用（Provider内でのref.watch等）を検出 する • ルール違反があればAIが自動的に修正を試みる （セルフヒーリング） • cancel_subscriptions / close_sinks / unawaited_futures 等のリソースリーク検出系ルール で、AIが生成しがちなリソース管理ミスを防ぐ
20. Layer 2: アーキテクチャ制約の定義 Claude Codeとの協働とガードレール設計 20 • サンプルで定義しているルール例（ MVVM + Repositoryの3層構造） • AIに”なぜこのルールなのか ”を伝える重要性 • 単にルールを列挙するだけでは、AIは「ルール外のグレーゾーン」で逸脱する • なぜそのルールが必要かを文脈とともに伝える ことで、AIの判断精度が上がる • これは人間のチームメンバーに対するオンボーディングと本質的に同じ ルール 内容 守る理由 レイヤー依存の方向 Presentation → Data → Core の一方向のみ 循環依存の防止 ViewModel設計 @riverpod + Notifier、状態は copyWith で更新 状態管理の統一 Repository契約 抽象+実装をペアで定義 テスタビリティ確保 Provider DIチェーン HttpClient → DataSource → Repository → ViewModel の順 責務分離と差し替え容易性
21. Layer 3: ルールファイルの設計 Claude Codeとの協働とガードレール設計 21 • CLAUDE.md（約400行）の構成の中でいくつかをピックアップ • CLAUDE.mdを補完する2つのドキュメント • architecture_guidance.md（約500行）— Mermaid図付きのアーキテクチャ詳細 • skill_guidance.md（約400行）— 13個のカスタムスキルの活用ガイド セクション 記載内容 AIへの効果 プロジェクト概要 Melosモノレポの構成とディレクトリ配置 プロジェクト全体の把握 開発規約 Riverpod生成ルール・Repositoryパターン・命名規約 設計の一貫性を維持 既知の注意点 エンドポイントの罠・.g.dart再生成忘れ等 ハマりポイント回避 カスタムスキル一覧 13個のスキルの用途と実行方法 操作手順の型化 最も重要なガードレールが、 リポジトリの設計思想・禁止事項・推奨パターンを記述したルールファイル です。
22. ルールファイル設計で意識していること Claude Codeとの協働とガードレール設計 22 • 効果的なルールファイルの書き方 ポイント やること やらないと起きること 「なぜ」を必ず添える ルールの背景・理由を文脈とともに記述 AIが形式的に従い、意図を外す 具体例を含める 推奨パターン・アンチパターンのコード例 グレーゾーンでAIが迷走する ドキュメントを分離する 役割ごとにファイルを分け見通しを保つ 1ファイルが肥大化し更新が滞る 随時更新する 開発中に発見したルールを都度追記 古い情報でAIが誤った判断をする 「AIに対するルールファイル設計」は「新メンバーへのオンボーディング設計」と本質的に同じ。 この経験は、チーム開発でのコーディング規約の策定やドキュメント文化の推進にそのまま活きます。
23. ガードレールの応用: カスタムスキルでAIの操作を型化する Claude Codeとの協働とガードレール設計 23 • 定義しているカスタムスキルの一覧をピックアップ スキル名 用途 効果 `add-feature` 新機能の追加（DataSource〜ViewModel〜Screen一式） レイヤー構成の遵守を自動化 `add-viewmodel-test` ViewModelテストの自動生成 テストパターンの統一 `schema-update` GraphQLスキーマ変更時の一括対応 Backend〜Mobileの同期漏れ防止 `state-audit` Riverpod状態管理の整合性チェック Provider依存の循環検出 • なぜスキルが効くのか • ルールファイルが「何を守るべきか」を伝えるのに対し、スキルは「どう作業するか」 を伝える • AIに「機能を追加して」と言うだけで、レイヤー構成に従った一式が自動生成 される • 属人的な手順の暗黙知がスキルとして形式知化される
24. ガードレールの効果 — Before / After Claude Codeとの協働とガードレール設計 24 • Before → After の比較 観点 Before（ガードレールなし） After（ガードレールあり） 設計 Providerの中で直接API呼び出し レイヤー構造に従ったコードを一貫生成 抽象度 不要に複雑なクラス階層を作り出す プロジェクトの粒度に合った設計を提案 命名 ファイルごとに規則がバラバラ 規約に沿った命名を自動的に適用 既存コード あるユーティリティを再発明する 既存パターンを参照して再利用 整備前は「AIの出力を毎回疑い、手直しする」のが大半 → 整備後は「微調整するだけ」で済むことが増えた。 このガードレールを育てる → AIの精度が上がる というサイクルこそ、苗床で磨く価値のある経験です。
25. 25 ドキュメント整備が生む開発生産性 AIと人間の双方にとっての最適解
26. ドキュメント整備がAIの生産性を向上させる ドキュメント整備が生む開発生産性 26 • ドキュメント充実度と AI生産性の相関 • 人間にとって良いドキュメント ≒ AIにとっても良いドキュメント • 構造化された情報 : 人間もAIも、整理された情報から素早く必要な文脈を取得できる • 具体例の存在 : 抽象的な説明よりも、コード例がある方が両者とも理解しやすい • 「なぜ」の明示 : 判断に必要な背景情報が書かれていると、的外れな出力が減る
27. 業務でドキュメント整備を推進する強い動機付け ドキュメント整備が生む開発生産性 27 • AI時代の新しい動機付け 従来の価値 AI時代に追加された新しい価値 新メンバーのオンボーディング短縮 AIのオンボーディングも短縮される チーム内の知識共有 AIがチーム知識を活用して精度の高い出力を生む 属人化の防止 AIがもう一人のメンバーとして機能する • 従来のドキュメント整備を推進しにくい理由 • 書く時間がもったいない。その時間でコードを書きたい • すぐ陳腐化するから意味がない • 誰も読まないドキュメントを作っても仕方ない 📝ドキュメント整備 🧠AIがチーム即戦力に 個人開発でClaude Codeとの連携がスムーズだった設計パターン を元に、業務での新規機能開発やリファクタリングを提案可能。
28. 28 業務への知識接続 個人開発から持ち帰る設計の引き出し
29. 個人開発と業務をつなぐ知識接続サイクル 業務への知識接続 29 • 知識接続サイクルの全体像 • サイクルの具体例 ステップ 具体的な行動 課題発見 業務で状態管理の依存関係が複雑で見通しが悪いと感じる 実験 個人開発でRiverpodの依存関係パターンを複数試す 言語化 この構成だと依存が循環しやすい等の知見をドキュメント 還元 業務でのリファクタリング提案に活かす 業務で課題発見🔍 個人開発で実験🌱 知見を言語化📝 業務へ還元⚙
30. 苗床から業務へ接続する7つの技術軸 業務への知識接続 30 # 苗床で養う力 業務で活きる場面 1 MVVM + Repository 3層でレイヤー設計の因果関係を体感 業務のClean Architectureへの理解が加速する 2 Riverpod 3.x + @riverpod でNotifier移行を先行体験 StateNotifier → Notifier の移行設計を具体的に提案できる 3 ViewModelテストの基本パターンを体得 業務テスト拡充の即戦力になる 4 カスタムスキルで AI操作の型化を大量実験 業務リポジトリのスキル設計に実証済みパターンを展開 5 CLAUDE.md + architecture_guidance.md + skill_guidance.mdの3ファイル体制で文書駆動を実証 業務のドキュメント整備推進に AI生産性向上のファクトを提供 6 Prisma + MySQL でORM運用の基礎力を養成 大規模スキーマ（マイグレーション）の運用・変更影響予測に活か す 7 Melosモノレポでワークスペース管理の基礎を体得 大規模モノレポの構造理解が早まる 小規模で全体像を掴み、大規模で深さを追求する — この段階的な学習が「苗床」の本質
31. 業務への知識接続 31 業務で発見 → StateNotifier + Reader DI から Notifier + Constructor Injection への移行を検討 ↓ 苗床で実験 → travel_booking で @riverpod + Notifier + family + keepAlive を先行採用 ↓ 言語化 → 「DIチェーンが宣言的になり可読性が上がる」「手書きcopyWithの工数感」等の知見 ↓ 業務に還元 → packages/ 側の Notifier 移行を具体的な実装パターンで提案 業務で発見 → Claude Code の業務導入時に、大規模コードベースでの制御が課題 ↓ 苗床で実験 → CLAUDE.md + 13スキル + architecture_guidance.md の3ファイル体制を構築 ↓ 言語化 → 「3層ガードレールモデル」「context: fork による安全な分析」等のパターン ↓ 業務に還元 → Flutter側 5スキル・バックエンド側 3スキル + PR Review Action として展開済み 業務で発見 → 業務テストの拡充（~148テストファイル）が課題 ↓ 苗床で実験 → ViewModelテスト4種を ProviderContainer(overrides:) パターンで徹底的に型化 ↓ 言語化 → 「テストデータは現実的な日本語の値を使う」「エラークリアのテストが重要」 ↓ 業務に還元 → flutter-unit-test / flutter-widget-test スキルとして業務に導入済み Riverpod世代間移行 ガードレール設計の実証と横展開 テストパターンの応用
32. まとめ — 本セッションの要点 32 本セッションでお伝えした内容を振り返ります。 テーマ キーメッセージ 大規模開発の壁 領域の細分化で「全体像の迷子」になりがち 苗床アプローチ 個人開発のミニアプリで、大規模設計の因果関係をシミュレーション 一気通貫の価値 APIからWidgetまで全部作ることで「理解の補助線」を得る ガードレール設計 静的解析・アーキテクチャ制約・ルールファイルの 3層で構成 ドキュメントの威力 整備するとAIも人間も生産性を向上させる事ができる 技術スタック対比 苗床と業務は相似形。 7つの技術軸で知識が接続される 知識接続サイクル 業務で課題発見 → 苗床で実験 → 言語化 → 業務に還元 まとめ＆伝えたいメッセージ
33. 伝えたいメッセージ • 個人開発は「苗床」として、大規模設計の感覚を最速で養える ◦ 全体を100%コントロールできる環境で、設計の因果関係を体感する ◦ 業務では試しにくい実験を、リスクゼロで高速に回せる • AIは万能ではないが、正しく付き合えば最高の「相棒」になる ◦ ガードレール設計で AIを制御するスキルは、チーム開発のオンボーディング設計と本質的に同じ ◦ 小さな積み重ねが、業務での設計判断に自信を与えてくれる • 苗床で得た知見を、業務に接続し続ける ◦ 個人開発 → 言語化 → 業務還元のサイクルを回すことで、学びが「設計の引き出し」になる まとめ＆伝えたいメッセージ 33 ご清聴ありがとうございました！質疑応答・感想などお気軽にどうぞ！ 参考リポジトリ : https://github.com/fumiyasac/travel_booking
34. Copyright © Bitkey Inc. All rights reserved. 34 We Are Hiring ! 左の2次元コードから ご連絡ください！