はじめに こんにちは！ KINTOテクノロジーズのデジタル戦略部DataOpsグループ所属の三浦です。 普段は、社内のデータ分析基盤の開発・保守・運用に加え、Google Analytics 4（以下、GA4）やGoogleタグマネージャー（以下、GTM）を利用した、Webサイトのアクセス解析や計測環境の整備を担当しています。 WebサイトでGA4やGoogle広告を計測する場合、一般的にはGoogleドメインからGoogleタグを読み込み、Googleドメインへ計測リクエストを送信します。 一方、ブラウザのプライバシー保護機能や広告ブロッカーなどの影響により、Googleタグの読み込みや計測リクエストがブロックされ、イベントが欠損することがあります。 今回、この課題への対応として、既存のAmazon CloudFrontを利用し、Googleタグゲートウェイを導入しました。 本記事では、Googleタグゲートウェイを導入した背景や構成、社内での役割分担、検証時に確認したポイント、導入後に確認できた効果について紹介します。 本記事の対象者 本記事は、以下のような方を対象としています。 GTMやGA4を利用したWebサイトの計測を担当している方 Googleタグゲートウェイの導入を検討している方 Amazon CloudFrontをCDNとして利用している方 本記事では、CloudFrontの細かな設定手順ではなく、導入時の考え方や進め方、検証内容を中心に紹介します。 Googleタグゲートウェイ導入の背景と概要 背景 当グループでは、Webサイトの利用状況や広告施策の成果を把握するため、GTMを利用してGA4やGoogle広告などの計測タグを配信しています。 通常の構成では、WebサイトからGoogleドメイン上のGoogleタグを読み込み、計測したイベントをGoogleドメインへ送信します。 通常のGoogleタグ配信の構成 しかし、Googleドメインへの通信は、ブラウザのプライバシー保護機能や広告ブロッカーなどによって、制限されることがあります。 計測タグや計測リクエストがブロックされると、ユーザーが実際にページを閲覧したり、コンバージョンしたりしていても、GA4やGoogle広告へイベントが送信されません。 その結果、以下のような課題が発生する可能性があります。 GA4で確認できるイベント数が、実際の発生件数より少なくなる コンバージョン数が正しく計測されない Webサイトの施策評価に使用するデータが不完全になる 広告経由の成果を正しく評価できない 広告配信の最適化に使用するコンバージョンデータが不足する 特に広告配信では、計測したコンバージョンデータが、自動入札や配信対象の最適化に利用されます。 そのため、イベントの欠損は、レポート上の数値が少なくなるだけでなく、広告配信の学習や最適化にも影響する可能性があります。 実際に対象サイトでは、GA4で計測しているコンバージョンページのイベント数と、バックエンドのデータベースに保存されているコンバージョン件数に差がありました。 もちろん、GA4とバックエンドのデータベースでは、計測の仕組みや集計条件が異なります。 そのため、数値が完全に一致するものではありません。 一方で、差が大きい状態では、実際に発生したコンバージョンの一部をGA4で取得できていない可能性があり、広告施策やサイト改善を評価するうえで課題となっていました。 そこで、Googleタグへの通信を自社ドメイン経由に変更し、タグやイベントがブロックされる影響を軽減することを目的として、Googleタグゲートウェイを導入しました。 概要 対象のWebサイトでは、CDNとしてすでにAmazon CloudFrontを利用していました。 そのため、新たにサーバーを構築するのではなく、既存のCloudFrontを利用してGoogleタグゲートウェイへの通信を中継する構成を採用しました。 導入後の構成は以下のとおりです。 flowchart TB Browser[Webブラウザ] --> Domain[Webサイトと同じ自社ドメイン] Domain --> CF[Amazon CloudFront] CF -->|通常のWebコンテンツ| Origin[既存の配信先] CF -->|Googleタグゲートウェイ用のパス| GTG[Googleタグゲートウェイ] GTG --> GA4[GA4・Google広告など] Webサイト上にGoogleタグゲートウェイ用のパスを用意し、そのパスへの通信をCloudFrontからGoogle側へ転送します。 ブラウザから見ると、Googleタグの読み込み先や対象となる計測リクエストの送信先が、Googleドメインではなく、Webサイトと同じ自社ドメインになります。 Googleタグゲートウェイ導入前後の構成図 要素技術・アーキテクチャの紹介 ここからは、今回の導入で利用したGoogleタグゲートウェイとAmazon CloudFrontについて紹介します。 Googleタグゲートウェイとは？ Googleタグゲートウェイ（ Google tag gateway for advertisers ）は、自社が管理するCDNやロードバランサーなどのインフラを利用して、Googleタグを自社ドメイン経由で配信する仕組みです。 通常はGoogleドメインから読み込まれるGoogleタグを、自社ドメイン上の特定のパスから読み込めるようにします。導入前後の経路の違いは、前述の「 概要 」節の構成図のとおりです。 Googleタグゲートウェイでは、GA4のイベント設計や、GTMコンテナ内のタグの処理内容を大きく変更するのではなく、Googleタグへアクセスする経路を変更します。 そのため、既存のGTMコンテナ内のタグ、トリガー、変数などを維持したまま導入できます。 Amazon CloudFrontとは？ Amazon CloudFront は、AWSが提供するCDNサービスです。 Webサイトのコンテンツを利用者に近い拠点から配信することで、表示速度や可用性の向上に利用されます。 CloudFrontでは、アクセスされたURLのパスに応じて、異なる配信先へリクエストを振り分けられます。 今回はこの仕組みを利用し、Googleタグゲートウェイ用のパスへの通信のみを、Google側へ転送するようにしました。 サーバーサイドGTMとの違い Googleタグゲートウェイと混同しやすい仕組みに、サーバーサイドGTMがあります。 サーバーサイドGTMでは、サーバー用のGTMコンテナを構築し、サーバー側で計測リクエストを処理し、送信先を制御します。 一方、Googleタグゲートウェイは、Googleタグの読み込みや対象となる計測リクエストを、自社ドメイン経由に変更する仕組みです。 観点 Googleタグゲートウェイ サーバーサイドGTM 変更するもの Googleタグへの通信経路 計測リクエストの処理・送信先 追加で必要なもの CDN / ロードバランサーの設定 サーバー用GTMコンテナと実行環境 既存のWeb用GTMコンテナ そのまま利用 サーバー用コンテナ向けの設定追加が必要 今回の目的は、既存のGTM構成を維持しながら、Googleタグへの通信経路を変更することでした。 そのため、新たなサーバー用GTMコンテナは構築せず、既存のCloudFrontとWeb用のGTMコンテナを利用する構成を採用しました。 導入の進め方 各担当者の役割分担 今回の導入では、計測担当だけでなく、インフラ担当、プロダクトチームのサイト管理者と連携して進めました。 大きな役割分担は以下のとおりです。 DataOpsグループ・計測担当 Googleタグゲートウェイの導入目的と要件の整理 対象ドメインや対象環境の整理 Googleタグゲートウェイ用パスの検討 ブラウザやGA4を利用した動作確認 既存の計測への影響確認 導入前後のイベント数の比較 インフラ担当 CloudFrontへのGoogleタグゲートウェイ用設定の追加 Googleタグゲートウェイへの転送設定 検証環境と本番環境への設定反映 必要に応じたCloudFrontやWAFの調査 プロダクトチーム・サイト管理者 Webサイトに設置しているGTMコードスニペットの差し替え 検証環境と本番環境へのリリース Googleタグゲートウェイは、GTMやGA4だけで完結する機能ではありません。 CDNなどの配信基盤と、Webサイトへ設置しているGTMコードスニペットの両方に対応が必要です。 そのため、導入前に各担当者の作業範囲と、検証時の確認項目を整理しました。 GTMコンテナ側の設定は変更しない Amazon CloudFrontを利用した今回の構成では、GTMコンテナ側でGoogleタグゲートウェイ用の設定変更は行っていません。 既存の本番用GTMコンテナを、そのまま利用しました。 変更したのは、Webサイトに設置されているGTMコードスニペットの読み込み先です。 変更前 GoogleドメインからGTMコンテナを読み込む 変更後 自社ドメイン上のGoogleタグゲートウェイ用パスから 同じGTMコンテナを読み込む GTMコンテナ内のGA4タグ、Google広告タグ、トリガー、変数などは変更していません。 GTMコードスニペットの差し替えについては、Webサイトを管理しているプロダクトチームへ依頼し、検証環境と本番環境へ反映してもらいました。 通信経路のみを変更する構成だったため、既存の計測設計への変更を抑えて導入を進められました。 検証用GTMコンテナは作成しない 今回の導入では、Googleタグゲートウェイの検証用に、新しいGTMコンテナは作成しませんでした。 実際に本番環境で利用しているGTMコンテナを、検証環境でもそのまま利用しました。 導入の流れは以下のとおりです。 検証環境のCloudFrontへ設定 検証環境のGTMコードスニペットを差し替え 検証環境で動作確認 本番環境のCloudFrontへ設定 本番環境のGTMコードスニペットを差し替え 本番環境で動作確認 先に検証環境のCDNへGoogleタグゲートウェイの設定を追加し、プロダクトチームに検証環境のGTMコードスニペットを差し替えてもらいました。 そこで問題がないことを確認した後、本番環境のCloudFront設定とGTMコードスニペットを変更しました。 本番用のGTMコンテナをそのまま使用したことで、検証用コンテナと本番用コンテナの間に設定差分が発生しません。 実際に本番で使用するタグ構成のまま、通信経路の変更による影響を確認できました。 検証時のポイント Googleタグが自社ドメインから読み込まれているか 最初に、ブラウザの開発者ツールにあるNetworkタブを利用し、GTMコンテナの読み込み先を確認しました。 導入前はGoogleドメインから読み込まれていたGTMコンテナが、導入後は自社ドメイン上のGoogleタグゲートウェイ用パスから読み込まれていることを確認します。 導入前 https://www.googletagmanager.com/... 導入後 https://www.example.com/<Googleタグゲートウェイ用パス>/... 読み込み先だけでなく、HTTPステータスコードが正常であることや、ページ表示時にGTMコンテナが問題なく実行されていることも確認しました。 既存のタグがこれまでどおり発火するか Googleタグの読み込み先を変更しても、GTMコンテナ内のタグやトリガーが、これまでどおり動作する必要があります。 GTMのプレビューモードを利用し、以下を確認しました。 ページ表示時に必要なタグが発火すること クリックなどのイベントタグが発火すること GA4へ必要なイベントが送信されること イベントパラメータの値が導入前と変わっていないこと 同一イベントが重複して送信されていないこと 今回、GTMコンテナ内の設定自体は変更していません。 そのため、通信経路を変更したことで、既存のタグ発火やイベント送信に影響が出ていないかを中心に確認しました。 GA4でイベントを確認できるか ブラウザ上でタグが発火していても、最終的にGA4へイベントが到達していなければ、計測は成立しません。 GA4のDebugViewやリアルタイムレポートを利用し、以下を確認しました。 ページビューが送信されていること 主要なイベントが送信されていること イベントパラメータが欠損していないこと page_location などの値が正しいこと コンバージョンページのイベントが送信されていること 導入前と比較して、想定外の重複や減少がないこと Googleタグゲートウェイを経由した場合でも、GA4上では、これまでと同じイベント名やパラメータとして確認できます。 SPAの画面遷移も確認する 対象サイトには、ページ全体を再読み込みせずに画面を切り替えるSPA形式のページもありました。 SPAでは、初回表示時にGTMコンテナが正常に読み込まれていても、その後の画面遷移でページビューやイベントが正しく送信されるとは限りません。 そのため、以下を分けて確認しました。 ページを最初に表示したときの計測 ページ内で画面遷移したときの計測 画面遷移後の page_location 仮想ページビューの発火 前画面の値が dataLayer に残っていないか 同じイベントが重複して送信されていないか Googleタグゲートウェイ自体は通信経路を変更する仕組みですが、導入を機に、既存のSPA計測が正常に動作していることも合わせて確認しました。 プレビューモードだけで判断しない GTMのプレビューモードでは正常に見えていても、プレビューモードを利用しない通常アクセスでは、想定した通信が発生していない場合があります。 そのため、以下の両方で確認しました。 GTMのプレビューモードを利用した状態 プレビューモードを利用しない通常アクセス 問題が発生した場合は、以下の順番で確認すると、原因を切り分けやすくなります。 Webサイト上でGTMコードスニペットが実行されているか GTMコンテナが読み込まれているか 対象のタグが発火しているか ブラウザから計測リクエストが送信されているか CloudFrontへリクエストが到達しているか Google側へ転送されているか GA4でイベントを確認できるか ブラウザのNetworkタブにリクエスト自体が表示されていない場合は、CloudFrontより前のWebサイトやGTMの処理を確認します。 一方、ブラウザからリクエストが送信されているものの、エラーになっている場合は、インフラ担当と連携して、CloudFrontやWAFなどを確認します。 すべての通信が自社ドメイン経由になるわけではない 検証時には、ブラウザのNetworkタブからGoogle関連の通信を確認しました。 その結果、GA4の計測では自社ドメイン経由になっている通信を確認できましたが、一部の通信は、引き続きGoogleドメインへ送信されていました。 :::message Googleタグゲートウェイを導入したからといって、Googleに関係するすべての通信が自社ドメイン経由になるわけではありません。 ::: そのため、Googleドメインへの通信が完全になくなるかどうかではなく、対象となるGoogleタグや計測リクエストが、想定どおり自社ドメインを経由しているかを確認しました。 導入後の効果 Googleタグゲートウェイの導入後、タグの発火状況と、コンバージョンページのイベント数を確認しました。 タグの発火状況が改善した 導入前は、Googleタグの読み込みや計測リクエストをGoogleドメインへ直接送信していました。 導入後は、対象通信が自社ドメインを経由する構成へと変更されました。 これにより、広告ブロッカー等に起因するタグの未発火が抑制され、GA4へ送信されるイベント数が前月比・前週比で約10〜15%増加しました。 :::message 旧環境との完全な並行稼働による厳密な差分比較はできないため、前後期間の傾向に基づく推定値です。 ::: Googleタグゲートウェイを導入しても、すべてのユーザー環境で必ずタグが発火するようになるわけではありません。 例えば、以下のような要因によって、引き続きイベントが送信されない可能性があります。 JavaScriptが無効化されている ユーザーの同意状況によって計測が制限されている ページ表示が完了する前にユーザーが離脱した ブラウザやネットワークの状態によって通信に失敗した 一方で、Googleドメインへの直接通信がブロックされることによるイベント欠損については、一定の改善効果を確認できました。 GA4とバックエンドデータベースの数値差が縮小した 今回、導入効果を確認するため、GA4で計測したコンバージョンページのイベント数と、バックエンドのデータベースに保存されているコンバージョン件数を比較しました。 導入前は、バックエンドのデータベース上ではコンバージョンが記録されているものの、GA4では対応するイベントを確認できないケースがあり、両者の数値に大きな差がありました。 導入前 バックエンドDBのコンバージョン件数 ＞ GA4のコンバージョンページイベント数 Googleタグゲートウェイの導入後は、GA4で確認できるコンバージョンページのイベント数が増加し、バックエンドのデータベースに記録されている件数へ大きく近づきました。 導入後 バックエンドDBのコンバージョン件数 ≒ GA4のコンバージョンページイベント数 バックエンドのデータベースとGA4では、計測の仕組みや集計条件が異なるため、両者の数値が完全に一致するとは限りません。 例えば、コンバージョン処理がバックエンドで完了していても、ユーザーが完了ページを表示する前に離脱した場合は、GA4のページイベントが発生しない可能性があります。 また、同意設定やブラウザ環境などによって、GA4への送信が制限される場合もあります。 それでも、導入後に両者の数値差が大きく縮小したことから、これまで欠損していた一部のイベントを取得できるようになったと考えています。 広告施策の評価に利用するデータが改善した コンバージョンイベントの取得数が増えたことで、GA4やGoogle広告で確認できるデータが、実際のコンバージョン状況により近づきました。 これにより、広告施策ごとの成果を、導入前より正確に評価できるようになりました。 また、Google広告へ連携されるコンバージョンデータの欠損が減ることで、自動入札や広告配信の最適化に利用できるデータ量の改善も期待できます。 ただし、広告の成果や配信精度は、以下のような複数の要因に左右されます。 広告予算 入札戦略 ターゲティング 広告クリエイティブ ランディングページ 市場環境 コンバージョン設定 そのため、Googleタグゲートウェイの導入だけで広告成果や広告精度が向上したとは断定していません。 今回の主な成果は、広告施策の評価や配信最適化に利用する、コンバージョンデータの欠損を減らせたことだと考えています。 振り返り GTMコンテナ内の変更を抑えて導入できた 今回の構成では、GTMコンテナ内のGA4タグ、Google広告タグ、トリガー、変数などを変更していません。 CloudFront側の通信経路と、Webサイトに設置しているGTMコードスニペットの読み込み先を変更することで導入できました。 既存の計測設計への影響を抑えながら導入できた点は、大きなメリットでした。 検証環境から段階的に導入することが重要 いきなり本番環境へ反映するのではなく、先に検証環境のCloudFront設定とGTMコードスニペットを変更しました。 検証環境では、GTMコンテナの読み込み、GA4イベント、SPA遷移、コンバージョンページなどを確認しました。 問題がないことを確認した後に本番環境へ展開することで、既存計測への影響を抑えながら導入できました。 複数チームの連携が必要 Googleタグゲートウェイは、GTMやGA4だけでなく、CloudFrontなどの配信基盤と、Webサイトに設置されるコードにも関係します。 今回の導入では、DataOpsグループ、インフラ担当、プロダクトチームがそれぞれ以下を担当しました。 DataOpsグループ：要件整理、計測確認、効果検証 インフラ担当：CloudFrontの設定 プロダクトチーム：GTMコードスニペットの差し替え 事前に担当範囲を整理したことで、検証環境から本番環境への展開をスムーズに進められました。 レイヤーごとに切り分けることが重要 Googleタグゲートウェイ導入後の通信には、複数の要素が関係します。 Webサイト ↓ GTMコードスニペット ↓ GTMコンテナ ↓ ブラウザ ↓ Amazon CloudFront ↓ Googleタグゲートウェイ ↓ GA4・Google広告など 問題が発生した場合は、最初からすべてを調査するのではなく、どこまで正常に処理されているかを順番に確認することが重要です。 ブラウザのNetworkタブ、GTMのプレビューモード、GA4のDebugViewなどを組み合わせることで、問題がWebサイト側にあるのか、GTMにあるのか、インフラ側にあるのかを切り分けやすくなりました。 おわりに 今回は、Amazon CloudFrontを利用して、Googleタグゲートウェイを導入した事例を紹介しました。 Googleタグゲートウェイの導入だけで、すべてのイベント欠損を防げるわけではありません。 一方で、Googleドメインへの直接通信がブロックされることによる欠損を軽減し、サイト改善や広告施策の判断に利用するデータを、実態に近づける効果を確認できました。 Amazon CloudFrontを利用してGoogleタグゲートウェイの導入を検討されている方にとって、本記事が少しでも参考になれば幸いです。

こんにちは。 ファインディ株式会社でテックリードマネージャーをやらせてもらっている戸田です。 生成AIが開発現場に入り込んでから1年あまり。Claude CodeやGitHub Copilotなどのエージェント型ツールも一般的になってきました。 その一方で、「AIを導入したのに、思ったほど速くなっていない」「むしろレビューが大変になった」という声を、社内外でよく聞くようになりました。 そんな中で先日、弊社主催の「AI Engineering Summit Tokyo 2026」にて 「速く作る」から「正しく作る」へ ─ 生成AI時代の開発フロー改革のロードマップと実行 ─ と題して登壇してきました。 ファインディ社内で1年強かけて見えてきた「AI導入の落とし穴」と、そこから組み立てた3段階のロードマップを共有する内容です。 ai-engineering-summit-tokyo.findy-tools.io この記事では登壇内容を振り返りつつ、AI導入の効果が伸び悩んでいる組織に向けて、ファインディがどのような順番で開発フローを作り変えてきたかを紹介します。 それでは見ていきましょう！ AIを入れたのに、アウトプットは伸びていなかった 「速く作る」だけでは限界がある AI活用レベル レベル 1：AIエージェントでコード生成 レベル 2：AIエージェントでモノを作る レベル 3：AIで価値を生み出す まとめ AIを入れたのに、アウトプットは伸びていなかった ファインディも同様に生成AIの本格活用を進め、Claude CodeやCodexなどのAIエージェントが日常的な開発フローに入り込んできました。社内の体感としては「1人あたりのPR作成数も増えていそうだし、開発のリードタイムも短くなっているはず」というものでした。 しかし、Findy Team+で1年分の数値を計測してみると、想像とは違う景色が見えてきました。 まずポジティブな変化として、PR作成総数は前年比で伸びていました。ただ、その内訳を見ると、稼働メンバー数が約1.5倍に増えていたことが大きく、1人あたりのPR作成数はほぼ横ばいだったのです。 さらに、レビュー開始からApproveまでの時間は前年比でおよそ20分延び、PR1本あたりの平均コメント数・レビュー数も約30%増えていました。AIによるコード生成が増えた一方で、レビュー側の負荷が確実に積み上がっていたわけです。 シニア層と若手層で傾向を分けて見ると、もう一段深い構造が見えてきました。AIの出力を読んで検証できるシニアメンバーはアウトプットが上がる一方、経験年数が浅いほどAI出力の合否判断に苦戦する傾向があり、結果としてレビュー側に判断の負荷が集中していました。 組織全体として、 AIに使われている 状態に近かったとも言えます。「体感と事実がズレているかもしれない」と疑い、各種数値を可視化していたからこそ、実は「1人あたりのPR作成数は増えておらず、それどころかレビューの負荷が増えており、結果的に開発のリードタイムは長くなっていた」ことに気づくことができたのです。 「速く作る」だけでは限界がある 計測結果から見えてきたのは、「コードを書く速度が上がっても、ボトルネックがレビューに移り変わったために、全体のリードタイムは短くならなかった」、ということでした。 AIでコードを書くスピードは確かに上がります。一方で、内容を十分理解せずに生成するケースが増えると、PRの一貫性や正確性が落ちます。 指摘の量が増えると、リードクラスのレビュー時間が膨らみ、リードタイムが悪化します。最終的に、トータルのアウトプットはAI導入前とほぼ変わらない、という結果に着地します。 AIの成果物に対する確認や検証に時間がかかるようになり、レビューの負荷が増える。これがAI導入の落とし穴の一つです。そのため、AIの成果物の品質を再現性高く担保するための仕組みを整えることが必要になります。 そのために必要になるのが、「正しい作り方と手順」を仕組み化することです。馬を御する馬具（ハーネス）になぞらえ、AIの動きを暴走させず目的の方向へ導くための仕組みを整えることを ハーネスエンジニアリング と呼びます。 このハーネス化を、ファインディは 開発フロー改革 として進めてきました。具体的には、AI活用のレベルを3段階に分け、土台から段階的に積み上げていくロードマップを描いています。 AI活用レベル 開発フローを分解し、AIで何を肩代わりできるかをマッピングすると、3つのレベルが浮かび上がりました。 レベル 1：速く作る ：コード変更とPR作成を中心に、AIで代替できる範囲を自動化する レベル 2：正しく作る ：タスク分解とIssue作成までAIに任せ、「正しく作る」仕組みを整える レベル 3：必要なものを作る ：要件定義やQAという「AIで代替しづらい」とされてきた領域に踏み込む ポイントは、「どれか1つを単独でやる」のではなく、Lv1 → Lv2 → Lv3 と段階的に積み上げて初めて効果が出るという点です。ここから各レベルを順に見ていきます。 レベル 1：AIエージェントでコード生成 レベル 1の目的は、コード変更とPull request作成までをAIエージェントに任せ、人間は本質的なレビューに集中することです。 このフェーズで真っ先に向き合う必要があるのは、「AIが出したコードの責任は誰にあるか」という問いです。 どれだけ自動化されても、AIが出力したコードの責任は人間にあります。品質と判断の最終責任は人間が引き受けることになります。 その前提の上で、レベル 1の工程を整理してみました。 コード変更とPull request作成はAIに全て任せることが出来ます。そしてレビューに関しては、コードの責任という観点から人間が行う必要があると考えていました。しかし、本当にそうなのか疑問に思いました。 自分自身がコードを書いてPull requestを作成していた頃を思い出してみてください。自分でコードを書いて、Pull requestを作成する。レビュー依頼を出す前にやっていたことがありました。セルフレビューです。 そしてセルフレビューで気づく内容と、実際に他のメンバーからもらうレビューの内容は観点や内容が違います。これを今回の開発フロー改革に当てはめました。 レビューをセルフレビューとレビューに分け、レベル 1ではセルフレビューまでをAIに任せることにしました。セルフレビューではコード変更そのものに対するレビュー、レビューでは人間が最終判断しないといけない内容にフォーカスしてレビューというように切り分けることにしました。 ここで重要なのは、AIを入れる前提として「AIと関係なく当たり前のこと」が揃っている必要がある、という点です。 アーキテクチャ・命名規則・型定義といったコード設計、十分なテストカバレッジ、一貫した設計パターン、そしてPRの適切な粒度・レビュー文化・タスク分解の習慣。 これらはAI以前から品質を保つために必須でしたが、AIエージェントが入ると一気に効いてきます。土台が弱いと、AIはその弱さを増幅する方向に働くからです。 ファインディがこの「土台」をどう積み上げてきたかは、次の記事で詳述しています。 tech.findy.co.jp その土台の上に、AIが参照するドキュメントとルールをガードレールとして整備します。 READMEやプロジェクトドキュメントで開発前提・アーキテクチャ・運用ルールを記述し、AGENT.mdやrulesでコード規約・命名規則・テスト方針をAIに自動参照させ、カスタムコマンドやプロンプトテンプレートで依頼タスクを規格化する。 この整備があって初めて、AIは使い物になるコードを出力してくれます。 ファインディではレベル 1を支える仕組みとして、Claude CodeのSkillを複数組み合わせています。代表的なものは次の通りです。 Pull request作成：typecheck／lint／test／buildといった品質チェックの自動実行、ブランチ命名規則の強制、Conventional Commitに沿ったコミット生成、PRテンプレートからのbody自動生成までを1コマンドで実行 Pull request作成前の自動セルフレビュー：セキュリティ／コード品質／規約準拠／Simplify観点／要件検証／チェックリスト照合の6観点で並列分析。信頼度の高い指摘のみを報告してノイズを抑制し、2026年4月時点で1500以上のPRで運用中 AI併用レビュー：Codex CLIを別系統として並行運用し、メインAIのレビューと統合してPRコメントに提示。AIの偏りに依存しない複眼チェックを実現 定期セルフレビュー自動化：平日の朝方にGitHub Actionsで起動し、直近1ヶ月変更されていない技術的負債となりうる既存コードに対して修正Pull requestを自動作成 チェックリスト自動更新：過去レビューコメントをGitHub APIで収集し、LLMで指摘パターンを分類してチェックリストへ反映。レビュアーの暗黙知をSkillに形式知として残す セルフレビュー周りの仕組みについては、それぞれ次の記事でも紹介しています。 tech.findy.co.jp tech.findy.co.jp これらは1リポジトリにSkill／Sub Agent／MCPとしてまとめており、Pluginとして運用することで /plugin install によるワンコマンド配布を実現しています。全員がcontributeできる構造にすることで、改善がそのまま組織全体に反映される回り方になっています。 レベル 2：AIエージェントでモノを作る レベル 1で「速く作る」の足回りが整うと、次にぶつかるのが「要件をどう実現するか」の手順自体がAIフレンドリーではない、という壁です。タスクの粒度や手順を誰も明示的に決めていないため、生成AIに何を渡せば精度よく動くかが属人化していました。 ここで必要になるのが、「作りたいもの（What）」と「作り方の設計図（How）」を分離して扱う発想です。 Whatをタスク分解の形でHowに落とし込み、それをAIに渡せば、AIはそのステップどおりに実装してくれます。そしてレビューでは、出来上がったコードよりも先に「作り方と実現方法が合っているか」を検証し、設計図のほうにフィードバックする。タスク分解の品質が、そのままアウトプットの品質を決める構造です。 このフェーズでは、AIとの関係性が「協働」から「委任」に変わります。 Vibe Codingが「AIは隣で並走するパートナー」だとすると、Agentic Workflowは「AIは自走する実行エージェントで、人間はその指揮者」になります。 任せる粒度も、1行〜1関数のレベルから、タスク／PR／フロー全体へと拡張されます。 Agentic Workflowの定義として4つの自律性を意識しています。 ゴール指向 ：「何を」を与え、「どう実現するか」はAIが組み立てる 計画と分解 ：大きなタスクをサブタスクに分けて順序付けて実行 ツール使用 ：ファイル・Skill・コマンド・検索・MCPを能動的に使う 自己検証ループ ：テスト失敗→修正→再実行を自律的に繰り返す 興味深かったのは、AI委任の前提が変わると開発環境そのものが変わったことです。 2026年に入ってから、ファインディではコード生成のメインツールがIDEからターミナルへ変化しました。 1ウインドウで1タスクずつ進めるのではなく、複数ウインドウ・ペインで同時にAIへ委任するスタイルになったため、並列委任しやすい場所として、ターミナル＋tmuxのような構成に自然と寄せていく流れになっています。IDEの役割はコードを書く場から、広域に渡るコードリーディングや理解を深める場へとシフトしています。 このレベル 2を支えるのが、要件構造化＆Issue自動生成のSkillです。次の6ステップで動きます。 要件理解 ─ インタラクティブな質問で曖昧さを解消 コード探索 ─ 並列の探索Agentが複数観点で同時調査 要件明確化 ─ 不足情報を補完してスコープを定義 設計提案 ─ 実装方針のドラフトを生成 タスク分解 ─ 実装単位に分解（粒度判定Skill連携） Issue作成 ─ Sub Issue／relationshipを含む構造化Issue このSkillで生成したIssueは累計3000以上にのぼり、親Issue（Feature）→子Issue（DB層→API層など）が blocked_by の依存関係付きで自動構成されます。 例えば「ユーザー通知機能の追加」という親Issueに対し、「#1 DB層：通知テーブル追加」「#2 POST API追加」「#3 DELETE API追加」のような子Issueが、依存関係込みで一気に並ぶイメージです。 実装フェーズでは、これを「Issue × Worktree × Agent」の並列モデルで走らせています。Team Lead Agentが blocked_by に従ってLayerごとにWorker Agentを起動・同期し、同じLayer内はworktreeを切ってWorker Agentが完全並列で実装する。Layer 0でDB層が完了したら、Layer 1のPOST／DELETE APIを2つのworktreeで同時に進める、といった動かし方ができます。 この並列モデルの詳細は次の記事で解説しています。 tech.findy.co.jp コードレビューの分担も、レベル 2では明示的に再定義しています。 担当 レビュー領域 AI コード規約・命名、型定義、テストコード・テストケース 人間 ビジネスロジックの要件適合、アーキテクチャや設計、データベース構造、明確なセキュリティリスク 視点はコードそのものから抽象的なところに寄せていきます。 結果として、レベル 2の導入後、1人あたりのPR作成数は前年比で1.5倍を超えました。AIフレンドリーな「設計図（タスク分解＋構造化Issue）」を誰でも作れる状態になり、作りたいものを再現性高くアウトプットできるようになった、というのがその答えです。 レベル 3：AIで価値を生み出す レベル 2まで進むと、開発スピードに対する次のボトルネックが見えてきます。「何を作るか」の上流が詰まり、せっかく整えた実装力を活かしきれない状態です。 具体的には、要件の実現可能性を調査できるのがエンジニアだけになっていたり、システムとプロダクトの概念が離れていて、お互いを十分知らないまま施策や検証が進んでしまったりします。 レベル 3の目的は、要件定義（PdM領域）とQA領域というAIで代替しづらいとされてきた領域に、AIで踏み込むことです。 レベル 3の起点になるのが 現状把握 です。現状把握の対象は広い範囲に及びます。コードベース・Google Analytics・プロダクト文書・GitHub Issues／PR・Datadog・各種KPIなど、必要なコンテキストは多岐にわたります。 まず要件定義では、これらを毎回手動で集めるのは現実的ではないため、専門Agentチームが各ソースから必要な分だけ自動収集する仕組みを組みました。 ファインディの要件定義Skillでは、7つの専門Agentが並列で動きます。 目的・成果分析 ─ WHY／WHAT仮説の自律生成 データ・コンテキスト収集 ─ GitHub Issues・Notionから数値収集 プロダクト文書抽出 ─ docs／配下のKPI・ポリシーを抽出 コードベース分析 ─ リポジトリの制約・パターンを分析 スコープ分割 ─ MVPと拡張項目に分割 技術的実現可能性評価 ─ 解決アプローチの実現可能性を評価 アクセス解析データ収集 ─ Google Analyticsから自動収集 これらのAgentがAgentTeamsとして並列で稼働し、お互い会話しながら必要な情報を集めて分析します。 ユーザーは分析結果を修正・補足し、最後にAIが構造化＆品質チェックしてGitHub Issueとして出力します。ユーザー操作は入力・レビュー・承認の3回のみで、それ以外はAIが自律的に進める設計です。出力されたWHY／WHAT構造化済みIssueは、そのままレベル 2のIssue自動分解Skillに連携できます。 もう1つの挑戦がQA領域です。ユーザビリティ・アクセシビリティ・UI／UXといった非機能要件のテストはAI単独では難しいため、AIで代替しづらい領域です。ファインディは「代替」ではなく「支援」、つまりAIがQAエンジニアの判断を最大化する形を仮説にしています。 次にQA領域は3つのSkillで一気通貫にしました。仕様ソース（Issue／Figma／Notion）を入力に、次の流れで進みます。 QA観点抽出：観点を自動抽出してQA観点mdを出力 QAテストケース生成：観点→ステップ／期待結果／前提条件に展開してMarkdown＋CSV化 QA自動実行：Playwright MCP経由でClaude Codeから直接ブラウザを操作し、Pass／Failとスクリーンショット付きのレポートを出力 QA観点抽出では、仕様分析／画面構造・UX探索／影響範囲判定の3つのAgentが並列で動き、観点設計のたたき台を数分で生成します。 テストケース生成では、観点→具体ケースへの落とし込みにかかる工数が数時間から数分に短縮されました。生成されたQAリストは、認証・認可／入力バリデーション／表示・UI／ファイル操作／外部連携／メール送信の6軸で共通基準と照合し、観点漏れ・粒度のばらつきを検出します。 人間が集中すべきは、ユーザビリティ評価、例外シナリオ、クライアント要件の確認といった「判断が必要な領域」です。反復可能なケースはAIが淡々と実行し、失敗時はスクリーンショット付きレポートで原因特定が速くなりました。 まとめ AI活用のレベルをレベル 1（速く作る）／レベル 2（正しく作る）／レベル 3（必要なものを作る）と分けてきましたが、最大の主張は、これらは「どれか1つ」ではなく段階的に積み上げて初めて成立する、ということです。 そして、ここで強調したいのが 順番を間違えない ことです。土台が弱いと、ガードレールもAI Skillも成果を出せません。ファインディが踏んだ順番は次の4段でした。 裏返すと、AIエージェントを入れる前にやっておくべきことは、AI以前から変わっていません。統一規約、テストコード、PR粒度、レビューなどの開発文化といった 基本の徹底 こそがAI活用における大前提です。 AI時代の本丸は、「速く作る」ではなく、「正しく作る」「必要なものを作る」への段階的越境です。あなたの組織が今どのレベルにいるか、そして次のレベルへ進むためにどの土台が弱いかを確認する目安として、このロードマップが役立てば幸いです。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

急成長を続けるプロダクト、多様化が止まらないユーザーデバイス、そしてチームごとにバラバラなテスト基準。QAマネージャーとして、場当たり的な個別対応に限界を感じてはいませんか？ 現場からの「どこまでテストすればいいのか」という問いと、経営層やPdMからの「リリース速度を落としたくない」という要求。 その板挟みの中で「これで本当に品質が担保できているのか」という不安を払拭するのは容易ではありません。 そこで今回は単なる表示確認にとどまらない、以下のような戦略的な「クロスブラウザテスト」の本質を掘り下げます。 なぜブラウザ差異が発生し、ビジネスにどのようなリスクを与えるのか データに基づき、どのように「全環境対応」の幻想を捨て、優先順位を決めるのか 手動と自動をどう使い分け、CI/CDに組み込んで持続可能な体制を築くのか import haihaiInquiryFormClient from "https://form-gw.hm-f.jp/js/haihai.inquiry_form.client.js";haihaiInquiryFormClient.create({baseURL: "https://form-gw.hm-f.jp",formUUID: "927d2c4e-f06c-45b1-bd36-0240e55ccf72",}) ▼テストの種類について詳しい内容はこちら▼ 【保存版】テストの目的別タイプ一覧 クロスブラウザテストとは？ クロスブラウザテストの定義 クロスブラウザテストとは、Google ChromeやSafari、Microsoft Edge、Firefoxといった複数の異なるWebブラウザ、およびそれらが動作するデバイスやOSの組み合わせにおいて、WebサイトやWebアプリケーションが意図通りに動作・表示されるかを検証するプロセスを指します。 QAの現場ではしばしばレイアウト崩れを確認する表示確認と同義に捉えられがちですが、本来の目的はそれ以上に多岐にわたります。 特定のブラウザでのみJavaScriptが実行されず、購入ボタンが反応しないといった機能不全や、特定のOSでフォーム入力の挙動が異なりユーザーが操作を完結できないといった操作性の問題、さらにはフォントの読み込み速度やアニメーションの滑らかさによるユーザー体験の毀損を防ぐことが重要です。 単なる見た目の整合性を超え、どの環境からアクセスしてもプロダクトが提供すべき価値を同等に享受できる状態を担保することが、クロスブラウザテストの本質的な役割といえます。 メガベンチャー規模のプロダクトにおいては、ユーザーの利用環境が多岐にわたるため、この検証の網羅性がサービス全体の信頼性に直結します。 なぜブラウザ差異が発生するのか ブラウザ間で表示や挙動の差異が発生する最大の要因は、各ブラウザが採用しているレンダリングエンジンやJavaScriptエンジンの違いにあります。 例えば、ChromeやEdgeはBlink、SafariはWebKit、FirefoxはGeckoという異なるレンダリングエンジンを用いてHTMLやCSSを解析し、画面上に描画しています。 各エンジンはW3Cなどの標準化団体が策定した仕様に準拠するよう開発されていますが、新しい仕様への対応スピードや、仕様書の記述に対する細かな解釈、さらには実装の優先順位がエンジンごとに異なります。 加えて、JavaScriptの実行を担うV8やJavaScriptCore、SpiderMonkeyといったエンジンの性能差や、特定のメソッドへの対応状況も挙動の乖離を生む原因となります。 結果として、同じコードであってもブラウザごとにCSSのプロパティが無視されたり、スクリプトの実行タイミングが微妙にずれたりするといった現象が発生します。 こうしたブラウザ内部の仕組みや、仕様解釈の微妙なズレが積み重なることで、開発者の意図しない差異が生まれる構造になっています。 クロスブラウザテストが担う品質価値 クロスブラウザテストが担保する品質は、プロダクトのビジネス的成功に直結する極めて重要な価値を持っています。 昨今の多様なデバイス環境において、特定のブラウザで発生する不具合は単なる技術的なミスに留まらず、ユーザー体験の低下、ひいてはコンバージョン率（CVR）の直接的な下落を招きます。 例えば、決済画面で動作が不安定になればユーザーは即座に離脱し、その機会損失は大規模なサービスほど膨大な額に達します。 また、サービスが特定の環境で適切に動作しないという事実は、プロダクトおよびブランドへの信頼性を大きく損ない、長期的なファンを失うといったビジネス上のリスクを孕んでいます。 QAマネージャーとしては、こうした不具合が引き起こすリスクを定量的に捉え、開発チームや経営層に対して品質投資の重要性を説く際の論理的な根拠とする必要があります。 クロスブラウザテストは、あらゆるユーザーに対して公平かつ安定したサービスを提供し、事業の持続的な成長を支える基盤としての役割を担っているのです。 クロスブラウザテストが必要とされる背景 ユーザー環境の多様化 現代のWebプロダクトにおいて、ユーザーがサービスに触れる入り口はかつてないほど複雑化しています。 Google Chrome、Safari、Microsoft Edge、Firefoxといった主要ブラウザのシェアは常に変動しており、それぞれが独自のレンダリングエンジンやスクリプト実行環境を持っています。 さらに、これらがWindowsやmacOSといったデスクトップOSだけでなく、iOSやAndroidといったモバイルOS上で動作することを考慮しなければなりません。 PC、スマートフォン、タブレットといったデバイスの種別も加わり、検証すべき組み合わせは指数関数的に増加しています。 メガベンチャーのような大規模なサービスでは、一部の環境で発生する軽微な表示崩れが、数万人規模のユーザーにとっての致命的な利用障害に繋がるリスクを孕んでいます。 特定の環境だけで発生するバグを未然に防ぎ、あらゆるユーザーに最低限の品質を保証するためには、こうした多様な環境の掛け合わせを前提とした検証体制の構築が不可欠となっています。 モバイル特有の課題 デスクトップ環境での検証以上に品質管理を難しくさせているのが、モバイル環境における固有の課題です。 スマートフォンやタブレットは画面サイズや解像度が機種ごとに激しく異なり、レスポンシブデザインが意図通りに機能しているかを常に監視する必要があります。 またマウス操作を前提としたデスクトップに対し、モバイルは指によるタッチ操作が基本となるため、ボタンの押しやすさやスクロールの挙動、ホバーアクションの有無といったインターフェース面の検証も欠かせません。 さらにモバイルブラウザはメモリ制限や電力消費の最適化のためにデスクトップ版とは異なる挙動を示すことがあります。 例えば、iOS版Safari特有の描画ルールや、Android端末のOSバージョンによるWebviewの差異などが、予期せぬ不具合の原因となるケースは少なくありません。 プロダクトがモバイルシフトを加速させる中で、こうしたデバイスごとの物理的・ソフトウェア的な差異を埋めるテストの重要性は増すばかりです。 「全環境対応」を目指さない考え方 QAの全体最適を考える上で最も重要なのは、すべての環境で完璧な動作を保証する全環境対応という幻想を捨てることです。 リソースが限られた現場において、シェアが極端に低い古いOSやマイナーなブラウザまで網羅することは、コスト対効果の観点から見て合理的ではありません。 現実的な品質戦略としては、まずはアクセス解析ツールなどから実際のユーザー利用率を抽出し、ビジネスに与える影響度が大きい環境を主要サポート対象として定義することが求められます。 機能の重要度に応じて、主要ブラウザではフル機能の動作を保証し、マイナー環境では最低限コンテンツが閲覧できる状態を維持するという、段階的な品質基準を設けるのが賢明です。 開発や経営層に対しても、闇雲にすべての不具合を解消するのではなく、リスクとコストを天秤にかけた戦略的な判断基準を提示することで、組織として納得感のある品質推進が可能になります。 テスト対象とテスト範囲の設計方法 対象ブラウザ・バージョンの選定 クロスブラウザテストの対象を定める際、まず取り組むべきは客観的なデータに基づいた優先順位付けです。 最新バージョンのブラウザを対象に含めるのは当然ですが、過去のバージョンをどこまで遡るかは、プロダクトのユーザー層によって最適解が異なります。 Google Analyticsなどのアクセス解析ツールを用いて、実際にサービスを利用しているユーザーのブラウザシェアとバージョン分布を詳細に分析することが不可欠です。 例えば、全ユーザーの95パーセントをカバーする範囲をサポート対象とする、あるいはビジネス上の重要度が高い特定のブラウザを重点項目に据えるといった明確な基準を設けます。 特に、自動更新が行われるエバーグリーンブラウザであるChromeやEdgeと、OSのアップデートに依存して更新頻度が異なるSafariでは、バージョンの扱いが異なる点に注意が必要です。 古いバージョンのサポートを打ち切る際の判断基準をデータで明確にしておくことで、開発チームや経営層に対しても、リソースをどこに集中すべきかという論理的な説明が可能になります。 闇雲に網羅性を求めるのではなく、データに基づき対象を絞り込むことが、QAの全体最適を実現するための第一歩となります。 対象OS・デバイスの整理 OS、ブラウザ、デバイスの膨大な組み合わせを整理するには、検証環境の特性を理解した使い分けが重要です。 メガベンチャーのような多種多様なプロダクトを抱える組織では、すべての組み合わせを実機で確認するのは現実的ではありません。 そこで、クリティカルな不具合が発生しやすい主要な組み合わせについては物理的な実機を用い、広範囲な網羅性が求められる検証にはクラウド上の仮想環境やエミュレータを活用するハイブリッドなアプローチを推奨します。 実機はタッチの感触や実際のレスポンス、物理的な挙動を確認するのに適していますが、仮想環境はスケールが容易でテスト自動化との相性が非常に良いという利点があります。 この設計においては、まず検証が必要なマトリクスを定義し、どのセルをどの手法で埋めるかを事前に決めておくことが属人化を防ぐ鍵となります。 また、iOSとAndroidそれぞれのOSバージョンと、そこで動作する標準ブラウザの挙動差を考慮に入れ、リスクの高いポイントを重点的に検証範囲へ組み込むことで、限られた工数の中で最大限の品質保証を実現できます。 こうした体系的な整理は、現場の負担を軽減し、持続可能な品質体制の構築に大きく寄与します。 優先的にテストすべき機能・ページ テストの範囲を限定するもう一つの軸は、機能やページの重要度による選定です。 すべてのページでピクセル単位の表示の整合性を求めるのではなく、ビジネスインパクトの大きい主要なユーザーフローを最優先に保護すべきです。 具体的には、ログイン、商品検索、決済、情報の送信といった、ユーザーが目的を達成するために不可欠な動線において、機能的な欠陥がないかを厳格に検証します。 特定のブラウザでボタンが反応しない、フォームが送信できないといった機能不全は、軽微なレイアウト崩れよりもはるかに深刻な機会損失や信頼低下を招きます。 QAマネージャーとしては、表示の美しさだけでなく、サービスが提供するコアな価値がどの環境でも損なわれていないかという視点で、開発側やプロダクトマネージャーと共通認識を持つことが重要です。 重要度の低いページについては自動チェックツールによる簡易的な目視に留め、主要なコンバージョンポイントにテストリソースを集中させることで、手戻りを最小限に抑えつつ、プロダクト全体のスピードと品質を両立させることが可能になります。 この優先順位付けこそが、QAが単なるボトルネックではなく、価値創出の中核として機能するための戦略的な判断となります。 クロスブラウザテストの実施方法と落とし穴 手動テストと自動テストの役割分担 クロスブラウザテストを組織全体で最適化するためには、手動テストと自動テストの役割を明確に定義し、相乗効果を生む設計が不可欠です。 手動テストが真価を発揮するのは、レイアウトの微妙な違和感やフォントの視認性、直感的な操作感といった、数値化しにくいUX（ユーザー体験）の検証領域です。 特に新機能のリリース初期やデザインの大幅変更時には、人間の目による探索的なアプローチが欠かせません。 一方で、複数のブラウザやOSの組み合わせを網羅する回帰テストにおいては、自動テストの導入が不可欠です。 ログイン、検索、決済といったビジネスインパクトの大きい定型的なユーザーフローに対して、PlaywrightやSeleniumなどのツールを用いた自動化パターンを構築することで、人的ミスを排除しつつ検証の頻度を飛躍的に高めることができます。 現場の属人化を防ぎ、QAが開発のボトルネックにならないようにするためには、機械的な繰り返し作業を自動化に委ね、QAエンジニアがより戦略的な品質設計や高難度な不具合の特定にリソースを割ける体制を構築することが、全体最適への近道となります。 よくある失敗パターン メガベンチャーのようなスピード感が求められる環境でよくある失敗は、開発効率を優先するあまり最新の特定ブラウザのみでテストを終えてしまうことです。 モダンブラウザは標準化が進んでいるとはいえ、SafariのようにOSアップデートと密接に関わるブラウザや、企業内で利用され続ける少し古いバージョンのEdgeなどでは、予期せぬ挙動差が頻発します。 また、PCでの検証を主軸に置き、モバイル端末での検証を開発終盤まで後回しにすることも大きなリスクを孕んでいます。 スマートフォンの画面サイズ、解像度、そしてタッチ操作特有のイベント処理は、デスクトップのシミュレータだけでは再現しきれない不具合を隠し持っていることが多いからです。 さらに、ブラウザごとのレンダリング性能やJavaScriptエンジンの処理速度の差を軽視することも、UXの観点では致命的です。 ある環境ではスムーズに動いても、別の環境ではページの読み込みが極端に重く、ユーザーの離脱を招くケースは少なくありません。 これらのパフォーマンス差を考慮せず、単に「動いている」ことだけを確認する姿勢は、ビジネス的な成功を脅かす落とし穴となります。 落とし穴への具体的な対策 こうした落とし穴を確実に回避するためには、論理的で再現性のある具体的な対策を講じる必要があります。 まず重要なのが、アクセス解析データに基づいてテスト対象を戦略的に絞り込むことです。 すべてのブラウザを平等に扱うのではなく、ユーザー数やビジネス上の優先度が高い環境にリソースを集中させることで、コスト対効果を最大化します。 実行環境においては、物理的な挙動を確認するための主要な実機と、膨大なOS・ブラウザの組み合わせを低コストで網羅できるクラウド上の仮想環境やエミュレータを賢く併用するハイブリッドな体制が理想的です。 さらに、検証の観点を「表示（デザインの整合性）」「機能（ロジックの正当性）」「性能（応答速度の快適さ）」の3つに明確に分離して考える視点を持つことも、品質の全体像を俯瞰する上で極めて有効です。 それぞれの重要度に応じた合格基準を設けることで、場当たり的な改善から脱却し、開発チームや経営層に対して「どのレベルの品質が担保されているか」を一貫した言葉で説明できるようになります。 この整理された知見を仕組み化することで、属人化を排除し、組織拡大に耐えうる持続可能な品質体制の礎を築くことが可能になります。 効率化・自動化と継続的な運用設計 クロスブラウザテストを支えるツール活用 メガベンチャー規模のプロダクトにおいて、膨大なデバイスとブラウザの組み合わせを自社で維持・管理することは、コストと工数の両面で現実的ではありません。 そこで重要となるのが、クラウド型ブラウザ検証サービスの活用です。 これらのサービスは、数千種類のOS、ブラウザ、実機の組み合わせをオンデマンドで提供し、インフラ維持の負担を大幅に軽減する役割を担います。 また自動化テストツールは、クロスブラウザテストの網羅性を担保するためのエンジンとして位置づけられます。 PlaywrightやSeleniumといったツールを基盤に、主要なユーザー動線を検証するスクリプトを記述することで、人手では不可能な頻度での多環境検証が可能になります。 QAマネージャーとしては、単にツールを導入するだけでなく、どの検証をクラウドで行い、どの範囲を自動化に委ねるかという戦略的な配置図を描くことが求められます。 ツールの導入は手段であり、QAチームがより付加価値の高い探索的テストや品質改善活動に集中するための環境作りであると捉えるべきです。 CI/CDとクロスブラウザテスト クロスブラウザテストの真の価値は、リリースの直前に一度だけ実施することではなく、開発サイクルの中に溶け込ませた継続的な検証にあります。 CI/CDパイプラインにクロスブラウザテストを組み込むことで、コードが変更されるたびに主要な環境での互換性を自動でチェックする仕組みを構築できます。 これにより、開発の初期段階でブラウザ固有の不具合を発見する「シフトレフト」が実現し、リリース間際の手戻りを劇的に削減できます。 ただし、すべてのテストを毎回のビルドで実行するとフィードバックループが遅延するため、回帰テストとしての組み込み方には工夫が必要です。 例えば、プルリクエスト時には最重要ブラウザのみを検証し、深夜の定期実行ですべてのサポート対象環境を網羅するといった段階的な設計が有効です。 こうした継続的な運用設計は、開発スピードを損なうことなく品質の最低ラインを常に維持し続けるための防波堤となり、組織拡大後も破綻しないQA体制の基盤となります。 運用で成果を出すためのベストプラクティス テスト運用を形骸化させず、着実に成果を出すためには、結果の記録と共有の仕組み化が欠かせません。 テスト結果は単なる成否のログに留めず、不具合発生時のスクリーンショットやビデオ、ネットワークログなどを自動で集約し、開発者が即座に修正に着手できる形で共有されるべきです。 また発見された不具合に対しては、ビジネスインパクトに基づいた厳格な優先度判断を行います。特定のブラウザでのみ発生する軽微な表示のズレに固執するのではなく、主要なユーザーフローが阻害されているかという視点で、プロダクトマネージャーや開発チームと同じ言葉で議論し、修正の優先順位を決定します。 さらに、毎回のテスト結果や発生した不具合の傾向を分析し、次回のテスト範囲やサポート対象の見直しに繋げる運用ループを回すことが重要です。 場当たり的な対応から脱却し、蓄積されたデータに基づいた改善を繰り返すことで、QA活動が事業の意思決定に貢献する価値創出の中核へと進化していきます。 まとめ クロスブラウザテストは、単なるバグ探しのプロセスではありません。あらゆる環境のユーザーに等しくプロダクトの価値を届け、ビジネスの機会損失を防ぐための「事業基盤」そのものです。 今回解説した要点は以下の通りです。 論理的なターゲット選定: アクセス解析データに基づき、全環境対応という幻想を捨てて、ビジネスインパクトの大きい環境にリソースを集中させる。 ハイブリッドな検証体制: 実機によるUX検証と、クラウド・仮想環境による網羅的な自動テストを使い分け、属人化を排除する。 継続的な運用設計: CI/CDパイプラインへの統合と運用ループの構築により、リリース速度を落とさず品質を維持する「シフトレフト」を実現する。 QAマネージャーに求められるのは、現場の細かな不具合を追うことだけではなく、「どのレベルの品質を、いかに持続可能な仕組みで担保するか」という全体設計です。 この記事で紹介した知見を、次の四半期の改善計画や、経営層・開発チームとの合意形成にぜひ役立ててください！ QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）