Webサイトのスクリーンショット取得に使える Stillio の代替ツール

Stillio は、Webサイトのスクリーンショットを定期的に取得し、オンラインのアーカイブに保存するホスト型サービスです。コンプライアンスの記録、広告の確認、競合の追跡、ブランドのモニタリングに使われています。すべてのチームが同じ機能を必要とするわけではありません。オンデマンドで取得したいチーム、アーカイブよりアラートを必要とするチーム、自社のインフラですべて実行したいチームがあります。以下の5つのツールが、それぞれのニーズに対応します。

各ツールの製品情報、プラン、価格は変更されることがあります。判断する前に、各ベンダーの公式サイトで現在の内容を確認してください。

Stillio の代替ツール一覧

ツール	種類	実行環境	スケジュール	変更アラート	コードの必要性
Temposhot	Mac アプリ	お使いの Mac	なし	なし	不要
Visualping	ホスト型モニタリングサービス	ベンダーのサーバー	あり	あり	不要
ScreenshotOne	スクリーンショットAPI	ベンダーのサーバー	独自のコードで実装	なし	必要
Urlbox	スクリーンショットAPI	ベンダーのサーバー	独自のコードで実装	なし	必要
changedetection.io	変更検知、オープンソース	セルフホストまたはホスト型	あり	あり	不要

主な違いは、ユーザーが操作しなくてもスケジュールに従って実行されるサービス（Stillio、Visualping、changedetection.io）と、ユーザーが自分で実行するツール（Temposhot、またはスクリプトから呼び出すAPI）の間にあります。

比較前に答える質問

各ツールは異なる問いに答えます。リストを見る前に、自分の問いを1文で書き出してください。「このページは月曜日以降に変わったか」はモニタリングサービス向けの問いです。「毎月1日の料金ページはどう見えていたか」は日付付きのアーカイブ向けの問いです。「自社の製品で任意のURLのライブのスクリーンショットを表示できるか」はAPI向けの問いです。

以下のチェックリストで、この問いを選択を決める具体的な項目に分解します。

多くのチームにとって、最初の2つの答えでツールの種類が決まります。残りの4つは、デバイスサイズ、保存先、出力を受け取る担当者といった詳細を決めます。

1. Temposhot

Temposhot は、スクリーンショットを自動取得する macOS アプリです。Website Capture モードでは、貼り付けたURLの一覧を受け取り、お使いの Mac 上の管理されたブラウザで各ページを取得します。

主な機能は次のとおりです。

• デバイスサイズ: Desktop 1920×1080、Tablet 768×1024、Mobile 390×844
• Area: Viewport または Full page
• Wait: Load、DOM content loaded、Network idle。0～60秒の Delay を設定可能
• フォーマット: JPEG、PNG、WebP。品質は1～100
• クリーンアップ: Block ads、Block trackers、ベストエフォートのCookieバナー処理
• 速度: 同時実行ブラウザ数は1～10（既定値は4）。行ごとに Cancel と Retry が可能
• 書き出し: ZIP、Images、検索可能な PDF、MP4

Stillio と比べた制約は次のとおりです。Temposhot は Apple シリコン搭載の Mac でのみ動作し、アプリが開いている間、かつユーザーが実行を開始したときにのみ動作します。クラウドのスケジューラー、ホスト型アーカイブ、チーム共有のダッシュボード、変更アラートはありません。すべてのデータはローカルに保存されるため、URLの一覧やキャプチャを第三者のサーバーに置きたくないチームに適しています。

適した用途: 監査、リデザインの記録、クライアント向けレポートなど、公開ページのオンデマンドの一括取得。最初の実行は Website Capture クイックスタート で確認できます。

クライアントアーカイブの実行手順

コンサルタントが、公開ページ60件のクライアントアーカイブを管理しています。アーカイブには、毎月最初の営業日に、各ページの Desktop と Mobile のキャプチャが必要です。Temposhot は、ユーザーが毎回手動で実行を開始する前提であれば、サーバーなしでこの作業に対応できます。以下の手順では、毎月同じ結果になるように各値を意図的に設定します。

コンサルタントは Desktop と Mobile を別々のバッチとして実行します。各バッチでデバイスサイズを1つに固定するため、比較セット内の画像は同じ寸法になります。ほとんどのクライアントサイトでは Wait を Load のままにし、読み込みが遅いページにのみ Network idle を使います。

JPEG アーカイブでは、品質85が妥当な設定です。この品質では文字が鮮明なまま保たれ、フルページの場合は同じページの PNG よりファイルサイズが小さくなります。小さな文字を正確に残す必要があるページには PNG が適しており、同じページでもファイルサイズは大きくなります。

60URLのバッチ サイズの見積もり

60件のURLを2つのデバイスサイズで取得すると、120件のキャプチャになります。コンサルタントはデバイスごとに作業を分けるため、各バッチは60行になります。既定の同時実行ブラウザ数4では、4行が同時にキャプチャされ、残りの行はブラウザの空きが出るまでキューで待機します。バッチの所要時間はページによって変わるため、コンサルタントは最初の月次実行の時間を測定し、次回以降の基準として使います。

1行の失敗はバッチを止めません。Capture failed の行はセッション内にそのまま残り、表示された時点で Retry を押すと Retry pending に移ります。書き出しの前に失敗した行を確認してください。失敗の原因は、ガイドに記載されている無効なURL、待機時間内に読み込みが完了しなかったページ、ブロックされたページ、メモリ不足の Mac のいずれかです。

タイムラインの時刻は1人のコンサルタントを想定した計画であり、ベンチマークではありません。手順の順序は維持し、時刻は最初の実行で得られた値に置き換えてください。

比較に使うデバイスサイズを選ぶ

比較では、両側のデバイスサイズを同じにする必要があります。Temposhot には3つのデバイスプリセットがあり、それぞれがブラウザのビューポートを設定します。Desktop（1920×1080）は、ほとんどのマーケティングページやダッシュボードに適しています。Tablet（768×1024）は、タブレット幅でレイアウトが変わるページに適しています。Mobile（390×844）は、スマートフォンで閲覧されることを前提とするページに適しています。

バッチごとにデバイスを1つ選び、もう一方のデバイス用に別のバッチを実行してください。同じフォルダーに異なるサイズを混在させると、同じページの2枚の画像の幅が一致しなくなり、レビューが難しくなります。Desktop と Mobile のキャプチャを比べると、サイトの実際の変更ではないレイアウトの差が表示されてしまいます。

Full page と Viewport

Viewport は、選択したデバイスサイズで表示中のブラウザ領域のみを保存します。これは「訪問者が最初に見るもの」に答えます。Full page は、スクロール可能なページ全体を保存します。これは「このページに何があるか」に答えます。アーカイブには通常 Full page が必要です。Viewport では最初の画面より下の内容が写らないためです。

Full page のキャプチャは縦に長くなるため、保存に時間がかかり、ディスク容量も多く使います。6画面分の内容があるランディングページは、Viewport では6枚の画像になりますが、Full page では縦に長い1枚の画像になります。ファーストビューの確認には Viewport を使い、例えばローンチレビューでヒーローセクションを確認する場合などに使ってください。記録用には Full page を使います。

読み込みの遅いページ向けの Wait と Delay

Wait は、キャプチャのタイミングを決めます。Load は標準の load イベントを待つため、ほとんどのサイトに適しています。DOM content loaded は画像やスタイルの読み込み完了前にキャプチャするため、スタイルが一部しか適用されていない画像になることがあります。Network idle はバックグラウンドのリクエストが止まるまで待つため、後から内容を読み込むページに適しています。ただし、ポーリングを続けるページではタイムアウトすることがあります。

キャプチャに空白の領域が出る場合は、次の順序で対処します。

1. Load のまま Delay を1～3秒に設定する。遅れて表示されるウィジェットやアニメーションに対応できます。
2. ページがリクエストを止める場合は、同じ Delay を設定したうえで Network idle に切り替える。
3. 空白が一部の行にしか出ず、Mac のメモリが不足している場合は Concurrent browsers を2に下げる。

Delay の範囲は0～60秒です。各行はキャプチャ前に Delay の時間だけ待機するため、コンテンツが表示される最短の値を設定してください。

後から検索しやすいファイル名を付ける

アーカイブは、ファイルを名前で探せて初めて役に立ちます。クライアント名、日付、デバイス、ページのスラッグを含む名前は、Finder や任意の検索ツールで整列しやすくなります。例えば client-a_2026-11_desktop_pricing.png は、ファイルを開かなくてもページ、月、サイズが分かります。

アーカイブ全体で1つの命名規則を使い、画像だけでなく ZIP のファイル名にも同じ規則を適用してください。そうすると、10月と11月の ZIP が、内部のページと同じ順序で並びます。

上記のツールは、ライブのページではなく出力ファイルを対象とします。Compare Images は、同じページの2か月分の差分を表示します。Resolution Checker は、Mobile のキャプチャが報告書に入れる前に幅390ピクセルであることを確認します。Image to PDF と Merge PDF は、1つの文書にまとめたいクライアント向けに画像と PDF を結合します。

2か月分を比較して変更を確認する

アラートサービスがない場合、変更の確認はアーカイブのレビュー時に行います。同じページの2か月分を Compare Images ツールで開き、スライダーで2つの画像を切り替えます。ピクセル差分の表示では、変化した領域がハイライトされるため、レビュアーは詳しく確認すべき箇所を特定できます。

少数のページであれば、レビューは1ページあたり約1分で完了します。ただし、これは手動の確認です。価格の変更や削除されたセクションは検出できますが、変更が発生した時点で通知されるアラートの代わりにはなりません。

バッチの実行中はアプリを開いたままにする

ローカルのバッチは、実行の間ずっとアプリが開いている必要があります。計画的な離席の前にバッチを開始し、戻ったら Capture History でセッションを確認してください。一部のURLが完了し、残りが失敗した場合、セッションには Partial と表示されます。バッチを停止した場合は Cancelled と表示されます。どちらの場合も完了したスクリーンショットは残るため、完了した行は書き出せます。

アーカイブにおけるCookieバナー

キャプチャにバナーが写ると、アーカイブが未完成に見えることがあり、アーカイブの目的となる内容を隠すこともあります。Website Capture には4つのバナーモードがあります。Reject banners は可能な場合にバナーを拒否します。Accept minimal は最小限の同意のみを受け入れます。Hide only は回答せずにバナーを非表示にします。Leave unchanged はページに表示されたままのバナーを残します。

アーカイブ全体で1つのモードを選び、比較セット内のすべての画像で同じバナーの状態になるようにしてください。バナーの処理はベストエフォートであるため、独自の同意ダイアログは画像に写ることがあります。バッチの前に1行でプレビューを取得し、全画面サイズで確認してください。

サービスを使わないアラート：確認の例

クライアントから、料金ページが変わったときに通知がほしいという依頼がありました。コンサルタントは月次バッチを実行し、Compare Images ツールで料金ページを前月と比較します。価格表の変更は、ハイライトされたブロックとして表示されます。コンサルタントは2枚の画像と日付をクライアントに送ります。変更1件あたりの作業は約5分です。

この方法は、多数のページには向きません。重要な少数のページに適しており、月次のサイクルはクライアントの必要とする頻度と一致します。毎日監視が必要なページには、モニタリングサービスを使ってください。

2. Visualping

Visualping は、ホスト型のWebサイト変更モニタリングサービスです。スケジュールに従ってページを確認し、各確認結果を前回の結果と比較して、変更を検出するとアラートを送信します。監視対象はページの一部に限定できます。

Stillio との違いは、スクリーンショットのアーカイブを完全に構築することではなく、変更の検出と報告に焦点を置いている点です。価格の追跡、ポリシーページ、求人情報、競合の発表に適しています。

適した用途: すべてのキャプチャを確認しなくても、何かが変わったことを把握したいチーム。

3. ScreenshotOne

ScreenshotOne は スクリーンショットAPI です。開発者は HTTP リクエストでURLとオプションを送信し、画像を受け取ります。スケジュール、保存、命名は、独自のコードや自動化プラットフォームで行います。

Stillio との違いは、完成した製品ではなく、構成要素であることです。すべてのリクエストを制御できる一方で、結果の定期実行と保存は自分で行う必要があります。

適した用途: 自社の製品やパイプラインにスクリーンショットを組み込みたい開発者。自分でブラウザを実行する必要はありません。

4. Urlbox

Urlbox も、HTTP リクエストでWebページを画像に変換するスクリーンショットAPIです。他のAPIと同様に、スケジュール、保存、確認は呼び出し側が担当します。対応する出力形式とレンダリングオプションは、公式ドキュメントに記載されています。

Stillio との違いは、日付でキャプチャを閲覧できる組み込みのアーカイブ画面がないことです。ファイルの保存先は利用者が決めます。

適した用途: 大規模なレンダリングが必要で、保存先とワークフローを自分で選びたいエンジニアリングチーム。

5. changedetection.io

changedetection.io は、Webページの変更を監視し、通知を送信するオープンソースのツールです。Docker などでセルフホストできます。プロジェクトはホスト型版も提供しています。

Stillio との違いは、主な出力が変更の記録と通知であることです。セルフホストではデータを管理下のインフラに残せますが、サービスの運用と更新は自分で行う必要があります。

適した用途: ページの一覧を第三者に送信せずに、定期的なモニタリングを行いたい技術者。

どの Stillio の代替ツールを選ぶか

1. スケジュールに従った日付付きのスクリーンショットアーカイブが必要で、何も保守したくない。 Stillio などのホスト型スケジューラーを使うか、同種のサービスと比較してください。
2. ページが変わったときにアラートが必要。 Visualping、またはセルフホストを希望する場合は changedetection.io。
3. スクリーンショットを製品やパイプラインに組み込む。 ScreenshotOne、Urlbox、または Playwright スクリプト。詳しくは Playwright で Webサイトのスクリーンショットを自動化する方法 を参照してください。
4. 公開ページの一括取得をオンデマンドで行い、ファイルを Mac に保存したい。 Temposhot の Website Capture。

複数のチームでは、2つのツールを組み合わせています。アラート用にモニタリングサービスを使い、アラートの後に続くレビュー用の画像セットをローカルのバッチツールで作成します。

ローカルバッチが適さない場合

ある変更を数分以内に確認しなければならない場合、ローカルバッチは適していません。Temposhot はユーザーが開始したときにのみ実行されるため、午前2時に重要になるアラートにはモニタリングサービスが必要です。また、複数のオフィスで1つのアーカイブを共有するチームにも適していません。キャプチャが1台の Mac に残るためです。

アクセスの方式も確認してください。チームの特定のメンバーだけが保有するログインを必要とするページの場合、Website Capture は共有されないセッションを持つ管理されたブラウザを使います。その場合は、サインイン済みのブラウザウィンドウから Auto Capture でページをキャプチャし、そのページに対するサイトの利用規約に従ってください。

よくある質問

バッチはどのくらいの頻度で実行できますか？

作業に必要な頻度で実行できます。Temposhot には実行スケジュールがなく、各実行は Start Capture を選択したときに開始されます。月次のアーカイブは一般的な周期です。毎週変わるページには毎週の実行が適しており、毎日の実行は、ユーザーが毎日アプリを開始することを前提とするため、モニタリングサービスかスクリプトが必要です。

サイトが自動化されたブラウジングをブロックする場合はどうなりますか？

サイトが自動化されたブラウジングを拒否したり、管理されたブラウザで表示されなかったりすると、行が失敗することがあります。まず行のエラーを確認してください。その行で Block ads または Block trackers をオフにし、後で再試行します。それでもサイトがキャプチャを拒否する場合は、アクセス制御を回避しようとしないでください。通常のブラウザウィンドウで Auto Capture を使ってページを自分でキャプチャし、サイトの利用規約に従ってください。

アーカイブはどのくらいの期間保存すべきですか？

クライアント、契約、社内規程が求める期間保存してください。各月の ZIP と PDF を保存し、後から読む人が必要な月を見つけられるように、ファイル名を一貫させてください。保存期間は年に1回見直し、規程上不要になったファイルは削除してください。

Temposhot でスケジュールに従ってスクリーンショットを取得できますか？

いいえ。実行は Start Capture を選択したときに開始され、アプリが開いている間に実行されます。スケジュールに従った取得が必要な場合は、ホスト型サービス、または launchd や CI で実行するスクリプトを使ってください。

スクリーンショットAPIはキャプチャを保存しますか？

ベンダーによって異なります。画像を直接返すものもあれば、設定したストレージにアップロードできるものもあります。ベンダーのドキュメントとプライバシーポリシーを確認してください。

データを第三者のサーバーに置かない選択肢はどれですか？

Temposhot のようなローカルアプリ、セルフホストの changedetection.io インスタンス、または自前の Playwright や Puppeteer のスクリプトです。

同じページの2つのキャプチャを比較するにはどうすればよいですか？

2枚の画像を Compare Images に読み込みます。ブラウザ上で差分が強調表示されます。

バッチの完了後に使えるツールはありますか？

出力ファイルを対象とするツールを使ってください。Image to PDF は画像を1つの PDF にまとめ、Merge PDF は複数の PDF を結合し、Image Compressor は共有前にファイルサイズを削減します。Screenshot Resolution Checker は画像のピクセルサイズを確認するため、デバイス比較で寸法を揃える必要があるときに役立ちます。

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

Temposhot の Website Capture は、お使いの Mac でURLの一括取得をローカルに実行し、画像、PDF、MP4 として書き出します。詳しくは Webサイトのスクリーンショット自動化 を参照するか、ダウンロードページ からアプリをダウンロードしてください。