sliderule

SlideRule

SlideRule は、1 つの C# 仕様を適用し、コーディングエージェント向けに同じルールを表示する .NET アーキテクチャチェッカーです。

長く運用されているコードベースには、レイヤー、境界、ルールがあります。それらは一部の人の頭の中にしかなく、ビルド時に確認する手順もなく、図は実態からずれていきます。変更が境界を越えても、ビルドは成功することがあります。コーディングエージェントは、その変更をすばやく、もっともらしく行いますが、どの壁が構造上のものかを把握できません。SlideRule が提案するのは、アーキテクチャをコードとして扱うことです。ルールを 1 つの C# 仕様にまとめ、その仕様からこのページで紹介するすべての形式を生成します。

1. 適用。 1 つのチェッカーが、コマンドライン、CI、ビルド、名前付き xUnit テストでルールの合否を判定します。Claude Code フックは、エージェントのターン終了時に同じチェックを実行します。
2. エージェント向けコンテキスト。 ルールは、管理対象の AGENTS.md ブロック、ディレクトリごとのルールカード、コーディングエージェント向けの MCP クエリツールに変換されます。

SlideRule はプレアルファ版です。1.0 より前は、マイナーバージョンで仕様 API が変更される場合があります。ステータスでは、現在の機能とバージョニングのルールについて説明しています。

ツールをインストールし、ソリューションをビルドして、チェックします。

dotnet tool install -g SlideRule.Cli
dotnet build MyApp.sln
sliderule check MyApp.sln

check は、仕様プロジェクト（ソリューション内の C# クラスライブラリ）からルールを読み込みます。まだ仕様プロジェクトがないソリューションでは、check は処理を停止し、見つからなかったことを報告します。はじめにのページでは、SlideRule パッケージを使って仕様プロジェクトを作成します。また、sliderule graph はルールを設定する前にソリューションを調査します。

ルールは 1 つのステートメントです。

arch.Rule("layering/domain-independent")
    .Enforce(domain.MustNotReference(application, infrastructure, api))
    .Because("The Domain holds the quote and rate model the rest of the subsystem is built on; it stays free of the layers that depend on it so it can be reasoned about and tested on its own.")
    .Fix("Move the dependency out of Domain: define an interface here and implement it in the outer layer that needs it.");

ルールはこれだけです。ID、姿勢、制約、理由、修正方法を含みます。ここでは姿勢が Enforce で、domain と、それが参照してはならない 3 つのレイヤーは、仕様の先行部分で名前空間パターンによって宣言されています。このルールはクリーンアーキテクチャのサンプルに含まれており、CI はルールの対象となるコードベースに対して check が成功する状態を維持します。ルールには、その理由の根拠となるページを引用したり、手本としてコピーする型を指定したりすることもできます。仕様の記述でその方法を紹介しています。

エージェントがルールに違反した場合

上記のようなルールは、このリポジトリにも適用されます。そのうちの 1 つは、MCP サーバーがこのチャネルで JSON-RPC を通信するため、CLI が stdout に出力しないようにしています。エージェントが CLI に進捗表示を追加しようとして、Console.WriteLine を使うとします。エージェントがターンを終了しようとすると、hooks/ にある Claude Code の Stop フックが作業ツリーに対して check を実行します。ルールが失敗し、フックは次のレポートをエージェントの stderr に出力して停止をブロックします。

FAIL cli/no-stdout — The Host layer must not use `Console.Out`, `Console.Write()` or `Console.WriteLine()`.
  because: Stdout is a protocol channel here — the MCP server speaks JSON-RPC over it and CLI output flows through System.CommandLine's console — so a direct Console write corrupts the wire and is invisible to the in-process tests.
  citation: https://modelcontextprotocol.io/specification/2025-06-18/basic/transports#stdio
  fix: Write CLI output through the command's InvocationConfiguration console; route server diagnostics to the logger or Console.Error.
  subject: 196 types, 1 generated
  src/SlideRule.Cli/Rendering/ProgressPrinter.cs:10 — SlideRule.Cli.Rendering.ProgressPrinter uses System.Console.WriteLine()
  src/SlideRule.Cli/Rendering/ProgressPrinter.cs:15 — SlideRule.Cli.Rendering.ProgressPrinter uses System.Console.WriteLine()

レポートには、ルール、その理由、引用、修正方法、違反している各行が表示されます。subject: 行は、ルールの対象に生成コードが含まれる場合にのみ表示されます。ここでは対象の 195 型のうち 1 つが該当しています。エージェントは出力をコマンドのコンソール経由に切り替え、次の停止時には問題がなくなります。

SlideRule 自身への適用のページでは、このリポジトリ独自の仕様が、生成される文章からコードスキャン、グラフまで、ほかの形式にもどのように反映されるかを紹介しています。また、両ページに掲載されているすべての抜粋が、どのように原文と一致する状態に保たれているかも説明しています。

4つの姿勢

すべてのルールは最初の2つのいずれかを持ち、すべてのスコープは最後の2つのいずれかを持ちます。

姿勢	内容	失敗する条件
Enforce	法律	ルールより前からある違反も含め、すべての違反
Migrate	件数を記録したベースライン上のラチェット	新たな違反。ベースラインに記録された箇所は警告されません
Quarantine	スコープの隔離	スコープへの新たな参照
Caution	新しい呼び出し元が使う可能性のあるコードに潜む危険	失敗することはありません。コードに触れる変更があると警告されます

Migrate は、コードがまだ守れていないルールに使います。sliderule baseline init はルールに対する現在の違反を記録し、それ以降、新たな違反があると失敗します。箇所を修正するたびに、sliderule baseline accept-reductions でベースラインを縮小し、空になると status がルールを Enforce に昇格するよう提案します。

スコープは、慎重な対応が必要なコードを示します。そこに潜む危険についての注意書きは、コードが脆弱な理由と、どのように呼び出すかを説明します。render は、それらをスコープのディレクトリにカードとして表示します。Quarantine は、スコープへの参照もベースラインに記録し、BoundaryOnlyVia で指定された表面を通る場合を除き、新しい参照があると失敗します。どちらの種類のスコープも、check --diff-base <ref> を指定すると、変更がスコープに触れた場合に警告します。仕様の記述のページでは、各姿勢をコードで示しています。また、SlideRule の運用では、捕捉から昇格までのラチェットの進め方を説明しています。

Enforce の後に続く3つの姿勢はそれぞれ、既存のコードベースでコーディングエージェントが犯しがちな間違いに対応します。Enforce はコードがすでに守っている法律であり、それに抵触する変更は、チェックが実行される場所ならどこでも失敗します。Meridian の例では、実際の出力を使って、そのうち3つの間違いを紹介しています。

• エージェントは多数派のパターン、つまり統計的な事前分布を模倣します。Meridian の8つのコントローラーのうち6つが SqlConnection を開くため、インライン SQL がプロジェクトの標準的なスタイルに見え、エージェントは次のコントローラーも同じように書きます。これに対応するのが Migrate です。レンダリングされたコンテキストで、そのパターンが負債であることを、エージェントが書き始める前に読む言葉で伝えます。
• エージェントは、役立つリファクタリングとしてゲートウェイを取り除きます。モジュール内のパブリック型は、手前にあるゲートウェイを迂回した直接呼び出しを誘発します。Quarantine スコープを使うと、そのゲートウェイが唯一認められた入口になります。
• エージェントは、構造上の奇妙さを修正します。値が飛び飛びになったチェックディジット表はバグに見えますが、連続した値にすると実在するすべてのコンテナー番号が壊れます。Quarantine または Caution スコープに記された危険が、これに対応します。そのスコープのディレクトリにあるカードには、コードの動作、構造上の要素、呼び出し方が説明されています。

1 つの仕様から生成されるもの

以下の各ターゲットは、同じモデルを読み取ります。違反レポートにはそれぞれ、ルール ID、生成されたルール文、理由、正確な file:line が記載されます。ルールに修正方法、引用、例がある場合は、それらも併せて表示されます。

ターゲット	内容
sliderule check	コマンドラインと CI 向けの、合格か不合格かを示す単一の判定
check --sarif	コードスキャン向けに、判定を SARIF 2.1.0 形式で出力
xUnit adapter	すべてのルールを、個別に名前を付けたテストとして出力
build analyzer	破られたルールをエディター上の波線と、ビルド時のコンパイラー警告として表示
sliderule render	管理対象の AGENTS.md ブロック、ディレクトリごとのルールカード、モデルを含む JSON ファイル
render --diagram	プロジェクトとその参照関係、および仕様の法則を示す 2 つの Mermaid 図
sliderule mcp	arch_check、arch_status、arch_explain、arch_context、arch_graph と、derive_spec プロンプト
sliderule hook	Claude Code エージェントのターン終了時に実行する check。ルールに違反すると停止をブロックします

アダプターの失敗メッセージは、CLI のものとバイト単位で完全に一致します。両者は 1 つのレンダラーを共有しており、プロダクトテストで同一であることを固定しています。管理対象のブロックと sliderule explain も、エージェント向けに作成され、人にも読みやすい、生成されたアーキテクチャドキュメントです。SlideRule 自体に対する SlideRule の実行のページでは、最新の状態を維持するゲートを紹介しています。

Coding agentsのページでは、どのエージェントが AGENTS.md ファイルを読み、各サーフェスを利用するかを説明しています。また、独自の CLAUDE.md を持つリポジトリが Claude Code 向けに追加する行も記載しています。

ArchUnitNET および NetArchTest との比較

NetArchTest と ArchUnitNET は、ユニットテスト内でアーキテクチャルールを実行し、その用途に優れています。SlideRule はルールをテストコードから 1 つの仕様に移し、その仕様から上記のすべての形式を生成します。

ツール	記述するもの	実行場所
NetArchTest	テストメソッド内の流れるようなアサーション	テストランナー
ArchUnitNET	テストクラス内の ArchUnit 形式のルール	テストランナー
SlideRule	専用プロジェクト内の 1 つの仕様	上記のすべてのターゲット

文法はこれらの先行ツールを調査して作られており、GRAMMAR.md に各相違点が記録されています。制約は動詞で否定形にします（MustNotReference）。これは ArchUnitNET に倣ったものです。ArchUnit の FreezingArchRule は、ルールの現在の違反をベースラインとして受け入れます。この機能に相当するのが、違反数をベースラインとして数える Migrate です。Quarantine は同じラチェット方式をコード領域に適用し、その領域への現在の参照を数え、認可された窓口を迂回する新たな参照があれば失敗させます。

Because は必須です。これがないルールは無効な仕様となり、check は何も評価する前に停止して、すべての仕様エラーを一度に報告します。述語のエスケープハッチである Must(condition, description:) でさえ、説明がなければコンパイルできません。理由はすべて、生成されたコンテキストを通じてエージェントに渡されます。Interchange の例では、12 個のルールそれぞれに Citation があり、理由の根拠となる learn.microsoft.com のページを指定しています。その 12 個のうち 9 個は、静的メソッドを含む通常のクラスライブラリである共通ルールパックに由来します。引用情報はパックが管理し、仕様は適用方針を選びます。このパックは、このリポジトリ内の実例であり、公開パッケージではありません。独自のパックは、依存するレジストリを必要とせず、リポジトリ内のクラスライブラリとして作成できます。

既存のコードベースで始める

SlideRule は、アーキテクチャが実在する一方で、一部の人の頭の中にしかない、長期間運用されるビジネスクリティカルな .NET コードベース向けに作られています。最初のルールは自分で記述することも、Getting started にあるように、derive_spec プロンプトを使ってエージェントに下書きさせることもできます。エージェントが提案するルールはすべて確認し、コミットする前に採用、編集、または破棄します。

対応するケース

実際のソリューションは、単一の形に収まることはほとんどありません。各行には、ひとつのケースと、それに対してチェッカーが行う処理を記載しています。各ケースが導入されたリリースは、変更履歴に記録されています。

ケース	チェッカーの処理
リンクされたソースファイル	共有ファイルの参照を、コンパイルするプロジェクトごとに一度読み取ります
マルチターゲットプロジェクト	ひとつのプロジェクトを、ひとつのフレームワークのメンバーと階層で読み取り、すべてのフレームワークの参照を読み取ります
複数のプロジェクト、またはパッケージにも存在する同じ型名	各参照に対するコンパイラーのバインディングに従います
生成されたコード	プロジェクトごと、およびルールの対象ごとに数えます
複数の言語を使うソリューション	読み取れない F#、VB、SQL の各プロジェクト名を示します
一元化されたパッケージ管理を使用するリポジトリ	derive_spec のスキャフォールドは、Directory.Packages.props の下でビルドできます
非 SDK スタイルの .NET Framework プロジェクト	Framework ビルドホストを介して読み込みます。 .NET Frameworkを参照してください
実際のビルドの binlog	check --binlog で再生します。.NET Frameworkを参照してください
ソリューションフィルター	フィルターを適用した実行でチェックされなかったプロジェクトを一覧表示します。コマンドラインリファレンスを参照してください
同じソリューションに対する2回目の実行	永続化されたキャッシュを再利用し、変更されたプロジェクトと、宣言が変更された場合はその依存プロジェクトのみを再抽出します
メソッド本体だけの編集	編集されたプロジェクトのみを再抽出します

チェッカーが読み取れない言語のプロジェクトがあると、モデルは縮小されます。チェック、ステータス、グラフの各ドキュメントには、その理由とともに該当プロジェクトが一覧表示され、実行はそのまま結果を返します。サーベイである sliderule graph には、マルチターゲットプロジェクトの共有型が従うフレームワーク名が示されます。また、2つのプロジェクト、またはプロジェクトとパッケージの両方で宣言されているすべての型名も一覧表示されます。ルールの対象に .Authored() を指定すると、そのルールは生成されたコードに適用されません。

編集後のチェックでは、再抽出するプロジェクトと、それらが参照するプロジェクトのみを読み込みます。これは、エージェントのターン終了時に hook が実行するチェックであり、その出力はコールド実行時の出力とバイト単位で一致します。コマンドラインリファレンスには、このようなチェックでソリューション全体を読み込むケースが記載されています。

.NET Framework

このツールは .NET 10 で動作します。チェック対象のコードベースは .NET 10 である必要はなく、それを規定する仕様も同様です。

仕様プロジェクトは net48 をターゲットにし、そのフレームワークの既定の言語レベルである C# 7.3 でコンパイルできます。他のすべての仕様と同じ netstandard2.0 の SlideRule パッケージを参照し、CLI はビルドされた DLL を分離されたロードコンテキストで読み込みます。typeof() による製品型への参照は、その型と依存先がすべて netstandard2.0 内に収まっている限り機能します。それを超えるもの、たとえば .NET に対応する型が存在しない .NET Framework の型は、名前空間パターンで指定します。DerivedFrom などのフィルターも、型の完全名を文字列として受け取ります。どちらもアセンブリの読み込みは必要ありません。

旧形式のプロジェクトファイルも読み込めます。非 SDK 形式の Framework プロジェクトとは、2003 MSBuild XML 名前空間を使用し、<Reference> 項目を明示し、AssemblyInfo.cs を手動で管理する形式です。Roslyn に同梱されている .NET Framework ビルドホストを通じて読み込まれ、他のものと同様に file:line 形式でレポートされます。

FAIL data-access/no-inline-sql — Types in `Classic.*` must not reference types in `System.Data.*`.
  Classic.Billing/BillingCalculator.cs:10 — Classic.Billing.BillingCalculator references System.Data.SqlClient.SqlConnection

check --binlog は、独自のデザイン時ビルドの代わりに、同じマシンでソリューションを実際にビルドしたときのバイナリログを再生します。ログは .NET Framework の MSBuild.exe から取得できます。ログを再生した場合とワークスペースを直接開いた場合とで、バイト単位で同一の出力が生成されます。

非 SDK 形式のプロジェクトの読み込みと、.NET Framework の MSBuild.exe から取得したログの再生には、どちらも Windows が必要です。Framework ビルドホストと MSBuild.exe は Windows に付属しているためです。コマンドラインリファレンスでは、ツールが使用する Visual Studio または Build Tools のインストール先と、その選択方法を説明しています。net48 の仕様プロジェクトにはそのような要件はなく、どこでもビルドできます。

例

examples/ にある、手順を詳しく示した6つの例は、架空の貨物運送会社を共有しています。そのうち4つはソリューションです。CI はそれぞれをビルドし、コミット済みのツリーに対して check が成功する状態を保ち、render --check を実行して、render が examples/ の下に出力するすべてのファイルが最新であることを確認します。

• 強制のみのクリーンアーキテクチャ：新規開発の見積もりサブシステムです。4層のクリーンアーキテクチャを9つのルールで規定し、各ルールを名前付きの xUnit テストとして実行します。

• 1つのコードベースにおける4つの姿勢のうち3つ：移行中のモノリスです。法則、3つのラチェットとそのバーンダウン、そして1つの隔離されたスコープがあります。

• 法則としてのモジュール分離：モジュラーモノリスです。各モジュールディレクトリに、レンダリングされた専用のルールカードがあり、1つのモジュールはファサードの背後に隔離されています。

• Microsoft のガイダンスを適用し、出典を明記：クックブックのページです。各ルールについて、標準文、仕様の抜粋、実際の違反例を示します。

残りの2つは、Meridian モノリス上のフローを、出力を記録しながらたどります。

• 既存のコードベースへの初日の導入：derive フロー全体を、実際の出力を伴う実際のコマンドで一つずつ実行します。

• フックで完結するエージェントループ：上記のループを、ストーリーボードに沿って一つずつたどります。貼り付けて使えるフック設定も含まれています。

インストール

CLI は .NET グローバルツールであり、実行するマシンには .NET 10 SDK が必要です。Getting started の要件では、SDK 10 未満を指定する global.json があるリポジトリ内へのインストールを含め、その他の要件を説明しています。

コマンドラインリファレンスでは、各コマンドのオプションと終了コード、プロジェクトの読み込みに失敗した場合やソリューションフィルターで対象が絞り込まれた場合の実行内容を説明しています。

コマンドは sliderule です。1 つのリリースは、バージョンが連動する 4 つのパッケージで構成されます。仕様プロジェクトでは、sliderule --version が出力するバージョンの SlideRule を参照します。

パッケージ	内容
SlideRule.Cli	sliderule グローバルツールです。check、render、explain、status、graph、baseline、hook と、MCP サーバー（sliderule mcp）を提供します。
SlideRule	依存関係のない仕様コントラクトです。仕様を記述する際、不正な文字列リテラルをコンパイラー警告として報告するアナライザーと、名前空間名および型名の補完機能を備えています。
SlideRule.Xunit	xUnit アダプターです。各ルールを個別の名前付きテストとして扱います。
SlideRule.Analyzers	ビルドアナライザーです。モデルファイル（render --model で書き出されます）を読み込み、壊れたルールをエディターでは波線で、dotnet build ではコンパイラー警告として示します。

SlideRule の運用では、リリースに合わせてツールとパッケージのバージョンを揃える方法を説明しています。

MCP クライアントの接続

MCP クライアントは mcp コマンドで同じツールを起動します。サーバーは stdio で通信します。.mcp.json の形式は次のとおりです。

{
  "mcpServers": {
    "sliderule": {
      "command": "sliderule",
      "args": ["mcp", "MyApp.sln"]
    }
  }
}

MCP レジストリから生成された設定では、ソリューションは渡されません。その場合、サーバーは各コマンドと同じように、コミット済みの sliderule.json から、または作業ディレクトリから上の階層へたどってソリューションを検索します。見つからない場合は、インストール時にバインドしてください。コーディングエージェントのページでは、バインド方法、ツール、derive_spec プロンプトについて説明しています。

ドキュメント

• Getting started：仕様なしの状態からチェックが成功するまで、最初の実行手順を説明します。

• Writing specs：ルールの構成要素、姿勢とスコープ、ルールが対象とする範囲を説明します。

• Coding agents：コンテキストファイル、MCP サーバー、フックについて説明します。

• Operating SlideRule：CI、ラチェット、ビルドアナライザー、アップグレード、失敗した実行について説明します。

• Command-line reference：すべてのコマンド、オプション、終了コード、ドキュメントを説明します。

• GRAMMAR.md：言語リファレンスです。

• SlideRule on itself：このリポジトリ自身の仕様を、独自のコードに対してチェックし、レンダリングします。

ステータス

SlideRule 0.1.0 は初回リリースです。このページにあるすべての機能は現在利用でき、4 つすべての評価モードで評価が実行されます。SlideRule 自身での SlideRule では、このリポジトリのコードに対してこれらの機能を実行する様子を確認できます。また、CI はその check --sarif の実行結果をコードスキャンにアップロードします。例外はビルドアナライザーで、4 つのサンプルソリューションで実証済みです。流れるように記述できるインターフェースは今後変更される可能性があります。GRAMMAR.md がその仕様であり、語彙表はリリース済みの API から生成されています。

パッケージのバージョンは、0.x のセマンティックバージョニングに従って一緒に更新されます。仕様 API に変更があるたびに、変更履歴の「破壊的変更」に記載され、互換レイヤーなしでリリースされます。パッチバージョンでは仕様 API に変更はありません。JSON ドキュメントは、構造が変わると schemaVersion が更新されます。人が読めるレポートには、どのリリースでも行が追加される可能性があります。テストでは、利用者がコンパイル時に参照する 2 つのパッケージ SlideRule と SlideRule.Xunit の公開インターフェースを固定しています。そのインターフェースは仕様言語とアダプターのテスト基底クラスであり、それらを支えるエンジンは内部実装です。また、パッケージ作成時にインターフェースを前回のリリースと比較するため、変更が誤って紛れ込むことはありません。

ビルド

dotnet build SlideRule.slnx
dotnet test SlideRule.slnx

SlideRule 自体の開発については、CONTRIBUTING.md をご覧ください。

ライセンス

MIT