Jewelry AI・同意の記録

同意はボタンのタップそのもので、最初の記録は書かれたまま残ります

登録画面にも同意画面にもチェックボックスはありません。文言はボタンの横にあり、タップそのものが行為です。そのタップが生むのは、同時に書き込まれる一対の記録です。記録は実際に表示された文書と照合され、同じ同意がもう一度届いても手を加えられません。

入れるべきチェックはありません

登録画面でも同意画面でも、同意と年齢の文言はボタンの横にあります。これらの画面からチェックや切り替えを探しても、見つかりません。タップが同意です（apps/jewelry-mobile/src/features/legal/legal-contract.ts）。

つまり、先に文書を開くことも求められていません。文言からそのままボタンへ進むことができ、画面はそれを完了した行為として扱います。

このページが説明するのは、根拠の及ぶ二つの画面です。アプリのほかの画面にチェックボックスや切り替えがあるかどうかについては、何も主張しません。

その瞬間に送られるもの

タップとともに三つの値が送られ、そのうちの一つは、何かが書き込まれる前に別の値と照合されます。

表示された文書のフィンガープリント。: 同意とともに送られ、その送信がその文書への同意として成立するかどうかを、サーバーが調べる対象です。
その文書が表示された言語。: あとから推定されるのではなく、送信の一部として申告されます。
固定の値として送られる、年齢要件の申告。: タップによって行われる申告です。年齢確認ではありませんし、サーバー側でもそのようには扱われません。
フィンガープリントと言語は一致していなければなりません。: サーバーは、送信されたフィンガープリントを、申告された言語に対して期待される値と比べます。そのため、クライアントが表示していない文書を同意済みとして報告することはできません（apps/api/src/auth/auth.controller.ts）。同じ照合は、生成のエンドポイントで記録される告知にも適用されます（apps/api/src/generation/generation.controller.ts:51）。

一対の記録と、その数え方

同意は一行ではありません。二行が同時に書き込まれ、同時に数えられます。

記録	何を持つか	どう数えられるか
利用規約への同意	同意が行われた瞬間と、文書が表示された言語	現在のバージョンに対してのみ数えられます
年齢要件	同意とともに固定の値として送られた申告	現在のバージョンに対してのみ数えられます
二つそろって	単一のトランザクションで書き込まれるため、通常の経路では中途半端に書かれた状態は想定されていません	現在のバージョンで両方あれば同意済み、どちらかが欠ければ同意していない扱いです

二度目の同意は、最初の同意を置き換えません

同じバージョンについての同意がもう一度サーバーに届いた場合、すでにある行はそのまま残されます。最初に記録された時刻と、その瞬間に読まれた言語は、そこに残り続けます（apps/api/src/legal/legal-evidence.service.ts）。

生成リクエストから書き込まれる告知の受領記録も同じです。繰り返しても、既存の受領記録には手が加えられません。

ここから一つの帰結が直接に導かれます。あとから表示言語を変えても、以前の記録が持っている内容は書き換わりません。記録が述べているのは、そのときに表示されていたことであって、いまアプリがどう設定されているかではありません。

これは、サーバー側で書き込みがどう定義されているかという性質です。設定でもなければ、どこかの画面にある操作でもなく、アプリの流れが操作するよう求めてくるものでもありません。

生成リクエストが加えるもの、その頻度

生成リクエストはそれぞれ、第三者のAIプロバイダーへの提供に関する告知を必須の項目として伴います。四つの作成リクエストすべてで必須です（apps/api/src/generation/generation.controller.ts:83）。

サーバーはそれを画像ごとの記録には変えません。バージョンと画面ごとに受領記録を一件だけ保持するため、同じ作業を繰り返しても項目が積み上がることはありません（apps/api/src/legal/legal-evidence.service.ts）。

受領記録は、生成が成功するより前、リクエストが受け付けられた時点で書き込まれます。利用者の側でそれに対応するのは、作成ウィザードの確認ステップにある短い注記です（create-wizard.tsx:699）。目にするのは、新しい同意の確認ではなく、その注記です。

このページが外に置く事柄

ここでの根拠は、同意が書き込まれる経路です。隣り合ういくつかの問いには、まったく別の仕組みが答えます。

文書が何を述べ、何を対象とし、何を認め、何を放棄させるのか。このページが説明するのは書き留められる内容だけであって、その意味ではありません。
同意が済んでいないあいだ、どのリクエストが拒否されるのか、そして同意するまで足止めする画面。その仕組みは別のページが持ちます。
文書がどこで開き、どの言語で表示されるのか。これは同意が送信される前に決まることで、別の場所で扱われます。
生成が実行されるときに端末から実際に何が出ていくのか。告知の記録が示すのは、告知が行われたことであって、何が送信されたかではありません。
同意の記録が内部のツールでどう表示されるのか、そしてアカウントが削除されたり書き出されたりしたときにどう振る舞うのか。
どの時点でどのバージョンのテキストが配備されているのか。コードが示すのは書き込みの経路であって、稼働中の状態ではありません。

上に書いたことの出典

チェックボックスがないことと、固定の年齢申告: apps/jewelry-mobile/src/features/legal/legal-contract.ts。同意とともに送られる年齢の確認が定数として置かれています。

一対の記録による数え方: apps/api/src/legal/legal-evidence.service.ts。両方の記録が現在のバージョンで存在するときにだけ、同意を現行のものとして扱います。

既存の記録に手を加えない書き込み: 同じサービス。更新の経路が空として定義されています。

フィンガープリントと申告された言語の照合: apps/api/src/auth/auth.controller.ts。生成の側でも同様に、apps/api/src/generation/generation.controller.ts:51。

作成リクエストで必須となる告知の項目: apps/api/src/generation/generation.controller.ts:83。利用者に表示される確認ステップの注記: create-wizard.tsx:699。

よくある質問

文書を一度も開かなかった場合でも、何か記録されましたか？

はい。ボタンのタップが行為であり、登録画面にも同意画面にも、先に入れておくべき別のチェックはありません。文書を開くことは、送信される内容には含まれていません。

もう一度同意すると、記録は今日の日付に更新されますか？

いいえ。同じバージョンについては、二度目の送信は既存の行をそのままにします。最初に記録された瞬間と、そのときに読まれた言語が残ります。これはサーバー側で書き込みがそう定義されているためであり、アプリのどこかで選べることではありません。

アプリの言語を切り替えました。記録に残っているのはどちらの言語ですか？

記録が書き込まれたときに、その文書が表示されていた言語です。あとから表示を変えても、既存の記録は書き換わりません。

生成した画像ごとに、新しい同意が記録されますか？

いいえ。告知の項目は四つの作成リクエストのそれぞれで必須ですが、サーバーはバージョンと画面ごとに受領記録を一件だけ保持します。そのため画像ごとに記録が積み上がることはなく、確認が繰り返されることもありません。目にするのは、作成ウィザードの確認ステップにある短い注記です。