ＫＩＮＴＯテクノロジーズ株式会社

https://www.kinto-technologies.com

愛知県

SeleniumConf & AppiumConf 2026登壇記複雑なシステムの品質を、どう設計するか。ーAIとテスト自動化で実践する、品質保証の仕組み

竹野光瑠, 呂文佳他1人

コーポレート・スタッフ, その他エンジニア

竹野光瑠

ＫＩＮＴＯテクノロジーズ株式会社 / コーポレート・スタッフ

フォロー

呂文佳

フォロー

パンヌウェイ

フォロー

on 2026/07/31

KINTOテクノロジーズでは、QA・テスト自動化の領域において、新しい技術やAIツールの活用に積極的に取り組んでいます。

2026年5月、スペイン・バレンシアで開催された「SeleniumConf & AppiumConf 2026」に、QAエンジニアの呂さんとパンヌさんが登壇しました。日本企業からの登壇者としては、同カンファレンスで唯一の参加となりました。

CFP（登壇応募）の採択率が5〜10%ともいわれるなか、二人は約8カ月の準備期間を経て、イベント全体で300〜400名が参加するカンファレンスに登壇しました。発表当日は約100名が集まる会場で、40分間の英語セッションを実施しました。発表したのは、複雑なシステムを対象としたテスト自動化や、AIツールを活用したQA業務の改善についてです。

その挑戦の背景には、日々の業務で積み重ねてきた自動化の取り組みと、「まずやってみよう」というKINTOテクノロジーズのQA組織の文化がありました。

国際カンファレンスへの挑戦を通じて得た学び、現地での交流、そしてAI時代における品質保証のあり方について、二人に話を聞きました。

当日の登壇の様子は、以下の動画からご覧いただけます。

▍呂さん　Quality Engineering G　Webチーム
QAエンジニアとして5〜6年の経験を積み、大手企業のプロジェクトでテスト自動化にも携わる。現在はWebチームで、Web系システムのリグレッションテスト自動化を担当している。

▍パンヌさん　Quality Engineering G　Mobileチーム
Java、C#、C++、PHPなどさまざまな言語を用いた開発や、Androidアプリ開発に約4年間携わった後、KINTOテクノロジーズでQAエンジニアへ転身。トヨタウォレットやグローバル向けアプリケーションの検証を担当している。現在はAppiumを用いたモバイルテスト自動化、CI/CD環境の構築、AIツールの活用に取り組んでいる。

「世界最高峰」の舞台で見えた、共通の課題

――今回登壇されたSeleniumConf & AppiumConf 2026は、どのようなカンファレンスだったのでしょうか。

呂さん：SeleniumConfはWeb系の自動化ツール、AppiumConfはスマホアプリの自動化ツールを中心とした、テスト自動化領域において長い歴史を持ち、世界各国からエンジニアが参加しています。CFPの採択率は5〜10%程度。世界中のトップエンジニアが応募する中から選ばれるのは、大変な名誉でした。最終的な発表者は45名、現地の参加者は300〜400名ほどでした。

パンヌさん：会場はバレンシアのマリーナにあるVeles e Ventsという建物で、地中海を臨みながらセッションの合間にスピーカーやエンジニアと気軽に話せる、とても開放的な雰囲気でした。20カ国以上からエンジニアが集まっていました。国や会社の規模が異なっていても、「自動化テストのメンテナンスが大変」「CI/CDをもっと高速化したい」といった課題は共通しており、強く印象に残りました。発表後には「うちも同じ課題を抱えている」「どこから始めたのか」といった具体的な質問を多くいただきましたし、「日本の自動車業界のQA文化はどうなのか」と聞かれる場面もありました。

――現地では発表以外の交流もあったそうですね。

呂さん：休憩時間やランチタイムに参加者同士で話す機会がたくさんありました。各セッションの後には5〜10分の休憩が挟まれていて、その場で発表者に直接質問できる雰囲気です。特に印象に残っているのは、登壇前日にあった「スピーカーだけが集まるディナー」です。45名の発表者が世界各国から集まって一気に情報交換できた、貴重な機会でした。

――他の発表者の取り組みで印象に残ったものはありましたか。

呂さん：アメリカのソニー支社で働く日本人の方が、PS4のテストについて発表していました。内容を完全に理解できたわけではありませんが、スマートフォンアプリにとどまらず、組み込み系の知識まで踏まえた発表で、視野の広さに驚きました。

パンヌさん：私はスペインの方の発表が印象的でした。フィーチャーフォン向けの自動化スクリプトを作っていて、コマンドを一行入力するだけで一連の処理を全て実行できる仕組みになっていたんです。45名の発表者が集まれば、それぞれ全く違う領域の工夫があって、聞いているだけでも刺激になりました。

呂さん：ちなみに、今回のカンファレンスに日本から参加していたのはKINTOテクノロジーズだけでした。日本人の方はいましたが、アメリカで働いている方だったので。そう考えると、あの場に日本企業として立てたこと自体、かなり名誉なことだったのだと思います。

――海外のエンジニアと話す中で、QAという職種の捉え方について感じたことはありますか。

呂さん：海外では、QAは開発チームから独立した職種ではなく、開発チームの一員として、開発と一緒にソフトウェアの品質を管理しているケースが多い印象でした。私は、QAはもっと開発チームに関わり、開発の視点からシステムを検証すべきだと考えるようになりました。自動化スクリプトを書く際にも、より多様な視点からのE2Eシナリオを考慮する必要があると感じています。

「挑戦してみたら？」の一言から始まった、8カ月の準備

――最初に登壇の話を持ちかけられた時、どんな気持ちでしたか。

パンヌさん：正直に言うと、嬉しさよりも驚きと不安のほうが大きかったです。私はミャンマー出身で、日本語と英語はできますが、どちらもネイティブではありません。国際カンファレンスの舞台で40分間、一人で英語のセッションをやるというのは、それまでのキャリアで想像もしていませんでした。ただ同時に、「自分たちが日々やっていることは、外の世界でも通用するんだろうか」という純粋な好奇心もありました。KINTOテクノロジーズのQuality Engineering Gのモバイルチームで自動化テスト実装者は2名体制で、128のテストシナリオを運用しながら、AIツールの活用にも試行錯誤で取り組んできました。その経験に価値があるのか、国際的な場で試してみたいという気持ちが、最後は不安を上回りました。

呂さん：私は、ゼロから構築した自動化フレームワークや、回帰テスト、テストデータ生成の部分について経験を発表できるのではないかと感じました。成功事例だけでなく、失敗経験やそこから得た学びも共有できる。話せる内容はたくさんありそうだと思いました。

――実は、登壇のきっかけは社内の方の一声だったとか。

パンヌさん：はい、社内のメンバーに「出してみたら？」と声をかけていただいたのがきっかけです。そこから募集ページに載っていたキーワードを参考に、自分たちで内容を考えてCFPを提出しました。発表内容についても、声をかけてくれたメンバーから「内容が良くても、印象に残る数字や結論をはっきり出さないと伝わらない」というアドバイスをいただき、これは登壇準備の中でも大きな指針になりました。

――CFP応募から登壇までの約8カ月、準備はどのように進めましたか。

パンヌさん：スライド作成やスピーカースクリプトの練り込み、想定Q&Aを50問用意したり、発音しやすい英語表現を一つひとつ選び直したりと、これまでのキャリアの中でも、特に密度の高い準備期間でした。

呂さん：私は隙間時間を使って英語のスピーチを練習しました。AIの音声会話モードを使って、発音や話すテンポを評価してもらい、少しずつ改善していきました。

――8カ月を振り返って、一番「成長した」と感じた瞬間はいつでしたか。

呂さん：英語力と、発表時の緊張への対応力が向上したと感じます。特にプレゼンテーションを終えたその瞬間、「やり切れた」という実感とともに成長を感じました。

パンヌさん：私が一番成長を感じたのは、本番のステージではなく準備の途中でした。最初は完璧な英語にこだわってスクリプトを書いていたのですが、読み返した時に「これは自分が素で喋る言葉ではない」と気づいたんです。そこから、難しい単語を避けて、発音しやすいシンプルな表現に一語ずつ選び直す作業に切り替えました。その過程で腹落ちしたのは、聴衆が求めているのは完璧な英語そのものではなく、現場で得たリアルな経験だ、ということでした。試行錯誤してきた飾らないストーリーこそ、自分にしか語れない強みだと信じられるようになったことが、8カ月間で得た一番大きな成長でした。

「メンテナンスに追われる悪循環」から始まった、テスト自動化への挑戦

――お二人がQA・テスト自動化の領域に進んだ背景を教えてください。

呂さん：これまでQAエンジニアとして5〜6年ほど勤務し、様々な大手企業の現場で自動化にも取り組んでいました。KINTOテクノロジーズのWebチームでは、2週間に1回、非常に複雑な回帰テストを実施する必要がありました。車種ごとの契約について、顧客の申請からバックエンドでの審査まで、一連のプロセスを繰り返しテストする必要がありました。当時これを自動化テストなしで対応するのは、あまりにも非効率だと感じていました。

パンヌさん：私はもともと、開発エンジニアとしてキャリアをスタートしました。前職でも単体テストや総合テストを担当した経験があり、その中でテスト実施そのものに興味を持ったのがきっかけです。KINTOテクノロジーズに入社してから、開発経験があるからこそ「どこにバグが潜みやすいか」「どう設計すればテストしやすいか」が見えることに気づきました。

――品質保証に対する考え方が変わった転機はありましたか。

パンヌさん：128のテストシナリオのフル実行に12時間かかり、開発チームへのフィードバックが間に合わなくなった時です。テストの量を増やすだけでは、品質を安定して支えられないと痛感し、Appiumフレームワークの再設計とCI/CDパイプライン構築でフィードバック速度を約30%改善しました。その後AIツールも導入しましたが、任せすぎてフレーキーテスト（不安定なテスト）が増えた失敗も経験しています。そこで学んだのは、「何をもって品質とするか」の判断基準がなければ、どんなツールも逆効果になるということでした。

呂さん：私が最初にフレームワークを立ち上げた頃、チーム内のメンバーはほとんど自動化の経験がなく、プログラミングの知識もありませんでした。そこで、全員がスクリプトの内容を理解しやすいように、長いワークフローを機能ごとに分割して、ひとつひとつの小さなモジュールにしました。個人技にせず、チームで運用できる状態を意識していました。

AIによって変わる、テスト自動化とQAエンジニアの役割

――取り組まれているPlaywright×AI、Appium×AIでは、どんな課題を解決しようとしていたのでしょうか。

呂さん：最初は、Excel VBAのような外部プログラムとの連携や、AWS S3へのファイルアップロードなどを実現するために、TypeScriptで書いていたスクリプトをすべてPythonに書き換える必要がありました。そこで、AIを活用して、TypeScriptからPythonへの書き換えを支援させました。大量のスクリプトにある重複部分を一括で修正したい時にも、AIを使うことで、修正対象となる箇所を抽出し、複数のスクリプトをまとめて修正できるようになりました。

パンヌさん：一番の課題は、テスト自動化の「メンテナンスに追われる悪循環」でした。128シナリオまで増える中、UIが変わるたびにテストコードの修正に追われ、QAエンジニア2名では新しいテストを書くより修正に時間を取られる状態でした。そこで、Appiumフレームワークをモジュラー構成に再設計してメンテナンスコストを下げること、AIツールで人手に頼っていた作業を効率化することの両輪で解決を目指しました。経験の浅いメンバーでも成果を出せるよう、GitHub Copilotで記述のハードルを下げつつ、AIの出力をそのまま信頼しないためのバリデーションチェックリストも整備し、最終判断は人間が行うというルールをチームで共有しています。

――AIを活用する中で、「働き方が変わった」と実感した瞬間はありましたか。

パンヌさん：一番実感したのは、Claudeでログ分析を始めた時です。失敗ログの解析に数時間かかっていた作業が大幅に短縮され、その分をテスト設計や品質基準の検討に使えるようになりました。QAの仕事の重心が、単純作業から意思決定へ移っていく感覚がありました。

呂さん：最近は、別のメンバーが作ってくれたAIエージェント（RAG）も活用しています。社内に蓄積された仕様書やナレッジをAIがデータベースのように管理していて、質問すると検索・回答生成までしてくれる。以前はキーワード検索で探すのに時間がかかっていましたが、必要な情報にたどり着くまでの時間が短くなり、働き方そのものが変わったと感じています。

――今も現場で向き合っている課題はありますか。

呂さん：Webチームでは、リグレッションテストが単一システムではなく、フロントエンド・バックエンドなど5〜6のシステムを横断するケースが多く、日々のリリースや更新のスピードにスクリプトの更新が追いつかないことがあります。知らないうちにスクリプトが古くなり、テストが正しく実施できていない、ということも起きます。CI/CDが整えば自動検知・自動修復もできますが、最近仕様が変わったシステムとの連携にはまだ時間がかかりそうで、現在まさに取り組んでいるところです。

パンヌさん：アプリチームでは画像比較の精度に課題がありました。実施端末によって画角が変わってしまうため、単純な比較では正確に判定できなかったんです。そこで直近3回分の実施結果をベースラインとして設定し、今回の結果と比較する方式に変更しました。ただ、傷や欠けなど特殊なケースの画像比較はまだ難しく、対応できる種類を限定している段階で、完全な解決はこれからです。

――一方で、AI時代でも人間が担うべき役割はどこにあると考えていますか。

呂さん：仕様が複雑な案件では、AIだけではまだ解決になりません。人間が多くのテスト観点を考える必要がありますし、更新が多すぎる案件では、AIエージェントが情報を読み込んでもまだ足りないケースがあります。

パンヌさん：AIにテストデータや期待値画像を生成させることもありますが、その結果は必ず人間がレビューする必要があります。1〜2カ所ほど誤りが含まれることがあるので、最終的な判断には人間の目が欠かせません。

「まずやってみよう」が根づくQA組織

――KINTOテクノロジーズのQA組織ならではの特徴を教えてください。

呂さん：2点あると思います。1つは、システムの内容そのものが非常に複雑なこと。複数のシステムを横断する長いリグレッションテストは、他社でもあまり聞いたことがありません。アジャイルで短期間に多くの改善やリリースを行うため、小さな変更でも全体を理解していないと品質を保証できない難しさがあります。もう1つは、新しい技術やツールをすぐに導入できることです。Devin AIのように、利用方法によってはコストの大きいツールについても、会社が検証の機会を用意してくれました。コードレビューや指摘の質が高く、業務効率を大きく向上させてくれています。

パンヌさん：私が感じるのは、「まずやってみよう」という文化が根づいていることです。AIツールの導入もSeleniumConf & AppiumConfへの登壇も、チームや会社が挑戦を後押ししてくれたからこそ実現できました。小さなチームだからこそ、スピード感を持って新しいことに取り組めるのが一番の強みだと思います。また、QAが独立した組織として複数のプロジェクトに関わっているため、さまざまな領域の経験を積めることも特徴です。アプリもWebも経験できますし、手動テストと自動テストの両方に関われ、検証だけでなく設計や企画の部分も学べる環境です。

――チーム内で新しい情報はどのように共有されているのでしょうか。

呂さん：リーダーが新しい情報をいち早く見つけて、すぐにチームに共有してくれます。提案するとすぐに試したいという人もいますが、一方で情報共有されても様子を見る人もいます。安全策を優先したい気持ちもよく分かるので、それぞれのペースがあっていいと思っています。誰かが新しいものを取り入れて成果を出せば、自然と周りにも広がっていく。そんな流れが今のチームにはあると感じます。

――AIと共存していく上で、エンジニアとして意識していることはありますか。

呂さん：まず積極的にAIの知識を勉強することが大事だと思います。自分の知見の外にあるものは想像できないので、知見を広げること自体が重要です。そのうえで、AIが得意な領域と得意ではない領域を事前にリストアップして整理し、それを踏まえて任せる範囲を判断するようにしています。

パンヌさん：どのAIツールにどんな特徴があるかを自分自身が理解し、どの業務のどの作業に使うかを人間が判断することが大事だと思っています。AIについての知識を自分の中に持っておくこと自体が、これからのQAには欠かせないスキルになると感じています。