developer-signup-flow

開発者向けサインアップフロー

開発者の時間を大切にし、できるだけ早くコーディングを始められるサインアップ体験を作りましょう。

概要

開発者向けサインアップは、開発者を理解していることを示す最初の機会です。不要なフォーム項目が一つ増えるたび、クリックが一回増えるたび、「続行する前にメールアドレスを確認してください」と求めるたびに、開発者の時間を大切にしていないというメッセージを伝えてしまいます。優れた開発者向けサインアップは、ほとんど存在しないかのように感じられます。開発者は「試してみたい」と思ってから60秒以内に「コードを書いている」状態になります。

このスキルでは、OAuth の統合、API キー生成の UX、段階的なプロフィール収集、そしてサインアップのコンバージョンで本当に重要な指標の測定について説明します。

始める前に

対象とする開発者セグメントを理解するために、/devmarketing-skills/skills/developer-audience-context スキルを確認してください。週末に趣味で試すユーザーを対象にするのか、社内で使うツールを評価するエンタープライズ開発者を対象にするのかによって、サインアップの最適化方法は大きく異なります。

効果的な OAuth の選択肢

GitHub を最優先するアプローチ

開発者向けツールでは、GitHub OAuth を主要な選択肢にしましょう。その理由は次のとおりです。

1. 本人確認が組み込まれている - アクティブな GitHub アカウントには、コミット履歴、リポジトリ、ソーシャルプルーフがあります
2. スコープに馴染みがある - 開発者は GitHub の権限モデルを理解しています
3. プロフィールデータ - ユーザー名とメールアドレスを取得でき、公開アクティビティから経験レベルを推測できます
4. 信頼のシグナル - GitHub は開発者がすでに日常的に使っている場所です

優れた実装（Vercel）：

• ページの目立つ位置に「GitHub で続行」ボタンが1つだけある
• メールアドレスでの登録も可能だが、二次的な選択肢として表示される
• パスワードの作成は不要
• OAuth の後、ダッシュボードにすぐリダイレクトされる

悪い実装：

• GitHub、Google、Twitter、LinkedIn、メールアドレス、「電話番号で登録」がすべて同じ目立ち方で表示される
• GitHub OAuth の後でもメールアドレスの確認が必要
• ダッシュボードを表示する前に、追加のプロフィール情報を求める

OAuth の選択肢の優先順位

対象ユーザーに応じて優先順位を付けましょう。

対象ユーザー	主要な選択肢	二次的な選択肢	避ける選択肢
オープンソース開発者	GitHub	メールアドレス	Google Workspace
スタートアップの開発者	GitHub	Google	エンタープライズ SSO
エンタープライズ開発者	SSO/SAML	Google Workspace	ソーシャルログイン
データサイエンティスト	GitHub	Google	Twitter
モバイル開発者	Google	GitHub	Facebook

Google OAuth を利用する際の考慮事項

次の場合、Google OAuth は効果的です。

• ツールが Google Cloud サービスと連携する
• Android 開発者を対象としている
• 対象ユーザーに、技術職以外の関係者（プロダクトマネージャー、デザイナー）が含まれる

次の場合、Google OAuth は効果的ではありません。

• 開発者が個人用 Gmail を使っている一方で、仕事用のアカウントで登録する必要がある
• ツールが Google エコシステムと連携しない
• Google Workspace 固有のスコープが必要になる

メールアドレスでの登録：適している場合

メールアドレスとパスワードでの登録は用意しておくべきですが、主要な選択肢にはしないでください。次のような開発者に向いています。

• OAuth がブロックされているエンタープライズ環境の開発者
• サードパーティへのアクセスを制限する、プライバシーを重視する開発者
• GitHub や Google のアカウントが仕事上の本人確認に適さない場合

メールアドレスでの登録をサポートする場合：

• メールアドレスだけで登録できるようにします。パスワードの作成を求めず、マジックリンクを送信します
• ダッシュボードを表示する前に、メールアドレスの確認を求めてはいけません
• マジックリンクを好む開発者向けに、「後でパスワードを設定」を用意します

フォーム項目を減らす

項目ゼロを目指す

最適なサインアップでは、独自のフォーム項目はゼロです。必要な情報はすべて OAuth から取得できます。

• 名前（OAuth プロフィールから取得）
• メールアドレス（OAuth プロフィールから取得）
• ユーザー名／ハンドル（GitHub のユーザー名から取得）
• アバター（OAuth プロフィールから取得）

質問が必要な場合

本当に情報が必要な場合は、後回しにしましょう。

悪い例：登録をブロック

Create Account
- Email
- Password
- Company Name (required)
- Role (required)
- Team Size (required)
- How did you hear about us? (required)
[Create Account]

良い例：段階的な収集

Continue with GitHub
[Immediate dashboard access]

[Later, contextually in dashboard]
"To customize your experience, what are you building?"
[ ] API/Backend
[ ] Web app
[ ] Mobile app
[ ] Data pipeline
[Skip for now]

フィールドの追加を判断するチェックリスト

追加する各フィールドについて、以下に回答してください。

• OAuth プロフィールデータから推測できますか？
• サインアップ後の行動から推測できますか？
• 必要な場面で、後から質問できますか？
• このフィールドによって、どのような判断が可能になりますか？また、その判断を今すぐ行う必要がありますか？
• このフィールドによって、コンバージョンにどれほどのコストが生じますか？

調査によると、必須フィールドが1つ増えるごとにコンバージョン率が5～10％低下します。

API キー生成の UX

すぐにキーを生成する

開発者はコードを書くためにサインアップします。すぐに API キーを表示してください。

優れた実装例（Stripe）：

1. OAuth の完了
2. ダッシュボードにテスト API キーがすぐに表示される
3. 追加のクリックなしでキーを確認してコピーできる
4. テストキーではなく、本番キーに「表示」パターンを使う

悪い実装例：

1. OAuth の完了
2. 「ようこそ！始めるにはプロフィールを完成させてください」
3. プロフィールフォームの入力が必須
4. 「最初のプロジェクトを作成する」ウィザード
5. プロジェクト設定ページ
6. 「API キーを生成」ボタン
7. ようやくキーが表示される

キー表示のベストプラクティス

Your API Key
sk_test_xxxxxxxxxxxxxxxxxxxx  [Copy]

[Show in cURL example] [Show in SDK example]

• 等幅フォントでキーを表示する
• ワンクリックでコピーできるボタンを用意する
• コード例など、コンテキストの中でキーを表示する
• テストキーはデフォルトで表示する
• 本番キーは「表示」をクリックして確認できるようにする
• キーをファイルにダウンロードするよう求めない

複数のキーとキー管理

開発者に必要になるまで待ちましょう。初回サインアップ時には、キーを1つだけ表示します。

次の場合にキー管理機能を導入します。

• 開発者が2つ目のプロジェクトを作成したとき
• 開発者がチームメンバーを招待したとき
• 開発者がキーのローテーションについて質問したとき

オンボーディングのパーソナライズ

ユースケースに基づくパス

質問を1つして、その後の体験をカスタマイズします。

質問（サインアップ後に表示、省略可能）： 「何を構築していますか？」

• 既存のアプリと連携する
• 新しいものを構築する
• チームでの導入を検討する
• まずは試してみる

パスのカスタマイズ：

選択肢	ダッシュボードで重視する内容	最初の CTA	ドキュメントのデフォルト
既存のアプリと連携	SDK と連携機能	「SDK をインストール」	連携ガイド
新しいものを構築	クイックスタートチュートリアル	「チュートリアルを始める」	はじめに
チームでの導入を検討	料金と機能	「デモを予約」	ユースケース
まずは試してみる	インタラクティブなプレイグラウンド	「プレイグラウンドを試す」	API リファレンス

フレームワーク／言語の検出

GitHub OAuth を使っている場合は、公開リポジトリを確認して言語の傾向を把握します。

Primary language: Python (45% of repos)
Also uses: JavaScript (30%), Go (15%)

→ Show Python SDK first in docs
→ Default code examples to Python
→ Suggest Python quickstart

行動に基づくパーソナライズ

サインアップ後の行動を追跡し、それに応じて調整します。

行動	調整
cURL の例をコピーする	cURL の例を増やし、SDK の例を減らす
早い段階で料金ページを閲覧する	ダッシュボードに無料枠の制限を表示する
複数のプロジェクトを作成する	チーム機能を提案する
ドキュメントを頻繁に閲覧する	「困っていますか？」ヘルプウィジェットを追加する

プログレッシブプロファイリング

収集する情報とタイミング

サインアップ時（OAuth のみ）：

• 名前、メールアドレス、アバター（OAuth から取得）

最初のセッション（任意、コンテキストに応じて）：

• 主なユースケース（ワンクリック）
• 希望する言語（推測、またはワンクリック）

最初の API 呼び出し後：

• 会社名（エンタープライズ機能向け）
• チームの規模（コラボレーション機能向け）

無料枠の上限に達した後：

• 電話番号（請求用）
• 請求先住所（請求書発行用）

アップグレード後：

• 会社の詳細プロフィール（アカウント管理用）
• 業界／分野（導入事例用）

プログレッシブプロファイリングを自然に感じさせる

悪い例：ランダムなポップアップ

[Popup after 3 days]
Help us serve you better!
Company: ___
Role: ___
Team size: ___
How did you hear about us: ___

良い例：コンテキストに応じた質問

[When developer invites first team member]
To set up your team workspace, what should we call it?
Company/Team name: ___

[When developer hits rate limit]
To increase your rate limit, we need to verify your account:
Phone: ___

サインアップのコンバージョン測定

主な指標

サインアップ開始率

• 「サインアップ」または「始める」をクリックした訪問者
• ベンチマーク：ランディングページ訪問者の5～15％

サインアップ完了率

• OAuth またはフォーム送信を完了したユーザー
• ベンチマーク：サインアップ開始数の70～90％（OAuth の場合）
• ベンチマーク：サインアップ開始数の30～50％（フォームの場合）

サインアップまでの時間

• サインアップのクリックからダッシュボード表示までの秒数
• ベンチマーク：OAuth では30秒未満、フォームでは60秒未満

アクティベーション指標（サインアップ後）

API キーのコピー率

• API キーをコピーしたユーザー
• ベンチマーク：初回セッション中に 60～80％

初回 API 呼び出し率

• 少なくとも 1 回 API を呼び出したユーザー
• ベンチマーク：最初の 24 時間以内に 30～50％

初回 API 呼び出しまでの時間

• サインアップから初回 API 呼び出しまでの時間（分）
• ベンチマーク：オンボーディングが適切に設計されている場合、10 分未満

ファネル分析

ファネル全体を追跡します：

Landing page visitors: 10,000
├── Clicked signup: 1,000 (10%)
├── Completed signup: 800 (80% of clicks)
├── Copied API key: 600 (75% of signups)
├── First API call: 300 (50% of key copies)
└── Second day return: 150 (50% of first call)

開発者がどこで離脱するのか、またその理由を特定します：

• OAuth 権限画面での離脱
• メール認証の遅延
• ダッシュボードに戸惑う
• API キーが見つからない
• 初回 API 呼び出しの失敗

A/B テストの優先順位

次の順番でテストします（効果が高いものから）：

1. 表示する OAuth オプションの数
2. フォームの入力項目数
3. メール認証のタイミング
4. ダッシュボード上の API キーの配置
5. デフォルトのクイックスタート言語
6. ウェルカムメールの送信タイミング

実際の開発者向けツールの例

優れたサインアップ：Vercel

1. 「GitHub で続行」が最も目立つ
2. OAuth はワンクリックで完了
3. インポートオプションが表示されたダッシュボードにすぐ移動
4. 質問されない
5. 60 秒以内に初回デプロイが可能

優れたサインアップ：Stripe

1. メールベースだが、手順は最小限
2. ダッシュボードを表示する前のメール認証は不要
3. テスト用 API キーがすぐに表示される
4. ガイド付きセットアップは任意
5. テストモードと本番モードが明確

サインアップが不適切な例：[避けるべき一般的なパターン]

• 「プロフィールを完成させる」までダッシュボードにアクセスできない
• 何も見られないうちにメール認証を求められる
• 会社名とチームの規模の入力が必須
• 電話番号の認証が必須
• スキップできない「最初のプロジェクトを作成」ウィザード
• 複数回クリックして画面を移動しないと API キーが見つからない

ツール

分析とテスト

• Amplitude/Mixpanel - ファネル分析とコホート追跡
• LaunchDarkly/Split - OAuth フローの A/B テスト
• FullStory/LogRocket - サインアップのデバッグ用セッションリプレイ
• Customer.io/Intercom - オンボーディングメールのシーケンス

認証プロバイダー

• Auth0 - 高機能ですが、複雑さが増します
• Clerk - 開発者向けで、デフォルト設定が優れています
• WorkOS - 必要に応じてエンタープライズ SSO を利用できます
• Supabase Auth - シンプルなオープンソースの選択肢
• Firebase Auth - モバイルファーストのプロダクトに適しています

API キー管理

• Unkey - サービスとしての API キー管理
• Custom - 開発者向けツールの多くは独自のものを構築しています

関連スキル

• /devmarketing-skills/skills/developer-onboarding - サインアップ後に起こること
• /devmarketing-skills/skills/developer-audience-context - サインアップするユーザーの理解
• /devmarketing-skills/skills/free-tier-strategy - サインアップする目的