探索的テストとは？チャーター設計・セッション記録と自動テスト化を実装者向けに解説

探索的テストは、テストの設計と実行を分けずに、対象を触りながら次に試すことをその場で決めていく進め方です。実装者が最初につまずくのは手法の理解ではなく、行き当たりばったりとの違いと、何を成果物として残すのかという運用の設計にあります。この記事では、ISTQB用語集の定義とアドホックテスト・モンキーテストとの線引き、セッションベースドテスト（SBTM）のチャーター記述形式とタイムボックス、記録をリポジトリで版管理する構成、見つけた欠陥をPlaywrightの自動テストへ資産化する実装までを整理します。

まとめ：探索的テストは記録の形式で成否が決まり、発見はスクリプトへ資産化する

探索的テストの弱点は再現性と進捗の見えなさに集約されます。裏を返せば、この2つを埋める仕組みを先に作れば残りは回る。埋める道具がチャーターとセッションシートで、ここを口頭運用にした現場から順に形骸化していきます。

セッションは90分を基準に区切り、1件のチャーターに1枚のシートを対応させる。シートはWikiや表計算ではなくリポジトリへ置き、テストコードと同じレビュー経路に乗せます。所要時間の内訳をテスト・バグ調査・準備の3区分で記録すれば、準備に半分以上を食われている構成上の問題も数字で見えます。

探索で見つけた欠陥は、その場で自動テストに変換して次回以降は機械に任せる。同じ経路を人が毎回歩き直す運用では、探索の価値である「まだ誰も見ていない領域」に時間が回りません。導入を見送るべき条件も後半で示します。

探索的テストの定義とISTQB用語集が示す設計と実行の同時進行という条件

まず用語の輪郭を固めます。探索的テストはテスト工程の名前ではなく、テストの設計と実行をどう配置するかというアプローチの呼び名です。

ISTQB用語集の定義に含まれる動的な設計と過去の結果という3条件

ISTQB用語集は探索的テストを「テスターが自身の知識、テスト対象の探索、過去のテスト結果に基づいて、動的にテストを設計し実行するテストアプローチ」と定義しています。条件は3つ。テスターの知識に依ること、対象を触って得た情報を使うこと、直前の結果を次の一手に反映することです。

実装上で効いてくるのは3つ目です。1件の不具合を見つけたら、同じ設計ミスが波及していそうな箇所へ即座に舵を切る。この分岐が事前設計のテストケースでは書けない部分で、探索的テストの取り分もそこにしかありません。直前の結果を無視して手順書どおりに触っているなら、形式が自由でも探索にはなっていません。

Cem Kanerが1984年に造語した経緯とスクリプトテストとの対比

用語自体は古く、Cem Kanerが1984年に名付けたものです。定義の核は「学習・テスト設計・テスト実行の同時進行」にあります。

対比の相手はスクリプトテストです。スクリプトテストでは個々の手順と期待結果が事前に確定しており、実行者は判断を求められません。探索的テストでは期待結果が開いた状態で、テスターが操作し、観察し、その場で評価します。優劣ではなく、期待結果を先に固定できるかどうかで使い分ける関係です。仕様が確定して回帰の網を張りたい領域はスクリプト側、仕様が曖昧なまま実装が先行した領域は探索側。テスト駆動開発（TDD）の基本サイクルのように期待結果から実装を導く進め方は、スクリプト側の極致に位置します。

アドホックテスト・モンキーテストと分ける基準はチャーターの有無

「事前にテストケースを書かない」という一点だけを見ると、アドホックテストやモンキーテストと区別がつきません。線引きは成果物と目的の側です。

モンキーテストはランダム入力を機械的に流す手法で、人の判断を前提としません。アドホックテストは目的の宣言と記録が無い点が決定的な差で、同じ人が同じ品質で2回できる保証もない。チャーターを1枚書けば探索的テストになる、と言い換えても実務上は正しい理解です。

スクリプトテストとの併用配分とテストピラミッド上での置き場所

探索的テストを単独で成立させようとすると破綻します。自動化された回帰の網が先にあって、その隙間を人が探索するという順序が前提です。

スクリプト側とセッション側の工数配分を決める2つの判断材料と目安

配分は仕様の確定度と変更頻度の2軸で決めます。半年以上変わらない機能はスクリプト側へ寄せ、リリースのたびに要件が動く機能は探索側の比率を上げる。目安は、テスト実行工数のうち探索セッションに割く比率を2割から3割に置く線です。

1割を切ると、探索は「余った時間にやること」に格下げされて実施されなくなります。逆に5割を超える構成は、自動回帰の不足を人力で埋めている状態。増やすべきはセッション数ではなく自動テストの本数で、判断材料にはテストカバレッジのC0/C1/C2と計測ツールで扱う網羅率の実測値を先に見てください。

単体・結合・E2Eの各層に対して探索セッションを置く位置の決め方

探索的テストはピラミッドの層ではなく、層の外側から統合済みの動くシステムに当てる行為です。単体テストの粒度で探索しても、入力と出力の組み合わせを人が手で試すだけになり、割に合いません。

当てる先はE2E層と同じ「結合済みの実環境」です。ただしE2Eの自動テストが検証するのは事前に決めた1本の経路のみで、その脇道は誰も見ていない。探索セッションはこの脇道を担当します。各層の本数配分はテストピラミッドにおける単体・結合・E2Eの配分を前提にしたうえで、自動ケース1本につき脇道が何本あるかを数えると対象の広さが見積もれます。

スモークテストやリグレッションとの実行順序と重複を避ける線引き

実行順序は固定です。デプロイ直後にスモークが通り、次にリグレッションが走り、その後に探索セッションを置く。壊れたビルドを人が探索しても、既知の障害を再発見するだけで時間が溶けます。門の判定設計はスモークテストのCI/CDへの組み込みと対象選定にまとめました。

重複を避ける線引きも単純です。自動テストが1本でも通っている経路は、探索セッションのチャーターに書かない。リグレッションテストの目的と範囲選定で選んだ範囲を除外リストとしてチャーターに添え、探索側は範囲外だけを歩く構成にしてください。

チャーターの記述形式とセッションを90分前後に区切る運用設計

ここからが運用の実装です。セッションベースドテスト（SBTM）はJonathan BachとJames Marcus Bachが2000年にHewlett-Packardで開発した管理手法で、探索的テストに進捗と証跡を与えます。

探索対象・使う道具・得たい情報の3要素で書くチャーターの記述型

チャーターはセッションの目的を1〜3文で書いたものです。Elisabeth Hendricksonが『Explore It!』（2013年）で示した「Explore（探索する対象）With（使う道具・条件）To discover（知りたい情報）」の3要素型が扱いやすい形です。

具体例を挙げます。「注文キャンセル機能を、在庫連携APIを遅延させた状態で探索し、在庫数の不整合が起きる条件を見つける」。対象・条件・知りたい情報が入り、90分で終わる粒度です。悪い例は「注文機能全体をテストする」で、範囲が広すぎて漂流します。粒度の判定基準は、終了時に見つかった・見つからなかったのどちらかで答えられるかの1点です。

セッション時間を90分前後に置く根拠とデブリーフィングの進め方

SBTMが示すタイムボックスは、中断されない1時間から2時間です。中央の90分を基準に置くと運用が安定します。60分を切ると準備と後片付けの比率が上がり、120分を超えると集中が落ちて記録の粒度が荒くなるためです。

セッション後には短いデブリーフィングを挟みます。Jonathan Bachが示したPROOFという枠組みが使いやすく、Past（何をしたか）、Results（何が分かったか）、Obstacles（何に阻まれたか）、Outlook（次に何を見るべきか）、Feelings（対象への感触）の5点を口頭で確認する形。所要は5分から10分です。ここで出たOutlookが次回のチャーター候補になり、供給が枯れません。Feelingsを残すのは、テスターの違和感が後から重大な障害として顕在化する例が多いためです。

TBSメトリクスでテスト・バグ調査・準備の時間比率を集計する運用

SBTMではセッション内の時間をTBSの3区分で記録します。T（Test）は探索そのもの、B（Bug）は不具合の切り分けと起票、S（Setup）はデータ準備や環境構築。終了時に合計100%となる比率を申告します。

この数字は個人評価には使いません。見るのは構成の異常です。Sが40%を超え続けるなら、テストデータの生成が手作業のままという構造的な問題があり、手当てはデータ投入スクリプトの整備になります。Bが50%を超えるセッションが続く場合は修正の順番待ちが溜まっており、セッション数を増やしても検出は伸びません。Tが常に80%を超えているならバグが出ていないので、チャーターの対象を未探索領域へ動かします。

セッション記録をリポジトリで管理する構成と集計スクリプトの実装

記録の置き場所を間違えると、SBTMは表計算の更新作業に堕ちます。成果物はコードと同じ場所へ置き、同じ経路でレビューする構成にします。

チャーターとセッションシートをYAMLで版管理する構成の作り方

推奨はリポジトリ直下にtesting/charters/とtesting/sessions/を切り、1セッション1ファイルのYAMLで残す構成です。ファイル名は2026-08-07-order-cancel-01.yamlのように日付と識別子で決め打ちにします。

1ファイルに持たせる項目はSBTMのセッションレポートに対応させます。charter（目的文）、areas（触った機能・画面の識別子）、tester、started_at、duration_min、tbs（testとbugとsetupの3値）、notes（時系列の観察メモ）、bugs（起票した課題キーの配列）、issues（不具合ではないが引っかかった点）、files（作成したデータや録画のパス）の10項目。プルリクエストに載せれば、誰が何をどこまで見たかがコミット履歴に残ります。Wikiの記録は差分が追えず、半年後の出発点になりません。

ブラウザ拡張で画面録画と課題の起票をつなぐ証跡収集の実装手順

手で記録を取ると探索の集中が切れます。証跡収集はブラウザ拡張に任せる構成が現実的です。Azure DevOpsを使っている現場なら、Test & Feedback拡張がそのまま使えます。ChromeとMicrosoft Edge（Chromium版）に対応し、テスト対象の画面を離れずにスクリーンショット、画面録画、作業ノートの取得と課題の起票までを完結できる作り。Firefox版は提供終了が案内されているため、新規配布はChromiumベースのブラウザへ揃えてください。

接続モードでAzure DevOpsに紐づけると、起票した不具合に操作の再現手順と録画が自動で添付されます。この添付の有無で開発者側の再現時間が変わる。JiraやRedmineの場合は、録画をファイルとして保存しYAMLのfilesにパスを書く運用でも成立します。証跡の目的は後から他人が同じ経路を辿れることであり、道具の名前ではありません。

集計スクリプトでセッション数とバグ検出率を週次で可視化する手順

YAMLで統一しておけば、集計は数十行のスクリプトで済みます。週次の指標は4つに絞る。消化セッション数、TBSの平均比率、1セッションあたりの起票件数、未探索のareas一覧です。

4つ目が実務では効きます。areasを機能一覧のマスタと突き合わせ、直近90日でどのセッションからも触られていない機能を抽出する。網羅率では見えない「誰も見ていない領域」がここに出ます。CIに載せるなら週次のスケジュール実行でMarkdownを生成し、チャットへ投げる形で足りる。人手の月次報告にすると更新が止まるため、生成は必ず自動で回してください。

探索で見つけた欠陥を自動リグレッションへ資産化する実装の手順

探索的テストの投資対効果は、発見をその場で自動テストへ変換できるかで決まります。人が同じ経路を毎月歩き直す運用では、探索できる面積が増えません。

playwright codegenで操作を記録しアサーションを付ける手順

Playwrightを使っている構成なら、再現手順の記録から自動テスト化までを1コマンドで始められます。npx playwright codegenに対象URLを続けて実行すると、ブラウザ操作がそのままテストコードとして生成されます。

探索の再現に効くオプションが3つあります。--deviceでモバイル端末をエミュレートし、--viewport-sizeで画面幅を指定し、--color-schemeで配色モードを切り替える。表示崩れを見つけた条件をそのまま再現できます。ログインが要る画面では--save-storageでクッキーとlocalStorage、IndexedDBを保存し、次回は--load-storageで読み込めば認証操作を省ける。記録中はツールバーからアサーションも差し込めます。要素の表示を見るassert visibility、テキストを見るassert text、入力値を見るassert valueの3種類。探索中に気づいた期待結果をその場で固定できます。

DevTools Recorderで記録したフローをJSONで残す使い分け

Playwrightを導入していない現場では、Chrome DevToolsのRecorderパネルが代替になります。ユーザーフローを記録して再生ボタンで再実行でき、パフォーマンス計測とも連携できます。

エクスポート形式はJSON、@puppeteer/replay用スクリプト、Puppeteerのコード、Firefoxでも動くPuppeteer（WebDriver BiDi対応）、Lighthouse解析を含むPuppeteerの5系統。拡張機能で出力先も増やせます。使い分けの基準は明快で、自動テストへ育てるならコードとして出し、証跡として残すだけならJSONで十分。JSONはセッションシートのfilesに置いて課題票から参照させます。要素の状態を確かめたい場合は、設定可能なwaitForElementステップとして属性やJavaScriptプロパティの検証を差し込めます。

自動化するケースと手動のまま残すケースを分ける2つの選別基準

探索で見つけたもの全てを自動テストにする必要はありません。判断は2つの基準で行います。第1に、その欠陥が同じ経路で再発しうるか。設定ミスや一度きりのデータ不整合が原因なら、テストではなく監視や制約で防ぐほうが安上がりです。第2に、判定が二値に落ちるか。表示の違和感やレイアウトの微妙な崩れは、自動化すると誤検知の温床になります。

この2つを満たすものだけをリグレッション側へ移し、残りはYAMLのissuesに書いて次回の同領域セッションで参照させます。自動化率を目標値にする運用は採りません。通るだけの脆いテストが増え、失敗が無視されるようになります。

探索的テストを導入しても効果が出ない現場の条件と見送りの判断

すべての現場に向く手法ではありません。ここは条件を付けて言い切ります。

テスターのドメイン知識が浅い段階で導入すると失敗する構造的な理由

探索的テストの検出力は、実施者が「何が正しい振る舞いか」を判断できるかに全面的に依存します。業務知識のない外部要員だけで探索セッションを組む構成は、投じた工数に対して検出がほぼゼロで終わる。手順書があれば誰でも実行できるスクリプトテストとは前提が逆です。

参画から3か月未満のメンバーだけでセッションを組むなら、先にスクリプトテストの実行を担当させてください。手順書を1周すると業務の全体像が入り、そこで初めて「この画面の遷移だけ他と違う」という違和感が持てます。ペアで組むなら、業務を知る側が観察と判断、不慣れな側が操作という分担にすると知識の移転も同時に進みます。

工数見積りと進捗報告が求められる受託開発での折り合いの付け方

受託開発では「何件のテストケースを消化したか」で進捗を報告する契約が残っています。ケース数を持たない探索的テストは、この報告形式と噛み合いません。個々の操作を事後にテストケースとして書き起こす運用は、記録工数が探索工数を上回るため採らないでください。

折り合いの付け方は、報告の単位をケースからセッションに変えることです。消化セッション数・対象領域のカバー状況・起票件数の3点なら進捗として説明できます。契約前に合意できない場合は、探索的テストを工数見積りの外に置き、リグレッションのケース消化を正式な進捗として扱う二重構成にする。発注側との合意形成はシステム開発のテスト工程と発注者が見る判断軸を参照してください。

探索的テストの内製化を進める順序と外部支援を使う判断の分岐点

導入の順序は、チャーター1枚とセッション1件から始めるのが確実です。ツール選定から入る立ち上げはほぼ失敗します。最初の3か月は、既存メンバーが週1回90分のセッションを回し、記録を溜めることだけを目標にする。起票がゼロなら対象領域の選び方が間違っているので、直近のリリースで障害が出た機能へチャーターを寄せます。

外部支援を検討する分岐は2つです。自動回帰の網がまだ無く探索の前提が整っていない場合と、記録の仕組みを作れる人手が社内に無い場合。パイプラインへの組み込みからセッション記録の運用設計、その後の引き取りまでは保守運用・内製化支援で対応しています。技法の整理から入るならブラックボックステストとホワイトボックステストの違いを先に共有すると、チャーターの観点を組み立てやすくなります。

よくある質問

探索的テストの導入と運用で問い合わせの多い論点をまとめます。

探索的テストとアドホックテストの違いは何ですか？

チャーターと記録の有無で分かれます。アドホックテストは目的を宣言せず、思いついた操作をその場で試すだけで、終了後に何をどこまで見たかを説明できません。探索的テストは開始前にチャーターで対象と知りたい情報を宣言し、シートに触った領域・所要時間の内訳・起票内容を残します。同じ「事前にテストケースを書かない」進め方でも、後から検証と再開ができるかが決定的な差。判定はチャーターが1枚あるかどうかで足ります。

探索的テストのやり方は何から始めればよいですか？

チャーターを1枚書き、90分のセッションを1回回すところから始めてください。対象を直近のリリースで障害が出た機能に絞ると、初回から起票が出て継続しやすくなります。記録はYAMLでもMarkdownでもよく、charter・areas・所要時間・TBS比率・観察メモ・起票キーの6項目で回ります。終了後に5分のデブリーフィングを挟み、そこで出た次に見るべき箇所を次回のチャーターにする。循環ができれば道具の整備は後で間に合います。

探索的テストは自動化できますか？

探索の判断そのものは自動化できません。自動化できるのは、見つけた欠陥の再現手順と、それを回帰として繰り返す部分です。npx playwright codegenで操作を記録してアサーションを差し込めば、発見からテストコード化までを数分で終えられます。判定が二値に落ちて再発しうる欠陥だけを自動テストへ移し、レイアウトの違和感のように誤検知を招くものは観点として残す。全件を自動化すると脆いテストが増え、失敗が無視されます。

1回のセッションは何分に設定するのが適切ですか？

中断されない90分前後が基準です。SBTMが示す範囲は1時間から2時間で、60分未満だと準備と後片付けの比率が上がり、120分を超えると集中が落ちて記録の粒度が荒くなります。1日3セッションまでに抑えてください。会議や問い合わせで中断が入ったセッションは無効として記録し、時間の埋め合わせをしない運用にします。中断込みで時間だけ満たすとTBS比率が歪みます。

探索的テストの成果はどう報告すればよいですか？

消化セッション数、対象領域のカバー状況、1セッションあたりの起票件数の3点で報告します。テストケースの消化率に換算すると、事後の書き起こし工数が探索工数を上回るため成立しません。カバー状況は、areasを機能一覧と突き合わせ、直近90日で一度も触られていない機能を残数として示すと説明しやすくなります。TBS比率も添えると、準備工数が過大な構成上の問題を共有できます。

関連記事

• テストピラミッドとは？単体・結合・E2Eの配分と戦略設計：探索を当てる母体の層配分です。
• リグレッションテスト（回帰テスト）とは？目的・範囲選定・自動化：発見の移し先となる範囲選定です。
• スモークテストとは？CI/CDへの組み込みと対象選定：探索の前に置く門の判定設計です。
• テスト駆動開発（TDD）の基礎と基本サイクル：期待結果を先に固定する側の進め方です。
• テストカバレッジとは？C0/C1/C2の網羅率と目標設定：探索比率を決めるときの実測値です。