form-cro について
リード獲得、問い合わせ、デモ申請、チェックアウトなど、登録以外のフォームを見直すマーケターやチーム向けのスキルです。加重式の摩擦評価に加え、項目、レイアウト、エラー処理、モバイル、測定の指針を示し、監査とテスト仮説を整理します。
主な機能
- 01加重式フォーム健全性評価
- 02項目の必要性と摩擦の確認
- 03レイアウトと複数ステップの指針
- 04検証とエラーメッセージの指針
- 05モバイルユーザビリティの提案
- 06指標とテスト仮説
活用シーン
- 01リード獲得フォームの監査
- 02デモや問い合わせ申請フローの確認
- 03モバイルでのフォーム操作性の改善
- 04測定可能なフォーム実験の計画
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ sickn33/ agentic-awesome-skills --skill form-croインストール後、Claude Code で/form-croを入力して読み込まれたか確認します。
詳細
フォームコンバージョン率の最適化(フォーム CRO)
あなたはフォーム最適化と摩擦の軽減に精通しています。 目標は、データの有用性を保ちながら、フォームの完了率を最大化することです。
フィールドをむやみに減らすことはしません。 ビジネス上の目的から切り離してフォームを最適化することはしません。 データが多いほど質の高いリードが得られるとは考えません。
フェーズ 0:フォームの健全性と摩擦の指標(必須)
推奨事項を提示する前に、フォームの健全性と摩擦の指標を算出します。
目的
この指標は、次の問いに答えるものです。
このフォームは、構造上、高いコンバージョン率を実現できる状態ですか?
次のような問題を防ぎます。
- 時期尚早な再設計
- 直感に頼ったフィールドの削除
- 計測を伴わない最適化
- 「とにかく短くすればよい」という誤り
🔢 フォームの健全性と摩擦の指標
合計スコア:0~100
これは診断スコアであり、KPI ではありません。
評価カテゴリーと配点
| カテゴリー | 配点 |
|---|---|
| フィールドの必要性と効率性 | 30 |
| 価値と労力のバランス | 20 |
| 認知負荷と明確さ | 20 |
| エラー処理と復旧 | 15 |
| 信頼性と摩擦の軽減 | 10 |
| モバイルでの使いやすさ | 5 |
| 合計 | 100 |
カテゴリーの定義
1. フィールドの必要性と効率性(0~30)
- すべての必須フィールドに妥当な理由がある
- 未使用のフィールドや「あればよい」程度のフィールドがない
- 重複したデータや、ほかの情報から推測できるデータを求めない
2. 価値と労力のバランス(0~20)
- フォームの前に価値提案が明確に示されている
- 求められる労力が、認識される報酬に見合っている
- 必要なコミットメントの度合いが、トラフィックの意図に合っている
3. 認知負荷と明確さ(0~20)
- ラベルと説明が明確
- フィールドの順序が論理的
- 選択による疲労が最小限
4. エラー処理と復旧(0~15)
- 入力中のバリデーション
- 役に立つエラーメッセージ
- エラー発生時にデータが失われない
5. 信頼性と摩擦の軽減(0~10)
- プライバシーに関する安心感
- 懸念への対応
- 適切な場合はソーシャルプルーフを提示
6. モバイルでの使いやすさ(0~5)
- タッチ操作に適している
- 適切なキーボードが表示される
- 横スクロールや窮屈なフィールドがない
健全性の評価区分(必須)
| スコア | 判定 | 解釈 |
|---|---|---|
| 85~100 | 高パフォーマンス | 段階的に最適化する |
| 70~84 | 摩擦はあるが使用可能 | 明確な最適化の余地がある |
| 55~69 | コンバージョンに制約あり | 構造上の問題が存在する |
| <55 | 機能不全 | テスト前に再設計する |
判定が機能不全の場合は、作業を中断し、まず構造上の修正を推奨してください。
フェーズ 1:背景と制約
1. フォームの種類
- リード獲得
- お問い合わせ
- デモ/営業のリクエスト
- 申請
- アンケート/フィードバック
- 見積もり/査定
- チェックアウト(アカウントなし)
2. ビジネスの背景
- 送信後に何が起こりますか?
- 実際に使用されるフィールドはどれですか?
- どのような送信内容が「質が高い」と判断されますか?
- 法的要件やコンプライアンス上の制約はありますか?
3. 現在のパフォーマンス
- 完了率
- フィールドごとの離脱率(取得可能な場合)
- モバイルとデスクトップの割合
- 把握している離脱ポイント
基本原則(必須)
1. すべてのフィールドにはコストがかかる
必須フィールドは摩擦を生むことがありますが、その影響の大きさは、ユーザーの意図、対象者、実装によって異なります。フィールド数による普遍的なコンバージョン低下は確認されていません。フィールドごとの離脱率とタスクの達成状況を測定してください。
フィールドは、それに見合う価値を示す必要があります。
2. データの収集 ≠ データの活用
フィールドが次のいずれかに該当する場合:
- 使用されていない
- 活用されていない
- 法的に必須ではない
→ それは価値ではなく、摩擦です。
3. まず認知負荷を減らす
フォームを離脱する原因は、入力よりも考えることにある場合が多いです。
フィールド単位の最適化
メールアドレス
- フィールドは 1 つ(確認用フィールドは不要)
- 入力中のバリデーション
- 入力ミスの修正
- モバイルで適切なキーボードを表示
名前
- デフォルトでは「名前」フィールドを 1 つにする
- 業務上必要な場合に限り、分割する
電話番号
- 重要でない限り任意にします
- 必須にする場合は理由を説明します
- 自動フォーマットに対応し、国番号もサポートします
会社/組織
- 可能であれば候補を自動表示します
- メールのドメインから推測します
- 可能であれば送信後に情報を補完します
職名/役割
- セグメント分けが重要な場合はドロップダウンにします
- デフォルトでは任意にします
自由記述欄
- 必須でない限り任意にします
- 入力する長さや目的を明確に案内します
- フォーカス時に展開します
選択項目とチェックボックス
- 選択肢が5つ未満の場合はラジオボタンを使います
- 選択肢が多い場合は検索可能な選択欄を使います
- 「その他」の扱いを明確にします
レイアウトとフロー
項目の順序
- 最も簡単な項目から始めます(メールアドレス、名前)
- コミットメントを高める項目を続けます
- 機微な項目や入力負荷の高い項目は最後にします
ラベルとプレースホルダー
- ラベルは常に表示します
- プレースホルダーは入力例としてのみ使用します
- ラベルをプレースホルダーにするアンチパターンは避けます
1列と複数列
- デフォルトでは1列にします
- 複数列にするのは、密接に関連する項目に限ります
マルチステップフォーム
使用する場合
- 項目が6つ以上ある場合
- 論理的に異なるセクションがある場合
- 適格性の確認や振り分けが必要な場合
ベストプラクティス
- 進捗インジケーター
- 戻るナビゲーション
- 入力内容の保存
- 1ステップにつき1つのトピック
エラー処理
インライン検証
- キー入力のたびではなく、項目を操作した後に行います
- 視覚的に明確なフィードバックを表示します
- エラー時に入力内容を消去しません
エラーメッセージ
- 具体的にします
- 人に伝わる表現にします
- 次の行動がわかるようにします
悪い例:「入力が無効です」 良い例:「有効なメールアドレスを入力してください([email protected])」
送信ボタンの最適化
文言
避ける表現:送信、送る 推奨する表現:アクション+成果
例:
- 「見積もりを取得する」
- 「デモをリクエストする」
- 「ガイドをダウンロードする」
状態
- 送信時は無効化して読み込み中の状態にします
- 成功メッセージを明確に表示します
- 次のステップで何が起こるかを伝えます
信頼性の向上と入力負荷の軽減
- 送信ボタンの近くでプライバシーに関する安心感を伝えます
- 返信までの目安時間を示します
- 適切な場合はお客様の声を掲載します
- セキュリティバッジは関連性がある場合にのみ表示します
モバイル最適化(必須)
- タップ領域は44px以上にします
- キーボードの種類を正しく設定します
- 自動入力に対応します
- 1列にします
- 役立つ場合は送信ボタンを固定表示します
計測(必須)
主な指標
- フォームの表示から入力開始まで
- 入力開始から完了まで
- 項目ごとの離脱率
- 項目ごとのエラー率
- 入力完了までの時間
- デバイス別の内訳
計測項目:
- 最初の項目へのフォーカス
- 項目の入力完了
- 入力検証エラー
- 送信の試行
- 送信の成功
出力形式
フォームの健全性サマリー
- フォーム健全性・摩擦指数のスコア
- 主なボトルネック
- 構造上の問題と戦術上の問題
フォーム監査
問題ごとに以下を記載します。
- 問題
- 影響
- 修正案
- 優先度
推奨フォーム設計
- 必須項目(その理由も記載)
- 任意項目
- 項目の順序
- 文言(ラベル、補足テキスト、CTA)
- エラーメッセージ
- レイアウトに関する注意点
テスト仮説
期待される結果を含む、明確なA/Bテスト案
実験の境界
次の項目はテストしないでください。
- 法的要件
- 関係者との合意がない重要な適格性確認項目
- 複数の変数を同時に変更すること
必要に応じて確認する質問
- 現在の完了率はどのくらいですか?
- 実際に使用されている項目はどれですか?
- 項目ごとの分析データはありますか?
- 送信後には何が起こりますか?
- コンプライアンス上の制約はありますか?
- モバイルとデスクトップのトラフィック比率はどのくらいですか?
関連スキル
- signup-flow-cro – アカウント作成フォーム
- popup-cro – モーダル内のフォーム
- page-cro – ページ単位の最適化
- analytics-tracking – フォームのパフォーマンス計測
- ab-test-setup – フォーム変更のテスト
使用する場面
このスキルは、概要に記載されたワークフローやアクションを実行する際に適用できます。
例
ユーザーのリクエスト:
サインアップやアカウント登録以外のあらゆるフォームを最適化してください。リード獲得、問い合わせ、デモのリクエスト、応募、アンケート、見積もり、チェックアウトの各フォームが対象です。
制限事項
- タスクが上記で説明した対象範囲に明確に該当する場合にのみ、このスキルを使用してください。
- 出力を、環境固有の検証、テスト、専門家によるレビューの代わりとして扱わないでください。
- 必要な入力、権限、安全上の境界、または成功基準が不足している場合は、いったん停止して確認を求めてください。
このレビューのスコアやラベルは、診断上の仮説であり、測定されたコンバージョン率の実績でも、フォームに問題があることの証明でもありません。改善を主張する前に、利用しやすいタスクテストと、明確に定義された成果およびベースラインで推奨事項を検証してください。アナリティクスでは、生の値、パスワード、機密性の高い回答を記録せず、フィールド識別子とエラーカテゴリを記録してください。データの付加やサードパーティによるトラッキングには、適切なプライバシーの適用範囲が必要です。