TypeScriptの型システムは、コード実行前に、型不一致、プロパティの欠落、関数シグネチャの誤りなど、重要な種類のバグを検出します。しかし、それ以外のすべては検出できません。例えば、アプリケーション内でのデータフローに依存するセキュリティ脆弱性、チームの境界が曖昧になるにつれて蓄積されるアーキテクチャ違反、呼び出し元が削除された後もコードベースに残るデッドエクスポート、コンパイルは正しくても特定の実行時条件下で失敗する非同期プログラミングのミスなどです。静的解析ツールはこれらのギャップを埋めるものであり、適切な組み合わせを選択するには、実際に何を見つけようとしているかを考慮する必要があります。
このガイドでは、2026年にTypeScriptチームにとって重要なツール、すなわちリンティングレイヤー(TypeScript-eslintを使用したESLint、Biome、OxcLint)、セキュリティレイヤー(Semgrep、Snyk Code、SonarQube)、アーキテクチャレイヤー(Dependency-Cruiser、Deptrac、Nx)、デッドコードレイヤー(Knip)、そして詳細分析レイヤー(ts-morph、TypeScriptコンパイラ自体)について解説します。それぞれのツールについて、実際の機能、設定方法、そしてどのような場合にそのツールが適さないのかに焦点を当てます。
TypeScript静的解析ツール:比較表
個々のツールについて詳しく説明する前に、以下の表で各ツールの主な機能、CIへの適合性、理想的な使用例を示します。単一のツールですべての側面を網羅することは不可能であり、効果的なTypeScript品質分析には複数のツールを組み合わせる必要があります。
| ツール | 主な機能 | CIに適しています | 費用 | 以下のためにベスト |
|---|---|---|---|---|
| ESLint + typescript-eslint | リンティング、スタイル、型認識ルール | はい | Free | チーム全体の規約、非同期型の安全性 |
| バイオーム | リンティング+フォーマット | はい | Free | ESLint + Prettier の代替品、スピード |
| オクスクリント | リンティング(ESLint互換) | はい | Free | 高速なリンティング時間を必要とするモノレポ |
| TypeScriptコンパイラ(tsc) | 型チェック | はい | Free | 型エラー、厳密なモード適用 |
| セムグレップ | SAST、カスタムパターン | はい | 無料 + 有料 | セキュリティスキャン、カスタム組織ルール |
| スニックコード | SAST、依存関係セキュリティ | はい | 無料 + 有料 | セキュリティを最優先するチーム、IDE統合 |
| SonarQube / SonarCloud | 品質ゲート、トレンド追跡 | はい | 無料 + 有料 | エンタープライズ品質のダッシュボード |
| ソナーリント | IDEレベルの品質フィードバック | IDEのみ | Free | インラインセキュリティと品質に関するヒント |
| 依存クルーザー | 依存関係グラフの強制 | はい | Free | アーキテクチャルールの検証 |
| デプトラック | レイヤー境界の強制 | はい | Free | クリーンアーキテクチャ、DDDの境界 |
| Nx | モノリポジトリの依存関係管理 | はい | 無料 + 有料 | モノレポのモジュール境界 |
| カット | デッドコードと未使用のエクスポート | はい | Free | 大規模に未使用コードを削減する |
| ts-morph | プログラムによるTS AST分析 | 選択的な | Free | カスタム分析、コード修正、ツール |
レイヤー1:リンティングとスタイル
ESLintとtypescript-eslint
ESLintはTypeScriptリンティングの基盤であり続けています。 typescript-eslint パッケージを使用すると、TypeScript の型情報にアクセスできるようになり、型コンテキストを必要とするルールを適用できます。その中でも最も価値のあるものは、一般的な Promise の間違いを検出する非同期処理固有のルールです。
bash
npm install --save-dev typescript-eslint
ジャバスクリプト
// eslint.config.js
import tseslint from "typescript-eslint";
export default tseslint.config(
...tseslint.configs.strictTypeChecked,
{
languageOptions: {
parserOptions: {
project: true,
tsconfigRootDir: import.meta.dirname,
},
},
rules: {
// Async safety rules -- highest value TypeScript-specific rules
"@typescript-eslint/no-floating-promises": "error",
"@typescript-eslint/await-thenable": "error",
"@typescript-eslint/no-misused-promises": "error",
"@typescript-eslint/require-await": "warn",
// Type safety
"@typescript-eslint/no-explicit-any": "warn",
"@typescript-eslint/no-unsafe-assignment": "error",
"@typescript-eslint/no-unsafe-return": "error",
},
}
);
上記の 4 つの非同期ルールは、typescript-eslint が通常の ESLint に対して提供する最も価値の高い追加機能です。これらは、未処理の Promise (浮動 Promise)、 await Promise 以外の値、同期関数を期待するコールバックに渡される Promise、および決して使用されない非同期関数に適用されます。 awaitこれらはコンパイルは正常に完了するものの、特定の条件下では実行時エラーが発生するパターンです。
ESLintではできないこと:ファイル間データフロー分析、アーキテクチャ境界の強制、セキュリティ汚染の追跡、デッドエクスポートの検出。これらの機能については、以下の他のレイヤーが必要です。
Biome:現代版ESLint + Prettierの代替品
Biomeは、ESLintとPrettierの両方を、25~35倍高速に動作する単一のRustベースのバイナリに置き換えます。JavaScript、TypeScript、JSX、JSONをサポートしています。新規プロジェクトや、ESLintのプラグインの複雑さや大規模コードベースでのパフォーマンスの遅さに悩まされているチームにとって、Biomeは最も強力な最新の代替手段です。
bash
npm install --save-dev --save-exact @biomejs/biome
npx @biomejs/biome init
bash
# Check and format in one pass
npx @biomejs/biome check --write src/
# CI mode -- no modifications, exit non-zero on any finding
npx @biomejs/biome ci src/
BiomeのプラグインエコシステムはESLintよりも規模が小さいため、カスタムルールを多用したり、フレームワーク固有のプラグインを使用しているチームにとっては大きな違いとなります。一方、ESLintのコアルールとPrettierのフォーマット機能のみを使用しているチームであれば、BiomeはESLintと同等のカバレッジをはるかに短い実行時間で実現できます。
OxcLint: スピード重視のESLint互換性
OxcLint(Oxcプロジェクトの一部)は、ESLint互換ルールを50~100倍高速に実行します。ESLintエコシステム全体を置き換えるものではありませんが、リンティング時間がボトルネックとなっているCIパイプラインにおいて、最速の選択肢となります。
bash
npm install --save-dev oxlint
npx oxlint src/
OxcLintは、標準的なESLintでは数分かかり、フィードバックループの遅延によってプルリクエストの品質が低下するような大規模なモノレポに最適な選択肢です。ESLintを置き換えるのではなく、併用することで最大限の効果を発揮します。迅速なフィードバックパスにはOxcLintを、マージ前の段階でルールを完全に網羅するにはESLintを使用してください。
レイヤー2:型チェック、TypeScriptコンパイラ
TypeScriptコンパイラ(tscは単なるビルドツールではなく、型レベルの正しさを検証するための主要な静的解析エンジンです。厳密モードを有効にすると、実際のバグを最も多く検出する設定が有効になります。
JSON
{
"compilerOptions": {
"strict": true,
"noUnusedLocals": true,
"noUnusedParameters": true,
"noImplicitReturns": true,
"noFallthroughCasesInSwitch": true,
"exactOptionalPropertyTypes": true,
"useUnknownInCatchVariables": true
}
}
bash
# Type-check only, no emit -- ideal for CI
npx tsc --noEmit
noUnusedLocals (NAIST) と noUnusedParameters コンパイラレベルで、未使用の変数と関数パラメータを検出する。 useUnknownInCatchVariables (TypeScript 4.4以降) 型は例外をキャッチします unknown ではなく any使用前に明示的な型絞り込みを強制する。
TypeScriptの制御フロー分析 これは、条件分岐内の型を絞り込むためにコンパイラが提供する組み込み機能です。これは、別のツールではなく、 strict モードは、それが完全に厳密に適用されることを保証します。コンパイラの制御フロー分析は、型ガードを理解します。 typeof 小切手、 instanceofそして、差別的な労働組合の形態。
tscの制限事項:TypeScriptコンパイラは、セキュリティ上の脆弱性、アーキテクチャ上の境界違反、デッドエクスポートを検出しません。型エラーは検出しますが、その検出は明確です。
レイヤー3:セキュリティ、TypeScript向けSAST
Semgrep: パターンベースのセキュリティスキャン
Semgrepはコードパターンマッチングによってセキュリティ脆弱性を検出します。TypeScriptの場合、SQLインジェクション、XSS、ハードコードされた認証情報、安全でないコードなどを検出できます。 eval 使用方法、プロトタイプの汚染、および安全でない Express.js 構成は、正しくコンパイルされるものの、悪用可能な脆弱性を引き起こすパターンです。
ヤムル
# Custom rule: flag user input in SQL queries (TypeScript)
rules:
- id: ts-sql-injection-risk
patterns:
- pattern: |
const query = `SELECT ... ${$USER_INPUT} ...`;
message: "User input directly interpolated into SQL -- use parameterized queries"
languages: [typescript]
severity: ERROR
bash
# Run with the community TypeScript security rules
semgrep scan --config=p/typescript --config=p/owasp-top-ten src/
SemgrepはESLintと競合するものではなく、補完的なツールです。ESLintはコーディング規約を強制し、Semgrepはセキュリティ上のアンチパターンを検出します。セキュリティを重視するほとんどのTypeScriptチームは、両方を使用すべきです。
Snykコード:IDE統合機能を備えたMLベースのSAST
Snyk Codeは、機械学習ベースの分析エンジンを用いてSASTを実行し、ファイル間の汚染の流れを追跡します。VS CodeやJetBrains IDEに統合されており、開発者がCI実行を待つことなく、コードを記述する際にインラインで検出結果を表示します。
bash
npm install --save-dev snyk
npx snyk auth
npx snyk code test
Snyk Codeは、開発者エクスペリエンスを重視し、IDE内でフィードバックを提供し、各検出結果に対して修正案を提示し、修復例を示すため、セキュリティ教育がセキュリティ検出と同じくらい重要な場合に最適な選択肢となります。
SonarQubeとSonarLint:品質ゲートとトレンド追跡
SonarQubeは、ダッシュボード、トレンド追跡、プルリクエストの装飾機能などを備えた、継続的なコード品質分析ツールです。TypeScriptの場合、バグ、コードの臭い、セキュリティ上の問題点、重複コードを検出します。SonarLintは、SonarQubeのルールをローカル環境で表示するIDE拡張機能です。
TypeScriptチームにとって、SonarCloud(クラウドホスト型バージョン)はよりシンプルな選択肢です。パブリックリポジトリは無料で利用でき、GitHub ActionsまたはGitLab CIを介したCI統合も数分で完了します。
ヤムル
# .github/workflows/sonar.yml
- name: SonarCloud Scan
uses: SonarSource/sonarcloud-github-action@master
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
SonarQubeが従来のリンティングツールよりも優れている点は、そのトレンドモデルにあります。つまり、コードの品質が時間とともにどのように変化しているか、どのコンポーネントが劣化しているか、そして各プルリクエストの新規コード品質ゲートスコアはどのくらいか、といった情報を提供します。こうした管理に役立つ指標こそ、ESLintやSemgrepでは提供できないSonarQubeの機能なのです。
レイヤー4:アーキテクチャ分析
Dependency-Cruiser: モジュール境界ルールの適用
Dependency-Cruiserは、インポートグラフが定義されたアーキテクチャルールに従っていることを検証します。視覚的な依存関係グラフを生成し、コードがモジュール境界制約に違反している場合はCIを失敗させます。
ジャバスクリプト
// .dependency-cruiser.cjs
module.exports = {
forbidden: [
{
name: "no-circular",
severity: "error",
comment: "Circular dependencies make code hard to test and maintain",
from: {},
to: { circular: true },
},
{
name: "no-ui-in-domain",
severity: "error",
comment: "Domain modules must not import from UI layer",
from: { path: "^src/domain" },
to: { path: "^src/ui" },
},
{
name: "no-external-in-shared",
severity: "warn",
comment: "Shared utilities should minimize external dependencies",
from: { path: "^src/shared" },
to: { pathNot: "^(src|node_modules/(lodash|date-fns))" },
},
],
};
bash
npx depcruise --validate .dependency-cruiser.cjs src/
Dependency-Cruiserは、Search Consoleデータ内の「react依存関係分析CLIツール」クエリに直接対応しており、TypeScript/Reactプロジェクトにおける依存関係グラフの生成と検証のための標準ツールです。
Deptrac:レイヤーベースの境界強制
Deptracはアーキテクチャレイヤーを強制し、永続化コードがプレゼンテーションからインポートできないこと、ドメインオブジェクトがインフラストラクチャに依存しないこと、およびモジュール境界がコードベース全体で尊重されることを保証します。
ヤムル
# deptrac.yaml
parameters:
layers:
- name: Domain
collectors:
- type: directory
value: src/domain
- name: Application
collectors:
- type: directory
value: src/application
- name: Infrastructure
collectors:
- type: directory
value: src/infrastructure
ruleset:
Domain:
- ~Infrastructure # Domain must not depend on Infrastructure
Application:
- Domain
Infrastructure:
- Application
- Domain
Deptracは、クリーンアーキテクチャ、DDD、またはヘキサゴナルアーキテクチャのパターンに従うプロジェクトにおいて最も価値を発揮します。これらのプロジェクトでは、レイヤーの分離は単なる好みではなく、設計上の制約となります。
Nx: モノレポレベルの依存関係管理
TypeScriptのモノレポの場合、Nxはリポジトリ内のすべてのプロジェクトにわたって、モジュール境界の強制、影響を受けるビルドの検出、および依存関係グラフの可視化を提供します。
JSON
// .eslintrc.json -- Nx module boundary rules
{
"rules": {
"@nx/enforce-module-boundaries": [
"error",
{
"allow": [],
"depConstraints": [
{ "sourceTag": "scope:shared", "onlyDependOnLibsWithTags": ["scope:shared"] },
{ "sourceTag": "scope:feature", "onlyDependOnLibsWithTags": ["scope:shared", "scope:feature"] },
{ "sourceTag": "scope:app", "onlyDependOnLibsWithTags": ["scope:shared", "scope:feature"] }
]
}
]
}
}
Nxの affected このコマンドは、変更されたモジュールに関連するテストとリンティングのみを実行するため、大規模なモノレポにおけるCI時間を大幅に短縮します。
レイヤー5:デッドコード検出
Knip: 未使用のエクスポート、ファイル、依存関係の検索
Knip はモジュール グラフ全体を分析して、未使用のエクスポート、未使用のファイル、および未使用の package.json 依存関係、ESLint のコード蓄積のクラス no-unused-vars ファイル内しか検索しないため、捕捉できません。
bash
npm install --save-dev knip
npx knip
JSON
// knip.json
{
"entry": ["src/index.ts", "src/**/*.test.ts"],
"project": ["src/**/*.ts"],
"ignore": ["src/generated/**"],
"ignoreDependencies": ["vitest"]
}
KnipはSCデータ内で「dead code detection unused exports javascript typescript」というキーワードで直接検索されます。TypeScriptプロジェクトにおけるモジュールレベルのデッドコード識別において、現在最も優れたツールです。
レイヤー6:プログラム分析、ts-morph
ts-morphは、TypeScriptコンパイラAPIラッパーであり、TypeScript ASTに対するカスタム分析、コード修正、およびツールを簡単に作成できます。SCデータでは、「ts-morph」および「ts morph」として直接検索されます。
タイスクリプト
import { Project } from "ts-morph";
const project = new Project({ tsConfigFilePath: "tsconfig.json" });
// Find all async functions that never await anything
const suspiciousAsyncFns: string[] = [];
for (const sourceFile of project.getSourceFiles()) {
for (const fn of sourceFile.getFunctions()) {
if (fn.isAsync()) {
const hasAwait = fn.getDescendantsOfKind(
SyntaxKind.AwaitExpression
).length > 0;
if (!hasAwait) {
suspiciousAsyncFns.push(
`${sourceFile.getFilePath()}:${fn.getName() ?? "anonymous"}`
);
}
}
}
}
console.log("Async functions with no await:", suspiciousAsyncFns);
ts-morphは、すぐに使える分析ツールではなく、分析ツールを構築するためのライブラリです。既存のツールでは対応できないカスタム分析(移行スクリプト、カスタムアーキテクチャ検証ツール、自動リファクタリング、コード生成パイプラインなど)を必要とするチームに適しています。
TypeScriptのAsync/Await静的解析
Search Consoleのデータによると、「TypeScript 静的解析 Async Await ペーパーツール」と「TypeScript 静的解析 Async Await 脆弱性ペーパーツール」に関するクエリが特定のグループに集中していることが分かります。これは、非同期プログラミングのエラーを型レベルで理解できるツールを探している実務家たちのニーズを反映しています。
本番環境の TypeScript チームにとっての実用的な答えは、typescript-eslint の 4 つの非同期固有のルールです (no-floating-promises, await-thenable, no-misused-promises, require-await)と組み合わせる strictNullChecks (NAIST) と useUnknownInCatchVariablesこれらを組み合わせることで、学術的な研究ツールを必要とせずに、最も一般的な非同期型エラーを検出できます。
非同期脆弱性パターンに関するセキュリティ研究を行っているチームにとって、TAJSとJellyはJavaScriptの非同期実行セマンティクスをモデル化した学術的な静的解析ツールですが、これらは研究ツールであり、実運用開発ツールではありません。
AngularとReact:フレームワーク固有の静的解析
Angularチーム向け, @angular-eslint コンポーネントパターン、テンプレート分析、サービスインジェクションを網羅するAngular固有のリンティングルールを提供します。上記のESLint + typescript-eslintの設定と統合されます。
Reactチーム向け eslint-plugin-react, eslint-plugin-react-hooks, eslint-plugin-jsx-a11y プラグインはReact固有のパターンに対応しています。Dependency-CruiserはReact固有の依存関係グラフ分析を処理し、SCデータ内の「react依存関係分析CLIツール」クエリの背後にあるツールです。
IDE統合:VS CodeとJetBrainsのためのツール
「VS Codeとの統合に最適なコード品質ツール」と「IDEとの統合に最適なコード品質ツール」という検索クエリは、実際のニーズを反映しています。CIからのフィードバックは、行動を変えるには遅すぎるのです。IDEと統合された分析は、最も効率的なフィードバックループを提供します。
VS Code:rust-analyzer Clippyとの互換性を備えたESLint拡張機能、インラインSonarQubeルール用のSonarLint拡張機能、セキュリティ検出用のSnyk拡張機能、および型レベルのフィードバックのための組み込みTypeScript言語サービス。
JetBrains (WebStorm/IntelliJ) : WebStormには、型エラーをインラインで表示するTypeScriptサポートが組み込まれており、ESLint、Prettier、SonarLintとの統合も可能です。組み込みの検査システムは、ESLintルールと同じパターンを多数カバーしています。
TypeScriptの静的解析カバレッジを最大化するためのVS Codeの設定:
JSON
// .vscode/settings.json
{
"typescript.tsdk": "node_modules/typescript/lib",
"typescript.enablePromptUseWorkspaceTsdk": true,
"editor.codeActionsOnSave": {
"source.fixAll.eslint": "explicit"
},
"eslint.validate": ["javascript", "typescript", "typescriptreact"],
"sonarlint.connectedMode.project": {
"connectionId": "my-sonarcloud",
"projectKey": "my-org_my-project"
}
}
認定条件 SMART TS XL TypeScript分析を企業全体に拡張
上記のツールは、TypeScriptプロジェクト内のTypeScriptを対象としています。しかし、TypeScriptサービスがCOBOLバッチプログラム、Java API、Pythonデータパイプライン、あるいはレガシーメインフレームシステムと連携する組織では、単一言語ツールでは言語境界を越える依存関係を把握できません。
SMART TS XLさん 静的コード分析 TypeScriptは、エンタープライズ環境における他のすべての言語(COBOL、JCL、Java、Python、RPG、SQL)と並んでカバーし、それらすべてにわたる統一された依存関係モデルを構築します。TypeScriptサービスがCOBOLプログラムによってサポートされているAPIを呼び出す場合、 SMART TS XL その関係をたどって、 影響分析 いずれのコンポーネントに変更を加える前にも。
エンタープライズ検索機能により、多言語コードベース全体をクエリ可能にします。特定のモジュールのすべてのTypeScriptインポート、TypeScriptサービスが呼び出すすべてのJavaメソッド、TypeScriptが利用するAPIにデータを提供するすべてのCOBOLコピーブックを、あらゆる言語の組み合わせで数百万行のコードから、数秒で検索できます。
TypeScriptをより大きなポートフォリオ内の1つの言語として運用するエンタープライズチームの場合、 SMART TS XL アーキテクチャの可視性と言語間の互換性を提供します 依存関係マッピング これにより、TypeScript固有のツールはシステムのその部分を見ることができるようになります。 SMART TS XL 全体像を把握している。
適切なスタックを構築する
TypeScriptの品質に関するあらゆる側面を網羅する単一のツールは存在しません。適切なアプローチは階層化されており、各階層はそれぞれ異なる種類の問題を対象としています。
最小限の実行可能な技術スタック(新規プロジェクト、小規模チーム向け):
- TypeScriptの厳格モード
- ESLintとtypescript-eslintの非同期ルール
npm audit依存関係の脆弱性について
本番環境向けアプリケーションスタック(中規模チーム、セキュリティ重視):
- 上記のすべてに加えて:
- フォーマットにはBiomeまたはPrettierを使用
- セキュリティSASTのSemgrep
- デッドコード用の切り抜き
- SonarCloudによる品質トレンドの可視化
エンタープライズ/モノレポスタック(大規模チーム、アーキテクチャ上の制約):
- 上記のすべてに加えて:
- モジュール境界強制のためのDependency-Cruiser
- モノレポ向けNxのビルド最適化
- レイヤー境界検証のためのDeptrac
- オンプレミス品質ゲート用のSonarQube(セルフホスト型)
多言語エンタープライズスタック(TypeScriptとレガシーシステムの併用):
- 上記のすべてに加えて:
- SMART TS XL 言語間影響分析および依存関係マッピング