Web開発者向けSafari MCPサーバー

(webkit.org)

1 ポイント投稿者 GN⁺ 5 시간 전 | 2件のコメント | WhatsAppで共有

Safari MCPサーバーは、コーディングエージェントを実際のSafariウィンドウに接続し、Web開発・デバッグ中にブラウザで見えている状態を直接確認できるようにする
エージェントはDOM、ネットワークリクエスト、スクリーンショット、コンソール出力にアクセスでき、コードだけでは分かりにくいレンダリング結果やユーザー体験を確認できる
Safari互換性、パフォーマンス、アクセシビリティ、フォーム・チェックアウト状態の検証のように、ブラウザごとの差異が重要な作業で、繰り返しのウィンドウ切り替えやプロンプト説明の負担を減らせる
タブ制御、URL移動、JavaScript実行、ネットワークリクエスト参照、ページコンテンツ抽出、DOM操作、スクリーンショット、ビューポート・メディアエミュレーションのツールを提供する
サーバーはローカルマシン上でのみ動作し、自身でネットワーク呼び出しは行わないが、取得したページデータはユーザーが実行中のエージェントへ直接渡されるため、信頼できるエージェントの利用が必要

Safari MCPサーバーの役割

Safari Technology Preview 247にSafari MCPサーバーが追加された
Web開発者向けのModel Context Protocolサーバーで、エージェントをSafariブラウザウィンドウに接続する
コードがブラウザで実際にどうレンダリングされるかをエージェントが確認できるため、コード分析とブラウザ状態確認のあいだのギャップを縮められる
MCP互換クライアントであればSafari MCPサーバーに接続できる
接続されたエージェントは、ユーザーがブラウザで見ている状態をより近く再現できる
- DOMアクセス
- ネットワークリクエストアクセス
- スクリーンショットアクセス
- コンソール出力アクセス

デバッグの往復を減らす仕組み

一般的なWebデバッグでは、ブラウザで問題を見つけ、コンソールやスタイルタブを確認し、その後またコードに戻って修正する流れを繰り返す
エージェントを使う場合でも、スクリーンショットを撮って問題を説明し、修正が不十分ならブラウザ・プロンプト・エージェントの間を再び行き来する必要がある
Safari MCPサーバーは、エージェントがブラウザの状態を直接確認できるようにし、ウィンドウ切り替えや詳細なプロンプト作成の負担を減らす
ユーザーが完璧なプロンプトで状況を説明しなくても、エージェントはSafariで確認可能な情報をもとに次の作業を続けられる

主なユースケース

SafariでのWeb開発
- エージェントはコードだけでなく、Safariでの実際のレンダリング結果まで確認できる
Safari互換性の改善
- 1つのブラウザだけでテストすると、他ブラウザでの潜在的なバグを見逃すことがある
- エージェントはSafariでサイトを開き、computed style、レイアウト、期待する挙動との差異を確認できる
パフォーマンス分析
- ページ上でJavaScriptを評価し、navigation timingやresource load timeのようなパフォーマンス指標を明らかにできる
- サイトを遅くしている箇所が見つかれば、修正対象を絞り込みやすい
アクセシビリティ点検
- 欠落したlabel、不適切なARIA属性、低いcontrastのような一般的なアクセシビリティ問題を確認できる
ユーザー状態の検証
- フォーム状態の確認、selectorによる要素参照、特定の操作確認、チェックアウトフローの複数状態の表示などを行える

提供ツール

browser_console_messages: 現在のタブまたは指定タブのバッファ済みコンソールログを返す
browser_dialogs: ブラウザdialogの一覧を取得し、応答を処理する
- accept、dismiss、JavaScript promptへのテキスト入力をサポート
create_tab, close_tab, switch_tab, list_tabs: ブラウザタブの作成・終了・切り替え・一覧取得を行う
navigate_to_url: URLへ移動し、読み込まれたページコンテンツを返す
page_info: 現在のページのURL、title、loading stateを確認する
evaluate_javascript: ページ内でJavaScriptコードを実行し、結果を返す
list_network_requests: 現在のタブのネットワークリクエスト概要を取得する
- URL、method、status、timingを含む
get_network_request: 単一のネットワークリクエストの詳細情報を取得する
- headers、body、timingを含む
get_page_content: ページのテキストコンテンツをmarkdown、HTML、JSONなど複数形式で抽出する
page_interactions: click、type、scroll、hover、keyPressのようなDOM操作を順番に実行する
screenshot: 現在のページをPNGスクリーンショットとしてキャプチャする
set_emulated_media: responsive-designテストのためにprintのようなCSS media typeをエミュレートする
set_viewport_size: ブラウザのviewportサイズをCSS pixel単位で設定する
wait_for_navigation: 現在のページの読み込み完了を待ち、最終URLとtitleを返す

始め方

まず Safari Technology Preview をインストールする必要がある
インストール後、Safariの設定で次の項目を有効にする必要がある
- Safari Settings > Advanced > Show features for web developers
- Safari Settings > Developer > Enable remote automation and external agents
Claudeを使う場合は、ターミナルで次のコマンドを使える

claude mcp add safari-mcp-stp -- "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver" --mcp

Codexを使う場合は、次のコマンドを使える

codex mcp add safari-mcp-stp -- "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver" --mcp

他のエージェントでは、mcp.json または config.json に次の設定を入れられる

"safari-mcp-stp": {  
  "command": "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver",  
  "args": ["--mcp"]  
}

上の例ではサーバー名を safari-mcp-stp としているが、safari のように好きな名前を使える

プロンプトとエージェントの動作

インストール後は、次のような簡単なプロンプトで始められる

Find bugs on my site in Safari

How accessible is my site in Safari?

See how my website performs in Safari

エージェントごとに動作方式はやや異なるが、Safari MCPサーバーを明示的に使うよう指示しなくても自動で利用できる場合がある
例のフローでは、ユーザーがSafariのflight pageのバグを尋ねると、エージェントが2つのバグを見つけ、Safariユーザーに問題を起こし得る項目を追加で確認する
最初の依頼だけでも、Safari MCPサーバーの助けを借りてその後の確認や問題特定を続けられる

ローカル実行とデータ処理

Safari MCPサーバーは完全にローカルマシン上で動作する
自身ではネットワーク呼び出しを行わない
Safariの個人情報にはアクセスしない
- AutoFill
- その他のブラウザ活動
ページコンテンツ、スクリーンショット、コンソールログを取得すると、そのデータはAppleではなく、ユーザーが実行中のエージェントへ直接渡される
以後のデータ処理方法は、利用するエージェントとモデルによって異なる
ブラウザアクセス権を与える他のエージェントと同様に、信頼できるエージェントのみを使うべき

WebKitが期待する活用

Web開発にはAIを使う方法と使わない方法の両方がある
AIが開発フローの一部であるなら、Safari MCPサーバーは生産性向上に役立つ可能性がある
エージェントがSafariブラウザ内の画面や動作を理解できるよう支援し、Safariでのテストやデバッグをより容易にすることが目的
問題があれば WebKit bug report にissueを送信できる

2件のコメント

shakespeares 1 시간 전

Safari MCPとは……感慨深いですね（笑）

GN⁺ 5 시간 전

Hacker Newsのコメント

2025年11月からChrome公式のMCP DevToolsサーバーを使っている
https://github.com/ChromeDevTools/chrome-devtools-mcp
その前はChrome WebDriverを使っていたが、MCPのほうが速く、機能も多かった
Firefoxでも動くか確認するために、LLMにFirefox公式MCPでページをテストするよう指示した
https://github.com/mozilla/firefox-devtools-mcp
これでSafariも互換性テストに追加する予定だ
- これらと、Playwright MCPをChrome/Firefox設定で使うことの違いがあるのか気になる
- ときどきは逆に、LLMにブラウザを操作させるのではなく、自分がブラウザで手動で行った作業がLLMから見えるようにしたいことがある
  その用途をカバーするためにMCPを作った
Federico Viticciが、MacStories、Mastodon、Connectedポッドキャストの最新エピソードで、これが何を意味するのかをもう少し詳しく扱っていて、一般の人にもより取っつきやすい
元記事にあるリンクもぜひ見たほうがいい
https://www.macstories.net/linked/safaris-new-mcp-server-is-...
https://mastodon.macstories.net/@viticci/116847167023618099
https://relay.fm/connected/610
テストだけでなく、日常的な作業にも特に期待している
自分がログインしているブラウザで、エージェントが代わりにブラウザ自動化を自然に実行できれば、自分とエージェントの間の引き継ぎがずっとスムーズに感じられそうだ
Chromeはバッテリー消費が大きいので、Safariをメインブラウザとして使ってきたというのもある
- Hyperiaを作っているが、ElectronベースのWebパネルをエージェントが完全に制御して、かなり踏み込んだ作業ができる: https://github.com/deepbluedynamics/hyperia
  エージェント用コンテナオーケストレーターも使っており、コンテナのポートを公開するMCPツールがあるので、作業結果をWebパネルに表示できる: https://github.com/DeepBlueDynamics/nemesis8
  今日n8にSafari MCP接続を追加する予定で、さらに多くの機能を含む新しいリリースが今夜出る予定だ
- 「Safariの個人情報、たとえば自動入力や他のブラウザ活動にはアクセスしない」という文言を見ると、エージェントが相互作用するインスタンスにはログインしていないという意味に読める
- 「自分とエージェントの間の引き継ぎがよりスムーズ」という部分が怖い
  ブラウザの向こう側にあるサービスの立場では、誰が何をしているのか知る方法がないからだ
  エージェントをどう制限するのか、自分がやったこととエージェントがやったことをどう追跡するのかがわからない
  何か見落としているのか、それとも時代遅れなのか気になる
個人的にはPlaywright-CLIを勧める: https://github.com/microsoft/playwright-cli
自分が使ったMCPサーバーよりずっと高速に動作した
- 継続的なブラウザセッションが必要ならspel(https://github.com/Blockether/spel)もある
  デーモン経由でChromium、Firefox、WebKitエンジンをサポートしている
- Playwrightはエンドツーエンドテストに優れていて、Electronとも相性が良い
  ただ、自分はPlaywright MCPを使っている
- こうしたものは全部、自分には重く感じられた
  フルブラウザ、デバッグプロトコル、そして読むたびにDOMダンプが入ってくるので、MCPかCLIかよりも、その下で何が使われているかのほうが重要だ
  そこで、システムWebViewを直接起動し、DOMの代わりに状態トークンと差分を返す小さなRustバイナリを作った
  HNのトップページを読み込んでも、エージェント側で約50トークンしかかからない
  MCPとCLIの両方をサポートしているので、エージェントは好みのほうを選べばよい
  https://github.com/frane/vibesurfer
Appleが提供するsafaridriverは数年前から存在している
WebDriver W3Cを使用し、Safariインスタンスとやり取りするために使える
Appleが本当にWeb開発者のことを気にかけているのかは分からない。
Apple製デバイスがなければSafariでどうやってテストするのか。
Safariだけを入れた最小限の仮想マシンをAppleが作るのは、そんなに難しいことなのだろうか。
- Apple製デバイスなしでSafariをどうテストするのかというのは、PlayStationなしでPlayStationのゲームをどうテストするのかという質問に近い。
  ハードウェアなしでハードウェアのファームウェアをどうテストするのか、エミュレーターやシミュレーターもないのに必要なハードウェアなしでプログラムをどう実行するのか、というのと同じ問題だ。
  特定のハードウェアでしか動かず、仮想化やエミュレーションもないなら、そのハードウェアの外ではテストできないのであり、これはコンピューティングの黎明期から何十年もそうだった。
  Appleの決定は難しいか簡単かよりも戦略で決まることが多く、彼らが壁に囲まれた庭を作っていることはかなり明白だ。
  気に入らないなら、他の人たちと同じようにそこに参加しなければいい。
- Chromeが支配的な状況でも、Edgeなどほかのブラウザーを見落としたくないのでChromiumをテストしている。
  同じように、完璧ではないにせよWebKitをテストできるし、望むならLinuxやWindowsでも可能だ:
  https://orionbrowser.com/platforms/linux
  AppleがSafari仮想マシン事業をやるとは思えないが、macOS仮想マシンが必要ならクラウドサービスプロバイダーを見ればいい: https://aws.amazon.com/ec2/instance-types/mac/
  多くの場所でソフトウェアテストのオーケストレーションがあらかじめ接続されている。
- Appleがこの新しいツールを出したばかりなので、Web開発者を気にかけているとは言える。
- LinuxやOS XでIEをテストしていたのと同じことだ。
最近はエージェントにChromeを起動させてCDPで直接通信するよう指示しているが、かなりうまく動いている。
- そのやり方も一度試してみるべきだな。
  Playwrightと比べてどうなのか気になる。
  Web開発の観点では、複数ブラウザーで使えることがPlaywrightの利点に見える。
  ブラウザーごとのツールのほうが速かったりトークン効率が良かったりするなら、作業の自動化やClawsにはそちらのほうが良い選択かもしれない。
- その通り。このやり方はMCP経路よりはるかにうまく動くし、より速い。
「Webを作る方法は、AIを使うかどうかに関係なくたくさんあります。AIが作業フローの一部なら、このツールは生産性向上に役立つと思います。そうでなくても、それはそれで構いません。」
2026年にこういうことを言うのは妙だ。
自分でコードを書いてすべてをエージェントに委ねないと、一部の人からは初心者扱いされる時代だからだ。
- 2年前なら、その逆のほうがばかげた話だと扱われていた。
  今ではAIを使っている人たちがその事実を隠さなくてよくなったのは良いことだ。
- どの部分が変なのか分からない。
  熱狂的な反AI陣営をなだめるために、こんな免責めいた文言を入れなければならなかった点が変だということか。
  これは明らかにAI支援開発のためのツールなのに、「AIを使わない皆さんにもエールを送ります」みたいな一文を添えなければならなかったことのほうが、むしろ非常に妙だ。
  ただし、君が考えている方向とは違う意味で妙だ。
ブラウザー自動化向けMCPが興味深いのは、SafariのWebKitエンジンがほとんどのAIエージェントにとって容易に扱えない側だからだ。
PlaywrightとPuppeteerはChromium中心なので、Safari向けMCPサーバーがあれば、エージェントのワークフローにおけるクロスブラウザーテストの実際の空白を埋められるかもしれない。

Web開発者向けSafari MCPサーバー

Safari MCPサーバーの役割

デバッグの往復を減らす仕組み

主なユースケース

SafariでのWeb開発

Safari互換性の改善

パフォーマンス分析

アクセシビリティ点検

ユーザー状態の検証

提供ツール

始め方

プロンプトとエージェントの動作

ローカル実行とデータ処理

WebKitが期待する活用

関連記事

2件のコメント

Hacker Newsのコメント