スタイル統一: 使用 - >使う、利用、用いるなど

guides/source/ja/2_3_release_notes.md

@@ -144,7 +144,7 @@ Customer.find_in_batches(:conditions => {:active => true}) do |customer_group|
 end
 ```
 
-`find_in_batches` には、ほとんどの `find` オプションを渡せます。ただし、返すレコードの順序を指定することや (常に主キーの昇順で返される整数値でなければなりません)、 `:limit` オプションを使うことはできません。代わりに、 `:batch_size` オプション (デフォルトは 1000件) を使用して、各バッチで返されるレコードの数を設定できます。
+`find_in_batches`には、ほとんどの`find`オプションを渡せます。ただし、返すレコードの順序を指定することや（常に主キーの昇順で返される整数値でなければなりません）、 `:limit`オプションを使うことはできません。代わりに、 `:batch_size`オプション（デフォルトは 1000件）を使って、各バッチで返されるレコードの数を設定できます。
 
 新しい `find_each` メソッドは、個々のレコードを返す `find_in_batches` のラッパーで、検索自体はバッチ処理で行われます (デフォルトでは 1000 件) 。
 
@@ -507,7 +507,7 @@ Active Supportでも、`Object#try`などいくつかの興味深い変更が行
 
 ### XMLminiのパーサーが差し替え可能に
 
-Active SupportのXML解析サポートで、パーサーを別のものに差し替えられるようになり、柔軟性が増しました。デフォルトでは、標準的なREXMLの実装を使用しますが、適切なgemがインストールされていれば、高速なLibXMLやNokogiriの実装を自分のアプリケーションに簡単に指定できます。
+Active SupportのXML解析サポートで、パーサーを別のものに差し替えられるようになり、柔軟性が増しました。デフォルトでは、標準的なREXMLの実装を使いますが、適切なgemがインストールされていれば、高速なLibXMLやNokogiriの実装を自分のアプリケーションに簡単に指定できます。
 
 
 ```ruby

guides/source/ja/5_1_release_notes.md

@@ -77,7 +77,7 @@ mailer用クラス内の全メソッドで利用する共通のパラメータ
 
   def account_invitation
     mail subject: "#{@inviter.name} invited you to their Basecamp (#{@account.name})"
-  end 
+  end
 end
 
 InvitationsMailer.with(inviter: person_a, invitee: person_b)
@@ -118,11 +118,11 @@ resolve("Basket") { [:basket] }
 ```ruby
  direct :commentable do |model|
   [ model, anchor: model.dom_id ]
-end 
+end
 
 direct :main do
   { controller: 'pages', action: 'index', subdomain: 'www' }
-end 
+end
 ```
 
 ### form_forとform_tagのform_withへの統合
@@ -424,16 +424,16 @@ Active Record
 
 ### 非推奨
 
-*   `error_on_ignored_order_or_limit`フラグを非推奨化: 今後は`error_on_ignored_order`を使用
+*   `error_on_ignored_order_or_limit`フラグを非推奨化: 今後は`error_on_ignored_order`を使うこと
     ([Commit](https://github.com/rails/rails/commit/451437c6f57e66cc7586ec966e530493927098c7))
 
-*   `sanitize_conditions`を非推奨化: 今後は`sanitize_sql`を使用
+*   `sanitize_conditions`を非推奨化: 今後は`sanitize_sql`を使うこと
     ([Pull Request](https://github.com/rails/rails/pull/25999))
 
 *   接続アダプタのDeprecated `supports_migrations?`を非推奨化
     ([Pull Request](https://github.com/rails/rails/pull/28172))
 
-*   `Migrator.schema_migrations_table_name`を非推奨化: 今後は,`SchemaMigration.table_name`を使用
+*   `Migrator.schema_migrations_table_name`を非推奨化: 今後は,`SchemaMigration.table_name`を使うこと
     ([Pull Request](https://github.com/rails/rails/pull/28351))
 
 *   引用符追加や型変換で使われていた`#quoted_id`を非推奨化
@@ -534,7 +534,7 @@ Active Support
 
 ### 非推奨
 
-*   トップレベルの`HashWithIndifferentAccess`クラスをやや弱めに非推奨化: 今後は`ActiveSupport::HashWithIndifferentAccess`クラスを使用
+*   トップレベルの`HashWithIndifferentAccess`クラスをやや弱めに非推奨化: 今後は`ActiveSupport::HashWithIndifferentAccess`クラスを使うこと
     ([Pull Request](https://github.com/rails/rails/pull/28157))
 
 *   `set_callback`や`skip_callback`で`:if`条件オプションや`:unless`条件オプションに文字列を渡すことを非推奨化

guides/source/ja/action_cable_overview.md

@@ -92,7 +92,7 @@ end
 
 次に、新しいコネクションを試行すると、このcookieがコネクションのインスタンスに自動で送信され、`current_user`の設定に使われます。現在の同じユーザーによるコネクションが識別されれば、以後そのユーザーが開いているすべてのコネクションを取得することも、ユーザーが削除されたり認証できない場合に切断することも可能になります。
 
-認証にセッションを含む場合、セッションにcookieストアを使用し、セッションcookieの`_session`とユーザーIDのキーとなる`user_id`を使用するアプローチが使えます。
+認証にセッションを含む場合、セッションにcookieストアを使い、セッションcookieの`_session`とユーザーIDのキーとなる`user_id`を使う方法が利用可能になります。
 
 ```ruby
 verified_user = User.find_by(id: cookies.encrypted["_session"]["user_id"])
@@ -684,7 +684,7 @@ WARNING: セキュリティ上の影響を完全に理解するまでは、Redis
 
 PostgreSQLアダプタはActive Recordコネクションプールを利用するため、アプリケーションのデータベース設定ファイル（`config/database.yml`）でコネクションを設定します。これについては将来変更される可能性があります（[#27214](https://github.com/rails/rails/issues/27214)）。
 
-NOTE: PostgreSQLでは、`NOTIFY`（通知を送信するために内部的に使用されるコマンド）に[8000バイトの制限](https://www.postgresql.org/docs/current/sql-notify.html)があり、大きなペイロードを処理するときに制約となる可能性があります。
+NOTE: PostgreSQLでは、`NOTIFY`（通知を送信するために内部的に使われるコマンド）に[8000バイトの制限](https://www.postgresql.org/docs/current/sql-notify.html)があり、大きなペイロードを処理するときに制約となる可能性があります。
 
 ### 許可されたリクエスト送信元
 

guides/source/ja/active_model_basics.md

@@ -1191,7 +1191,7 @@ class Person
 end
 ```
 
-`human_attribute_name`メソッドを使用すると、属性名を人間が読みやすい形式に変換できます。人間用のフォーマットはロケールファイルで定義されます。
+`human_attribute_name`メソッドを使えば、属性名を人間が読みやすい形式に変換できます。人間用のフォーマットはロケールファイルで定義されます。
 
 ```yaml
 # config/locales/app.pt-BR.yml

guides/source/ja/active_record_postgresql.md

@@ -329,7 +329,7 @@ irb> article.status = "deleted"
 ArgumentError: 'deleted' is not a valid status
 ```
 
-enumの名前をリネームするには、`rename_enum`を利用して、モデルの使用方法も更新します。
+`rename_enum`を使うとenumの名前をリネームできます。リネーム後にモデルでのenumの利用方法も更新する必要があります。
 
 ```ruby
 # db/migrate/20150718144917_rename_article_status.rb

guides/source/ja/active_record_querying.md

@@ -717,15 +717,15 @@ Book.where("created_at >= :start_date AND created_at <= :end_date",
 
 #### 条件で`LIKE`を使う
 
-引数はSQLインジェクションを防ぐために自動的にエスケープされますが、SQL `LIKE`ワイルドカード（つまり、`%`と`_`）はエスケープ**されません**。引数にサニタイズされていない値が使用されている場合、予期しない動作となることがあります。例えば:
+引数はSQLインジェクションを防ぐために自動的にエスケープされますが、SQL `LIKE`ワイルドカード（つまり、`%`と`_`）はエスケープ**されません**。引数にサニタイズされていない値が使われている場合、予期しない動作となることがあります。例えば:
 
 ```ruby
 Book.where("title LIKE ?", params[:title] + "%")
 ```
 
-上の例は、ユーザーが指定した文字列で始まるタイトルに一致することを意図しています。しかし、`params[:title]`に含まれる`%`または`_`はワイルドカードとして扱われるため、意外な結果をもたらします。状況によっては、データベースがインデックスを使用できなくなるため、クエリが大幅に遅くなる可能性があります。
+上の例は、ユーザーが指定した文字列で始まるタイトルに一致することを意図しています。しかし、`params[:title]`に含まれる`%`または`_`はワイルドカードとして扱われるため、意外な結果をもたらします。状況によっては、データベースがインデックスを利用できなくなるため、クエリが大幅に遅くなる可能性があります。
 
-これらの問題を回避するには、[`sanitize_sql_like`][]を使用して関連する引数のワイルドカード文字をエスケープします。
+これらの問題を回避するには、関連する引数のワイルドカード文字を[`sanitize_sql_like`][]でエスケープします。
 
 ```ruby
 Book.where("title LIKE ?",
@@ -1691,7 +1691,7 @@ Customer.includes(orders: { books: [:supplier, :author] }).find(1)
 
 #### 関連付けのeager loadingで条件を指定する
 
-Active Recordでは、eager loadingされた関連付けに対して、`joins`のように条件を指定可能ですが、このやり方よりも[joins](#テーブルを結合する)の使用を推奨します。
+Active Recordでは、eager loadingされた関連付けに対して、`joins`のように条件を指定可能ですが、このやり方よりも[joins](#テーブルを結合する)を使うことをオススメします。
 
 とはいえ、eager loadingされた関連付けに対して条件を指定せざるを得ない場合は、以下のように普通にwhereを使っても大丈夫です。
 
@@ -2631,7 +2631,7 @@ EXPLAIN SELECT "customers".* FROM "customers" INNER JOIN "orders" ON "orders"."c
 (7 rows)
 ```
 
-eager loadingを使用している場合、内部的には複数のクエリがトリガされることがあり、このとき一部のクエリが先行するクエリの結果を必要とすることがあります。このためexplainは、このクエリを実際に実行した後で、クエリプランを要求します。以下に例を示します。
+eager loadingを使うと、内部的には複数のクエリがトリガされることがあり、このとき一部のクエリが先行するクエリの結果を必要とすることがあります。このためexplainは、このクエリを実際に実行した後で、クエリプランを要求します。以下に例を示します。
 
 ```ruby
 Customer.where(id: 1).includes(:orders).explain

guides/source/ja/association_basics.md

@@ -1644,7 +1644,7 @@ Entry.create! entryable: Message.new(subject: "hello!")
 
 ### さらに委譲を追加する
 
-`Entry`デリゲータを拡張して`delegates`を定義し、サブクラスに対してポリモーフィズムを使用することで、さらに拡張できます。
+`Entry`デリゲータを拡張して`delegates`を定義し、サブクラスに対してポリモーフィズムを使うことで、さらに拡張できます。
 
 たとえば、`Entry`の`title`メソッドをそのサブクラスに委譲するには以下のようにします。
 

guides/source/ja/autoloading_and_reloading_constants.md

@@ -205,7 +205,7 @@ INFO: 技術的には、`once`オートローダーによって管理される
 
 `config.autoload_lib_once`を呼び出すことで、`lib`内のクラスやモジュールが自動的に読み込まれます。アプリケーションの初期化時でも再読み込みは行われません。
 
-`config.autoload_lib_once`は7.1以前では利用できませんが、アプリケーションがZeitwerkを使用している限り、エミュレーションは可能です。
+`config.autoload_lib_once`は7.1以前では利用できませんが、アプリケーションがZeitwerkを使っている限り、エミュレーションは可能です。
 
 ```ruby
 # config/application.rb
@@ -291,7 +291,7 @@ end
 
 ただし、`main`オートローダが管理している自動読み込みパスからの自動読み込みはできません。これは、`config/initializers`にあるコードや、アプリケーションやエンジンのイニシャライズについても同様です。
 
-イニシャライザーは、アプリケーションの起動時に一度だけ実行されます。再読み込み時に再度実行されることはありません。もしイニシャライザがリロード可能なクラスやモジュールを使用していた場合、それらに対する編集はその初期コードに反映されないため、古くさくなってしまいます。したがって、初期化時にリロード可能な定数を参照することは禁止されています。
+イニシャライザーは、アプリケーションの起動時に一度だけ実行されます。再読み込み時に再度実行されることはありません。イニシャライザがリロード可能なクラスやモジュールを使っている場合、それらに対する編集はその初期コードに反映されないため、古くなってしまいます。したがって、初期化時にリロード可能な定数を参照することは禁止されています。
 
 その理由は、イニシャライザはアプリケーション起動時に1度しか実行されないためです。再読み込み時に再実行されることはありません。イニシャライザが再読み込み可能なクラスやモジュールを利用している場合、それらを編集しても初期コードに反映されないため、古くなってしまいます。この理由により、初期化時に再読み込み可能な定数を参照することは禁止されています。
 

guides/source/ja/configuring.md

@@ -255,8 +255,8 @@ Rails全般に対する設定を行うには、`Rails::Railtie`オブジェク
 #### `config.add_autoload_paths_to_load_path`
 
 自動読み込みパスを`$LOAD_PATH`に追加しなければならないかどうかを指定します。`zeitwerk`モードでは`config/application.rb`で`false` に設定することが推奨されます。
-Zeitwerkは内部的に絶対パスを使用し、`:zeitwerk`モードで動作するアプリケーションには `require_dependency`が不要なので、モデル、コントローラ、ジョブなどは`$LOAD_PATH`に入れておく必要がありません。
-これを`false`に設定すると、Ruby が相対パスで`require`呼び出しを解決する際にこれらのディレクトリをチェックする必要がなくなり、Bootsnapの作業とメモリを節約できます。
+Zeitwerkは内部的に絶対パスを使っており、`:zeitwerk`モードで動作するアプリケーションには`require_dependency`が不要なので、モデル、コントローラ、ジョブなどは`$LOAD_PATH`に入れておく必要がありません。
+これを`false`に設定すると、Rubyが相対パスで`require`呼び出しを解決する際にこれらのディレクトリをチェックする必要がなくなり、Bootsnapの作業とメモリを節約できます。
 
 デフォルト値は、`config.load_defaults`のターゲットバージョンによって異なります。
 
@@ -1338,7 +1338,7 @@ Active Recordで楽観的ロック（optimistic locking）を使うかどうか
 `7.1`に設定すると、Active Recordインスタンスを`Marshal.dump`でより効率的にシリアライズ可能になります。
 
 これによりシリアライズ形式が変更されるため、この方法でシリアライズされたモデルは古いバージョンのRails（< 7.1）では読み込めなくなります。
-ただし、この最適化が有効かどうかにかかわらず、古い形式を使用するメッセージは引き続き読み込めます。
+ただし、この最適化が有効かどうかにかかわらず、古い形式が使われているメッセージは引き続き読み込めます。
 
 | バージョン              | デフォルト値           |
 | --------------------- | -------------------- |
@@ -1644,7 +1644,7 @@ record.token # => "fwZcXX6SkJBJRogzMdciS7wf"
 
 `ActiveRecord::Base.connection`の振る舞いを、「エラーを発生」「非推奨警告を表示」「どちらも行わない」のどれにするかを制御します。
 
-`ActiveRecord::Base.connection`は、プールからデータベースコネクションをチェックアウトし、リクエストやジョブの終了までリースされた状態にします。この振る舞いは、使用可能なコネクション数よりも多くのスレッドまたはファイバーを利用する環境では望ましくない場合があります。
+`ActiveRecord::Base.connection`は、プールからデータベースコネクションをチェックアウトし、リクエストやジョブの終了までリースされた状態にします。この振る舞いは、利用可能なコネクション数よりも多くのスレッドまたはファイバーを用いる環境では望ましくない場合があります。
 
 この設定を使うことで、`ActiveRecord::Base.connection`を呼び出すコードをトラッキングして削除し、代わりに`ActiveRecord::Base.with_connection`を利用する形に移行できます。
 
@@ -1656,7 +1656,7 @@ record.token # => "fwZcXX6SkJBJRogzMdciS7wf"
 
 #### `config.active_record.database_cli`
 
-`rails dbconsole`を実行するときにデータベースへのアクセスに利用するCLIツールを制御します。デフォルトでは、データベースの標準ツールが使用されます（例: PostgreSQLの場合は`psql`、MySQLの場合は`mysql`）。このオプションは、データベースシステムごとにツールを指定するハッシュを受け取り、フォールバックオプションが必要な場合は配列を渡せます。
+`rails dbconsole`を実行するときにデータベースへのアクセスに利用するCLIツールを制御します。デフォルトでは、データベースの標準ツールが使われます（例: PostgreSQLの場合は`psql`、MySQLの場合は`mysql`）。このオプションは、データベースシステムごとにツールを指定するハッシュを受け取り、フォールバックオプションが必要な場合は配列を渡せます。
 
 ```ruby
 # config/application.rb
@@ -2598,7 +2598,7 @@ config.active_support.message_serializer = YAML
 #### `config.active_support.use_message_serializer_for_metadata`
 
 `true`に設定すると、メッセージデータとメタデータを一緒にシリアライズするときのパフォーマンスの最適化を有効にします。これによりメッセージのフォーマットが変更されるため、この方法でシリアライズされたモデルは古いバージョンのRails（< 7.1）では読み込めなくなります。
-ただし、この最適化が有効かどうかにかかわらず、古い形式を使用するメッセージは引き続き読み込めます。
+ただし、この最適化が有効かどうかにかかわらず、古い形式を使っているメッセージも引き続き読み込めます。
 
 デフォルト値は、`config.load_defaults`のターゲットバージョンによって異なります。