「AIエージェントがコードを大量生成するほど、コードベースは指数関数的にカオス化する」——このAI開発時代のジレンマに正面から取り組むOSSが、sentrux/sentruxだ。Pure Rust製の単一バイナリで、52言語のコード構造を5つの指標(モジュラリティ・非循環性・深さ・均等性・冗長性)で測定し、0〜10000点の品質スコアを継続的にフィードバックする。Claude Code・Cursor・Codex等のMCP互換クライアントと直接統合し、エージェントが自分の生成物がアーキ品質に与える影響をリアルタイムで把握できる。執筆時点でGitHub Stars 1,400、Forks 126、MIT、最新v0.5.7(2026年3月)。
この記事ではSentruxの仕組みと活用法を解説します。Vibe Coding/AIコーディング全体の見取り図はVibe Coding完全ガイド2026をご覧ください。
この記事のポイント
- AIエージェントがコードを生成→Sentruxが品質を測定→エージェントにフィードバック、という閉ループを実現するセンサー型OSS。
- 5つの根本原因メトリクス(modularity / acyclicity / depth / evenness / redundancy)で0〜10000点の品質シグナルを出力。
- MCP統合でClaude Codeからネイティブに呼び出せる。
/plugin install sentrux一発で導入完了。 - Rust製単一バイナリ・依存ゼロ・52言語対応——導入摩擦が極小、商用OSS(MIT)で恒久無料。
Source: sentrux/sentrux — リアルタイムTreemap可視化。エージェントがファイルを編集すると、該当箇所が即座にハイライトされる。
Sentruxとは:AIエージェント時代の「コード品質センサー」
Sentruxは、「コード生成」に対する「コード品質測定」のフィードバック層として設計されたOSSだ。プロジェクトの説明にこうある——「AIで生成すればするほど、コードベースは機械速度でアーキテクチャ的に劣化する」。
これはAIで開発する全エンジニアが直感的に分かる問題だ。Claude Codeに「この機能を作って」と依頼すると、確かに動くコードが出てくる。だが、
- 同じ責務のロジックが3箇所に重複する
- 循環依存がいつのまにか3〜5箇所生まれている
- 「god file」(数千行のメガクラス)が気づかぬうちに肥大化する
- レイヤリング違反(presentation→infraの直接呼び出し等)が何度も再発する
これらはコンパイルは通る・テストもパスするが、長期メンテナンスが破綻するタイプの劣化だ。Sentruxは、こうした「目に見えない構造の腐敗」を、エージェントの作業中にリアルタイムで検知する。
| 観点 | 中身 |
|---|---|
| 提供元 | sentrux/sentrux(OSS) |
| ライセンス | MIT |
| 主要言語 | Rust 87.5% |
| 対応言語数 | 52言語(tree-sitter経由) |
| 配布形態 | macOS / Linux / Windows 単一バイナリ + Brew + Homebrew Cask |
| MCP対応 | 完全対応(Claude Code等) |
| GUI | wgpuベースのライブTreemap |
| ライブ更新 | エージェント編集を即座に可視化 |
なぜ今これが必要か:「AI生成→アーキ崩壊」の悪循環
AIエージェントの普及で起きている根本的な変化を、もう少し具体的に見る。「コード生成のスピード」と「アーキ整合性のスピード」には、明確な不均衡がある。
| 指標 | 人間が書いていた頃 | AIエージェント時代 |
|---|---|---|
| コード生成速度 | 100行/時間 | 1万行/時間 |
| 設計判断速度 | 100行/時間 | 100行/時間(人間が判断) |
| アーキ整合性チェック | コードレビュー | 追いついていない |
| god fileが生まれる速度 | 数ヶ月 | 数日 |
「設計の速度はボトルネックのまま、コード生成だけが100倍速くなった」結果、コードベース全体が機械速度で劣化する。これに対する従来の対策は、
- 計画書(Spec/Design Doc):書いた瞬間から陳腐化
- コードレビュー:人間が追いつけない
- 静的解析(SonarQube等):AIネイティブに作られていない
- テストカバレッジ:「動く」は保証するが「設計が崩れない」は保証しない
要するに、AIエージェント時代のために設計されたフィードバックループが必要だ、というのがSentruxの問題提起だ。
Claude Code/Codex] B --> C[コード生成] C --> D[Sentrux
センサー] D -->|品質シグナル
0-10000点| B D -->|可視化| H[人間] H -->|フィードバック| B D -->|ルール違反検知| E[CI/CD] E -->|ブロック| F[マージ拒否]
「エージェントの生成物が、エージェント自身にも、人間にも、CIにも、リアルタイムで見える」状態を作るのが、Sentruxの存在理由だ。
主要機能:可視化・5メトリクス・ガバナンス
Sentruxの提供価値は3層に整理できる。
| 層 | 中身 |
|---|---|
| 可視化(Visualization) | ライブTreemap + 依存エッジ。エージェント編集を即座にハイライト |
| 測定(Measurement) | 5つの根本原因メトリクスから0〜10000点の品質スコア |
| ガバナンス(Governance) | 品質ゲート + ルールエンジンで構造制約を強制 |
Source: sentrux/sentrux — Healthビュー。5メトリクス内訳と品質スコア推移を一覧。
各層の意味を順に展開する。
可視化:「エージェントの編集を目で追える」
GUIを起動すると、プロジェクト全体がTreemapとして表示される。ファイル間の依存関係はエッジで描かれ、エージェントが書き換えたファイルは即座に色変化する。
これは「pair programming with AI」の体験を変える。エージェントが「ここを編集します」と宣言したとき、Sentruxの画面では実際にどこが触られているか、依存にどう影響するかを視覚的に確認できる。
測定:5つの根本原因メトリクス
「コード品質」を曖昧な定義で扱わず、5つの計測可能な根本原因に分解する。
| メトリクス | 意味 | 高い時の症状 |
|---|---|---|
| modularity | モジュール分割の適切さ | 1ファイルに何でも入っている、責務分離不足 |
| acyclicity | 循環依存の少なさ | 相互参照、テスト困難 |
| depth | 階層の深さ | 抽象化が過剰/不足 |
| evenness | サイズの均等性 | 一部のファイルが極端に肥大化(god file) |
| redundancy | 重複の少なさ | 同じロジックが複数箇所、DRY違反 |
これらが0〜10000点の総合品質スコアに統合される。シングルナンバーで品質トレンドを追えるのが、過去のCC(Cyclomatic Complexity)等の単一指標と決定的に違う点だ。
ガバナンス:CIに組み込めるルールエンジン
.sentrux/rules.tomlでプロジェクトルールを宣言できる。
[constraints]
max_cycles = 0 # 循環依存ゼロを強制
max_coupling = "B" # 結合度の上限
max_cc = 25 # 関数複雑度の上限
no_god_files = true # god file禁止
[[layers]]
name = "core"
paths = ["src/core/*"]
order = 0
[[layers]]
name = "app"
paths = ["src/app/*"]
order = 2
[[boundaries]]
from = "src/app/*"
to = "src/core/internal/*"
reason = "App must not depend on core internals"
sentrux check .でこのルールに違反していないか検証できる。CI/CDに組み込めば、「PRがアーキ違反を含んでいたらマージブロック」が成立する。
5つのメトリクスの仕組み:how-it-works
5メトリクスがどう品質スコアを生成するかは、公式の解説図にまとまっている。
Source: sentrux/sentrux — 5メトリクスから0〜10000点の品質スコアを算出する仕組み。
「single number」に統合する設計は、経営層・SRE・開発者全員が同じ言語で品質を語れるようにするためだ。100以上の細かいメトリクスがある SonarQube 系列とは反対のアプローチで、「総合点」で動向を追う。
数値の解釈は概ねこうなる:
| スコア範囲 | 意味 |
|---|---|
| 9000-10000 | エンタープライズ級、長期メンテ前提 |
| 7000-8999 | 健全、改善余地あり |
| 5000-6999 | 黄信号、リファクタ計画を |
| 3000-4999 | 赤信号、アーキ判断が必要 |
| 0-2999 | 危険、再設計を検討 |
インストール:macOS / Linux / Windows 単一バイナリ
SentruxはPure Rust製の単一バイナリで、依存関係ゼロ。導入摩擦が極めて低い。
macOS
brew install sentrux/tap/sentrux
# アップデート
brew update && brew upgrade sentrux
Linux
curl -fsSL https://raw.githubusercontent.com/sentrux/sentrux/main/install.sh | sh
Windows
curl -L -o sentrux.exe \
https://github.com/sentrux/sentrux/releases/latest/download/sentrux-windows-x86_64.exe
ソースからビルド
git clone https://github.com/sentrux/sentrux.git
cd sentrux && cargo build --release
Linux GPU 設定
GUI(wgpu)が動かない環境では、明示的にバックエンドを指定する。
WGPU_BACKEND=vulkan sentrux # Vulkan強制
WGPU_BACKEND=gl sentrux # OpenGL強制
基本的な使い方:CLIコマンド一覧
sentrux # GUI起動(プロジェクトlivemap表示)
sentrux /path/to/project # 指定ディレクトリをスキャン
sentrux check . # ルールチェック(CI互換)
sentrux gate --save . # エージェントセッション前にベースライン保存
sentrux gate . # セッション後に比較・退化を検出
特にgateコマンドが面白い。「エージェントを起動する前にベースラインを保存→作業終了後に比較→品質が落ちていたら警告」という運用が、3コマンドで成立する。これが「AIエージェントの作業に対する自動QA」として機能する。
Claude CodeへのMCP統合:1コマンドで導入完了
SentruxはMCP(Model Context Protocol)に完全対応しており、Claude Codeから直接呼び出せる。導入は1コマンド。
/plugin marketplace add sentrux/sentrux
/plugin install sentrux
他のMCPクライアント(Cursor等)には設定ファイル経由で追加。
{
"mcpServers": {
"sentrux": {
"command": "sentrux",
"args": ["--mcp"]
}
}
}
これでClaude Codeに9つのMCPツール(scan / health / session_start / session_end / rescan / check_rules / evolution / dsm / test_gaps)が追加され、エージェントが自分のコード品質をリアルタイムで把握できるようになる。
MCP連携の全体像はMCPとは何か——Model Context Protocolの仕組みと使い方2026で整理しており、Sentruxはその「自分のコード品質を計測するMCPサーバー」カテゴリの先駆けと位置付けられる。
実例ワークフロー:「品質を落とさない」エージェント運用
実際にSentrux + Claude Codeでどんな会話・ワークフローになるかを見る。
ユーザー: 「ユーザー認証モジュールをリファクタリングして」
Claude Code:
→ scan("/path/to/project") を実行
→ { quality_signal: 7342, files: 139, bottleneck: "modularity" }
Claude Code:
→ session_start() を実行
→ { status: "Baseline saved", quality_signal: 7342 }
→ 作業開始
Claude Code: (リファクタリングを実施)
Claude Code:
→ session_end() を実行
→ { pass: false, signal_before: 7342, signal_after: 6891,
summary: "Quality degraded during this session" }
Claude Code:
「品質が劣化しました(7342→6891)。
bottleneckが modularity → redundancy に移っているので、
作成した同名関数の重複を整理します」
→ 自動で改善
→ session_end() 再実行
→ { pass: true, signal_after: 7401 }
「エージェント自身が品質低下に気づいて、自動で修正する」フローが、Sentrux のフィードバックループだけで成立する。これは人間のレビューの前段階で自動的にコード品質を担保する手段になる。
ルールエンジン詳細:レイヤリング違反の検知
rules.toml の [[layers]] と [[boundaries]] の組み合わせで、Clean Architectureや Hexagonal Architecture を強制できる。
[[layers]]
name = "domain"
paths = ["src/domain/*"]
order = 0 # 最下層
[[layers]]
name = "application"
paths = ["src/application/*"]
order = 1
[[layers]]
name = "infrastructure"
paths = ["src/infrastructure/*"]
order = 2
[[layers]]
name = "presentation"
paths = ["src/presentation/*"]
order = 3 # 最上層
[[boundaries]]
from = "src/domain/*"
to = "src/infrastructure/*"
reason = "Domain must not know about infrastructure (DIP)"
[[boundaries]]
from = "src/presentation/*"
to = "src/domain/*"
reason = "Presentation should depend on application, not domain directly"
これがあれば、「エージェントが間違ってドメイン層からインフラ層を直接呼んだ瞬間、CIで止まる」運用が組める。Clean Architectureを「ドキュメントで守る」のではなく、「コードレベルで実行可能なルールとして守る」転換だ。
52言語対応:tree-sitter プラグインベース
Sentruxの52言語対応は、tree-sitterパーサプラグインで実現されている。プラグインの追加・管理もシンプル。
# 利用可能なプラグインを一覧
sentrux plugin list
# 新しい言語のサポートを追加
sentrux plugin add <name>
# 自前の言語プラグインを開発
sentrux plugin init my-lang
サポートされる主要言語は以下。
| カテゴリ | 言語 |
|---|---|
| システム系 | Rust / Go / C / C++ / Zig |
| Web系 | JavaScript / TypeScript / PHP / Ruby |
| エンタープライズ | Java / Kotlin / Scala / C# |
| データサイエンス | Python / R |
| モバイル | Swift / Dart / Kotlin |
| 関数型 | Haskell / Clojure / Elixir / Erlang / OCaml |
| その他 | Lua / Bash / Perl / Nim 等 |
「プロジェクトの主要言語を切り替えてもSentruxは変わらない」のが運用上大きい。Java→Kotlinや、Python→Goのような移行プロジェクトでも、同じツール・同じメトリクスで連続性を保てる。
競合比較:SonarQube・CodeScene・NDepend との位置取り
「コード品質」「アーキテクチャ分析」のツールは複数存在する。Sentruxの位置取りを整理する。
| ツール | ライセンス | 主言語 | AI連携 | リアルタイム可視化 | 価格 |
|---|---|---|---|---|---|
| Sentrux | MIT | Rust | MCPで直結 | 対応 | 無料 |
| SonarQube Community | LGPL | Java | プラグイン経由 | 限定的 | 無料 |
| SonarQube Enterprise | 商用 | Java | プラグイン | 限定的 | 高価 |
| CodeScene | 商用 | Clojure | API経由 | 対応 | 中〜高価 |
| NDepend | 商用 | C# | API経由 | 対応(Visual Studio) | 中価 |
| Structure101 | 商用 | Java | なし | 対応 | 中価 |
「MCP経由でAIエージェントと直接連携する」点は、現時点でSentruxの独自性だ。SonarQube等の既存ツールはAPI経由で呼び出せるが、「エージェントが自然言語で品質を取得・解釈する」設計にはなっていない。
「AIエージェント時代に最初から設計されたコード品質ツール」というのは、新しいカテゴリだと言える。SonarQubeを置き換えるのではなく、共存して別レイヤーで動く位置取りで、両方を組み合わせる運用が現実的だ。
DSM(Dependency Structure Matrix):構造を行列で見る
Sentruxのdsmコマンドは、Dependency Structure Matrixを出力する。これはモジュール間の依存関係を行列形式で可視化する古典的な手法だが、Sentruxのリアルタイム描画と組み合わさると一段強くなる。
sentrux dsm .
DSMは以下のような構造を見せる。
| UserAPI | OrderAPI | PaymentAPI |
UserAPI | - | 0 | 0 |
OrderAPI| X | - | X |
PaymentAPI| 0 | 0 | - |
X = 依存あり、0 = 依存なし。対角線の上か下かに偏っているとレイヤリングが守れている、バラついていると循環依存がある、と読める。
DSMは1980年代から知られる手法だが、プロジェクト全体の依存構造を1枚の図で見せるのは今でも強力だ。Sentruxは生成・解釈をMCP経由でClaude Codeに委ねられるため、人間がDSMを読み解けなくてもAIに「この行列をどう改善すべきか」と聞けば良い。
test_gaps:テスト未カバー箇所の検出
test_gaps MCPツールは、テストカバーされていない構造的なリスク箇所を検出する。単純なライン・ブランチカバレッジではなく、「依存が密なファイル」「重要なレイヤー境界」でテストが薄い箇所を特定する。
Claude Code: test_gaps()
→ {
gaps: [
{ file: "src/payment/processor.ts",
reason: "High coupling, no integration tests" },
{ file: "src/auth/middleware.ts",
reason: "Layer boundary, only unit tests" },
]
}
エージェントに「これらの場所にテストを追加して」と指示すれば、「テストカバレッジ高いがリスクは残る」という典型的な落とし穴を回避できる。
AIエージェント時代の品質保証:Sentruxの位置づけ
ここまでの整理を踏まえて、独自視点を1つ。Sentruxはコード品質ツールではなく、AIエージェントのための「センサー」として理解するのが正しい、というのが私見だ。
理由は3つ。
1. ループを「閉じる」
人間がレビュアーを務める従来の品質保証は、人間がボトルネックになる。SentruxはMCP経由でエージェントに直接フィードバックすることで、ループから人間を一旦外せる。重要な判断には人間が介入する一方、構造劣化の機械的検知はエージェントとSentruxで自動化する。
2. 「測定可能性」の前提を作る
「アーキテクチャの良し悪し」は曖昧で、エンジニア間の議論を抽象化させがちだった。Sentruxの0〜10000点シングルスコアは、「何点までは許容、何点以下なら緊急対応」という意思決定を可能にする。「品質の言語」が標準化される意味は大きい。
3. AIに任せる範囲を広げる
エージェントに大胆なリファクタリングを任せる際、「品質指標が上がる範囲なら全部任せていい」という安全網が成立する。これはCursor×Claude Opus 4.6が9秒で本番DBを消したPocketOS事件のような暴走事故への防御策にもなる——エージェントが構造を破壊する直前にSentruxが警告を出せれば、人間の介入タイミングが格段に早くなる。
日本企業導入時の論点
日本企業でSentrux導入を検討する場合の現実的な論点を整理する。
| 論点 | 状況 | 取れる対応 |
|---|---|---|
| データ主権 | コードを外部に送りたくない | 完全ローカル動作・MIT |
| エンタープライズサポート | 商用契約が必要なケース | OSSのみのため、ない。GitHub Issuesでサポート |
| Java/.NETレガシー基盤 | 既存システムへの適用 | tree-sitter言語サポートで対応可能 |
| 既存SonarQube投資 | 切り替えではなく併用 | 両方使う——SonarQubeは静的解析、Sentruxは構造監視 |
| 監査人への説明 | OSS導入の説明 | MITで透明性・継続性を強調 |
| 既存CI/CDとの統合 | Jenkins / GitHub Actions等 | sentrux check .はexit codeで終了するため統合容易 |
「SonarQubeから乗り換える」のではなく、「SonarQube + Sentruxの2層体制」で運用するのが2026年時点では現実的だ。SonarQubeはコード品質指標の網羅性、SentruxはAIエージェント時代のリアルタイム性とMCP統合で、役割が違う。
Understand Anythingとの組み合わせ:「構造を測る×意味を理解する」
Sentruxを単独で使うと「構造の劣化を検知できる」が、「なぜそうなったのか」「業務的にどう意味を持つか」の理解は別レイヤーになる。ここで相性が良いのが、コードベースをナレッジグラフ化するOSSプラグインUnderstand Anything(Claude Codeプラグイン・コードベースをナレッジグラフ化)だ。
両者の役割を整理すると、完全な補完関係にある。
| 観点 | Sentrux | Understand Anything |
|---|---|---|
| 主目的 | 構造品質を数値化 | コードを意味的に探索 |
| データ表現 | 5メトリクス + 0〜10000点 | ナレッジグラフ(構造 + ドメイン) |
| 主な利用者 | エージェント・CI・SRE | エンジニア・PM・新人オンボード |
| 強み | リアルタイム劣化検知 | ドメイン知識の可視化 |
| 弱み | 「なぜ劣化したか」の説明力 | リアルタイム性(ビルド型) |
| MCP統合 | あり(9ツール) | あり(Claude Code 1stクラス) |
| ライセンス | MIT | OSS |
Sentruxが「コードの構造を測る」、Understand Anythingが「コードの意味を理解する」——同じ Claude Code エコシステムから両方のMCPツールを呼び出せるため、1つの会話で構造と意味の両側からコードベースを掴める。
併用シナリオ:チームドメインナレッジを「測定可能」にする
新人がコードベースに参画するときの典型的な辛さは、「コードの動きは追えるが、なぜそういう設計なのかが分からない」ことだ。これに対する2026年的なアプローチが、
- Understand Anythingでコードベース全体をナレッジグラフ化 → ドメインの全体像を理解
- Sentruxで構造品質スコアを把握 → どこが「触ってはいけない場所」「リファクタ候補」か理解
- Claude Code経由で両方に質問 → 「このモジュールの目的は?品質スコアは?関連ドメインは?」を1スレッドで取得
新人: 「決済モジュールについて教えて」
Claude Code:
→ Understand Anything: domain_graph(file="src/payment/")
→ { entities: ["Order", "Payment", "Refund"],
relations: [...],
summary: "決済処理は Order → Payment → 外部API → Refund の流れ" }
→ Sentrux: scan(file="src/payment/")
→ { quality_signal: 6800, bottleneck: "redundancy",
flag: "yellow - refactor recommended" }
Claude Code:
「決済モジュールはOrder/Payment/Refundの3エンティティで構成され、
外部API(Stripe)との連携が中心。品質スコアは6800(要改善)で、
ボトルネックは『同名関数の重複』。リファクタ候補としては、
Payment.process() と Order.charge() の重複ロジックを統合することを推奨します」
「ドメイン理解 + 品質状態 + 改善提案」が、人間の口頭説明なしで揃う。この体験が新人オンボーディングを数日 → 数時間に圧縮する可能性を秘めている。
コードレビュー改善:「品質×ドメイン」両軸でレビューする
PRレビューでも両者の併用が効く。
| レビュー観点 | 担当ツール | 提供する情報 |
|---|---|---|
| 「このPRで品質スコアは下がるか?」 | Sentrux gate |
数値で即時判定、CI連携可 |
| 「このPRはドメイン的に正しい場所を変更しているか?」 | Understand Anything | ナレッジグラフでレイヤー責務を確認 |
| 「テストが必要な構造的リスク箇所は?」 | Sentrux test_gaps |
高結合・レイヤー境界を抽出 |
| 「変更箇所がドメイン的に何を意味するか?」 | Understand Anything | 影響範囲を意味的に説明 |
| 「変更が他チームに影響するか?」 | 両方 | 構造(依存)+ 意味(ドメイン)で判定 |
「数値レビューと意味レビューの両側から自動的にPRを評価する」ことが、Claude Codeから両方のMCPを呼ぶだけで成立する。レビュアーの負荷が「読む」から「判断する」に集約されることで、レビューの質を保ったままスループットを上げることができる。
「ドメイン知識をAIに付ける」という考え方
ここで一段抽象化する。「AIエージェントにドメイン・コード知識を継承する」という課題は、2026年のエンジニア組織の大きな関心事だ。これに対する典型的アプローチは:
- CLAUDE.md / AGENTS.md にドメイン知識をテキストで書く
- Cursor Rules / .cursorrules でコーディング規約を伝える
- MCPサーバで外部知識ソースに接続する
- ナレッジグラフ(Understand Anything)で構造化された知識を持つ
- 計測指標(Sentrux)で「良い」状態の客観基準を持つ
1〜3は「テキストや設定で知識を伝える」、4〜5は「ツールを介して自動的に知識を構築・測定する」という違いがある。AIエージェントが実用化される未来では、4〜5のような動的・自動構築型のナレッジ層が主流になる、というのが私見だ。
Andrej Karpathy式 Skills + CLAUDE.mdガイドで扱う「人間が書くドメイン知識」と、SentruxやUnderstand Anythingのような「ツールが自動で構築する知識」は、補完関係にある。両方を組み合わせるのが2026年的なAI協働開発の標準スタックだ。
1年後の予想:Sentruxが定着させる3つの変化
最後に独自視点で1年後の予想を3つ。
予想1:「品質シグナル」がエージェントの標準入力になる
Claude Code・Codex・Geminiなどのエージェントが、起動時に自動でSentruxを呼び出して品質スコアを取得するのが標準動作になる。「現在7300点のプロジェクトを8000点まで改善する」のような目標値ベースの作業指示が、当たり前のプロンプトになる。
予想2:「アーキテクチャの数値化」がコードレビューを変える
「コードレビューでアーキを議論する」のは、Sentruxのスコアという共通言語を持つことで、議論が短くなる。「このPRはスコアを-300する」「-300は許容範囲か」という議論が中心になり、主観的な「美しいコード」議論が減る。
予想3:「企業のコード資産価値」が定量化される
M&Aデューデリ・新システム調達・ソフトウェア資産評価で、「Sentruxスコア」が企業価値の指標として使われ始める。「この会社のコードベースは平均7500点で、競合は4500点」といった比較が経営層レベルで議論される未来が、1年以内に立ち上がる。
まとめ:「AIで生成→AIで品質保証」を可能にするレイヤー
Sentruxは派手な新機能を持つツールではない。「コード構造を測定する」という地味な作業を、MCP経由でAIエージェントに直結することで、新しい価値を出している。
- 個人開発者:Brewで入れて
sentrux一発で使える、無料・OSS。 - 小〜中規模事業者:CIに組み込んで品質ゲートを自動化、SonarQubeと併用。
- エンタープライズ:MIT・自己ホスト・データ主権、Clean Architectureを実行可能ルールに。
- AIエージェント運用:エージェントの暴走を構造的に検知し、自動修復ループを回せる。
「コードを書くスピードが100倍になっても、設計判断のスピードは変わらない」——この本質的な不均衡を、Sentrux + Claude Code/Cursor/Codex が部分的に解決する。AIエージェントを真剣に使うすべてのチームに、検討する価値のあるOSSだ。
FAQ
Q. 既存のSonarQubeは捨てるべきですか?
A. 捨てる必要はありません。 SonarQubeは細かい100+のメトリクス・セキュリティスキャン・コードスメル検出に強く、Sentruxは構造分析・MCP統合に強いです。役割が違うため両方使うのが推奨です。SonarQubeを「静的解析」、Sentruxを「リアルタイム構造監視」と棲み分けると整理しやすいです。
Q. なぜRust製で52言語対応なのですか?
A. パーサとしてtree-sitterを採用しているためです。tree-sitterは多くの言語のCommunityパーサが豊富にあり、Rustから直接利用できます。Sentrux本体はRustで実装しつつ、52言語の構文木解析をtree-sitterに委ねる設計で、新しい言語の追加コストが極めて低いです。
Q. CI/CDに組み込む方法は?
A. sentrux check .をCIで実行し、exit codeで合否判定するのが基本です。GitHub Actionsなら以下のように。
- run: sentrux check .
- run: sentrux gate .
ルール違反や品質低下があれば非ゼロ終了するため、PRをブロックできます。
Q. プライベートコードを外部に送らずに動きますか?
A. 完全ローカル動作です。MCP経由でClaude Codeに繋ぐ場合でも、Sentrux自体はローカルバイナリとして動作するため、コードベース全体が外部送信されることはありません。Claude Codeがクエリを投げる範囲のみが従来通りAnthropicに送信されます。
Q. 0〜10000点のスコアの計算式は公開されていますか?
A. 5メトリクス(modularity / acyclicity / depth / evenness / redundancy)の重み付き合成として算出されます。OSSなのでソースコードを読むことで詳細な計算式を確認できます。MITライセンスで自前にカスタマイズした重み付けを作ることも可能です。
Q. AIエージェントに使わせない場合でも価値がありますか?
A. あります。 Sentruxは人間が単独で使うツールとしても十分機能します。Treemap可視化、5メトリクススコア、ルールエンジンによる構造監視は、エージェントなしでも有用です。MCP統合は追加で得られる価値と考えてください。
Q. コードベースの巨大さに上限はありますか?
A. 公式に明記された上限はありませんが、100万行以下程度のプロジェクトなら快適に動きます。それを超える超大規模プロジェクト(モノレポ等)では、sentrux scan の実行時間と、GUIのTreemapレンダリング負荷を考慮する必要があります。
Q. test_gaps と通常のカバレッジツールの違いは?
A. 通常のカバレッジ(jacoco、go cover等)は「コードの行が実行されたか」を測ります。Sentruxのtest_gapsは「依存が密で重要な構造的箇所がテストされているか」を測ります。「カバレッジは100%だがリスクは残る」ケースを補完する用途です。
Q. 自前のメトリクスを追加できますか?
A. v0.5.7時点では5メトリクスは固定ですが、MITライセンス・Rust実装なので自前のメトリクスを追加してビルドすることが可能です。コミュニティへPRを送る選択肢もあります。
Q. Vibe Codingとの関係は?
A. Vibe Coding完全ガイド2026で扱う「AIエージェントと協働する開発スタイル」を、構造品質の観点から下支えするツールがSentruxです。Vibeコーディングのスピードを活かしつつ、構造劣化を防ぐ仕組みとして機能します。
Q. Understand Anythingとどう使い分けますか?
A. Sentruxは「構造品質を数値化する」、Understand Anythingは「コードを意味的に探索する」——役割が違うため併用するのが正解です。同じClaude Codeから両方のMCPツールを呼び出せるため、1スレッドで「構造の劣化検知」と「ドメイン理解」を両立できます。新人オンボーディング・PRレビュー・大規模リファクタの場面で特に効果的です。
Q. チームでドメイン知識を継承するにはどう組み合わせるのが理想?
A. Understand Anythingでドメイン構造を可視化 → SentruxでアーキスコアをCIに乗せる → CLAUDE.md/AGENTS.mdに人間視点の補足を書く、という3層スタックが現実的です。テキスト・グラフ・スコアの3形式でナレッジを多重化することで、AIエージェントも人間も同じコードベースを共有できます。