僕たちが考えた 最強のAI駆動開発 〜Flutterへのリプレイスを添えて〜

山手ウエスト #1 「AI開発、最近どうですか？」@新宿での登壇内容

Transcript

1. 僕たちが考えた 最強のAI駆動開発 〜Flutterへのリプレイスを添えて〜 AI開発、最近どうですか？ | 奥田竜矢
2. 自己紹介 担当領域 モバイルアプリ開発 経歴 2023年入社 趣味 奥田竜矢 開発部アプリグループマネージャー 筋トレ、フェレット、ポケモンカード
3. 会社・プロダクト紹介 助太刀 23万+ 82職種 建設現場で働くすべての人を支えるプラットフォーム 登録事業者数(国内最大級) 建設業のほぼ全職種に対応 サービス展開 マッチング アプリ「助太刀」 正社員採用 助太刀社員
4. 前提:Flutter リプレイスプロジェクト 移行元 移行先 iOS ネイティブアプリ Swift / 既存実装 Android ネイティブアプリ Kotlin / 既存実装 クロスプラットフォーム ▶ Flutter に統合 1コードベース・大量の画面を移植
5. 本日のアジェンダ 01 僕たちが考えた最強のAI駆動開発とは? 02 AIナレッジベースを作ろう 〜AIが迷わない環境づくり〜 03 転用の連鎖 〜開発以外への染み出し〜 04 最後に
6. 僕たちが考えた 最強のAI駆動開発とは?
7. 最強のAI駆動開発とは── 仕事を しないこと!!! 大真面目です 人がやらなくていいことは、全部 AI にやらせる。それが当初の目標でした。
8. 思考の流れ 前提 仕事をしないこと ▶ つまり AI をうまく使うしかない ▶ でも ドキュメント必要じゃないか？ 「ナレッジベース、作ろう」 AI が迷わないための"教科書"を先に整備する。これが全ての起点でした。
9. AIナレッジベースを作ろう 〜AIが迷わない環境づくり〜
10. ナレッジベースを起点に Flutter ナレッジベース プロジェクト全体の技術方針・チームルール・アーキテクチャ概要設計論定・依存関係・横断ルール ｜ 用語集・ドメイン定義 01 開発手順 タスク開始から PRまでの手順書 02 コードルール CLAUDE.md・ アーキテクチャ規約 ↓ 03 テスト方針 フェーズ別テスト・ ガードレール設計
11. 作ったナレッジベースの中身 - "AI の教科書" Markdown ドキュメント 約 400 ファイル features(231) development(63) shared(64) 機能仕様:画面仕様・State・API 連携・画面遷 移・プラン別仕様 開発ガイド:ワークフロー・テスト戦略・トラッ キング・AI 運用ルール デザインシステム Piccolo・共通 Widget カタロ グ ios_diff(20) architecture(9) glossary ほか iOS ネイティブとの差分・エラーコード45種の 移植状況分類 4層アーキテクチャ・状態管理・画面遷移の設 計方針 用語集・ドメイン定義・技術的負債ポータル
12. ナレッジベースの内容 — 全体概要 ナレッジベース 全体設計・方針 技術選定・移行方針 Flutter 採用理由・iOS ネイティブからの移行戦略 フレームワーク選定・依存ライブラリ方針 プロジェクト全体の技術方針 チームルール・ドメイン定義 用語集・横断ルール 約 400 Markdown ドキュメントの起点 アーキテクチャ全体図 4層クリーンアーキテクチャ概要 Domain / Infrastructure / Application / Presentation チーム開発ルール ブランチ戦略・レビュープロセス・AI 運用ルール コミットルール・ワークフロー共通指針
13. 実装 - 4層アーキテクチャ × Phase 分割 Phase 1 Domain Phase 2 Infrastructure Phase 3 Application Phase 4 Presentation エンティティ・リポジトリ I/F(他層依存なし) DTO・Mapper・リポジトリ実装 UseCase・Notifier・DI 画面・NavigationEvent・AppNavigator AI と相性が良い理由 sk-wiki の層別実装ガイドを AI が参照 freezed / Riverpod の定型パターン Phase ごとに区切って実装・テスト 参考実装を ナレッジベース から取得
14. ナレッジベースの更新フロー — AIと人の分担 タスク発生 AIがナレッジベース参照・更新 開発タスクが起票される AIが自律的にナレッジベースを読み、実装後 に差分更新 ・Notion 起票 ・担当アサイン ・ブランチ作成 → ・sk-wiki 系スキルで自動追従 ・CLAUDE.md を参照して実装 ・差分をドキュメントに反映 AI を信頼する。ただし、検証は仕組みで行う。
15. 実践の成果 — “うまくいってる”の中身 リリース時のクリティカル不具合 0件 リリース時期 予定通り 移植した画面(page/screen 数) 152 画面 置き換え後のコード規模(ざっくり実測) Dart 合計 約 60万行 手書きコード 約 15万行 自動生成 約 26万行 テスト(19万行)が手書き実装(15万行)より多い ── AI に“書かせきった”証拠 テストコード 約 19万行
16. 後から知った:これ、名前がついてた 僕らが「ナレッジベース 作ろう」と呼んでいたもの、世界では── Context Engineering AI エージェントに「何を読ませるか」を設計する仕事。2026年、研究テーマから本番運用の関心事へ AGENTS.md llms.txt Codified Context エージェント向け設定ファイルのオープン規 約。6万超の OSS が採用 AI が読むためのサイト目次の規格。 Anthropic・Stripe・Cloudflare など600サイト 超が採用 規約の 研究 ≒ 僕らの CLAUDE.md ≒ 僕らの ナレッジベース の index ≒ CLAUDE.md オン マン 仕 2026 “憲法” + く 報告( デ ド ) ii + sk-w k で AI を 様書群 導
17. 転用の連鎖 〜開発以外への染み出し〜
18. ナレッジベース起点の転用連鎖 ナレッジベース PRD 生成へ転用 改善施策へ染み出し 🚀 起点 💡 気づき 🔥 連鎖 AIを活用したナレッジベース自動生成・更新の仕 組みが開発チーム内で定着 ナレッジベース生成のAIコンテキストを使って実 装PRDを自動生成する仕組みに応用 プロダクト改善施策の立案・検証までAIで一気通 貫する仕組みへ拡張 ナレッジベース、うまくいってる... 開発チームで運用定着 ✓ これ、他に転用できるかも! → PRD 作れる!! ✓ 染み出しの起点：工数削減だけでなく、やれることが広がった 改善施策もできる!!! → 全チームへ波及 ✓
19. 企画・仕様策定への染み出し 事例 01 ― 企画・仕様策定 実装前ドキュメントも、 AI と共作する BEFORE /sk-flutter-prd Flutter 実装 PRD を自動生成。レビューの叩き台を数分で用意 AFTER PdM のレビュー効率化のため、アプリの基本設計(PRD)を AI が再生成し てから人がレビューする /sk-wiki-spec 仕様追加・変更を ナレッジベース と整合を取りながら相談・反映 結果 Notion MCP タスク・PRD・開発ドキュメントを AI が直接参照・更新
20. 運用・レビューへの染み出し 事例 02 ― 運用・レビュー 「開発の AI 化」は 入口にすぎなかった 運用監視・コードレビューまで AI が担う体制へ。人は高度な判断に集 中 運用監視 × Datadog MCP 障害調査・ログ分析を AI が実施 監視設定・ダッシュボードの整備 コードレビュー × AI AI レビューガイドラインを整備 Devin Review と併用し観点を分担 結果 人は設計判断・仕様妥当性に集中 運用監視ログの設計(ログの意味論整理)も AI と実施 「開発の AI 化」は入口にすぎなかった
21. まとめ — 染み出しから見えたこと コンテキストを整備した領域から、 順に AI 化できる ライフサイクル全体が AI 化の対象になる ナレッジベース起点の転用連鎖 企画・デザインへの拡張 「開発の AI 化」は入口にすぎなかった ナレッジベースの AI 自動生成・更新の仕組みが定着。 そこからPRD 生成、改善施策立案へと連鎖的に染み出 した。 実装だけでなく、仕様策定・デザイン生成まで AI が叩 き台を担う。人は判断に集中できる体制へ。 コンテキストを整備した領域から順に AI 化が進む。ラ イフサイクル全体が対象になる。 開発 → PRD → 改善施策 仕様 → デザイン → 実装 → 運用
22. 最後に
23. 結果発表 STEP 1 AI で効率化 → 時間が生まれる STEP → 開発以外へ染み出す STEP なぜか、仕事が増えた!!! 効率化で空いた時間が、新しい仕事でどんどん埋まっていく AIが仕事を奪うのではなく、人間がやれることの上限が引き上がった → プロダクト改善まで巻き取 る STEP 4
24. 想定 vs 現実 💭 想定していたこと コード生成が速くなれば 全体が速くなる ルールは書けば守られる AI の出力はそのまま使える ⚡ 実際に起きたこと → ボトルネックは コンテキスト整備とレビューに移動した → 明文化 + 物理ブロック(hooks)+ テスト の三段構えが必要だった → Figma・API 仕様の必須確認を ルール化して誤適用に対処
25. 運用して分かったコスト コスト 01 プロンプト整備の初期コスト 効果的な指示文の設計・検証・改善には相応の時間と 試行錯誤が必要。最初のひと手間が最も重い。 コスト 02 そでも 一度整備すれば 全タスクに効く 出力確認・レビューの手間 AIの出力をそのまま使えるケースは多くない。 品質担保のための確認作業は引き続き人間が担う。 コスト 03 ツール・ナレッジの継続更新 AIの進化に合わせてワークフローも更新が必要。 「作って終わり」ではなく運用・改善サイクルが伴う。 投資対効果は高い コストは時的は続的。 のはで効いてくる。
26. 再定義 最強のAI駆動開発とは 環境・ルール・フィードバックループへの 継続的投資 AI の賢さに依存するのではなく、「どんな AI でも成果が出る構造」を作る 構成要素 01 コンテキスト 02 ルール ※なお、仕事は減っていない。やりたいことが増えた。 03 ワークフロー 04 ガードレール 05 → 全体 自己強化ループ ↩ 継続改善
27. 次の挑戦 — プロダクト改善に、本気で乗り出す NSM(最重要指標) ユーザー詳細閲覧 短期(〜2026/11) 中期(〜2027/2) AI 分析基盤のプレ運用 改善フローを完走させる ▶ GA4 計測の検証・分析の仕組み化 フロー完走 5施策 / 成果 1施策 「仕事、また増えるのでは?」 長期(2027/3〜) 恒常化と MAU の回復 ▶ 改善フローの恒常化・MAU を取り戻す ── 増える。でも、やりたい仕事だ。
28. AI計測から判定まで 改善施策の運用ループ AI が一気通貫。人間は判断に集中する。 Step 01 計測 GA4 + AI 分析基盤で指標を自動計測 Step 02 分析 → /propose で改善案カードを自動生成 Step 03 — 人間が判断 優先付け → 採用 / 却下を判断 → 施策 PRD 化 Step 04 改善 → /sk-flutter-prd → 実装 → /retro で判定 判定結果をもって、また OKR へ（AI が提案し、人間は選ぶだけ） ポイント 01 課題を素早く察知 ポイント 02 運用監視 × Datadog MCP で障害・ログを AI が即時分析。人は設計判断に集中 できる。 採用した施策カードは PRD 化 → 実装 → /retro の判定結果までボードで一元管理。 改善サイクルを短縮
29. まとめ AI 駆動開発の本質は 「AI が迷わない環境づくり」 Flutter リプレイスという大規模移植が 環境整備の投資を正当化してくれた 明日から始めるなら まず"AI のための ナレッジベース(教科書)"を作るところから
30. ご清聴ありがとうございました