プロダクトツアーとは？SaaSでの活用・作り方・効果測定

プロダクトツアーとは、WebアプリやSaaSの使い方を、実際の画面の流れに沿ってステップバイステップで案内していくガイド体験のことです。代表的なアプローチとしては、初回ログイン時に操作対象となるボタンや入力をハイライト表示し、吹き出しで「次に行うべき操作」を誘導するアプリ内ツアーが挙げられます。また、オンボーディング用のチェックリストと組み合わせることで、初期設定の進捗状況を視覚的に提示するケースも多く見られます。

「チュートリアル」「ウォークスルー」「インアプリガイド」といった用語と類似した意味合いで活用されますが、これらには業界で統一された厳密な定義の違いがあるわけではありません。なお、ユーザー登録前にWebサイト上で体験してもらったり、メールで送付したりする独立型のクリック式コンテンツをプロダクトツアーと呼ぶ場合もあります。

両者を区別する大きなポイントは、「実際のシステムに操作結果や設定データが残るかどうか」という点です。アプリ内ツアーでは、本番の利用画面上で実際に値の入力や保存処理を行うよう設計されるのが一般的です。一方で、キャプチャや擬似画面で進める共有型のガイドツアーは、用意されたシナリオを体験する形式であるため、どれだけツアーを進めても実際のシステムアカウントの初期設定が完了したことにはならない点に留意して使い分けることが大切です。

👉 関連記事：インタラクティブデモとは？仕組み・メリット・活用方法を解説

ユーザーがシステムを開いた目的によって、必要とされる案内の性質や深さは変化します。初期設定を進めたいユーザー、リリースされた新機能を試したいユーザー、特定の操作で迷っているユーザーに対して、一律で長尺のツアーを表示する必要はありません。ユーザーの文脈に合わせた使い分けが推奨されます。

1. 初回ログインや無料トライアルで最初の成功体験へ案内する

新規登録直後のユーザーに対しては、システムに存在するすべてのメニューを一度に説明するのではなく、製品が持つ本質的な価値を真っ先に実感できる「一つのアクション」へ絞って案内することが効果的です。

例えば、タスク管理SaaSであれば「最初のプロジェクトを1件作成・保存する」、データ分析ツールであれば「最初のレポートを出力してみる」といったように、明確に完了を判定できる行動をゴールに設定します。

なお、同じ初回ログインであっても、管理者アカウントにはメンバー招待やアクセス権限の設定が求められ、一般メンバーには自身のタスク登録が求められるといった違いが生じます。ユーザーの役割や付与されている権限に配慮した設計を行わないと、画面上に存在しないボタンのクリックを促してしまう原因になります。

2. 既存ユーザーに対して新機能や未利用機能の活用を促す

新機能のリリース案内をポップアップやメールで通知するだけでは、ユーザーが実際の画面上でどこから操作を始めればよいか迷ってしまうことがあります。該当する新機能の画面を初めて開いたタイミングで短いガイドを表示し、最初の設定変更やデータ保存まで誘導する設計が有効です。

すでに設定を完了しているユーザーや、その機能を使用する権限のないユーザーへ何度も繰り返し表示させない配慮も欠かせません。「機能のリリースを広く認知してもらうための通知」と、「実際に画面上で設定を完了させるためのプロダクトツアー」の役割の違いを正しく整理して活用しましょう。

3. 操作につまずきやすい画面で直感的な自己解決を支援する

データが存在しない初期画面（空の状態）で何から着手すべきか分からない場合や、入力項目が多岐にわたる複雑な設定画面においては、必要なポイントのみに絞ったコンパクトなガイドが大きな助けとなります。ユーザーが自分のタイミングで「ガイドを表示する」というボタンを押して起動できるオンデマンド形式にしておけば、日常業務の手を止めることなくスムーズな解決を支援できます。

ただし、権限不足によるエラーや外部システムとの連携不具合などは、単なる画面上の操作説明だけで解決できる問題ではありません。画面ガイドとあわせて、必要な権限の確認手順やサポート窓口への問合せ導線もあらかじめ提示しておくのが安心です。

プロダクトツアー最大の強みは、ユーザーが今まさに操作している画面上で、迷いや疑問を即座に解消できる点にあります。初期設定における離脱を防ぎ、カスタマーサクセスやサポート担当者が日々繰り返している基本的な操作説明の工数を大幅に削減できる可能性を秘めています。

一方で、高度なデータ移行作業や、個社ごとの個別要件が絡む複雑な初期設定までを、すべて数ステップのツアーだけで完結させようとするアプローチは適切ではありません。

プロダクトツアーを単に画面上に設置・導入しただけで、自動的にシステムの利用率や継続率が向上するわけではありません。「誰を対象とし」「どのタイミングで表示させ」「実際のシステム上にどのような操作結果が残ったか」という定量的データをしっかりと測定し、真にユーザーの役に立っているかを定期的に検証・改善していく姿勢が大切です。

ここでは、架空のBtoBタスク管理SaaSにおいて「最初のプロジェクトを作成する」という目標を設定したプロダクトツアーの設計プロセスを例に解説していきます。掲載している画面名や案内文は説明用のサンプルであり、実際のツールの画面表示とは異なります。

1. 案内したいターゲット層と完了してほしいゴール行動を定義する

まず、ツアーの対象者を「初回ログインを行った一般メンバー」に絞り込み、達成すべき目標を「自身で作成したプロジェクトがシステム上に正常に保存・表示されること」と明確に定義します。

単に「プロジェクト管理機能の概要を把握してもらう」といった曖昧な設定では、ツアーが成功したかどうかをデータで客観的に判定することができません。

あわせて、ツアーを開始する画面、必要な作成権限の有無、入力前に揃えておくべき情報についてもあらかじめ確認しておきます。仮に一般メンバーには作成権限が付与されていないシステム仕様である場合は、同じツアーを強制的に進めさせるのではなく、管理者へ権限付与を申請する手順を案内する別の導線を用意するのがスマートです。

2. 表示する画面位置・タイミング・終了条件を設定する

例えば「まだプロジェクトを作成した実績がないユーザーが、データのない空の管理画面を開いた瞬間」にツアーを表示するトリガーを設定しておけば、ユーザーが置かれている状況と案内のタイミングが見事に合致しやすくなります。すでに作成を完了しているユーザーに対して、ログインのたびに何度も繰り返し表示させない配慮も考慮しておきましょう。

また、途中でスキップして閉じる、後からヘルプメニュー等で再呼び出しする、最後のステップまで完了したと判定する、といった各種イベント挙動も設計段階で決めておきます。なお、自動表示の制御、ツアーの再開処理、ユーザー属性（セグメント）ごとの出し分け機能の可否は、採用するプロダクトツアーツールや自社アプリ側の実装仕様によって異なる点に留意が必要です。

3. 1つの操作ステップごとに簡潔な案内を作成する

1つの画面上に長文の説明テキストを詰め込むのではなく、ユーザーが「今まさに操作すべき1つの要素」へ視線を集中させる構成にします。以下の例では、4つのステップを通じて「入力・保存を行い、実際の画面上で作成結果を確認する」までを一連の流れとして整理しています。

表｜架空のタスク管理SaaSにおけるプロダクトツアー設計記入例

各ステップを単なる「次へ」ボタンのクリックで進める仕様にするのか、あるいは実際の画面上でのクリックやテキスト入力を検知して自動で次へ進める仕様にするのかも重要な設計ポイントです。

「次へ」ボタンで進む形式の場合、ユーザーが説明テキストを読んだだけで実際の操作を行わずにツアーを終えてしまう可能性があります。

実データの保存処理を真のゴールとする場合は、見た目上のガイド進行とバックエンドでの保存イベントを区別してトラッキングできる設計が推奨されます。

4. 初めて操作する第三者でテストを行い公開後も改善する

作成した担当者自身がプレビュー画面でスムーズに最後まで進められたとしても、実際の初見ユーザーの画面では吹き出しが他の要素と重なって表示されてしまうケースがあります。データが存在しない初期状態、すでにデータが蓄積されている状態、権限が異なるアカウント、画面幅が狭いモバイル環境など、多様な検証環境を用意して想定通りの操作感で進められるかをテストします。

読みづらい文章や直感的でない表現は分かりやすい言葉へ修正し、意図しない画面でツアーが起動してしまう場合は発火条件を細かく調整します。

また、将来的に自社アプリのUIデザインが変更された際に、誰がプロダクトツアーの再テストと表示位置の修正を行うかという運用ルールもあらかじめ定めておきましょう。プレビューモードで最後まで進めたことと、本番環境でユーザーの保存イベントや分析ログが正しく記録されたこととは別であるため、本番公開後のログ確認まで徹底することが大切です。

プロダクトツアーを公開した後に発生する「使われない」「すぐに閉じられてしまう」といった課題の原因は、案内文の表現そのものよりも、「表示されるタイミング」「画面や権限の差異」「ツアー終了後の導線」に潜んでいることが少なくありません。

ここでは、陥りがちな典型的な3つの問題点と、その具体的な対処アプローチを整理して解説します。

1. 意図していないタイミングで一律表示しない

既存ユーザーが日常業務を急いで進めたい場面で、ログインのたびに初回向けの大きなモーダルウィンドウが開いてしまえば、いくら丁寧な案内であっても利便性を損なう要因になってしまいます。

「まだ対象の初期操作を行っていない未着手ユーザーのみに絞って表示する」「ユーザーが該当機能の画面を開いた瞬間に起動させる」「一度閉じたユーザーには再表示させない」といった表示トリガーの設定を慎重に検討しましょう。

制御できる表示条件の柔軟性は利用するツアーツールやシステム仕様によって異なるため、あらかじめ管理画面や仕様を確認しておきましょう。

2. アカウントの権限や画面状態による誤案内を防ぐ

管理者のみに付与されている操作ボタンを一般ユーザーの画面上でハイライトしたり、データが1件もない空の画面を前提とした案内をすでにデータが蓄積されている画面上で表示したりすると、ユーザーは指示通りの操作ができずガイドの途中で離脱してしまいます。

ユーザーのロールや権限ごとにツアーのシナリオ自体を分けて作成するか、あるいは対象外のユーザーに対しては案内を表示させず別のヘルプページへ誘導するといった分岐設計が有効です。

なお、本番の操作画面に直接要素を重ねるアプリ内ツアーは自社UIのデザイン変更の影響を受けやすく、一方で画面をキャプチャして再現する独立したクリック型デモは本番UIの進化に伴って画面上のズレが生じやすい傾向があります。どちらの形式を採用する場合であっても、UI変更時の定期的なメンテナンス体制を整えておくことが大切です。

3. ツアー完了後の「次にとるべきアクション」を明確に示す

ツアーの最終ステップで単に「ツアーが完了しました」とだけ表示されても、ユーザー側は「結局、自分の手で何が達成できたのか」を実感しづらいことがあります。

今回のタスク管理SaaSの例であれば、作成したプロジェクト名が一覧上に正常に反映された状態を画面上でしっかり確認させた上で、続けて「次に最初のタスクを1件追加してみましょう」といったように、実務の成果に直結する具体的な次のステップをひとつ案内する構成が効果的です。

ただし、擬似的に再現されたデモ画面上でツアーを完了したからといって、本番のシステム環境上で実際のデータ保存処理が完了したことを意味するわけではありません。採用しているガイドの形式に応じて、「何が完了し、何が確認できたのか」をユーザーへ正しく認識してもらえるよう親切な案内を心がけましょう。

プロダクトツアーの完了率が高かったとしても、ユーザーが実際のアプリ内で目的の初期操作や設定を完遂したとは限りません。プロダクトツアーの効果を客観的に検証する際は、「狙った対象者に正しく表示されたか」「どのステップで離脱やスキップが発生したか」「最終的に本番環境で目標とする行動が起こったか」という3つの段階に分けてログやデータを分析していくことが大切です。

例えば「初回プロジェクトの保存完了率」を導入前後で比較する場合は、評価対象となるユーザーの定義、保存完了と判定するイベント基準、集計対象とする観察期間をしっかりと揃えておく必要があります。

また、ツアーの導入と同時にアプリ自体のUI変更や新規ユーザーの属性変化があった場合は、それらの外部要因による影響も考慮しながら成果を分析するのがスマートです。ツアーツール上の閲覧ログと製品アプリ内のデータ保存イベントは異なるシステムで管理されるケースが多いため、双方のデータ連携やイベントトラッキングの可否をあらかじめ確認しておきましょう。

一例として、カスタマーエンゲージメントプラットフォームであるIntercomが提供するプロダクトツアー機能などでは、ユーザーの属性情報やアプリ内のイベントログをもとに目標（ゴール）を設定し、指定期間内における実際の達成状況をダッシュボード上でトラッキングできます。

ただし、こうした分析を行うためにはツール側に必要なイベントがあらかじめ連携・計測されていることが前提となり、導入するすべてのプロダクトツアーツールで同様の機能が標準実装されているわけではない点に配慮しておきましょう。

プロダクトツアーを活用したオンボーディングの改善事例をご紹介します。

「製品アプリ内で実際の操作を案内する方式」と「事前に用意された共有型デモで使い方を学んでもらう方式」とでは、得られる成果やデータが持つ性質が異なります。それぞれの特徴を理解するための参考にしてみてください。

FullstarのLESSAR事例｜初期設定をアプリ内で直接案内

カスタマーサクセスプラットフォーム「Fullstar」が紹介するAR作成サービス「LESSAR」の事例では、カスタマーサクセスによる人的支援を直接行わないフリープランにおいて、初期設定完了率が約60％にとどまっていた点が課題として挙げられていました。そこでシステム内に6つのチュートリアルツアーを設置したところ、導入後に初期設定完了率が14％向上したと報告されています。

なお、公開情報においては「14％向上」という数値がパーセントポイントの増加を意味するのか、あるいは比較前の数値に対する相対的な増加率であるかまでは特定できないため、元の発表データのまま記載しています。また、この成果はLESSAR様のユーザー属性や運用条件のもとで得られた実績であり、あらゆるSaaSプロダクトで同様の改善幅が担保されるわけではない点に配慮しておきましょう。

👉出典： Fullstar｜プロダクトツアーの活用事例

ReelDx様の導入事例｜共有可能なインタラクティブデモでオンボーディングを効率化

当社の「Supademo」をご活用いただいているReelDx様は、医療教育向けの動画および症例ケース共有プラットフォームを提供されています。従来はマニュアル動画の作成・更新作業や、ユーザーとの1対1による画面共有レクチャーに多くの時間を費やしていました。そこでSupademoによるインタラクティブデモを導入し、ユーザーが必要なタイミングでいつでも自律的に操作方法を確認できるオンボーディング環境を整えられました。

この取り組みにより、100名以上のユーザーに対するオンボーディング支援を実現し、月間12時間以上のサポート工数削減を達成されたと報告されています。この実績は、共有型デモコンテンツの活用によって実現したReelDx様固有の成果であり、本番画面上で実際のシステム設定を直接完遂させるアプリ内ツアーの成果とは性質が異なる点を確認しておくと安心です。

👉Supademo：ReelDxのオンボーディング事例ReelDxの顧客事例を見る (英語)

プロダクトツアーの提供方式を選ぶ基準は、「ユーザーがどの場所で、どのような操作を完了させる必要があるか」にあります。

ユーザーがログインした後の本番画面上で実際のデータ入力や初期設定までを完遂してほしい場合は、アプリ内ツアーが第一候補となります。一方で、会員登録前の製品案内として見せたい場合や、サポートページ・案内メール内で操作手順を分かりやすく提示したい場合は、画面URLで柔軟に共有できる独立型のクリック型ツアーが向いています。

当社の「Supademo（スパデモ）」では、製品の実際の操作画面をもとに直感的なクリック型のインタラクティブデモを作成し、共有リンクの送付やWebサイト・社内ドキュメントへの埋め込みによってユーザーへ届けることができます。新規ユーザーの導入支援や既存ユーザー向けのヘルプコンテンツとしても幅広くご活用いただけます。ただし、クリック型デモ内での擬似操作は、本番アカウント上でのデータ保存や設定処理を直接実行するものではない点に配慮しておきましょう。

本番システムのUI上でガイドを自動表示させたい場合や、ユーザーの権限・行動履歴に応じた細かい出し分け、実際のシステム操作を条件としたステップ進行を行いたい場合は、アプリ内ツアーに対応したツールの機能仕様と、自社アプリ側への組み込み要件をあらかじめ確認しておくと安心です。

プロダクトツアーに組み込む内容は、最初からシステムのすべての機能を網羅する必要はありません。まずは「誰に届けたいのか」というターゲット層を明確にし、そのユーザーがアプリ内で最初に完遂したい「ひとつの重要な操作」を絞り込むことからスタートしましょう。

案内を表示させる画面、タイミング、ユーザー権限を丁寧に整理した上で、最終的に本番環境で目標とするアクションが起こったかまでをトラッキングしていくことが推奨されます。

また、ツアーは一度制作して公開したら終わりではなく、ユーザーが途中で離脱してしまうステップや、UI変更に伴うガイドのズレを定期的に見つけて改善していく姿勢が長続きする案内に繋がります。なお、データ移行やイレギュラーなトラブル対応が必要となる高度な場面においては、無理に自動化せずカスタマーサクセスによる人的なサポートもあわせて残しておくことが大切です。