カスタムワークフロー

年齢ゲートと検証可能な親の同意（VPC）のk-IDカスタムワークフローには、プレイヤーがゲームにアクセスできるかどうか、およびどのような権限を持っているかを決定する複数のステップが含まれます。

ワークフローの概要

以下のフローチャートは、k-ID Engineワークフローのビューを示しています。API呼び出しは、ワークフローで使用されるポイントで識別されます。

注意: ユーザーの**kuid**がある場合、それを使用してゲームのセッションがあるかどうかを検索できます。

ワークフローステップ

1. 年齢ゲート要件の取得

プレイヤーの管轄区域で/age-gate/get-requirementsを呼び出して、以下を決定します：

• 年齢ゲートを表示する必要があるかどうか
• 許可されている年齢収集方法
• 年齢閾値（デジタル同意年齢、法的年齢、最小年齢）
• 年齢保証が必要かどうか

2. 年齢の収集（必要な場合）

年齢ゲートが必要な場合（shouldDisplay = true）、管轄区域で承認された方法でプレイヤーの年齢を収集します。

3. アクセスのための年齢チェック

プレイヤーの生年月日と管轄区域で/age-gate/checkを呼び出して、次のステップを決定します：

• PROHIBITED: プレイヤーが最小年齢未満 - アクセスをブロック
• CHALLENGE: プレイヤーが親の同意を必要とする - チャレンジを作成
• PASS: プレイヤーは続行できる - セッションを作成または返す

4. 同意チャレンジの処理（必要な場合）

チャレンジが作成された場合：

• プレイヤーにチャレンジを表示する（QRコード、OTP、メール入力）
• 信頼できる大人に通知する（提供された場合はメールで）
• 同意を待つ（webhooksまたはポーリング経由）
• 結果を処理する（同意が付与された場合はアクセスを許可）

5. セッションの取得

同意が付与されたか、同意が不要な場合、/session/getを呼び出してセッションを取得し、プレイヤーの権限と年齢ステータスを取得します。

6. 権限の使用

セッション権限を使用して、各権限のenabledとmanagedByフィールドに基づいて、ゲーム内の機能へのアクセスを制御します。

アカウントシステム統合

一部のスタジオには、複数のゲームにまたがる共通のアカウントシステムがあります。このような状況では、年齢ゲートを統合し、アカウント作成フローで直接検証可能な親の同意（VPC）を処理することが望ましい場合が多く、同じパブリッシャーからのすべてのゲームに対してプレイヤーが年齢を一度だけ尋ねられるようにします。

このタイプの統合を行う場合、いくつかの重要な考慮事項があります：

VPCの製品コンテキスト

ゲームがすべてプレイにアカウントを必要とする場合、VPCはアカウント作成プロセスからトリガーできます。ただし、同意のリクエストはゲーム固有である必要があるため、親は何に同意しているかを知ることができます。k-ID APIは、VPCをトリガーする際に使用されるAPIキーに基づいて、同意プロセス中に親に提示される製品を決定します。

実際には、アカウントシステムへのk-IDの統合は、アカウント設定時にアカウント作成プロセスをトリガーしたゲームを決定し、それをk-ID APIキーにマッピングできる必要があります。

kuidを使用してk-IDセッションにアクセス

k-IDは、何らかの形式の信頼できる大人の同意を得たすべてのプレイヤーに対して、kuidまたはk-IDユーザーIDと呼ばれるグローバル識別子を公開します。kuidはSessionオブジェクトのプロパティとして返されます。複数のゲームにまたがるアカウントシステムと統合する場合、kuidはSessionに存在する場合、アカウントシステムのプレイヤーのアイデンティティに関連付ける必要があります。これにより、正しい製品の適切なAPIキーを使用してkuidのみをパラメータとして提供することで、任意のk-ID製品のk-IDセッション（存在する場合）を取得できます。

複数製品のセッションのキャッシュ

アカウントシステムと統合する場合、複数の製品からのセッションがキャッシュされます。Sessionオブジェクトは、k-ID製品IDをキーとして使用して、アカウントシステムのマップとしてすべてキャッシュできます。プレイヤーが新しいゲームをプレイしようとすると、製品IDでSessionオブジェクトを含むマップをクエリでき、Sessionが既に存在する場合、プレイヤーは追加の信頼できる大人の同意なしで続行できます。

アカウントレベルの製品

k-IDのアカウントシステム統合を設定する場合、通常、各ゲーム用に1つのk-ID製品を作成し、Compliance Studioでアカウントシステム自体用に別のk-ID製品を作成します。これは、すべてのゲームまたはアカウント自体に共通またはグローバルな権限と開示を表すのに役立ちます。

製品がアカウントシステムにマッピングされている場合、これは各ゲームに対して2つのSessionオブジェクトが取得されることを意味します：1つはゲームにマッピングされたk-ID製品用、もう1つはアカウントシステムにマッピングされたk-ID製品用です。k-ID APIは、APIキーによって製品にスコープされます。アカウントシステムにマッピングされたk-ID製品にアクセスしようとしているのか、ゲームにアクセスしようとしているのかに応じて、正しいAPIキーを使用する必要があります。