Riderのコーディングルール統一｜.editorconfigと設定レイヤーの優先順位・CI強制の手順

JetBrains Riderでチームのコーディングルールを揃えるとき、設定をどこに保存するかで運用の寿命が決まります。IDEの設定画面で整えたコードスタイルは、レイヤーベース設定として.DotSettingsという独自形式に入りますが、Riderの公式ヘルプは「EditorConfigで設定したコードスタイルとコードインスペクションは、すべての設定レイヤーを常に上書きする」と明記しています。つまり規約の正本は.editorconfigに置くのが筋です。本記事はRider 2026.2.2（ビルド262.10315.191、2026年9月16日リリース）の公式仕様をもとに、レイヤー構造の理解から重大度の書き方、保存時の自動整形、CIでの違反検知までを手順として並べます。

まとめ：Riderの規約統一で先に決める5点

• 正本は.editorconfig。Riderの設定レイヤー（.DotSettings）より常に優先されるため、二重管理をやめてこちらへ寄せます。
• VCSに入れるのは.editorconfigと<SolutionName>.sln.DotSettingsの2つ。個人設定の.sln.DotSettings.userはコミットしません。
• 重大度は記法によって取れる値が違う。Rider固有の検査はresharper_..._highlightingでerror | warning | suggestion | hint | none、コンパイラ警告はdotnet_diagnostic.<ID>.severityでnone | silent | suggestion | warning | errorです。
• 重大度が効かないときは「Read settings from editorconfig, project settings and rule sets」を疑う。このチェックが外れていると.editorconfigの検査設定は読まれません。
• 強制はCIで行う。ReSharper Command Line Toolsは無償で、jb cleanupcodeとjb inspectcodeをIDEなしで実行できます。

設定の保存先となる3つのレイヤーと、.editorconfigが上書きする関係

Riderは設定を1か所に持たず、重なり合う複数のレイヤーに保存します。公式ヘルプは「JetBrains Riderは最初に3つのレイヤーを提示する」と述べており、その3つがThis computer、Solution team-shared、Solution personalです。どのレイヤーに保存したかを意識しないまま設定を触ると、手元では規約どおりなのに他のメンバーの環境では違う整形になる、という食い違いが起きます。

3つのレイヤーが書き込むファイルと適用範囲

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です。パスにバージョン番号が入っているため、Riderをメジャー更新すると別ファイルになります。このレイヤーはそのマシンの中だけで完結し、チームへ配布されません。全員に守らせたいルールをここに置いても共有されないため、規約は次のレイヤー以降へ出す必要があります。

Solution team-sharedは公式に「命名スタイルやフォーマットルールなど、現在のソリューションでチームの設定を強制するための共通設定」と位置づけられています。ファイルをVCSに入れてメンバーが取得すると、ソリューションの再読み込みなしで自動的に適用されます。Solution personalはチーム共有設定を変更せずに自分だけ上書きするためのもので、公式ヘルプも「VCSに追加すべきではありません」と明言しています。

.editorconfigが全レイヤーより優先される根拠

3層の上下関係だけを覚えても足りません。公式のLayer-based settingsはCode style and code inspections settings configured in EditorConfig will always override settings from all settings layers.と書いており、EditorConfigはレイヤー構造の外側から全体を上書きします。Use EditorConfigの側にも、既定で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が解釈する.editorconfigプロパティの3系統

Riderの公式ヘルプは「設定ダイアログで構成できるコードスタイル設定は、それぞれ固有のEditorConfigプロパティを持つ」と説明しており、コードスタイルと検査ルールの設定全体を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系統が1行ずつ入るよう並べた設定例です。

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.*の守備範囲です。公式ヘルプはこの記法をdotnet_diagnostic.<ID>.severity = none | silent | suggestion | warning | errorと定め、適用先を「C# 8.0以降のコンパイラ警告と、コンパイラ自身が出すものを含むRoslyn解析規則」と限定しています。Rider独自の検査（上の例のpossible_null_reference_exceptionなど）はこれに当たらないため、resharper_..._highlightingを使う必要があります。取り違えると、書いたのに何も変わらないという状態になります。

値の並びが似ているため見落としやすいのですが、公式が2つの記法に示す値の一覧は一致していません。dotnet_diagnostic側の一覧にはsilentが載りhintが載らず、resharper_..._highlighting側はその逆です。片方の感覚で値を書き写さず、該当ページの一覧を見て決めてください。命名規則のdotnet_naming_rule.*系も「指定した記号の種別がRiderの命名設定で扱える種別と一致する場合に機能する」という条件付きです。

Visual Studioとの差として1点挙げると、Riderはプロジェクトファイルから参照されている.globalconfigに書かれたEditorConfig標準プロパティも解釈します。公式ヘルプはこの挙動を(unlike Visual Studio)と明示的に対比しています。参照されていない.globalconfigは対象外です。

設定画面の内容を.editorconfigへ書き出す手順

ゼロから手書きする必要はありません。既にRiderのUIで整えたスタイルがあるなら、そのままエクスポートできます。Ctrl+Alt+Sで設定を開き、Editor | Code Styleを選び、Enable EditorConfig supportの横にあるExportをクリックします。既定ではソリューションのルートディレクトリに新しい.editorconfigが作られ、既存ファイルがある場合はディレクトリ階層上で最も近いファイルが使われます。

ダイアログのShow additional optionsを展開すると、既定値のままの設定も書き出すか、JetBrains固有のスタイルを含めるか、検査重大度を含めるかを個別に選べます。既定では「変更した設定のプロパティだけ」が保存され、それ以外は各ツールの既定値のままになります。既定値まで書き出す設定にすると出力が一気に増え、どれがチームで決めた項目なのか差分から読み取れなくなります。最初は既定のまま出力し、必要な項目を手で足す進め方が扱いやすいはずです。書き込み前にプレビューが表示され、既存ファイルと値が衝突するプロパティは赤く示されます。

検査の重大度チューニングと、設定が効かないときの確認箇所

規約を決めても、IDEが出す警告が多すぎれば誰も読まなくなります。Riderは検査ごとに重大度を変えられるので、落としたい違反だけをエラーに引き上げ、それ以外を下げるのが実用的な運用です。

重大度の5値と、書き換えの実例

公式のConfigure warningsは構文を[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の機能に限らない話になります。ツール選定の観点は静的解析とは？実行せずに欠陥を見つける仕組みとツールの選び方で整理しています。

保存時の自動整形と、ファイル単位でのクリーンアップ差し替え

ルールを書いても、適用が手動なら守られません。Riderにはファイルを保存したタイミングでコードクリーンアップを走らせる設定があります。

Actions on Saveによる保存時の自動整形

Ctrl+Alt+Sで設定を開き、Tools | Actions on Saveを選び、Reformat and Cleanup Codeをオンにします。ここで適用するコードクリーンアッププロファイルと、ファイル全体に当てるか変更行だけに当てるかを選択できます。変更行だけに絞れば、既存ファイルを開いただけで巨大な差分が発生する事故を避けられます。レガシーコードを抱えたリポジトリでは、この選択をチームで揃えておかないとPRのレビュー負荷が跳ね上がります。

トリガーは明示的な保存に限られる点に注意してください。公式ヘルプは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.と条件を示し、続けて自動保存されたファイルは整形キューに入り次の明示保存でまとめて処理されると説明しています。編集したのに整形されないように見えるときは、まだ明示保存していないだけという場合があります。

特定ファイルの整形除外とプロファイル差し替え

生成物やベンダー提供のソースなど、整形してはいけないファイルは必ず出てきます。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と説明しています。無償かつクロスプラットフォームなので、CIに入れるハードルは低いほうです。使うコマンドは整形のcleanupcodeと検査のinspectcodeの2つで、どちらもjbの下に並びます。

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でのグローバル導入はCIを回すたびに解決される版が変わり、同じコミットでも整形結果が変わり得ます。リポジトリ側でdotnet new tool-manifestとdotnet tool install JetBrains.ReSharper.GlobalToolsを実行し、生成された.config/dotnet-tools.jsonをコミットしておけば、CIはdotnet tool restoreで同じ版を取得します。

git diffによるCleanupCodeの書き換え検知

CleanupCodeはコードを書き換えるツールなので、CIでは「書き換えが発生したら規約違反」と解釈します。公式のCleanupCode Command-Line Tool自身が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を続ければ、差分が出た時点でジョブが失敗します。

設定の読み取り経路も押さえておきます。CleanupCodeは.DotSettingsファイルから整形ルール・構文スタイル・C#のファイルと型のレイアウトを読み、--settingsパラメータで共有設定ファイルのパスを明示することもできます。そのうえで、EditorConfigに書いたコードスタイルプロパティは同じ項目のRider設定を上書きします。ローカルと同じ結果を得るには、.editorconfigと.sln.DotSettingsの両方がチェックアウトされている必要があります。

InspectCodeの出力形式と最低重大度

InspectCodeは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エージェントの変更に対する品質チェックフック

CIはPRを出した後の関門です。エージェントにコードを書かせる運用では、その手前で規約を当てられるほうが手戻りが小さくなります。Rider 2026.2はこの用途にコード品質チェックフックを追加しました。JetBrainsのリリース記事は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ではRider's quality-check hooks now support Codex in addition to Claude Code.とあり、対応エージェントがCodexにも広がりました。

この仕組みが参照するのは、これまでの章で整えた.editorconfigと.sln.DotSettingsです。規約を正本に集約しておくほど、人・CI・エージェントの3者が同じルールで判定されるようになります。逆に規約が個人のThis computerレイヤーに残っていると、そのIDEで動くフックと、共有設定だけを読むCIとで判定が食い違います。

他言語でも規約をCIに載せる考え方は同じです。TypeScript側の例はBiome v2とは？導入・biome.json設定・ESLint/Prettier移行まで使い方を徹底解説、インフラコード側はTerraformコーディング規約（スタイルガイド）｜fmt・命名規則・ディレクトリ構成の統一ルールが参考になります。

Visual Studio・外部フォーマッタと併用するときの住み分け

チーム全員がRiderを使うとは限りません。混在環境では「誰が規約の正本を持つか」を先に決める必要があります。

Visual Studio単体の環境が混じる場合、resharper_プレフィックスのプロパティは読まれません。共通で守らせたい項目は標準プロパティと.NETコーディング規約プロパティの範囲に収め、Rider固有プロパティは「Riderユーザーの快適さを上げる追加分」と割り切るほうが破綻しません。Visual Studio 2026側の変更点はVisual Studio 2026の新機能｜VS2022との違い・サポート期限・システム要件【2026年最新】にまとめています。Visual StudioにReSharperを入れる選択肢の費用と機能はReSharperとは？使い方・料金・VS Code対応まで2026.2で解説で扱いました。

整形をCSharpierのような外部フォーマッタに任せる構成も選べます。JetBrains Marketplaceにはcsharpierプラグイン（ID 18243）が公開されているので、導入前にMarketplaceの対応ビルド欄で使用中のRiderに対応しているか確認してください。この場合はRider側の整形をdisable_formatter=trueで止め、検査だけRiderに担当させると責務が重なりません。整形ルールを2つのツールに分散させたまま運用すると、保存するたびに整形が打ち消し合う状態になります。

日本語UIの切り替えと、無償で使える範囲

規約の設定そのものではありませんが、Riderを配る前に確認しておく2点です。どちらも2024年以降に仕様が変わっており、古い手順のまま書かれた情報が残っています。

Rider 2024.2以降の言語パック同梱とUI言語の切り替え

「Riderの日本語化にはJetBrains Marketplaceから言語パックを入れる」という手順は、現行版では古くなっています。公式のLanguage and regionはJetBrains Rider is available in English but also includes bundled plugins that support Chinese, Korean, and Japanese.と記載し、中国語・日本語・韓国語の言語パックがRiderに同梱され既定で有効だと説明しています。切り替え手順はよくある質問にまとめました。OSの言語とRiderの言語が違う場合は、揃えるかどうかの提案が表示されます。同じJetBrains系IDEでの日本語化はIntelliJ IDEAでJava開発を始める手順｜インストール・JDK設定・日本語化でも扱っています。

非商用無料ライセンスで使える範囲

Riderは2024年10月24日のJetBrainsの発表で非商用利用が無償になりました。アナウンスは対象をlearning, open-source project development, content creation, or hobby developmentと列挙し、For commercial projects, nothing will changeとして商用プロジェクトは従来どおり有償ライセンスが必要だと述べています。社内の業務コードに使う場合は有償です。JetBrains製品のライセンス体系そのものの整理はRubyMineとは？料金と無料になる非商用ライセンスの条件が詳しいので、購入判断の前に確認してください。

なお、CIで使うReSharper Command Line Toolsは前述のとおり無償です。有償ライセンスを全員分そろえる前でも、規約チェックだけはCIに載せられます。

よくある質問

.editorconfigはどこに置けばいいですか？

ソリューションのルートディレクトリに置き、先頭にroot = trueを書くのが基本です。Riderは現在のファイルのディレクトリから親をさかのぼって.editorconfigを探し、ルートディレクトリに到達するかroot=trueのファイルを見つけるまで適用を重ねます。サブプロジェクトだけルールを変えたい場合は、そのディレクトリにroot指定なしのファイルを追加して差分だけ書きます。

.DotSettingsと.editorconfigはどちらを使うべきですか？

コードスタイルと検査の重大度は.editorconfigに寄せてください。両方に書くと.DotSettings側は必ず負けます。.sln.DotSettingsには、コードクリーンアップのカスタムプロファイル定義など、EditorConfigで表現できない設定だけを残します。

Riderを日本語表示にするにはどうすればいいですか？

設定のAppearance & Behavior | System Settings | Language and RegionでLanguageに日本語を選びます。Rider 2026.2では日本語の言語パックがバンドル済みで既定で有効なため、Marketplaceから別途インストールする必要はありません。一覧に出ない場合は設定のPluginsからInstalledタブを開き、言語パックプラグインのチェックが外れていないか確認します。

CSharpierとRiderのフォーマッタは併用できますか？

併用自体は可能ですが、整形の担当は片方に寄せるべきです。csharpierプラグイン（Marketplace ID 18243）でCSharpierに整形を任せる場合は、対応ビルドを確認したうえで導入し、対象ファイルのマスクにdisable_formatter=trueを指定してRider側の整形を止めます。両方を有効にしたままActions on Saveを使うと、保存のたびに互いの整形結果を上書きし合います。

Visual Studioと比べて規約運用で何が違いますか？

Riderがresharper_プレフィックスのJetBrains固有プロパティを解釈する点と、プロジェクトファイルから参照された.globalconfigのEditorConfig標準プロパティも読む点です。混在環境では標準プロパティと.NETコーディング規約プロパティを共通の土台にし、固有プロパティは追加分として扱ってください。

関連記事

• ReSharperとは？使い方・料金・VS Code対応まで2026.2で解説
• 静的解析とは？実行せずに欠陥を見つける仕組みとツールの選び方
• Visual Studio 2026の新機能｜VS2022との違い・サポート期限・システム要件【2026年最新】
• Terraformコーディング規約（スタイルガイド）｜fmt・命名規則・ディレクトリ構成の統一ルール
• IntelliJ IDEAでJava開発を始める手順｜インストール・JDK設定・日本語化