解決したい課題
現在、顧客情報の作成（POST /me/customer）および更新（PATCH /me/customer）用のAPI仕様において、リクエストパラメータに email や traq_id フィールドが含まれています。
クライアント側からこれらのパラメータを任意に送信可能であるため、以下のようなセキュリティ設計上のリスクが存在します。
traq_id の任意書き換え:
自身のアカウントに対して他人の traQ ID を不正に指定し、顧客情報の紐付けを改ざんできてしまうリスク。email の検証バイパス:
メール所有権の確認プロセス（/verify-email）を経ないまま、任意のメールアドレスに顧客の登録情報を変更できてしまうリスク。
達成したい要件（ゴール）
APIスキーマ（インターフェース契約）の安全設計（Secure by Design）を実現するため、以下の要件を満たす仕様変更を行います。
- 入力パラメータの制限:
顧客の作成・更新時のリクエストスキーマから email および traq_id フィールドを排除し、入力可能なパラメータを name（氏名） のみに制限します。
- セッション情報のセキュアな暗黙利用:
顧客情報の登録・更新に必要な email や traq_id はクライアントから受け取るのではなく、バックエンド側で認証セッション情報（NeoShowcaseAuth または EmailVerifiedSession）から安全に取得して処理を行うAPI仕様とします。
解決したい課題
現在、顧客情報の作成（
POST /me/customer）および更新（PATCH /me/customer）用のAPI仕様において、リクエストパラメータにemailやtraq_idフィールドが含まれています。クライアント側からこれらのパラメータを任意に送信可能であるため、以下のようなセキュリティ設計上のリスクが存在します。
traq_idの任意書き換え:自身のアカウントに対して他人の traQ ID を不正に指定し、顧客情報の紐付けを改ざんできてしまうリスク。
emailの検証バイパス:メール所有権の確認プロセス（
/verify-email）を経ないまま、任意のメールアドレスに顧客の登録情報を変更できてしまうリスク。達成したい要件（ゴール）
APIスキーマ（インターフェース契約）の安全設計（Secure by Design）を実現するため、以下の要件を満たす仕様変更を行います。
顧客の作成・更新時のリクエストスキーマから
emailおよびtraq_idフィールドを排除し、入力可能なパラメータをname（氏名） のみに制限します。顧客情報の登録・更新に必要な
emailやtraq_idはクライアントから受け取るのではなく、バックエンド側で認証セッション情報（NeoShowcaseAuthまたはEmailVerifiedSession）から安全に取得して処理を行うAPI仕様とします。