crafted by Mize ↗
Open Repository Intelligence Open Repository Intelligence
CodeLens ACTIVE
CodeLens Engine
StatusOnline
Versionv0.4
ModelClaude Sonnet
Latency—
0
GOOD
改善余地があります
toma-0105/makasete-calo-gohan
「献立を考える負担をゼロに」というコンセプトは明快だが、コードも同じ精神で「エラーハンドリングを考える負担をゼロに」してしまっており、候補枯渇時の500エラーが本番でユーザーを出迎える未来が見える。
⭐ 0 Stars
·
🍴 0 Forks
·
📝 196 Commits
·
💬 32 Issues
·
🔵 Ruby
·
Rails
🔍 重要ファイル 12 件を精査 全 276 ファイル中 AI が優先度順に選択
0
✦ 品質
0
🛡 セキュリティ
0
⚙ 保守性
📋 概要

Ruby on Rails 8.0製のダイエット献立自動生成Webアプリ。Devise認証・PostgreSQL・Hotwire(Turbo/Stimulus)・TailwindCSS/DaisyUIを採用し、TDEE・アレルギー情報をもとにAIまたはロジックで1日3食の献立を自動生成する機能を中心に構成されている。

🎯 今すぐ直すべき3点
  1. config/initializers/devise.rb config.mailer_sender が 'please-change-me-at-config-initializers-devise@example.com' のままになっている。本番環境で送信されるパスワードリセットメールの差出人が無効アドレスになりメール到達性が損なわれるため、実際のサービスドメインのアドレスに変更し、環境変数経由で設定すること(例: ENV.fetch('DEVISE_MAILER_SENDER'))。
    ↗
  2. app/services/menu_generator_service.rb ファイル全体が7298文字・truncatedのため全容未確認だが、読めた範囲でエラーハンドリングが見当たらない。MealMasterのレコードが不足している場合(例: breakfast用のstapleが0件)にnil参照やArray#sampleがnilを返してサービスがクラッシュするリスクがある。generate_breakfast / generate_lunch_or_dinner の各メソッドで候補が空の場合のガード節(raise または早期return+エラーメッセージ)を追加すること。
    ↗
  3. config/environments/production.rb config.active_storage.service が :local のままになっており、Renderなどのエフェメラルファイルシステム上ではアップロードファイルがデプロイのたびに消失する。S3互換ストレージ(AWS S3 / Cloudflare R2等)に切り替え、config/storage.ymlとRAILS_MASTER_KEY経由のcredentialsで接続情報を管理すること。
    ↗
🔍 検出された問題 (6件)
🟧 Warning 📄 config/initializers/devise.rb
Deviseメール送信者アドレスがデフォルトのプレースホルダーのまま
config/initializers/devise.rb の config.mailer_sender が 'please-change-me-at-config-initializers-devise@example.com' に設定されたままになっている。パスワードリセットや確認メールがこのアドレスから送信されるため、SPFレコード不一致によりスパム判定・メール不達が発生し、ユーザーがアカウント回復できなくなる危険がある。
🟧 Warning 📄 config/environments/production.rb
本番環境のActive Storageがローカルファイルシステムを使用
config/environments/production.rb で config.active_storage.service = :local が設定されている。Renderなどのエフェメラルインフラではデプロイ・再起動のたびにアップロードファイルが消失し、ユーザーデータの永続性が保証されない。現時点でファイルアップロード機能が存在しない場合でも、将来の機能追加時に設定変更を忘れるリスクがある。
🟧 Warning 📄 app/services/menu_generator_service.rb
MenuGeneratorServiceにエラーハンドリングが見当たらない
app/services/menu_generator_service.rb の generate_breakfast / generate_lunch_or_dinner において、MealMasterの候補が0件の場合のガード処理が読めた範囲では確認できない。seeds未投入環境やアレルギー除外により候補が枯渇した際にnil参照エラーが発生し、献立生成画面が500エラーになる危険がある。ファイルがtruncatedのため全容は未確認だが、優先して確認・対処すべき箇所である。
🟧 Warning 📄 Gemfile
公開エンドポイントにレート制限が設定されていない
Gemfileにrack-attackやthrottleに相当するgemが含まれておらず、献立生成エンドポイント(LLMまたは重いDB処理を伴う可能性がある)へのリクエストに制限がない。悪意あるユーザーによる大量リクエストでサーバーリソースが枯渇するリスク、またはLLM APIを使用している場合はAPI費用が青天井になる危険がある。
🟨 Suggestion 📄 db/seeds.rb
db/seeds.rb のマスタデータ登録が create! の逐次呼び出しで非効率
db/seeds.rb でAllergenMasterおよびMealMasterを1件ずつ create! で登録しており、レコード数が増えるとseed実行時間が線形に増加する。insert_all! を使えばバルクインサートで大幅に高速化できる。また現状のガード条件(AllergenMaster.exists?)は全件存在チェックのみのため、部分的に投入済みの場合の整合性が保証されない。
🟨 Suggestion 📄 README.md
README.mdがサービス説明に特化しており技術的セットアップ情報が不足
README.md(truncatedのため全容未確認だが読めた3000文字)はサービスコンセプト・ユーザーストーリーの記述が詳細な一方、ローカル開発環境の構築手順・環境変数一覧・テスト実行方法が確認できない。新規コントリビューターがリポジトリをcloneしてから動作確認するまでの手順が不明瞭で、オンボーディングコストが高くなる。
✅ 良い点
  • spec/requests/menus_spec.rb が「他人の献立は保存できず404になる」「ゲストユーザーは保存不可」など認可境界を網羅したリクエストスペックを持っており、認可ロジックのリグレッションを防ぐ安全網として機能している。
  • app/services/menu_generator_service.rb の SelectedMeal Struct が delegate :id, :name, :category, to: :meal_master を使い、portion_scale適用後のカロリー計算を calories メソッドに閉じ込めている。呼び出し側がMealMasterと区別なく扱えるため、カロリー調整ロジックの変更が1箇所に局所化されている。
  • Dockerfile がマルチステージビルド(build / base の2ステージ)を採用し、最終イメージからnode_modulesを削除・非rootユーザー(rails uid=1000)で実行しており、本番イメージのサイズ削減とコンテナセキュリティの基本が押さえられている。
  • spec/spec_helper.rb でSimpleCovのブランチカバレッジ(enable_coverage :branch)を有効化しており、行カバレッジだけでなく条件分岐の網羅状況も計測できる体制が整っている。

作り切ることが第一歩。改善を続けることがエンジニアリング。

🔧 リファクタ提案
  • app/services/menu_generator_service.rb の CHINESE_KEYWORDS / WESTERN_KEYWORDS などのジャンル判定正規表現をGenreClassifier等の専用クラスまたはモジュールに切り出すことで、MenuGeneratorServiceの責務をメニュー選出ロジックのみに絞り、ジャンル判定のテストを独立して書けるようにする。
  • db/seeds.rb のマスタデータ登録を insert_all!(Rails 6+)に置き換え、AllergenMaster・MealMasterそれぞれをハッシュ配列で一括投入する形にリファクタする。これによりseed実行時間の短縮と、データ定義の見通しの向上が期待できる。
  • spec/services/menu_generator_service_spec.rb でselect_one_dish? / include_soup? をallow(service).to receive(:...)でスタブしているが、これらのメソッドが将来privateになった場合にverify_partial_doublesが機能しなくなる。確率定数(ONE_DISH_SELECTION_PROBABILITY等)をコンストラクタ引数またはDIで注入できる設計にし、テストでは確率を0.0/1.0に固定することでスタブ不要にする方が堅牢。
🔒 セキュリティ注意点
  • LLMを献立生成に使用している場合(Gemfileからは確認できないが、サービス概要からAI生成が示唆される)、ユーザーのアレルギー情報や食材条件をプロンプトに埋め込む際にPrompt Injectionの対策(入力のサニタイズ・システムプロンプトとユーザー入力の明確な分離)が必要。現時点でLLM利用の有無がコード上で未確認のため、該当する場合は最優先で対処すること。
  • config/initializers/devise.rbのコメントアウト行にsecret_keyの値らしき長い16進数文字列('a0a5d6ba623c...')が残っている。コメントアウトされているため直接の脅威ではないが、誤ってコメントを外した場合やgit履歴から漏洩するリスクがある。この行はコメントごと削除し、必要であればRAILS_MASTER_KEY経由のcredentialsで管理すること。
📤 PRコメント出力

このレビューをGitHub PRコメントとして貼り付けられるMarkdown形式で出力します。