freeeにおける AI を用いた ブラウザ動作確認の自動化の取り組み

freee 技術の日 2026のセッション資料です。

Transcript

1. freeeにおける AI を⽤いた ブラウザ動作確認の⾃動化の取り組み hachi / kacy / sae 2026年10⽉03⽇
2. 債権‧請求書開発部 部⻑ 基盤QA ⼈事労務QA hachi kacy sae 2022年入社 2018 freee入社（サポート） 2012 新卒でSIer入社（PM/ITSM） freee請求書のアプリケーション エンジニア 2025 QAチームに異動（基盤QA） 2022 edtechでQAにキャリア変更 Rubyist. 2024 freeeにjoinしQAマネージャー
3. 開発で⼤事だけど⼀番時間のかかる作業 3
4. 動作確認 4
5. このセッションで得られるもの • AIを使った動作確認を安く、早く、うまくやる⽅法 • Playwright CLI と何が違うのか • freeeでどのように活⽤されているのか
6. よくある開発のフロー コード変更 動作確認 PullRequest 動作確認 マージ Staging デプロイ レビュー 指摘修正 動作確認 Production デプロイ
7. よくある開発のフロー コード変更 動作確認 PullRequest 動作確認 マージ Staging デプロイ レビュー 指摘修正 動作確認 Production デプロイ
8. よくある開発のフロー コード変更 PullRequest 動作確認 レビュー 指摘修正 動作確認が多い！ 動作確認 マージ Staging デプロイ 動作確認 Production デプロイ
9. 動作確認こそAIにやってほしい 9
10. Playwright CLI 10
11. Playwright CLIやAI Agentブラウザ操作ツールの課題 • Playwright CLI ◦ トークンコスト（が⾼くなることがある） ◦ コンテキストをすぐ消費する ◦ 望んだ結果に辿り着かないこともある • AI Agent がブラウザを操作するツール ◦ AIを使わないと動作しない ◦ 再現性
12. Playwright CLIやAI Agentブラウザ操作ツールの課題 • Playwright CLI ◦ トークンコスト（が⾼くなることがある） ◦ コンテキストをすぐ消費する ◦ 望んだ結果に辿り着かないこともある • AI Agent がブラウザを操作するツール ◦ AIを使わないと動作しない ◦ 再現性
13. なぜか • ツールにはプロダクトの知識がない ◦ 適切にコンテキストとして与える必要がある • アクセシビリティツリーを読んでもわからないコンテキスト ◦ ex. このプロダクトの X という機能は設定画⾯で有効にしてからでな いと使えない
14. プロダクトの知識の与え⽅ • ソースコード ◦ ブラウザ操作においては余計な情報が多い • 設計ドキュメント ◦ 開発差分のみについて⾔及されがち • ヘルプページ ◦ 画像など、⼈間寄りのドキュメントになりがち
15. プロダクトの知識の与え⽅ • ソースコード ◦ ブラウザ操作においては余計な情報が多い • 設計ドキュメント ◦ 開発差分のみについて⾔及されがち • ヘルプページ もっといい情報源があるじゃない ◦ 画像など、⼈間寄りのドキュメントになりがち
16. プロダクトの知識の与え⽅ • ソースコード ◦ ブラウザ操作においては余計な情報が多い • 設計ドキュメント ◦ 開発差分のみについて⾔及されがち • ヘルプページ E2E テスト ◦ 画像など、⼈間寄りのドキュメントになりがち
17. freee の E2E 管理 • Playwrightベース • 全てのプロダクトの E2E テスト を⼀つのリポジトリに⼀元管理 • helper や Page Object もそのリ ポジトリで管理している • inowright/inoC はSEQチームが 管理している
18. freee の E2E 管理 • Playwrightベース • 全てのプロダクトの E2E テスト を⼀つのリポジトリに⼀元管理 • helper や Page Object もそのリ ポジトリで管理している この知識と操作を Playwright CLI に組み込めばいい
19. inoC • freee プロダクトの知識と操作を組み込んだ Playwright CLI のラッパー • コマンド‧できること紹介
20. コマンド inoC • freee プロダクトの知識と操作を組み込んだ Playwright CLI のラッパー • コマンド‧できること紹介
21. コマンド inoC • freee プロダクトの知識と操作を組み込んだ Playwright CLI のラッパー • コマンド‧できること紹介 Playwright CLI と同じ
22. inoC inowright-cli help
23. inoC pages の例
24. inoC inowright-cli help
25. inoC helpers の例
26. よくやる使い⽅ • claude code で /inowright-cli:verify-pr skill を実⾏する • PR description の動作確認欄を⾒て、claude がいい感じに動作確認す る • 動作確認がshellスクリプトになり、コメントとしてPRに添付される
27. スキル
28. スキルで作成した Shell Script 例（抜粋） よくやる使い⽅ • claude code で /inowright-cli:create-script skill を実⾏する • inowright-cli を使っていい感じに動作確認をしてもらう • 動作確認がshellスクリプトになる
29. スキルで作成した PR comment 例（抜粋）
30. スキルで作成した PR comment 例（抜粋）
31. inoCまとめ • inoC とは E2E 基盤を組み込んだ動作確認ツール • freeeプロダクトでよくやる動作が helper に、ページ構成が Page Object になっているのでコンテキストを圧縮できる • E2E テスト⾃体が常にメンテナンスされているので陳腐化しない • ユーザーが与えるコンテキストを減らせるので、出⼒のブレを抑えられ る
32. 活⽤事例紹介 32
33. 実際にinoCを使ってみて思ったこと • 4か⽉で12 案件inoCでQA⼯程を回した結果 • 実際に活⽤した結果わかったこと • 安⼼してみんなで使えるようにするために ◦ inowright-cli 信頼性ゲートの今後
34. 私のinoC活用事例と結果（ 4か月で12 案件） 自動実行の成果 実績サマリ 自動実行ケース 約926ケース 自動実行由来のバグ起票＋バグ疑い 9件 ＋ 6件 →QA開始後すぐのバグ検出に繋がった 推定削減工数（ 1ケース20分換算） →エッジケースのバグもしっかり救済 約308時間 自動での修正後確認 4件 34
35. 実際に活用した結果わかったこと 収穫・効果的だった点 (Good) 見えてきた課題・注意点 (motto) 01 リグレッション・ Fix確認の自動化が楽 01 信頼性担保プロセスの未確立による工数超過 02 複数環境の差分比較でデグレード故障を検出 02 不適切な操作（ Act）実行パターンの混入 があった 03 データ駆動テストによる圧倒的な網羅性 03 浅い判定による形骸化リスクがあった 04 自動化対象の選定基準（ Testability）の言語化 04 非同期処理・タイミング依存による偽陽性の発生 35
36. inowright-cli 信頼性ゲートの今後 前提：スクリプト実⾏成功 ≠ テスト完了。2層の強固なゲートで品質を担保する必要あり ① 機械lint（危険記述の⾃動検知） ② AI信頼性レビュー（「意味」の検査） ⽬的：「危険な記述パターン」を機械的に即時ブロック ⽬的：機械チェックのすり抜けをログからAIが読解し 批判的に検証 • エラー放置禁⽌：操作失敗を無視しさせない • 裏ルート(API直叩き)禁⽌：正規UI⼿順を遵守 • 確かめず合格禁⽌：アサーション必須 • セキュリティ保護 • ⽭盾：操作前から合格条件を満たしている • うわべ検査：単なる有無や形式的な合格判定 • ⼿順ズレ、判定すり替えなど... 36
37. 活⽤事例の紹介_2 • ⼤量データ投⼊ • リグレッションテスト＆バグの原因調査
38. 活用事例① : 大量データ投入 【背景】 新プロダクト（AIアシスタント）をユーザさんに操作して頂くために、デモ事業所 が必要になった • 「実際の事業所に近いデータ 」が必要 • データ投入対処のプロダクトが多数 ◦ 会計 / 人事労務 / 請求書 / 工数管理 / 販売 など • データ投入者はデータ投入対象プロダクトの知見は皆無
39. 活用事例① : 大量データ投入 【実施にやったこと】 claude code から自然言語で inoC に指示 • 目的とゴールを伝える ◦ 実在する事業所ぽっいデータの種類 / 規模 など • 参照資料を伝える ◦ プロダクトコード / ヘルプ / など
40. 活用事例① : 大量データ投入 【結果】 年度 総収益 当期純利益 2024 4.01億円 2.72億円 2025 5.36億円 3.66億円 2026 6.23億円 4.12億円 • 取引: 1,416 • 取引先: 1,859 / 部門: 127 / 品目: 154 / メモタグ: 98 • ファイルボックスの証憑: 299 • 帳票（請求書ほか6種）: 766 • 従業員: 105 • 勤怠: 約1万
41. 活用事例② : リグレッションテスト＆バグの起票 【背景】 AIアシスタントで「エンドポイントを特定する仕組み」を変更 ↓ 「AIアシスタントで処理可能な全てのエンドポイントを叩ける 」ことを 確認するリグレッションテストが必要
42. 活用事例② : 挙動確認＆バグの起票 【AIアシスタントの特色】 ◦ チャットの履歴が残る ◦ チャットの履歴に下記が残っている ▪ どんな指示をして ▪ どんなエラーが起きたか
43. 活用事例② : 挙動確認＆バグの起票 【実施にやったこと】 以下を inoC に伝える • 正確なデータを作成 / 取得したいわけではない ▪ パラメータは必須項目のみで良い ▪ 値は適当に決めて良い • 下記の情報を知りたい ◦ 実行したエンドポイント ◦ 実行結果（httpコード） ◦ チャットのsession_id
44. 活用事例① : 大量データ投入
45. 活用事例② : 挙動確認＆バグの起票 【失敗したエンドポイントに関する調査】 ◦ ${チャットのsession_idl} を渡し、失敗の原因調査を依頼 ◦ （通常のバグ報告のフォーマットを参照させた上で）フォーマットに 則って調査結果をJiraに起票するように指示
46. やってみてわかったこと 最初から完璧に動かすのは厳しいが、以下の手順を踏むとスムーズ ◦ 雑な指示で動かす => 意図通りはない挙動を軌道修正 ◦ 意図通り動いたら大量・並行処理（10〜15並列） 正しく動くための情報を参照させる ◦ ヘルプ / プロダクトのリポジトリ ◦ いったん人が手で動かして記憶・記録させる トークンと時間はそれなりに消費する ◦ 大量データ / 繰り返し実行する処理に対しては非常に有用 ◦ 簡単な挙動は手でやった方が早い