SaaSのサインアップフォームは火曜日に500人の新規ユーザーをキャプチャします。オンボーディングシーケンスは水曜日の朝に開始されます。木曜日までに、7件のメールがハードバウンスしました。偽のアドレスや使い捨てアドレスからではなく、「gmial.com」「yaho.com」「hotmial.com」からです。その7人のユーザーはモバイルで素早く入力し、送信してから移動しました。彼らはアクティベーションメールを見ることはありません。何人かは戻ってきて製品を非難し、チャーンします。残りは消え去ります。
キャプチャファネルのメール入力ミスはすべて、参加したいと考えていた実在の人物に属しています。これは詐欺ではありません。これはボットトラフィックではありません。これはZeroBounceが40億件以上のアドレスの分析によると、すべてのリストの1～3%に現れる静かな問題です。入力ミスドメイン（すべての正規表現チェックに合格し、完全に有効に見え、最初のオンボーディングメールが到着する前にファネルを静かに破壊するアドレス）。
目次
- メール入力ミスが偽アドレスまたは使い捨てアドレスと異なる問題である理由
- 5つのビジネスモデル全体にわたるメール入力ミスの実際のコスト
- ほとんどの不正なアドレスを占める6つの入力ミスパターン
- 検出方法の比較 - キャプチャ時に入力ミスを実際にキャッチするもの
- 7つの決定における入力ミス耐性登録フロー
- 実践者がメール入力ミスについて実際に尋ねること
メール入力ミスが偽アドレスまたは使い捨てアドレスと異なる問題である理由
分類法から始めてください。記事の残りはそれに依存しています。すべてのサインアップフォームに3つの障害モードが現れ、バウンスログでは似ているように見えますが、まったく異なる対応が必要です。
入力ミスアドレスは機械的入力エラーのある正当なユーザーです：gmial.com、yaho.com、hotnail.com、outlok.com。ユーザーはメールを望んでいます。彼らはアクティベーションリンクを期待しています。彼らは素早く入力し、1文字離れ、フォームはそれを受け入れました。ファネルのすべてのメトリックは、実際には最初から到達不可能なユーザーである彼らを、エンゲージされたが消えたユーザーとして扱います。
使い捨てアドレスは形式的には正当ですが、意図的に回避です：mailinator.com、tempmail.io、guerrillamail.com。ユーザーはオプトインしているように見えながら、アクティブに関係をオプトアウトしています。彼らは試用、ゲートされたコンテンツ、割引コードが必要ですが、ライフサイクルメッセージングは必要ありません。専用の使い捨てメールアドレスチェッカーがこのカテゴリを処理します。検出ロジックが基本的に近接計算ではなくドメイン評判ルックアップであるため。
無効または偽のアドレスはゴミ文字列、作り上げられたドメイン、またはボット送信です：[email protected]、[email protected]。人間の意図がなく、回復可能な信号がありません。拒否して続行します。
これらは登録境界で異なるプロセスが必要です。使い捨てはブロックまたはゲスト層へのダウングレードが必要です。入力ミスは1クリック修正プロンプトでフラグを立てるべきです。偽りは汎用エラーで拒否されるべきです。これらを単一の「不正なメール」カテゴリとして扱うと、2つの障害モードのいずれかが生じます：回復可能なユーザーにハードブロックで摩擦を追加するか、すべてを受け入れてダウンストリームでバウンスダメージを吸収するかのいずれかです。どちらも高価です。
正規表現の検証が入力ミスをキャッチできない理由は、実装固有ではなく、構造的です。RFC 5321およびRFC 5322はメールアドレスの構文を定義します。許可された文字、引用規則、ドメイン形式、長さ制限。文字列「[email protected]」は完全にRFC準拠です。メールボックスは存在しません。ドメインは入力ミススクワッターに登録されています。ユーザーはあなたのサーバーから単一バイトも受け取りません。しかし、文字列は有効です。正規表現は文字に対して機能し、DNS解決またはドメイン近接には機能しません。これはパターンマッチングのカテゴリリミットであり、より良いパターンで修正できるものではありません。
入力ミスアドレスはRFC準拠、構文的に完璧で、実在のものと構造的に区別できません。これがまさにあなたの検証レイヤーがそれを通過させている理由です。
隠れたボリュームはほとんどのチームが推定するより大きいです。ZeroBounceの40億アドレスデータセットは、一般的なウェブフォームキャプチャの1～3%の範囲に入力ミスドメインを配置しています。Kickboxの入力ミスドメイン研究は、タッチスクーン入力が物理キーボードより高い文字レベルのエラー率を生成するため、モバイルヘビーな視聴者はその範囲の上端に向かってスキューしていることに注目しています。月間10,000のサインアップで1.5%の入力ミス率を行うSaaSの場合、それは毎月150人のユーザーで、あなたが送信するすべてのライフサイクルメール（アクティベーション、機能教育、請求リマインダー、ウィンバック）から自己失格します。
これらの150人のユーザーは3つのダウンストリームコストチャネルを同時に流れます。オンボーディングシーケンスはボイドに火をつけ、試用から有料への変換をドラッグします。トランザクショナルメール（パスワードリセット、レシート、二要素コード）は到着しないため、1件あたり5～15ドルのサポートチケットが生成されます。マーケティングキャンペーンは、タイプされたアドレスだけでなく、ドメイン全体のメール送信者の評判を低下させるハードバウンスを蓄積します。次のセクションのコストマトリックスは5つの一般的なビジネスモデルの各チャネルを定量化しています。
5つのビジネスモデル全体にわたるメール入力ミスの実際のコスト
同じ1～3%の入力ミス率は、メールがビジネスで実際に何をするかに応じて劇的に異なるドルダメージを生じさせます。タイプされたB2Bリードとタイプされたeコマースチェックアウトは異なる方法で、異なるタイムラインで、異なるレベルのレベルに対して失敗します。
| ビジネスモデル | 失われた主要なメール機能 | 入力ミス率への影響 | 複合効果 |
|---|---|---|---|
| SaaS無料試用 | アクティベーション+オンボーディングシーケンス | 1～2%は試用を開始しない | オンボーディングリフトの15～25%が失われる |
| eコマースチェックアウト | 注文確認+配送 | 1～3%はサポートチケットをトリガー | 「私の注文はどこ」あたり5～15ドル |
| ニュースレター/コンテンツ | ウェルカム+継続キャンペーン | 1～3%はエンゲージメント確認を行わない | バウンスが2%危険ゾーンに近づく |
| B2Bリード生成 | リードナーチャリング+営業引き渡し | 0.5～1.5%（デスクトップヘビー） | 失われたMQL=完全なCAC無駄 |
| モバイルファーストコンシューマーアプリ | アカウント検証+再エンゲージメント | 2～3%以上（モバイルスキュー） | 低いモバイル保持を複合化 |
入力ミス率ソース：ZeroBounce40億アドレス分析とKickboxの入力ミスドメイン研究。オンボーディングリフト数値はTotango 2023 SaaS Metrics Reportからです。バウンス閾値はMailchimpの配信可能性ベンチマークとM3AAWGの送信者ベストコモンプラクティスからです。モバイルエラー率はAzenkotとZhaiのMobileHCIテキスト入力研究からです。
SaaSは入力ミスごとの最高のドル影響を被ります。コストが顧客ライフサイクル全体にわたって複合化するためです。数学を見ます。Totangoベンチマークは、構造化オンボーディングメールシーケンスからのリフトをシーケンスなしで15～25%に配置しています。タイプされたユーザーはオンボーディングメールをゼロ受け取り、ベースライン変換に戻ります。月額50ドルの計画で平均12ヶ月のテニュアを持つ場合、失われた各ユーザーの20ポイント変換デルタは、大体タイプされた各サインアップあたり120ドルの予想収益を表します。月間10,000のサインアップで1.5%の入力ミス率で、150ユーザー×120ドル=月あたり約18,000ドルの予想収益が静かに失われているということです。紹介、拡張、口コミの効果を数える前に。
サインアップフォームの検出されない入力ミスのすべてのパーセンテージポイントは、ボイドに発火するオンボーディング投資のパーセンテージポイントです。
eコマースは失われたメールではなくサポート負荷で支払う。Zendesku顧客サービスベンチマークデータは認証と「メールを受け取りませんでした」問題をインバウンドチケットのトップカテゴリに配置し、総量の15～30%を占めることが多いです。意味のある割合は、送信者側の配信可能性障害ではなく、タイプされたキャプチャに遡ります。顧客はgmial.comを入力し、注文確認はハードバウンスし、顧客は注文が失敗したと想定し、チケットは手動で5～15ドルで解決するためにキューアップします。
ニュースレール送信者は評判カスケードに直面します。新規サインアップの1～3%がハードバウンスすると、Mailchimpが配信可能性危険ゾーンとしてフラグを立てるキャンペーンごとのバウンス上限に向かって加速します。ダメージはタイプされたアドレスに限定されません。ISPはバウンス率が2%を超えて維持されると、ドメイン全体への送信にフィルタリングを適用します。1つの悪いキャプチャコホートは、次の3つのキャンペーンの正当なインボックスプレイスメントを抑制できます。
DMAの報告されたメールROI1ドルあたり35～42ドル（DMA Marketer Email Tracker）は、コスト計算を増幅します。配信されないメールの小さなパーセンテージでも、そのレバレッジ比率に対して乗数します。1.5%の入力ミス率は1.5%の収益損失ではありません。これは1.5%の送信投資がゼロ出力を生成しながら、残りの98.5%が公開されたROIを生成する場合です。非対称性は、見かけのサイズと比較して入力ミスを修正する価値がある理由です。
ほとんどの不正なアドレスを占める6つの入力ミスパターン
入力ミスはランダムではありません。これらはキーボードレイアウト、モバイルオートコレクト動作、および予測可能な認知ショートカットによって駆動される機械的パターンの一握りに集まります。各パターンの背後にあるメカニズムを知ることは、決定的に修正可能なものと何がユーザー確認を必要とするかを示します。
- ドメインレベルの近接入力ミス（gmial、yhoo、hotnail）。これらはQWERTYキーボード隣接性に従います。「i」と「a」はホームロー上の隣同士に座り、人差し指が滑り、フォームは結果を受け入れます。ZeroBounceはこれを40億アドレスデータセットの単一最大の入力ミスカテゴリとして識別しています。また、最も回復可能でもあります：正しいドメインへのLevenshtein距離は1で、主要プロバイダーの短いリストに対するあいまいマッチングは高精度でそれらをキャッチします。
- TLD混乱（.co vs .com、.net vs .com、.om vs .com）。「.com」が単一ショートカットキーであるモバイルキーボードによって駆動されるため、見逃される可能性があり、アクティブな国コードTLD（.co.uk、.com.au）を持つ市場のユーザーは正しくない組み合わせに筋肉記憶を探索します。「.co」は自体がコロンビアに割り当てられた有効なTLDであるため、特に有害です。ドメイン存在チェックはきれいに合格します。メールボックスはほぼ確実に存在しません。
- サブドメインとプロバイダースワップ（outlook.com ↔ live.com、icloud ↔ icould、msn ↔ mns）。ユーザーはMicrosoftまたはAppleエラのドメインがアカウントに使用しているものを誤って思い出し、特に移行後。レガシープロバイダーで元のサインアップが発生した古いユーザー人口統計での高い有病率。あいまいマッチングが入力ミスドメインレジストリに対してこれらをキャッチしますが、正規表現は動作しません。
- 二重文字または落とされた文字（aaccount、coom、gmaill、hotmai）。タッチスクリーンオートフィルアーティファクト。AzenkotとZhaiのテキスト入力研究は、ユーザーが送信前に視覚的に校正しない文字列、特にメールフィールドで、タッチスクリーンで長く、非辞書、視覚的に密集しているため、高いシステム的な文字レベルのエラー率を文書化しています。
- モバイルオートコレクト上書き。予測テキストは有効なメールフラグメントを一般的な辞書単語に静かに「修正」します（「gmail」→「gail」、「outlook」→「outlooks」）。修正は検出的というより構造的です：入力フィールドはOS
type="email"とautocomplete="email"を宣言してオートコレクトを無効化すべきです。Nielsen Norman Groupのフォーム設計ガイダンスは、高エラーリスクフィールドのベースラインプラクティスとしてこれを扱います。 - 空白と句読点スリップ（末尾のスペース、カンマとして期間、ダブル@）。フォームフィールドがディスプレイを視覚的にトリムするため、ユーザーには見えないことが多く、SMLTPがアドレスを拒否するまで問題を隠します。ストリップと正規化ロジックはキャプチャで回復可能なサブセットを排除します。残りはアドレス文法に対して明示的な検証が必要です。
これら6つのパターンのうち、3つは文字列だけからのアドレスから決定的に修正可能です（近接、TLD、二重文字）。2つはあいまいであるためユーザー確認が必要です（サブドメインスワップ、オートコレクト上書き）。1つはすべての検証が実行される前に入力レイヤーで事前防止されます（空白）。修復マップが重要なのは、UX契約を設定するためです。どのパターンが静かな正規化を保証するか、どの「Did you mean?」プロンプトを保証するか、どのエラーメッセージでブロックされるかを設定します。
検出方法の比較 - キャプチャ時に入力ミスを実際にキャッチするもの
ほとんどのチームはすでに何かメールフィールドを検証しています。問題は、彼らが持っているものが構文カテゴリではなく入力ミスカテゴリを実際にキャッチするかどうかです。以下の5つの方法は、現実的なオプション空間をカバーしています。
| 方法 | 入力ミスをキャッチ | リアルタイム | 追加される摩擦 | リスト影響 |
|---|---|---|---|---|
| 正規表現/ RFC構文チェック | いいえ | はい | なし | なし |
| ダブルオプトイン確認 | バウンス後 | いいえ（非同期） | 高い | 20～40%の縮小 |
| クライアント側あいまいマッチ | 部分的 | はい | 低い | 最小限 |
| ドメインMXレコードチェック | いいえ | はい | なし | 低い |
| リアルタイム検証API | はい | はい（sub-500ms） | 最小限 | 最小限 |
ダブルオプトイン縮小数値：GetResponse単一対ダブルオプトイン研究。リアルタイムAPI遅延：NeverBounce APIドキュメンテーション。3層検証アーキテクチャ（構文→MX→メールボックス）：ZeroBounce APIドキュメンテーション。
正規表現は必要だが不十分です。RFC 5321および5322をきれいに実装し、明らかな不正形式の文字列を画面に出し、クライアント側でゼロ時間で実行されます。前述のすべての入力ミスアドレスは正規表現なしで合格します。正規表現を最初のフィルターとして扱いますが、唯一のものとしては扱いません。
ダブルオプトインは最も人気のある「ソリューション」であり最も高価です。GetResponseの研究は、ダブルオプトインリストが20～40%小さかったことを発見しました。単一オプトインリスト。タイプされたユーザーは定義上確認メールを受け取ることができないため、数学的に見落とされた20～40%の中にいます。メカニズムは逆さまです：確認メールはユーザーが既に失われた後にのみ入力ミス問題を診断します。確認メッセージ自体がハードバウンスするときに入力ミスについて学びます。その時点でユーザーはタブを閉じて移動しています。ダブルオプトインは許可とエンゲージメントフィルタリングのために価値を持ち続けています。これは、いかなる意味においても、キャプチャ側の入力ミス検出レイヤーではありません。
クライアント側あいまいマッチング（「Did you mean gmail.com?」）は良いUXであり、インフラストラクチャとして脆弱です。入力ミスドメイン辞書の保守、国際化ドメインの処理、および正当な国コードまたは企業TLD（.co Colombia、.om Oman）がタイプされたと見なされる障害モードを避ける必要があります。Baymard Instituteによって文書化されました。辞書は古くなります。新しいタイプミスパターンが現れます。有効な検証呼び出しの上にUIレイヤーとして有用です。1つの置換ではありません。
MXレコードチェックは存在しないドメインを排除しますが、タイプミスオブリアルドメインの場合を逃します。「gmial.com」は登録済み、MX解決ドメインです。これが長い実行タイプミストラップである理由です。スクワッターがトラフィックを望みます。MXチェックは製造されたドメインをキャッチします。この記事が説明している入力ミスカテゴリをキャッチしません。チェックは安価で実行する価値がありますが、渡してそれを実在のアドレスであると誤解しないでください。
リアルタイム検証APIはすべての4つのレイヤーを結合します。ZeroBounceとNeverBounceによって文書化される標準アーキテクチャは、構文→MX→メールボックスレベルプローブ→入力ミスドメインフラグ→使い捨てドメインフラグを単一sub-500msコールで実行します。出力はバイナリpassfailではなく、登録フローが分類された判定であり、カテゴリごとに異なる分岐ができます。実際の時間メールアドレス検証呼び出しは、5つの独立したバリデータを書かずに、入力ミス用に提案し、使い捨てブロック、無効で拒否できるように、これらの信号を個別の結果コードとして返します。
遅延は異議ではありません。NeverBounceの公開応答時間100～500msはUI遅延の知覚閾値以下です、特にコールがフィールドのぼかしで発火する場合。ユーザーはすでに注意を次のフィールドに移動しています。提案は、彼らが検索するときに現れます。
7つの決定における入力ミス耐性登録フロー
以下のアーキテクチャは理論的ではなく、戦術的です。各項目は、チームが一度行い、登録コードパスで符号化する決定です。理由は特定の構文より重要です。スタックに適応してください。
- 送信時ではなくブラーで検証します。メールフィールドがフォーカスを失ったときに検証コールを実行し、ユーザーが精神的に次のフィールドにコミットする前に提案プロンプトが表示されるようにします。Nielsen Norman Groupのフォーム研究は、インライン検証が送信時検証よりエラー回復に優れていることを示しています。ユーザーはまだ離れたばかりのフィールド志向です。送信時エラーには再オリエンテーションが必要で、罰のように感じます。
- ブール値ではなく、判定分類API応答を使用します。応答は入力ミス、使い捨て、ロールアカウント、および無効メールボックスフラグを分離する必要があります。各トリガーは異なるUIになります。ブール「is_valid」応答は1つの処理を5つの異なる問題に選択するよう強制します。これがチームが回復可能なユーザーをブロックする理由です。ベンダーAPIは理由のためこの方法で構造化された応答です。
- 自動修正ではなく提案します。入力ミスフラグの場合、「Did you mean [email protected]?」を1クリック受け入れとして表示します。静かな自動修正はユーザー信頼を違反します。Baymardのeコマースフォーム研究は、ユーザーがフィールド変化を検出すると放棄することを示しています。また、正当な企業ドメインのようなエッジケースで入力ミスを破棄します。
- 使い捨てを入力ミスとは別にブロックします。使い捨て信号は、限定機能を持つゲスト階層にハードブロックまたはダウングレードの価値があります。入力ミス信号は、1クリック修正で回復可能なユーザーを柔らかく提案する価値があります。両者を同じように扱うことは回復可能なユーザーを罰しながら試用虐待に対して不正に保護します。ブランチングコストは1つの追加条件です。
- 入力レイヤーでオートコレクトを無効化します。
<input type="email" autocomplete="email" autocorrect="off" spellcheck="false">を使用します。これは検証実行前に自動修正上書きパターンを事前防止します。それは、入力ミスクラス全体を排除する5属性変更です。 - ハードバウンス閾値を設定しても計測します。M3AAWGとMailchimpはどちらともキャンペーンごとのハードバウンスが1%未満で持つことをお勧めします。2%が配信可能性危険ゾーンです。サインアップコホートバウンス率で1.5%以上でアラートします。キャンペーン全体率ではありません。コホートレベルバウンスはキャプチャ側検証が特定のソースで失敗していることを示す先行指標です。これは、キャンペーン全体の平均を希釈する属性です。
- 入力ミスパターンをログして、フィードバックします。ユーザーが最も頻繁にタイプするドメインを追跡します。オーディエンスが「yaho.com」または「.cm」パターンを生成する場合、提案ロジックをどこで硬化させるかが分かります。これはキャプチャ時検出とオンゴーイングリストハイジーンインサイト間のループを閉じます。各検証変更から実際のデルタを測定できるため、推測ではなくます。
全体のフローは1つのAPI統合とUI決定の一握りを取ります。複合ペイオフは、すべてのダウンストリームシステム（オンボーディング、請求、サポート、マーケティング）は、すでに境界の入力ミス、使い捨て、無効フィルタをクリアしたアドレスで動作するということです。ダッシュボードでリスト品質問題を診断するのをやめて、フォームで防止し始めます。
実践者がメール入力ミスについて実際に尋ねること
- 確認メールはすでに入力ミスをキャッチしていないですか？いいえ。それは診断します。キャッチされません。GetResponseの単一対ダブルオプトイン比較は20～40%のユーザーが確認しないことを発見しました。タイプされたユーザーは定義上確認メールを受け取ることができないため、数学的に見落とされた20～40%の中にいます。確認メッセージ自体がハードバウンスするときに入力ミスを学びます。その時点でユーザーはタブを閉じて移動しています。実時間キャプチャ側メールアドレス検証は、ユーザーがまだフォーム上にいる間と入力ミスをサーフしており、ワンクリックで修正できます。確認メールは許可とエンゲージメントフィルタリングのための価値を保持します。彼らは入力ミス検出のための機械的副業ではありません。2つのレイヤーは異なるジョブを実行する必要があります。
- 「gmial」を「gmail」に自動修正する場合、ユーザー意図をオーバーライドしていますか？あなたは意図的な選択ではなく、機械的入力エラーを修正しています。しかし、ユーザーを確認する場合のみ。Baymard Instituteのeコマースフォーム研究は、静かな修正がダメージ信頼を示し、正当な企業ドメインと地域TLD（.coコロンビア、.omオマーン）を入力ミスとして破棄して、特に破ります。防御可能なパターンは1クリック提案です：「Did you mean [email protected]? [Yes, use this] [No, keep mine]」。これはユーザー代理店を保持しながら修正をシームレスにします。ユーザーは最終的な決定を保持し、入力ミスされたアドレスは提案が正しい95%以上の場合に回復され、稀な正当なエッジケースには明確なオーバーライドパスがあります。静かな書き直しは間違ったメトリックに最適化され、長いテールの経験を悪化させます。
- 入力ミスアドレスと使い捨てアドレスの違いは何ですか？また、なぜそれが重要なのですか？入力ミスは機械的エラーのある正当なユーザーです。使い捨てはアクティブに関係を回避するユーザーです。信号はダウンストリーム重複：両方ともバウンス、両方ともリスト品質を低下、両方ともデリバリアビリティを傷つけます。しかし、キャプチャ時の応答は異なるべきです。入力ミスは提案プロンプトを取得します。なぜなら、ユーザーが希望しています。使い捨てはブロックまたはダウングレードされます。ユーザーはオプトインしながらオプトアウトしているため。実時間APIがそれらを個別に旗立てることで、2つの並行バリデーター書かずに各ルートを適切に許可します。それらを同一に扱うことは、回復可能なユーザーの過度なブロック（入力ミスと一緒に使い捨てを難しく拒否する場合）か、試用虐待の不正保護（入力ミスと一緒に使い捨てのみソフト警告する場合）のいずれかです。専用使い捨てメールアドレスチェッカーは使い捨て固有検出レイヤーを処理します。入力ミス提案レイヤーは上に座っています。
- 今、サインアップの実際に入力ミスはいくつありますか？業界データは0.5～2%デスクトップヘビーB2B視聴者のためと2～3%以上モバイルヘビーコンシューマーアプリの場合に収まります。ZeroBounceの40億アドレスデータセットとKickboxの入力ミスドメイン研究が最も引用されるソースです。推測ではなく自分の基準を測定するには：最後の90日のサインアップを引き出し、ESPのハードバウンスログに対して相互参照し、主要プロバイダー（gmail、yahoo、hotmail、outlook、icloud、aol）から1 Levenshtein文字のバウンスを隔離します。そのサブセットは現在の入力ミス率です。実時間検証展開から30日後に同じクエリを再実行して、デルタをきれいに測定します。前後の数字は、内部的正当化のための唯一の番号です。
- APIなしでタイプミス検出を自分で構築できますか？部分的です。共通タイプドメイン（gmial.com、yaho.com、hotnail.com、outlok.com、icould.com）のハードコードリストに対するクライアント側あいまいマッチングスクリプトは、低コストで上位60～70%をキャッチします。Levenshtein距離≤2の20大プロバイダーのリストは、ボリュームの驚くべき共有をカバーしています。残りのケースはインフラが必要です：TLD混乱処理、サブドメインスワップ検出、メールボックスレベル非存在プローブ、および新しいパターンが出現する際の継続的に更新された入力ミスドメインレジストリ。ビルド対購入の閾値は通常、あなたのチームが永遠に辞書保守、MXチェックインフラ、およびSMTPレベルのメールボックスプローブの所有権を望むかどうかです。ほとんどのチームにとって、APIパスはメンテナンスオーバーヘッドより安価です。長いテールパターンでの限界カバレッジ利益は、実際の収益が存在する場所です。初日に体験デセント剧本が処理する上位60%ではなく。