【イベントレポート】Autify Meetup 2025/09 – 事例から学ぶ自動化設計の勘所

はじめに
2025/9/11(木) に弊社東日本橋オフィスにて、2025年3回目の「Autify Community Meetup」を開催しました!
最新機能の発表から、ユーザー企業によるリアルな事例、そして参加者同士の自由なディスカッションまで、盛りだくさんの内容となった今回。その模様をお届けします。
受付でHattyがお出迎え
なお、参加者の方によるレポートもございますので、こちらも併せてご覧ください!
【イベント登壇レポート】半年でシナリオ数2.5倍、安定稼働率98%!TOKIUM QAチームの「Autifyテスト設計術」
Autify 製品アップデート
最初のセッションでは、Autifyのプロダクトマネージャーである浅野さんから、各製品のアップデートについて発表がありました。
今年7月に発表されたばかりの新製品である Autify Nexus では、自然言語ステップの追加やAIによるカバレッジレポート生成といったAI機能の強化に加え、ワークスペース変数・シークレット機能・シナリオの過去バージョン復元など、様々な機能のアップデートがありました。
特に注目を集めたのは自然言語ステップです。「AIに自然言語でテスト内容を指示できる」という、これまでのレコードアンドリプレイ型とは一線を画すステップですが、一方で動作が決定論的でない(実行のたびに動作が変わる可能性がある)ため、今までのテスト自動化と同じ感覚で使ってしまうとちょっと危険かも……?
NexusにおけるAI機能は「AI Everywhere」をコンセプトに、テストプラン作成から結果分析までAIエージェントで実行可能にしていくというビジョンも示されました。
その他、NoCode Web にはPDFエクスポート機能の搭載、NoCode Mobile にはローカルテスト機能、JavaScriptステップの追加といった進化が加わりました。
また、NoCode Mobileでは現在自然言語によるアサーションを開発中。こちらはNexusの自然言語ステップにちょっと似ていますが、自然言語で期待値を与えると、画面がそのように表示されているかをAIが確認してくれるという画期的なものになっています。
各製品のアップデートについてはデモウェビナーでも紹介予定ですので、ご興味のある方はぜひご参加ください!
最新のテストAIエージェントも紹介!Autify Nexusデモウェビナー
株式会社TOKIUM 富田さま「複雑化・巨大化するプロダクトに立ち向かう!私たちのAutifyテスト設計術」
ユーザー事例セッションでは、株式会社TOKIUMの富田さま にご登壇いただきました。
プロダクトの拡大により自動化とメンテナンスが追いつかず、不具合が発生していた課題をどのように改善したかを共有していただきました。
- 状態遷移テストを取り入れた設計の見直し
- テスト容易性の改善による自動化カバレッジの向上
- 自動化チームの再編成
- スプレッドシートによるシナリオのドキュメント化
- 環境を横断して運用できるシナリオ共有の工夫
結果として、シナリオ数は半年で30件から80件に増加、安定稼働率は70%から98%に改善。
「Autifyは社内にとって貴重な資産になった」と語り、今後開発が加速する経理AIエージェントの品質担保にも力を入れていきたいと語っておられました。


Autify 村穂さん「ベストプラクティスを適用するとシナリオはどう変化するのか」
続いて登壇したのは、Autify Pro Service チームの村穂さん。
テーマは「自動化を前提に設計するマインドセット」です。
手動テストをそのまま置き換えるのではなく、動的データ生成や事前処理/事後処理の設計を行い、可読性の高いシナリオに仕上げることが、結果的に品質とメンテナンス性を高めるという考え方が紹介されました。
村穂さんは、テスト設計で最も重要なのは「そのアサーションやシナリオが何を証明するのかを明確にすること」だと強調しました。
- 「退会するボタンがあることを確認」では意図が不明瞭 → 「ログイン済みであることを確認」とすれば目的が伝わる
- 「会員登録画面の一連操作」といった表現よりも、「会員登録後に宿泊予約が取れること」といったストーリー形式の方が理解しやすい
- シナリオ名はステップの羅列から付けるのではなく、シナリオがPassすることで何が達成されるのかを表すべき
「シナリオを第三者や未来の自分が理解できる形にすることが、チームの生産性を守るカギになる」というメッセージは、多くの参加者の共感を呼びました。
フリーディスカッション:自動化におけるテスト設計とは?


最後は毎回恒例、参加者同士でのディスカッションタイム!テーマは 「自動化におけるテスト設計とは?」 でした。A〜Cまでの3グループに分かれて、Autifyのメンバーも交えてディスカッションを行いました。各グループに同席したAutifyメンバーのメモ書きから一部抜粋してご紹介します。
Aグループのディスカッションから
テスト設計における基準のようなものが各社にあるか話を聞いたところ、
- 基準があるお客様
- 案件毎に最初にテストすること・しないことを決めてテスト設計を開始する
- 基準はないが、QA同士でレビューをし合う
というふうに各社ポリシーが異なるようでした。
また、チームでAutifyを使う上で、不便に感じるところをお伺いしたところ、
- 複数バージョン管理が出来ないのが不便
- 自動化したシナリオのレビューに関するやり取りは全てスプレッドシートベースで行っている
- 実際のテストのうち、Autifyのどのステップにあたるかは、スプレッドシートで管理している
など、Autifyだけでは完結しない業務がたくさんあることを教えていただきました。 その他観点出しの壁打ちをAIと実施したりなどの話も出ておりました。
Bグループのディスカッションから
現場に根ざした課題や気づきが共有されました。
- 手動と自動を分けて考えている現状
スプレッドシートでカバレッジを整理し、機械的にできる部分はできるだけ自動化している。 - プロセスの流れ
「要件定義 → テスト計画 → 観点出し → ケース作成 → 実行 → バグ分析」というワークフローを基本としつつ、必要に応じてループしている。 - 手動テスト先行の文化
手動テストで回したものを自動テスト化しており、「最初から自動テストを前提に設計する発想」がまだ根付いていないことに気づいた。 - 自動化と手動の違いに対する気づき
「手動テストを自動化する」のと「最初から自動化を前提に設計する」のはまったく異なる、という実感が共有された。 - QAチーム不在の環境
開発がテストも兼務しており、各タスクやリリースごとのテストはどうしても属人化しやすい。そこから自動化をどう設計に取り込むかが課題。 - 長期的なプロセス像
外部設計から単体設計・実行、トランザクション設計、シナリオ設計へと進むプロセスを、システムの規模やリリースサイクルに応じて1年単位で回しているケースもある。
Cグループのディスカッションから
- テストの設計と、自動テストの設計はどう違うのか
- テストの設計書と、自動テストの設計書は、分けて作るのか。そもそもどのように作るのか(何をどこまで書くか。どのような表現方法が適しているのか)
- 自動テストの設計のアウトプットはどんなものになるのか
- プロダクトのディレクションやQAやプロジェクトリードなどを全て兼任してしまっている状態で、もっと他の人に振りたいのだが、うまくできない
まとめ
今回は10名弱といつもより少なめの人数での実施になったのですが、その分濃いディスカッションが出来ました!プロダクトのアップデートもあって、盛りだくさんの内容となりましたね。
次回のミートアップは12/11(木)を予定しています!忘年会がてら気軽に遊びに来てください。それでは、👋〜
登壇いただいたTOKIUMの富田様と石川様
ご参加の皆さんと。