七海
2026/10/30
今日のメモ
# 今日やったこと
■ 卒業制作
- 16タイプと4グループを管理する`PersonalityType`モデルを作成
- 16タイプの初期データをseedで登録
- UserとPersonalityTypeを関連付け、初期設定前は未選択でも登録できるようにした
- バディキャラ18件を管理するモデルと初期データを作成
- ユーザーが選んだバディキャラを保存できる関連を追加
- SD・全身・顔アイコン画像を用意し、DBには画像パスを保存する形にした
- バディキャラごとに`casual`／`polite`の話し方を設定
- seedの再投入、RSpec、RuboCop、CIまで確認
# 今日理解できたこと
共通データは、ユーザーごとに文字列を直接持たせるのではなく、専用テーブルで管理してIDを参照する形にすると、重複を減らして一貫したデータを扱いやすくなる。
ユーザー登録とタイプ選択は別のタイミングなので、DB側でもNULLを許可し、初期設定前でも登録できるようにする。
#### モデル側のチェックとDB制約は役割が違う
モデルのバリデーションは、保存前に分かりやすいエラーとして扱うためのもの。
一方で、NOT NULL・ユニーク制約・外部キーなどのDB制約は、データ自体の整合性を守るために設定する。
特にタイプコードの重複は、モデルだけでなくDB側にもユニークインデックスを設定した。
また、外部キーを設定していても、NULLを許可することで「まだ選択していない状態」は表現できることが分かった。
#### seedは繰り返し実行しても増えないようにする
初期データは、
`find_or_initialize_by(code: code)`
で既存のタイプを探し、あれば再利用する形にした。
そのため、seedを繰り返し実行しても同じタイプが追加され続けることはなく、実際に再投入後も16件のままであることを確認した。
#### バディキャラのデータと画像は分けて管理する
バディキャラはDB上では18件登録するが、画像は6セットだけを使う設計にした。
- 動物：NT・NF・SP・SJの4種類
- 人物：INTPの男の子・女の子
動物はグループごとに同じ画像を共有するため、18レコードすべてに別画像を用意する必要はない。
画像ファイルは`app/assets/images/companions`へ置き、DBには画像そのものではなく参照用のパスを保存する。
この形なら、将来タイプ専用の画像が増えた場合も、対象レコードの参照先だけ変更できる。
# まだ理解できていないこと
- AI対話・まとめで`casual`／`polite`を切り替える処理
- 本番環境への初期データ投入
# 次にやること
「12. 本番メール送信サービスの選定・送信検証を行う
#16」
# 感想など
この2日で、16タイプという共通データから、実際にユーザーが選ぶバディキャラ：ミツメイトまで一気につながった。
特に、DB上のレコード数と画像ファイル数を一致させる必要はなく、参照先を分けて管理することで、MVPの制作量を抑えつつ将来の差し替えにも対応できる設計にできたのがよかった。
■ 卒業制作
- 16タイプと4グループを管理する`PersonalityType`モデルを作成
- 16タイプの初期データをseedで登録
- UserとPersonalityTypeを関連付け、初期設定前は未選択でも登録できるようにした
- バディキャラ18件を管理するモデルと初期データを作成
- ユーザーが選んだバディキャラを保存できる関連を追加
- SD・全身・顔アイコン画像を用意し、DBには画像パスを保存する形にした
- バディキャラごとに`casual`／`polite`の話し方を設定
- seedの再投入、RSpec、RuboCop、CIまで確認
# 今日理解できたこと
共通データは、ユーザーごとに文字列を直接持たせるのではなく、専用テーブルで管理してIDを参照する形にすると、重複を減らして一貫したデータを扱いやすくなる。
ユーザー登録とタイプ選択は別のタイミングなので、DB側でもNULLを許可し、初期設定前でも登録できるようにする。
#### モデル側のチェックとDB制約は役割が違う
モデルのバリデーションは、保存前に分かりやすいエラーとして扱うためのもの。
一方で、NOT NULL・ユニーク制約・外部キーなどのDB制約は、データ自体の整合性を守るために設定する。
特にタイプコードの重複は、モデルだけでなくDB側にもユニークインデックスを設定した。
また、外部キーを設定していても、NULLを許可することで「まだ選択していない状態」は表現できることが分かった。
#### seedは繰り返し実行しても増えないようにする
初期データは、
`find_or_initialize_by(code: code)`
で既存のタイプを探し、あれば再利用する形にした。
そのため、seedを繰り返し実行しても同じタイプが追加され続けることはなく、実際に再投入後も16件のままであることを確認した。
#### バディキャラのデータと画像は分けて管理する
バディキャラはDB上では18件登録するが、画像は6セットだけを使う設計にした。
- 動物：NT・NF・SP・SJの4種類
- 人物：INTPの男の子・女の子
動物はグループごとに同じ画像を共有するため、18レコードすべてに別画像を用意する必要はない。
画像ファイルは`app/assets/images/companions`へ置き、DBには画像そのものではなく参照用のパスを保存する。
この形なら、将来タイプ専用の画像が増えた場合も、対象レコードの参照先だけ変更できる。
# まだ理解できていないこと
- AI対話・まとめで`casual`／`polite`を切り替える処理
- 本番環境への初期データ投入
# 次にやること
「12. 本番メール送信サービスの選定・送信検証を行う
#16」
# 感想など
この2日で、16タイプという共通データから、実際にユーザーが選ぶバディキャラ：ミツメイトまで一気につながった。
特に、DB上のレコード数と画像ファイル数を一致させる必要はなく、参照先を分けて管理することで、MVPの制作量を抑えつつ将来の差し替えにも対応できる設計にできたのがよかった。
🙂
⛅
🌱
フルちゃん
2026/10/30
今日のメモ
# 今日やったこと
ミニアプリの実装（下書きの編集、削除、挑戦の削除）、復習
# 今日理解できたこと
useEffectによる同じ画面の再描画を行うために、useStateを用いて数値の定数を用意しカウント数をとることについて理解が深まった
# まだ理解できていないこと
# 次にやること
ミニアプリの復習（コードレビュー部分の復習）
# 感想など
明日も頑張っていきたい！
ミニアプリの実装（下書きの編集、削除、挑戦の削除）、復習
# 今日理解できたこと
useEffectによる同じ画面の再描画を行うために、useStateを用いて数値の定数を用意しカウント数をとることについて理解が深まった
# まだ理解できていないこと
# 次にやること
ミニアプリの復習（コードレビュー部分の復習）
# 感想など
明日も頑張っていきたい！
🙂
⛅
🌱
フルちゃん
2026/10/29
今日のメモ
# 今日やったこと
ミニアプリの実装計画作成（マイページの下書きの編集、削除）
paizaを解いた
# 今日理解できたこと
gets.to_sでは/n（改行の文字コード？）を取り除くことができない
include?メソッドで文字列の情報を正しく取得できなかった
gets.to_s.chompなどを行う必要がある
# まだ理解できていないこと
# 次にやること
ミニアプリの実装
# 感想など
明日も頑張っていきたい！
ミニアプリの実装計画作成（マイページの下書きの編集、削除）
paizaを解いた
# 今日理解できたこと
gets.to_sでは/n（改行の文字コード？）を取り除くことができない
include?メソッドで文字列の情報を正しく取得できなかった
gets.to_s.chompなどを行う必要がある
# まだ理解できていないこと
# 次にやること
ミニアプリの実装
# 感想など
明日も頑張っていきたい！
🙂
⛅
🌱
スティーブ
2026/10/28
今日のメモ
チーム開発
準備の１時間を寝てしまい、迷惑をかけてしまう。
引っ越しチーム開発仕事と分単位でスケジュールをこなすほど忙しくて
まじでやばい。
準備の１時間を寝てしまい、迷惑をかけてしまう。
引っ越しチーム開発仕事と分単位でスケジュールをこなすほど忙しくて
まじでやばい。
😞
☁
🌰
七海
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のような既存の認証機能を使いながら、規約への同意や画面デザインなど、このアプリ固有の部分を追加していく流れも少しずつ分かってきた。
🙂
⛅
🌿
七海
2026/10/26
今日のメモ
# 今日やったこと
■卒業制作
- GitHub ActionsでRSpec・RuboCop・セキュリティチェックを自動実行できるようにした
- CI用のPostgreSQL 17を起動し、テストDBを準備してRSpecを実行する構成を確認した
- bundler-auditで検出された依存gemの脆弱性に対応した
- 共通ヘッダー・フッターをRailsのパーシャルへ切り出した
- モックの共通テーマCSSをRailsへ取り込み、共通指定とTOP固有指定を整理した
- PC・スマホ幅で表示確認を行い、日本語の改行位置を調整した
- CIでもTailwind CSSを生成して画面テストできるようにした
# 今日理解できたこと
- CIは、PRの作成や更新をきっかけに、テストやコードチェックを自動で実行する仕組み。
手元でRSpecやRuboCopを実行できていても、人が毎回忘れずに実行するとは限らないため、mainへ取り込む前に自動確認できる状態にしておく意味がある。
- CIが失敗したときは、「CIが失敗した」という一括りではなく、どのジョブが失敗したかを見ることが大切。
今回はRSpec自体は成功していたが、bundler-auditがcrassの脆弱性を検出したため、対象gemを更新、→ RSpec・静的解析・セキュリティチェックすべての成功を確認できた。
CIはテストだけではなく、依存ライブラリの問題を早めに見つける仕組みとしても役立つと分かった。
- 共通テーマと画面固有のCSSを分ける
今回はCSSの役割を分けた。
- shared-theme.css：色・透明度・フォントなど、モック全体で使う共通テーマ
- application.css：共通テーマに不足する、アプリ全体の配置やボタンの基本形
- landing.css：TOPページだけに必要な配置
最初からすべてのCSSを1ファイルへコピーするのではなく、既存の共通テーマを利用して、不足分だけ追加する形を採用した。
共通部分と画面固有部分を分けることで、後続画面でも再利用しやすくなる。
- レスポンシブ対応は、はみ出しだけではないということ
PC表示だけでなく、Chromeの開発者ツールを使って375px幅のスマホ表示も確認したところ、
レイアウト自体は収まってい他けれど、日本語の見出しが、
「なら／ない」
「日／も」
のように意味の途中で分断されて表示されていた。
そのため、spanで意味のまとまりを作って、途中で折り返さないように調整した。
レスポンシブ対応では、画面内に収まっているかだけでなく、文章として自然に読めるかも確認する必要があると感じた。
- 「手元では動くのにCIでは動かない」ときは、ローカルで自動的に行われている処理がCI環境では実行されていない可能性も確認する必要がある。
# まだ理解できていないこと
- 今後画面が増えたとき、どこまでを共通CSSとして切り出すのが適切か
- 共通テーマ・画面固有CSS・Tailwindを併用するときの整理方法
- CIのジョブが増えた場合の実行時間や構成の最適化
# 次にやること
[9. 利用規約・プライバシーポリシーのページを作成する #13]に進む
# 感想など
今日は、コードを書くことだけでなく「同じものを何度も書かない仕組み」と「問題を自動で見つける仕組み」を実装した感じ
CIでは、テスト自体は成功していても依存gemの脆弱性が見つかって、自動チェックを入れる意味を実際に体験できた。
画面実装では、作成済みのモックのCSSをそのまま持ってくるのではなく、共通テーマと画面固有の指定を分けて考える必要があった。
また、スマホ表示では単にはみ出していないだけでは不十分で、日本語の改行位置まで含めて読みやすさを見る必要があると実感した。
■卒業制作
- GitHub ActionsでRSpec・RuboCop・セキュリティチェックを自動実行できるようにした
- CI用のPostgreSQL 17を起動し、テストDBを準備してRSpecを実行する構成を確認した
- bundler-auditで検出された依存gemの脆弱性に対応した
- 共通ヘッダー・フッターをRailsのパーシャルへ切り出した
- モックの共通テーマCSSをRailsへ取り込み、共通指定とTOP固有指定を整理した
- PC・スマホ幅で表示確認を行い、日本語の改行位置を調整した
- CIでもTailwind CSSを生成して画面テストできるようにした
# 今日理解できたこと
- CIは、PRの作成や更新をきっかけに、テストやコードチェックを自動で実行する仕組み。
手元でRSpecやRuboCopを実行できていても、人が毎回忘れずに実行するとは限らないため、mainへ取り込む前に自動確認できる状態にしておく意味がある。
- CIが失敗したときは、「CIが失敗した」という一括りではなく、どのジョブが失敗したかを見ることが大切。
今回はRSpec自体は成功していたが、bundler-auditがcrassの脆弱性を検出したため、対象gemを更新、→ RSpec・静的解析・セキュリティチェックすべての成功を確認できた。
CIはテストだけではなく、依存ライブラリの問題を早めに見つける仕組みとしても役立つと分かった。
- 共通テーマと画面固有のCSSを分ける
今回はCSSの役割を分けた。
- shared-theme.css：色・透明度・フォントなど、モック全体で使う共通テーマ
- application.css：共通テーマに不足する、アプリ全体の配置やボタンの基本形
- landing.css：TOPページだけに必要な配置
最初からすべてのCSSを1ファイルへコピーするのではなく、既存の共通テーマを利用して、不足分だけ追加する形を採用した。
共通部分と画面固有部分を分けることで、後続画面でも再利用しやすくなる。
- レスポンシブ対応は、はみ出しだけではないということ
PC表示だけでなく、Chromeの開発者ツールを使って375px幅のスマホ表示も確認したところ、
レイアウト自体は収まってい他けれど、日本語の見出しが、
「なら／ない」
「日／も」
のように意味の途中で分断されて表示されていた。
そのため、spanで意味のまとまりを作って、途中で折り返さないように調整した。
レスポンシブ対応では、画面内に収まっているかだけでなく、文章として自然に読めるかも確認する必要があると感じた。
- 「手元では動くのにCIでは動かない」ときは、ローカルで自動的に行われている処理がCI環境では実行されていない可能性も確認する必要がある。
# まだ理解できていないこと
- 今後画面が増えたとき、どこまでを共通CSSとして切り出すのが適切か
- 共通テーマ・画面固有CSS・Tailwindを併用するときの整理方法
- CIのジョブが増えた場合の実行時間や構成の最適化
# 次にやること
[9. 利用規約・プライバシーポリシーのページを作成する #13]に進む
# 感想など
今日は、コードを書くことだけでなく「同じものを何度も書かない仕組み」と「問題を自動で見つける仕組み」を実装した感じ
CIでは、テスト自体は成功していても依存gemの脆弱性が見つかって、自動チェックを入れる意味を実際に体験できた。
画面実装では、作成済みのモックのCSSをそのまま持ってくるのではなく、共通テーマと画面固有の指定を分けて考える必要があった。
また、スマホ表示では単にはみ出していないだけでは不十分で、日本語の改行位置まで含めて読みやすさを見る必要があると実感した。
🙂
⛅
🌱
フルちゃん
2026/10/25
今日のメモ
# 今日やったこと
ミニアプリの復習
Vercelでのnode.jsのバージョン確認
動的計画法の問題を解いてみた
# 今日理解できたこと
VercelのBuild Command で node -v && next build とし、Redeployで再デプロイすることでbuild logに node.jsのバージョンを確認できること
バージョンを見ないときはVercelのBuild Command 元に戻すもしくはOverriddenをオフにすること
最新のバージョンであることが確認できた
動的計画法は難しい！
# まだ理解できていないこと
# 次にやること
ミニアプリの実装
アルゴリズムの問題を解く
# 感想など
次も頑張っていきたい！
ミニアプリの復習
Vercelでのnode.jsのバージョン確認
動的計画法の問題を解いてみた
# 今日理解できたこと
VercelのBuild Command で node -v && next build とし、Redeployで再デプロイすることでbuild logに node.jsのバージョンを確認できること
バージョンを見ないときはVercelのBuild Command 元に戻すもしくはOverriddenをオフにすること
最新のバージョンであることが確認できた
動的計画法は難しい！
# まだ理解できていないこと
# 次にやること
ミニアプリの実装
アルゴリズムの問題を解く
# 感想など
次も頑張っていきたい！
🙂
⛅
🌱
フルちゃん
2026/10/24
今日のメモ
# 今日やったこと
コーディングテストを受けた！
反省点：
- 標準入力データの取得に時間がかかってしまった！特に文字列と数値が混じっている場合のデータの取得方法について慣れていけるようにトレーニングしていきたい！
- Ruby の elsif と Python の elif とかいてしまって動作がうまくいかなくて時間をロスしてしまった
- map関数の理解で曖昧なところがあった
# 今日理解できたこと
Rubyのmap関数について
```
[[1, 2, 3], [4, 5, 6], [7, 8, 9]].map { |line| p line }
# 出力結果
# [1, 2, 3]
# [4, 5, 6]
# [7, 8, 9]
[[1, 2, 3], [4, 5, 6], [7, 8, 9]].map { |a, b, c| p a }
# 出力結果
# 1
# 4
# 7
# 文字列にした場合
[['s', 'm', 'l'], ['x', 'y', 'z'], ['c', 'a', 't']].map { |line| p line }
# 出力結果
# ["s", "m", "l"]
# ["x", "y", "z"]
# ["c", "a", "t"]
[['s', 'm', 'l'], ['x', 'y', 'z'], ['c', 'a', 't']].map { |a, b, c| p b }
# 出力結果
# "m"
# "y"
# "a"
# putsにした場合
[['s', 'm', 'l'], ['x', 'y', 'z'], ['c', 'a', 't']].map { |line| puts line }
# 出力結果
# s
# m
# l
# x
# y
# z
# c
# a
# t
[['s', 'm', 'l'], ['x', 'y', 'z'], ['c', 'a', 't']].map { |a, b, c| puts b }
# 出力結果
# m
# y
# a
['c', 'a', 't'].map { |a, b, c| p a }
# 出力結果
# "c"
# "a"
# "t"
['c', 'a', 't'].map { |a, b, c| p b }
# 出力結果
# nil
# nil
# nil
```
# まだ理解できていないこと
# 次にやること
ミニアプリの復習
# 感想など
明日も頑張っていきたい！
コーディングテストを受けた！
反省点：
- 標準入力データの取得に時間がかかってしまった！特に文字列と数値が混じっている場合のデータの取得方法について慣れていけるようにトレーニングしていきたい！
- Ruby の elsif と Python の elif とかいてしまって動作がうまくいかなくて時間をロスしてしまった
- map関数の理解で曖昧なところがあった
# 今日理解できたこと
Rubyのmap関数について
```
[[1, 2, 3], [4, 5, 6], [7, 8, 9]].map { |line| p line }
# 出力結果
# [1, 2, 3]
# [4, 5, 6]
# [7, 8, 9]
[[1, 2, 3], [4, 5, 6], [7, 8, 9]].map { |a, b, c| p a }
# 出力結果
# 1
# 4
# 7
# 文字列にした場合
[['s', 'm', 'l'], ['x', 'y', 'z'], ['c', 'a', 't']].map { |line| p line }
# 出力結果
# ["s", "m", "l"]
# ["x", "y", "z"]
# ["c", "a", "t"]
[['s', 'm', 'l'], ['x', 'y', 'z'], ['c', 'a', 't']].map { |a, b, c| p b }
# 出力結果
# "m"
# "y"
# "a"
# putsにした場合
[['s', 'm', 'l'], ['x', 'y', 'z'], ['c', 'a', 't']].map { |line| puts line }
# 出力結果
# s
# m
# l
# x
# y
# z
# c
# a
# t
[['s', 'm', 'l'], ['x', 'y', 'z'], ['c', 'a', 't']].map { |a, b, c| puts b }
# 出力結果
# m
# y
# a
['c', 'a', 't'].map { |a, b, c| p a }
# 出力結果
# "c"
# "a"
# "t"
['c', 'a', 't'].map { |a, b, c| p b }
# 出力結果
# nil
# nil
# nil
```
# まだ理解できていないこと
# 次にやること
ミニアプリの復習
# 感想など
明日も頑張っていきたい！
🙂
⛅
🌱
フルちゃん
2026/10/23
今日のメモ
# 今日やったこと
ミニアプリの復習
# 今日理解できたこと
```
const { post } = attempt;
```
const post = attempt.post;と同じ
attemptはMyAttempt型になっていて
```
export type AttemptPostSummary = {
id: number;
title: string | null;
image_public_id: string | null;
discarded: boolean;
};
export type MyAttempt = Attempt & { post: AttemptPostSummary };
```
{ } の中にキーの名称であるpostを書くことで、キーの型であるAttemptPostSummary型のデータ要素 (オブジェクト) を取得できる
# まだ理解できていないこと
# 次にやること
ミニアプリの復習（残り）
# 感想など
明日も頑張っていきたい！
ミニアプリの復習
# 今日理解できたこと
```
const { post } = attempt;
```
const post = attempt.post;と同じ
attemptはMyAttempt型になっていて
```
export type AttemptPostSummary = {
id: number;
title: string | null;
image_public_id: string | null;
discarded: boolean;
};
export type MyAttempt = Attempt & { post: AttemptPostSummary };
```
{ } の中にキーの名称であるpostを書くことで、キーの型であるAttemptPostSummary型のデータ要素 (オブジェクト) を取得できる
# まだ理解できていないこと
# 次にやること
ミニアプリの復習（残り）
# 感想など
明日も頑張っていきたい！
🙂
⛅
🌱
七海
2026/10/22
今日のメモ
# 今日やったこと
■Issue #30「26. OpenAI APIの技術検証と利用上限の方針を決める」
の続きから作業
- RailsからOpenAI APIへ短い入力を送り、応答取得を確認
- 共通プロンプトをファイル化し、検証用スクリプト作成
- 対話ケースA〜F2を使って、実際の返答品質を検証
- 検証結果をもとにプロンプト・対話回数・最終返信のルールを調整
- ケースDの保存済み会話から、まとめ生成を検証
- 応答時間・トークン使用量・キャッシュ・費用を記録
- 入力文字数、日次上限、再試行、まとめ生成の扱いを決定
- Issue #30へ検証結果・決定事項・残課題を整理し追記
- コミット〜PRマージまで完了
# 今日理解できたこと
APIへ接続できることと、アプリで求める対話ができることが別すぎる
最初に短い入力で通信確認をしたあと、曖昧な感情、解釈への訂正、自己否定、相反する感情、16タイプへの言及、何も感じない状態、安全上の懸念など、複数のケースで実際に対話した。
評価では単に「正しい返答か」だけでなく、
もう少し話したいと思えるか
AIに答えを言われたのではなく、自分で気づいた感覚があるか
本人が話していない感情や価値観を作っていないか
訂正や状態の変化に合わせて問いを変えられるか
など、利用体験も確認した。
プロンプトは、実際の返答を見ながら調整する必要がある
「決めつけない」「共感する」と書くだけでは、発言を言い換えるだけのオウム返しに近い返答になることがあった。
そのため、本人の発言の中にある
- まだ言葉になっていない部分
- 気持ちと行動の食い違い
- 相反する感情
- 引っかかり
これらへ焦点を向けるように何度も調整を重ねた。
また、すべての場面でAIがユーザーに質問することが正解ではないと分かった。
「何も感じない」「分からない」など、言語化する余力が少ない状態では、無理に深掘りせず短く受け止めることも必要になるため
一方で、「質問しない」「決めつけない」などプロンプトにかくとAIが自身の対応方針を説明したりして
（例えば、「〜はずだと決めつけずに、今伝えてくれたことをそのまま受け止めるよ。」とか)
会話がメタになってしまうので、方針は説明するのではなく返答の中で実行する必要がある。
技術検証によって対話回数の設計も変わった
最初はAI返信3回の設計方針で検証してたけれど、実際に使うと、利用者がAIの問いを受けてから考えるという機会は2回しかなく、
（正直物足りない、もう１ターン欲しい。問いに対してユーザーが考える、これは2回じゃなく3回にしたい。
なぜなぜ分析だって、最低3回はすることが多いし、物足りない感すごい、最低3回考えたい。）
と思った。
また、ターン回数固定という仕様である限り、AIからの最後の返信に疑問系つけるのはNGすぎる。
問いを投げられると、人って返したくなっちゃう気がする。でも返せない。。だから、ボールを持たされたままな感覚になってしまった。
そのため、通常のAI返信は最大4回
利用者が問いを受けて考える機会を3回設ける
通常の最終返信では新しい質問をしない
最後は短い受け止めと整理で着地する
という方針へ変更した。
ただし、毎回4返信を完走すること自体を目的にはしない。
（「何も感じない」「何も分からない」という状態をはじめ、固定4返信だけでは扱えないケースがあるため。）
言語化が難しい状態や余力がない状態では早く終了することも適切な結果として扱う必要があると分かった。
また、最終ターンで「消えたい」という発言が出るケースも検証。
AIは通常の内省を続けず安全確認へ切り替え、通常の「最終返信では質問しない」というルールより安全対応を優先できた。
ただ、安全確認の質問をした直後に通常の4返信上限で終了すると、その質問に利用者が答えられない問題も分かった。
安全対応については通常対話とは別に設計する必要がありるため、本実装前の課題として残す。
# まだ理解できていないこと
#### 理解、もしくはまだ設計できていないこと
- 言語化が難しい場合の早期終了・継続のUI
- 安全確認後の会話フローと終了条件
- 安全対応と通常の4返信上限の関係
- 本実装での最適な出力上限
- まとめ生成結果をAPIからどの形式で取得・保存するか
# 次にやること
#30では技術検証と方針決定まで完了したため、追加のAPI検証は終了
残った課題は後続のAI関連Issueへ引き継ぎ
ひとまず次のIssue「7. GitHub Actionsでテスト・静的解析を自動実行する」に進む
# 感想など
ほぼ一日、AI対話の検証に使った…
最初は「APIにつながって、自然な返事が返ればOK」くらいに考えてたけど、実際に想定できる様々なケースを用意して自分で会話してみると、返信回数や最後の質問の有無だけでも体験が大きく変わることが分かった。
特に、最後に質問されたまま終わる違和感や、何も言葉にできない状態で無理に4返信続けても意味がないこと、安全確認が必要な場合は通常の対話ルールをそのまま使えないことなど、実際に試さなければ気づけなかったことばかりだった。
最初は6時間以内に終わる想定だったのに、結果的に合計10時間かかったIssueではあったけど、単にAPIを接続しただけではなく、「このアプリでAIをどう使いたいのか」をかなり具体的にできた。
■Issue #30「26. OpenAI APIの技術検証と利用上限の方針を決める」
の続きから作業
- RailsからOpenAI APIへ短い入力を送り、応答取得を確認
- 共通プロンプトをファイル化し、検証用スクリプト作成
- 対話ケースA〜F2を使って、実際の返答品質を検証
- 検証結果をもとにプロンプト・対話回数・最終返信のルールを調整
- ケースDの保存済み会話から、まとめ生成を検証
- 応答時間・トークン使用量・キャッシュ・費用を記録
- 入力文字数、日次上限、再試行、まとめ生成の扱いを決定
- Issue #30へ検証結果・決定事項・残課題を整理し追記
- コミット〜PRマージまで完了
# 今日理解できたこと
APIへ接続できることと、アプリで求める対話ができることが別すぎる
最初に短い入力で通信確認をしたあと、曖昧な感情、解釈への訂正、自己否定、相反する感情、16タイプへの言及、何も感じない状態、安全上の懸念など、複数のケースで実際に対話した。
評価では単に「正しい返答か」だけでなく、
もう少し話したいと思えるか
AIに答えを言われたのではなく、自分で気づいた感覚があるか
本人が話していない感情や価値観を作っていないか
訂正や状態の変化に合わせて問いを変えられるか
など、利用体験も確認した。
プロンプトは、実際の返答を見ながら調整する必要がある
「決めつけない」「共感する」と書くだけでは、発言を言い換えるだけのオウム返しに近い返答になることがあった。
そのため、本人の発言の中にある
- まだ言葉になっていない部分
- 気持ちと行動の食い違い
- 相反する感情
- 引っかかり
これらへ焦点を向けるように何度も調整を重ねた。
また、すべての場面でAIがユーザーに質問することが正解ではないと分かった。
「何も感じない」「分からない」など、言語化する余力が少ない状態では、無理に深掘りせず短く受け止めることも必要になるため
一方で、「質問しない」「決めつけない」などプロンプトにかくとAIが自身の対応方針を説明したりして
（例えば、「〜はずだと決めつけずに、今伝えてくれたことをそのまま受け止めるよ。」とか)
会話がメタになってしまうので、方針は説明するのではなく返答の中で実行する必要がある。
技術検証によって対話回数の設計も変わった
最初はAI返信3回の設計方針で検証してたけれど、実際に使うと、利用者がAIの問いを受けてから考えるという機会は2回しかなく、
（正直物足りない、もう１ターン欲しい。問いに対してユーザーが考える、これは2回じゃなく3回にしたい。
なぜなぜ分析だって、最低3回はすることが多いし、物足りない感すごい、最低3回考えたい。）
と思った。
また、ターン回数固定という仕様である限り、AIからの最後の返信に疑問系つけるのはNGすぎる。
問いを投げられると、人って返したくなっちゃう気がする。でも返せない。。だから、ボールを持たされたままな感覚になってしまった。
そのため、通常のAI返信は最大4回
利用者が問いを受けて考える機会を3回設ける
通常の最終返信では新しい質問をしない
最後は短い受け止めと整理で着地する
という方針へ変更した。
ただし、毎回4返信を完走すること自体を目的にはしない。
（「何も感じない」「何も分からない」という状態をはじめ、固定4返信だけでは扱えないケースがあるため。）
言語化が難しい状態や余力がない状態では早く終了することも適切な結果として扱う必要があると分かった。
また、最終ターンで「消えたい」という発言が出るケースも検証。
AIは通常の内省を続けず安全確認へ切り替え、通常の「最終返信では質問しない」というルールより安全対応を優先できた。
ただ、安全確認の質問をした直後に通常の4返信上限で終了すると、その質問に利用者が答えられない問題も分かった。
安全対応については通常対話とは別に設計する必要がありるため、本実装前の課題として残す。
# まだ理解できていないこと
#### 理解、もしくはまだ設計できていないこと
- 言語化が難しい場合の早期終了・継続のUI
- 安全確認後の会話フローと終了条件
- 安全対応と通常の4返信上限の関係
- 本実装での最適な出力上限
- まとめ生成結果をAPIからどの形式で取得・保存するか
# 次にやること
#30では技術検証と方針決定まで完了したため、追加のAPI検証は終了
残った課題は後続のAI関連Issueへ引き継ぎ
ひとまず次のIssue「7. GitHub Actionsでテスト・静的解析を自動実行する」に進む
# 感想など
ほぼ一日、AI対話の検証に使った…
最初は「APIにつながって、自然な返事が返ればOK」くらいに考えてたけど、実際に想定できる様々なケースを用意して自分で会話してみると、返信回数や最後の質問の有無だけでも体験が大きく変わることが分かった。
特に、最後に質問されたまま終わる違和感や、何も言葉にできない状態で無理に4返信続けても意味がないこと、安全確認が必要な場合は通常の対話ルールをそのまま使えないことなど、実際に試さなければ気づけなかったことばかりだった。
最初は6時間以内に終わる想定だったのに、結果的に合計10時間かかったIssueではあったけど、単にAPIを接続しただけではなく、「このアプリでAIをどう使いたいのか」をかなり具体的にできた。
😐
⛅
🌰
フルちゃん
2026/10/22
今日のメモ
# 今日やったこと
- 卒制アプリNode.jsのアップデート
セキュリティサポートが終了していたため、node.js 24.22.1にアップデート（昨日の更新に対応できている）
- ミニアプリの復習
- paiza B問題とC問題1問ずつ
- コーディングテストに向けたRubyの記事集をtimesに投稿
# 今日理解できたこと
自分のRailsアプリではnode.jsが導入されている！ビルド時のみに用いられているため、早急に必要ではないようだが、行った！
今回の脆弱性の用途（ドメインなどではあったようだ）には該当しないようだった！
# まだ理解できていないこと
Vercelの方は最新のをVercel側がアップデートしているようだが、気になる！
# 次にやること
ミニアプリの復習の続き（レビューの部分）
# 感想など
明日も頑張っていきたい！
- 卒制アプリNode.jsのアップデート
セキュリティサポートが終了していたため、node.js 24.22.1にアップデート（昨日の更新に対応できている）
- ミニアプリの復習
- paiza B問題とC問題1問ずつ
- コーディングテストに向けたRubyの記事集をtimesに投稿
# 今日理解できたこと
自分のRailsアプリではnode.jsが導入されている！ビルド時のみに用いられているため、早急に必要ではないようだが、行った！
今回の脆弱性の用途（ドメインなどではあったようだ）には該当しないようだった！
# まだ理解できていないこと
Vercelの方は最新のをVercel側がアップデートしているようだが、気になる！
# 次にやること
ミニアプリの復習の続き（レビューの部分）
# 感想など
明日も頑張っていきたい！
🙂
⛅
🌱
フルちゃん
2026/10/21
今日のメモ
# 今日やったこと
ミニアプリ（マイページ）の実装、少し復習
paizaを解いた
# 今日理解できたこと
TypeScriptのメソッドの引数について{ ...DEFAULT_QUERY, ...query } と書くことで初期値DEFAULT_QUERYで同じ型の与えられた値queryで（全てでなくてもハッシュの一部の要素でも良い）引数の値を上書きできるということを表せる！
# まだ理解できていないこと
# 次にやること
ミニアプリ（マイページ）の復習
ソフトウェア設計手法
# 感想など
ソフトウェア設計手法明日やりたい！
ミニアプリ（マイページ）の実装、少し復習
paizaを解いた
# 今日理解できたこと
TypeScriptのメソッドの引数について{ ...DEFAULT_QUERY, ...query } と書くことで初期値DEFAULT_QUERYで同じ型の与えられた値queryで（全てでなくてもハッシュの一部の要素でも良い）引数の値を上書きできるということを表せる！
# まだ理解できていないこと
# 次にやること
ミニアプリ（マイページ）の復習
ソフトウェア設計手法
# 感想など
ソフトウェア設計手法明日やりたい！
🙂
⛅
🌱
七海
2026/10/21
今日のメモ
# 今日やったこと
（10/20~10/21にやったこと）
- RSpec・FactoryBotを導入し、TOPページのrequest specを作成
- SimpleCovを導入し、RSpec実行時にコードカバレッジを確認できるようにした
- Rails生成時から導入されていたRuboCopの設定・役割を確認し、READMEへ実行方法を追記
- OpenAI APIを利用するAI対話機能について、候補モデル・料金・キャッシュ・利用体験を比較検討
- GPT-6.1 Solを採用候補として決定
- OpenAI API Platformへの初回入金、APIキーの作成・設定、公式SDKの導入
- AIに求める対話方針と、検証用プロンプトを整理
# 今日理解できたこと
RSpecでは、実際にコードを動かして「期待する振る舞いになっているか」を確認できる。
TOPページでは単に成功系であればよいのではなく、期待するHTTPステータスが200であることを明確に確認したかったため、have_http_status(:ok)を使用した。
書き方 ➡️ 成功する条件
have_http_status(:ok) ➡️ 200だけ
have_http_status(200) ➡️ 200だけ
have_http_status(:success) ➡️ 200〜299のすべて
:successでは200〜299まで許容するため、テストしたい内容によって使い分ける必要がある。
SimpleCovはテスト時に「どのRubyコードが実行されたか」を可視化するためのもので、カバレッジが高いことと、テストの品質が高いことは同じではない。
100％を目標にするのではなく、テストされていない重要な処理を見つけるために使う。
RuboCopはRSpecとは役割が異なり、コードを実行するのではなく、静的に解析して書式や問題になりそうな書き方を確認する。
（今回はRails生成時からrubocop-rails-omakaseが導入済みだったため、新しいツールや独自ルールを増やさず既存設定を利用）
### AI機能について理解・整理できたこと
卒業制作に組み込むAIには、単に正しい答えを出すことよりも、
- 利用者の発言や文脈を丁寧に受け取る
- 感情や価値観を勝手に断定しない
- 本人が訂正した場合は理解を更新する
- 共感だけで終わらず、本人自身が考えられる問いを返す
- 解決策や結論を急いで押しつけない
という振る舞いが重要だと整理できた。
Claude Sonnetも候補として調査したけど、複数のAPIへ初期費用を払い比較すること自体はMVPの必須条件ではないので、実際に自分自身が自己理解や感情の整理に利用してきたGPTを採用する方針にした。
ChatGPTとの対話によって、言葉にできなかった感情を整理し、自分が何を大切にしていたのかに気づけた経験が、このアプリの原体験でもある。
そのため、まずGPT-6.1 Solを採用候補としてAPI上で検証し、「内省や言語化に慣れていない人でも、自分自身の気づきにたどり着ける体験」を再現できるかを確認する。
また、API料金だけでなく、ユーザーがAIの返信を読んで5分・10分と考える可能性を踏まえ、キャッシュ保持時間や会話履歴の扱いも利用体験に関係するので比較検討した。
キャッシュが切れても会話履歴そのものが失われるわけではなく、アプリ側で履歴を保持して再送すれば文脈は維持できる。
料金を抑えるためにユーザーへ素早い返信を求めるのではなく、考える時間そのものを自己理解のプロセスとして大切にしたい。
# まだ理解できていないこと
- GPT-6.1 Solを実際のAPIで利用した場合の対話品質・応答時間・実際のトークン使用量
- 推論トークンやキャッシュを含めた、1回の振り返りにかかる実費
- 1送信あたりの文字数、AIの出力量、1日の利用上限などの最適な値
- 検証用プロンプトで、狙ったものがどこまで安定して再現できるか
# 次にやること
- GPT-6.1 SolとのAPI通信を実際に試す
- 曖昧な感情、解釈への訂正、自己否定、相反する感情など複数ケースで対話品質を検証する
- 入出力トークン数、推論、キャッシュ、応答時間、費用を記録する
- 検証結果をもとにプロンプトを調整する
- 文字数・対話回数・日次利用上限など、MVPでの利用制限方針を決定する
# 感想など
テスト周りは、それぞれのツールの役割を改めて少しずつ整理できた。
RSpec、SimpleCov、RuboCopはすべて「品質を確認するもの」ではあるけれど、確認しているものはそれぞれ違う。実際に導入・確認したことで、理解は深まった。
そして今日は、卒業制作の中でも特に大切なAI対話についてかなり深く考えた。
あっという間に時間が溶けていって、でも進捗は思うように進んでいなくて、焦ってしまう…。
最初は「どのモデルが一番賢いか」を選ぶ問題にも見えたけれど、考えていくうちに、賢さそのものではなく「利用者が自分で考え、自分の言葉で気づける余白を残せるか」が重要と改めて分かった。
自分自身がChatGPTとの対話で得た体験が開発の原点なので、それをそのままコピーするのではなく、内省に慣れていない人でも使いやすい形へ落とし込んでいきたい。
（10/20~10/21にやったこと）
- RSpec・FactoryBotを導入し、TOPページのrequest specを作成
- SimpleCovを導入し、RSpec実行時にコードカバレッジを確認できるようにした
- Rails生成時から導入されていたRuboCopの設定・役割を確認し、READMEへ実行方法を追記
- OpenAI APIを利用するAI対話機能について、候補モデル・料金・キャッシュ・利用体験を比較検討
- GPT-6.1 Solを採用候補として決定
- OpenAI API Platformへの初回入金、APIキーの作成・設定、公式SDKの導入
- AIに求める対話方針と、検証用プロンプトを整理
# 今日理解できたこと
RSpecでは、実際にコードを動かして「期待する振る舞いになっているか」を確認できる。
TOPページでは単に成功系であればよいのではなく、期待するHTTPステータスが200であることを明確に確認したかったため、have_http_status(:ok)を使用した。
書き方 ➡️ 成功する条件
have_http_status(:ok) ➡️ 200だけ
have_http_status(200) ➡️ 200だけ
have_http_status(:success) ➡️ 200〜299のすべて
:successでは200〜299まで許容するため、テストしたい内容によって使い分ける必要がある。
SimpleCovはテスト時に「どのRubyコードが実行されたか」を可視化するためのもので、カバレッジが高いことと、テストの品質が高いことは同じではない。
100％を目標にするのではなく、テストされていない重要な処理を見つけるために使う。
RuboCopはRSpecとは役割が異なり、コードを実行するのではなく、静的に解析して書式や問題になりそうな書き方を確認する。
（今回はRails生成時からrubocop-rails-omakaseが導入済みだったため、新しいツールや独自ルールを増やさず既存設定を利用）
### AI機能について理解・整理できたこと
卒業制作に組み込むAIには、単に正しい答えを出すことよりも、
- 利用者の発言や文脈を丁寧に受け取る
- 感情や価値観を勝手に断定しない
- 本人が訂正した場合は理解を更新する
- 共感だけで終わらず、本人自身が考えられる問いを返す
- 解決策や結論を急いで押しつけない
という振る舞いが重要だと整理できた。
Claude Sonnetも候補として調査したけど、複数のAPIへ初期費用を払い比較すること自体はMVPの必須条件ではないので、実際に自分自身が自己理解や感情の整理に利用してきたGPTを採用する方針にした。
ChatGPTとの対話によって、言葉にできなかった感情を整理し、自分が何を大切にしていたのかに気づけた経験が、このアプリの原体験でもある。
そのため、まずGPT-6.1 Solを採用候補としてAPI上で検証し、「内省や言語化に慣れていない人でも、自分自身の気づきにたどり着ける体験」を再現できるかを確認する。
また、API料金だけでなく、ユーザーがAIの返信を読んで5分・10分と考える可能性を踏まえ、キャッシュ保持時間や会話履歴の扱いも利用体験に関係するので比較検討した。
キャッシュが切れても会話履歴そのものが失われるわけではなく、アプリ側で履歴を保持して再送すれば文脈は維持できる。
料金を抑えるためにユーザーへ素早い返信を求めるのではなく、考える時間そのものを自己理解のプロセスとして大切にしたい。
# まだ理解できていないこと
- GPT-6.1 Solを実際のAPIで利用した場合の対話品質・応答時間・実際のトークン使用量
- 推論トークンやキャッシュを含めた、1回の振り返りにかかる実費
- 1送信あたりの文字数、AIの出力量、1日の利用上限などの最適な値
- 検証用プロンプトで、狙ったものがどこまで安定して再現できるか
# 次にやること
- GPT-6.1 SolとのAPI通信を実際に試す
- 曖昧な感情、解釈への訂正、自己否定、相反する感情など複数ケースで対話品質を検証する
- 入出力トークン数、推論、キャッシュ、応答時間、費用を記録する
- 検証結果をもとにプロンプトを調整する
- 文字数・対話回数・日次利用上限など、MVPでの利用制限方針を決定する
# 感想など
テスト周りは、それぞれのツールの役割を改めて少しずつ整理できた。
RSpec、SimpleCov、RuboCopはすべて「品質を確認するもの」ではあるけれど、確認しているものはそれぞれ違う。実際に導入・確認したことで、理解は深まった。
そして今日は、卒業制作の中でも特に大切なAI対話についてかなり深く考えた。
あっという間に時間が溶けていって、でも進捗は思うように進んでいなくて、焦ってしまう…。
最初は「どのモデルが一番賢いか」を選ぶ問題にも見えたけれど、考えていくうちに、賢さそのものではなく「利用者が自分で考え、自分の言葉で気づける余白を残せるか」が重要と改めて分かった。
自分自身がChatGPTとの対話で得た体験が開発の原点なので、それをそのままコピーするのではなく、内省に慣れていない人でも使いやすい形へ落とし込んでいきたい。
🙂
⛅
🌱
フルちゃん
2026/10/20
今日のメモ
# 今日やったこと
ミニアプリ（マイページ）実装Claude Codeと打ち合わせ
paiza BとC解いた
ソフトウェア設計手法のカリキュラムにらめっこ
# 今日理解できたこと
# まだ理解できていないこと
# 次にやること
paizaを解く
ソフトウェア設計手法のカリキュラム進める
# 感想など
明日も頑張る！
ミニアプリ（マイページ）実装Claude Codeと打ち合わせ
paiza BとC解いた
ソフトウェア設計手法のカリキュラムにらめっこ
# 今日理解できたこと
# まだ理解できていないこと
# 次にやること
paizaを解く
ソフトウェア設計手法のカリキュラム進める
# 感想など
明日も頑張る！
🙂
⛅
🌱
フルちゃん
2026/10/19
今日のメモ
# 今日やったこと
卒制アプリのdependabotに対応
# 今日理解できたこと
セキュリティ対策はGithubのsettingの「Dependabot alerts」「Malware alerts」「Dependabot security updates」をオンにすると行えること
脆弱性について公開されているgemについてアップデートや通知が届くようだ！
# まだ理解できていないこと
# 次にやること
ミニアプリの実装（マイページ）
# 感想など
明日も頑張っていきたい！
卒制アプリのdependabotに対応
# 今日理解できたこと
セキュリティ対策はGithubのsettingの「Dependabot alerts」「Malware alerts」「Dependabot security updates」をオンにすると行えること
脆弱性について公開されているgemについてアップデートや通知が届くようだ！
# まだ理解できていないこと
# 次にやること
ミニアプリの実装（マイページ）
# 感想など
明日も頑張っていきたい！
🙂
⛅
🌱
七海
2026/10/19
今日のメモ
# 今日やったこと
■ 卒業制作実装開始
Issue #4 / 1. Rails・PostgreSQLの開発環境構築
- Docker ComposeでRails＋PostgreSQLの開発環境を構築
Issue #5 / 2. TOPページ作成
- TOPページのルーティング・Controller・Viewを実装
Issue #6 / 3. Render・Neonへの初回デプロイ
- 本番環境でTOPページ・画像・DB接続を確認
- 本番環境固有の設定エラーを修正
- PRのマージからIssue・Projectsが自動更新される流れを確認
# 今日理解できたこと
PRにCloses #番号を書くと、mainへのマージ時に対象Issueが自動で閉じられる。
また、GitHub Projects側の自動化によって、
PRをマージ → IssueがClosed → ProjectsでDoneへ移動
という流れまで自動でつながっていることが分かった。
また、画面遷移図の段階で、最低限の線と記号だけではなく、実際の画面配置・色・メインビジュアル画像まで何度も検討してモックを固めていたため、設計時にはかなり時間がかかったものの、今回のTOPページ実装は迷わず短時間で進めることができた。
自分の場合は、実際の画面イメージが見えない状態だと必要なボタンや遷移画面の見落としも増えやすく、開発へのワクワク感も持ちにくいからって理由だったけど、
先にUIを具体化することは単なる見た目づくりではなく、その後の実装をスムーズに進めるための設計作業でもあったんだと実感した。
今後も画面遷移図に時間をかけたことでスムーズに進むシーンは多そう。
# まだ理解できていないこと
- Docker・Rails・PostgreSQLそれぞれの設定については、動かせるようになっただけでなく、今後さらに「なぜこの設定が必要なのか」を説明できるようにしたい
- Renderとローカル環境の違いや、本番固有の設定については今後のデプロイでも理解を深めたい
# 次にやること
- Issue #7以降の第1週予定Issueを進める
- 各Issueで「何を作ったか」だけでなく、採用理由・仕組み・エラー原因も理解メモとして残す
- 今後も変更をため込まず、本番環境でこまめに動作確認する
# 感想など
今日からいよいよ卒業制作の実装開始。
設計中は、画面遷移図やモックを結構作り込み、「ここまでやる必要絶対ないのにな」と思いつつも凝り性が発動して時間がかかってたけど、実装に入ってみると、その時に決めた内容がそのまま道しるべになり、TOPページはほとんど迷わず作ることができた。
設計に時間をかけた分が、実装速度として返ってきた感覚があって少し嬉しかった♩
初回デプロイは実際に本番環境でしか気づけない設定ミスにも遭遇し、「CIが通ること」と「本番で正常に動くこと」は別だと実体験として理解できた。
初日から環境構築・TOPページ・初回デプロイまで進められて、卒業制作がようやく「机上で設計しているもの」から「実際に動くアプリ」になり始めた感じ。
■ 卒業制作実装開始
Issue #4 / 1. Rails・PostgreSQLの開発環境構築
- Docker ComposeでRails＋PostgreSQLの開発環境を構築
Issue #5 / 2. TOPページ作成
- TOPページのルーティング・Controller・Viewを実装
Issue #6 / 3. Render・Neonへの初回デプロイ
- 本番環境でTOPページ・画像・DB接続を確認
- 本番環境固有の設定エラーを修正
- PRのマージからIssue・Projectsが自動更新される流れを確認
# 今日理解できたこと
PRにCloses #番号を書くと、mainへのマージ時に対象Issueが自動で閉じられる。
また、GitHub Projects側の自動化によって、
PRをマージ → IssueがClosed → ProjectsでDoneへ移動
という流れまで自動でつながっていることが分かった。
また、画面遷移図の段階で、最低限の線と記号だけではなく、実際の画面配置・色・メインビジュアル画像まで何度も検討してモックを固めていたため、設計時にはかなり時間がかかったものの、今回のTOPページ実装は迷わず短時間で進めることができた。
自分の場合は、実際の画面イメージが見えない状態だと必要なボタンや遷移画面の見落としも増えやすく、開発へのワクワク感も持ちにくいからって理由だったけど、
先にUIを具体化することは単なる見た目づくりではなく、その後の実装をスムーズに進めるための設計作業でもあったんだと実感した。
今後も画面遷移図に時間をかけたことでスムーズに進むシーンは多そう。
# まだ理解できていないこと
- Docker・Rails・PostgreSQLそれぞれの設定については、動かせるようになっただけでなく、今後さらに「なぜこの設定が必要なのか」を説明できるようにしたい
- Renderとローカル環境の違いや、本番固有の設定については今後のデプロイでも理解を深めたい
# 次にやること
- Issue #7以降の第1週予定Issueを進める
- 各Issueで「何を作ったか」だけでなく、採用理由・仕組み・エラー原因も理解メモとして残す
- 今後も変更をため込まず、本番環境でこまめに動作確認する
# 感想など
今日からいよいよ卒業制作の実装開始。
設計中は、画面遷移図やモックを結構作り込み、「ここまでやる必要絶対ないのにな」と思いつつも凝り性が発動して時間がかかってたけど、実装に入ってみると、その時に決めた内容がそのまま道しるべになり、TOPページはほとんど迷わず作ることができた。
設計に時間をかけた分が、実装速度として返ってきた感覚があって少し嬉しかった♩
初回デプロイは実際に本番環境でしか気づけない設定ミスにも遭遇し、「CIが通ること」と「本番で正常に動くこと」は別だと実体験として理解できた。
初日から環境構築・TOPページ・初回デプロイまで進められて、卒業制作がようやく「机上で設計しているもの」から「実際に動くアプリ」になり始めた感じ。
🙂
⛅
🌿
七海
2026/10/18
今日のメモ
# 今日やったこと
■ Docker完全ガイド 開発/本番環境運用に備えて
∟ 1. Docker入門とDockerfileの基本構文
∟ 2. レイヤーキャッシュと効率的なビルド
∟ 3. docker-composeでマルチコンテナを動かそう
∟ 4. 開発環境と本番環境の使い分け／運用戦略
∟ 5. Railsアプリケーションのコンテナ化ハンズオン
# 今日理解できたこと
■ Dockerの基本的な仕組み
- **Dockerfile**：イメージを作成するための設計図
- **イメージ**：アプリの実行に必要な環境をまとめたもの
- **コンテナ**：イメージをもとに作成される実行環境
- **Docker Compose**：複数のコンテナをまとめて定義・管理する仕組み
■ レイヤーキャッシュとDockerfileの最適化
Dockerはビルド時にキャッシュを再利用することで、不要な処理を省略できる。
特に重要なのは、変更頻度の低い処理を先に、変更頻度の高い処理を後に配置すること。
また、不要な一時ファイルは同じ `RUN` 命令内で削除することで、イメージの肥大化を防げる。
■ 開発環境と本番環境の管理
開発環境では変更の即時反映やデバッグのしやすさ、本番環境では軽量化・セキュリティ・安定稼働が重視される。
環境別のDockerfile管理方法2種類
- **マルチステージビルド**：1つのDockerfile内で開発用・本番用などのステージを分ける
- **ファイル分割**：`Dockerfile.dev` と `Dockerfile.prod` のように用途ごとに分ける
環境変数も `.env.development` や `.env.production` などで分離できる。
APIキーやパスワードなどの機密情報は、Gitの管理対象に含めず、安全に管理することが重要。
■ Procfile.devとForeman
`Procfile.dev` にRailsサーバーとJavaScriptのビルド処理を定義した。
`./bin/dev` からForemanを実行することで、複数のプロセスを同時に起動できる。
Docker Composeはコンテナを管理し、Foremanはコンテナ内の複数プロセスを管理する
■ Docker環境の終了時
`docker compose down` と `docker compose down -v` は異なり、`-v` を付けると名前付きボリュームも削除されることに注意が必要。
# まだ理解できていないこと
- Dockerfileやcompose.ymlを、教材なしで一から設計できるほどには理解できていない
- Docker環境で問題が起きた際、自分で原因を判断して適切に修正する力はまだ不十分
# 次にやること
- 卒業制作の開発環境を確認し、今回学んだ設定やコマンドと結びつけて理解する
- AIに修正を依頼する場合も、自分でも調べて、提案された変更の目的と影響を理解してから実行する
# 感想など
これまでDocker Desktopを使った環境構築や、Docker Composeでのアプリ起動は何度も経験していたけど、今回の学習で初めて、それぞれのファイルやコマンドが担っている役割を体系的に理解できた。
特に印象に残ったのはDockerfile最適化テクニックと、開発環境・本番環境で設定を使い分ける方法
これまでは用意された環境を動かすことが中心だったけど、環境の作り方にも設計上の意図があるんだなとわかった。
また、AI活用の心得を読んで、
自分が何をしているのか理解し、判断する姿勢を持つことが大切だと改めて感じた。
ただAIに正解を出してもらうのではなく、まずは正しく動くものを参考にしながら、自分でコードを読み、仕組みや設計意図を理解する力を身につけたい。
今後の卒業制作でも、効率化のためにAIを活用しながら、コードの理解と判断力を身につけることを意識していきたい
■ Docker完全ガイド 開発/本番環境運用に備えて
∟ 1. Docker入門とDockerfileの基本構文
∟ 2. レイヤーキャッシュと効率的なビルド
∟ 3. docker-composeでマルチコンテナを動かそう
∟ 4. 開発環境と本番環境の使い分け／運用戦略
∟ 5. Railsアプリケーションのコンテナ化ハンズオン
# 今日理解できたこと
■ Dockerの基本的な仕組み
- **Dockerfile**：イメージを作成するための設計図
- **イメージ**：アプリの実行に必要な環境をまとめたもの
- **コンテナ**：イメージをもとに作成される実行環境
- **Docker Compose**：複数のコンテナをまとめて定義・管理する仕組み
■ レイヤーキャッシュとDockerfileの最適化
Dockerはビルド時にキャッシュを再利用することで、不要な処理を省略できる。
特に重要なのは、変更頻度の低い処理を先に、変更頻度の高い処理を後に配置すること。
また、不要な一時ファイルは同じ `RUN` 命令内で削除することで、イメージの肥大化を防げる。
■ 開発環境と本番環境の管理
開発環境では変更の即時反映やデバッグのしやすさ、本番環境では軽量化・セキュリティ・安定稼働が重視される。
環境別のDockerfile管理方法2種類
- **マルチステージビルド**：1つのDockerfile内で開発用・本番用などのステージを分ける
- **ファイル分割**：`Dockerfile.dev` と `Dockerfile.prod` のように用途ごとに分ける
環境変数も `.env.development` や `.env.production` などで分離できる。
APIキーやパスワードなどの機密情報は、Gitの管理対象に含めず、安全に管理することが重要。
■ Procfile.devとForeman
`Procfile.dev` にRailsサーバーとJavaScriptのビルド処理を定義した。
`./bin/dev` からForemanを実行することで、複数のプロセスを同時に起動できる。
Docker Composeはコンテナを管理し、Foremanはコンテナ内の複数プロセスを管理する
■ Docker環境の終了時
`docker compose down` と `docker compose down -v` は異なり、`-v` を付けると名前付きボリュームも削除されることに注意が必要。
# まだ理解できていないこと
- Dockerfileやcompose.ymlを、教材なしで一から設計できるほどには理解できていない
- Docker環境で問題が起きた際、自分で原因を判断して適切に修正する力はまだ不十分
# 次にやること
- 卒業制作の開発環境を確認し、今回学んだ設定やコマンドと結びつけて理解する
- AIに修正を依頼する場合も、自分でも調べて、提案された変更の目的と影響を理解してから実行する
# 感想など
これまでDocker Desktopを使った環境構築や、Docker Composeでのアプリ起動は何度も経験していたけど、今回の学習で初めて、それぞれのファイルやコマンドが担っている役割を体系的に理解できた。
特に印象に残ったのはDockerfile最適化テクニックと、開発環境・本番環境で設定を使い分ける方法
これまでは用意された環境を動かすことが中心だったけど、環境の作り方にも設計上の意図があるんだなとわかった。
また、AI活用の心得を読んで、
自分が何をしているのか理解し、判断する姿勢を持つことが大切だと改めて感じた。
ただAIに正解を出してもらうのではなく、まずは正しく動くものを参考にしながら、自分でコードを読み、仕組みや設計意図を理解する力を身につけたい。
今後の卒業制作でも、効率化のためにAIを活用しながら、コードの理解と判断力を身につけることを意識していきたい
😐
☁
🌱
フルちゃん
2026/10/18
今日のメモ
# 今日やったこと
ミニアプリの復習
# 今日理解できたこと
テストコードについて
AbortContrllerとReadableStreamControllerの両方が用いられてごちゃごちゃしていた！
ReadableStreamはデータが少しずつ時間をかけて届くものを表す、ブラウザ標準のオブジェクト。ReadableStreamControllerとして引数で用いられるcontrollerはcloseしない限り、動作が待ちのままにできる！テストコードにおいてReadableStreamオブジェクトをfetch関数のスタブとしてcontroller.errorとするのみでcloseしていなかったため、await response.text()の取得においてデータの取得待ちにできた！
# まだ理解できていないこと
# 次にやること
ミニアプリの実装（マイページ）
卒制アプリのdependabot周り
面接の回答を練る
# 感想など
明日も頑張っていきたい！
ミニアプリの復習
# 今日理解できたこと
テストコードについて
AbortContrllerとReadableStreamControllerの両方が用いられてごちゃごちゃしていた！
ReadableStreamはデータが少しずつ時間をかけて届くものを表す、ブラウザ標準のオブジェクト。ReadableStreamControllerとして引数で用いられるcontrollerはcloseしない限り、動作が待ちのままにできる！テストコードにおいてReadableStreamオブジェクトをfetch関数のスタブとしてcontroller.errorとするのみでcloseしていなかったため、await response.text()の取得においてデータの取得待ちにできた！
# まだ理解できていないこと
# 次にやること
ミニアプリの実装（マイページ）
卒制アプリのdependabot周り
面接の回答を練る
# 感想など
明日も頑張っていきたい！
🙂
⛅
🌱