コンテンツへスキップ

Macでウェブサイトのスクリーンショットを一括で撮影する方法

MacでTemposhotを使い、ウェブサイトのスクリーンショットを一括で撮影します。URLリストを貼り付け、デスクトップ・タブレット・モバイルのプリセットを選び、並列撮影を実行して監査やレポート用に書き出せます。

12分で読めますWebサイトキャプチャ作成者:Temposhot Team

Website Capture of three URLs with four concurrent browsers

30ページを手作業で撮影するには、開く、待つ、スクロールする、保存するという操作を30回繰り返す必要があります。一括実行では、URLリストを一度読み込むと、各URLをローカルのブラウザで開き、URLごとに1枚の画像を保存します。この記事では、Temposhot の Website Capture で一括実行する手順と、結果を揃えるための設定を説明します。

Website Capture of three URLs with four concurrent browsers

Webクローラーとは何ですか?

Webクローラーは1つのアドレスから開始し、リンクをたどってページを探索します。Website Capture はこの動作を行いません。リストに入力されたURLだけを撮影し、1行につき1枚のフレームを作成します。リンクを自動でたどることはありません。

そのため、出力を予測できます。40件のURLを入力すると、フレームは最大40枚になり、各フレームは入力した行と1対1で対応します。サイト全体を撮影する場合は、先にページ一覧を書き出します(サイトマップファイル、CMS、アクセス解析レポートなど)。その後、その一覧をWebsite Captureに貼り付けます。

各フレームは1つのセッションとして Capture History に保存されます。バッチは後から再度書き出せ、ページを再読み込みする必要はありません。

貼り付け前にURLリストを整える

整ったリストは、時間の浪費と結果の混乱を防ぎます。貼り付け前に次の3点を確認します。

  • 元データに重複がある場合は、手作業で削除します。Temposhot は重複行をスキップしますが、監査用に保持するリストは元のサイトマップやレポートと一致させます。
  • トラッキングパラメータの扱いを決めます。?utm_source=newsletter 付きのURLは、通常パラメータなしのURLと同じページを表示します。ただし、サイトによってはパラメータで内容が変わります。訪問者が実際に使うURLをそのまま保持します。
  • 順序に意味を持たせます。フレームは行の順に並ぶため、レポートで読む順序が重要な場合は、セクション順、次にパス順で並べ替えます。

400ページのサイトを100件ずつに分けると、セッションは4つになります。各セッションは個別に確認と再実行ができ、1つのセッションの失敗行は他のセッションに影響しません。pricing-pages-2026-11 や docs-part-2 のようにバッチに名前を付けておくと、Capture History のエントリとレポートを対応させやすくなります。

結果ペインを確認する

実行が終わると、結果ペインにセッションのすべてのフレームが表示されます。書き出す前に次の3点を確認します。

  1. Capture History における各セッションのステータス。Partial は一部のURLが失敗したことを示します。Cancelled は実行が停止されたことを示し、完了済みのフレームは残ります。
  2. フレーム数と完了した行数の比較。両者が一致しない場合は、フレームが書き出し対象に選択されていないことを示します。撮影の問題ではなく、選択の問題です。
  3. 各行の最初のフレーム。バナー、ログインフォーム、空白ページが写っているフレームは、行が Capture complete と表示されていても、撮影結果としては失敗です。

バッチを1ページ1フレームのDocumentにする場合は、Create Document を選択します。レビュー担当者にファイルとして渡す場合は、書き出しボタンの ZIP、Images、PDF、MP4 を使います。

用途ごとの書き出し形式

レビュー担当者がファイルをどう使うかで形式を選びます。

  • PDF は、順番に読んで印刷するレポートに適しています。各ページにフレームが含まれるため、レビュー担当者が1枚ずつファイルを開く必要はありません。
  • ZIP は、チームが自分のツールで画像を開く場合に適しています。アーカイブには、編集を加えていない元のキャプチャが保存されます。
  • Images は、PNGファイルを読み込む別のツールで使うフォルダに適しています。たとえば、PNGファイルを取り込むデザインレビューボードなどです。
  • MP4 は、操作の説明動画に適しています。各フレームは書き出し設定で選んだフレームレートで再生されます。30フレームを毎秒1フレームで再生すると、30秒の動画になります。

書き出し設定シートには、各形式の画質とフレームレートがあります。保存済みのファイルは実行時の値を保持するため、書き出し前に設定を確認します。

大きなバッチの前に所要時間を見積もる

バッチの所要時間は、全ページの合計ではなく、最も遅いラウンドの時間におおむね等しくなります。Concurrent browsers を4にすると、4ページが同時に読み込まれ、ブラウザが空くと次のページが始まります。見積もりは、URL数を同時実行数で割り、ページごとの平均時間を掛けて求めます。

ページあたり6秒の40件のバッチを4つの同時ブラウザで処理するタイムライン。URL 1から4は0:00に開始、URL 5から8は0:06に開始、URL 37から40は0:54に開始し、バッチは約1:00に終了する。

例として、1ページあたり6秒の40件のバッチを考えます。40を4で割ると10ラウンドで、10ラウンド×6秒は60秒です。同じリストを同時実行数1で実行すると、40×6で240秒かかり、4倍の時間になります。同時実行数を増やすと全体の時間は減りますが、ページごとの待ち時間は減りません。Delay を4秒に設定したページは、所属するすべてのラウンドで4秒ずつ加算されます。

40件の例の3つの数値。4つのブラウザで10ラウンド、1ページ6秒でバッチ全体が60秒、同時実行数1では240秒。

実際の所要時間は、これより長くなる場合があります。ページごとの読み込み時間は一定ではなく、20秒かかるページは、その間ずっとブラウザの枠を占有します。最初の8件をテストとして実行し、結果からページごとの時間を読み取ってから、全体の所要時間を計算します。

用途に合わせてデバイスと撮影範囲を選ぶ

既定値は、すべてのフレームの見た目を決めます。バッチで答えたい問いに合わせて選び、その後は固定します。

Viewport と Full page の比較。保存される領域、適した用途、フレームの高さの決まり方を示す。

Full page で撮影した長いページのフレームは高さが大きく、Viewport のフレームより目視で比較しにくくなります。1920 × 1080 の Desktop ビューポートの場合、高さ10000ピクセルのページは、ビューポートのおよそ9倍の高さのフレームになります。レビューには Full page のバッチを、同じURLの素早い確認には Viewport のバッチを使います。

レスポンシブ確認では、デバイスごとに1行を使います。下の表は、モバイルのバッチの1行の設定を示しています。

モバイルのバッチの1行の設定。デバイスは390 by 844、撮影範囲は Full page、待機条件は Network idle、Delay は2秒、Cookie バナーは拒否、画像形式は PNG、ブロック機能はオン。

モバイルのフレームは幅が狭いため、既定サイズのテキストは Desktop サイズのレポートでは小さく見えます。実行前に、プレビューを原寸で確認します。文字が読みにくい場合は、レポートには Desktop を、レスポンシブ確認には Mobile を使います。

モバイルのバッチのすべてのページで、同じ行の設定を使います。1行だけ Delay やデバイスが異なると、ページとは無関係な理由でフレームの見た目が変わります。

失敗した行の切り分け

失敗した行だけでは原因を特定しにくいため、固定の順序で原因を確認します。次の手順は、コストの低い確認から順に並べています。

下の図は、行が通る状態を示しています。Capture failed になった行は Retry でキューに戻せ、再試行は Retry pending から始まります。

バッチ中の行の流れ。Capture pending から Capturing を経て Capture complete または Capture failed になり、失敗した行は Retry で Retry pending に戻る。

次のショートカットは、バッチセッションで使うキーを示しています。

バッチセッションのショートカット一覧。Command+2 で Website Capture を開き、Enter で現在の行の下に新しい行を追加する。
失敗した行の切り分けの5つの手順。URLを確認する、待機条件を Load に変えて短い Delay を追加する、ブロック機能をオフにする、同時実行数を下げる、行を再試行する。

最初の手順で、大半の失敗を見つけられます。パスが欠けているURLやタイプミスのあるURLは、実行前に「Enter a valid HTTP or HTTPS URL」というメッセージを表示します。そのため、実行中の失敗は通常、ページ、待機条件、Mac の負荷のいずれかが原因です。原因となった設定を変更してから、その行を再試行します。同じ設定で再試行すると、通常は同じ失敗を繰り返します。

一部のサイトは、自動化されたブラウザを意図的に拒否します。すべての設定で失敗し、URLに関するエラーが表示されない行は、通常このようなサイトです。Website Capture はブロックを回避しようとしません。その行は失敗として記録し、スクリーンショットは手作業で撮るか、サイトの運営者にエクスポートを依頼します。

切り分け後も失敗のままの行は、手作業で撮影するための短いリストにまとめます。各行の横に「ログインが必要」「サイトが自動化されたブラウザをブロックしている」などの理由を書き、バッチ内の欠落の理由がわかるようにします。

完了したバッチを検証する

完了したバッチは、レポートに入れる前に確認します。次のチェックリストを順に確認します。

完了したバッチの4つのチェック項目。すべての行に最終状態がある、フレーム数が完了した行数と一致する、デバイス、撮影範囲、待機条件が行間で一致する、失敗した各行に理由が記録されている。

セッションの最初、中間、最後のフレームを開きます。ログイン画面、同意を求める画面、エラーページが読み込まれたページは、ファイル一覧では成功に見えます。目視で確認すると、ステータスでは分からない問題を見つけられます。

バッチを受け取る人にとって、フォルダの構成も重要です。バッチ名に合わせたツリーにすると、ファイルを見つけやすくなります。

2つのバッチフォルダを含む納品フォルダのファイルツリー。料金ページのデスクトップ版とドキュメントページのモバイル版があり、それぞれに書き出した PDF と notes.txt がある。

毎月の監査の結果を比較可能に保つ

毎月実行するバッチは、設定とURLリストが変わらない場合にのみ比較できます。設定はセッション名と一緒にメモとして保存します。典型的な記録には、デバイス、撮影範囲、待機条件、Delay、Cookie の設定、形式、同時実行数に加えて、URL数と完了件数を含めます。

たとえば、毎月第1月曜日に実行する60件の監査で、完了が52件、失敗が8件だった場合、完了率は87%です。翌月に完了が60件になった場合、増えた8件は、リストの変更またはサイト側の変更で説明できます。保存済みの設定がないと、この比較は信頼できません。待機条件やデバイスが変わっていると、増加の一部がそれで説明できてしまうためです。

URLリストは、共有フォルダに固定のファイルとして保存します。ページを追加または削除したときだけリストを編集し、変更日を記録します。こうすると、リスト自体が監査の対象ページの記録にもなります。

1つのバッチで複数のデバイスを混在させる

1つのバッチで複数のデバイスを混在させることは、混乱した結果の最も一般的な原因です。レビュー担当者は390ピクセルのフレームと1920ピクセルのフレームを並べて見ると、ページが異なると判断しがちです。バッチごとにデバイスを1つにし、2つ目のデバイスは同じURLリストで別のセッションとして実行します。

比較可能なバッチフレームのための do と dont の一覧。バッチごとにデバイスを1つにする、各デバイスで同じURLリストを実行する、Viewport と Full page を1つのバッチに混在させない、理由を書かずに1行だけ変更しない。

最初のURLバッチを撮影する

  1. Website Capture を開く

    サイドバーの Website Capture を選択するか、Command+2 を押します。

  2. URLを追加する

    Bulk insert を選択し、1行に1つずつURLを貼り付けて、Insert URLs を選択します。重複行はスキップされます。example.com のようなドメインのみの入力には https:// が追加されます。受け付けるのは HTTP と HTTPS のアドレスだけです。URLを1つ追加するには、最後の行に入力して Enter を押します。

  3. 既定値を設定する

    Device(Desktop 1920×1080、Tablet 768×1024、Mobile 390×844のいずれか)と Area(Viewport または Full page)を選びます。待機条件と画像形式を選択します。

  4. 1行ごとに設定を上書きする

    1ページだけ異なる待機条件やデバイスが必要な場合は、その行の設定を開きます。実行前に結果を確認するには、Render preview を選択します。

  5. 同時実行数を設定して開始する

    Concurrent browsers を1から10の間で設定し(既定値は4)、Start Capture を選択します。

各行は独自の状態を順に移ります。Capture pending、Capturing、そして Capture complete または Capture failed です。1行が失敗しても、他の行は停止しません。

よくあるバッチ撮影の用途

用途DeviceArea書き出し
リニューアル前後の記録DesktopFull pagePDF
競合のランディングページのレビューDesktopViewportImages
小規模サイトのレスポンシブ確認Mobile、その後 DesktopFull pageZIP
公開ページの日付付き記録DesktopFull pagePDF
サイトの主要ページの短い操作動画DesktopViewportMP4

レスポンシブ確認では、同じリストを2回実行します。1回目は Mobile、2回目は Desktop です。バッチごとにデバイスを1つにすると、フレームを比較しやすくなります。

大規模バッチの上限

Website Capture は Mac 上で動作するため、実用上の上限はメモリと CPU によって決まります。Concurrent browsers は、同時に読み込むページ数を制御します。既定値の4が妥当な出発点です。値を大きくすると完了は早くなりますが、メモリの使用量が増えます。

その他に考慮すべき上限は次のとおりです。

  • サインインしたセッションが必要なページは、サインアウトした訪問者に見える状態で撮影されます。Website Capture は公開ページで最もよく動作します。
  • 一部のサイトは自動化されたブラウザを拒否します。その行は Capture failed で終了します。
  • 停止された実行は、完了済みのフレームをすべて保持し、セッションは Cancelled と表示されます。
  • 完了行と失敗行が両方ある実行は、Partial と表示されます。

数百件のURLリストは、50から100件ずつのバッチに分けると、各セッションを確認と再実行しやすくなります。

ノートパソコンでのメモリと同時実行数

同時に実行するブラウザは、それぞれメモリと CPU を使います。負荷はページによって異なります。ニュースのトップページや動画を含むダッシュボードなどの重いページは、テキストのみのページより多くを使います。既定値の4から始め、最初のラウンド中はアクティビティモニタで状態を確認します。メモリの圧迫が強まり、Mac がスワップを多用する状態になったら、次のバッチで Concurrent browsers を下げます。2で90秒で完了するバッチは、8で停止して3回の再試行が必要になるバッチより優れています。

所要時間の例の値も、同じように比例します。同時実行数10では、40件のバッチは4ラウンド、1ページ6秒の場合で約24秒で完了しますが、メモリの使用量は既定値の2.5倍になります。Mac がスワップせずに扱える範囲で最も高い値を選びます。

バッチ撮影を改善する

バッチを比較に使えるのは、すべてのページが同じ方法で撮影されたときだけです。例外が必要なページがない限り、行ごとにデバイス、撮影範囲、待機条件、Delay、ブロック設定を同じにします。

  1. Wait. ほとんどのサイトには Load が適しています。読み込み後にコンテンツを取得するページには Network idle が役立ちます。1から3秒の Delay は、アニメーションの完了を待つのに役立ちます。
  2. Lazy images. スクロールして表示領域に入ったときにだけ画像を読み込むページは、フルページ撮影で全体を一度スクロールする処理が必要です。Network idle の待機条件では、これが常に行われるとは限りません。フルページのフレームに画像の領域が空白で写る場合は、その行を Network idle に切り替え、短い Delay を追加します。原因の説明は lazy loading の項目にあります。
  3. Cookie banners. Reject banners、Accept minimal、Hide only、Leave unchanged から選びます。処理はベストエフォートのため、独自の同意管理ツールを使うサイトでは、プレビューを確認します。
  4. Format. 既定は JPEG です。小さな文字をくっきり残す必要がある場合は PNG、ファイルサイズを小さくしたい場合は WebP を使います。画質の1から100の値は、JPEG と WebP に適用されます。
  5. Blocking. Block ads と Block trackers は既定でオンです。レイアウトがブロックされたスクリプトに依存する行では、その行だけオフにします。

URLごとの設定の一覧は、キャプチャオプションのガイドにあります。

FAQ

1つのバッチに URL は何件まで入れられますか?

URLリストに固定の上限はありません。実用上の上限は、1回の実行にかかる時間と、実行後に確認しやすいかどうかです。

失敗したページだけを再試行できますか?

はい。失敗または中止された各行には Retry コントロールが表示され、他の行の完了を待たずに実行できます。行の状態の一覧は、実行と結果のガイドにあります。

1ページを2つの幅で撮影できますか?

はい。同じURLで異なるデバイスを設定した2つの行を使います。各行は独自の設定を保持するため、Desktop の行と Mobile の行を同じセッションで実行できます。公平に比較するには、両方の行でそれ以外の設定を同じにします。プレビューには、そのフレームが使うデバイスサイズが表示されるため、実行前に各行のプレビューを確認します。

いいえ。各ページは、実行の間に Cookie やサイトデータを保持しないプライベートなブラウザセッションで開かれます。同意の選択に依存するバッチでは、各行に Cookies オプションを設定する必要があります。認識されないバナーは、フレームに残ります。

どの形式で書き出せますか?

結果ペインでは ZIP、Images、PDF、MP4 を書き出せます。PDF は OCR でテキストを認識するため、検索可能です。

ログインの後ろにあるページも撮影できますか?

Website Capture は、普段使うブラウザのプロファイルではなく、管理されたローカルブラウザでページを読み込みます。サインインが必要なページには、Chrome の Temposhot 拡張機能を使います。これは、アクティブなタブのフルページ PNG を1枚保存します。

バッチ撮影を開始する

よく確認するURLを5件、Website Capture に貼り付け、既定の同時実行数4で実行します。その後、長いリストを実行する前に、1行で Render preview を使って Viewport と Full page を比較します。

ノーコードでWebサイトのスクリーンショットを自動化しますか?

Webサイトスクリーンショット自動化のページでは、Website Capture の機能を説明しています。最初の実行は Website Capture クイックスタートで確認できます。Temposhot は Apple Silicon の Mac 向けに、ダウンロードから無料で入手できます。

website-capturebatch-screenshotsmacurls

このページで使用する用語: full page screenshot, responsive screenshot, viewport screenshot

繰り返し撮影するスクリーンショットを、完成したデータに仕上げます

Temposhotは、タイマーまたはクリックごとに撮影し、結果をPDF、画像、ZIP、MP4で書き出します。

関連記事