聴講メモ：五反田.mobile ~モバイルアプリ × AI~

企画されている方から前々から聞いていてずっと楽しみにしていた、五反田のモバイル勉強会第1回。しかもテーマがモバイルアプリ開発におけるAI導入で、まさに今あれこれと試行錯誤しているので、個人的にはとても嬉しいタイミングだった。

イベントページ：https://gotanda-mobile.connpass.com/event/369003/

AI導入はどこも手探りだと思うが、自社内しか見えていないと、今の進め方がきちんと的を射ているのかも分からないし、他社と比較して進んではいなくともどの程度劣後しているかも把握しづらい。他社の率直な導入状況を、LTに加えて懇親会でも知ることができ、たいへんありがたい場だった。

Claude Code の Sub agents 機能、Firebase Crashlytics を MCP で接続できることなど、明日から早速導入してみたい知見もあった。Devin の使い所／使い分けの勘所は聞く人により意見に大きく開きがあったのが意外だった。実験段階でまだまだデファクトが定まっていない状態なので、トライ&エラーのしがいがあるし、こうした知見の需要もまだまだ高いと感じた。

あと、懇親会中にもLTタイムがあったのも新しくて良かった。

Copilot code reviewを試してみた

牟田拓広 さん

  • Copilot Code Review 使えるかを設定で確認 → Reviewers に Copilot 追加
  • 日本語でレビューさせたい
    • プロンプト copilot-instructions.md に指定
    • defualt ブランチにマージされて適用
  • PRできたタイミングで自動レビューさせる：Rulesetsで設定
  • 効果検証これからだが、SwiftLint カスタムルール運用をこっちに寄せられるかも

データと見るLuupでのAI活用

瀧川陽介 さん

  • 開発現場にAI導入で何が変わりそう？アウトプット量？
    • PRマージ数集計：Devin + Claude Code で 140%
      • 毎週コンスタントにマージできている
      • Claude 導入でさらに加速した
  • Devin / Claude 使い分け
    • Devin：現場調査系、不具合の初期調査や仕様の調査、設計、軽い実装
      • 複雑なタスクはコミュニケーションコストがかかる
  • どのプロセスが良くなった？
    • リードタイム／サイクルタイム：43%
    • Claude code のレビュー活用
  • MCP の導入
    • xcodebuildmcp など：かなり精度向上に貢献
  • ほか
    • Velocity 計測はしているが、生産性指標にはしていない
    • 不具合発生数は変化なし：QA工程で吸収できているのかも
  • 声
    • 重いタスクで手いっぱいだったが、重いタスクの裏で、2、3タスクこなせる
    • 地図を図形描画など小難しい実装が容易にできて脳のリソースの割き方
  • 今後
    • Notion / Figma / GitHub MCP 活用
    • チーム全体での標準化、Claude のサブエージェント活用
    • 開発フローの見直し、AI 前提で非連続的改善
  • Q&A
    • Devin に合わないタスクとは？
      • ゴールが決まっていて簡潔な指示でPR作成できる1ステップ系は得意
      • それ以外が向いていない、コミュニケーションしながら修正組立する系
        • 言葉で説明が必要なUI実装
      • Claude は画像も提供できるので、Figma のスクショつけたりしてできる
        • Figma MCPと疎通しても良さそう
    • BE/Web/Mobile で性能の違いは？
      • コードベースの設計によって精度が変わってくる
      • 共通して、AIがわかりやすいようモジュール化、コンポーネント設計が必要（人にとってもAIにとっても）
    • 人間のレビュワーとしての負荷の問題は？
      • AIのレビューが効いているので軽減できている
      • 一部のチームはレビューまでのリードタイムが長くなる傾向がある、チーム状況に応じた改善が必要
    • xcodebuildmcp による精度向上とは？
      • Claude 側がビルドまでやってくれるので、ビルド通る状態まで持っていける
      • 質問者：テスト回すのも Claude に任せるが、ロジック修正まで手をつける悩みあり

Crashlyticsの修正、AIにまかせて早く帰ろう。

大桃良太 さん

  • MCP で Firebase と Claude を接続
  • Firestore のデータ操作、Remote Config の操作も自然言語で行える
  • Claude Code と Firebase MCP のセットアップ方法
    • クラッシュ情報のデータ取得、スタックトレースやビルド情報なども
    • 期間、OS、バージョンなどをクラッシュごとにグルーピング
    • メモも追加可能
  • Claude Code に不具合修正を依頼
    • 不具合を認識させて修正案を考えてもらう
    • クラッシュ要因を影響度、優先度にランク付け
    • 実際
      • 原因分析：5案出し
      • 原因ごとに信頼度を推定
      • 修正案を検討
      • 修正案に至るまでのトライ&エラーはあり

Claude Code Subagents でAIもチーム開発の時代へ

道免陽平 さん

  • Subagents とは？
    • 特定タスクや役割に特化した専門的なアシスタント
    • メインの会話とは異なるコンテクスト
    • 単一の万能AI→複数の専門AIチームへ
  • なぜ？
    • チーム開発、関心の分離：ひとりだと一杯一杯でパフォーマンス低下
    • メリット
      • コンテキストを保持して、メインの会話を汚染しない
      • 専門性の向上
      • 再利用性が向上し、別プロジェクトに転用可能
      • 柔軟な権限により、タスクに応じて権限調整できる
  • 使ってみた
    • メインエージェント → UI担当、ロジック担当、調査担当、コミット担当
    • 独自のデザインシステムによるカラー定義にも追従してくれた
  • Q&A
    • Subagents の分け方（粒度）
      • 細かく検討はできていないが、アプリ内の機能ごとに分けてもいいかも
    • Firebase MCP で取得できる情報
      • Firebase Dashboard で取れる情報は取れるのではないか説

Devin で iOS の PR から Android のコードを生成する

@yanzm さん

  • Devin で iOS/Android 片方の実装からもう一方の実装をさせる
  • やってみる
    • モデルを追加するだけのPR
      • Android はガワのモジュールだけ作った
        • iOS 実装側のデイレクトリ命名をもとに models を探しに行った
        • build.gradle からネームスペースを読みに行き、モジュール配下にパッケージを作成、出来た
        • デフォルトブランチ以外からPRを作ってくれるか？
          • デフォルトブランチのまま調査し、PR作る直前で作業ブランチをチェックアウトしてしまった：指示が必要 → 毎度指示面倒なので Knowledge に追加
        • 先にダミーの .kt がある場合の検証
          • 既存のモデルファイルを発見し、そこと同じところに配置してくれた
        • API 実装
        • 指示なくとも既存実装に習って要件満たしてできた
        • UI実装
          • sealed interface 使って UiState 実装してくれた、UiState による表示の仕分けも
          • Android 開発のベストプラクティスに沿って、StateFlow や MutableStateFlow 使って実装してくれた
          • 命名がiOSっぽい（e.g. onAppear）
          • Screen/Content を分離する iOS の設計を踏襲してくれた
          • Scaffold は使ってくれなかった
            • 明示するか、既存実装が Scaffold 使っていれば追従したかも
  • ワンバンクで複雑な PR でやってみた
    • +512行、16ファイルの変更
    • UI 実そが画像の追加で難儀したがそれ以外はちゃんと実装してくれた
      • 画像はまったく違うものを持ってきた
      • それ以外は出来すぎてめっちゃ怖い
      • 既存ににている実装や参考実装がたくさんあるのが効いた？
      • design-system の Composable も使ってくれる
  • まとめ
    • 焦点を絞った PR はかなり角度高い、大きい PR も80点いける
    • 対お関係が既存のコードベースからわかりにくいと、対象実装を探せずに確度下がる
      • 対応しているのが理想だが、難しければ対応関係の知識を渡せばOK
    • コードベースは移管性のある構成にしよう
  • Q&A
    • 逆に Android → iOS でうまくいかな場面は？
      • Android → iOS 作らせる時に、design system の Composable を使ってくれないことはあった
    • UI層について、iOSのデザインをそのままを持ってきていたが、フレームワーク特化の表現やカスタムUIの性能は？
      • あまり試せてないが、縦横の要素の並べ方は意図した通りに作られるが、ドラッグ処理、スクロール処理、アニメーションは意図した通りにならない可能せはある
      • 最初から100点を作らせるよりも、Devin に調査代わりにどの画面にどう作ったら良いか？を教えてもらう形でお願い→参考に、自分で手で書くことが多い

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です