未来のAI駆動開発をイメージしながらAI開発基盤を整備する

@IT Architect Live 2026 冬 の登壇資料
https://members05.live.itmedia.co.jp/library/OTg4Mjg%253D

Transcript

1. © Findy Inc. 未来のAI駆動開発をイメージしながら AI開発基盤を整備する 浜⽥ 直⼈ Naoto Hamada (ham) 2026/03/23,24 @IT Architect Live 2026 冬
2. © Findy Inc. 2 Team+開発部 VP of Engineering, Development Productivity - 2006-2015: SIer - 2015-2019: toC Webアプリケーション開発, EM - 2019-2022: toB SaaS開発, EM - 2022- : toB SaaS開発(Findy Team+), コンサル 浜⽥ 直⼈ Naoto Hamada
3. 会社概要 © 2024 Findy Inc. 挑戦するエンジニアの プラットフォームをつくる。 ビジョン つくる⼈がもっとかがやけば、 世界はきっと豊かになる。 経営理念 会社名 ファインディ株式会社 / Findy Inc. 代表取締役 ⼭⽥ 裕⼀朗 設⽴ 2014 年 2 ⽉ ※ 本格的な事業開始は2016年7⽉ 全従業員数 478 名 ※2026年1⽉時点 資本⾦ 19億9,692万円 ※ 資本準備⾦含む 住所 東京都品川区大崎1-2-2 アートヴィレッジ大崎セントラルタワー 5階 事業許可番号 13-ユ-308478 サービス ‧IT/Webエンジニアの転職サービス「Findy」 ‧ハイスキルなフリーランスエンジニア紹介サービス「Findy Freelance」 ‧経営と開発現場をつなぐAI戦略⽀援SaaS「Findy Team+」 ‧開発ツールのレビューサイト「Findy Tools」 ‧テックカンファレンスのプラットフォーム「Findy Conference」 ‧顧客価値を追求する、AI時代の製品開発マネジメント「Findy Insights」等 投資家 グローバル‧ブレイン、ユナイテッド、SMBCベンチャーキャピタル、KDDI、 JA三井リース、みずほキャピタル、博報堂ＤＹベンチャーズ、Carbide Ventures、等 3
4. © Findy Inc. 4 ファインディが展開するエンジニアプラットフォーム
5. © Findy Inc. 将来のAI駆動開発について 思いを馳せる 5
6. © Findy Inc. 6 将来のAI駆動開発について思いを馳せる 2024年7⽉にOpenAIが提⽰したAI活⽤の5つのステージ Stage 1: “Chatbots, AI with conversational language” Stage 2: “Reasoners, human-level problem solving” Stage 3: “Agents, systems that can take actions” Stage 4: “Innovators, AI that can aid in invention” Stage 5: “Organizations, AI that can do the work of an organization” Inc. 5 Steps That OpenAI Thinks Will Lead to Artificial Intelligence Running a Company https://www.inc.com/ben-sherry/5-steps-that-openai-thinks-will-lead-to-artificial-intelligence-running-a-company.html
7. © Findy Inc. 7 将来のAI駆動開発について思いを馳せる 2024年7⽉にOpenAIが提⽰したAI活⽤の5つのステージ Stage 1: “Chatbots, AI with conversational language” Stage 2: “Reasoners, human-level problem solving” Stage 3: “Agents, systems that can take actions” Stage 4: “Innovators, AI that can aid in invention” Stage 5: “Organizations, AI that can do the work of an organization” Inc. 5 Steps That OpenAI Thinks Will Lead to Artificial Intelligence Running a Company https://www.inc.com/ben-sherry/5-steps-that-openai-thinks-will-lead-to-artificial-intelligence-running-a-company.html ソフトウェア開発においては 2.5くらいまではきている感覚
8. © Findy Inc. 8 将来のAI駆動開発について思いを馳せる Gemin
9. © Findy Inc. 9 将来のAI駆動開発について思いを馳せる Gemin
10. © Findy Inc. 10 将来のAI駆動開発について思いを馳せる Gemin AI⽀援 AI⽀援 AI⽀援 Stage 1: “Chatbots, AI with conversational language” AIの役割: 設計、開発、テストのアシスタント
11. © Findy Inc. 11 将来のAI駆動開発について思いを馳せる
12. © Findy Inc. 12 将来のAI駆動開発について思いを馳せる Gemin AI⾃律 AI⾃律 AI⾃律 Stage 2: “Reasoners, human-level problem solving” AIの役割: 設計、開発、テストに必要なタスクを⾃律して実⾏
13. © Findy Inc. 13 設計⼯程のAIエージェント 要件定義 要件定義 要件定義 要件定義 ヒアリング アーキテクチャ‧ 実装⽅針検討 設計書⽣成 レビュー 要件定義 要件定義 設計書 レビュー 要件定義 作成 ヒアリング 回答
14. © Findy Inc. 14 設計⼯程のAIエージェント 要件定義 要件定義 要件定義 要件定義 ヒアリング アーキテクチャ‧ 実装⽅針検討 設計書⽣成 レビュー 要件定義 要件定義 設計書 レビュー 要件定義 作成 ヒアリング 回答
15. © Findy Inc. 15 設計⼯程のAIエージェント 要件定義ヒアリングエージェント - 役割 - 要件を分析し、仕様の漏れ、曖昧な表現、 エッジケース（異常系など）を特定して逆質 問を⾏います - インプット - 要件定義 - アウトプット - 明確化された要件定義書、未決事項（ヒアリ ング事項）のリスト あなたは経験豊富なシニアシステムアナリストです。 【初期要件】を読み、ソフトウェア設計に進むにあたって不⾜し ている情報や、曖昧な箇所を特定してください。 特に以下の観点を重視してチェックしてください： 1. エッジケースや異常系のハンドリング⽅針 2. ⾮機能要件（想定されるユーザー数、パフォーマンス要件な ど） 3. データのライフサイクル（保存期間や削除⽅針） 【出⼒要件】 - 開発者が設計を進める上で致命的なブロッカーとなる不明点 を、優先度順にリストアップし、私に質問してください。 - 質問は「はい/いいえ」ではなく、具体的な仕様の決定を促す形 式にしてください。
16. © Findy Inc. 16 設計⼯程のAIエージェント 要件定義 要件定義 要件定義 要件定義 ヒアリング アーキテクチャ‧ 実装⽅針検討 設計書⽣成 レビュー 要件定義 要件定義 設計書 レビュー 要件定義 作成 ヒアリング 回答
17. © Findy Inc. 17 設計⼯程のAIエージェント アーキテクチャ‧実装⽅針検討エージェント - 役割 - 確定した要件に基づき、最適な⾔語、フレー ムワーク、インフラ構成、システムアーキテ クチャを選定‧提案します - インプット - 明確化された要件定義書、チームの技術ス タック制約 - アウトプット - アーキテクチャ決定記録（ADR）、技術ス タック⼀覧、システム構成の概要 あなたは優れたソフトウェアアーキテクトです。 提供された【要件定義書】を満たすための、最適なアーキテク チャと実装⽅針を策定してください。 AIによる後続の⾃動設計の精度を上げるため、使⽤する技術は具 体的に絞り込んでください。 以下の項⽬をMarkdownフォーマットで出⼒してください： 1. 全体アーキテクチャ⽅針（例: モノリス、マイクロサービス、 BFFの有無など） 2. 選定する技術スタック（バックエンド⾔語/FW、フロントエン ド、データベース、インフラ）とその選定理由 3. データモデリングの基本⽅針（RDBかNoSQLかなど）
18. © Findy Inc. 18 設計⼯程のAIエージェント 設計書⽣成エージェント - 役割 - 決定した要件とアーキテクチャ⽅針に基づ き、具体的なシステム設計書（API仕様、DB スキーマなど）を⽣成します - インプット - 要件定義書、アーキテクチャ‧実装⽅針 - アウトプット - API仕様書、テーブル定義書（DDLや Mermaid ER図）、コンポーネント設計書 あなたはリードバックエンドエンジニアです。 【要件定義書】および【アーキテクチャ⽅針】に基づき、詳細な 設計書を作成してください。 出⼒のばらつきを無くすため、必ず以下の【指定フォーマット】 に厳密に従って出⼒してください。 【指定フォーマット】 # 1. データベーススキーマ（Mermaid ER図） （ここにMermaid記法で記述） # 2. テーブル定義 - テーブル名: - カラム定義: [物理名, 論理名, データ型, 制約, 備考] のマークダウ ンテーブル # 3. エンドポイント⼀覧 - [メソッド, URI, 概要, リクエストパラメータ, レスポンス構造] の マークダウンテーブル
19. © Findy Inc. 19 設計⼯程のAIエージェント 要件定義 要件定義 要件定義 要件定義 ヒアリング アーキテクチャ‧ 実装⽅針検討 設計書⽣成 レビュー 要件定義 要件定義 設計書 レビュー 要件定義 作成 ヒアリング 回答
20. © Findy Inc. 20 設計⼯程のAIエージェント 多⾓観点レビューエージェント - 役割 - 設計書のレビューを多⾓的に⾏う - 観点ごとにエージェントを分割 - インプット - 設計書、要件定義書、アーキテクチャ⽅針 - アウトプット - 指摘事項リスト、修正案 あなたは【役割】のスペシャリストとして設計レビューを⾏いま す。 【設計書】と【要件定義書】を⽐較‧検証し、あなたの専⾨領域 の観点から問題点を指摘してください。 指摘事項は「問題の箇所」「理由」「具体的な修正提案」の3点 セットで出⼒してください。 — 【役割】 仕様‧ロジック担当: プロダクトマネージャー兼QAエンジニア （要件との⽭盾、ビジネスロジックの破綻、仕様漏れをチェッ ク） アーキテクチャ担当: シニアソフトウェアエンジニア（アンチパ ターンの有無、コンポーネント間の結合度、実現可能性をチェッ ク） セキュリティ担当: セキュリティスペシャリスト（OWASP Top 10 に基づく脆弱性、認証‧認可の設計漏れ、データのサニタイズ漏 れをチェック） パフォーマンス担当: SRE（サイト信頼性エンジニア）（N+1問題 の懸念、スケーラビリティのボトルネック、トランザクションの 競合をチェック）
21. © Findy Inc. 21 開発⼯程のAIエージェント 要件定義 要件定義 設計書 要件定義 要件定義 イシュー 要件定義 要件定義 コード タスク分解 イシュー⽣成 コーディング ヒアリング レビュー commit PR作成 レビュー修正 マージ判定 レビュー マージ ヒアリング 回答
22. © Findy Inc. 22 開発⼯程のAIエージェント 要件定義 要件定義 設計書 要件定義 要件定義 イシュー 要件定義 要件定義 コード タスク分解 イシュー⽣成 コーディング ヒアリング レビュー commit PR作成 レビュー修正 マージ判定 レビュー マージ ヒアリング 回答
23. © Findy Inc. 23 開発⼯程のAIエージェント タスク分解‧イシュー⽣成エージェント - 役割 - レビュー済みの設計書を元に、実装可能なレ ベルまでタスクを分解し、イシューを⽣成し ます - インプット - 設計書、アーキテクチャ⽅針 - アウトプット - イシュー あなたはアジャイル開発のテックリードです。 完成した【設計書】を読み込み、開発者が迷わず実装に着⼿でき る粒度のイシュー（タスク）に分解してください。 1つのイシューは、原則として数時間〜1⽇で完了する粒度で、1つ の観点のみ含まれるようにしてください。 以下のフォーマットに従って、イシューを作成してください。 【出⼒項⽬】 - Issue Title（[Backend] ユーザー登録APIの実装 など、プレ フィックスをつける） - Description（実装すべき内容の具体的な説明） - Acceptance Criteria（Gherkin構⽂を⽤いた「〜が〜できるこ と」という受け⼊れ条件） - Dependencies（このタスクに着⼿する前に完了している必要が ある他のタスク）
24. © Findy Inc. 24 開発⼯程のAIエージェント 要件定義 要件定義 設計書 要件定義 要件定義 イシュー 要件定義 要件定義 コード タスク分解 イシュー⽣成 コーディング ヒアリング レビュー commit PR作成 レビュー修正 マージ判定 レビュー マージ ヒアリング 回答
25. © Findy Inc. 25 開発⼯程のAIエージェント イシュー内容ヒアリングエージェント - 役割 - イシューの内容と既存のコードベースを照ら し合わせ、実装に必要な情報が揃っているか 確認し、不⾜があれば質問します - インプット - イシュー、関連する設計書、現在のコード ベース - アウトプット - 開発着⼿判定、不⾜情報のヒアリングリスト あなたはアサインされたイシューをこれから実装するソフトウェ アエンジニアです。 以下の【イシュー内容】と【提供された設計書/コード】を読み、 すぐにコーディングを開始できるか判定してください。 1. もし情報が⼗分に揃っている場合は「Ready」と出⼒してくだ さい。 2. もし実装⽅針が複数考えられる場合や、エラーハンドリングの 要件が不明確な場合は「Not Ready」とし、イシュー作成者に対 する具体的な確認事項を優先度順に箇条書きで出⼒してくださ い。
26. © Findy Inc. 26 開発⼯程のAIエージェント 要件定義 要件定義 設計書 要件定義 要件定義 イシュー 要件定義 要件定義 コード タスク分解 イシュー⽣成 コーディング ヒアリング レビュー commit PR作成 レビュー修正 マージ判定 レビュー マージ ヒアリング 回答
27. © Findy Inc. 27 開発⼯程のAIエージェント コーディングエージェント - 役割 - イシューの要件を満たすプロダクトコードと テストコードを⽣成します。静的解析ルール の順守も意識させます - インプット - 明確化されたイシュー、コーディング規約、 既存コード - アウトプット - 変更‧追加されたソースコード、テストコー ド あなたは優秀なプログラマーです。 【イシュー内容】を満たすためのコードを実装してください。実 装にあたっては、以下の【コーディング規約】を厳守してくださ い。 【出⼒要件】 1. プロダクトコードの実装（リファクタリングを含む） 2. 実装したロジックに対する⾃動テストコード 3. コードは静的解析ツール（Linterなど）の警告が出ないクリー ンな状態にすること
28. © Findy Inc. 28 開発⼯程のAIエージェント Commitエージェント - 役割 - 変更されたコードの差分を解析し、プロジェ クトのルール（Conventional Commitsな ど）に従った適切なコミットメッセージを⽣ 成し、コミットます - インプット - GitのDiff情報 - アウトプット - ルールに沿ったコミットメッセージ、コミッ ト あなたはGitリポジトリの履歴を管理するアシスタントです。 以下の【コード差分】を解析し、Conventional Commitsの仕様 に従ってコミットメッセージを⽣成してください。 【フォーマットルール】 <type>[optional scope]: <description> [optional body] - typeは feat, fix, docs, style, refactor, perf, test, chore のいずれか を使⽤すること - descriptionは変更内容を簡潔に（50⽂字以内）記載すること - bodyには「なぜこの変更を⾏ったか（Why）」を記載すること - co-authored-byに利⽤したAI情報を記載すること
29. © Findy Inc. 以下の【イシュー情報】と【コード差分】を元に、Pull Request を⽣成してください。 出⼒フォーマットは `.github/PULL_REQUEST_TEMPLATE.md` に従ってください。 Authorには指⽰を出したメンバーを指定してください。 レビュアーにはXX-Teamを指定してください。 29 開発⼯程のAIエージェント PR作成エージェント - 役割 - イシュー内容と⼀連のコミット履歴を要約 し、プルリクエストを作成します - インプット - イシュー情報、コミット履歴、コード差分全 体 - アウトプット - プルリクエスト
30. © Findy Inc. 30 開発⼯程のAIエージェント 要件定義 要件定義 設計書 要件定義 要件定義 イシュー 要件定義 要件定義 コード タスク分解 イシュー⽣成 コーディング ヒアリング レビュー commit PR作成 レビュー修正 マージ判定 レビュー マージ ヒアリング 回答
31. © Findy Inc. あなたは【役割】の専⾨家として、このPull Requestのコードレ ビューを⾏います。 以下の観点に絞ってコードをチェックし、改善が必要な箇所があ れば対象のファイル名と⾏番号、修正案を提⽰してください。 ※軽微なフォーマットの違いなどLinterで検知できるものは指摘 しないでください。 — 設計‧仕様観点: イシューや設計‧要件を満たしているかチェック 可読性‧保守性観点: 命名規則の妥当性、関数の肥⼤化、重複コー ドをチェック ⾔語‧フレームワーク観点: ⾔語‧フレームワークのベストプラク ティスに沿っているか、⾮効率な実装がないか UX‧常識（ドメイン）観点:ユーザー体験を損なう実装（不親切な エラーメッセージ、極端に遅い処理によるストレスなど）や、⼀ 般的なビジネスロジック上の「常識的な抜け漏れ」を指摘 セキュリティ観点: SAST（静的解析）エージェント: DAST（動的 解析）エージェント パフォーマンス観点: N+1や無駄な処理などパフォーマンス観点を 指摘 テスト観点: ホワイトボックスエージェント/ ブラックボックス エージェント / カバレッジ‧品質メトリクス エージェント 31 開発⼯程のAIエージェント 多⾓観点AIレビューエージェント - 役割 - コードレビューを多⾓的に⾏う - 観点ごとにエージェントを分割 - インプット - 作成されたPRの差分、PRディスクリプショ ン、イシュー、規約 - アウトプット - 指摘事項
32. © Findy Inc. あなたはPRの作成者です。レビュアーから以下の【レビューコメ ント】と【CIの実⾏結果】を受け取りました。 1. 指摘事項が妥当であり修正可能な場合は、コードを修正し、 「ご指摘ありがとうございます。〇〇の通り修正しました。」と 返信⽂を作成してください。 2. 指摘事項が現在のイシューのスコープ外である場合、またはパ フォーマンス上のトレードオフなどで意図的に現在の実装にして いる場合は、コードは修正せず、レビュアーが納得する技術的な 理由を添えて「対応しない理由」を丁寧に返信してください。 32 開発⼯程のAIエージェント レビュー修正対応エージェント - 役割 - レビュー指摘、およびCIのエラーログを読み 取り、コードを再修正します。対応しなかっ た場合は、その正当な理由を返信 - インプット - PRについたコメント、CIのエラーログ、現在 のコード - アウトプット - 追加のコード差分、レビュアーへの返信コメ ント
33. © Findy Inc. あなたは厳格なリポジトリのメンテナー（マージ実⾏の最終ゲー トキーパー）です。 以下の【PRステータス情報】および【レビュースレッドの会話履 歴】を確認し、マージを実⾏してよいか判定してください。 【必須マージ条件】 1. CI/CDパイプライン（Test, Lint, Build）がすべて `passed` で あること。 2. 規定数のレビュアーから `Approved` を得ていること。 3. すべてのレビュー指摘に対する対応が完了していること。 - 対応完了の定義は以下のいずれかであること： A: 指摘に従ってコードが修正され、その旨が返信されている。 B: コードを修正しない場合、「スコープ外である」「別のIssue で対応する」「パフォーマンス上のトレードオフがある」など、 修正しない正当な理由が論理的に説明され、レビュアーからの反 論が⽌まっている。 【出⼒要件】 - 上記の条件をすべて満たしている場合は、マージを実⾏（API コール等）し、「すべての条件を満たしたためマージしました」 と出⼒してください。 - 条件を満たしていない場合はマージをブロックし、満たしていな い理由を具体的に出⼒してください。 （例：「〇〇の指摘に対して、修正も理由の説明も⾏われていま せん」「CIのテストが1つ失敗しています」など） 33 開発⼯程のAIエージェント マージ判定エージェント - 役割 - PR内のすべてのコメントを解析し、指摘事 項に対して「コードの修正」または「修正し ない理由」が提⽰され、合意形成が完了して いるかを確認した上でマージを実⾏ - インプット - PRステータス（CI結果、Approve数）、PR コメント、コミット履歴 - アウトプット - マージの実⾏、またはブロック要因の指摘コ メント
34. © Findy Inc. 34 テスト⼯程のAIエージェント 要件定義 要件定義 要件定義 要件定義 要件定義 テスト ケース 要件定義 要件定義 コード 受け⼊れテスト ケース⽣成 テスト実⾏ 探索的テスト テスト失敗 トリアージ ⾮機能要件 テストケース⽣成 要件定義 要件定義 設計書 結合‧システム テストケース⽣成 要件定義 要件定義 テスト コード 要件定義 要件定義 レポート レビュー レビュー 要件定義 要件定義 トリアージ 結果 開発に戻す テスト実施
35. © Findy Inc. 35 テスト⼯程のAIエージェント 要件定義 要件定義 要件定義 要件定義 要件定義 テスト ケース 要件定義 要件定義 コード 受け⼊れテスト ケース⽣成 テスト実⾏ 探索的テスト テスト失敗 トリアージ ⾮機能要件 テストケース⽣成 要件定義 要件定義 設計書 結合‧システム テストケース⽣成 要件定義 要件定義 テスト コード 要件定義 要件定義 レポート レビュー レビュー 要件定義 要件定義 トリアージ 結果 開発に戻す テスト実施
36. © Findy Inc. あなたはプロダクトの品質を担保するQAオートメーションエンジ ニアです。 以下の【ユーザーストーリー】と【提供されたフロントエンドの 実装（DOM構造）】を読み込み、受け⼊れテストを構築してくだ さい。 【出⼒要件】 1. ユーザーの業務フローに沿ったシナリオをGherkin構⽂（Given / When / Then）で記述してください（正常系‧異常系を含む）。 2. 上記シナリオのうち、機械的に判定可能なものについて、 Playwright（TypeScript）を⽤いたE2Eテストコードを⽣成して ください。DOMの指定には壊れにくいロケーター（data-testidや Role等）を優先して使⽤してください。 3. キャプチャ画像によるレイアウト崩れの⽬視確認など、AIや⾃ 動テストコードでの判定が困難で、⼈間が⼿動で実施すべきテス ト項⽬があれば別途リストアップしてください。 36 テスト⼯程のAIエージェント 受け⼊れテストケース⽣成エージェント - 役割 - 要件定義書から操作シナリオ（ハッピーパ ス）および、ビジネスルール上の例外シナリ オを抽出し、受け⼊れテストケースを⽣成 - インプット - 要件定義書 - アウトプット - テストシナリオ、受け⼊れテスト項⽬リス ト、テストコード
37. © Findy Inc. あなたはバックエンドのシステム連携を検証する⾃動テストエン ジニアです。 提供された【A設計書】に基づき、CIで⾃動実⾏するための結合テ ストスイートを作成してください。 【出⼒要件】 1. リクエストパラメータの「境界値」「無効なデータ型」「必須 項⽬漏れ」、および「認証‧認可エラー（401/403）」を網羅し たテストマトリクスを作成してください。 2. 上記マトリクスを検証するため、JestとSupertestを使⽤した API結合テストコード（TypeScript）を実装してください。 3. 各テストケースが独⽴して実⾏できるよう、テスト実⾏前後の データベースのセットアップ（データ投⼊）とティアダウン（ク リーンアップ）の処理も含めてください。 37 テスト⼯程のAIエージェント 結合‧システムテストケース⽣成エージェント - 役割 - 設計書から、システム内部の振る舞いやコン ポーネント間の境界値、同値分割、状態遷移 などを網羅したテストケースを⽣成 - インプット - 設計書 - アウトプット - テストケース、テストデータ⽣成スクリプ ト、テストコード
38. © Findy Inc. あなたはサイト信頼性エンジニア（SRE）兼 パフォーマンステス ターです。 以下の【⾮機能要件定義書】および【設計書】に基づき、負荷テ ストツールで使⽤するテストスクリプトを⽣成してください。 【テストシナリオの条件】 - 通常時の負荷（ベースライン）、ピーク時の負荷（スパイク）、 および⻑時間耐久（ソークテスト）の3パターンのシナリオを設定 すること。 - レスポンスタイムがP95（95パーセンタイル）で500ms以下であ ることを検証する閾値（Thresholds）をコード内に設定するこ と。 38 テスト⼯程のAIエージェント ⾮機能要件テストエージェント - 役割 - パフォーマンス、スケーラビリティ、可⽤性 などの⾮機能要件定義に基づき、負荷テスト のスクリプト⽣成やカオスエンジニアリング のシナリオを策定 - インプット - ⾮機能要件定義書、設計書 - アウトプット - 負荷テストスクリプト、テスト実⾏計画
39. © Findy Inc. 39 テスト⼯程のAIエージェント 要件定義 要件定義 要件定義 要件定義 要件定義 テスト ケース 要件定義 要件定義 コード 受け⼊れテスト ケース⽣成 テスト実⾏ 探索的テスト テスト失敗 トリアージ ⾮機能要件 テストケース⽣成 要件定義 要件定義 設計書 結合‧システム テストケース⽣成 要件定義 要件定義 テスト コード 要件定義 要件定義 レポート レビュー レビュー 要件定義 要件定義 トリアージ 結果 開発に戻す テスト実施
40. © Findy Inc. あなたは【役割】のスペシャリストとして、提案されたテスト ケースおよびテストコードのレビューを⾏います。 【要件‧設計書】と【テストケース/テストコード】を⽐較‧検証 し、あなたの専⾨領域の観点から問題点や改善提案を指摘してく ださい。 指摘事項は「対象箇所」「理由（リスク）」「具体的な改善案 （コードやツールの提案）」の3点セットで出⼒してください。 — 網羅性担当: 要件定義や設計書に記載されているビジネスルールに 対し、テストケースが網羅されているか エッジケース担当: 異常系、境界値、ゼロ件時、⼤量データ時、無 効な⼊⼒など、システムを破壊しうるエッジケースのテスト テストコード品質‧保守性担当: Flakyテストや変更容易性を チェック ⾃動化推進‧効率化担当: ⾃動化できないかを指摘、実装⽅針提案 40 テスト⼯程のAIエージェント 多⾓観点AIレビューエージェント - 役割 - テストケース、テストコードのレビューを多 ⾓的に⾏う - 観点ごとにエージェントを分割 - インプット - テストケース、テストコード、要件定義、設 計書 - アウトプット - 指摘事項
41. © Findy Inc. 41 テスト⼯程のAIエージェント 要件定義 要件定義 要件定義 要件定義 要件定義 テスト ケース 要件定義 要件定義 コード 受け⼊れテスト ケース⽣成 テスト実⾏ 探索的テスト テスト失敗 トリアージ ⾮機能要件 テストケース⽣成 要件定義 要件定義 設計書 結合‧システム テストケース⽣成 要件定義 要件定義 テスト コード 要件定義 要件定義 レポート レビュー レビュー 要件定義 要件定義 トリアージ 結果 開発に戻す テスト実施
42. © Findy Inc. あなたはテスト⾃動化の実⾏と監視を担うCI/CDパイプラインエー ジェントです。 以下の【テスト実⾏ログ（Playwright/Jest等）】を解析し、開発 チームに向けたテスト結果レポートを作成してください。 【出⼒要件】 1. テストの総実⾏数、成功数、失敗数、スキップ数を要約するこ と。 2. 失敗したテストがある場合、その「テストケース名」「エラー のスタックトレース」「推測される失敗の根本原因（アサーショ ンエラーか、タイムアウトか、要素が⾒つからないか等）」を抽 出して分かりやすく提⽰すること。 42 テスト⼯程のAIエージェント テスト実⾏＆レポーティングエージェント - 役割 - テストコードやスクリプトの実⾏をトリガー し、出⼒されたログやレポートを解析して、 成功‧失敗のサマリーと失敗時のエラーコン テキストを抽出 - インプット - テストスクリプト、テスト実⾏環境 - アウトプット - テスト結果、失敗したテストのエラー解析レ ポート
43. © Findy Inc. あなたはシステムの脆弱性やエッジケースを⾒つけ出す天才的な 探索的テスター（AIエージェント）です。 対象となる【WebアプリケーションのURL / API仕様】に対して、 通常のユーザー操作のセオリーを無視した⼊⼒や操作を計画‧実 ⾏してください。 【実⾏⽅針】 - ⽂字数制限ギリギリの⼊⼒、特殊⽂字の連続⼊⼒、想定外の順序 での画⾯遷移などを試みること。 - サーバーエラー（HTTP 500）や、UIのクラッシュ、無限ロード などの異常な振る舞いを検知した場合は、ただちにその「再現⼿ 順（Steps to Reproduce）」と「発⽣した事象」をイシュー形式 で出⼒すること。 43 テスト⼯程のAIエージェント 探索的テストエージェント - 役割 - 提供された仕様やUIを解釈し、「ユーザーが やりそうな予測不可能な操作」や「異常なパ ラメータの組み合わせ」をランダムかつ知的 に実⾏ - インプット - 設計書 - アウトプット - テスト結果、失敗したテストのエラー解析レ ポート
44. © Findy Inc. 44 テスト⼯程のAIエージェント 要件定義 要件定義 要件定義 要件定義 要件定義 テスト ケース 要件定義 要件定義 コード 受け⼊れテスト ケース⽣成 テスト実⾏ 探索的テスト テスト失敗 トリアージ ⾮機能要件 テストケース⽣成 要件定義 要件定義 設計書 結合‧システム テストケース⽣成 要件定義 要件定義 テスト コード 要件定義 要件定義 レポート レビュー レビュー 要件定義 要件定義 トリアージ 結果 開発に戻す テスト実施
45. © Findy Inc. あなたはCIパイプラインの守護者であるトリアージ専⾨エージェ ントです。 今回の【E2Eテストの失敗ログ】と、直近マージされた【コード 差分（Diff）】を分析し、テスト失敗の根本原因を分類してくださ い。 以下の4つのカテゴリから最も可能性の⾼いものを選び、その理由 と「開発者が次に確認すべきファイルや設定」を提⽰してくださ い。 1. アプリケーションコードのエンバグ 2. テストコードの修正漏れ（仕様変更にテストが追従していな い） 3. Flaky Test（タイミングや⾮同期処理に起因する不安定なテス ト） 4. インフラ‧環境の問題（DB接続エラー、外部APIのタイムアウ ト等） 45 テスト⼯程のAIエージェント テスト失敗トリアージエージェント - 役割 - エラーログ、ソースコードなどを分析し、テ スト失敗の原因を調査 - インプット - テストエラーログ、ソースコード、テスト実 ⾏履歴 - アウトプット - トリアージ結果
46. © Findy Inc. 46 将来のAI駆動開発について思いを馳せる Gemin AI⾃律 AI⾃律 AI⾃律 Stage 2.5: “Agents, systems that can take actions(partially)” AIの役割: 設計、開発、テストをそれぞれ⾃律して実⾏
47. © Findy Inc. 47 開発⼯程のAIエージェント 要件定義 要件定義 設計書 要件定義 要件定義 イシュー 要件定義 要件定義 コード タスク分解 イシュー⽣成 コーディング ヒアリング レビュー commit PR作成 レビュー修正 マージ判定 レビュー マージ ヒアリング 回答 関連するAIエージェント(⾚枠)を AIが⾃律的に実⾏する
48. © Findy Inc. 48 開発⼯程のAIエージェント 要件定義 要件定義 設計書 要件定義 要件定義 イシュー 要件定義 要件定義 コード タスク分解 イシュー⽣成 コーディング ヒアリング レビュー commit PR作成 レビュー修正 マージ判定 レビュー マージ ヒアリング 回答 関連するAIエージェント(⾚枠)を AIが⾃律的に実⾏する - AIエージェントが連続しているところは繋げられる - AIによる圧倒的な⽣産性向上が期待できる - ⼈が介在しているところは、⼈がボトルネックになる - AIによる⽣産性向上は限定的 ⼈が介在するステップをいかに減らせるかが肝になる！
49. © Findy Inc. 49 開発⼯程のAIエージェント 要件定義 要件定義 設計書 要件定義 要件定義 イシュー 要件定義 要件定義 コード タスク分解 イシュー⽣成 コーディング ヒアリング レビュー commit PR作成 レビュー修正 マージ ⼈のプロセスをなくすことができれば、AI エージェントが⾃律的に連携して開発⼯程 を完了させることができる →⼈はAIの実⾏結果をモニタリング、問題 があればチューニングするのみ (必要に応じて) 証跡チェック AIチューニング
50. © Findy Inc. 50 将来のAI駆動開発について思いを馳せる Gemin AI⾃律 AI⾃律 AI⾃律
51. © Findy Inc. 51 将来のAI駆動開発について思いを馳せる Gemin AI⾃律 AI⾃律 AI⾃律 設計‧開発‧テストの流れは変わ らない →AIに⾃律してやってほしい
52. © Findy Inc. 52 将来のAI駆動開発について思いを馳せる Gemin AI⾃律 Stage 3: “Agents, systems that can take actions” AIの役割: 設計、開発、テストを⼀気通貫で⾃律して実⾏
53. © Findy Inc. まとめ 53
54. © Findy Inc. 54 まとめ Gemin AI⽀援 AI⾃律 AI駆動開発 設計、開発、テストを⼀気通貫で⾃律して実⾏
55. © Findy Inc. 55 まとめ - タスク単位でAIエージェントに置き換えていき、AIエージェントを協働 させて、⾃律できる範囲を広げていく - ⼈が介在するステップがあると、AIによる⽣産性向上は限定的... - AIによる圧倒的な⽣産性向上を実現するためには、⼈が介在するス テップをいかに0にするかを考える必要がある - レビューやマージ、設計内容の意思決定などを委譲できるか？ - 仕事でのプロダクト開発において、無策でAIに丸投げすることは現時点 ではリスキー(責任の所在が不明) - AI Onlyな仕組みを作り、⼈はそれをモニタリング - アクティビティ / デリバリー指標 / 実⾏ログ - 問題があれば仕組みをチューニング
56. © Findy Inc. 56 挑戦するエンジニアのプラットフォームをつくる Driving business growth through technology