Microsoft AI Engineer Coach完全解説：VS Code拡張でAIコーディング習慣を可視化・診断・改善する45ルール

microsoft/ai-engineer-coach

ai-coding vscode microsoft AIコーディング dev

2026.05.23 2分更新 2026.05.23

Microsoft AI Engineer Coach完全解説：VS Code拡張でAIコーディング習慣を可視化・診断・改善する45ルール - AIツール日本語解説 | AI Heartland

AIコーディングツールを使っているつもりで非効率なエンジニアは多い。AI Engineer CoachはセッションログをローカルでAI分析し、YOLO承認・プロンプト短縮・セッションドリフトなど45のアンチパターンを自動検出。使うだけで習慣の盲点が見える。

AIコーディングアシスタントは「使っている」と「正しく使えている」の間に大きな差があります。GitHub Copilotを毎日使いながらも、プロンプトは短く、生成されたコードを確認せずに承認し、一つのセッションで全く関係のない作業を混在させているエンジニアは珍しくありません。

Microsoft AI Engineer Coach（以下AEC）は、そうした習慣の盲点を可視化するためのVS Code拡張機能です。2026年5月にMicrosoftのエンジニアチームがOSSとして公開し、リリースから2週間で554スターを獲得しました。

AIコーディング全体のツール選定については Vibe Codingとは？AIコーディングの始め方・ツール比較・実践ワークフロー2026 で体系的にまとめています。

AI Engineer Coach とは — Microsoft OSSが作るアンチパターン診断エンジン

AI Engineer Coachは「better agentic engineering」をスローガンに掲げ、AIコーディングアシスタントの使用状況をローカルで分析してダッシュボードに可視化します。

中核となる機能は3点です。

1. マルチハーネス対応のセッション解析
GitHub Copilot（VS Code）、Claude Code、OpenCode、Codex、Xcodeの5ハーネスに対応します。複数のAIコーディングツールを使い分けているエンジニアでも、一つのダッシュボードで横断分析が可能です。

2. 45のアンチパターン検出ルール
Prompt Quality・Session Hygiene・Code Review・Tool Mastery・Context Managementの5グループに分類された45のルールが、パターンを自動検出します。各ルールはMarkdown + DSLで記述されており、プロジェクト固有のルールを追加カスタマイズできます。

3. 完全ローカル処理・ゼロテレメトリ
セッションログの解析はすべてマシン上で完結し、データは一切外部サーバーに送信されません。VS Code組み込みのCopilot言語モデルAPIを使うオプション機能（ルールコンパイラ、コンテキストレビュー）を除き、外部接続は発生しません。

拡張機能の著者はSanjay Singh、Joy Distelbrink、Tamas Boncz、Aymen Furterの4名。Microsoftの公式プロダクトではなくコミュニティ主導のOSSですが、microsoft組織下で公開・メンテナンスされています。

ポイント
AI Engineer CoachはMicrosoftの公式製品ではないオープンソースプロジェクトです。「Microsoft製品としての保証やサポートはない」と明記されています。MITライセンスで利用・改変・再配布は自由です。

対応ハーネスとセッションログの仕組み

AECが解析できるハーネスは現時点で5種類です。各ハーネスはそれぞれ異なる場所にセッションログを保存しており、AECのパーサーが各フォーマットを解釈します。

ハーネス              ログ保存先（デフォルト）
──────────────────────────────────────────────────
VS Code / Copilot    ~/.vscode/logs/
                     %APPDATA%\Code\logs\ (Windows)
Claude Code          ~/.claude/projects/
OpenCode             ~/.opencode/logs/
Codex                ~/.codex/logs/
Xcode AI             ~/Library/Developer/Xcode/

AECのソースコード（src/core/）を見ると、ハーネスごとに独立したパーサーが実装されています。

src/core/
├── parser-claude.ts        # Claude Code専用パーサー
├── parser-codex.ts         # Codex専用パーサー
├── parser-opencode.ts      # OpenCode専用パーサー
├── parser-vscode.ts        # VS Code / Copilot専用パーサー
├── parser-xcode.ts         # Xcode AI専用パーサー
├── parser-harnesses.ts     # ハーネス統合レジストリ
└── parser.ts               # 共通パーサーインターフェース

各パーサーは生のログファイルを読み取り、セッション・リクエスト・ツール使用・承認操作・生成コード量などを共通のデータモデルに変換します。変換後のデータはローカルキャッシュ（cache.ts）に保持され、ダッシュボードのすべてのページから参照されます。

解析エンジンの実体は analyzer.ts とその派生である analyzer-dashboard.ts・analyzer-timeline.ts・analyzer-patterns.ts・analyzer-context.ts です。スコープ別（セッション単位・リクエスト単位）で統計を集計し、ルールエンジン（rule-engine.ts）に渡してアンチパターンを判定します。

重要な設計思想はリードオンリーです。AECはセッションログファイルを読み取るだけで、内容を変更することは一切ありません。

インストールとクイックスタート

2026年5月時点では、VS Code Marketplaceへの公開はまだ行われていません。GitHubからクローンしてビルドする手順が必要です。Node.js 20+とVS Code 1.118+が前提条件です。

# 1. クローン
git clone https://github.com/microsoft/ai-engineering-coach.git
cd ai-engineering-coach

# 2. 依存関係インストール
npm install

# 3. vsixパッケージをビルド
npm run package

# 4. インストール（macOS / Linux）
code --install-extension ai-engineer-coach-*.vsix

# 4. インストール（Windows / PowerShell）
code --install-extension (Get-ChildItem . -Filter 'ai-engineer-coach-*.vsix' | Select-Object -First 1).FullName

インストール後の起動手順は以下のとおりです。

コマンドパレットを開く（macOS: Cmd+Shift+P / Windows/Linux: Ctrl+Shift+P）
AI Engineer Coach: Open Dashboard を実行
サイドバーのナビゲーションからページを切り替える

初回起動時はローカルのセッションログをスキャンするため、ログ量によっては数秒から数十秒かかります。スキャン完了後はキャッシュが更新され、以降の起動は即時です。データを最新状態に更新するには AI Engineer Coach: Reload Data コマンドを実行します。

ビルドに失敗する場合は npm run pack（vsce package --no-dependenciesを内部実行）が原因の可能性があります。esbuildがランタイム依存関係をすべてバンドルするため、vsceの依存関係列挙をスキップする設定が必要です。最新のmain ブランチには修正済みのコードが含まれています。

ダッシュボード：4カテゴリ13ページの全機能

AECのUIは「Observe → Measure → Improve → Level Up」の4カテゴリに分類された13ページで構成されます。以下の図はページの全体構成を示しています。

graph LR A["AI Engineer Coach
Dashboard"] --> B["Observe
観察する"] A --> C["Measure
計測する"] A --> D["Improve
改善する"] A --> E["Level Up
向上する"] B --> B1["Dashboard
スコア・週次トレンド"] B --> B2["Timeline
Ganttセッション表示"] B --> B3["Coding Moments
スクリーンショット"] C --> C1["Output
生成コード量"] C --> C2["Burndown
トークン予算"] C --> C3["Patterns
7x24活動ヒートマップ"] D --> D1["Anti-Patterns
45ルール検出"] D --> D2["Rule Editor
ルール作成・編集"] D --> D3["Rule Playground
DSL対話REPL"] D --> D4["Skill Finder
繰返しパターン検出"] D --> D5["Context Health
コンテキスト品質"] E --> E1["Learning Center
パーソナライズ学習"] E --> E2["Achievements
XP進捗ティア"] E --> E3["Agentic SDLC
開発ライフサイクル"] E --> E4["Share
スタットカード"]

Observe：使用状況を「観察する」

Dashboardはメインの概要ページです。プラクティススコアの週次トレンド、日次活動チャート、ワークスペース別のトップ統計が表示されます。スコアは5つのカテゴリ（Prompt Quality・Session Hygiene・Code Review・Tool Mastery・Context Management）ごとに算出され、週次の変化も可視化します。

TimelineはGanttスタイルのセッションタイムラインです。縦軸が日付・横軸が時刻で、各セッションがバーとして表示されます。セッションの重複（並行して複数のAIセッションを走らせている状態）も検出します。1日ごとにドリルダウンして個々のリクエストを確認することもできます。

Coding MomentsはAIコーディングセッション中のスクリーンショットギャラリーです。「ストーリーリール」形式で時系列に並べて閲覧でき、ワークスペースフィルタリングに対応しています。

Measure：生産性を「計測する」

OutputはAI生成コード量の分析ページです。言語別・モデル別・ワークスペース別・ハーネス別に生成LOC（Lines of Code）を集計したテーブルが表示されます。どのプロジェクトで、どのモデルを使って、どれだけのコードを生成しているかを定量的に把握できます。

Patternsは7×24の活動ヒートマップです。縦軸が曜日、横軸が時間帯で、AIアシスタントを使った時間帯の濃度が色で示されます。深夜帯や週末に集中している場合は weekend-overwork・late-night-coding ルールが発火します。

Burndownは月次のAIトークン予算の残量と消費ペースを表示します。v0.1.0時点では一時的に無効化されています。

Improve：習慣を「改善する」

Improveカテゴリが最も重要です。Anti-Patternsページが中核で、残る4ページがそのサポート機能です。

Anti-Patternsは5つのプラクティススコアカードと、発火したルールの一覧を表示します。各ルールにはトリガー条件の説明、具体的な改善アドバイス、実際のセッションデータから抽出したサンプルが表示されます。スコアカードとルール一覧の両方をナビゲーションとして使えるカバレッジヒートマップもあります。

Rule EditorはルールのGUI編集インターフェースです。組み込みの45ルールを閾値調整・有効化・無効化できるほか、新規ルールをビジュアル入力で作成し、実データに対してライブテストできます。

Rule PlaygroundはルールDSLのインタラクティブREPLです。フィールドブラウザ、関数カタログ、メトリクス一覧を参照しながらDSLを試行錯誤できます。独自ルールを書く際の学習コストを大幅に下げます。

Data Explorerはセッションデータのローレベルブラウザです。リクエストフィールドの分布確認、アドホックフィルタリング、DSL記述時のフィールド名確認に使います。

Skill Finderは繰り返し登場するプロンプトパターンを検出し、コミュニティのオープンソーススキルカタログとのマッチングを提案します。「毎回同じ形式のコード説明を求めている」「決まったリファクタリングを繰り返している」といったパターンをスキル化する起点になります。

Context Healthはワークスペースのエージェント対応度を診断します。指示ファイルの存在・品質、devcontainerの設定、カスタムスキルの定義数、MCPツールの設定などをチェックするエージェント準備チェックリストが中心機能です。

Level Up：スキルを「向上する」

Learning Centerは実際の使用データから生成されたパーソナライズドクイズを提供します。クイズ形式とコード比較形式の2種類があり、自分の弱点パターンに合った問題が出題されます。

AchievementsはXPベースの進捗システムです。Bronze → Silver → Gold → Diamondの4ティアで構成され、特定の行動（新しいスキルの作成、セッションの集中度改善など）に対してXPが付与されます。

Agentic SDLCはソフトウェア開発ライフサイクルの各フェーズ（要件定義・設計・実装・テスト・デバッグ・デプロイ・ドキュメント）でAIをどのように活用しているかを可視化します。特定フェーズでのAI活用が薄い場合、改善の示唆を提示します。

Shareはスタットカードの生成機能です。自分のAI利用統計をカード画像として出力し、シェアできます。

45のアンチパターン検出ルール：グループ別詳解

AECの根幹であるアンチパターン検出ルールを、グループ別に詳しく見ていきます。

Prompt Quality：プロンプトの品質

プロンプトの書き方に関するルール群です。AIアシスタントへの指示が適切かどうかを検出します。

lazy-promptingは「短すぎるプロンプト」の検出です。30文字未満のプロンプトがリクエスト全体の30%を超えると発火します。「fix bug」「refactor this」のような文脈のない短い指示は、AIが文脈を推測せざるを得ず、品質の低い回答を生む傾向があります。

verbose-prompt-no-compressionは逆のパターンで、プロンプトが不必要に長く冗長な場合に発火します。文脈を詰め込みすぎてコンテキストウィンドウを圧迫しているケースです。

repeated-promptsは同一または酷似したプロンプトを繰り返している場合に発火します。Skill Finderとの連携で、スキル化の候補として提示されます。

Session Hygiene：セッションの衛生管理

セッションの使い方に関するルール群です。一つのセッションをどう活用するかがAI応答品質に直結します。

session-driftは一つのセッションで4種類以上の異なるタスクタイプを混在させると発火します。バグ修正・機能追加・ドキュメント作成・テスト作成を一つのセッションで行うと、AIのコンテキストウィンドウが散漫になり応答品質が低下します。タスクタイプが変わるたびに新しいセッションを開始することが推奨されます。

mega-sessionsは一つのセッションのリクエスト数が閾値を超えると発火します。長大なセッションは多くの場合コンテキストウィンドウが圧迫されており、後半のリクエストへの応答精度が下がります。

abandon-sessionsは開始したが途中で放棄したセッションが多い場合に発火します。「思ったような回答が得られなかったから諦めた」ケースが多く、プロンプトの改善余地を示唆します。

broken-flow-stateは作業の集中セッション中に不自然な中断が多い場合に発火します。

Code Review：生成コードのレビュー

AIが生成したコードを適切にレビューしているかを検出するルール群です。

yolo-modeはエージェントのツール承認の90%以上が自動承認になっている状態を検出します。ファイル編集・ターミナルコマンド・Web検索などの操作が実質無監督で実行されている高リスクな状態で、深刻度はHIGHです。

セキュリティ観点では特に重要なルールです。--dangerously-skip-permissionsフラグや全ツールの一括自動承認は、意図しないコード変更やシステム操作を招く可能性があります。

speed-acceptはAIが20行以上のコードを返した直後の15秒以内に次のメッセージを送信した場合に発火します。20行のコードを15秒で確認することはほぼ不可能であり、「目を通さずに承認している」ことを示すパターンです。

copy-paste-blindnessはAI生成コードを確認なしにコピーアンドペーストしていると推測される場合に発火します。

Tool Mastery：ツールの習熟度

AIコーディングツールの機能を十分に活用しているかを検出するルール群です。

no-plan-modeはエージェントモードを多用しているにもかかわらず、Planモード（プランニング先行）を一度も使っていない場合に発火します。複雑なタスクをいきなりエージェントモードで実行すると、誤った方向性に進んでしまうケースが多くなります。まずPlanモードでスコープを確認してから実装に移ることが推奨されます。

no-skillsはカスタムスキルが一切作成されていない場合に発火します。繰り返すタスクをスキル化することでプロンプトの品質と一貫性が向上します。

no-slash-commandsはスラッシュコマンドをほとんど使っていない場合に発火します。/fix・/test・/explainのようなコマンドは意図を明示的に伝えるためのツールです。

agentic-no-toolsはエージェントモードで作業しているにもかかわらず、ツールをほとんど使っていない場合に発火します。エージェントの真価は適切なツール活用にあります。

Context Management：コンテキスト管理

AIに渡すコンテキストの品質と効率を検出するルール群です。

cache-hit-starvationはプロンプトキャッシュのヒット率が著しく低い場合に発火します。毎回異なる形式でプロンプトを書いていると、キャッシュが効かずトークンコストと応答速度が悪化します。

excessive-file-contextは必要以上に多くのファイルをコンテキストに含めている場合に発火します。無関係なファイルを大量に渡すとコンテキストウィンドウが圧迫され、モデルが本質的な部分に集中できなくなります。

no-devcontainerは.devcontainer/設定が存在しない場合に発火します。開発環境を定義せずにAIコーディングを行うと、環境依存の問題を再現・修正しにくくなります。

instruction-bloatは指示ファイル（CLAUDE.md・agents.md等）が過度に肥大化している場合に発火します。指示が増えすぎると優先順位が曖昧になり、AIが重要なルールを見落とす可能性があります。

カスタムルールDSL：自分のアンチパターンを定義する

AECのルールはMarkdownファイルで記述されています。フロントマターでメタデータを定義し、detectコードブロックにDSLを書きます。

以下は組み込みのlazy-promptingルールの定義です：

---
id: lazy-prompting
name: Lazy Prompting
group: prompt-quality
severity: medium
scope: requests
version: 1
tags: [prompt, quality, short]
thresholds:
  minChars: 30
  maxRatio: 0.3
  minSample: 10
---

# Description
Detects requests with very short prompts that lack sufficient context.

# When Triggered
9 requests () are under  characters.

# Detection Logic
```detect
scan: requests
match: messageLength < thresholds.minChars AND messageLength > 0
aggregate: ratio
check: ratio > thresholds.maxRatio AND count > thresholds.minSample
examples: "" ( chars)

Tests

{messageText: "fix bug", messageLength: 7} -> triggered
{messageText: "Refactor the authentication middleware to use JWT", messageLength: 48} -> clean

カスタムルールを作成する際のDSLキーワードは以下のとおりです：

| キーワード | 意味 |
|---|---|
| `scan` | スコープ指定。`requests`（リクエスト単位）または`sessions`（セッション単位） |
| `match` | フィルタ条件。論理演算子`AND`・`OR`・`NOT`が使える |
| `aggregate` | 集計方法。`count`・`ratio`・`sum`など |
| `check` | 最終判定条件。閾値との比較 |
| `examples` | ダッシュボードに表示するサンプルのテンプレート |
| `thresholds.*` | フロントマターで定義した閾値への参照 |

独自ルールの例として、「4時間以上継続するセッション」を検出するルールを書いてみます：

```yaml
---
id: ultra-long-session
name: Ultra Long Session
group: session-hygiene
severity: medium
scope: sessions
version: 1
tags: [session, focus, duration]
thresholds:
  maxDurationMs: 14400000
  minOccurrences: 3
---

# Description
セッションが4時間を超えて継続している場合を検出します。

# Detection Logic
```detect
scan: sessions
match: durationMs > thresholds.maxDurationMs
aggregate: count
check: count >= thresholds.minOccurrences
examples: : h session

Rule PlaygroundではDSLをリアルタイムで実データに対してテストできるため、閾値の調整とデバッグが容易です。

<div class="point-box">
<strong>チームへの応用</strong><br>
カスタムルールはプロジェクトリポジトリ内のディレクトリに配置して共有できます。チーム独自の開発ガイドライン（「テストコードなしのコミットを促すプロンプトはNG」など）をルールとして定義し、全員のダッシュボードに展開することができます。
</div>

## Context Health：エージェント対応度の診断

Context Healthページは、ワークスペースがエージェントAI開発に対応できているかを診断します。チェック内容は大きく3つに分かれます。

**エージェント準備チェックリスト**では以下の項目を確認します：

- CLAUDE.md / agents.md / GEMINI.md などのAI指示ファイルの存在と品質
- `.devcontainer/` による開発環境の標準化
- カスタムスキルの定義数と品質
- MCPサーバーの設定数
- スラッシュコマンドの活用状況
- Plan Modeの使用頻度

各項目はGreen / Yellow / Redのステータスで表示されます。

**ワークスペースコンテキストマップ**はリポジトリ内のAI関連設定ファイル（CLAUDE.md・agents.md・.devcontainer・スキルファイル等）を一覧し、相互の関係を可視化します。

**AI指示ファイルレビュー**はオプション機能です。VS Code組み込みのCopilot言語モデルAPIを使って、CLAUDE.mdなどの指示ファイルの内容をAIがレビューし、「曖昧な記述がある」「矛盾するルールがある」「重要なコンテキストが欠落している」などの改善提案を生成します。

この機能はユーザーが明示的に呼び出した場合のみ動作し、自動的にデータを送信することはありません。

## 他ツールとの機能比較

AI Engineer Coachは「個人の AI コーディング習慣の分析」というカテゴリでは現時点でほぼ唯一の本格実装です。類似するアプローチのツール・機能と比較します。

| 観点 | AI Engineer Coach | GitHub Copilot Metrics | WakaTime |
|---|---|---|---|
| 対象ユーザー | 個人開発者 | 組織管理者 | 個人・チーム |
| データの処理場所 | ローカルのみ | GitHubサーバー | WakaTimeサーバー |
| ハーネス対応 | 5種類（マルチ） | GitHub Copilotのみ | エディタ統合 |
| アンチパターン検出 | 45ルール（自動） | なし | なし |
| カスタムルール | DSL記述可能 | 不可 | 不可 |
| 生成コード量の計測 | あり | あり | なし（入力量のみ）|
| 学習・XPシステム | あり | なし | なし |
| コスト | 無料（MIT） | GitHub Enterprise Addon | 無料/有料プラン |
| テレメトリ | なし | あり | あり |
| インストール | vsixビルド必要 | 不要（クラウド） | エージェント必要 |

最大の差別化ポイントは「**ローカル完結 × マルチハーネス × アンチパターン自動検出**」の組み合わせです。

GitHub Copilot Metricsは組織単位で「Copilotがどれだけ使われているか」を把握するためのツールであり、個人の習慣改善には向きません。WakaTimeはコーディング時間を追跡しますが、AIアシスタントの使い方の質は分析しません。

AECは「自分のAI使い方のクセを把握して改善する」という個人の習慣改善にフォーカスしており、セキュリティに敏感な環境でも使いやすいローカル完結設計が特徴です。

Claude Code・CursorどちらのユーザーがAIコーディングツールをより効率的に使えているかを比較したい場合は [Claude Code vs Cursor徹底比較2026年版：CLI派とIDE派、どちらを選ぶべきか](/explain/claude-code-vs-cursor-comparison-2026/) も参考にしてください。

## アンチパターン検出の実例：YOLO Modeが発火したとき

ダッシュボードのAnti-Patternsページで各ルールの検出結果がどのように表示されるかを、YOLO Modeを例に説明します。

YOLO Modeが発火した場合の表示は以下のようなイメージです：

[HIGH] YOLO Mode — Code Review Score: 12/100

847 of 950 tool actions (89%) were auto-approved. The agent is running virtually unsupervised.

Auto-approved tools: BashTool, EditTool, WebFetchTool

How to Improve: Disable blanket auto-approve. Review file edits, terminal commands, and web searches individually. Use session-scoped approval only for trusted, low-risk tools. ```

この表示を見て取れる具体的なアクションは2点です。まずAIコーディングツールの設定を開き、全ツール自動承認を無効化します。次に、信頼性の高い低リスクなツール（ファイルの読み取り・定型検索等）に限ってセッションスコープで自動承認を設定し、ファイル編集・ターミナルコマンドは毎回手動確認するように変更します。

Speed Acceptが発火した場合の表示例は「workspace/project: avg 45 AI LOC, avg 3s gap」のようになります。特定のワークスペースで、特に大量のコードを短時間で受け入れているかを示します。

No Plan Modeでは「240 agentic requests but no use of plan mode. Jumping straight to implementation often leads to wrong approaches.」のような文言が表示され、Planモードの具体的な使い方の例（/planコマンドの使い方・モードピッカーでの切り替え）が提示されます。

GitHub Copilot以外のハーネスでの活用

AECはGitHub Copilot以外のハーネスでも有効です。Claude Codeユーザーにとっては特に有用な機能があります。

Claude Codeのセッションログ（~/.claude/projects/以下）を解析することで、以下のパターンが検出されます：

no-plan-mode：Claude CodeのPlanモードを一度も使っていない
yolo-mode：--dangerously-skip-permissions相当の設定で運用している
session-drift：一つのClaudeセッションで複数の無関係なタスクを混在させている
no-skills：カスタムスキル（.claude/skills/）を作成していない
context-engineering-gaps：CLAUDE.mdや指示ファイルの設定が不十分

Claude CodeとGitHub Copilotを並行して使っているエンジニアは、AECで両ハーネスのセッションを横断比較することで「どちらのツールをどのようなタスクに向けているか」のパターンも把握できます。

Copilot系ツールの活用パターンをさらに深掘りする場合は awesome-copilot完全ガイド：GitHub公式Copilotカスタマイズ集の全リソース解説も合わせて確認することをお勧めします。

開発ロードマップと今後の展開

v0.1.0はFirst Releaseとして位置づけられており、以下の機能が含まれます：

Dashboard with timeline, output, and consumption views
Anti-pattern detection with 40+ built-in rules
Skill Finder and context quality analysis
Activity patterns (projects, work hours)

GitHubのIssueとPullRequestを見ると、コミュニティからは以下のような機能要望・改善提案が上がっています：

VS Code Marketplace への公開（インストール手順の簡素化）
Burndownページの有効化（v0.1.0では一時無効）
ハーネスカバレッジの拡張（Cursor・Windsurf等）
チーム共有機能（プライバシーを維持しながらスコアを共有）
CLIモードでの解析（VS Code不要）

OSSとして公開されているため、コントリビュートや機能追加の提案はGitHubのIssueを通じて行えます。MITライセンスのためフォークして独自拡張することも可能です。

まとめ：「使っているつもり」から「正しく使えている」へ

AI Engineer Coachは、AIコーディングアシスタントの活用状況を定量化し、習慣の盲点を検出するツールです。45のアンチパターン検出ルール、カスタムDSL、コンテキストヘルス分析、スキルファインダーという4つの柱が揃っており、個人の習慣改善から始めてチームへのルール展開まで対応できます。

2026年5月時点では：