製品アップデート: より優れたバルク検証UX、より正直な非同期進捗、およびモダンMCP接続モデル

過去のリリースサイクルを通じて、すべてが同じ方向を指す一連の変更を行いました。BillionVerifyをより信頼しやすく、監視しやすく、統合しやすくしています。

これらの変更の一部は製品で即座に見られます。Bulk Verifyエクスペリエンスはファイル提出後よりクリーンになりました。検証履歴ページはジョブがまだ実行中でもより有用です。プログレスインジケータはユーザーが実際に関心のあることを反映し、内部キュー機構を露出させなくなりました。

変更の一部はより深いレベルです。UIの背後にある検証ステータスコントラクトはより豊かで明示的です。データモデルはメールレベルのプログレスとバックエンド実行プログレスを区別しており、これはクライアントに正直なリアルタイムの状態をレンダリングするための非常に優れた基盤を提供します。

そして変更の一部は開発者に直接影響します。BillionVerify MCPは古い?api_key=セットアップ形状から完全に移行し、OAuth、保護されたリソース検出、モダンなクライアント互換性を中心とした、ホスト型のリモートMCPモデルに移行しました。製品、ドキュメント、マーケティングページ、認証サーフェスを更新して、その現実に対応させました。

このポストはこれらの更新を1つのナラティブにまとめているため、顧客、開発者、内部チームはそれらがどのように適合するかを確認できます。

短いバージョンが欲しい場合、ここにあります：

Bulk Verificationはクリーンなアップロード後フローを使用しています。
非同期ジョブ監視はより有益で、より正直です。
バックエンドステータスインターフェイスは分散作業用にはより良く構造化されています。
BillionVerify MCPは現在、より明確な長期的形状を持っています：リモートエンドポイント、URLに埋め込まれたAPIキーではなく、OAuthを含みます。

完全なストーリーが欲しい場合、読み続けてください。

クイックリンク

なぜこれらの更新が一緒に属するのか

一見すると、このリリースはいくつかの別々のテーマに見えます：

一括検証ページのフロントエンドのクリーンアップ
より詳細な履歴詳細画面
バックエンドステータスコントラクトのアップグレード
MCP認証とドキュメンテーションのクリーンアップ

しかし、根底にあるテーマはすべてで同じです：曖昧性を排除することです。

曖昧性はソフトウェア製品ではさまざまな形で現れます。

ファイルアップロード後の重複したUIとして表れることもあります。ユーザーはどのボタンが重要か、次のステップはどこにあるか、またはシステムがバックグラウンドで作業を続けているかどうかが不確かです。

「29% 完了」と表示されていても、周囲の数字がその割合が何を表しているかを説明していない進捗バーとして表れることもあります。処理されたメール数の 29% ですか？完了したワーカータスクの 29% ですか？マージされた結果の 29% ですか？ほとんどのユーザーはジョブを監視するためにキューアーキテクチャをデコードしたくありません。

曖昧性は開発者のオンボーディングにあることもあります。製品は既に本番環境で 1 つのアーキテクチャをサポートしていますが、その公開ドキュメントの一部は古い接続モデルを提案し続けています。これにより、セットアップエラー、混乱、および不必要な不信感が生じます。

このリリースは、これらの問題に対する私たちの答えです。

ユーザーが実際に知る必要があることについて、製品の UX を厳密にしました。クライアントが実際にレンダリングする必要があることについて、バックエンドインターフェースを厳密にしました。そして、プラットフォームが今日どのように機能するかについて、開発者向けの MCP ストーリーを厳密にしました。

1. Bulk Verifyがよりクリーンなアップロード後の体験を実現

このリリースの第一部は、ファイルが送信された直後の瞬間に焦点を当てました。

その瞬間は見た目以上に重要です。

大規模なCSVファイルをメール検証用にアップロードするとき、ユーザーはまだ完了していません。入力状態から監視状態へと移行したばかりです。インターフェースは、いくつかの直後の質問に答えるのをサポートする必要があります：

ファイルは正常に送信されましたか？
処理はすでに開始されていますか？
この特定のジョブを監視するにはどこに移動しますか？
システムが完了時に通知してくれることを信頼できますか？

以前のフローはこれらの質問に答えていましたが、多くの繰り返しで行っていました。成功カード、周囲のステータステキスト、利用可能なボタンはすべて、わずかに異なる方向に注意を引きました。

私たちはそれをクリーンアップしました。

ページで変更されたもの

サブミッション成功状態がより簡潔になり、スキャンしやすくなりました。成功アイコンとタイトルの垂直方向のスペースが削減され、ユーザーが実際に気にするディテールに余裕ができました：ファイル名、メールカウント、推定処理時間、次のアクション。

ライブプログレスもサブミッション後にデフォルトで表示されます。ユーザーはその情報を表示するために追加のステップを実行する必要がなくなりました。ジョブが進行している場合、ページはそれを直ちに表示する必要があります。

メインのポスト送信CTAも重要な方法で変更されました。ユーザーをジェネリック履歴インデックスに送信する代わりに、プライマリアクションは直接正確なジョブ詳細ページにリンクします。小さな変更に聞こえるかもしれませんが、不要なホップを削除し、ワークフローをより意図的に感じさせます。

また、技術的には機能していたが、意味のある有用性がなかった要素も削除しました：

アップロードエリア内の重複ステータステキスト
成功カード内の余分な「別のファイルをアップロード」ボタン

ユーザーはメインアップロードサーフェスから別のファイルをアップロードできます。違いは、インターフェースがもう自分自身と競争しないということです。

これが実際に重要な理由

Bulk検証は、繰り返しの運用ワークフローでよく使用されます。ユーザーは1日に複数のファイルをアップロードし、仕事セッション全体で複数のジョブを監視し、後でフィルタ済み結果をダウンロードするために戻ってくることがあります。その種の環境では、UI重複の小さな部分でも累積されます。

ポストアップロード状態をクリーンアップすることで、3つの方法で役立ちます：

サブミッション直後に必要なスクリーン解析の量を削減します。
次のステップを明らかにします。
UIをユーザーのメンタルモデルに合わせます：「ファイルは中にあります。これでこのジョブをフォローしたいです。」

これは、それ自体でスプラッシュスクリーンショットを作ることはめったにないが、毎日製品をより落ち着きと一貫性を感じさせる改善です。

例：新しいポスト送信パス

これが現在の意図されたユーザージャーニーです：

Bulk検証フロー内でCSVをアップロードします。
ファイル名、行数、ETAを含む直後の成功状態を確認します。
手動でそれを表示する必要なくライブプログレスを確認します。
1つのプライマリボタンをクリックして、そのジョブの正確な履歴詳細ページを開きます。
メールまたは履歴を通じて後で戻り、結果とエクスポートを確認します。

これは以下より単純なパスです：

ファイルをアップロードします。
重複ステータスエリアを解析します。
ジェネリック履歴をクリックします。
正しい行を見つけます。
ターゲットジョブを再度開きます。

単一セッションでの労力削減は小さく、繰り返し使用での労力削減は大きいです。

2. 検証履歴が実際のモニタリングサーフェスのように動作するようになった

2番目の大きな改善は、非同期検証履歴ページに関するものです。

このページは機能していましたが、内容が薄くてでした。ジョブが存在し、進行中であることを示すことはできましたが、アクティブなモニタリング用に設計されたサーフェスという感覚はまだありませんでした。

これは長時間実行される検証ジョブには適切ではありません。

顧客がファイルの処理中に履歴詳細ページを開く場合、彼らは単なるパーセント数を探しているわけではありません。彼らは以下を理解しようとしています：

このジョブが参照するファイル
ワークロードの規模
すでに完了した作業量
初期結果の構成
ジョブがどのくらい長くかかるか

このような現実を中心にページを再設計しました。

安定したメタデータが最初に表示されるようになった

更新された履歴ページは、安定したサマリーカードから始まります。このカードは、最も重要なジョブメタデータをまとめています：

元のファイル名
合計行数
ユニークメール数
推定処理時間
開始時間

この情報は、リアルタイムポーリングループに依存していません。動的ステータスペイロードがまだ落ち着いたり更新されていなくても、安定したコンテキストができるだけ早く表示されるべきだからです。

ユーザーがページに到達したとき、ライブステータスレスポンスの完了を待つ代わりに、すぐに自分の状況を把握できます。

ライブ進捗エリアがはるかに充実した

サマリーの下、実行中の状態エクスペリエンスが大幅に改善されました。

限定的なコンテキストの単なるプログレスバーの代わりに、ページは次のものを表示します：

処理済みの量
残りの量
ステータス全体での結果の分布
メイン一括検証フローと一致する言語とETAの意味

同じくらい重要なことに、内部メトリクスは内部に留めるべき値を削除しました。ユーザーが「私のジョブはどこまで進んでいますか？」と尋ねるとき、顧客が測定しようとしていないワーカータスクとチャンク数を故意に露出させるのをやめました。これらの値は運用上は有用ですが、顧客が測定しようとしているものではありません。

正しい質問はほぼ常にキュー中心ではなく、メール中心です。

完了状態のツールは変わらない

この作業の設計上の制約の1つは、完了したジョブページの分析の深さを失いたくないということでした。

そのため、既存の結果の分析チャートとエクスポートツールを保持しました。更新は完了状態のエクスペリエンスを置き換えることについてではありませんでした。それはページの上部を強化し、実行中の状態エクスペリエンスをワークフローに値するものにすることについてでした。

つまり、ページは両方のジョブをより良くこなします：

処理中、それはモニタリングサーフェスとして機能します
完了後、それは依然として分析およびエクスポートサーフェスとして機能します

例：ユーザーが一目で理解できるようになったこと

実行中のジョブページは現在、これらすべてを迅速に答えます：

「これは私が先ほどアップロードした19,293行のファイルです。」
「その中に19,010個のユニークメールがあります。」
「システムは約33分と推定しています。」
「499個のメールはすでに検証されています。」
「これまでのところ、完了したセットの大部分は有効で、無効および不明なシェアが小さくなっています。」

これは単なるパーセント数の不明確なセマンティクスよりも、はるかに有用なメンタルモデルです。

3. Progress semanticsがより正直になりました

非同期製品における最大の教訓の1つは、「progress」は単一の概念ではないということです。

分散システムでは、独立して動く複数のものがあります：

ワーカータスクが完了する
チャンクがマージされる
メールレベルの結果が蓄積される
最終ファイルがダウンロード可能になる

クライアントが1つの汎用的なprogressフィールドのみを受け取る場合、その数値がどの意味を持っているのか推測する必要があります。これが技術的には一貫していても体験として混乱を招くUIの状態につながります。

契約レベルでこれを修正したいと考えました。

コアシフト

更新されたインターフェースにより、以下を区別することが可能になります：

email_progress
chunk_progress
progress_source

この区別により、クライアントはユーザーの意図に合わせたprogress表示をレンダリングするための、はるかに強固な基盤を得ます。

例えば：

大きなユーザー向けprogress barはemail_progressを優先できます
オペレーショナルまたは診断ビューは依然としてchunk_progressを使用できます
フォールバックが必要な場合、progress_sourceそれを明示的にできます

これはすべてのprogress percentagesが同じことを意味すると見せかけるより、はるかに健全なモデルです。

ペイロード例

以下は、これが実現する形状の種類です：

{
  "task_id": "36f68e67-ddcb-441a-a407-22f826e72443",
  "status": "processing",
  "total_emails": 19010,
  "processed_emails": 499,
  "valid_emails": 496,
  "invalid_emails": 2,
  "unknown_emails": 1,
  "catchall_emails": 0,
  "risky_emails": 0,
  "role_emails": 0,
  "disposable_emails": 0,
  "email_progress": 3,
  "chunk_progress": 7,
  "progress_source": "email_progress"
}

基礎となるキューシステムについて何も知らなくても、クライアントはこのレスポンスから適切な判断を下すことができます。

それが重要です。なぜなら、APIはデータを返すだけではなく、意味を定義するからです。

顧客にとって更に良い理由

顧客は、実際には19,010個のメールのうち499個しか処理されていない場合、ワーカーが96個の内部タスク中7個を完了したかどうかには関心を持ちません。間違ったprogress抽象化を公開すると、安心ではなく混乱が生じます。

プライマリUIをemail_progressに移すことで、製品はユーザーが実際に気にする作業単位を反映するようになります。

フロントエンドチームにとって更に良い理由

UIは、単一の曖昧なpercentフィールドから多くを推測する必要がなくなりました。

これにより、製品バグの全クラスが削減されます：

progress barが早すぎて表示される
要約ブロックがメインのパーセンテージの後ろに遅れる
バックエンド実装の詳細をエンドユーザーに説明しようとする不器用なステータスコピー

また、フロントエンドチームに、安定したジョブメタデータから変化する実行データを分離するのに、より清潔な方法を提供します。これは、リリースの次の部分に直接つながります。

4. バックエンドステータスコントラクトが分散作業に適した構造に改善されました

フロントエンドの変更は、バックエンドコントラクトの改善なしでは十分に機能しません。

ここでは2つの重要な構造的決定を行いました。

第一に、安定したメタデータとライブステータスを分離しました

ジョブ作成後、ほとんど変更されないフィールドがあります:

ファイル名
作成時刻
総行数
ユニークメール数
推定処理時間

一方、本質的に動的なフィールドもあります:

現在のステータス
処理済みメール数
ライブ結果の内訳
進捗率

両方のデータクラスを同じポーリングパスで強制的に処理しようとすると、UIの使いにくさの一般的な原因となります。フロントエンドは、すぐに利用可能であるべきデータを待つことになり、また必要以上の頻度で安定したデータを再リクエストすることになります。

新しいモデルはよりクリーンです:

安定したジョブメタデータはメタデータとして扱われます
ライブジョブステータスはステータスとして扱われます

これは明確に書くと当たり前に聞こえますが、実装品質に有意義な影響を与えます。

履歴詳細ページは、安定した要約情報を素早くレンダリングし、変更が必要なものだけをポーリングし、ジョブ実行中もUIを落ち着いた状態に保つことができるようになりました。

第二に、ステータスペイロード自体を拡張しました

リアルタイムステータスインターフェースは、これまでに何が起こったかについてより豊富な情報を提供するため、分散非同期処理により適したものになりました。

これには次のようなカウンターが含まれます:

処理済み
有効
無効
不明
リスクあり
キャッチオール
ロール
使い捨て
使用クレジット

これらの値により、インターフェースは人間向けの進捗表示だけでなく、自動化や下流のワークフローにとってもより有用になります。現在の結果内訳を理解するクライアントは、アラート、通知、エクスポート、後処理についてより良い判断を下すことができます。

例: これがUIを超えて重要である理由

BillionVerifyの上に構築された顧客向けアプリが次のことを実現したい場合を想像してください:

リストの実行中にライブ品質分布を表示する
ジョブが異常に高い無効率を生成している場合にユーザーに通知する
有用な結果セットが存在するとすぐにフィルター済みエクスポートを提供する
エンジニアリングが生のワーカー状態を検査する必要なく、サポートまたはオペレーションダッシュボードを稼働させる

これらすべてのユースケースは、バックエンドステータスコントラクトが明示的で十分に豊富である場合に容易になります。

これが、最初の目に見える変更が「プログレスバーの見た目が良くなった」であっても、バックエンドインターフェースの作業が重要である理由です。より良いプログレスバーは、多くの場合、より良いコントラクトの兆候なのです。

5. MCPはリモートOAuth時代へ完全に移行しました

このアップデートの最後の大きなピースは開発者向けですが、このリリースにおいて最も重要な長期的な製品改善の一つです。

BillionVerify MCPは、モダンリモートクライアント向けに本来あるべき形で提示・ドキュメント化されるようになりました：

ホストされたリモートエンドポイント
OAuthベースの認可
保護されたリソースディスカバリー
標準的なBearer トークンアクセス

エンドポイントは：

https://mcp.billionverify.com/mcp

これが重要な理由は、古いセットアップパターンは、プラットフォームが内部的にすでに移行した後も、公開資料に長く残るものだからです。私たちの場合、一部のドキュメントとマーケティングコンテンツは、MCPがURLに埋め込まれたAPIキーとcurl --stdioラッパーで接続できることを暗に示していました。

それはBillionVerify MCPに対する正しい形ではなくなりました。

古い心的モデル

古いパターンはおおよそこのようなものでした：

curl --stdio "https://mcp.billionverify.com/mcp?api_key=YOUR_API_KEY"

そのモデルは複数の関心事を1つの厄介なセットアップステップに圧縮していました：

トランスポート
認証
シークレット管理
ローカルラッパー動作

また、ホストされたリモートMCPサーバーがモダンクライアントにどのように使用されるべきかについて、間違ったシグナルを発していました。

新しい心的モデル

現在のモデルはより洗練されています。

Claude Codeの場合、推奨セットアップは：

claude mcp add --transport http billionverify https://mcp.billionverify.com/mcp

Claude Code内では：

/mcp

ここから、クライアントはブラウザでOAuthフローを完了します。

ChatGPTおよび他の互換性のあるリモートMCPクライアントの場合、適切な開始地点はエンドポイント自体です：

https://mcp.billionverify.com/mcp

クライアントは保護されたリソースメタデータを検出し、認可フローに従い、認証されたコールに対してBearer アクセストークンを使用します。

最も重要な違い：MCP認証はREST認証ではない

古いドキュメントがクリーンアップが必要だった理由の一つは、APIキーはBillionVerifyでまだ重要だからです。しかし、MCPのブートストラップストーリーには属さなくなりました。

明確な分離は：

REST APIはAPIキーを使用する
リモートMCPはOAuthを使用する

この区別は現在、製品サーフェス全体でより明確になっています。

開発者が使用している場合：

ChatGPT
Claude Code
その他のOAuth対応リモートMCPクライアント

リモートMCPパスを使用すべきです。

彼らが構築している場合：

バックエンドからバックエンドへの自動化
APIキー駆動スクリプト
ローカルstdioとAPIキーのみをサポートするクライアント

APIリファレンスとRESTフローの代わりに使用すべきです。

これは見た目の違いではありません。製品の境界であり、ドキュメントはそれを明らかにすべきです。

6. 公開ドキュメントとマーケティングが製品と一致

アーキテクチャのアップグレードは、公開資料がまだ別のストーリーを語っている場合、問題の一部しか解決しません。

そのため、MCPドキュメントとマーケティングのクリーンアップを同じリリースの一部として扱いました。

更新内容：

公開MCPページ
MCPガイド
Claude Codeガイド
AIガイドのエントリーポイント
多言語ドキュメント
ローカライズされたマーケティングFAQ

目標はシンプルでした。「BillionVerify MCPに接続するには？」という質問に対して、明確な答えが1つあるべきということです。

現在、その答えが存在します。

開発者にとって重要な理由

公開ドキュメントが実装の現実に遅れている場合、開発者は3つの方法でその代償を払います：

セットアップ試行の失敗
プラットフォームへの信頼喪失
明白であるべきことを明確にするためのサポート負担の増加

公開インターフェースを実際のリモートOAuthモデルと一致させることで、サポート問題になる前に不要な摩擦を減らします。

プラットフォーム位置付けにとって重要な理由

MCPエコシステムは急速に発展しています。ChatGPT、Claude Code、その他のAIクライアントを通じてツールを評価するチームが増えるにつれて、最初の統合体験の質がより重要になります。

プロトコルレイヤーでは最新に見えるが、公開セットアップガイダンスでは時代遅れに見える製品は、信頼を構築すべき場所でためらいを生じさせます。

そのため、サインインと同意サーフェスを、より明確な利用規約、プライバシー、サポート連絡先の可視性で強化しました。レビュアー、開発者、エンタープライズ評価者はすべて、信頼シグナルが明示的である場合に利益を得ます。

7. このリリースの実践的なビフォー・アフター

このリリースを理解するための有用な方法は、ビフォー・アフターのユーザーエクスペリエンスと開発者エクスペリエンスを比較することです。

ビフォー

バルク検証ファイルは正常に送信できましたが、送信後の状態にはまだ重複するUIと不明確な次のステップがありました。
履歴詳細ページはアクティビティを表示しましたが、まだ完全な監視サーフェスとは感じられませんでした。
パーセンテージ完了値が存在する可能性がありますが、処理済みメールと内部タスク完了のどちらを表しているかをユーザーに明確に伝えていませんでした。
MCP公開資料は、従来の?api_key=セットアップストーリーをまだ部分的に反映していました。

アフター

送信後のエクスペリエンスはより清潔、より簡潔、より直接的です。
ライブプログレスはバルクフローでデフォルトで表示されます。
送信後のメインCTAはユーザーを正確なジョブ詳細ページに直接案内します。
履歴詳細ページは安定したサマリーメタデータと、より充実したライブ結果の可視性を表示します。
ユーザー向けプログレスはメールレベルのプログレスセマンティクスに焦点を当てています。
内部タスク数はもはや顧客向けメトリクスとして公開されていません。
バックエンド状態インターフェースは、リアルタイムクライアントと分散ジョブ向けにより適切に構成されています。
MCP公開資料はリモートOAuthアーキテクチャを一貫して反映しています。

これは単一の機能ではありません。これはワークフロー全体にわたる意味のある品質向上です。

8. さまざまなオーディエンスにとっての意味

運用・成長チームの場合

UI摩擦が少なくなり、ジョブ実行中の可視性が向上し、起動したジョブへのアクセスが明確になった、より滑らかなバルク検証ワークフローが実現します。

プロダクト・フロントエンドチームの場合

より強力な進捗セマンティクスとメタデータと実時間ステータス間のより清潔な分離が実現し、進捗が多いスクリーンをより簡単に構築でき、より簡単に説明できるようになります。

バックエンド・プラットフォームチームの場合

分散検証のための強力なステータスコントラクトと、異なる進捗値が実際に何を意味するかに関する、より清潔なストーリーが実現します。

MCPを統合する開発者の場合

セットアップの質問に対してはるかに明確な答えが得られます。MCPクライアントにはリモートMCP + OAuthを使用し、そのモデルが適切な場所ではREST APIにはAPIキーを使用します。

9. 始める場所

更新されたエクスペリエンスまたは統合パスを探索したい場合は、ここから始めてください:

製品についてもっと学ぶ: メール検証
より大規模なワークフローを実行: 一括メール検証
基礎を理解: メール検証とは?
サポートされているクライアントからMCPを接続: MCPの概要
セットアップについてさらに詳しく: MCPガイド
Claude Codeを具体的にセットアップ: Claude Codeガイド
APIキーベースの統合を代わりに使用: APIリファレンス

Closing

このリリースは、1つの大きな派手な表面的な変更ではありませんでした。曖昧さが忍び込んでいた箇所を製品として引き締めることでした。

バルク検証ジャーニーをより整理しました。非同期モニタリングをより有用にしました。進捗報告をより正確にしました。そしてMCPストーリーを、私たちが実際に構築しているプラットフォームに合わせました。

これらの改善は相互に強化し合います。

UIが少なく言っても多くを意味するとき、製品はより信頼しやすくなります。ドキュメントが実際のアーキテクチャを説明するとき、統合がより容易になります。そして、エクスペリエンスの下にあるインターフェースが、より明確なセマンティクスを持つとき、進化がより容易になります。

これが私たちがBillionVerifyを継続して推し進めている方向です。

既にBillionVerifyを使用している場合、これらの変更は日常的なワークフローがより直接的で、より予測可能に感じられるようにするはずです。

現在プラットフォームを評価している場合、このアップデートは、製品品質についての私たちの考え方の良いスナップショットです：ユーザー向けの明確さの上に、明示的な契約が下に、現実に合致するドキュメントです。

Instantly や Smartlead を使うチームは、キャンペーン前に BillionVerify でリストをクリーニングすることで到達率を大幅に改善できます。

認証プロバイダーを選ぶ前に、精度と速度の面で BillionVerify と ZeroBounce を比較してみてください。