Playwright WebKit vs Safari 27：2026年のリモートテストはどう選ぶか

Playwrightで複数ブラウザーの検証を運用しているものの、WebKitの成功結果をSafariの合格判定に使ってよいか迷うフロントエンド・テスト担当者向けです。

Safari 27のリリース門番や再現環境を整えたいテスト担当者、実MacのテストノードをCIへ追加するか検討中のDevOps・開発基盤担当者にも適しています。

最終更新：2026年9月1日。Safari 27の状態は、Safari 27公式リリースノート、自動操作の設定はSafari WebDriver公式資料ではなく、指定されたmacOSでWebDriverを有効にする公式手順を基準に確認しています。Safari 27は公式資料上でBetaとして扱われているため、安定版の機能として断定しません。

Playwrightのブラウザー資料は、Playwrightが管理するWebKitを提供する一方、ブランド版Safariを直接実行する仕組みではないと説明しています。また、その実装はSafariへ正式に取り込まれる前のコードを含む場合があります。Playwrightの対応ブラウザー説明を、テスト対象の定義として確認してください。

ここで重要なのは、レンダリングエンジンが近いことと、製品としてのブラウザーが同じことは別だという点です。SafariにはmacOSのフォント、ウィンドウや権限の扱い、システムサービスとの接続、媒体デコーダー、Safari固有の設定や更新状態が関係します。

したがって、Playwright WebKitで見つかった不具合は有力な再現情報になりますが、WebKitで通ったことはSafariでの互換性証明にはなりません。

注意：Safari 27のBeta機能について、現行の安定版Safariで利用できる、またはすべてのmacOS構成で同じ結果になる、といった読み替えは避けてください。リリース判定では、検証したOS、Safariの状態、実行日時を記録します。

Playwright WebKitは、Playwrightの対応環境上でWindows、Linux、macOSから実行できます。これに対してSafari本体の自動操作は、macOS上のSafariとsafaridriverを必要とします。Safari WebDriverの公式テスト手順に沿って、Mac側の設定と接続方式を確認します。

次のように、テストの性質で振り分けると判断がぶれにくくなります。

• Playwright WebKitへ残すテスト：静的ページ、一般的なフォーム、DOM操作、CSSレイアウト、基本的なキーボード操作、毎回大量に実行する回帰テスト。
• 実Safariへ追加するテスト：動画や音声の再生、カメラ・マイク、通知や位置情報などの権限、システムフォント、キーチェーン連携、ファイルのアップロード・ダウンロード、ウィンドウやポップアップの制御。
• 二軌道にするテスト：ログイン、決済、会員登録、重要な編集画面、媒体を含む公開経路、Safari専用の挙動、リリース候補版の最終確認。

LinuxのPlaywright WebKitで問題を発見できる範囲は広いものの、macOSに依存する統合部分までは埋まりません。特に媒体と権限は、単なるページ描画の回帰とは分けて扱う必要があります。

二軌道運用は、全テストを2種類の環境で常に重複実行するという意味ではありません。安定していて件数の多い回帰はPlaywright WebKitへ集約し、実Safariは失敗時の影響が大きい経路に絞ります。

推奨しやすい分け方は次のとおりです。

• コミット単位：Playwright WebKitで高速な基本回帰を実行します。
• マージリクエスト単位：変更された機能に関係するWebKitテストを追加し、認証や主要画面だけ実Safariへ送ります。
• 日次ビルド：媒体、権限、ファイル操作、ウィンドウ制御を含むSafari検証をまとめて実行します。
• リリース候補：公開に関係する主要経路を実Safariで再確認し、失敗証跡と環境情報が揃わなければ合格にしません。

PlaywrightのブラウザーはCI用にインストール・キャッシュできますが、実Safari側ではグラフィカルなログイン状態、権限承認、ノードの再起動、セッションの解放を運用対象に含める必要があります。起動時間や並列数を根拠なしに比較するのではなく、チームの失敗率、待ち時間、保守工数を自分のCI記録で測定します。

実Safariのノードが必要になった場合は、NUKCLOUDの日本語案内で利用形態を確認し、まずは短期間の検証用環境として構成するのが安全です。長期運用へ進む前に、実行経路と復旧手順を固定します。

PlaywrightとSafari WebDriverは、ブラウザーを操作する目的は共通していても、同一の実行モデルではありません。Playwrightのスクリプトが変更なしでSafari本体を制御できる、と見積もるのは危険です。

移行前に、次の能力一覧を作成します。

• セレクターが標準的なWebDriver操作で再現できるか。
• 自動待機に依存した箇所を、明示的な状態確認へ置き換えられるか。
• カメラ、マイク、通知などの権限承認を、テスト開始前に安全に準備できるか。
• ダウンロード先、アップロード元、ファイル名の検証方法が環境間で一致するか。
• 新しいウィンドウ、タブ、ポップアップの取得と終了を制御できるか。
• 失敗時にSafariのログ、ページ状態、操作手順を保存できるか。

Safari 27のWebDriverに関する変更は、Safari 27の公式リリースノートに記載された範囲だけを採用します。Beta段階の記述を安定機能としてCIの必須条件にせず、安定版へ移行した後に再確認してください。

同じ操作がPlaywright WebKitでは成功し、Safariでは失敗した場合、最初から「Safariのバグ」と決めません。サイトの実装不備、WebKit実装の差、SafariとmacOSの統合差を切り分けるため、最低限次の情報を同じ失敗単位で保存します。

1. 操作開始時点のURL、画面状態、ブラウザーとOSのバージョン。
2. クリック、入力、待機、権限承認を含む最小の操作手順。
3. スクリーンショット、必要に応じた動画、ネットワーク記録、コンソール出力。
4. Playwright側ではTrace Viewerで確認できるトレース、Safari側ではWeb InspectorとWebDriverログ。
5. 同じ条件で再実行した結果と、最小再現ケース。

Playwrightのデバッグ資料はトレースや画面情報を確認する手掛かりになります。Safari側のDOM、ネットワーク、コンソールを調べる場合は、Safari Web Inspectorの公式資料を使います。

経験則：単発の成功は、別環境での互換性を証明しません。失敗が再現しない場合でも、環境情報と証跡が欠けていれば、リリース門番を通過させる前に原因不明として扱います。

判断を「WebKitかSafariか」の二択にせず、次の条件で運用方式を選びます。

• 低リスクの内容ページ：Playwright WebKitを主軸にします。実Safariは日次または変更時の抜き取りで十分な場合があります。
• 交互作用の多いWebアプリ：基本回帰はWebKit、ログイン・入力・主要導線はSafariへ送ります。
• 媒体を扱うアプリ：再生開始、停止、音量、全画面、権限拒否後の動作を実Safariで確認します。
• Safari拡張やSafari固有機能：Safari本体を必須にします。Playwright WebKitだけで合格判定を完了しません。
• 決済や公開直前の業務経路：二軌道を採用し、実Safariの証跡がない場合はリリースを保留します。

運用開始前は、次のチェック項目を満たしているか確認します。

• [ ] テスト名またはタグでWebKit用とSafari用のジョブを分けた。
• [ ] SafariノードのOS、Safari状態、safaridriver設定を記録した。
• [ ] 権限承認、ログイン状態、ファイル領域の初期化を自動化した。
• [ ] トレース、スクリーンショット、Web Inspector関連ログの保存先を決めた。
• [ ] ノード停止後の再起動、再接続、セッション解放を確認した。
• [ ] バージョン更新時の再検証条件と、旧環境へ戻す条件を決めた。
• [ ] WebKitのみで合格にする範囲と、Safariを必須にする範囲を文書化した。

実SafariをCIへ接続する場合は、最初から全回帰を移すのではなく、公開に直結する1つの経路で、Safariの起動、認証、証拠収集、再起動復旧までを検証します。必要なMacを自社で購入して固定運用する方法は、長期かつ安定した高負荷処理には向きますが、初期費用、保守、設置場所、障害時の交換が負担になります。Linuxの仮想環境だけに寄せる方法も、macOS固有の権限や媒体挙動を確認できません。

短期間でSafariの実行可能性を確かめたい場合は、NUKCLOUDの日本向け利用案内を参照し、実際の公開経路で試験してください。実行ノードの復旧と証跡保存まで再現できた時点で、継続的なCIへ組み込むかを判断できます。

Playwright WebKitの成功はSafariの合格になりますか

なりません。共通するWebKit由来の問題を早期発見する材料にはなりますが、Safariの外殻、macOSのシステム統合、権限、フォント、媒体処理まで同一とは限りません。Safari専用の不具合を閉じるには、実Safariでの再現確認が必要です。

Safari 27を自動操作する環境は何が必要ですか

Safari本体を対象にするなら、macOS上のSafariとsafaridriverを用意します。Playwright WebKitだけなら、Playwrightが対応するWindows、Linux、macOSのいずれかで実行できます。Macを用意する範囲は、Safari本体を確認するテストへ限定できます。

LinuxのWebKitテストで分かる問題はどこまでですか

一般的なDOM、CSS、JavaScript、フォーム操作など、WebKitに共通しやすい問題を見つける用途です。macOSのシステムフォント、権限ダイアログ、キーチェーン、媒体デコーダー、Safari固有の設定までは保証しません。

既存CIへ実Safariを追加する手順は何ですか

対象経路を絞り、リモートMacでSafariとsafaridriverの接続を確認し、ジョブのルーティング、権限準備、証跡保存、失敗時の再接続を順番に検証します。Playwright APIの自動待機やコンテキスト管理をそのまま移せない箇所は、WebDriver向けに個別対応します。

Linux CIとPlaywright WebKitだけで運用すると、実行基盤を増やしにくい反面、Safari固有の不具合を見逃し、macOSの権限や媒体処理を再現できず、公開直前に手動確認が集中しやすくなります。Mac実機を一台だけ購入して使い続ける方式も、利用者の増加時に並列性が不足し、保守担当者と故障時の代替機が必要になります。

そのため、短期間のSafari検証やリリース前の専用ノードを求めるチームでは、NUKCLOUDのリモートMacを使って重要経路を先に試す方法が現実的です。Safariの起動、テスト権限、ログ保存、再起動復旧を確認してから継続利用へ進めば、単なる「Macを借りる」判断ではなく、CIの門番として運用できるかを評価できます。