ブログ・ 2026年8月4日

AI APIアクセスにおける生体認証ステップアップ：特権を個人に紐付ける (JA)

オンボーディングは登録者が誰であるかを証明しますが、6ヶ月後にAPIキーを誰が持っているかについては何も証明しません。割り当ての増加、クレジットの付与、キーの発行に対するパスワード不要の生体認証による再認証は、$0.10で2秒未満で完了します。.

By Didit2026年8月4日更新日 2026年8月4日

オンボーディング時の認証は、アカウントを作成した人が誰であるかを証明します。しかし、今それを誰が使用しているかについては何も証明しません。

このギャップはほとんどの製品で一般的であり、AIプラットフォームでは、アカウントの背後にある資産がモデルアクセス、クレジット、および割り当てであるため、重大な結果を招きます。APIキーはベアラートークンであり、それを持っている人がアカウントです。キーはチーム内で共有されたり、リポジトリに貼り付けられたり、転売されたり、乗っ取られたりします。クリーンなオンボーディングから6ヶ月後、「このアカウントは認証済みです」という言葉は過去の事実を述べているに過ぎません。

生体認証はこのギャップを埋めます。特権的なアクションの瞬間に実際の人物を再認証します。書類不要、パスワード不要、2秒未満、認証あたり$0.10です。

主なポイント

オンボーディング認証はスナップショットです。生体認証は重要な瞬間にチェックします。
ユーザーの最初の認証時にすでに保存されている顔画像に対する生体検知と顔照合。書類不要、パスワード不要。
セッション限定。/v3/biometric-auth/エンドポイントはありません。workflow_type=BIOMETRIC_AUTHENTICATIONを使用するセッションを通じて実行されます。
重要な実装の詳細：ユーザーの最初の認証時と同じvendor_dataを使用してください。そうしないと、保存された顔が取得できません。
適切なトリガー：割り当ての増加、クレジットの付与、新しいAPIキーの発行、ティアのアップグレード、特権を持つチームメンバーの追加、およびトラフィック層からの行動アラート。
認証あたり$0.10、成功課金、2秒未満。

なぜ再認証がAIプラットフォームに必要か

3つの失敗モードにより、オンボーディングのスナップショットでは不十分です。

キーの共有と転売。認証済みの開発者に発行されたキーはどこにでも行き着く可能性があります。アカウントは認証されたままですが、それを使用している人は認証した本人ではありません。これは、正当に認証されたアカウントがファーム化されたネットワークへの入り口となるメカニズムであり、オンボーディングのみを監視する制御からは見えません。

アカウント乗っ取り。資格情報がフィッシングまたはスタッフィングされ、攻撃者は確立された評判と引き上げられた制限を持つ認証済みアカウントを継承します。認証済みアカウントは、乗っ取りのターゲットとしてより魅力的であり、魅力的でないわけではありません。

事後のエスカレーション。1月に控えめなアクセスで認証されたアカウントが、8月に50倍の割り当て増加を要求します。1月の認証は8月の要求とは関係ありません。

これら3つのすべてにおいて、アカウントの認証ステータスは変更されておらず、その背後にいる人物はあなたが思っている人物ではありません。パスワード、ワンタイムコード、またはセッショントークンではこれらのケースを区別できません。なぜなら、それらのすべてが正当に資格情報を保持している攻撃者だからです。生体認証チェックだけが、重要な質問をします。今ここにいる人物は、認証した本人ですか？

仕組み

生体認証は、通常の本人確認フローと同じLivenessV3およびFaceMatchV3コンポーネントを再利用します。唯一の違いは、参照画像の取得元です。新しく提出された書類の顔画像ではなく、ユーザーの以前の認証時にすでに保存されている顔画像を使用します。

そのため、書類が不要であり、通常の製品フローに組み込むのに十分な速さと安さです。

セッション限定です

専用の/v3/biometric-auth/エンドポイントはありません。認証は、そのように構成されたワークフロー（workflow_type=BIOMETRIC_AUTHENTICATION）を持つセッションを通じて提供されます。APIリファレンスでスタンドアロンのエンドポイントを探しても見つからないのはこのためです。

フロー

コンソールでBIOMETRIC_AUTHENTICATIONタイプのワークフローを構成し、そのworkflow_idをメモします。
セッションを作成します。

curl -X POST 'https://verification.didit.me/v3/session/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "workflow_id": "YOUR_BIOMETRIC_AUTH_WORKFLOW_ID",
    "vendor_data": "acct_8842",
    "callback": "https://yourplatform.example/auth/complete"
  }'

返されたセッションをユーザーに送信します。ホスト型、または無料のSDKのいずれかを使用して埋め込みます。
決定を取得します。

curl -X GET 'https://verification.didit.me/v3/session/{sessionId}/decision/' \
  -H 'x-api-key: YOUR_API_KEY'

または、session.status.updatedを購読してWebhookを受け取ります。

統合を壊す唯一の詳細

ユーザーの元の認証時と同じvendor_dataを使用してください。

この値は、Diditが保存された顔画像を照合のために取得する方法です。新しいまたは異なるvendor_dataでは、比較する保存された顔がないため、フローは要求されたことを実行できません。保存された参照を意図的に上書きする必要がある場合は、portrait_imageを明示的に渡しますが、通常のパスは、オンボーディング時に設定され、永続的に再利用されるアカウントごとの安定したvendor_dataです。

これは、初日からvendor_dataを独自のスキーマの第一級識別子として扱うべきであるという主張です。また、顔検索の結果がアカウントにきれいにマッピングされる理由でもあります。

結果の読み取り

結果はliveness_checksとface_matchesで返されます。どちらも常に配列であり（単一のオブジェクトではありません）、各項目にはnode_idが付いているため、マルチインスタンスワークフローはステップを区別できます。各項目は、そのステップがデータを生成するまでnullです。

警告には、LOW_LIVENESS_SCORE、顔攻撃アラート、ブラックリスト一致、低顔照合類似度が含まれます。しきい値と拒否アクションは設定可能であるため、通常の割り当て増加よりも、多額のクレジット付与に対してより厳格な基準を適用できます。

ステップアップをトリガーすべきもの

この制御の価値は、トリガー設計にほぼ完全に依存します。多すぎると迷惑になり、少なすぎると重要なときに発動しません。

アクセスエスカレーション — 割り当ての増加、クレジットの付与、新しいAPIキーの発行、ティアのアップグレード、機密とみなす機能ティアへの移行。

アカウント変更 — 新しい特権チームメンバー、請求所有者の変更、支払い先の変更、パスワードまたはMFAのリセット。

行動アラート — 最も価値の高いトリガー。トラフィック層が集中したクエリや蒸留されたパターンでアカウントにフラグを立てた場合、生体認証ステップアップは、トラフィック層ではできない質問をします。認証された人間が今もこのアカウントを操作しているか？合格は解釈を絞り込みます。失敗または放棄自体が強力なシグナルです。

リンクシグナル — DEVICE_RECOVERED_HIGH_CONFIDENCEを持つセッション、または既存の認証済みユーザーと一致した顔は、アカウントが何を要求しているかに関わらず、ステップアップを稼いでいます。

休眠とエスカレーション — 数ヶ月間静かだったアカウントが突然大幅な増加を要求する。休眠だけではなく、その組み合わせです。

なぜパスワードやコードを要求しないのか？

従来のすべての要素はベアラー資格情報であり、ここでの脅威モデルは資格情報を保持している攻撃者だからです。

ワンタイムコードは、ファイルに登録されている電話番号またはアドレスに送信されます。これは、乗っ取り後に攻撃者が制御したり、正当なキー共有者が単に転送したりします。パスワードは文字列の知識を証明します。ハードウェアキーはオブジェクトの所有を証明しますが、キーと一緒に引き渡すことができます。

生体検知された顔照合は、特定の人間が今ここに存在することを証明します。特権を個人に紐付けるには、それが実際の質問に答える唯一の要素です。$0.10で2秒未満という安さで、緊急事態のために温存するのではなく、実際のトリガーに使用するのに十分なコストです。

それがしないことも述べる価値があります。アカウントの背後にいる人間を再認証しても、モデルの抽出を防ぐことはできず、それを検出することもできません。認証された開発者は、依然として持っているアクセスを悪用する可能性があります。これは、「このアカウントは一度認証された」と「この人間は今ここにいる」という間の、狭く現実的なギャップを埋めます。モデルレベルの出力制御と意味的トラフィック検出は別々の層であり、あなたのものとして残ります。

ユースケース

AI APIプラットフォームは、割り当てのエスカレーション、クレジットの付与、およびキーの発行を、人間に対するチェックの背後に置きます。

エージェントおよび自動化製品は、エージェントに新しい機能が付与されたり、支出限度額が引き上げられたりする前に、ステップアップを要求します。

金融サービスは、高額送金や支払い先の変更前に再認証を行います。

マーケットプレイスは、支払い方法の変更前に販売者を再認証します。これは、最も一般的なアカウント乗っ取りの報酬です。

回復フローを持つあらゆるプラットフォームは、ほとんどのアカウントセキュリティ設計における最も弱いリンクである知識ベースの質問の代わりに、生体認証による再認証を使用します。

よくある質問

ユーザーは再度書類を提出する必要がありますか？

いいえ、それがポイントです。チェックは、元の認証時にすでに保存されている顔画像に対して実行されます。生体検知と顔照合で、書類は不要です。

ユーザーがDiditで一度も認証されたことがない場合はどうなりますか？

その場合、保存された顔画像がないため、認証するものはありません。生体認証は再認証のプリミティブであり、同じvendor_dataでの以前の認証を前提としています。

どれくらいの時間がかかりますか？

2秒未満の推論です。ユーザーの視点からは、セルフィーと一瞬です。

自社のインターフェース内で実行できますか？

はい。ウェブ、iOS、Android、React Native、FlutterのSDKはすべて無料で、ホワイトラベル（$0.20）でDiditのブランドを削除できます。

アカウント所有者の写真やビデオを誰かが提示した場合はどうなりますか？

それが生体検知の目的です。Diditのパッシブ生体検知は、iBetaレベル1のプレゼンテーション攻撃検出評価を受けており、顔攻撃アラートは警告として表示されます。しきい値は設定可能です。

費用はいくらですか？

認証あたり$0.10、成功課金、最低料金なし。

すべてのログインにこれを要求すべきですか？

いいえ。ログインは間違ったトリガーです。常に発動し、ほとんどの場合何もありません。特権のエスカレーションとアラートに紐付けてください。そこでは間違いのコストが高く、頻度は低いです。

始めますか？

1つのワークフローを構成し、それをエスカレーションポイントに接続し、どこでも再利用してください。

ドキュメントを読む — 生体認証の概要とセッションAPI。
製品を見る — ユーザー認証。
価格を確認する — 認証あたり$0.10、成功課金、最低料金なし。
無料で始める — business.didit.me、毎月500回のKYC認証が無料。