2026年10月27日の日記 📖
七海
今日のメモ
# 今日やったこと
■ 卒業制作
issue 9. 利用規約・プライバシーポリシーのページを作成する#13
issue 10. Deviseを導入し、ユーザー登録を実装する#14
- 利用規約・プライバシーポリシーのページを作成
- 未ログイン状態でも閲覧できるルートと、共通フッターからのリンクを実装
- 実際の利用サービスや保存方針に合わせて本文を調整
- アプリ用の問い合わせメールアドレスを用意
- API利用履歴の保存方針と制定日を確定
- Deviseを導入し、メールアドレス・パスワードによるユーザー登録を実装
- 規約への同意チェックを追加
- 日本語のエラー表示・成功通知を整備
# 今日理解できたこと
利用規約やプライバシーポリシーは、雛形を置くだけではなく実際のサービス構成やデータの扱いと一致させる必要がある。
また、`store: false`でもOpenAI側に一切データが残らないわけではなく、API上の応答保存と不正利用監視などのログは別の仕組み
#### Deviseによるユーザー登録
認証処理を一から実装せず、Deviseの仕組みを利用して登録機能を作った。
`devise_for :users`が認証用のルートを用意し、Userモデル側のDeviseモジュールが登録や入力検証を担当する。
パスワードはそのままDBへ保存せずに、ハッシュ化された値が`encrypted_password`に保存される。
登録時点では後続の初期設定まで完了していないため、`nickname`や`honorific`は空でも保存できる設計にした。
#### 同意チェックは画面だけでは不十分
利用規約への同意チェックは、HTMLの`required`だけでは直接リクエストを送ることで回避できるため、同意値を`attr_accessor`で一時的に受け取り、サーバー側でもバリデーションを行った。
DBへ同意値そのものは保存せず、新規登録時だけ確認する形にした。
request specでは、
- 未チェック
- 同意項目自体が送られない
の両方でユーザーが作成されないことを確認した。
#### エラー表示と共通スタイル
入力エラーは`resource.errors`、登録成功などの通知は`flash`で表示するため、役割が異なる。
TOP専用CSSに置いていた改行用のスタイルを共通CSSへ移し、登録画面でも再利用できるようにした。
画面固有のスタイルと、複数画面で使う共通スタイルを分けることの重要性を改めて感じた。
# まだ理解できていないこと
- 本番実装時の規約・プライバシーポリシーと実際のデータ処理の最終照合
# 次にやること
issue 11. ログイン・ログアウトを実装する #15
規約・プライバシーポリシーについては、AI機能やデータ保存の本実装後に、記載内容と実際の動作が一致しているか再確認する。
# 感想など
今日は特に、画面を作るだけでなく、
- 説明した内容と実際の実装を一致させること
- ブラウザ側のチェックだけでなくサーバー側でも守ること
が勉強になった
また、保存期間を決めると削除処理まで必要になるなど、規約上の決定がそのまま実装内容にも影響すると分かった。
Deviseのような既存の認証機能を使いながら、規約への同意や画面デザインなど、このアプリ固有の部分を追加していく流れも少しずつ分かってきた。
■ 卒業制作
issue 9. 利用規約・プライバシーポリシーのページを作成する#13
issue 10. Deviseを導入し、ユーザー登録を実装する#14
- 利用規約・プライバシーポリシーのページを作成
- 未ログイン状態でも閲覧できるルートと、共通フッターからのリンクを実装
- 実際の利用サービスや保存方針に合わせて本文を調整
- アプリ用の問い合わせメールアドレスを用意
- API利用履歴の保存方針と制定日を確定
- Deviseを導入し、メールアドレス・パスワードによるユーザー登録を実装
- 規約への同意チェックを追加
- 日本語のエラー表示・成功通知を整備
# 今日理解できたこと
利用規約やプライバシーポリシーは、雛形を置くだけではなく実際のサービス構成やデータの扱いと一致させる必要がある。
また、`store: false`でもOpenAI側に一切データが残らないわけではなく、API上の応答保存と不正利用監視などのログは別の仕組み
#### Deviseによるユーザー登録
認証処理を一から実装せず、Deviseの仕組みを利用して登録機能を作った。
`devise_for :users`が認証用のルートを用意し、Userモデル側のDeviseモジュールが登録や入力検証を担当する。
パスワードはそのままDBへ保存せずに、ハッシュ化された値が`encrypted_password`に保存される。
登録時点では後続の初期設定まで完了していないため、`nickname`や`honorific`は空でも保存できる設計にした。
#### 同意チェックは画面だけでは不十分
利用規約への同意チェックは、HTMLの`required`だけでは直接リクエストを送ることで回避できるため、同意値を`attr_accessor`で一時的に受け取り、サーバー側でもバリデーションを行った。
DBへ同意値そのものは保存せず、新規登録時だけ確認する形にした。
request specでは、
- 未チェック
- 同意項目自体が送られない
の両方でユーザーが作成されないことを確認した。
#### エラー表示と共通スタイル
入力エラーは`resource.errors`、登録成功などの通知は`flash`で表示するため、役割が異なる。
TOP専用CSSに置いていた改行用のスタイルを共通CSSへ移し、登録画面でも再利用できるようにした。
画面固有のスタイルと、複数画面で使う共通スタイルを分けることの重要性を改めて感じた。
# まだ理解できていないこと
- 本番実装時の規約・プライバシーポリシーと実際のデータ処理の最終照合
# 次にやること
issue 11. ログイン・ログアウトを実装する #15
規約・プライバシーポリシーについては、AI機能やデータ保存の本実装後に、記載内容と実際の動作が一致しているか再確認する。
# 感想など
今日は特に、画面を作るだけでなく、
- 説明した内容と実際の実装を一致させること
- ブラウザ側のチェックだけでなくサーバー側でも守ること
が勉強になった
また、保存期間を決めると削除処理まで必要になるなど、規約上の決定がそのまま実装内容にも影響すると分かった。
Deviseのような既存の認証機能を使いながら、規約への同意や画面デザインなど、このアプリ固有の部分を追加していく流れも少しずつ分かってきた。
visibility
公開