【Sentry Snapshots ベータ公開】スナップショットテストでビジュアルリグレッションを検出

Article by: (読了時間:6分)

 
 
要約 — Sentry Snapshots がベータ公開されました。(英語記事公開日2026/6/11)CI でスクリーンショットの差分を検出し、意図しないビジュアルの変更を検知、フロントエンドを持つあらゆるプラットフォームに対応。まずはSnapshots のドキュメントから始めてください。

 

Sentry Snapshotsは、コミットのたびにスクリーンショットを比較し、表示内容に変更があった場合はPRをブロックして、その変更が意図したものかどうかを確認できます。ユーザーが実際に目にし、操作するのはコードではなくアプリケーションです。Snapshotsは、そのユーザー体験を手軽に検証するための仕組みです。

コードの変更はかつてないほど簡単になりましたが、同時に、スピードのために品質を犠牲にする可能性も高くなっています。現代のコードベースには、正しさを担保するためのガードレールが必要です。Snapshots でめざしているのは、コードへのチェック機能と、ワークフローを改善するためのリソースを提供することです。

 

スナップショットテストとは

スナップショットテストの基本的な流れはシンプルです。

  1. コードを変更する
  2. アプリケーションのスクリーンショットを生成する
  3. そのスクリーンショットをベースラインと比較する
  4. 変更箇所を表示する

 

Sentry Snapshots では、スクリーンショットをアップロードすると差分を比較し、差分があれば PR にコメントします。

その後 UI に移動して、具体的にどのような変更があるかを確認できます。

このシンプルなワークフローにより、ビジュアルのカバレッジという新しい軸が加わり、異なるテーマ・言語・ビューポートでアプリケーションが期待通りに表示されているかをテストできます。スナップショットテストは、意図した以上の変更が行われていないかを検証します。

 

Sentry Snapshots とエージェントの連携

従来からビジュアル変更に対するガードレールとして利用されてきたスナップショットテストは、AIエージェントによる開発でも特に有効です。たとえ雑なプロンプトでエージェントが変更を加えたとしても、スナップショットテストを実行し、変更が検出されればPRをブロックできます。

しかし Snapshots はエージェントが「活用する」アーティファクトにもなり得ます。最近、Snapshots 自体のビジュアル変更を行う際に Snapshots を活用した流れをご紹介します。

 

課題

複数のユーザーから「Snapshot Toolbar」に関して似たようなフィードバックが寄せられていました。

  • 最初に表示される赤い「差分マスク」の意味が分からない
  • マスクを非表示にしたいが方法が分からない(実際には可能)
  • 差分ビューを切り替えたいが、操作方法が見つからない

 

要するに、既存機能の見つけにくさが課題でした。

 
コンテキストとしての Snapshots

最初のステップはカバレッジを増やすことでした。テストはある程度用意していましたが、コンポーネントの異なるアクティブ状態のスクリーンショットを追加したかったのです(アクティブなビューによってわずかな差異があります)。

テストを追加するには、当然まず該当のテストファイルを見つける必要があります。

Sentry Snapshots では、すべての画像に context メタデータを追加できます。これは任意の内容を持てる自由なフィールドで、エージェントに情報を提供するために設計されています。Sentry 自身の Snapshots 活用では source_test_file(ファイルへのパス)を渡しています。

スナップショットテストをさらに追加するために必要だったのは、メタデータを LLM にコピー&ペーストして、やりたいことを説明するだけでした。

 

Find this snapshot test and add states for the different diff views
{
“display_name”: “all controls @md”,
“group”: “SnapshotsToolbar/light”,
“image_file_name”: “static/app/views/preprod/snapshots/main/snapshotstoolbar-light-allcontrols-md.png”,
“width”: 1984,
“height”: 90,
“tags”: {
“area”: “snapshots”,
“theme”: “light”,
“viewport”: “md”
},
“context”: {
“test_file_path”: “static/app/views/preprod/snapshots/main/snapshotsToolbar.snapshots.tsx”
}
}

 

スナップショットテストを作成するためのフレームワークが整っていれば、エージェントは追加のテストも容易に作成できます。特に、どこを確認すべきかを具体的に指示した場合はなおさらです。

今回追加した新しいテストがこちらです(分かりやすさのためユニークな UI 部分をハイライト表示しています)。

今回はスナップショットテストに関する作業をしていたため、コピー&ペーストは簡単でしたが、このデータは sentry-mcp や REST API 経由でも取得できるため、他のシナリオでも活用できます。今回はエージェントの誘導に context プロパティをそのまま使いましたが、生成された画像や差分データをエージェントへの参照として渡すこともでき、これもエージェントにとって有用な情報になります。

 

CI からの差分レビュー

発見しやすさを改善するための最初の試みは、アクティブなラベルを表示することでしたが、特にオーバーレイマスクの部分で期待どおりの効果が得られませんでした。

そこで、スナップショットへのリンクを LLM に渡しました。

I want to make the color picker more noticeable, but it’s still too subtle.
Make it have a light border on dark theme and dark border on light theme:
https://sentry.sentry.io/preprod/snapshots/299186/?selectedTypes=changed&selectedSnapshot=static%2Fapp%2Fviews%2Fpreprod%2Fsnapshots%2Fmain%2Fsnapshotstoolbar-dark-allcontrols-sm.png

 

これによりエージェントが sentry-mcp を使ってスナップショットリソースを取得しました。取得した内容は以下のとおりです。

  • ベース画像
  • HEAD 画像
  • 差分マスク
  • メタデータ

 

エージェントは簡単に変更を加えました。現実的には、この程度のシンプルな変更であればリソースなしでもできたかもしれません。しかし、スクリーンショットデータとコンテキストメタデータを組み合わせることで、タスクに特化したコンテキストが得られます。ここには絞り込まれたスクリーンショットデータとローカルの PR 情報が含まれます。「スクリーンショット+やってほしいこと」を LLM に渡すための、再現性のある体系的な方法です。

 

ローカルでの検証としての Snapshots

ループを完結させるには、エージェントがスナップショットを生成して差分を取れる必要があります。スナップショットの生成はリポジトリによって異なりますが、sentry-cli を使ってベースライン画像をダウンロードし、ローカルのスナップショットセットと比較できます。エージェントに差分を取らせて結果を表示させることも(あるいは LLM に判断させて意図的な変更であればそのままコミットさせるという少々危険な方法も)可能です。

ローカルでの流れはおおよそ以下のとおりです。

# 1. download base
sentry-cli snapshots download –app-id {your-id} –branch {main}
# 2. generate snapshots locally
# 3. diff snapshots
sentry-cli snapshots diff ./snapshots-base path-to-local –fail-on-diff –selective

 

これはエージェントとは独立して使っても便利ですが、エージェントのプリコミット処理やプロンプトの一部として組み込むことも可能です。

ローカルの差分は期待どおりの内容でした。新しいコミットをプッシュすると、CI 上の Snapshots も差分を検出。承認してマージした結果がこちらです。

これはシンプルな変更例ですが、これらのワークフローがいかに広がりを持つかは容易に想像できます。Snapshots は高度に関連性のあるコンテキストとして活用でき、エージェントがそれを照会し、変更を加え、ローカルで検証ループを回す、という流れが実現します。

詳細についてはローカルテストのドキュメントをご参照ください。

 

スナップショットテストの限界

スナップショットテストがすべての人・すべてのリポジトリに向いているわけではありません。ここまで読んで「スナップショットテストなんて役に立たない」と憤慨している方もいるかもしれません。質の高いスクリーンショットを生成するコストが見合わないこともあります。過去に「ゴールデンファイル」や git-lfs の管理に苦労した経験をお持ちの方もいるでしょう。

それは私たちも同感です。だからこそ、まず Emerge Tools でモバイルアプリに特化した Snapshots を構築し、面倒な部分を抽象化しました。その製品は OpenAI などの企業に ChatGPT や Codex の開発で活用されています。Sentry Snapshots はそこで有効だったものを踏まえ、あらゆるプラットフォームへと機能を拡張したものです。

コードによっては、スナップショットテストを適用しにくいケースもあります。Sentryでも、Snapshotsの活用方法を現在も改善し続けています。それでも、スナップショットテストのワークフローが非常に効果的であることを実際に確認してきたため、今後も機能の改善を続けていきます。

 

Sentry Snapshots をはじめる

Sentry のモットーは「code breaks, fix it faster.(コードは壊れる、より速く直せ)」です。Snapshots はそもそも壊れないようにするための一歩です。

Snapshots は現在、全ユーザー向けにベータ公開されています。iOS と Android には、Previews からスクリーンショットへ移行するための推奨ワークフローが用意されています(iOS リポジトリは最近、Codex の新しい iOS 機能の一部として紹介されました)。フロントエンドを持つあらゆるプラットフォームで Snapshots を利用できます。

ご質問やフィードバックがあればお待ちしています。

 

Sentry をはじめて使う方はこちら。

 

 

 

Original Page: Catch visual regressions with Snapshots, now in beta

 




IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談は「お問い合わせ」からお気軽にお問い合わせください。

 

シェアする

Recent Posts

;