--- title: "Riderの.editorconfig設定｜DotSettingsとの優先順位・既存コードからの自動検出・CI強制" url: "https://www.issoh.co.jp/tech/details/8161/" published: 2025-08-12 updated: 2026-11-06 categories: ["C# / .NET"] publisher: "株式会社一創" --- # Riderの.editorconfig設定｜DotSettingsとの優先順位・既存コードからの自動検出・CI強制 JetBrains RiderでC#のコーディングルールをチームに揃えるなら、規約の置き場所は`.editorconfig`に決めるのが近道です。Riderの設定画面で整えたコードスタイルは`.DotSettings`という独自形式のファイルに入りますが、公式ヘルプは「EditorConfigで設定したコードスタイルとコードインスペクションは、すべての設定レイヤーを常に上書きする」と明記しています。本記事はRider 2026.2.4.1（ビルド262.11879.119、2026年11月3日リリース）の公式仕様をもとに、既存コードから規則を抜き出して`.editorconfig`を作るところから、重大度の書き方、保存時とコミット時の整形、CIでの違反検知までを導入の順に並べます。 ## まとめ：Riderで規約を.editorconfigに集約する6つの手順 1. **既存コードから規則を検出する**。設定の**Editor | Code Style | C#**にある**Auto-Detect Code Style Rules**で、今のコードが実際に従っている書式を拾い、`.editorconfig`へ保存します。 2. **VCSに入れるのは`.editorconfig`と`.sln.DotSettings`**。個人設定の`.sln.DotSettings.user`はコミットしません。 3. **重大度は記法で値の一覧が違う**。Rider固有の検査は`resharper_..._highlighting`で`error | warning | suggestion | hint | none`、コンパイラ警告は`dotnet_diagnostic..severity`で`none | silent | suggestion | warning | error`です。 4. **検査の重大度が効かないときは「Read settings from editorconfig, project settings and rule sets」を確認する**。整形は既定で読むのに、検査と命名スタイルはこのチェックが要ります。 5. **保存時とコミット時に整形を当てる**。Actions on Saveは明示保存でしか動かないので、Commit Checksの**Cleanup with…**も併用します。 6. **最後の関門はCI**。無償のReSharper Command Line Toolsで`jb cleanupcode`と`jb inspectcode`を回し、差分か検出が出たらジョブを落とします。 ## 設定の保存先となる3つのレイヤーと.editorconfigの優先順位 Riderは設定を1か所に持たず、重なり合う複数のレイヤーに保存します。標準のレイヤーは**This computer**、**Solution team-shared**、**Solution personal**の3つです。どのレイヤーに保存したかを意識しないまま設定を触ると、手元では規約どおりなのに他のメンバーの環境では違う整形になる、という食い違いが起きます。 ### 3つのレイヤーが書き込むファイルと適用範囲 | レイヤー | 保存先ファイル | 適用範囲 | VCS | | -------------------- | ----------------------------------- | --------------- | ------- | | This computer | GlobalSettingsStorage.DotSettings | そのマシンの全ソリューション | 対象外 | | Solution team-shared | .sln.DotSettings | 該当ソリューション・チーム共有 | コミットする | | Solution personal | .sln.DotSettings.user | 該当ソリューション・自分だけ | コミットしない | This computerの実ファイルは、Windowsが`%APPDATA%\JetBrains\Rider2026.2\resharper-host\GlobalSettingsStorage.DotSettings`、macOSが`~/Library/Application Support/JetBrains/Rider2026.2/resharper-host/GlobalSettingsStorage.DotSettings`、Linuxが`~/.Rider2026.2/config/resharper-host/GlobalSettingsStorage.DotSettings`です。パスにバージョン番号が入っているため、2026.3へ上げると別ファイルになります。このレイヤーはチームへ配布されないので、全員に守らせたいルールをここに置いても効きません。 Solution team-sharedは、命名スタイルや整形ルールなどチームの設定を現在のソリューションに強制するためのレイヤーです。ファイルをVCSに入れてメンバーが取得すると、ソリューションを開き直さなくても適用されます。Solution personalは共有設定を変えずに自分だけ上書きするためのもので、公式ヘルプも「VCSに追加すべきではない」としています。 ### .editorconfigが全レイヤーより優先される根拠 公式の[Layer-based settings](https://www.jetbrains.com/help/rider/Sharing%5FConfiguration%5FOptions.html)は`Code style and code inspections settings configured in EditorConfig will always override settings from all settings layers.`と書いており、EditorConfigはレイヤー構造の外側から全体を上書きします。[Use EditorConfig](https://www.jetbrains.com/help/rider/Using%5FEditorConfig.html)にも、既定でEditorConfigプロパティがRider設定の指定を上書きすると書かれています。 二重管理する意味はありません。コードスタイルと検査の重大度は`.editorconfig`へ一本化し、`.sln.DotSettings`にはコードクリーンアップのカスタムプロファイルのように、EditorConfigで表現できない項目だけを残します。`.editorconfig`はディレクトリ階層をさかのぼって適用されるので、サブプロジェクトだけ規約を変えたいときは該当ディレクトリに追加のファイルを置けば済みます。 ### VCSにコミットするファイルと除外するファイル GitHubが公開しているgitignoreテンプレート集のVisualStudio向けファイルには、ReSharper関連として`*.DotSettings.user`が登録されています。Riderのソリューション個人設定もこのパターンに一致します。自前の`.gitignore`を書く場合、先頭のワイルドカードを落とすと`MyApp.sln.DotSettings.user`に当たらないので注意してください。 ``` # .gitignore # チーム共有設定はコミットする（除外しない） # MyApp.sln.DotSettings # .editorconfig # 個人設定だけ除外する *.DotSettings.user # ReSharper の作業ディレクトリ _ReSharper*/ # .idea は共有したい設定も含むため、個人用ファイルだけを除外する # （github/gitignore の Global/JetBrains.gitignore と同じ方針） .idea/**/workspace.xml .idea/**/tasks.xml .idea/**/shelf ``` ### Riderの版が混在するチームで.DotSettingsの変更が読まれないケース Riderの新しい版は、設定の保存形式を変えたときに`.DotSettings`を初回起動時に自動で書き換えます。公式の説明では、新形式の設定を追記し、旧形式の項目は変更も削除もしないので、アップグレード済みのファイルを古い版のメンバーと共有してもかまいません。書き換え済みの印として、次のような項目がファイルに追加されます。 ``` True ``` 落とし穴は逆方向にあります。新しい版に上げたあと古い版に戻って設定を変え、再び新しい版に戻ると、Riderは2回目のアップグレードをしません。公式は、このとき古い形式で保存された設定が新しい版に読まれない場合があると注意しています。2026.2系と2026.3系が混在する時期は、`.sln.DotSettings`を触る人を新しい版の利用者に限るか、変更後に両方の版で読まれているかを確かめてください。`.editorconfig`に寄せた項目はこの影響を受けないので、混在期間を短く保てないチームほど`.editorconfig`への集約が効きます。 ## .editorconfigを作る：既存コードからの自動検出と設定画面からの書き出し ゼロから手で書く必要はありません。既にコードがあるリポジトリなら自動検出、設定画面でスタイルを整えてあるならエクスポートが入口になります。 ### 既存コードの規則検出と.editorconfigへの保存 規約を後から入れるときに困るのは、決めたルールと今のコードがずれていて、最初の一括整形で巨大な差分が出ることです。Riderの[Code Style: C#](https://www.jetbrains.com/help/rider/Settings%5FCode%5FStyle%5FCSHARP.html)ページにある**Auto-Detect Code Style Rules**は、現在のソリューションで使われている整形と構文スタイルを分析し、今の設定と異なる規則を検出します。検出結果は確認・修正したうえで、設定レイヤーか、`.editorconfig`または`.clang-format`形式のファイルへ保存できます。 先に今のコードの実態を規則として書き出し、それを出発点にチームで変えたい項目だけを議論する順序にすると、規約導入のPRが「議論した変更」と「機械的な整形」に分かれてレビューしやすくなります。ソリューション全体でなく一部のコードだけを手本にしたいときは、エディターでコードを選択して`Alt+Enter`から**Reformat and cleanup | Detect code style settings**を実行します。公式は整形ルールの検出がC#とC++だけで動くとしています。命名規則も既定では既存コードから学習する設定になっており、手で決めたい場合は**Editor | Code Style | C# | Naming**の**Use auto-detected rules**を外します。 ### 設定画面から.editorconfigへの書き出し RiderのUIで整えたスタイルがあるなら、そのままエクスポートできます。`Ctrl+Alt+S`で設定を開き、**Editor | Code Style**の**Enable EditorConfig support**の横にある**Export**をクリックします。既定ではソリューションのルートに新しい`.editorconfig`が作られ、既存ファイルがある場合はディレクトリ階層上で最も近いファイルが使われます。 ダイアログの**Show additional options**を開くと、既定値のままの設定も書き出すか、JetBrains固有のスタイルを含めるか、検査重大度を含めるかを選べます。既定では変更した設定のプロパティだけが保存されます。変更した設定だけの書き出しは差分を追いやすい反面、未出力の項目は各IDEの設定に依存します。全員で固定したい項目は、既定値と同じでも明示してください。書き込み前のプレビューでは、既存ファイルと値が衝突するプロパティが赤く示されます。 ## Riderが解釈する.editorconfigプロパティの3系統 Riderの設定ダイアログで変えられるコードスタイル設定には、それぞれ対応するEditorConfigプロパティがあります。書けるプロパティは3系統に分かれ、どの系統かで他のエディタに効くかどうかが決まります。 ### 標準プロパティ・.NET規約プロパティ・JetBrains固有プロパティの使い分け 1つ目はEditorConfig標準プロパティです。標準といっても対応状況は一律ではなく、EditorConfig公式のプロパティ一覧は`indent_style`や`indent_size`を「Widely Supported by Editors」、`max_line_length`を「Supported By A Limited Number of Editors」と分けています。2つ目は`csharp_style_var_for_built_in_types`のような.NETコーディング規約プロパティ。3つ目が`resharper_`で始まるJetBrains固有プロパティで、Rider独自の整形・構文スタイル・検査重大度はここで指定します。以下は公式ヘルプの掲載例をもとに、3系統が並ぶようにした設定例です。 ``` root = true [*] # 標準プロパティ indent_size=2 max_line_length=100 # .NET コーディング規約プロパティ csharp_space_between_parentheses=expressions, type_casts, control_flow_statements csharp_style_var_for_built_in_types=true # コンパイラ警告の重大度 dotnet_diagnostic.CS8618.severity = none # JetBrains 固有：整形スタイル resharper_csharp_brace_style=next_line resharper_csharp_blank_lines_around_invocable=2 # JetBrains 固有：構文スタイル csharp_default_private_modifier=explicit braces_for_ifelse=not_required # JetBrains 固有：検査の重大度 resharper_possible_null_reference_exception_highlighting=error resharper_replace_with_string_is_null_or_empty_highlighting=none ``` 取り違えやすいのは`dotnet_diagnostic.*`の守備範囲です。公式ヘルプはこの記法の値を`none | silent | suggestion | warning | error`とし、適用先を「C# 8.0以降のコンパイラ警告と、コンパイラ自身が出すものを含むRoslyn解析規則」に限っています。Rider独自の検査（上の例の`possible_null_reference_exception`など）はこれに当たらないため、`resharper_..._highlighting`で書きます。値の一覧も一致しておらず、`dotnet_diagnostic`側には`silent`があって`hint`が無く、`resharper_..._highlighting`側はその逆です。片方の感覚で値を書き写さず、該当ページの一覧を見て決めてください。 Visual Studioとの違いが1つあります。Riderは**プロジェクトファイルから参照されている**`.globalconfig`に書かれたEditorConfig標準プロパティも解釈し、公式ヘルプはこれを`(unlike Visual Studio)`と対比しています。参照されていない`.globalconfig`は対象外です。命名規則の`dotnet_naming_rule.*`系は、指定したシンボルの種別がRiderの命名設定で扱える種別と一致する場合にだけ機能します。 ## 検査の重大度を.editorconfigで調整する手順と、効かないときの確認箇所 IDEが出す警告が多すぎれば誰も読まなくなります。落としたい違反だけをエラーに引き上げ、それ以外を下げる運用にしてください。 ### 重大度の5値と書き換えの実例 公式の[Configure warnings](https://www.jetbrains.com/help/rider/Code%5FAnalysis%5F%5FConfiguring%5FWarnings.html)は構文を`[inspection_property]=[error | warning | suggestion | hint | none]`と示しています。`Possible 'System.NullReferenceException'`検査をエラーに上げるなら`resharper_possible_null_reference_exception_highlighting=error`、Redundant argument with default value検査を無効にするなら`resharper_redundant_argument_default_value_highlighting=none`です。同じページは、`.editorconfig`の検査設定が設定画面のInspection Severityページより優先されるとも書いています。 ### 重大度が反映されないときに開く設定 `.editorconfig`に重大度を書いたのに表示が変わらないときは、Rider側の受け入れ設定を確認してください。公式ヘルプは`To configure code inspections and naming styles from EditorConfig, you have to select the Read settings from editorconfig, project settings and rule sets checkbox on the Editor | Inspection Settings page of JetBrains Rider settings.`と条件を書いています。整形スタイルは既定で読まれるのに、検査と命名スタイルだけこのチェックボックスを要求する非対称があります。 有効になっていれば、Riderは適用状況を画面上で示します。コードスタイル設定ページの項目がEditorConfigで上書きされていると黄色の警告が出て、上書きされた項目も黄色でハイライトされます。現在のファイルにどの`.editorconfig`が効いているかは、**Help | Find Action**から**Show Code Style Configuration**を開いて確かめます。 ### generated\_codeによる生成コードの検査対象の限定 生成コードは手作業で修正せず、通常のソースと検査対象を分けます。Riderは生成コードとして指定された範囲では、コンパイラのエラーと警告を調べる検査だけを実行します。`*.designer.cs`のような典型的なマスクは既定で登録済みで、独自の生成物は`.editorconfig`からも指定できます。 ``` [*generated.cs] generated_code = true ``` 検査体系そのものをどう設計するかは、IDEの機能に限らない話です。ツール選定の観点は[静的解析とは？検出できる欠陥と静的解析ツールの選び方｜Coverity・cppcheckを比較](/tech/details/7475/)で整理しています。 ## 保存時とコミット時にコードクリーンアップを当てる設定 ルールを書いても、適用が手動なら守られません。Riderには保存時とコミット時の2か所にクリーンアップを差し込む設定があり、役割が違います。 ### Actions on Saveによる保存時の自動整形 `Ctrl+Alt+S`で設定を開き、**Tools | Actions on Save**の**Reformat and Cleanup Code**をオンにします。ここで適用するクリーンアッププロファイルと、ファイル全体か変更行だけかを選べます。変更行だけに絞れば、古いファイルを開いて保存しただけで巨大な差分が出る事故を避けられます。 トリガーは明示的な保存に限られます。公式の[Code cleanup](https://www.jetbrains.com/help/rider/Code%5FCleanup%5F%5FIndex.html)は`Note that this will only happen when you save changes explicitly with Ctrl+S or Ctrl+S and will not be triggered by auto-saving.`と書き、自動保存されたファイルは整形キューに入り、次の明示保存でまとめて処理されると説明しています。`Ctrl+S`を押す習慣のない人の変更は、整形されないままコミットまで進むことがあります。 ### Commit Checksによるコミット前のクリーンアップ 保存時の整形をすり抜けた変更は、コミットの時点で止めます。`Ctrl+K`か**Git | Commit**でCommitツールウィンドウを開き、**Show Commit Options**の**Commit Checks**で**Cleanup with…**にチェックを入れます。コミット画面の[リファレンス](https://www.jetbrains.com/help/rider/Commit%5FDialog.html)はこの項目を「コミットまたはシェルブするファイルにFull Cleanupプロファイルを実行する」と説明しているので、保存時やCIと揃えるなら**Choose profile**で同じプロファイルを指定します。この状態で**Commit**か**Commit and Push**を押すと、Riderはステージ済みのファイルにクリーンアップを当ててからコミットします。 対象はコミットするファイルですが、そのファイル内の未変更箇所にもクリーンアップが及び得るため、実行後の差分を確認してください。この設定はRiderのUIからコミットしたときだけ効きます。ターミナルの`git commit`や他のGUIクライアントは通らないので、全員に効く関門はCIに置きます。 ### 特定ファイルの整形除外とプロファイル差し替え 生成物やベンダー提供のソースなど、整形してはいけないファイルは必ず出てきます。C#では`disable_formatter=true`を付けたEditorConfigマスクでRiderのフォーマッタを止められます。ファイルの集合ごとにクリーンアッププロファイルを差し替える`resharper_substitution_for_cleanup_profile`プロパティもあります。 ``` [Generated/**.cs] # このディレクトリ配下はフォーマッタを動かさない disable_formatter=true [reformatIfRunWithFullCleanup.cs] # フルクリーンアップ指定時も整形のみに差し替える resharper_substitution_for_cleanup_profile.anysuffix=Built-in:Full Cleanup => Built-in: Reformat Code ``` 組み込みプロファイルは3種類です。**Built-in: Full Cleanup**はファイルヘッダーの更新を除く全タスク、**Built-in: Reformat Code**は整形のみ、**Built-in: Reformat & Apply Syntax Style**は整形と構文スタイルの適用です。保存時・コミット時・CIで別のプロファイルを使うと結果がずれるので、1つに決めて`.sln.DotSettings`で共有し、コマンド側でも`--profile`で同じ名前を明示してください。 ## CIでの規約強制：jb cleanupcodeとjb inspectcode IDEの設定だけに頼ると、Riderを使っていないメンバーやAIエージェントが書いたコードが規約をすり抜けます。JetBrainsはIDEなしで同じ整形と検査を実行できるコマンドラインツールを配布しており、公式ヘルプは`ReSharper Command Line Tools is a set of free cross-platform standalone tools`と説明しています。NuGetの`JetBrains.ReSharper.GlobalTools`の安定版はRiderと同じ2026.2.4.1（2026年11月3日更新）で、パッケージの対象フレームワークは.NET 8.0です。 ``` dotnet tool install -g JetBrains.ReSharper.GlobalTools # Windows ARM64 ではアーキテクチャの明示が要る dotnet tool install -g JetBrains.ReSharper.GlobalTools --arch arm64 # 整形と検査（パッケージ共通のコマンドは jb） jb cleanupcode MyApp.sln --profile="Built-in: Reformat Code" jb inspectcode MyApp.sln -o=inspect.sarif -e=WARNING ``` 規約を揃えるのが目的なので、ツールの版も固定します。`-g`でのグローバル導入は実行環境ごとに入る版が変わり、同じコミットでも整形結果が変わり得ます。リポジトリで`dotnet new tool-manifest`と`dotnet tool install JetBrains.ReSharper.GlobalTools --version 2026.2.4.1`を実行し、生成されたマニフェストをコミットしておけば、CIは`dotnet tool restore`で同じ版を取得します。マニフェストの置き場所はSDKで違い、.NET SDK 10.0.401で実行するとカレントディレクトリ直下に`dotnet-tools.json`が作られ、`.config`フォルダは作られませんでした。同じSDKの`dotnet new sln`はソリューションを`.slnx`形式で作りますが、`jb cleanupcode MyApp.slnx`・`jb inspectcode MyApp.slnx`はどちらもそのまま受け付けました。 ### git diffによるCleanupCodeの変更検知 CleanupCodeはコードを書き換えるツールなので、CIでは「書き換えが発生したら規約違反」と扱います。公式の[CleanupCode Command-Line Tool](https://www.jetbrains.com/help/rider/CleanupCode.html)も`If your project is under Git VCS, use git diff after running CleanupCode to reveal any changes that were made by the tool.`とこの使い方を案内しています。`git diff --exit-code`を続ければ、差分が出た時点でジョブが失敗します。整形の崩れた`Foo.cs`を1つ置いたコンソールアプリで下のワークフローの手順を順に流すと、`cleanupcode`の書き換えで`git diff --exit-code`が1を返し、`inspectcode`のSARIFには`CSharpWarnings::CS8600`（null許容でない型へのnull代入）の警告が1件入って、件数判定の`test`も1を返しました。 CleanupCodeは`.DotSettings`から整形ルール・構文スタイル・C#のファイルと型のレイアウトを読み、`--settings`で共有設定ファイルのパスを明示することもできます。そのうえでEditorConfigのコードスタイルプロパティが同じ項目を上書きします。ローカルと同じ結果を得るには、`.editorconfig`と`.sln.DotSettings`の両方がチェックアウトされている必要があります。 ### InspectCodeの出力形式と最低重大度 [InspectCode](https://www.jetbrains.com/help/rider/InspectCode.html)は2024.1から既定の出力形式がSARIFです。XMLは`-f="xml"`で取得でき、既定のまま`-o=inspect.xml`と書いてもXMLは出ません。形式を決めるのは拡張子ではなく`--format`です。 既定ではSuggestion以上の重大度が報告されます。`--severity`（短縮形`-e`）に`INFO, HINT, SUGGESTION, WARNING, ERROR`のいずれかを渡すと下限を変えられるので、CIでは`-e=WARNING`程度に絞ります。**この指定は報告対象を絞るだけで、合否は決めません**。CIで落とすには、出力したSARIFの検出件数を読んで終了コードを立てます。解析前のビルド有無は`--build`と`--no-build`で明示でき、公式は既定動作か`--build`を推奨しています。 ``` # .github/workflows/code-style.yml name: code-style on: [pull_request] jobs: style: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-dotnet@v4 with: dotnet-version: '10.x' - run: dotnet tool restore - name: format check run: | dotnet tool run jb -- cleanupcode MyApp.sln --profile="Built-in: Reformat Code" git diff --exit-code - name: inspection run: | dotnet tool run jb -- inspectcode MyApp.sln -o=inspect.sarif -e=WARNING test "$(jq '[.runs[].results[]] | length' inspect.sarif)" -eq 0 ``` ### AIエージェントの変更に対する品質チェックフック エージェントにコードを書かせる運用では、PRより手前で規約を当てられるほうが手戻りが小さくなります。Rider 2026.2はこの用途にコード品質チェックフックを追加しました。有効にするのは設定の**Tools | AI Agent Hooks**で、2026.2 EAP 5の[告知](https://blog.jetbrains.com/dotnet/2026/06/08/rider-2026-2-code-quality-check-hooks-for-ai-agents/)によれば、RiderがClaude Code側に必要なフックの設定項目を自動で書き込みます。JetBrainsの[2026.2リリース記事](https://blog.jetbrains.com/dotnet/2026/07/22/rider-2026-2-release/)は`Code quality check hooks for Claude Code validate every change an agent makes before it can continue, blocking on errors and returning warnings as feedback.`と説明しています。エージェントの変更をRiderのインスペクションで検査し、エラーなら続行を止め、警告はフィードバックとして返す仕組みです。続く[2026.2.1](https://blog.jetbrains.com/dotnet/2026/08/19/rider-resharper-2026-2-1/)では`Rider's quality-check hooks now support Codex in addition to Claude Code.`とあり、Codexにも対応しました。 このフックが判定に使うのも、ここまでで整えた`.editorconfig`と`.sln.DotSettings`です。規約が個人のThis computerレイヤーに残っていると、そのIDEで動くフックと共有設定だけを読むCIとで判定が食い違います。JetBrains製IDEのAI機能の料金と使い方は[JetBrains AI Assistantとは？料金・AIクレジット・使い方とGitHub Copilotとの違い](/tech/details/10358/)で扱っています。 規約をCIに載せる考え方は他言語でも同じです。TypeScript側は[Biome v2とは？最新2.6の導入・biome.json設定とESLint/Prettier移行](/tech/details/7390/)、インフラコード側は[Terraformコーディング規約とterraform fmtの使い方｜公式スタイルガイド準拠の命名・コメント・CI強制](/tech/details/4083/)が参考になります。 ## Visual Studio・外部フォーマッタと併用するときの住み分け チーム全員がRiderを使うとは限りません。混在環境では、どのツールが何を担当するかを先に決めます。 | 環境 | 規約の正本 | Rider固有プロパティ | CIでの強制 | | ------------------------- | ------------- | ------------ | ------------------------------- | | Rider | .editorconfig | 解釈する | jb cleanupcode / jb inspectcode | | Visual Studio + ReSharper | .editorconfig | 解釈する | jb cleanupcode / jb inspectcode | | Visual Studio 単体 | .editorconfig | 無視される | dotnet format | | CSharpier 併用 | 整形はCSharpier | 整形は無効化して委譲 | CSharpier の CI コマンド | Visual Studio単体の環境が混じる場合、`resharper_`プレフィックスのプロパティは読まれません。全員に守らせたい項目は標準プロパティと.NETコーディング規約プロパティの範囲に収め、Rider固有プロパティはRiderユーザー向けの追加分と割り切ってください。Visual Studio 2026側の変更点は[Visual Studio 2026の新機能｜VS2022との違い・サポート期限とVS2027への更新【2026年10月】](/tech/details/10289/)、Visual StudioにReSharperを入れる場合の費用と機能は[ReSharperとは？使い方・料金・日本語化とVS Code版まで解説【2026.2】](/tech/details/6856/)にまとめています。 整形をCSharpierに任せる構成も選べます。CSharpierのリポジトリにあるRiderプラグインは、dotnetツールのCSharpierを呼び出して整形する仕組みで、本体とは別に版が振られています。[JetBrains Marketplaceのcsharpierプラグイン](https://plugins.jetbrains.com/plugin/18243-csharpier)（ID 18243）は、2026年9月25日公開の10.0.7が最新で、対応ビルドは251.0から262.\*まで、つまりRider 2025.1〜2026.2系です。いずれも2026年11月6日にMarketplaceのAPIで確認した値なので、2026.3（ビルド263）へ上げる前にプラグイン側の対応を確かめてください。この構成ではRider側の整形を`disable_formatter=true`で止め、検査だけRiderに担当させます。整形ルールを2つのツールに持たせたままにすると、保存のたびに整形結果を打ち消し合います。 ## Riderの日本語化と、無償で使える範囲 規約の設定そのものではありませんが、Riderを配る前に確認しておく2点です。どちらも2024年に仕様が変わっており、古い手順の情報が残っています。 ### Rider 2024.2以降の言語パック同梱とUI言語の切り替え 「Riderの日本語化にはMarketplaceから言語パックを入れる」という手順は、現行版では不要です。公式の[Language and region](https://www.jetbrains.com/help/rider/Language-and-region.html)は`JetBrains Rider is available in English but also includes bundled plugins that support Chinese, Korean, and Japanese.`と記載しています。切り替えは**Appearance & Behavior | System Settings | Language and Region**で行い、OSの言語とRiderの言語が違う場合は揃えるかどうかの提案も表示されます。同じJetBrains系IDEの日本語化は[IntelliJ IDEAでJava開発を始める手順｜インストール・JDK設定・日本語化【2026.2対応】](/tech/details/4377/)でも扱っています。 ### 非商用無料ライセンスで使える範囲 Riderは2024年10月24日の[JetBrainsの発表](https://blog.jetbrains.com/blog/2024/10/24/webstorm-and-rider-are-now-free-for-non-commercial-use/)で非商用利用が無償になりました。発表は対象を`learning, open-source project development, content creation, or hobby development`と列挙し、`For commercial projects, nothing will change`として商用は従来どおり有償だと述べています。社内の業務コードに使う場合は有償ライセンスが要ります。JetBrains製品のライセンスの整理は[RubyMineとは？最新版2026.2.4・料金と無料の条件・初期設定【2026年11月】](/tech/details/3382/)が詳しいです。 CIで使うReSharper Command Line Toolsは前述のとおり無償です。有償ライセンスを全員分そろえる前でも、規約チェックだけはCIに載せられます。 ## よくある質問 ### .editorconfigはどこに置けばいいですか？ ソリューションのルートディレクトリに置き、先頭に`root = true`を書くのが基本です。Riderは現在のファイルのディレクトリから親をさかのぼって`.editorconfig`を探し、ルートディレクトリに到達するか`root=true`のファイルを見つけるまで適用を重ねます。サブプロジェクトだけルールを変えたい場合は、そのディレクトリに`root`指定なしのファイルを追加して差分だけ書きます。 ### .DotSettingsと.editorconfigはどちらを使うべきですか？ コードスタイルと検査の重大度は`.editorconfig`に寄せてください。両方に書くと`.DotSettings`側は必ず上書きされます。`.sln.DotSettings`には、コードクリーンアップのカスタムプロファイル定義など、EditorConfigで表現できない設定だけを残します。 ### 既存プロジェクトに規約を入れると差分が大量に出ませんか？ 先に**Auto-Detect Code Style Rules**で今のコードの書式を規則として保存すれば、規約を入れた直後の差分を小さく抑えられます。変えたい項目は別のPRで1つずつ変え、Actions on Saveは「変更行だけ」に設定すると、触ったファイルの全体が書き換わることもありません。 ### CSharpierとRiderのフォーマッタは併用できますか？ 併用はできますが、整形の担当は片方に寄せます。csharpierプラグイン（Marketplace ID 18243）でCSharpierに整形を任せる場合は、対象ファイルのマスクに`disable_formatter=true`を指定してRider側の整形を止めます。両方を有効にしたままActions on Saveを使うと、保存のたびに互いの整形結果を上書きし合います。 ### Visual Studioと比べて規約運用で何が違いますか？ Riderは`resharper_`プレフィックスのJetBrains固有プロパティを解釈し、プロジェクトファイルから参照された`.globalconfig`の標準プロパティも読みます。混在環境では標準プロパティと.NETコーディング規約プロパティを共通の土台にし、固有プロパティは追加分として扱ってください。 ## 関連記事 - [ReSharperとは？使い方・料金・日本語化とVS Code版まで解説【2026.2】](/tech/details/6856/) - [静的解析とは？検出できる欠陥と静的解析ツールの選び方｜Coverity・cppcheckを比較](/tech/details/7475/) - [Visual Studio 2026の新機能｜VS2022との違い・サポート期限とVS2027への更新【2026年10月】](/tech/details/10289/) - [Terraformコーディング規約とterraform fmtの使い方｜公式スタイルガイド準拠の命名・コメント・CI強制](/tech/details/4083/) - [JetBrains AI Assistantとは？料金・AIクレジット・使い方とGitHub Copilotとの違い](/tech/details/10358/) --- 出典: [Riderの.editorconfig設定｜DotSettingsとの優先順位・既存コードからの自動検出・CI強制]()（株式会社一創）