Rails初心者向け：マイグレーションにおけるchangeメソッドとup/downメソッドの使い分け

目次

1. はじめに
2. changeメソッドとは？
   • 具体例：カラム追加のケース
3. up/downメソッドとは？
   • 同じ処理をup/downで書いた場合
4. いつchangeメソッドを使うべきか？
5. いつup/downメソッドを使うべきか？
   • 頻出！可逆的でない操作の具体例
6. ベストプラクティス
7. まとめ
8. 参考

はじめに

Railsでデータベースの構造を変更する際、マイグレーションファイルを使用します。マイグレーションには主に2つの書き方があります：

1. changeメソッドを使用する方法
2. up/downメソッドを使用する方法

この記事では、それぞれの特徴と使い分けについて、具体例を交えて説明します。

changeメソッドとは？

changeメソッドは、Rails 3.1から導入された比較的新しい書き方です。このメソッドの特徴は、マイグレーションの実行（up）とロールバック（down）を自動的に処理してくれることです。

具体例：カラム追加のケース

class AddColumnDispensedGroupIdToPrescriptionHeaders < ActiveRecord::Migration[7.0]
  def change
    add_column :prescription_headers, :dispensed_group_id, :string, after: :started_audit_at
  end
end

このコードでは： - マイグレーション実行時（up）：指定されたカラムが追加されます - ロールバック時（down）：自動的にカラムが削除されます

up/downメソッドとは？

upとdownメソッドは、マイグレーションの実行とロールバックの処理を明示的に記述する方法です。

同じ処理をup/downで書いた場合

class AddColumnDispensedGroupIdToPrescriptionHeaders < ActiveRecord::Migration[7.0]
  def up
    add_column :prescription_headers, :dispensed_group_id, :string, after: :started_audit_at
  end

  def down
    remove_column :prescription_headers, :dispensed_group_id
  end
end

いつchangeメソッドを使うべきか？

以下のような単純な操作の場合、changeメソッドを使用することをお勧めします：

✅ changeメソッドで対応可能な操作： - カラムの追加/削除 - テーブルの作成/削除 - インデックスの追加/削除 - 参照キーの追加/削除

これらの操作は「可逆的」で、Railsが自動的にロールバック方法を理解できます。

いつup/downメソッドを使うべきか？

以下のような複雑な操作の場合は、up/downメソッドを使用する必要があります：

⚠️ up/downメソッドが必要なケース： 1. データの変更を含む操作 ```ruby def upå User.where(role: nil).update_all(role: 'member') end

def down User.where(role: 'member').update_all(role: nil) end ```

1. 複雑なテーブル構造の変更 ruby def up rename_column :users, :name, :first_name add_column :users, :last_name, :string User.all.each do |user| name_parts = user.first_name.split(' ') user.update( first_name: name_parts[0], last_name: name_parts[1] ) end end

2. 可逆的でない操作を含む場合

頻出！可逆的でない操作の具体例

ケース1: カラムの削除

# ❌ Bad: changeメソッドの場合
def change
  remove_column :users, :birth_date
end

# ✅ Good: up/downメソッドの場合
def up
  remove_column :users, :birth_date
end

def down
  add_column :users, :birth_date, :date  # データ型の指定が必要！
end

なぜup/downが必要？ - データ型の変更によってデータが失われる可能性がある - ロールバック時の挙動を明確に制御したい

ベストプラクティス

1. 基本的にはchangeメソッドを使用する
2. 複雑な変更や、データの更新が必要な場合はup/downメソッドを使用する
3. downメソッドを書く場合は、必ずupの逆の操作を正確に記述する
4. カラムの削除や型の変更時は特に注意が必要

まとめ

• 単純なスキーマ変更 → changeメソッド
• 複雑な変更やデータ操作を含む場合 → up/downメソッド
• カラムの削除や型の変更は要注意！

この使い分けを覚えておくことで、より保守性の高いマイグレーションを書くことができます。

参考

• Active Record マイグレーション - Railsガイド

メソッドの配置で読みやすさが変わる！Rubyクラスの整理術

こんにちは！今回は、クラス内のメソッドをどのように配置すると読みやすくなるのか、実践的なガイドをお届けします。

なぜメソッドの配置順序が重要なの？

メソッドの配置順序は、コードの「物語」を語るようなものです： - 読み手がコードの流れを理解しやすくなる - メンテナンスがしやすくなる - 新しい機能を追加する場所が明確になる

基本的な配置順序

1. クラス構成要素

class SampleClass
  # 1. 定数
  SOME_CONSTANT = 'value'

  # 2. モジュールのインクルード
  include SomeModule
  extend OtherModule

  # 3. 属性
  attr_accessor :name
  attr_reader :age

  # 4. バリデーション
  validates :name, presence: true

  # 5. コンストラクタ
  def initialize(name)
    @name = name
  end

  # 6. 以降のメソッド...
end

2. メソッドの配置順序

class SampleService
  # 1. パブリックメソッド（メインロジック）
  def execute
    validate_input
    process_data
    generate_result
  end

  private

  # 2. 主要な判定処理
  def valid_input?
    # 入力チェックロジック
  end

  # 3. データ取得処理
  def fetch_data
    # データ取得ロジック
  end

  # 4. 計算・加工処理
  def calculate_total
    # 計算ロジック
  end

  # 5. パラメータ関連
  def build_params
    # パラメータ構築ロジック
  end

  # 6. ユーティリティメソッド
  def format_result(data)
    # フォーマット処理
  end

  # 7. キャッシュ/メモ化メソッド
  def cached_data
    @cached_data ||= fetch_data
  end
end

実践的な配置のポイント

1. 依存関係を考慮する

class OrderProcessor
  def process_order
    validate_order    # 1. 検証
    calculate_total   # 2. 計算
    update_inventory  # 3. 更新
  end

  private

  def validate_order
    # 先に必要な処理
  end

  def calculate_total
    # validate_orderに依存
  end

  def update_inventory
    # calculate_totalに依存
  end
end

2. 関連する処理をグループ化

class UserService
  # 認証関連
  def authenticate
    validate_credentials
    generate_token
  end

  private

  def validate_credentials
    # 認証処理
  end

  def generate_token
    # トークン生成
  end

  # データ処理関連
  def process_user_data
    format_data
    save_data
  end

  private

  def format_data
    # データフォーマット
  end

  def save_data
    # データ保存
  end
end

:star: おすすめの配置原則

1. 上から下への流れを意識

   • 初期化・設定
   • メインロジック
   • 補助的な処理
   • ユーティリティ

2. 関連する処理は近くに

   • 同じ機能に関するメソッド
   • 同じデータを扱うメソッド

3. 抽象度でグループ化

   • 高レベルな処理を上部に
   • 詳細な実装を下部に

4. 可読性を高める工夫

class ComplexService
  # ===== メインロジック =====
  def execute
    # メイン処理
  end

  private

  # ===== データ処理 =====
  def process_data
    # データ処理
  end

  # ===== ユーティリティ =====
  def format_output
    # フォーマット処理
  end
end

実践的なTips！

1. コメントを効果的に使う

class ApiService
  # Public API Methods
  def fetch_data
    # API呼び出し
  end

  private

  # Data Processing
  def process_response
    # レスポンス処理
  end

  # Utility Methods
  def format_response
    # フォーマット処理
  end
end

1. メソッドの長さにも注意

# 👍 Good: 関連する小さなメソッド
def process_order
  validate_order
  calculate_total
  update_inventory
end

def validate_order
  # 10-15行程度の検証ロジック
end

# 👎 Bad: 長すぎるメソッド
def process_everything
  # 100行を超えるような処理...
end

まとめ

メソッドの配置は「コードの物語」を語るようなものです： 1. 論理的な流れを持たせる 2. 関連する処理をグループ化 3. 依存関係を考慮 4. 可読性を重視

これらの原則を意識することで、より読みやすく保守しやすいコードになります！

よくある疑問

Q: プライベートメソッドは必ず下に書くべき？

A: 通常はその方が読みやすいですが、関連するメソッドを近くに置くことを優先しても良いです。

Q: 長いメソッドはどこに置く？

A: 長いメソッドは分割を検討しましょう。分割できない場合は、そのメソッドの主要な処理が属するグループに配置します。 また分割の目安は私は 改行抜きで10行以上程度あり、意味のあるまとまりに分割できそうな時は分割しています。

コードの整理は、チームの合意を得ながら進めることが重要です。これらのガイドラインを参考に、プロジェクトに合った整理方法を見つけてください！

実践！マジックナンバー、定数化すべき？すべきでない？

実践！マジックナンバー、定数化すべき？すべきでない？

こんにちは！今回は現場でよく議論になる「マジックナンバーを定数化すべきかどうか」について、実例を交えながら解説していきます。

マジックナンバーって何？

マジックナンバーとは、コード内で直接使用される数値定数のことです。例えば：

def calculate_shipping_fee(amount)
  return 0 if amount >= 3000  # ← この3000がマジックナンバー
  500  # ← この500もマジックナンバー
end

定数化した方が良い場合

1. ビジネスロジックを表す数値

class Order
  # 👍 Good
  FREE_SHIPPING_THRESHOLD = 3000
  BASE_SHIPPING_FEE = 500

  def calculate_shipping_fee(amount)
    return 0 if amount >= FREE_SHIPPING_THRESHOLD
    BASE_SHIPPING_FEE
  end
end

2. 設定値やフラグ

class User
  # 👍 Good
  MAX_LOGIN_ATTEMPTS = 3
  PASSWORD_MIN_LENGTH = 8
  DEFAULT_PAGINATION_PER_PAGE = 20

  def validate_password(password)
    errors.add(:password, "must be at least #{PASSWORD_MIN_LENGTH} characters") if password.length < PASSWORD_MIN_LENGTH
  end
end

3. ステータスや状態を表す数値

class Task
  # 👍 Good
  STATUS_PENDING = 0
  STATUS_IN_PROGRESS = 1
  STATUS_COMPLETED = 2

  def start_task
    update(status: STATUS_IN_PROGRESS)
  end
end

定数化が不要な場合

1. 数学的な計算で使う一般的な数値

# 👍 Good：数学的な意味が明確
def calculate_diameter(radius)
  radius * 2  # 円の直径を求める
end

# 👍 Good：配列の中間点
def find_middle_element(array)
  array[array.length / 2]
end

2. インデックスの調整

# 👍 Good：意図が明確な単純な計算
def next_element(array, current_index)
  array[current_index + 1]
end

3. 明白な初期値

# 👍 Good：一般的な初期値
def initialize
  @count = 0
  @sum = 0
end

実践的な例：医薬品監査システムの場合

class PharmaceuticalAudit
  # 👍 定数化すべき：ビジネスロジックの一部
  INITIAL_AUDIT_COUNT = 1
  MAX_DAILY_AUDITS = 3
  ERROR_THRESHOLD = 0.05

  def audit_required?(error_rate)
    error_rate > ERROR_THRESHOLD
  end

  # 👎 定数化不要：単純な計算
  def calculate_error_rate(errors, total)
    errors.to_f / total
  end
end

判断のための3つのポイント

1. 変更の可能性

• 📈 高い: 仕様変更で値が変わりそう → 定数化
• 📉 低い: 普遍的な値 → そのまま使用OK

2. 意味の明確さ

• 🤔 不明確: 数値の意味が分かりにくい → 定数化
• 👀 明確: 文脈から意味が明らか → そのまま使用OK

3. 再利用性

• 🔄 複数箇所: 同じ値を何度も使用 → 定数化
• 1️⃣ 1箇所のみ: 使用箇所が限定的 → ケースバイケース

まとめ：実践的な判断基準

以下のような場合は定数化を検討しましょう：

1. 💼 ビジネスルールを表す値

   • 最小注文金額
   • 割引率
   • ステータスコード

2. ⚙️ 設定値として使われる数値

   • 最大試行回数
   • タイムアウト時間
   • ページネーションの件数

3. 🔄 複数箇所で使用される値

   • エラーコード
   • デフォルト値
   • 共通の制限値

定数化が不要なケース：

1. ➗ 一般的な計算で使う数値

   • 半分にする（/2）
   • 2倍にする（*2）
   • インデックス調整（+1, -1）

2. 0️⃣ プログラミング上の一般的な初期値

   • カウンター初期化（= 0）
   • 配列の開始インデックス（[0]）

実践的なTips！

1. 命名は具体的に

# 👎 Bad
MAX_VALUE = 3000

# 👍 Good
FREE_SHIPPING_THRESHOLD = 3000

1. グループ化して管理

# 👍 Good
module OrderConstants
  SHIPPING = {
    FREE_THRESHOLD: 3000,
    BASE_FEE: 500
  }.freeze
end

1. コメントを活用

# 👍 Good
# 2024年4月の消費税改定に対応
TAX_RATE = 0.1

マジックナンバーの扱いは、コードの品質とメンテナンス性に大きく影響します。ぜひこの記事を参考に、プロジェクトに適した判断をしていってください！

質問やコメントがありましたら、ぜひ教えてください！一緒により良いコードを目指しましょう！

現場で使える！コミットメッセージの書き方ガイド

こんにちは！今回は、日々の開発で避けて通れない「コミットメッセージ」について、実践的なガイドをお届けします。特に新人エンジニアの方々に向けて、分かりやすく解説していきます。

なぜコミットメッセージの先頭に「type:」をつけるの？

「fix:」や「refactor:」といったprefixをよく見かけると思います。これには重要な理由があります：

1. 変更の種類が一目で分かる

   • チームメンバーが変更内容を素早く理解できる
   • コードレビューの効率が上がる

2. コミット履歴の検索が楽になる

   • 「すべてのリファクタリング」を見たい時は「refactor:」で検索
   • バグ修正を探す時は「fix:」で検索

3. 自動化がしやすい

   • CIツールやバージョニングツールが種類を判別しやすい
   • リリースノートの自動生成にも活用できる

実践！使いやすいコミットメッセージ集

1. リファクタリング系

refactor: Improve code readability
（コードの可読性を改善）

refactor: Simplify calculation logic
（計算ロジックをシンプル化）

refactor: Extract duplicate code
（重複コードを抽出）

refactor: Optimize database queries
（DBクエリを最適化）

2. レビュー対応系

fix: Address code review feedback
（コードレビューの指摘に対応）

fix: Update based on review comments
（レビューコメントに基づいて更新）

style: Apply coding standards from review
（レビューで指摘されたコーディング規約を適用）

3. その他よく使う系

feat: Add user authentication
（ユーザー認証を追加）

fix: Resolve calculation error
（計算エラーを解決）

docs: Update README
（READMEを更新）

test: Add unit tests for user model
（ユーザーモデルのユニットテストを追加）

主なtype（接頭辞）の使い分け

type	使う時	例
feat:	新機能の追加	feat: Add email notification
fix:	バグ修正・レビュー対応	fix: Correct total calculation
refactor:	リファクタリング	refactor: Simplify loop logic
style:	コードスタイルの修正	style: Fix indentation
docs:	ドキュメント関連	docs: Update API guide
test:	テストの追加・修正	test: Add login test cases
chore:	その他の修正	chore: Update dependencies

実践的なTips！

1. 具体的に書く Bad: fix: Fix bug Good: fix: Fix total calculation in shopping cart

2. 検索しやすく Bad: refactor: Improve code Good: refactor: Optimize user search query performance

3. チーム規約に従う

   • チームによって好まれるスタイルは異なります
   • 最初は既存のコミット履歴を参考にするのがおすすめ！

まとめ

コミットメッセージは「将来の自分」や「チームメンバー」へのメッセージです。 - 変更内容が分かりやすい - 検索しやすい - チーム全体の効率が上がる

これらを意識して、素晴らしいコミットメッセージを書いていきましょう！

質問やコメントがありましたら、ぜひ教えてくださいね。一緒により良いコード管理を目指しましょう！

Rubyのeach_with_objectで集計処理をスッキリ書こう

みなさん、Rubyで集計処理を書くときってどうしていますか？ 今回はeach_with_objectを使って、コードをよりシンプルに書く方法を紹介します！

よくある集計処理の例

例えば、以下のような集計処理があったとします：

def calculate_total_input_quantity
  return if @pharmaceutical_quantities.blank?

  @total_input_quantities = {}  # 中間の集計用オブジェクト

  @pharmaceutical_quantities.each do |pq|
    yj_code = pq.yj_code
    @total_input_quantities[yj_code] ||= BigDecimal(0, 2)
    @total_input_quantities[yj_code] += BigDecimal(pq.total_quantity || '0', 2)
  end
end

このコードには以下のような課題があります：

• 中間変数（ハッシュ）の初期化が必要
• nilチェックのための条件分岐が多い
• コードが少し冗長

each_with_objectを使ってリファクタリング

これをeach_with_objectを使って書き直すと、こんなにスッキリします：

def calculate_total_input_quantity
  return if @pharmaceutical_quantities.blank?

  @total_input_quantities = @pharmaceutical_quantities.each_with_object(Hash.new(0)) do |pq, totals|
    totals[pq.yj_code] += pq.total_quantity
  end
end

何が良くなった？

1. コードが短くなった！
2. 中間変数の初期化が不要になった
3. Hash.new(0)で自動的にデフォルト値が設定される
4. 可読性が上がった

each_with_objectの導入ポイント

コードを見ていて、以下のようなパターンを見つけたら、each_with_objectの導入チャンスです！

1. 空のオブジェクトの初期化がある

# Before: これは導入のサイン！
result = {}
items.each do |item|
  # 結果をresultに蓄積
end

# After: each_with_objectで簡潔に
items.each_with_object({}) do |item, result|
  # 結果をresultに蓄積
end

2. ||= で初期値を設定している

# Before: この初期値設定パターンを見たら！
result = {}
items.each do |item|
  result[item.category] ||= []
  result[item.category] << item
end

# After: Hash.new + each_with_objectで簡潔に
items.each_with_object(Hash.new { |h, k| h[k] = [] }) do |item, result|
  result[item.category] << item
end

3. 複数の値を同時に更新している

# Before: 複数の集計があったら！
stats = { total: 0, count: 0 }
items.each do |item|
  stats[:total] += item.price
  stats[:count] += 1
end

# After: each_with_objectでスッキリ
items.each_with_object(total: 0, count: 0) do |item, stats|
  stats[:total] += item.price
  stats[:count] += 1
end

4. ネストされた構造を作っている

# Before: ネストされた初期化があったら！
result = {}
data.each do |record|
  result[record.year] ||= {}
  result[record.year][record.month] ||= 0
  result[record.year][record.month] += record.value
end

# After: each_with_objectですっきり
data.each_with_object(Hash.new { |h, k| h[k] = Hash.new(0) }) do |record, result|
  result[record.year][record.month] += record.value
end

でも、これらの場合は他のメソッドを使おう

単純な処理の場合は、each_with_objectを使わない方がスッキリ書けます：

単純な変換なら map

# ✗ これは冗長
users.each_with_object([]) do |user, names|
  names << user.name
end

# ○ これがスッキリ！
users.map(&:name)

単純な集計なら sum や reduce

# ✗ これは冗長
numbers.each_with_object(0) do |num, sum|
  sum += num
end

# ○ これがスッキリ！
numbers.sum

まとめ

each_with_objectは、中間の集計用オブジェクトが必要な場合に特に威力を発揮します。 具体的には以下のようなケースです：

• 空のハッシュや配列の初期化がある
• デフォルト値の設定が必要（||=を使っている）
• 複数の値を同時に更新している
• ネストされた構造の初期化がある

ただし、単純な変換や集計にはmapやsumなどの専用メソッドを使う方が適切です。 状況に応じて適切なメソッドを選ぶことで、メンテナンスしやすいコードが書けますよ！

コミットメッセージの先頭タグ一覧：featからchoreまでの活用法

こんにちは！この記事では、コミットメッセージの先頭につける「タグ」について詳しく解説します。featやfixといったタグを使うことで、コミットの意図を明確に示すことができ、プロジェクトの管理やコードの追跡が容易になります。

---

なぜコミットメッセージにタグをつけるのか？

コミットメッセージにタグをつけることで、以下のメリットが得られます。

1. 変更の目的が明確になる
   コミットメッセージを見ただけで、そのコミットがバグ修正なのか新機能追加なのかが一目でわかります。

2. 履歴の管理が簡単になる
   タグ付きのメッセージは後から検索やフィルタリングがしやすくなります。

3. チーム内のコミュニケーションが向上
   コミットの内容が明確になることで、開発チーム内でのやり取りがスムーズになります。

---

コミットメッセージのタグ一覧

ここでは、よく使用されるコミットタグの一覧とその用途について紹介します。これらのタグは、プロジェクトのコミットメッセージの標準として設定するとよいでしょう。

feat - 新機能の追加

• 概要：featは、プロジェクトに新しい機能を追加する際に使用します。
• 使用例： feat: ユーザー登録機能を追加

fix - バグ修正

• 概要：fixは、既存の機能に関するバグを修正する際に使用します。feat同様、リリースノートなどにも取り込まれやすいタグです。
• 使用例： fix: ログイン画面で発生するエラーを修正

refactor - リファクタリング

• 概要：refactorは、機能の変更やバグ修正を伴わないコードの改善に使用します。パフォーマンス向上やコードの見通しを良くするための変更を示します。
• 使用例： refactor: API呼び出しの処理をリファクタリング

docs - ドキュメントの変更

• 概要：docsは、READMEやAPIドキュメントの変更、コメントの追加など、ドキュメントに関連する変更に使用します。
• 使用例： docs: インストール手順を更新

style - コードのスタイル修正

• 概要：styleは、コードの動作に影響を与えないスタイルの変更に使用します。インデント調整やスペース、セミコロンの追加などが該当します。
• 使用例： style: インデントを2スペースに変更

test - テストの追加や修正

• 概要：testは、新しいテストの追加や既存のテストの修正に使用します。テストコードのみに関する変更を示します。
• 使用例： test: ユーザーログイン機能のテストを追加

chore - その他の雑務

• 概要：choreは、ビルドタスクやパッケージのアップデート、プロジェクトの設定変更など、プロジェクトに影響を与えない雑務に使用します。
• 使用例： chore: 依存パッケージを最新バージョンに更新

perf - パフォーマンス向上

• 概要：perfは、パフォーマンスの改善に関連する変更に使用します。パフォーマンス向上のためのコードの最適化が該当します。
• 使用例： perf: クエリのパフォーマンスを改善

---

追加で使える便利なタグ

ci - 継続的インテグレーションの設定

• 概要：ciは、CI/CDパイプラインの設定変更に使用します。
• 使用例： ci: GitHub Actionsの設定を追加

build - ビルド関連の設定や変更

• 概要：buildは、ビルドシステムや外部依存関係に関連する変更に使用します。
• 使用例： build: Webpackの設定を修正

revert - 変更の取り消し

• 概要：revertは、以前のコミットを取り消す際に使用します。変更内容の説明に元のコミットIDを記載することが一般的です。
• 使用例： revert: "feat: 新しいダッシュボードの追加"

---

タグの使い方の例

コミットメッセージの書き方は、チームで統一するとさらに効果的です。ここでは、いくつかの使用例を紹介します。

1. 新機能の追加： feat: プロフィール画像のアップロード機能を追加

2. バグ修正： fix: パスワードリセット機能が動作しない不具合を修正

3. パフォーマンス向上： perf: データベースクエリのパフォーマンスを最適化

4. スタイル修正： style: コードフォーマットを統一

---

まとめ

コミットメッセージに適切なタグをつけることは、コードの管理や後からの追跡を簡単にするだけでなく、チーム内のコミュニケーションをスムーズにし、開発効率を向上させます。プロジェクトのルールに合わせて、タグを効果的に活用しましょう。

CodeRabbit GitHubコマンド一覧：レビューから管理まで便利なコマンド集

こんにちは！この記事では、GitHubで便利に使えるCodeRabbitのコマンド一覧を紹介します。コードレビューやコード改善、分析などさまざまな場面で活用できるコマンドが用意されているので、ぜひ使いこなして開発効率を高めましょう！

---

よく使用するコマンド

レビュー基本コマンド

CodeRabbitを使って、基本的なコードレビューや解説、テストに関連する指示が行えます。

• @coderabbitai review - コードレビューを依頼
• @coderabbitai explain - コードの解説を依頼
• @coderabbitai suggest - コード改善案の提案を依頼
• @coderabbitai test - テストのアドバイスを依頼
• @coderabbitai security - セキュリティに関するレビューを依頼

コード改善コマンド

コードのクオリティ向上やドキュメンテーションに役立つコマンドです。

• @coderabbitai fix - コードの修正を依頼
• @coderabbitai improve - 改善点の提案を依頼
• @coderabbitai doc - ドキュメント生成を依頼
• @coderabbitai comment - コードにコメント追加を依頼

---

その他の便利なコマンド

分析コマンド

コードの複雑さやパフォーマンスの観点から、さらに深い分析が可能です。

• @coderabbitai complexity - コードの複雑度を分析
• @coderabbitai coverage - テストカバレッジを分析
• @coderabbitai performance - パフォーマンスについてのアドバイスを依頼
• @coderabbitai best-practices - ベストプラクティスに沿っているか確認

コミュニケーションコマンド

チームやレビュアーとのコミュニケーションをサポートします。

• @coderabbitai tldr - 要約を依頼
• @coderabbitai context - 背景や文脈の説明を依頼
• @coderabbitai clarify - 不明点の確認や詳細説明を依頼
• @coderabbitai summarize - 内容を簡潔にまとめる

管理コマンド

CodeRabbitの設定や情報確認に使用できるコマンドです。

• @coderabbitai config - 設定を変更
• @coderabbitai ignore - 無視する項目を設定
• @coderabbitai stats - 統計情報を取得
• @coderabbitai help - コマンド一覧やサポート情報を表示

---

使用例

ここでは、CodeRabbitのコマンドを活用した具体的な使用例を紹介します。

1. 基本的なレビュー依頼 markdown @coderabbitai review

2. セキュリティ重視のレビュー markdown @coderabbitai review --focus=security

3. 特定ファイルの説明をリクエスト markdown @coderabbitai explain src/main.js

4. 改善案の提案をリクエスト markdown @coderabbitai suggest

---

注意点

• コマンドは必ずPRのコメントとして投稿してください。
• @coderabbitai は必ず先頭につけてください。
• 大文字小文字は区別されません。
• レスポンスが返ってくるまで少し時間がかかる場合があります。
• プロジェクトの設定により使用できるコマンドが制限されている場合もあります。

---

CodeRabbitのコマンドを活用することで、開発スピードやレビューの質が向上し、効率的なコラボレーションが可能になります。