「速く作る」から「正しく作る」へ ─ 生成AI時代の開発フロー改革の ロードマップと実行 ─

Transcript

1. © Findy Inc. 2026.06.09 AI Engineering Summit Tokyo 2026 「速く作る」から「正しく作る」へ ─ ⽣成AI時代の開発フロー改⾰の ロードマップと実⾏ ─ ファインディ株式会社 テックリードマネージャー ⼾⽥ 千隼 @starfish0206 1
2. © Findy Inc. 本⽇の内容 1. AI 導⼊の落とし⽳と、計測でわかった現実 2. 「速く作る」から「正しく作る」へ 3. 3つのAI活⽤レベル 4. ファインディのAI活⽤を⽀えるSkill/Agent/Command 5. まとめ 2
3. © Findy Inc. 🎲 活⽤レベルの個⼈差 AIエージェントの使いこなし度に メンバー間で⼤きなばらつき 特にジュニアほど使えていない 🔍 AI出⼒の合否判断ができない 理解せずに AI の出⼒を そのままレビューに回している 📉 Pull requestの質が低下 コードの⼀貫性‧正確性が落ち ⼿戻りが増えている 😩 リードクラスのレビュー負担増 指摘の量が増え、 本来注⼒すべきレビューに時間が割けない 組織全体が「AI に使われている」状態に陥っている ⼼当たりありませんか？ 3
4. © Findy Inc. AI導⼊の「落とし⽳」 4
5. © Findy Inc. 😊 現場の体感 ✓ AI導⼊後、効率が上がったように感じた ✓ 開発スピード感は上がっているはず 🤔 でも実は… × リリースや価値提供は増えていない × アウトプットもアウトカムも 本当に増えている？ → 体感と現実がズレているのでは？ 計測してみたら、想定と違うことが起きていた Pull requestの量は増えたように感じたが 5
6. © Findy Inc. 全体のPull request作成数 6
7. © Findy Inc. 1⼈あたりのPull request作成数 7
8. © Findy Inc. 8 計測したら、AIを導⼊しても⽣産性は変わらなかった 👥 稼働⼈数 1.5 倍 メンバー数は増加 📤 1 ⼈あたりのPull request作成数 横ばい 1⼈あたりのアウトプットは変化無し ⏱ レビュー → Approve 時間 +20 分 昨年⽐で延伸 💬 平均コメント数‧レビュー数 +30% 指摘量が増加 AIを導⼊したのに、⽣産性は伸びていない ファインディで実際に起きていたこと
9. © Findy Inc. 9
10. © Findy Inc. 10
11. © Findy Inc. ➜ ➜ ➜ 観点 󰞵 シニアエンジニア 👶 若⼿エンジニア ⽣産性 上がった 悪化した PR の質 保たれている 低下 AI 出⼒の理解 読める∕検証できる 理解せずレビュー依頼 💬 レビューコメント 増加 ⏱ レビュー負担 上昇 📉 リードタイム 悪化 🟰 トータル⽣産性 ほぼ横ばい 「AIで効率化できた」という実感とのギャップ AI の導⼊でトータルの⽣産性は変わらなかった 11
12. © Findy Inc. 「速く作る」から「正しく作る」へ 12
13. © Findy Inc. ➜ ➜ ⚡ AIが⾼速化したのは「コードを書く」⼯程 💻 書く⼯程 コード⽣成は AIで⼀気に 速くなった 🔍 レビュー‧検証 ←制約 「正しいか」の確認に 時間がかかる 🟰 全体は横ばい 確認に時間が掛かり 速さの恩恵が消える 可視化した数値が何よりの証拠 速くなったのは開発⼯程ではなくコード⽣成 13
14. © Findy Inc. ➜ ➜ ➜ ⚡ 速くコードを書ける AI でスピードは上がる ⚠ 質が落ちる 理解せず⽣成しがち 💢 指摘が増える レビュー負荷の急増 🟰 ⽣産性は横ばい 速さの恩恵が消える 🛠 「正しい作り⽅と⼿順」をハーネス化 する ファインディは「開発フロー改⾰」としてAI時代の開発を⾒直した 正しい作り⽅と⼿順を「ハーネス化」する ⚡ AI活⽤レベルを3段階に分けて、段階的に進める 14
15. © Findy Inc. 🏗 AIを活⽤する前に、これらはAI関係なく重要 ✅ コード設計‧規約‧テストコード • アーキテクチャ‧命名規則‧型定義 • ⼗分なテストカバレッジ • ⼀貫した設計パターン → AI 以前から、品質を保つには必須 🌿 開発⽂化（プロセス） • Pull requestの粒度 • レビュー⽂化 • タスク分解の習慣 • etc → AI 以前から、開発を回すには必須 この基盤の上にこそ、ガードレールもAIも活きる 前提 15
16. © Findy Inc. ⬜ AIがサポート出来る 要件定義‧タスク分解 ⼈間主導でAIは壁打ち相⼿として補助 🟥 AIエージェントに任せる Issue作成 / コード変更 / PR作成 AIが主体的に実⾏ 🟧 AIで代替できる セルフレビュー‧レビュー 本来は⼈間がやるべきだが、代替できる ⬛ AIで代替しづらい QA‧マージ‧リリース 最終判断は⼈間が担う AI代替度で⼯程を分類 16
17. © Findy Inc. 🗺 ⼯程ごとに、AIの主体性と⼈間の役割は変わる ⼯程 🤖 AIの役割 👤 ⼈間の役割 要件定義‧タスク分解 壁打ち‧たたき台⽣成 意思決定‧スコープ確定 Issue / コード / PR ⽣成〜PRを⾃律実⾏ 分解されたタスクを渡す セルフ / レビュー 複数観点でチェック 設計‧要件適合の判断 QA‧マージ‧リリース テスト⽣成‧実⾏⽀援 品質保証‧リリース判断 ⼯程 × 役割：AIと⼈間の分担 17
18. © Findy Inc. VibeCodingでコード⽣成して、Pull requestを作成してレビュー依頼を投げる 📍 対象⼯程 コード変更‧PR作成 セルフレビュー 🤖 AIの役割 コード⽣成〜PR作成〜 セルフレビューを実⾏ 👤 ⼈間の役割 コード⽣成のハンドリング セルフレビュー結果の判断 AI活⽤レベル1: AIエージェントでコード⽣成 18
19. © Findy Inc. 正しい⽅法と⼿順を⽤意して、AgenticWorkflowに委任する 📍 対象⼯程 タスク分解‧Issue作成 レビュー 🤖 AIの役割 タスク分解‧構造化Issue 並列実装‧レビュー観点の抽出 👤 ⼈間の役割 タスクとIssueの⽅向性を決定 レビュー AI活⽤レベル2: AIエージェントでモノを作る 19
20. © Findy Inc. 必要なモノを作る 📍 対象⼯程 要件定義‧QA エンジニアリングからの越境 🤖 AIの役割 現状把握‧要件構造化 QA観点/実⾏を⽀援 👤 ⼈間の役割 何を作るかの意思決定 品質の最終保証 AI活⽤レベル3: AIで価値を⽣み出す 20
21. © Findy Inc. ロードマップ 要件定義 タスク分解 Issue作成 コード変更 Pull request 作成 セルフ レビュー レビュー QA マージ リリース 21
22. © Findy Inc. ロードマップ 要件定義 タスク分解 Issue作成 コード変更 Pull request 作成 セルフ レビュー レビュー QA マージ リリース AIがサポート出来る AIエージェント AIで代替できる AIで代替しづらい 22
23. © Findy Inc. ロードマップ 要件定義 タスク分解 Issue作成 コード変更 Pull request 作成 セルフ レビュー レビュー QA マージ リリース AIがサポート出来る AIで代替しづらい ①AIエージェントでコード⽣成 AIエージェント AIで代替できる 23
24. © Findy Inc. ①AIエージェントでコード⽣成 ②AIエージェントでモノを作る ロードマップ 要件定義 タスク分解 Issue作成 コード変更 Pull request 作成 セルフ レビュー レビュー QA マージ リリース AIがサポート出来る AIエージェント AIで代替できる AIで代替しづらい 24
25. © Findy Inc. ロードマップ 要件定義 タスク分解 Issue作成 コード変更 Pull request 作成 セルフ レビュー レビュー QA マージ リリース AIがサポート出来る AIエージェント AIで代替できる AIで代替しづらい ③AIで価値を⽣み出す ②AIエージェントでモノを作る ①AIエージェントでコード⽣成 25
26. © Findy Inc. AI活⽤レベル1 AIエージェントでコード⽣成 26
27. © Findy Inc. ⚡ レベル1の⽬的：コード変更 + Pull request作成をAIで⾃動化 ⚠ 現場で起きている課題 🎲 活⽤レベルの個⼈差 若⼿ほど使えていない∕メンバー間でばらつき⼤ 🔍 AI出⼒の合否判断ができない 理解せずにAI出⼒をレビュー依頼 📉 Pull requestの質が低下 リードクラスのレビュー負担が増加 😩 「AI に使われている」状態 AI主導になり、⼈間側の理解が追いつかない 理解と責任の所在を再設計する必要がある 「速く作る」フェーズと現状課題 27
28. © Findy Inc. 🛡 ⾃動化されても、品質と判断の最終責任は⼈間が引き受ける ⼯程 担当 責任の対象 コード変更 🤖 AI コード変更 Pull request作成 🤖 AI コード変更 セルフレビュー 🤖 AI コード変更 レビュー 👤 ⼈間 作っているモノ レビュー依頼を出すまでがPull request作成 セルフレビューはレビュー依頼を出す前に⾏うべき AIが出⼒したコードの責任は「⼈間」にある 28
29. © Findy Inc. AI が参照するドキュメント‧ルールを整える 📘 README / プロジェクトドキュメント 🛠 やること 前提‧運⽤ルールなどを記述 ✨ 効果 AIが⽂脈を理解 初期質問の往復が減る 📐 AGENT.md / rules 🛠 やること コード規約‧命名規則‧ テスト⽅針をAIが参照 ✨ 効果 出⼒されるコードの ⼀貫性が担保される 📋 カスタムコマンド / プロンプトのテンプレ 🛠 やること 依頼タスクの規格化 （よくある作業をコマンド化） ✨ 効果 同じ品質のアウトプットが 繰り返し得られる ガードレールがあって初めて、AIが「使い物になるコード」を出す AIのガードレール整備 29
30. © Findy Inc. AI活⽤レベル1を⽀えるSkill 30
31. © Findy Inc. 🚢 Pull request作成 Pull request作成を⾃動化 品質チェック内蔵 🤖 セルフレビュー 複数エージェントを並列で実⾏ 複数の観点からチェック 🔄 外部AI併⽤レビュー Codex CLI と並⾏運⽤ レビュー精度UP ⏰ 定期セルフレビュー⾃動化 平⽇朝⽅にCI 実⾏ 📋 チェックリスト⾃動更新 過去レビューを学習 指摘観点を継続改善 AI活⽤レベル1を⽀えるSkill 31
32. © Findy Inc. ➜ ⼊⼒ コード変更 （ローカル） Pull request作成Skill 品質チェックと同時にPR作成を⾃動化 ➜ 出⼒ PR + レビューコメント （GitHub） ✅ 品質チェック⾃動実⾏ typecheck / lint / test / build を READMEに従って実⾏ 🌿 ブランチ、コミット戦略の検証 feature / fix / refactor / chore の 命名と分岐を強制 🔍 セルフレビュー Skill と統合 PR 作成前にセルフレビュー → 修正コミット → 結果をコメントで⾃動投稿 📝 PR テンプレート⾃動読込 .github/PULL_REQUEST_TEMPLATE.md を もとに body を⽣成 Pull request作成 32
33. © Findy Inc. 🔒 セキュリティ ✨ コード品質 📐 規約準拠 🧹 simplify観点 🎯 要件検証 ☑ チェックリスト 照合 → 複数エージェントが並列で動き、信頼度の⼀定以上の指摘のみ報告 セルフレビュー：複数観点を並列分析 ⚡ 実績：2000以上のPRで運⽤中（2026年5⽉時点） Pull request ▼ ▼ ▼ ▼ ▼ ▼ 33
34. © Findy Inc. ⼊⼒：PR の差分 🤖 メインAIレビュー ⾃動セルフレビュー （6 エージェント並列） 🔄 外部AIレビュー OpenAI Codex CLI （別系統で再評価） ↓ ↓ 統合してレビューコメントとして提⽰ ↓ ↓ 特定のAIに偏らないレビュー∕重要箇所の⾒落としを減らす 外部AI併⽤レビュー：複数視点チェック 34
35. © Findy Inc. ⏰ 平⽇の朝⽅— GitHub Actions で定時起動 🎯 対象：⼀定期間の間、変更されていないファイル（技術的負債候補） ↓ matrix 並列 PR #1 matrix 並列 PR #2 matrix 並列 PR #3 … 定期セルフレビュー⾃動化 35
36. © Findy Inc. 1 過去レビューを収集 GitHub API で 直近 1 ヶ⽉のコメントを取得 2 LLM で傾向分析 よくある指摘パターン を抽出‧分類 3 チェックリスト更新 個⼈別 / チーム別に カスタマイズして反映 4 セルフレビューのSkillに反映 Skillの精度が継続向上 ↻ レビュアーの暗黙知が、Skillに組み込まれて形式知として継続的に改善される チェックリスト⾃動更新 36
37. © Findy Inc. 📦 Plugin Repository Skill / Sub Agent / MCP を リポジトリで管理 👥 全メンバー /plugin install で ワンコマンド配布∕更新 全員がcontributeできる 改善が組織全体に即反映 Plugin で簡単展開 37
38. © Findy Inc. AI活⽤レベル2 AIエージェントでモノを作る 38
39. © Findy Inc. ⚠ 課題：要件を実現する⼿順がAIフレンドリーではない ❓ 実現⽅法がわからない タスクの粒度や⼿順を 誰も決めていない 📭 依頼内容を作れない ⽣成 AI へ何を渡せば 精度よく動くかが 属⼈化している 💡 明確で簡潔なステップ構造 = AI に渡す「設計図」が必要 「正しく作る」フェーズと現状課題 39
40. © Findy Inc. 🎯 レベル2の⽬的：AIに「正しく作らせる」仕組みを整える 🧩 タスク分解 AIが処理しやすい 単位に分割する 📝 Issue 作成 構造化された設計図を 親⼦Issueで表現 🔍 コードレビューの再定義 AIと⼈間で レビュー領域を分割 「正しく作る」フェーズ 40
41. © Findy Inc. 💭 作りたいもの (Why / What) ➜ 🛠 作り⽅の設計図 (How) タスク分解で表現 ➜ 🤖 AI が実装 ステップ通りに ⽣成 ↻ 🔎 レビュー：作り⽅と実現⽅法が合っているかを検証 → 設計図にフィードバック ✨ タスク分解の品質が、そのままアウトプットの品質を決める 「どうやって作るか」を AI に渡す 41
42. © Findy Inc. 協働から委任 へ 「協働」 して書くVibe Coding、「委任」 して任せるAgentic Workflow ──── 協働 から 委任 へ ─ スケールさせたい領域から、任せる範囲を広げていく ────▶ 観点 🤝 AI との協働 (レベル1 Vibe Coding) 🎯 AI への委任 (レベル2 Agentic Workflow) 関係性 隣で並⾛するパートナー タスクを任せる実⾏者 ⼈間の役割 ハンドルを握る運転⼿ ⾏き先を決める指揮者 AI の役割 助⼿席のナビゲーター ⾃⾛する実⾏エージェント 任せる粒度 1 ⾏〜1 関数 タスク / PR / フロー全体 42
43. © Findy Inc. Agentic Workflow ─ 定義と4つの⾃律性 ⼈間がゴールと制約を与え、AIエージェントが計画‧実⾏‧⾃⼰検証までを⾃律的に進める開発スタイル 👤 ⼈間 ─ゴール ＋ 制約 ──▶ 🤖 AIエージェント 計画 → ツール実⾏ → ⾃⼰検証 ─ 成果物 ────▶ 👤 ⼈間レビュー 🎯 ゴール指向 「何を」を与え、「どう実現するか」はAIが組み⽴てる 🧭 計画と分解 ⼤きなタスクをサブタスクに分解して順序付けて実⾏ 🛠 ツール使⽤ ファイル / Skill / コマンド / 検索 / MCP を能動的に使う 🔁 ⾃⼰検証ループ テスト失敗 → 修正 → 再実⾏ を⾃律的に繰り返す 43
44. © Findy Inc. ターミナルへの回帰 ─ AI委任が変えた開発の作業環境 2026年〜 ファインディはメインツールがIDE → ターミナルへ AI 委任の並列性が開発環境そのものを変えた ⌨ メインツールの移⾏ IDEで編集‧実⾏   ↓ ターミナルで作業 （使うものは個⼈の⾃由） 🪟 並列委任の前提 1 ウインドウで1タスクずつ   ↓ 複数ウインドウ‧ペインで 同時にAIへ委任 🔍 IDE の役割変化 すべての開発作業   ↓ 広域に渡るコードリーディング 理解を深めるとき AIに並列で任せる前提に合わせて、開発環境そのものが「並列委任しやすいもの」 へ変化 44
45. © Findy Inc. AI活⽤レベル2を⽀えるSkill 45
46. © Findy Inc. 1 要件理解 — インタラクティブな質問で曖昧さを解消 ↓ 2 コード探索 — 並列の探索 Agent が複数観点で同時調査 ↓ 3 要件明確化 — 不⾜情報を補完しスコープを定義 ↓ 4 設計提案 — 実装⽅針のドラフトを⽣成 ↓ 5 タスク分解 — 実装単位に分解（粒度判定 Skill 連携） ↓ 6 Issue 作成 — Sub Issue / relationship を含む構造化 Issue ⚡ 4000個以上のIssueを⽣成 開発Issue作成 46
47. © Findy Inc. ① 要件理解 47 🤖 ① 質問 要件を具体化 AskUserQuestion活⽤ 👤 ② 回答 ユーザーが 選んで答える 🤖 ③ 要約 理解を明⽂化して提⽰ 👤 ④ 確認 OK / 修正を繰り返す ➡ ➡ ➡ ユーザーと合意できるまで選択式の質問を繰り返す（推測で進めない）
48. © Findy Inc. ② コード探索 48 📥 機能要件 ＋ 探索の指⽰ 🤖 探索Agent① 類似機能の実装‧ パターン‧テストを追跡 🤖 探索Agent② アーキテクチャ‧拡張点を調査 システムの現状との ギャップを洗い出す ➡ ➡ ➡ ➡ 複数の探索Agentを並列起動 複数観点を同時に調べて現状の理解とギャップの洗い出しを⾼速化
49. © Findy Inc. ③ 要件明確化 49 🔍 設計の前に、残った "ギャップ" を洗い出す 🧩 エッジケース ⚠ エラー処理 🔗 統合ポイント 📐 スコープ境界 🕰 後⽅互換 ⚡ 性能要件 ⬇ ✅ すべて確認し、全回答が揃って要件を確定させてから設計へ進む
50. © Findy Inc. ④ 設計提案 50 評価軸 🛡 最⼩変更 ⚖ 実⽤バランス ✨クリーン 変更範囲 最⼩ 中 ⼤ 保守‧拡張性 低〜中 中 ⾼ リスク 低 中 中〜⾼ 適切な場⾯ 緊急‧⼩修正 標準的な開発 ⻑期‧基盤 3案を並列設計し、表で⽐較して1案を採⽤
51. © Findy Inc. ⑤ タスク分解 51 📥 設計案 （設計提案） 🧩 タスク分解 Skill PR単位に分解 🔍 タスクレビュー Agent 粒度‧独⽴性を検証 📋 確定 & 選択 Issue化対象を選ぶ ➡ ➡ ➡ ↺ 要調整なら Skill へ戻して再分解 すべてのタスク = 独⽴して revert できる「完結した作業単位」 1 独⽴性チェック ❓ Task A なしで Task B は機能する？ YES → Step 2 へ NO → 同じ PR ➜ 2 完結性チェック ❓ Task A 単独で 意味のある完結した 機能になる？ YES → Step 3 へ NO → 同じ PR ➜ 3 revert 影響チェック ❓ Task A を revert したら Task B が壊れる？ YES → 同じ PR NO → 別 PR に分割
52. © Findy Inc. 🎯 親 Issue (Feature)：通知機能の追加 ▼ #1 DB層：通知テーブル追加 ▼ ▼ #2 POST API追加 #3 DELETE API追加 ⛓ blocked_by の依存関係 52 ⑥ Issue作成
53. © Findy Inc. 🎩 Team Lead Agent — Layer ごとに Worker を起動‧同期 🎯 親 Issue (Feature)：ユーザー通知機能の追加 ▼ Layer 0 #1 DB層 通知テーブル追加 🌿 worktree-1 🤖 Worker Agent ▼ ▼ Layer 1 #2 API層 POST API 追加 🌿 worktree-2 🤖 Worker Agent #3 API層 DELETE API 追加 🌿 worktree-3 🤖 Worker Agent blocked_byに従ってLayer 単位で同期 同Layer内は worktree + Agent で完全並列 並列実装：Issue × Worktree × Agent ▼ ▼ ▼ ▼ 53
54. © Findy Inc. 🤖 AI に任せる ✓ コード規約‧命名 ✓ 型定義 ✓ テストコード‧テストケース 👤 ⼈間が確認する ✓ ビジネスロジックが要件をクリアするか ✓ アーキテクチャ‧データベース設計 ✓ 明確なセキュリティリスク → コードそのものから脱却 視点がより抽象的 に レビュー ＝ 抽出された観点を⼈間が確認‧判断すること コードレビューの再定義 54 🤖 セルフレビューをAI に任せ、"⼈間が⾒るべき観点" を抽出‧提⽰
55. © Findy Inc. 📈 1 ⼈あたり Pull request作成数（前年⽐） 1.5 倍越え ⬆ 🛠 AIフレンドリーな設計図 誰でも作れる状態 になった （タスク分解 + 構造化Issue） 🎯 正しい⽅法と⼿順で作れる 作りたいものを 再現性⾼くアウトプット できる AI活⽤レベル2の結果 55
56. © Findy Inc. AI活⽤レベル3 AIで価値を⽣み出す 56
57. © Findy Inc. ⚠ 「速く正しく作る」をクリアすると上流⼯程が詰まる 🔍 要件の実現可能性の調査が エンジニアだけ PdM がシステムを把握できれば、 施策作成までのスピードは上がる ↔ システムとプロダクトの 概念が離れている お互いを知らない状態で 施策や検証が進む 何を作るかが決まらないと、開発スピードを活かせない 「必要なものを作る」フェーズと現状課題 57
58. © Findy Inc. 🎯 レベル3の⽬的：AIで価値を⽣み出すところまで踏み込む 📋 要件定義 → PdM領域への越境 エンジニアリングのスピードを プロダクト企画にまで広げる ✅ QA 領域への挑戦 「AI で代替しづらい」とされた 品質保証も AI ⽀援で進める 「必要なものを作る」フェーズ 58 エンジニアリングの越境がレベル3の鍵
59. © Findy Inc. ➜ ➜ 🧭 システム + プロダクトの 現状把握 🔎 現状把握 システムと プロダクトの両⽅を 計測 / 取得 🛠 現状から何がどう変わるか 施策を検討 🚀 価値提供 PDCA 実装 → 検証 → 計測 再現性⾼く回す 「現状把握」が出発点 59
60. © Findy Inc. AI活⽤レベル3を⽀えるSkill 60
61. © Findy Inc. ⼊⼒ 曖昧なアイデア GitHub Issue ➜ 要件定義構造化 Skill （WHY/WHAT 分析） ➜ 出⼒ WHY/WHAT 構造化済み GitHub Issue HOW（実装詳細）はレベル2の要件→Issue⾃動作成Skillに連携可能 要件定義Skill 61
62. © Findy Inc. 💻 システム情報 📁 リポジトリ コード / アーキテクチャ 実装パターン 📊 運⽤メトリクス Datadog / ログ → システムの「いま」を AI に渡せる 📦 プロダクト情報 📈 Google Analytics ユーザー⾏動 / KPI 📚 Notion 仕様 / プロダクト⽅針 🗂 各種プロダクトデータ 売上 / 顧客 など → プロダクトの「いま」を AI に渡せる ✨ 「数値を⾒ながら AI と壁打ち」が標準動作に システム & プロダクトの現状把握 62
63. © Findy Inc. 要件定義の出発点は「現状把握」 広い範囲のコンテキストを必要な分だけ収集する 💻 コードベース リポジトリの構造 実装制約‧パターン 📊 Google Analytics ユーザー⾏動 離脱率‧遷移パターン 📚 プロダクト⽂書 KPI 定義 / ポリシー Notion‧docs/ 🐙 GitHub Issues / PR 過去の議論‧経緯 類似施策の結果 🔍 Datadog 運⽤メトリクス 障害‧パフォーマンス 💼 各種指標 顧客‧売上‧KPIデータ ビジネス指標 専⾨Agentチームが、各ソースから「必要な分だけ」を⾃動収集 現状把握 63 各観点の専⾨家が並列で動くことで、要件定義の質と速度を両⽴ Agent Teamsを使い、お互いが会話できる
64. © Findy Inc. 要件Issueを作成し、そのまま実装へ 64 🔍 複数視点で並列チェック 価値‧論理‧充⾜度を 5観点で同時に検証 📋 MVP / エンハンスに分割 要件Issueを 分けて作成 🤖 開発Issue作成スキルへ そのまま 連携できる ➡ ➡ 🎯 親Issue （施策全体） ➡ 🚀 MVP Issue ✨ エンハンスIssue① ✨ エンハンスIssue② 🔀 要件定義で作ったIssueは、そのまま開発Issue作成スキルへ → タスク分解‧⼦Issue化まで、要件から実装まで⼀気通貫
65. © Findy Inc. ➜ ➜ ➜ 🤔 従来の認識 × ユーザビリティ × アクセシビリティ × UI / UX これらのテストは AI 単独では難しい → 「QA は AI で代替しづらい」 💡 ファインディの仮説 ✓ 「代替」 ではなく「⽀援」 する ✓ AI が QA エンジニアの判断を最⼤化 する形 → ⼈間 × AI の協働モデル 🔧 AI ⽀援の 4 ステップ 📥 仕様の⾃動構造化 🔍 観点抽出 📋 テストケース⽣成 🎭 ⾃動実⾏ QA領域への挑戦：「代替」ではなく「⽀援」 65
66. © Findy Inc. ➜ ⼊⼒ 仕様ソース Issue Figma Notion QA観点抽出 観点を⾃動抽出 ➜ テストケース⽣成 ⾃動実⾏と ⼈間確認で分ける ➜ QA⾃動実⾏ Playwright実⾏ ➜ 出⼒ レポート (スクリーンショッ ト付) 観点 → 設計 → 実⾏ が、Pluginのスキル群で⼀気通貫に完結 QA領域の3つのSkill 66
67. © Findy Inc. ▼ ⼊⼒：仕様ソース （Issue / Figma / Notion） 仕様分析 Agent 仕様を構造化抽出 画⾯構造‧UX 探索Agent コードから画⾯‧操作フロー を分析 影響範囲判定 Agent 変更による回帰リスクを評価 出⼒：QA観点 Markdown 複数Agent が並列で動き、観点設計を数分で⽣成 QA観点 ▼ ▼ ▼ 67
68. © Findy Inc. ⼊⼒ QA観点md ➜ QAテストケース⽣成Skill 観点 → ステップ∕期待結果 ∕前提条件 を構造化 ➜ 出⼒ テストケース (Markdown) ⚡ 効果：観点 → 具体ケースへの落とし込み⼯数 数時間 → 数分 フォーマット統⼀でレビューも速い∕QAリスト作成が⼀気通貫に QAテストケース⽣成 68
69. © Findy Inc. 🤖 ⾃動実⾏できる ✓ 機能要件 / 画⾯操作で確認 ✓ 画⾯ポチポチで再現できる検証 → Playwright で⾃動実⾏ 👤 ⼈間が確認する ✓ UI / UX‧操作感 ✓ アクセシビリティ等の⾮機能 ✓ ⾃動で完全網羅が難しい領域 → ⼈間がチェックする項⽬として  テストケースを作成 → AIに任せる領域と⼈間が責任を持つ領域を分けて運⽤ QAテストケースを "⾃動 / ⼈間" で分けて⽣成 69 🤖 ⾃動でチェックできる項⽬と 👤 ⼈間が確認すべき項⽬を、分けて抽出する
70. © Findy Inc. 🔐 認証‧認可 ⌨ ⼊⼒バリデーション 🖼 表⽰‧UI 📂 ファイル操作 🔗 外部連携 ✉ メール送信 共通基準で、観点漏れ‧粒度のばらつきを 6 軸並列で検出 QAテストケース品質レビュー 📋QAテストケース（観点 / テストケース） ▼ ▼ ▼ ▼ ▼ ▼ 70
71. © Findy Inc. 😩 Before：⼿動 QA × 同じケースを毎回⼿で繰り返す × 退⾏テストに時間が取られ 新規ケースの検証が遅延 × ヒューマンエラー、再現できないバグ × ⼯数が機能数に⽐例して膨らむ 🤖 After：AI ⽀援 QA ✓ 反復可能なケースはAI が淡々と実⾏ ✓ 同じテストを 何度でも再現可能 ✓ スクショ付きレポート ✓ ⼈間は「判断が必要な領域」に集中 🎯 ⼈間が集中すべき：ユーザビリティ評価 / 例外シナリオ / クライアント要件確認 QA⾃動実⾏Skill 71 🎭 Playwright MCP を介して、Claude Code から直接ブラウザを操作
72. © Findy Inc. まとめ 72
73. © Findy Inc. ➜ ➜ レベル1 「速く作る」 コード⽣成の⾃動化 レベル2 「正しく作る」 モノ作り全体の再設計 レベル3 「必要なものを作る」 他領域への越境 どれか1つではなく、段階的に積み上げることで初めて成⽴する AI活⽤レベル 73
74. © Findy Inc. ⚠ ⼟台が弱いと、ガードレールもAIも成果を出せない 4. 🤖 AI Skill / Plugin 横展開 — 組織全体で AI 活⽤を加速させる 3. 🛡 ガードレール‧ハーネス整備 — AI が出⼒するコードのガードを敷く （README / AGENT.md / rules / 規約） 2. 🌿 PR 粒度‧レビュー⽂化 — 開発⽂化を育てる 1. ✅ コード品質‧テストコード — 統⼀規約 / 型定義 / テストコード — まず ここを充実させる 💡 順番を間違えない：基本が固まってからAI活⽤を載せる ⚠ 順番を間違えない：基本が先、AI活⽤は後 74
75. © Findy Inc. 🧭 ⼈間の役割が上流へ コードの読み書きから 何をどう作るかの判断へ変化 より抽象的で上流の仕事に集中 🌱 やるべきことは変わらない 統⼀規約 / コード品質 / テストコード PR 粒度 / レビュー / ⽂化 AI時代の本丸は「速く作る」ではなく「正しく作る」「必要なものを作る」 への 段階的越境 まとめ 75 基本の徹底こそがAI活⽤の⼤前提 基本の⼟台の上に、段階を踏んでAI活⽤を進めることが⼤事
76. © Findy Inc. ご清聴ありがとうございました Ask the Speakerで会いましょう 76