Macでウェブサイトのスクリーンショットを一括で撮影する方法
MacでTemposhotを使い、ウェブサイトのスクリーンショットを一括で撮影します。URLリストを貼り付け、デスクトップ・タブレット・モバイルのプリセットを選び、並列撮影を実行して監査やレポート用に書き出せます。
12分で読めますWebサイトキャプチャ作成者:Temposhot Team

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

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点を確認します。
- Capture History における各セッションのステータス。Partial は一部のURLが失敗したことを示します。Cancelled は実行が停止されたことを示し、完了済みのフレームは残ります。
- フレーム数と完了した行数の比較。両者が一致しない場合は、フレームが書き出し対象に選択されていないことを示します。撮影の問題ではなく、選択の問題です。
- 各行の最初のフレーム。バナー、ログインフォーム、空白ページが写っているフレームは、行が 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数を同時実行数で割り、ページごとの平均時間を掛けて求めます。
例として、1ページあたり6秒の40件のバッチを考えます。40を4で割ると10ラウンドで、10ラウンド×6秒は60秒です。同じリストを同時実行数1で実行すると、40×6で240秒かかり、4倍の時間になります。同時実行数を増やすと全体の時間は減りますが、ページごとの待ち時間は減りません。Delay を4秒に設定したページは、所属するすべてのラウンドで4秒ずつ加算されます。
実際の所要時間は、これより長くなる場合があります。ページごとの読み込み時間は一定ではなく、20秒かかるページは、その間ずっとブラウザの枠を占有します。最初の8件をテストとして実行し、結果からページごとの時間を読み取ってから、全体の所要時間を計算します。
用途に合わせてデバイスと撮影範囲を選ぶ
既定値は、すべてのフレームの見た目を決めます。バッチで答えたい問いに合わせて選び、その後は固定します。
Full page で撮影した長いページのフレームは高さが大きく、Viewport のフレームより目視で比較しにくくなります。1920 × 1080 の Desktop ビューポートの場合、高さ10000ピクセルのページは、ビューポートのおよそ9倍の高さのフレームになります。レビューには Full page のバッチを、同じURLの素早い確認には Viewport のバッチを使います。
レスポンシブ確認では、デバイスごとに1行を使います。下の表は、モバイルのバッチの1行の設定を示しています。
モバイルのフレームは幅が狭いため、既定サイズのテキストは Desktop サイズのレポートでは小さく見えます。実行前に、プレビューを原寸で確認します。文字が読みにくい場合は、レポートには Desktop を、レスポンシブ確認には Mobile を使います。
モバイルのバッチのすべてのページで、同じ行の設定を使います。1行だけ Delay やデバイスが異なると、ページとは無関係な理由でフレームの見た目が変わります。
失敗した行の切り分け
失敗した行だけでは原因を特定しにくいため、固定の順序で原因を確認します。次の手順は、コストの低い確認から順に並べています。
下の図は、行が通る状態を示しています。Capture failed になった行は Retry でキューに戻せ、再試行は Retry pending から始まります。
次のショートカットは、バッチセッションで使うキーを示しています。
最初の手順で、大半の失敗を見つけられます。パスが欠けているURLやタイプミスのあるURLは、実行前に「Enter a valid HTTP or HTTPS URL」というメッセージを表示します。そのため、実行中の失敗は通常、ページ、待機条件、Mac の負荷のいずれかが原因です。原因となった設定を変更してから、その行を再試行します。同じ設定で再試行すると、通常は同じ失敗を繰り返します。
一部のサイトは、自動化されたブラウザを意図的に拒否します。すべての設定で失敗し、URLに関するエラーが表示されない行は、通常このようなサイトです。Website Capture はブロックを回避しようとしません。その行は失敗として記録し、スクリーンショットは手作業で撮るか、サイトの運営者にエクスポートを依頼します。
切り分け後も失敗のままの行は、手作業で撮影するための短いリストにまとめます。各行の横に「ログインが必要」「サイトが自動化されたブラウザをブロックしている」などの理由を書き、バッチ内の欠落の理由がわかるようにします。
完了したバッチを検証する
完了したバッチは、レポートに入れる前に確認します。次のチェックリストを順に確認します。
セッションの最初、中間、最後のフレームを開きます。ログイン画面、同意を求める画面、エラーページが読み込まれたページは、ファイル一覧では成功に見えます。目視で確認すると、ステータスでは分からない問題を見つけられます。
バッチを受け取る人にとって、フォルダの構成も重要です。バッチ名に合わせたツリーにすると、ファイルを見つけやすくなります。
毎月の監査の結果を比較可能に保つ
毎月実行するバッチは、設定とURLリストが変わらない場合にのみ比較できます。設定はセッション名と一緒にメモとして保存します。典型的な記録には、デバイス、撮影範囲、待機条件、Delay、Cookie の設定、形式、同時実行数に加えて、URL数と完了件数を含めます。
たとえば、毎月第1月曜日に実行する60件の監査で、完了が52件、失敗が8件だった場合、完了率は87%です。翌月に完了が60件になった場合、増えた8件は、リストの変更またはサイト側の変更で説明できます。保存済みの設定がないと、この比較は信頼できません。待機条件やデバイスが変わっていると、増加の一部がそれで説明できてしまうためです。
URLリストは、共有フォルダに固定のファイルとして保存します。ページを追加または削除したときだけリストを編集し、変更日を記録します。こうすると、リスト自体が監査の対象ページの記録にもなります。
1つのバッチで複数のデバイスを混在させる
1つのバッチで複数のデバイスを混在させることは、混乱した結果の最も一般的な原因です。レビュー担当者は390ピクセルのフレームと1920ピクセルのフレームを並べて見ると、ページが異なると判断しがちです。バッチごとにデバイスを1つにし、2つ目のデバイスは同じURLリストで別のセッションとして実行します。
最初のURLバッチを撮影する
Website Capture を開く
サイドバーの Website Capture を選択するか、Command+2 を押します。
URLを追加する
Bulk insert を選択し、1行に1つずつURLを貼り付けて、Insert URLs を選択します。重複行はスキップされます。
example.comのようなドメインのみの入力にはhttps://が追加されます。受け付けるのは HTTP と HTTPS のアドレスだけです。URLを1つ追加するには、最後の行に入力して Enter を押します。既定値を設定する
Device(Desktop 1920×1080、Tablet 768×1024、Mobile 390×844のいずれか)と Area(Viewport または Full page)を選びます。待機条件と画像形式を選択します。
1行ごとに設定を上書きする
1ページだけ異なる待機条件やデバイスが必要な場合は、その行の設定を開きます。実行前に結果を確認するには、Render preview を選択します。
同時実行数を設定して開始する
Concurrent browsers を1から10の間で設定し(既定値は4)、Start Capture を選択します。
各行は独自の状態を順に移ります。Capture pending、Capturing、そして Capture complete または Capture failed です。1行が失敗しても、他の行は停止しません。
よくあるバッチ撮影の用途
| 用途 | Device | Area | 書き出し |
|---|---|---|---|
| リニューアル前後の記録 | Desktop | Full page | |
| 競合のランディングページのレビュー | Desktop | Viewport | Images |
| 小規模サイトのレスポンシブ確認 | Mobile、その後 Desktop | Full page | ZIP |
| 公開ページの日付付き記録 | Desktop | Full page | |
| サイトの主要ページの短い操作動画 | Desktop | Viewport | MP4 |
レスポンシブ確認では、同じリストを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、ブロック設定を同じにします。
- Wait. ほとんどのサイトには Load が適しています。読み込み後にコンテンツを取得するページには Network idle が役立ちます。1から3秒の Delay は、アニメーションの完了を待つのに役立ちます。
- Lazy images. スクロールして表示領域に入ったときにだけ画像を読み込むページは、フルページ撮影で全体を一度スクロールする処理が必要です。Network idle の待機条件では、これが常に行われるとは限りません。フルページのフレームに画像の領域が空白で写る場合は、その行を Network idle に切り替え、短い Delay を追加します。原因の説明は lazy loading の項目にあります。
- Cookie banners. Reject banners、Accept minimal、Hide only、Leave unchanged から選びます。処理はベストエフォートのため、独自の同意管理ツールを使うサイトでは、プレビューを確認します。
- Format. 既定は JPEG です。小さな文字をくっきり残す必要がある場合は PNG、ファイルサイズを小さくしたい場合は WebP を使います。画質の1から100の値は、JPEG と WebP に適用されます。
- Blocking. Block ads と Block trackers は既定でオンです。レイアウトがブロックされたスクリプトに依存する行では、その行だけオフにします。
URLごとの設定の一覧は、キャプチャオプションのガイドにあります。
FAQ
1つのバッチに URL は何件まで入れられますか?
URLリストに固定の上限はありません。実用上の上限は、1回の実行にかかる時間と、実行後に確認しやすいかどうかです。
失敗したページだけを再試行できますか?
はい。失敗または中止された各行には Retry コントロールが表示され、他の行の完了を待たずに実行できます。行の状態の一覧は、実行と結果のガイドにあります。
1ページを2つの幅で撮影できますか?
はい。同じURLで異なるデバイスを設定した2つの行を使います。各行は独自の設定を保持するため、Desktop の行と Mobile の行を同じセッションで実行できます。公平に比較するには、両方の行でそれ以外の設定を同じにします。プレビューには、そのフレームが使うデバイスサイズが表示されるため、実行前に各行のプレビューを確認します。
Cookie はバッチをまたいで保持されますか?
いいえ。各ページは、実行の間に 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で書き出します。
関連記事
- Mac 向けスクリーンショット自動化ツールのおすすめ (2026年版)自動スクリーンショットに使う Mac のツールを選びます。時間指定の間隔、クリックごとの 1 枚、URL 一覧のバッチ、検索可能な PDF に対応し、Temposhot、Snagit、CleanShot X を比較します。
- CleanShot X と Snagit の比較:どちらのスクリーンショットアプリが作業に合うかMac 版の CleanShot X と Snagit を、キャプチャと録画、編集、ステップガイド、OCR、共有、Windows 対応、販売形態で比較します。
- 2026年版 Mac向け Shottr の代替アプリ比較Mac向け Shottr 代替アプリを比較します。繰り返しキャプチャ、画面録画と共有リンク、自動マスキング、クロスプラットフォーム対応、標準アプリを扱います。
- 2026 年版: Mac 向け Xnapper の代替アプリ比較Mac 向け Xnapper の代替アプリを、繰り返し撮影、スクロールキャプチャと録画、無料の背景、クロスプラットフォームのガイド、標準搭載アプリの観点で比較します。