Share
Embed
Slide 1
Slide 1 text
~AI × Mobile開発編~
#Fukuoka_33tech vol.4
Sansan 技術本部
ミヤモト グスタボ ルイス, 原⽥ 拓眞, 平⼭ 智⼰
Slide 2
Slide 2 text
Sansan株式会社について
Slide 3
Slide 3 text
Sansan株式会社の働き⽅を変えるAXサービス
⽣産性を向上させ、企業のAI活⽤を最⼤化するデータベースとしても貢献できる
「働き⽅を変えるAXサービス」を提供します。
データクオリティマネジメント
請求
名刺
管理
営業 契約
名刺管理から、収益を最⼤化する AI契約データベースが、利益を守る 「なくせる」をつくり、全社の働き⽅を変える
名刺アプリ
経理AXサービス
取引管理サービス
ビジネスデータベース
各サービスの活⽤で変わる働き⽅
情報を分析・活⽤しやすく
データに基づいた判断ができる
情報の管理がしやすく
すぐに共有できる
必要な情報を
すぐに⾒つけられる
個⼈向け
法⼈向け
Slide 4
Slide 4 text
Sansan株式会社
「Sansan」に込めた想い
“San”（〜さん）は、英語の“Mr.”や“Ms.”にあたる
「⼈」を象徴する⾔葉です。
Sansanは、⼈と⼈、そして出会いを表します。
“世界を変える出会い”を⽣み出したい。
⾚いラインには、そんな想いがこめられています。
Sansan
Bill One
Contract One
Sansan Data Intelligence
Eight
主な提供サービス
2007年6⽉11⽇
73億50百万円（2026年2⽉28⽇時点）
Sansan神⼭ラボ
Sansan Innovation Lab
Sansan⻑岡ラボ
Sansan Global Pte. Ltd. （シンガポール）
Sansan Global Development Center, Inc. （フィリピン）
Sansan Global (Thailand) Co., Ltd.（タイ）
ナインアウト株式会社
株式会社⾔語理解研究所
設⽴
資本⾦
本社
関⻄⽀店
福岡⽀店
中部⽀店
拠点
サテライト
オフィス
グループ会社
東京証券取引所 プライム市場
上場証券取引所
働き⽅を変えるAXサービスの企画・開発・販売
事業
寺⽥親弘
代表者
Slide 5
Slide 5 text
技術本部
各事業部・プロダクトユニットと連携するEngineering Unitと、サービスの根幹技術を担う組織が存在。
Digitization部 Sansan Engineering Unit
研究開発部（R&D）
Bill One AR プロダクト開発部 Bill One Service Platform
プロダクト開発部
Bill One 開発戦略部
Platform Engineering Unit
Contract One Engineering Unit Data Intelligence Engineering Unit
Bill One EX プロダクト開発部
Eight Engineering Unit Bill One AP プロダクト開発部
VPoE室 コーポレートシステム部 情報セキュリティ部
海外開発拠点⽀援室 Quality Assurance Engineering Unit CTO室
技術本部
Slide 6
Slide 6 text
拠点
Sansan⻑岡ラボ
Sansan神⼭ラボ
関⻄⽀店
中部⽀店
Sansan Innovation Lab 海外拠点（グループ会社）
・シンガポール
Sansan Global Pte. Ltd.
・フィリピン
Sansan Global Development Center, Inc.
・タイ
Sansan Global (Thailand) Co., Ltd.
福岡⽀店
本社
Slide 7
Slide 7 text
福岡オフィス
〒810-0801 福岡県福岡市博多区中洲3-7-24 WeWork ゲイツ福岡 11F
Slide 8
Slide 8 text
技術本部 Sansan Engineering Unit
Gustavo Miyamoto
Slide 9
Slide 9 text
AIで変わったのは、
コードじゃなくて
"開発のあり⽅"だった
#Fukuoka_33tech vol.4 ~AI × Mobile開発編~
Sansan株式会社 Gustavo Miyamoto
Slide 10
Slide 10 text
ミヤモト グスタボ ルイス
Sansan株式会社
技術本部 Sansan EU Mobile Applicationグループ
開発歴 18年（うちモバイル 13年）
ブラジルで開発スタート → Android → iOS/Android エンジニア
→ TL → EM（兼QA）
2026年2⽉ Sansan⼊社（⼊社2カ⽉）
iOSアプリ開発・Swift Concurrency移⾏（実装担当）・SKYNET
プロジェクト参加
そんな⾃分が「⼊社2カ⽉の新参者」になったとき、AIは何を変
えたか
̶̶それが今⽇の話です。
Slide 11
Slide 11 text
⼊ったら、プロジェクトが進⾏中だった
- プロジェクト概要
> RxSwift → async/await 移⾏
> Strict Concurrency Checking対応
> VIPERアーキテクチャ全5層・100画⾯超
̶̶その中で、AIの使い⽅が根本から変わっていた
✓
Phase 1
API層
✓
Phase 2
UseCase層
✓
Phase 3
Interactor層
Phase 4
Presenter層
Phase 5
Cleanup
⾃分が⼊ったのはここから
Slide 12
Slide 12 text
なぜ途中参⼊でも、詰まらなかったのか
「理解してから動く」ではなく「動きながら理解する」が機能するようになった
以前の使い⽅
- ドキュメントが整っておらず、AIに渡せる
⽂脈が薄い
- 結果として浅い回答ばかり
- 出⼒を検証する余裕もなく、「適切に使え
ている」という実感がないまま
- チームでAIの知⾒が積み上がらない
- 個⼈の試⾏錯誤のまま終わる
⼊社して変わったこと
- タスクが普通に並列で進む
- コードベースを全部知らなくていい
- AIとドキュメントで
都度、⽂脈を構築して進める
- ドキュメント(運⽤・アーキテクチャ・ADR)
がそのままAIへのInput。
⼊⼒が最⼩限で済む
Slide 13
Slide 13 text
解決したい課題
- ⽣成AI活⽤が「個⼈の⼯
夫」にとどまってしまい、
チームとして再現できる成
果が積み上がらない
- AI導⼊の効果が属⼈的で、
何ができて何ができない
か・どれだけ価値が出たか
を説明しづらい
- 品質（動作確認・根拠の提
⽰）まで含めた「完了」を
安定して出しにくい
社内で熱量⾼く⽴ち上がったAI開発⾃動化プロジェクト、SKYNET̶̶そこに⾃分も加わった
チームはすでに、本気で動いていた
プロジェクト概要
- AIを"開発チームの⼀員"と
して運⽤。要件を渡すと実
装〜レビュー対応までを⾃
律的に進める仕組みをつく
る
- 構築軸：フロー・スキル・
ナレッジ・計測
- まず実装⽅針が⽐較的明確
なTech案件から。再現性
を重視して適⽤範囲をコン
トロール
⽬標
- 要件定義書を渡すだけで、
AIが実装→テスト→PR作
成→レビュー対応までを短
期間で完遂。⼈は意思決定
と最終レビューに集中
- 特定の⼈・案件に依存せず、
複数案件で再現可能な進め
⽅
- 成果の根拠がナレッジ・メ
トリクスで整理され、チー
ム外にも展開可能
Slide 14
Slide 14 text
要件定義書を渡すと、AIがこのフローを⾃律的に回す
コードは書ける。次の壁は"動く証拠"だ
現在地
フローは⼀度通った（計画→実装）
最⼤のボトルネックは品質保証（動作確認）
再現性（複数案件への流⽤）・ナレッジ化もこれから
ボトルネックへのアプローチ
Mobile MCPを導⼊、AIがシミュレータを⾃動操作し、
動作をスクリーンショットで証跡として残す
⼈は最終確認に集中。現在、精度向上に向けてチームで
試⾏錯誤中
⽬指すのは、コードを書くAIツールではなく、
チームで評価できるAIエンジニアをつくること
計画策定 コード実装
ユニット
テスト・ビルド
確認
セルフレビュー PRレビュー依頼
動作検証・
証跡撮影
Slide 15
Slide 15 text
2カ⽉で気づいたこと
- AIを「うまく使えていない」原因は、個⼈ではなく環境にある
> ⽂脈・余裕・チームの仕組み
̶̶この3つが揃って初めて、AIは本来の⼒を発揮する
- 新参者の「わからない」が、AIとの対話を具体的にした
> 曖昧な前提を持たないからこそ、⽂脈をゼロから整理してAIに渡せる
̶̶「知らない」は弱点ではなく、問いを精緻にする起点だった
- 環境設計がAIの効果を決める
> ドキュメント・アーキテクチャ・チーム⽂化
̶̶これらがAI活⽤の基盤。ツールより先に整えるべきもの
AIをうまく使えるかどうかは、ツールより先に、チームと環境の設計に
かかっている̶̶それが2カ⽉で最も腑に落ちたことです。
Slide 16
Slide 16 text
AIで変わるのは、
ツールじゃなく
"開発のあり⽅"。
あなたのチームの開発のあり⽅は、
変わっていますか？
気になった⽅、ぜひ話しかけてください。
Slide 17
Slide 17 text
技術本部 Bill One EXプロダクト開発部
原⽥ 拓眞
Slide 18
Slide 18 text
Cursor Automationsを利⽤して、
運⽤を効率化しよう。
#Fukuoka_33tech vol.4 ~AI × Mobile開発編~
Sansan株式会社 原⽥拓眞
Slide 19
Slide 19 text
写真が入ります
原⽥拓眞
Sansan株式会社 技術本部
Bill One EX プロダクト開発部
- 2014年4⽉新卒⼊社（12年⽬！）
- ⼊社当初はSansanのWebアプリエンジニア（C#）
- Androidエンジニア・アーキテクトを経て、
現在Flutterエンジニア
- 福岡採⽤強化のため、
エンジニア採⽤やイベント企画も⾏う
- 家族は福岡出⾝の同居⼈1⼈と同居⽝1匹
- 2025年4⽉から福岡へ移住。
Slide 20
Slide 20 text
Cursor Automationsとは？
Slide 21
Slide 21 text
Cursor Automations
今年3⽉から提供された、
⾃動実⾏エージェント。
トリガーを設定すると、
そのトリガーに応じてエージェントが
起動し、あらかじめ設定した
プロンプトを実⾏する。
Slide 22
Slide 22 text
起動トリガーの設定
- 毎時 / ⽇ / 週 / cron 定義
- GitHub / GitLab イベントから起動
- PR作成とか、commit追加、pushなど
- Slack イベントから起動
- 新しいメッセージの投稿、チャンネル作成
- Sentry イベントから起動
- Issueの状態変化
- Linear イベントから起動
- Issueの状態変化、cycleの終了
- PagerDuty イベントから起動
- インシデントの状態変化
- Webhook イベントから起動
- 上記サービス以外もあらゆるWebhookから起動できる
Cursor Automationsで設定できること（起動⽅法）
Slide 23
Slide 23 text
- 起動時に指定したGitリポジトリのブランチでチェックアウトされる
- 任意のプロンプトを書くことができる
- ⽂字数上限は不明ながら、結構⻑⽂のプロンプトを⼊れることができた
- 5,400⽂字くらい
- ⽇本語OK
- 選べるモデルは限られている
- いつものチャットで選べるものはほぼ使える
- Codex 5.3 (High / Extra High)
- GPT -5.4 (High / Extra High)
- Opus 4.6 High
- Sonnet 4.6 High
- Haiku 4.5
- Composer 2
Cursor Automationsでできること（プロンプト）
Slide 24
Slide 24 text
- MCPサーバと連携して、性能を拡張できる
- Slack
- GitHub
- 任意のMCPサーバー
- メモリ機能
- 同じAutomationsで、実⾏を跨いでメモの永続化が可能
- 記憶を蓄積して、実⾏回数とともに改善を⾏うエージェントが作れる
- 誤解や悪意のある⼊⼒に影響されたメモリが作成されることもあるので、
⼊⼒情報の信頼性に注意（チャットボットとかには向かない）
Cursor Automationsでできること（MCP）
Slide 25
Slide 25 text
Bill OneのCursor Automations活⽤事例
Slide 26
Slide 26 text
⾃動PRレビュー
Slide 27
Slide 27 text
Bill One EXモバイルチームでのこれまでのレビューの歴史（ざっくり）
⼈間だけのレビュー（最初期だけ）
GitHub Copilot
⼀般的な指摘はしてくれるけど、プロダクトのコンテキストが含まれないので的はずれなことも多い
Code Rabbit（追加）
最近ちょっと賢くなったけど、⽢かったり融通が効かないところはある
Cursor Automations（現在これだけ）
開発はCursorメインでやっているので、今までの開発資産を⼀番⽣かせる
Slide 28
Slide 28 text
Cursor Automationsによる⾃動PRレビュー
- PR作成・Pushなどをトリガーに設定
- 以下の観点を下にレビュー指摘するように
プロンプトで指⽰
- PRのdiff / descriptionやリンクされた
Issueから変更意図・背景理解
- リスク分析（認証認可 / 永続化 / APIへ
の⼊⼒値 / ロジックミスなど）
- データ不整合やrace condition, 無限ル
ープ、リーク、ぬるぽ、境界値検査な
どの有無を調査
- リスクや問題規模に応じて、Critical /
High / Medium / Low に分類して指摘
Slide 29
Slide 29 text
- ⼈間が指摘しなくてもいいようなレビューの⾃動化
- typo
- プロパティの不⾜
- コメントの不⾜・⽭盾
- ⼈間が⾒落とすようなレビューの充実
- ⾮同期処理によるrace conditionの発⽣の可能性
- 脆弱性やセキュリティ上の懸念
コスト
- 1レビューにつき $0.2 くらい
- 使⽤モデル : Codex 5.3 High
- 差分だけ読み取るようにしてコスト削減している
成果とコスト
Slide 30
Slide 30 text
⾃動クラッシュチェック
Slide 31
Slide 31 text
Cursor Automationsで⾃動クラッシュチェック
- SentryのIssueイベントでトリガー
- 以下の観点でSentryのIssueを調査・報告するよ
うにプロンプトで指⽰
- 影響を受けたユーザーの体験
- 影響ユーザー数、発⽣規模、拡⼤の傾向
- 原因の分析
- 完全性・機密性観点での評価
- 過去の類似事象の調査（Slack）/ 緊急度
の更新必要の有無
- 該当するIssueのSlackポストに返信する形で報
告させる
Slide 32
Slide 32 text
- ⽇次運⽤チェックの圧倒的短縮
- ⼈⼒でやると1Issueにつき15 - 30分程度掛かるような問題もCursorの
調査内容を確認することで済むようになったので数分レベルで処理できるよ
うになった
- 正確性については今のところ問題ない
- Gitリポジトリ上にアプリの設計に関するドキュメントや多様なSKILLが配置さ
れているのでそれがうまく利⽤されている
コスト
- 1Issue調査あたり $1 前後
- 使⽤モデル :Sonnet 4.6 High
- SentryMCPを使っているのでコンテキスト消費が多いかも。コスト改善の余地あり
⾃動クラッシュチェックで得られた成果とコスト
Slide 33
Slide 33 text
注意点など
Slide 34
Slide 34 text
設定した管理権限に応じて扱われる認証情報と課⾦される対象が変わる
- Team Owned
- Automationsを編集できるのはチーム管理者のみ（メンバーは閲覧のみ）
- チーム共有のサービスアカウントで実⾏される
- Team Visible
- Automationsを編集できるのは作成者のみ（メンバーは閲覧のみ）
- 管理者は無効化ができる
- 作成者のアカウント情報で実⾏され、作成者のアカウントで使⽤した扱いになる
- Private
- Automationsを編集・閲覧できるのは作成者のみ
- 管理者は無効化ができる
- 作成者のアカウント情報で実⾏され、作成者のアカウントで使⽤した扱いになる
管理権限を変更した時（特にOwnedとそれ以外）MCPの認証情報なども
再発⾏し直す必要がある
Slide 35
Slide 35 text
Cursor Automationsを使って
さらに⽣産性を上げよう
Slide 36
Slide 36 text
技術本部 Bill One EXプロダクト開発部
平⼭ 智⼰
Slide 37
Slide 37 text
iOSエンジニア、Flutterに転⽣する
- AI と駆け抜けた半年間
#Fukuoka_33tech vol.4 ~AI × Mobile開発編~
Sansan株式会社 Tomoki Hirayama
Slide 38
Slide 38 text
写真が入ります
平⼭ 智⼰
Sansan株式会社 技術本部
Bill One EX プロダクト開発部 兼
情報セキュリティ部
iOSエンジニア歴 10年 (2016〜)
⾼専在学中 (4年) + ⼤学時代 (2年) + Sansan (4年)
その他、セキュリティーとクラウド、ゲーム開発知識
2022年 Sansan 新卒⼊社
Sansan iOS アプリ開発 (2022-2024)
SansanにKMP導⼊ (2024年冬)
Bill Oneアプリ開発でFlutterを導⼊ (2025年夏)
Slide 39
Slide 39 text
今⽇のテーマ
これまで導⼊実績のなかったFlutterを利⽤し、
約半年でアプリをリリースするまでに効果があったAI活⽤
Slide 40
Slide 40 text
No content
Slide 41
Slide 41 text
第１節
Bill One アプリ開発プロジェクト
Flutter 採択
Slide 42
Slide 42 text
〜 2025年夏頃 〜
- Bill Oneのモバイルアプリを作りたい
- 期間は半年間で iOS / Android 両⽅で出したい
- 初期はエンジニア3⼈でチーム発⾜
Bill Oneアプリ開発プロジェクト
iOS
エンジニア
(⾃分)
Android
エンジニア
(アーキテクト)
Android
エンジニア
(Flutter 経験者)
Android
エンジニア
後に参⼊
Slide 43
Slide 43 text
〜 技術選定 〜
- ネイティブ / KMP / React Native / Flutter を⽐較検討
- ADR をベースに議論し、チームとして Flutter を選択
- 技術本部での設計レビューを通し正式に採択
Flutterの採択
icons by icons8.com
Slide 44
Slide 44 text
第２節
Flutter のキャッチアップ
Slide 45
Slide 45 text
Flutter のキャッチアップ
〜 Flutter導⼊決定当初のHirayama〜
Flutter 未経験による不安
- わからないことが多すぎる (Dart, Flutter, ライブラリ, 環境)
- ⼤規模アプリ開発への適合性への疑念
- 失敗させたくないプロジェクトで未採⽤技術を採⽤することへの
不安
iOS歴が⻑いゆえの不安
- Swiftの型安全・スレッド安全なプログラミングとの⽐較
- ネイティブのデザインシステムから離れること
Slide 46
Slide 46 text
AI活⽤ ①
短期間でFlutterを学ぶ
Slide 47
Slide 47 text
短期間でのFlutter学習
AIに教材を作成させた
- 公式Docs、⼀般的なライブラリDocs
- 追加で学びたいことも追記更新
対象者のスキルセット・レベルを考慮させる
- Swift / Kotlin との⽐較コードを出す
- ネイティブからの差分をメインに学習する
Flutter経験メンバーを含めて学習する
- 業務として時間を確保
- 経験者が補⾜し、正確な理解をする
Slide 48
Slide 48 text
必要⼗分な情報を短期間で学べた
- ネット上には⼭ほどの教材があるが、必要な知識のみに絞った最適化を
⾏った
- 1週間程度で AI を併⽤して画⾯作成とその理解ができるようになった
不安から⾃信に変わった
- 不⾜している知識を効率よく補うことで、時間をかけずに短期間で⼿を
動かせるようになった
AIを活⽤した効果
Slide 49
Slide 49 text
No content
Slide 50
Slide 50 text
第３節
AI ネイティブ開発 スタート
Slide 51
Slide 51 text
BOチームのAIネイティブ開発
Cursorを前提とした開発環境
- 拡張機能や設定をプロジェクトとして共有
- モデルレベルで skill, command, sub-agentを最適化
AIが開発しやすい環境を⼈間が作る
- AIはマネをすることが得意
- AIに考えさせるとハルシネーションの可能性がある
- ⾏動はあらかじめ規定し、どの⾏動をとるかを考えさせる
Slide 52
Slide 52 text
AI活⽤ ②
画⾯を爆速で開発する
Slide 53
Slide 53 text
デザインシステムの整備と活⽤
Figmaとコードを1:1で対応させる
- 画⾯デザインの全てはデザインシステ
ムのコンポーネントで構成される
- 対応するFlutter Widgetを作成する
Figma MCP / Code Connect を使う
- Code Connectを設定するとFigma
MCPを利⽤したときに対応するコンポ
ーネントをより正確に利⽤する
Slide 54
Slide 54 text
No content
Slide 55
Slide 55 text
No content
Slide 56
Slide 56 text
1プロンプトで1画⾯が短時間で⾼精度に実装される
- FigmaのFrameへのリンクを渡すだけでデザインシステムのコンポーネン
トを利⽤し実装されるため、画⾯実装コストが⼤幅に削減された
全画⾯で共通のUIコンポーネントが利⽤される
- ⼈間が画⾯を実装する必要がなくなるように整備していく⼒学が働くの
で、UIの共通化が積極的に⾏われるようになった
- 共通化の判断は⼈間が⾏って統制はとる
AIを活⽤した効果
Slide 57
Slide 57 text
AI活⽤ ③
品質を担保する
Slide 58
Slide 58 text
品質の重要性
- 事業の信頼性：セキュリティーとデータ保護の⽣命線
- 企業の経費情報という機密性の⾼い経理データを扱う
- 誤った情報の表⽰や不正な操作を防ぐ、完全性の担保も重要
- ⽣産性：スピードを⽣かすための⼿戻りコスト削減
- 常にチーム内で合意の取れた設計で実装する
- 開発チームの持続性：属⼈化を防ぎ、均質な開発を可能にする
- 個⼈のナレッジではなくチームのナレッジとする
- 中⻑期的にアプリを保守し続けられるようにする
Slide 59
Slide 59 text
設計の定義と知識のSkill化
可能な限り設計やルールを⾔語化してDocs化する
- コーディングルールやアーキテクチャ、画⾯設計や命名...
- パッケージの作成、モデリング等、意図のある設計を⾔語化
- セキュリティーガイドライン
どういう時にどの設計を使うのか知識をSkill化する
- 例: コーディングする時には必ずコーディングルール&命名Docsを読む
- 例: ボトムシートを表⽰する時はボトムシート実装のDocsを読む
- 例: ドメインモデルを作成する時はバックエンドの実装を⾒る
- Bill Oneとしてのドメインを正しくモデリングするため
Slide 60
Slide 60 text
設計の定義と知識のSkill化
画⾯実装の設計(Plan)と実装時の⼿順をCommand化
- デザイン(Figma), UserStory (Notion) を渡したらそれぞれを読み込み、
Skillを利⽤して必要なコンテキストを読み込むように指⽰した
プロンプトCommandにする
- 全員が使う基本的なプロンプトを共通化する
Slide 61
Slide 61 text
開発中のデザイン
Slide 62
Slide 62 text
設計に準じたスピーディな実装を全員が⾏える (作業例)
- 1. /flutter.planning {FigmaURL} {NotionURL} 命名はHoge
- 設計Docsやアーキテクチャ等, 詳細設計に必要な知識を読む
- デザインシステムのコンポーネントの確認も含む
- 2. 出⼒されたPlanを⾒て細かい仕様やコードを調整
- 3. /flutter.execute-plan
- 実装時に必要な⼿順 (ビルド, テスト, ファイル作成)を読ませて作業する
- 4. 動作確認と修正
- 5. /create-pr
AIを活⽤した効果
1,2 ⽇で1つの画⾯の実装は完了する
Slide 63
Slide 63 text
設計に準じたスピーディな実装を全員が⾏える
- ⼈間が仕様を正しく理解している必要があるが、数個のコマンドだけで
⼀定の品質が担保された開発が誰でも⾏えるようになった
- 実装⾃体の作業コストが激減した
- 代わりに仕様の調整やバックエンドとの作業の調整等、⼈とのコミュニケー
ションが必要な作業がボトルネックとなった
- QAの起票数も想定範囲内となり、計画への影響も特に無かった
プロジェクト終盤に⾏った脆弱性診断では対応必要な指摘が0件
- セキュリティーについてのルールをあらかじめ定義していたため、検出
された項⽬が全て考慮済みとなった
AIを活⽤した効果
Slide 64
Slide 64 text
iOSエンジニアからモバイルエンジニアになった (個⼈的)
- ⾃分が作成したいものをどう⾔語化すればよいのかが反復的な経験とし
て⾝につけられた
- iOSという⼀つの技術にこだわっていたiOSエンジニアから、⼿段(実装作
業)はAIに任せて仕様を守り、より品質の⾼いアプリを作ることを⽬指す
エンジニアになった (気がする)
AIを活⽤した効果
Slide 65
Slide 65 text
第４節
AI ネイティブ開発 加速
Slide 66
Slide 66 text
BOチームのAIネイティブ開発
〜全員が⼀定レベルの作業ができるようになった頃の課題〜
- バックエンドの実装待ちで作業が⽌まる
- QA起票の対応をしつつ画⾯実装もしたいけどコンテキストスイッチ⼤変
- Commandの実⾏待ちもあり、さらに作業を加速させたい
Slide 67
Slide 67 text
AI活⽤ ④
作業可能な範囲を広げる
Slide 68
Slide 68 text
開発を加速させる
Cursor Worktreeを⽤いてタスクを並列作業させる
- 新規画⾯の実装を⾏いつつ、バグ修正をする
- ⼈間がコンテキスト管理を⾏える範囲で、1⼈が作業できる量を増やす
領域を超えた⽀援を⾏う
- Cursor Workspaceを⽤いてリポジトリを横断した調査を⾏ってPlanを
作成する
- バックエンドで必要な作業をプロンプトにした PR (Prompt-Request) を
エンジニアに渡すことで作業を引き継ぐ
Slide 69
Slide 69 text
バックエンドの問題をモバイルエンジニアが発⾒できる
- Workspaceによるリポジトリを横断したコードベース・通信ログ・
GCPログなどMCPを活⽤してAIが触れられる情報を広く与えることで、
バックエンドの知識がなくても⾼精度に問題を特定できるようになった
- 必要な修正もPRとして作成することで、問題と作業の意図が⾔語化
されるので作業の引き継ぎが容易になる
- 実際に修正までもモバイルエンジニアが⾏った時もあった
AIを活⽤した効果
Slide 70
Slide 70 text
作業量がコストではなくなりつつある
- 作業⾃体はAIが⾏い⼈間は判断と作業管理を⾏うので、⼈間のコンテキスト
ウィンドウの限り⽣産量がスケールできる
- どのように作業をするかより、どのようなものを作りたいのかを効率的に
⾔語化できれば、⼤規模な作業においてもAIが作業を効率化してくれる
AIを活⽤した効果
Slide 71
Slide 71 text
AI活⽤⑤
AIに役割を与える
Slide 72
Slide 72 text
より品質を⾼める
Skillの中でSub-Agentを⽤意する
- Planの中でも調査、設計、レビューそれぞれでSub-Agentを⽤意する
- コンテキストがSubAgent内で分離することで、作業に集中させる
- それぞれに「Jr.エンジニア」や「シニアエンジニア」など現実世界でも
想像できるようなロールと責務・ルールを与える
- 役割を与えることで、余計な作業をさせたり考えさせない
Slide 73
Slide 73 text
信頼性の⾼いPlanで品質の⾼いコードが出⼒されるようになった
- 雑なPromptを使っていた頃と⽐較し、関連情報や既存実装を
しっかり調査して実装するようになり、⼈間が詳細なコードについて
関与せずとも良いレベルまで近づいてきている
- 現実的には⼈間がレビューしないといけないので、
無くせないがレビュー負荷が減った
AIを活⽤した効果
Slide 74
Slide 74 text
今回はここまで
Slide 75
Slide 75 text
まとめ
半年でアプリをリリースする上で効果的だった事
1. デザインシステムを整備
2. 設計を⾔語化して定義
3. 知識をSkillに、作業をCommandに
4. 作業できる範囲を広げる (並列数, 技術領域)
5. SubAgentを⽤いて品質を⾼める
誰もが同じ作業で同じ成果物を出⼒できるようにする
その上で、より品質の⾼いものを⽬指すとよい
Slide 76
Slide 76 text
Sansan 技術本部
募集ポジション紹介
https://media.sansan-engineering.com/
Slide 77
Slide 77 text
No content