rubocop-rails-omakase

AIに効かせるガードレールとして、RuboCop設定をRails本体と比較して見直した話 こんにちは、ツクリンク株式会社でソフトウェアエンジニアをしている千葉です。 今回は、AI開発のガードレールとして正しく機能させることを目的に、ツクリンクの.rubocop.ymlをRails本体（rails/rails）のRuboCop設定と比較し、設定が異なるCopを一つずつ見直しました。 本記事では、差分のあった12Copの一覧と、「寄せる・寄せない」をどう判断したのかを代表的なCopを例に整理してご紹介します。 ✅ はじめに ツクリンクではRuboCopを運用しており、以前はClaude Code Routinesで違反を自動で解消する仕組みもご紹介しました。ただ、.rubocop.ymlの設定自体は過去の経緯で決まったものも多く、「なぜこのルールを無効にしているのか」「世の中の標準からどのくらいズレているのか」をあらためて確認する機会がありませんでした。 一方で、ツクリンクではエンジニア全員がClaude Codeを使っています。AIはプロジェクトの文脈を読み取ってコードを書くので、.rubocop.ymlは人間向けの規約というより、AIが書くコードの質を決める文法のガードレールになります。思考の方向性を示すCLAUDE.md、インターフェース定義のopenapi.ymlとあわせて、このガードレールがしっかり整備されていれば、多少ラフなプロンプトでもAIが迷わずプロジェクトに馴染むコードを書けるようになるはずだと考えています。 CIでRuboCopを実行する仕組みは既にあるため、ガードレールの仕組み自体は整っています。ただし、仕組みがあっても、ルール側が「正しい」と言える状態になっていなければ機能しません。過去の経緯で無効化されたままのCopや、pending（RuboCopに追加されたが、まだ有効化されていない状態）のまま放置されたCopが残った設定では、AIがそれに従って書いたとしても正直あまり意味がないと思っています。 そこで今回は、ガードレールの中身を正しくするために、Railsアプリとして最も参照されるであろうRails本体のRuboCop設定を基準にして、自社設定との差分を一つずつ見直して、ルール側を先に確定させることにしました。 「自社のRuboCop設定が妥当なのか分からない」「AI開発に向けてコード規約を整備したい」といった方の参考になれば幸いです。 ✅ 比較方法 今回の比較は以下の条件で行いました。 比較対象: rails/railsが有効化している99Cop 方法: 両者の.rubocop.ymlを比較して設定が異なるCopを洗い出し、rails/railsの設定をツクリンクのリポジトリに適用してrubocopを実行し、Copごとの違反件数を集計 rails/railsが有効化している99Copのうち、ツクリンクと設定が異なっていたのは12Copでした。 ✅ Rails本体と設定が異なる12Cop 比較した結果を一覧にすると以下のようになりました。Cop名は公式ドキュメントへのリンクになっています。 Cop rails/rails tsukulink 判定 Style/StringLiterals double_quotes 無効 対応不要と判断 Style/FrozenStringLiteralComment always 無効 影響が大きいため今回は見送る Layout/IndentationConsistency indented_internal_methods normal 対応不要と判断 Layout/EmptyLinesAroundAccessModifier only_before around 対応不要と判断 Layout/SpaceInsideBlockBraces 有効 無効 適用済み Layout/EndAlignment variable keyword 対応不要と判断 Style/RedundantReturn 有効 無効 適用済み Performance/SelectMap 有効 pending 適用済み Style/KeywordArgumentsMerging 有効 pending 適用済み Style/ArrayIntersect 有効 pending 適用済み Style/Semicolon AllowAsExpressionSeparator: true false 対応不要と判断 Lint/Debugger DebuggerRequires: debugのみ デフォルト 対応不要と判断 ✅ 判断の仕方（代表的な3Cop） 12Cop全てを同じ観点で見ていきましたが、ここでは判断の仕方が分かりやすい3つを取り上げます。 各Copについて、何をチェックするルールか、両者の設定、寄せた場合に何が起きるか、メリット・デメリットの順に見て、判定を出しています。 採らなかった例: Style/StringLiterals 文字列リテラルのクォートをシングル・ダブルのどちらかに統一するCopです。 rails/rails: ダブルクォートで統一します（double_quotes）。式展開やエスケープが無くても"..."を使います tsukulink: 現状、無効。シングルとダブルが混在しています（RuboCop本体のデフォルトはシングル統一） 寄せると: 違反は60221箇所あり、これを全て'...'から"..."に置換することになります。挙動は変わりませんが、ほぼ全ファイルの差分になってしまいます rails/rails（ダブル統一）: 上がNG、下がOK シングル統一（RuboCopデフォルト）: 上がOK、下がNG name = 'tsukulink' name = "tsukulink" シングル統一でも式展開・エスケープが必要なときはダブルを使う（どちらの設定でもOK） greeting = "こんにちは、#{name} さん" メリット Rails本体・omakase・Standard1といったRails周辺の主流と同じ見た目になること 後から式展開を入れるときにクォートを替える手間がなくなり、レビューでクォートの選び方を議論する必要が消えること デメリット ほぼ全ファイルに及ぶ差分でgit blameが壊れること 進行中のブランチと広範囲にコンフリクトする可能性があること Rubyコミュニティの標準（RuboCopデフォルトはシングル）とは逆で、挙動上の利点がないこと 判定 挙動上の利点がない見た目の差に対して、ほぼ全ファイルの差分とgit blameが壊れるコストが見合わないため、対応不要と判断しました。 採った例: Style/RedundantReturn メソッドの最後の式に付いた不要なreturnをチェックするCopです。Rubyは最後の式の値を自動的に返すので書かなくてもよいものです。 rails/rails: 有効。ただしreturn a, bのように複数値を返す場合は許容します（AllowMultipleReturnValues: true） tsukulink: 無効（「明示的にreturnを書くことを許容」として外している）。RuboCopデフォルトは有効です 寄せると: 違反は61箇所で、末尾のreturnを削除するだけです。挙動は変わりません。途中で抜けるガード節のreturnは対象外です NG def display_name return name.presence || "名称未設定" end OK def display_name name.presence || "名称未設定" end メリット Rubyの慣用に沿い、RuboCopデフォルト・Rails本体・omakaseのすべてと一致すること 件数が少なく、Safe autocorrectで完了すること デメリット 「末尾でもreturnを書いて返り値であることを明示したい」という書き方ができなくなること（ツクリンクが無効にしている理由）。ただし実害はありません 判定 RuboCopデフォルトとも一致しており、件数が少なくSafe autocorrectだけで完了するため、適用しました。 保留した例: Style/FrozenStringLiteralComment ファイル先頭に# frozen_string_literal: trueのマジックコメントがあるかをチェックするCopです。このコメントがあると、そのファイル内の文字列リテラルは全て凍結（変更不可）になります。 rails/rails: 全ファイルに必須です（always） tsukulink: 無効。コメントがあるのは117ファイルのみです 寄せると: 違反は2944ファイルあり、それぞれ先頭に1行追加することになります。自動修正はUnsafeで、文字列を破壊的に変更しているコード（<<やgsub!など）があるとFrozenErrorで落ちるようになります NG（ファイル先頭にコメントがない） class Company < ApplicationRecord OK frozen_string_literal: true class Company < ApplicationRecord コメントを付けると壊れるコードの例 message = "こんにちは" message << "世界" # FrozenError message = +"こんにちは" # 先頭に + を付けるか String.new で回避 メリット 同じリテラルが評価されるたびに新しいStringオブジェクトを作らなくなり、メモリ負荷が下がること 意図しない文字列の破壊的変更（定数やデフォルト引数の汚染）をエラーで捕まえられること Ruby 3.4は凍結されていないリテラルの変更に警告を出すようになっており、将来のデフォルトに先回りできること デメリット 実行時になって初めてFrozenErrorが出る可能性があり、テストで網羅されていない経路では本番障害になり得ること 全テストの実行とRuby 3.4の警告（-W:deprecated）による事前確認が必要なこと 判定 対応したいものの、自動修正がUnsafeで本番障害になり得ます。全テストの実行とRuby 3.4の警告確認を含めて別途取り組む必要があるため、今回は見送りました。 ✅ 対応方針まとめ 12Copの判定を整理すると以下になります。 判定 Cop 適用済み（Safe autocorrect or 設定変更のみ） Layout/SpaceInsideBlockBraces、Style/RedundantReturn、Style/KeywordArgumentsMerging、Style/ArrayIntersect 適用済み（手動修正） Performance/SelectMap 影響が大きいため今回は見送る Style/FrozenStringLiteralComment 対応不要と判断 Style/StringLiterals、Layout/IndentationConsistency、Layout/EmptyLinesAroundAccessModifier、Layout/EndAlignment、Style/Semicolon、Lint/Debugger 「対応不要」と判断したCopに共通するのは、Rails本体と揃えても自社にとっての実利がないか、差分のコストに見合わないという点です。Rails本体はフレームワークのソースコードであり、アプリケーションコードと同じスタイルが最適とは限らないため、「Rails本体がこうしているから」だけを理由に寄せるのは避けました。 一方で適用したCopは、RuboCopデフォルトで有効なもの（Layout/SpaceInsideBlockBraces、Style/RedundantReturn）か、pendingとして次期デフォルトになることが決まっているもの（Performance/SelectMap、Style/KeywordArgumentsMerging、Style/ArrayIntersect）で、いずれも件数が少なくSafe autocorrectで完了する、あるいはパフォーマンス上の実利があるものです。 ✅ まとめ Rails本体のRuboCop設定を基準に自社設定を比較してみたところ、99Copのうち差分があったのは12Copで、そのうち実際に寄せるべきと判断したのは6Copでした（うち5Copを適用し、1Copは対応を見送り）。 12Copを一つずつ見ていくと、採るべきものと採らなくてよいものはかなりはっきり分かれました。有名なプロジェクトの設定であっても、自社に合うかどうかは一つずつ確かめる必要があると改めて認識しました。 RuboCopの設定を見直したいと考えている方や、AI開発に向けてコード規約を整備したいと考えている方の判断材料になれば幸いです。 脚注 omakaseはRailsチームが提供するアプリケーション向けのRuboCop設定、Standardはコミュニティ主導のRubyスタイルガイドです。いずれもRails本体の設定とは一部異なるルールを採用しており、本記事では「Rails周辺で広く使われる標準」の参考として言及しています。 ↩︎