#Fukuoka_33tech vol.4 ~AI × Mobile開発編~

■ イベント
#Fukuoka_33tech vol.4 ~AI × Mobile開発編~
https://sansan.connpass.com/event/388197/

■ 発表者
技術本部 Sansan Engineering Unit
Gustavo Miyamoto

技術本部 Bill One EX プロダクト開発部
原田 拓眞／平山 智己

■ 技術本部 採用情報
https://media.sansan-engineering.com

Transcript

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