PlaywrightのWebKitと正式Safariは、同じテスト対象として扱えません。WebKitは幅広い回帰を効率よく見るために使い、Safariでしか確かめられない挙動はSafari上で確認します。どちらを採用するかは、必要なテスト証拠から決めてください。

Playwrightのブラウザー documentation が扱う主なブラウザーエンジンはChromium、Firefox、WebKitの3種類です。プロジェクトを複数定義すれば、同じテストを各エンジンで実行できます。ただし、テストが通ったことは、すべてのOSやブラウザーバージョンでの動作を確認したことにはなりません。Playwrightのブラウザーとプロジェクトの説明も参照し、実行環境を記録しましょう。

PlaywrightのWebKitは、ブランド版Safariそのものを起動する仕組みではありません。Playwrightのドキュメントでは、同プロジェクトで使うWebKitビルドとSafariを区別し、macOS上でのWebKit実行はSafariに近いテスト環境になる一方、Safariそのもののテストとは異なることを説明しています。

「WebKitで通ったからSafariでも問題ない」と結論づけるのは避けてください。どのOS、ブラウザーのビルド、Playwrightのバージョンで実行したかをテスト結果に添えれば、失敗の再現性や環境差を後から調べやすくなります。

フォーム入力、メニュー操作、ルーティング、基本的なレイアウト確認など、エンジンをまたぐ一般的なユーザー操作は、既存のPlaywrightプロジェクトで回帰させるのが現実的です。CIにWebKitプロジェクトを追加すれば、Safari利用者にも関係する共通部分の不具合を早めに検出できます。

この運用の利点は、すでにあるテストの流れへWebKitを組み込みやすいことです。一方、実行結果が正式Safariの証明にはならないこと、WebKitのビルドや実行プラットフォームが異なれば結果にも差が出ることは、テスト方針に明記してください。

実務では、PRごとにクロスブラウザーの共通回帰を実行し、Safari固有の確認は必要な変更やリリース判定に結び付ける方法があります。Playwrightの失敗調査では、Trace Viewerの公式説明を参考にトレースを確認できます。ただし、そのトレースはPlaywrightの実行証拠であり、正式Safariでの実行結果の代わりにはなりません。

正式Safariでの確認が必要なのは、Safariの挙動そのものが受け入れ条件になっている場合です。たとえば、Safari固有機能を使う画面、対象のSafariバージョンで報告された不具合、Safari利用者の実操作を再現するテストが該当します。

Safari WebDriverは、macOS上でSafariを自動化するための選択肢です。Appleの説明に沿ってリモート自動化を有効にし、safaridriverを使ってテストを実行します。ドライバーが利用できることだけを根拠に、Playwrightのテスト資産がそのまま動く、あるいは特定機能が保証されるとは判断しないでください。AppleのSafari WebDriver資料と有効化・実行手順を確認し、チームのテスト基盤に合わせて実装します。

Safariを正式に確認する利点と負担

• 利点： Safari本体での操作結果を、受け入れテストの証拠として残せます。
• 利点： Safariの特定バージョンで起きる問題を、対象環境で再現できます。
• 負担： macOS実行環境の準備、更新、アクセス管理を担当する必要があります。
• 負担： WebKitだけのジョブよりテスト範囲が増え、結果の保管・調査方法も整える必要があります。

CIを選ぶときは、実行頻度だけでなく、誰がMacを管理するか、Safariテストが失敗したとき誰が再現するかも決めましょう。Macの保守担当が不明なままジョブだけ増やすと、Safariの更新後に不安定なテストが放置されやすくなります。

動画や音声の再生、対応形式、ブラウザーやOSに関わる機能は、WebKitでの確認だけでは実際のSafari利用時の結果を確定できません。WebKitのテストで問題の兆候を見つけたら、対象のSafariと実際のメディア素材でも再生・操作を試し、どの条件で結果が変わるかを記録します。

WebKitはSafariの基盤となる技術ですが、WebKit上での動作をSafariの実機能と同一視しないことが重要です。たとえば、WebKitが公開するSafari 26.0の機能に関する記録は、特定バージョンに紐づいた情報として読めます。プロジェクトの結論には、実際に使ったSafariのバージョン、OS、メディア形式、再生結果を添えてください。

WebKitテストで失敗した場合は、Safariでも同じ問題が起きると断定せず、まず条件を切り分けます。逆にWebKitで通過した場合も、正式Safariでの受け入れが必要な機能ならSafariで確認を続けます。この二つの証拠を分けて保存することが、互換性の判断を誤らないための要点です。

Safariの検証を含むCIは、すべてをMacへ集約するより、テスト目的で階層化するほうが管理しやすくなります。通常のWebKit回帰は現在のクロスプラットフォームCIに残し、Safari固有の合否判定だけをmacOSのSafari WebDriverジョブへ割り当てます。

MacをCIへ加える前に、次の項目を確認してください。

• [ ] Safariで確認が必要なテストと、WebKit回帰で足りるテストを分ける。
• [ ] CIログにOS、Safari、Playwright、WebKitの実行情報を残す。
• [ ] Safari WebDriverの有効化と実行手順を担当者が再現できるようにする。
• [ ] Safariジョブの失敗時に、再現・修正・結果保管を行う担当を決める。
• [ ] Macの常時利用が必要か、特定のリリース確認だけで足りるかを見直す。

注意：WebKitの成功はWebKit上の成功として記録し、正式Safariの受け入れ結果と同じ欄へまとめないでください。異なるテスト証拠を一つの合否にすると、Safariで未確認の範囲が見えなくなります。

PlaywrightのWebKitテストはSafariテストと同じですか？

同じではありません。PlaywrightのWebKitプロジェクトはWebKitを使いますが、ブランド版Safariを直接操作するものではありません。一般的な回帰には有効ですが、正式Safariでの挙動を保証したい場合は、対象のmacOSとSafariを用意して別のテスト結果を残してください。

Playwrightから正式版Safariを直接起動できますか？

PlaywrightのWebKitプロジェクトをSafari本体の起動手段として扱うことはできません。Safariを自動化するには、macOSでSafari WebDriverを利用する構成を検討します。Playwrightで書いたテストをSafari WebDriverでどう扱うかは、実装方式と既存のテスト基盤を確認して決めてください。

Safari WebDriverのテストにmacOSは必要ですか？

Safari WebDriverでSafariを自動化するテストは、macOS上のSafariを実行対象にします。Appleの案内に従ってリモート自動化を有効にし、safaridriverを利用できる環境を整えてください。Macの準備や保守をチームで担えない場合は、ジョブ追加の前に運用責任も決める必要があります。

どんな互換性問題を正式Safariで確かめるべきですか？

Safari固有機能、特定バージョンで報告された不具合、Safari利用者の操作、媒体の再生結果など、正式Safariが判定対象になる問題です。WebKitでの結果は原因を絞る手掛かりにはなりますが、Safariの合否そのものではありません。実際の素材と対象環境を使って再現し、結果を記録してください。

Safari固有の確認が必要ないチームなら、既存CIのPlaywright WebKitを維持し、実行環境の記録を整えるところから始められます。正式Safariの自動化や継続的な再現環境が必要なら、Macの運用担当、利用頻度、アクセス方法を先に整理してください。自前のMacは常時使う環境を管理しやすい一方、調達と保守が必要です。LinuxのCIだけでは正式Safariを動かせず、都度の手作業確認では再現性や記録が不足しがちです。必要な期間だけMac環境を使いたい場合は、KVMNODEのリモートMac案内を確認し、チームのテスト要件に合うか検討できます。継続的な自社保有との違いは、Mac miniの導入案内も判断材料になります。