configure-codacy

Codacy を設定する

用語集： Codacy の概念（イシュー、検出結果、重大度、カバレッジ、ツール、パターンなど）の共通定義については、glossary.md を参照してください。

このスキルは、プロジェクトの実際の技術スタックとコーディング規約に合わせて Codacy の設定を調整します。リポジトリの言語とフレームワークを検出し、幅広いツールとパターンを初期化して分析を実行した後、ノイズを適切に削減します。変更内容とその理由をすべて記録した、クリーンで有用なシグナルの多い設定を作成します。

前提条件

• Codacy Analysis CLI（codacy-analysis）。discover と init --auto に対応している必要があります。CLI がこれらのコマンドに対応していない場合は、npm i -g @codacy/analysis-cli を実行して更新してください。セットアップについては codacy-analysis-cli を参照してください。
• Codacy Cloud CLI（codacy）。リポジトリが Codacy Cloud 上にあるかどうかを確認し、Cloud 専用ツールからイシューを取得する場合に必要です。セットアップについては codacy-cloud-cli を参照してください。

両方の CLI は ~/.codacy/credentials の認証情報を共有するため、一度ログインすれば両方を使用できます。

設定の仕組み

設定はすべて .codacy/codacy.config.json を使ってローカルで行います。ファイルを編集して分析を実行すれば、プッシュやクラウドでの再分析を行わずに結果をすぐに確認できます。調整が完了したら、設定を一度の操作で Codacy Cloud にインポートできます。

重要な原則は、幅広く始めてから、データに基づいてノイズを削減することです。init --auto でパターンのカバレッジを最大限にして初期化し、分析を実行してイシューの全体像を把握した後、重大度やカテゴリの分布に基づいて無効化または調整する項目を判断します。

編集する前に、スキーマ全体について設定形式のリファレンスを確認してください。フィールド名が重要です（例：除外フィールドは excludePaths ではなく exclude です）。パターンを無効にするには、patterns 配列から削除します。ツールを無効にするには、ツールの項目全体を削除します。

組織の標準が優先されます。 組織レベルの Coding Standard で適用されているパターンは、リポジトリレベルでは変更できません。

ローカル設定のみです。 .codacy/codacy.config.json ファイルはローカル分析専用です。このファイルをリポジトリにコミットまたはプッシュしても、Codacy Cloud の分析には一切影響しません。Codacy Cloud に設定を適用するには、インポートコマンド（codacy tools ... --import）を使用してください。

呼び出しモード

このスキルには、調整後に設定を Codacy Cloud にインポートするかどうかを制御する、次の 3 つのモードがあります。

• 対話型（デフォルト）： 調整が完了し、結果を提示した後、AskUserQuestion を通じて設定を Codacy Cloud にインポートするかユーザーに尋ねます。引数を指定しない場合は、このモードがデフォルトです。
• 自動インポート： ユーザーの呼び出し引数に「import」という単語が含まれている場合（例：/configure-codacy import configuration、/configure-codacy --import）、インポートの確認を省略し、結果の提示後に自動でインポートします。CI の実行や自動化に便利です。
• ローカルのみ： リポジトリが Codacy Cloud 上にない場合（ステップ 0 で判定）、インポートについては尋ねません。結果を提示し、設定がローカル分析専用として準備できていることを伝えます。

さらに、force フラグはインポート中の Coding Standard の処理を制御します。

• force 無効（デフォルト）： インポートで Coding Standard と競合した場合（409 エラー）、--force を付けて自動的に再試行しないでください。代わりに、AskUserQuestion を通じて競合内容をユーザーに提示し、Coding Standard のリンクを解除するか判断してもらいます。
• force 有効： ユーザーの呼び出し引数に「force」という単語が含まれている場合（例：/configure-codacy import force）、Coding Standard と競合した際に --force を付けて自動的に再試行します。

呼び出し引数は、処理の最初に解析してください。ステップ 6 で参照する内部フラグを設定します。

• 引数に「import」が含まれる場合 → 自動インポートモード
• 引数に「force」が含まれる場合 → force モード（Coding Standard の自動リンク解除を許可）
• それ以外 → 対話型モード（ステップ 0 でリポジトリが Cloud 上にないと判定された場合は、ローカルのみになることがあります）

プロジェクトに合わせた設定ワークフロー

Configuration Progress:
- [ ] Step 0: Check environment and capture baseline
- [ ] Step 1: Discover repository stack
- [ ] Step 2: Initialize auto-tuned configuration
- [ ] Step 3: Run broad-config baseline analysis
- [ ] Step 4: Smart noise evaluation and tuning
- [ ] Step 5: Show local results
- [ ] Step 6: Cloud import (conditional)
- [ ] Step 7: Clean-up

ステップ 0：環境を確認し、ベースラインを記録する

このステップでは開始時点を確認し、最終的な要約に使用する変更前のメトリクスを記録します。フローは、リポジトリが Codacy Cloud 上にあるかどうか、およびローカル設定がすでに存在するかどうかという 2 つの条件によって異なります。

0a. 一時ディレクトリを作成し、Codacy Cloud のステータスを確認する

中間分析ファイル用の一時ディレクトリを作成します：

mkdir -p .codacy/tmp

Cloud CLI は、git remote origin URL からプロバイダー、組織、リポジトリを自動検出するため、手動で特定する必要はありません。リポジトリ内では、以下の codacy コマンドを <provider> <org> <repo> を明示せずに実行できます。説明を明確にするため、例では明示的な形式を使用しています。実際には、自動検出される短縮形式に置き換えてください。

CLI 出力に関する注意点： codacy と codacy-analysis の両 CLI は、実際の JSON 出力の前に進行状況の行（例：- Fetching tools...、- Fetching issues...）を stderr に出力します。CLI の出力を jq に直接パイプする場合は、解析エラーを避けるため stderr をリダイレクトしてください：

codacy repository --output json 2>/dev/null | jq '...'

Cloud のステータスを確認します：

codacy repository --output json

成功した場合、リポジトリは Codacy Cloud 上にあります。後で Cloud 専用ツールを特定できるよう、有効なツールも一覧表示します：

codacy tools --output json 2>/dev/null | jq '[.[] | select(.settings.isEnabled == true) | {name, isClientSide}]'

失敗した場合（リポジトリが Codacy 上にない、認証情報がない、または Cloud CLI がない場合）は、Cloud 機能をスキップすることを記録してください。ローカルワークフローは単独で完結します。呼び出しモードをローカルのみ（「呼び出しモード」セクションを参照）に設定してください。

0b. ベースラインを記録する（変更前の基準値）

Cloud のステータスとローカル設定の有無に応じて分岐します。ここで記録するベースラインが、ステップ 5 の要約に使用する正確な変更前の基準値です。

トラック A — リポジトリが Codacy Cloud 上にある（信頼できるベースライン）：

Cloud の設定を信頼できる情報源として使用します。init --remote を使って取得してください。

重要： .codacy/codacy.config.json がすでに存在する場合、init --remote は失敗します。削除する前にバックアップを作成し、必ずファイルを削除してください：

# Delete any existing config first — init --remote refuses to overwrite
rm -f .codacy/codacy.config.json

# Fetch the current Cloud configuration
codacy-analysis init --remote <provider> <org> <repo>

# Store a copy for later merging and comparison
cp .codacy/codacy.config.json .codacy/tmp/codacy-remote-config.json

# Record BEFORE metrics
jq '[.tools[].patterns | length] | add' .codacy/codacy.config.json
jq '.tools | length' .codacy/codacy.config.json

# Run analysis with the Cloud config to capture the BEFORE issue landscape
codacy-analysis analyze --install-dependencies --output-format json --output .codacy/tmp/codacy-remote-results.json

# Record BEFORE issue count and runtime
jq '.issues | length' .codacy/tmp/codacy-remote-results.json
jq '.metadata.durationMs' .codacy/tmp/codacy-remote-results.json

Cloud のイシュー概要を取得します。これにより、個々のイシューをすべてダウンロードすることなく、リポジトリ全体のパターンごとのイシュー数、誤検知数、推奨アクションを確認できます：

codacy issues -O -o json > .codacy/tmp/codacy-cloud-overview.json

この概要データは、ステップ 4 で調整方針を決める際に役立ちます。Cloud 上で最も多くのイシューを生み出しているパターン（本番環境における実際の状況）、パターンごとの誤検知率がわかるほか、ノイズを減らすための推奨アクション（イシュー全体の 10％以上、または平均の 3 倍を占めるパターンの特定）も生成されます。推奨アクションには、コーディング規約や設定ファイルの制約に合わせた、すぐに実行できる無効化コマンドが含まれます。後で比較できるよう、保存してください。

Cloud 専用ツールも確認します。Cloud では有効になっているものの、ローカルの Analysis CLI では利用できないツールです。codacy-analysis info でローカル CLI がサポートするツールを取得し、上記の Cloud で有効なツールの一覧と比較してください。info の出力にない Cloud の有効化ツールは、Cloud 専用ツールです（例：SonarSharp、Codacy ScalaMeta Pro）。Cloud 専用ツールがあり、イシューも存在する場合は、それらを取得してください：

codacy issues --output json > .codacy/tmp/codacy-remote-cloud-results.json

トラック B — Cloud 上にはないが、ローカルに .codacy/codacy.config.json が存在する場合：

# Store a copy for later merging and comparison
cp .codacy/codacy.config.json .codacy/tmp/codacy-previous-config.json

# Record BEFORE metrics
jq '[.tools[].patterns | length] | add' .codacy/codacy.config.json
jq '.tools | length' .codacy/codacy.config.json

# Run analysis with the existing local config
codacy-analysis analyze --install-dependencies --output-format json --output .codacy/tmp/codacy-previous-results.json

# Record BEFORE issue count and runtime
jq '.issues | length' .codacy/tmp/codacy-previous-results.json
jq '.metadata.durationMs' .codacy/tmp/codacy-previous-results.json

トラック C — Cloud もローカル設定もない場合：

変更前の状態を、未設定として記録します：0 パターン、0 ツール、0 イシュー、実行時間は null。分析は実行しません。

実行したトラックから変更前のメトリクスを保存してください。ステップ 2〜3 の広範な設定メトリクスは内部用であり、ユーザーには報告しません。

0c. Cloud のノイズ事前評価（Track A のみ）

Cloud の概要を取得済みの場合（.codacy/tmp/codacy-cloud-overview.json が存在する場合）は、Cloud の本番データに基づいて、すでにノイズが多いと判明しているパターンを特定するため、ここで分析します。ローカル分析を実行する前に既知のノイズを無効化しておくことで、時間を節約できます。

まず、概要の推奨アクションを確認します。CLI は、全イシューの 10% 以上を占めるパターン、またはパターンごとの平均件数の 3 倍に達するパターンをすでに特定し、すぐに実行できる無効化コマンドを提示しています。これらの推奨を主な判断材料とし、以下の基準で補足します。

概要の patterns 配列（各エントリーは {id, title, total}）と誤検知数を解析します。

# Issue counts per pattern
jq '[.overview.patterns[] | {id, title, total}] | sort_by(-.total)' .codacy/tmp/codacy-cloud-overview.json

# Patterns with potential false positives (count > 0)
jq '[.overview.patterns[] | select(.potentialFalsePositives > 0) | {id, title, total, potentialFalsePositives, falsePositiveRatio: ((.potentialFalsePositives / .total) * 100 | round)}] | sort_by(-.falsePositiveRatio)' .codacy/tmp/codacy-cloud-overview.json

以下の基準でノイズの多いパターンを特定します。

1. プロジェクトの言語と合わないパターン — パターン ID を検出済みのスタックと照合します（次に実行する Step 1 で確認できますが、Step 0a の Cloud ツール一覧から大まかな使用言語を把握できます）。パターン ID には対象言語が含まれていることがよくあります（例：python.、java.、ruby.）。プロジェクトで明らかに使われていない言語のパターンに印を付けます。

2. 規約・スタイルに関するノイズ — 件数が非常に多い（件数の上位 5%）パターンのうち、CodeStyle、Documentation、Comprehensibility などのカテゴリに属するものは、規約の不一致である可能性が高いです。候補として印を付けます。

3. 誤検知率の高いパターン — イシューのうち、誤検知の可能性があると判定された割合が高いパターン（例：potentialFalsePositives / total > 30%）は、事前に無効化する有力な候補です。これらのパターンは、Codacy 自身のヒューリスティックでも信頼性が低いと判断される結果を出しています。誤検知データを保存し、Step 4b のルール 7 で使用します。誤検知率の高いパターンは、ローカル検証の際に追加の精査対象となります。

4. Security パターンは事前に無効化しない — 件数や誤検知率にかかわらず、Security パターンに事前無効化の印を付けることはありません。これらは Step 4 で全コンテキストを考慮して扱います。

5. 重大度が Critical／High のパターンは事前に無効化しない — これらは、何らかの対応を行う前にローカル検証が必要です。

ノイズの多い各パターンを、次の 2 つのリストに分類します。

• cloudNoiseLocal — ローカル Analysis CLI がサポートするツールの、ノイズの多いパターンです。Step 2 で init --auto を実行した直後に、.codacy/codacy.config.json から削除します。
• cloudNoiseCloudOnly — クラウド専用ツールの、ノイズの多いパターンです（Step 0b で特定）。インポートを実行する場合に限り、Step 6（インポート）で Cloud CLI を使って無効化します。

Step 2 と Step 6 で使用するため、両方のリストを保存します。これは事前フィルターです。Step 4 では、ローカル分析結果を使ってより詳細なノイズ評価を行います。

Step 1：リポジトリのスタックを検出する

検出を実行して、リポジトリの言語、フレームワーク、ライブラリを把握します。

codacy-analysis discover --output-format json --output .codacy/tmp/codacy-discover.json

出力を解析して、以下を把握します。

• プロジェクトで使用されている言語
• 使用中のフレームワークとライブラリ（例：React、Django、Spring Boot）
• これらの情報は、Step 4 のノイズ評価に役立ちます（例：プロジェクトで React を使用していると分かれば、JSX 関連のパターンが該当します）。

注：Codacy Cloud の確認は、Step 0 ですでに完了しています。

Step 2: 自動調整された設定を初期化する

まず、既存の .codacy/codacy.config.json があれば削除します（バックアップコピーはすでに Step 0 で保存されています）。

rm -f .codacy/codacy.config.json

検出されたスタックに合わせてフィルタリングした、最も幅広く有用なパターンセットで初期化します。

codacy-analysis init --auto "Critical,High,Warning,Minor,AllSecurity,ErrorProne,Performance,BestPractice,UnusedCode,Compatibility,Complexity,Comprehensibility,CodeStyle,Documentation"

このフィルターの意味は次のとおりです。

• Critical — Codacy が推奨する（デフォルトの）重大度が Critical のパターン
• AllSecurity — Security カテゴリーのすべてのパターン（デフォルト以外も含む）
• その他すべて — 全カテゴリーにおける、重大度が High、Warning、Minor の Codacy 推奨（デフォルト）パターン

実際の分析データに基づいて Step 4 で絞り込めるよう、幅広い設定から始めることを意図しています。

Cloud のノイズを事前にフィルタリングする（Track A のみ）： Step 0c で cloudNoiseLocal パターンが特定された場合は、新しく作成した設定から今のうちに削除します。cloudNoiseLocal の各パターンについて、.codacy/codacy.config.json の該当するツールの patterns 配列内で見つけて削除してください。これにより、Cloud の本番データですでにノイズが多いと判明しているパターンに、ローカル分析の時間を費やさずに済みます。これらの削除を記録し、概要に含めてください（Cloud データを理由として patternChanges に記載する事前フィルターの変更です）。

Step 0 で保存したベースラインから、保持する設定をマージします。

• Track A（Cloud）：.codacy/tmp/codacy-remote-config.json からマージします
• Track B（ローカル設定）：.codacy/tmp/codacy-previous-config.json からマージします
• Track C（以前の設定なし）：マージは不要です

該当するトラックでは、次の手順を実行します。

1. 新しく作成した .codacy/codacy.config.json を読み込みます
2. 保存済み設定のグローバルな exclude 配列をマージします（置き換えないでください。新しい設定にも独自の除外設定がある場合があります）
3. 保存済み設定と新しい設定の両方に存在する各ツールについて、ツールごとの exclude 配列をマージします
4. 保存済み設定で useLocalConfigurationFile が true で、該当するツールが引き続き存在する場合は、その設定と localConfigurationFile のパスを復元します

幅広い設定のメトリクスを記録します（内部用。概要の変更前の参照値ではありません）。

# Count enabled patterns across all tools in the broad config
jq '[.tools[].patterns | length] | add' .codacy/codacy.config.json

# Count enabled tools in the broad config
jq '.tools | length' .codacy/codacy.config.json

Step 3: 幅広い設定でベースライン分析を実行する

幅広い設定で分析を実行し、問題の全体像を把握します。これは調整の判断に使う内部手順です。ユーザー向け概要の変更前の参照値には、Step 0 の結果を使用します。

codacy-analysis analyze --install-dependencies --output-format json --output .codacy/tmp/codacy-baseline.json

標準出力のバッファリングによって JSON が壊れるのを防ぐため、必ず --output <file> を使用してください。

幅広い設定のメトリクスを記録します（Step 4 の調整判断に使用し、概要には使用しません）。

# Total issues in broad config
jq '.issues | length' .codacy/tmp/codacy-baseline.json

# Total runtime in milliseconds
jq '.metadata.durationMs' .codacy/tmp/codacy-baseline.json

問題の分布を解析します — これがすべての調整判断の基礎になります。

# Issues grouped by pattern (noise detection)
jq '[.issues | group_by(.patternId) | .[] | {patternId: .[0].patternId, toolId: .[0].toolId, severity: .[0].severity, category: .[0].category, count: length}] | sort_by(-.count)' .codacy/tmp/codacy-baseline.json

# Issues by severity
jq '.issues | group_by(.severity) | map({severity: .[0].severity, count: length})' .codacy/tmp/codacy-baseline.json

# Issues by category
jq '.issues | group_by(.category) | map({category: .[0].category, count: length})' .codacy/tmp/codacy-baseline.json

# Top 20 files by issue count
jq '[.issues | group_by(.filePath) | .[] | {filePath: .[0].filePath, count: length}] | sort_by(-.count) | .[0:20]' .codacy/tmp/codacy-baseline.json

# Per-tool results
jq '.toolResults | map({toolId, status, issueCount, durationMs, filesAnalyzed})' .codacy/tmp/codacy-baseline.json

Step 4: ノイズをスマートに評価して調整する

これがこのスキルの中核です。構造化された、コンテキストを考慮する判断フレームワークを使って、ベースラインの結果を確認してください。

相互参照としての Cloud 概要（Track A のみ）： .codacy/tmp/codacy-cloud-overview.json が存在する場合（Step 0b で取得済み）、パターンごとの問題数と誤検知データを、ローカルのベースラインとの相互参照に使用してください。Cloud の概要は Codacy でのリポジトリ全体の分析（本番環境での実際の結果）を反映しますが、ローカルのベースラインが対象とするのはローカル CLI で分析できるファイルのみです。Cloud の概要では件数が多い一方で、ローカルでは少ないパターンは、Cloud のみのツールカバレッジを示している可能性があります。重複排除や無効化の判断では、この点を考慮してください（Cloud で引き続き必要なパターンを無効にしないでください）。概要の誤検知件数は、特に以下のルール 7 で役立ちます。Cloud で誤検知率が高いパターンは、ローカルでも同様に信頼性の低い結果を出している可能性があります。

4a. ノイズフロアを確立する

Critical と High の問題（重大度が "Error" または "High"）が全問題に占める割合を計算します。この割合に基づいて、優先度の低いカテゴリーをどの程度積極的に削減するかを決定します。

全問題に占める Critical と High の割合	CodeStyle と Documentation のパターンに対する対応
>50%	重大度が Minor および Warning の CodeStyle と Documentation のパターンをすべて無効にします。コードベースには深刻な問題があり、スタイル上の問題はそれらを見えにくくするノイズにすぎません。
30–50%	重大度が Minor の CodeStyle と Documentation のパターンを無効にします。Warning レベルのパターンは維持します。
10–30%	すべてのパターンを維持しますが、ノイズの多いパスを対象にファイル除外を行います。
<10%	すべて維持します。コードベースはスタイルの適用から十分な恩恵を受けられるほどクリーンです。

重大な問題が多い場合は、同じ考え方を他の優先度の低いカテゴリー（Comprehensibility、Compatibility）にも割合に応じて適用します。状況に応じて判断してください。

4b. パターンレベルの判断

ベースラインの結果に含まれる各パターンを、問題の件数が多い順に並べ、次の優先順位に従って判断します。

1. セキュリティパターンは、すべてのセキュリティ上の懸念を網羅する必要があります。 category == "Security" に該当するパターンは、別のツールの有効なパターンが同じ意味上の懸念をすでに網羅している場合（ルール 2 を参照）を除き、有効なままにします。セキュリティパターンのノイズが多く、重複排除が適用されない場合は、パターンを無効にするのではなく、特定のファイルを除外します。

2. ツールをまたいで重複するパターンを重複排除します。 複数のツールが同じ意味上の懸念（例：「ハードコードされたシークレット」、「SQL インジェクション」、「XSS」、「未使用のインポート」）を検出した場合、問題メッセージ、影響を受けるファイル、影響を受ける行を比較して重複を特定します。重複するパターンの組み合わせについて、次のように判断します。

   • より特化した、または精度の高いツールのパターンを残します（例：Semgrep のセキュリティルールよりも汎用的な Biome チェック、汎用リンターよりも専用の SAST スキャナーを優先します）。
   • 精度が同程度の場合は、プロジェクトでより積極的に使われているツールのパターンを残します（有効なパターン数が多い、CI で使われている、ローカル設定ファイルがある、など）。
   • もう一方のツールの重複するパターンを無効にします。
   • これは懸念事項の削除ではなく、重複排除です。残したパターンによって、その懸念事項は引き続き網羅されます。
   • これはセキュリティだけでなく、すべてのカテゴリに適用されます。たとえば、2 つのツールがともに「未使用のインポート」を検出する場合も対象です。
   • 変更ログに、どのパターンを残し、どのパターンを無効にしたか、また残したパターンがより適切な検出元である理由を記録します。

3. 有効な Critical／High の問題を決して無効にしないでください。 実際の問題を検出している severity == "Error" または severity == "High" のパターンは、有効なままにする必要があります。誤検知と思われる場合は、パターンを無効にするのではなく、該当するファイルを除外します。

4. 対象の技術スタックが異なる場合は無効にします。 Step 1 の discover 出力と照合します。プロジェクトに存在しない言語やフレームワーク向けのパターンは、完全なノイズです。例：

   • JavaScript のみのプロジェクトにおける Python のセキュリティパターン
   • Java のみのプロジェクトにおける PMD7 の Apex パターン
   • リポジトリに存在しない言語向けの Semgrep ルール

   これらのパターンを設定から削除します。

5. ノイズの許容範囲を超えた場合は無効にします。 4a の判断を適用します。Minor の重大度における CodeStyle／Documentation を削除するとノイズの許容範囲で判断した場合は、それらのパターンを削除します。

6. 規約と一致しない場合は無効にします。 パターンが、コードベースの 80% 超で一貫して採用されている規約に反するものを検出する場合、そのパターンはプロジェクトで確立された規約と矛盾しています。例：

   • プロジェクト全体で「誤った」スタイルが一貫して使われている場合のタブとスペースのルール
   • プロジェクトで確立された命名規則に合わない命名規則のルール

7. 誤検知が多い場合は無効にします。 Cloud overview の誤検知データ（Step 0c から取得）を主な判断材料として使います。potentialFalsePositives / total > 30% に該当するパターンは、無効化の有力候補です。これは Codacy 独自のヒューリスティックが、結果のかなりの割合を信頼性の低いものとして検出していることを示しています。該当するパターンについて、コード内の実際の検出例をサンプルとして確認します。ローカルの検出例から、このコードベースではパターンが価値の低い結果を出していると確認できた場合は、無効にします。Cloud の誤検知データがないパターンについては、一般に誤検知率が高いことで知られているか確認します。このコードベースで検出結果が実際に役立たないことを確認してから、無効にしてください。

8. 無効化する前にパラメーターを調整します。 価値のあるパターンを無効にする前に、設定可能なパラメーターがあるか確認します。

   • Lizard の複雑度しきい値 — コードベースの実際の複雑度に合わせて引き上げます。
   • 行の長さ制限 — プロジェクトで確認された最大値に設定します。
   • その他のしきい値ベースのルール — ルールを有効なまま維持しつつ、誤検知を減らすよう調整します。

   調整すれば、ノイズを減らしながら網羅性を保てます。

9. 無効化する前にファイルを除外します。 パターンが有効でも、適用対象外のファイルで検出される場合は、パターンを無効にするのではなく、そのファイルを除外します。実際のソースコードに対しては、パターンを有効なままにします。

4c. ファイル単位の評価

ベースライン結果（ステップ 3）から、問題件数の多い上位ファイルを確認します。除外は厳密にデータに基づいて行ってください。ベースライン結果に実際に含まれており、意味のあるノイズを発生させているファイル／パスのみを除外に追加します。

重要： 分析 CLI はすでに .gitignore を考慮しています。.gitignore に一致するファイルは分析されないため、Codacy の設定で除外する必要はありません。結果に問題が実際に現れていない限り、dist/**、node_modules/**、build/**、coverage/** などのパスをあらかじめ除外に追加しないでください。

問題件数上位 N 件に含まれる、ノイズの多い各ファイル／パスに対する手順：

1. そのファイルが生成コードかどうかを確認します（例：*.generated.ts、routeTree.gen.ts、自動生成された API クライアント、.pb.go ファイル）。
2. そのファイルがリポジトリにコミットされたベンダーコードまたはサードパーティコードかどうかを確認します（例：.yarn/releases/、Git の無視対象ではない vendor/）。
3. そのファイルがコミットされたビルド出力かどうかを確認します（Git の無視対象ではないもの）。
4. そのファイルがテスト用フィクスチャ、スナップショット、またはモックデータであり、特定のツールで誤検出を発生させているかどうかを確認します。
5. 上記のいずれかに該当する場合、適切な除外に追加します。
   • すべてのツールに影響する生成コード／ベンダーコード／ビルド出力：グローバルな exclude 配列に追加します
   • 特定のツールでのみノイズを発生させるファイル：そのツールの exclude 配列に追加します（例：CHANGELOG.md に反応する markdownlint、コミット済みのベンダー CSS に反応する Stylelint）
6. 正当なソースコードである場合は除外しないでください。代わりに、パターン単位の調整（上記のルール 1～9）でノイズに対処します。

すべての除外は、実際の結果に基づいて正当化する必要があります。「常にこれらのパスを除外する」という規範的なチェックリストを維持しないでください。

4d. ツール単位の評価

設定内の各ツールについて、次の点を確認します。

• スタックに無関係ですか？ discover の出力に、そのツールの対象言語のファイルがない場合は、ツールのエントリー全体を削除します。例：Ruby がないプロジェクトの RuboCop、Java がないプロジェクトの Checkstyle。
• 実行に失敗しましたか？ toolResults[].status を確認します。値が "failed" の場合は、原因を errors[] で確認します。根本原因を修正すれば動作する可能性があるため、ツールは設定に残し、サマリーに記載します。
• 問題がゼロですか？ 問題がゼロのツールはノイズではありません。コード品質を確認できているか、対象ファイルが見つからなかったかのいずれかです。スタックに明らかに無関係でない限り、有効のままにします。

4e. 失われたパターンの復元

ベースライン分析結果（ステップ 0）と、調整後の現在の .codacy/codacy.config.json を比較します。次の条件を満たす各パターンについて：

• ベースライン分析で問題が検出されている（Track A の場合は .codacy/tmp/codacy-remote-results.json、Track B の場合は .codacy/tmp/codacy-previous-results.json）
• category == "Security"、または severity == "Error"、または severity == "High" を満たす
• 現在の設定に存在しない（init --auto によって除外された、または調整中に削除された）

→ 該当するツールの下に設定へ戻します。これは内部的な保持のための手順です。復元されたパターンはサマリーの変更として報告しません（すでにベースライン設定に含まれていたため、ユーザーから見れば何も変わっていません）。

Track C ではこの手順を省略します（以前の設定がなく、復元するものがないため）。

すべての変更を適用する

.codacy/codacy.config.json を編集し、4a～4e で決定した内容をすべて反映します。Step 5 のサマリーに記載するため、変更をすべて記録してください。

• 無効化したパターンごとに、patternId、アクション "disabled"、理由を記録します
• 調整したパターンごとに、patternId、アクション "updated"、変更前後のパラメーター、理由を記録します
• 削除したツールは toolChanges に記録します
• 追加したツールは toolChanges に記録します
• 新たに追加したファイル除外は fileExclusions に記録します
• 復元したパターン（Step 4e）はサマリーに含めません。復元によって現状が維持されます

セキュリティガードレール — 保存前に必ず確認してください。 更新した設定を書き込む前に、ハードコードされたシークレット、SQL インジェクション、XSS、パストラバーサル、オープンリダイレクトなど、すべてのセキュリティ上の懸念が、category == "Security" の有効なパターンで少なくとも 1 つ引き続きカバーされていることを確認してください。セキュリティパターンを無効化できるのは、別のツールの有効なパターンが同じ懸念をカバーしている場合のみです（Step 4b のルール 2 に従ったツール間の重複排除）。いずれかの懸念がカバーされなくなった場合は、その懸念に対して最も精度の高いパターンを再度有効にしてください。

4f. 検証

調整後の設定で分析を実行し、改善を検証します。

codacy-analysis analyze --install-dependencies --output-format json --output .codacy/tmp/codacy-tuned.json

実行後のメトリクスを記録します：

# Enabled patterns after tuning
jq '[.tools[].patterns | length] | add' .codacy/codacy.config.json

# Enabled tools after tuning
jq '.tools | length' .codacy/codacy.config.json

# Total issues after tuning
jq '.issues | length' .codacy/tmp/codacy-tuned.json

# Runtime after tuning
jq '.metadata.durationMs' .codacy/tmp/codacy-tuned.json

検証：

• 問題の数が、幅広い設定を使用したベースライン（Step 3）と比べて十分に減少している必要があります。
• 問題が増加した場合、または十分に減少しなかった場合（20％未満の削減）は、調整内容を見直し、もう一度繰り返してください。「結果の AI 分析を行う」（Step 4b）に戻って更新後の結果を確認し、さらに変更を適用して、この検証を再実行します。
• 残っているすべての問題に確認する価値がある状態を目指します。

Step 5：ローカルの結果を表示する

5a. サマリー JSON を生成する

変更前後のメトリクス、詳細な変更履歴、補足情報を含む .codacy/configure-codacy-summary.json を作成します。実行時間の値はミリ秒単位です（CLI の生の durationMs）。

before の値は Step 0 のものを使用します（変更前に取得したベースライン。Track A では Cloud 設定、Track B ではローカル設定、Track C では未設定の状態）。after の値は Step 4f のものを使用します（最終的な調整済み設定）。初期設定が存在しない場合（Track C）、before の値は未設定の状態を反映します。測定できないメトリクス（実行時間など）には null、件数（パターン、ツール、問題）には 0 を使用してください。

{
  "summary": {
    "enabledPatterns": { "before": 1000, "after": 300 },
    "enabledTools": { "before": 34, "after": 15 },
    "issues": { "before": 7000, "after": 550 },
    "analysisRuntime": { "before": 240000, "after": 60000 }
  },
  "toolChanges": [
    {
      "toolId": "Biome",
      "action": "disabled",
      "reason": "Project uses ESLint9 with local config; Biome is redundant and produced 16K false positives in TypeScript",
      "patternsAffected": 232
    },
    {
      "toolId": "markdownlint",
      "action": "enabled",
      "reason": "New tool added for Markdown linting; README.md excluded per-tool to avoid inline HTML noise",
      "patternsAffected": 43
    }
  ],
  "patternChanges": [
    {
      "patternId": "Semgrep_python.lang.security.audit.xss.template-injection",
      "toolId": "Semgrep",
      "action": "disabled",
      "reason": "Wrong stack — pattern for Python; project is JavaScript-only",
      "delta": -45,
      "parameters": []
    },
    {
      "patternId": "Lizard_ccn-medium",
      "toolId": "Lizard",
      "action": "updated",
      "reason": "Raised threshold from 10 to 20 to match codebase complexity profile",
      "delta": -120,
      "parameters": [
        { "id": "threshold", "before": "10", "after": "20" }
      ]
    },
    {
      "patternId": "Semgrep_codacy.javascript.security.hard-coded-password",
      "toolId": "Semgrep",
      "action": "enabled",
      "reason": "New High Security pattern — detects hardcoded passwords; found 101 issues across 41 files for review",
      "delta": 101,
      "parameters": []
    }
  ],
  "fileExclusions": {
    "global": ["src/routeTree.gen.ts"],
    "perTool": {
      "markdownlint": ["README.md"]
    }
  },
  "securityCoverage": {
    "deduplication": [
      "Semgrep slack-webhook-url disabled — same concern covered by Semgrep detected-slack-webhook"
    ],
    "newCoverage": [
      "unsafe-dynamic-method (Critical, 5 issues)",
      "open-redirect-from-function (Critical, 4 issues)",
      "hard-coded-password (High, 101 issues)"
    ],
    "noisyButKept": [
      "Semgrep hard-coded-password (101 issues) — kept per security guardrail, file exclusions preferred over disabling"
    ]
  },
  "keyImprovements": [
    "Lizard complexity thresholds tuned to match mature React SPA — 576 fewer noise issues while keeping genuinely complex functions flagged",
    "6 new security patterns detecting open redirects, unsafe dynamic methods, hardcoded passwords, and React href injection (119 new findings)",
    "markdownlint added for Markdown quality",
    "Checkov expanded from 6 to 1358 IaC security patterns"
  ],
  "localConfigTools": [
    {
      "toolId": "ESLint9",
      "configFile": "eslint.config.js",
      "issueCount": 42,
      "note": "Issues from this tool are controlled by the project's ESLint config, not Codacy patterns. Edit eslint.config.js to reduce noise."
    }
  ],
  "codacyYaml": null,
  "importResults": null,
  "cloudVerification": null
}

フィールドの説明：

summary — 変更前後のメトリクス（上記と同じです）。

toolChanges — 追加または削除したツールごとに 1 つのエントリーを記述します。各エントリーには以下を含めます。

• toolId — ツールの識別子
• action — "enabled"（ツールを追加）または "disabled"（ツールを削除）
• reason — ツールを追加または削除した理由
• patternsAffected — 追加または削除したツールに含まれるパターンの数

patternChanges — 個々のパターン変更ごとに 1 つのエントリーを記述します。各エントリーには以下を含めます。

• patternId — パターンの識別子
• toolId — このパターンが属するツール
• action — "enabled"、"disabled"、または "updated"
• reason — この変更を行った理由（監査可能性のため）
• delta — このパターンの問題数の変化。初期状態（Step 0）と最終的な調整後の状態（Step 4f）を比較します。初期設定で有効になっていなかったパターンの場合、delta は調整後の分析における問題数の全数です（新たに有効化した場合は正の値、調整中に無効化した場合は 0）。
• parameters — パラメーターの変更（該当しない場合は空の配列）

ツール全体の変更に伴って追加または削除したパターンについては、個別のエントリーを patternChanges に含めないでください。それらは toolChanges のエントリーで扱います。patternChanges に記載するのは、有効なままのツール内で個別に変更したパターンです。

ここに "restored" パターンを含めないでください。復元（Step 4e）は、init --auto によって Critical／High／Security の結果を持つベースライン設定のパターンが失われないようにする内部処理です。もともと存在していた設定を維持するものであり、ユーザーに提示する変更ではありません。 fileExclusions — このチューニング実行中に追加された新しい除外のみを一覧表示します。ベースライン設定にすでに存在する除外は自動的に引き継がれますが、ここには一覧表示されません（変更ではないためです）。

• global — チューニング中に追加された新しいグローバル除外グロブ
• perTool.<toolId> — チューニング中に追加された新しいツールごとの除外グロブ

新しい除外が追加されなかった場合は、fileExclusions を省略します。

securityCoverage — セキュリティ上の懸念への対処方法を記録します。

• deduplication — 別のパターンが同じ懸念をカバーするため無効化されたセキュリティパターン（維持されたパターンと無効化されたパターンを記載）
• newCoverage — ベースライン設定にはなく、新たに有効化されたセキュリティパターンと問題件数
• noisyButKept — ノイズが多いものの、セキュリティガードレールに従って有効なまま維持されたセキュリティパターン

keyImprovements — 最も重要な改善点を要約した、人が読みやすい3～6文の配列です。変更内容と定量的な影響に焦点を当ててください。ユーザーへの要約として提示できる内容にしてください。

localConfigTools — useLocalConfigurationFile: true を持つツールの配列です。各項目には次の情報が含まれます。

• toolId — ツール識別子
• configFile — このツールが使用するプロジェクトの設定ファイルのパス
• issueCount — チューニング後の分析でこのツールが検出した問題の件数
• note — このツールのノイズは Codacy のパターンではなく、プロジェクト独自の設定によって制御されることの説明

ローカル設定ファイルを使用するツールがない場合は、空の配列にします。

codacyYaml — ファイル除外が追加された場合に生成された .codacy.yaml ファイルの内容を含む文字列です（手順5cを参照）。.codacy.yaml が生成されなかった場合は null です。

importResults — 手順6が実行されるまでは null です。Cloud へのインポートを実施した場合は、その結果が格納されます（スキーマは手順6fを参照）。

cloudVerification — 手順6eが実行されない限り null です。インポート後の Cloud 検証結果が含まれます。再解析が完了したかどうか、前後の問題件数、Cloud で無効化されたパターン、警告が記録されます。スキーマは手順6eを参照してください。

5b. ローカルの結果を提示する

実行前と実行後の結果を明確に比較してユーザーに表示します。

1. メトリクステーブル — 有効なパターン数、有効なツール数、問題の合計件数、実行時間（実行前と実行後、および削減率）。「実行前」は手順0のベースラインです。以前の設定が存在しない場合（トラックC）は、実行前の列に「以前の設定なし」と記載します。
2. ツールの変更 — 追加または削除されたツールとその理由
3. 影響度の高いパターン変更 — patternChanges の項目を |delta| の大きい順に並べます。
4. 新しいセキュリティカバレッジ — ベースライン設定になかった新しいセキュリティパターン
5. セキュリティの重複排除 — 重複排除されたセキュリティパターンがあれば、維持されたものと無効化されたもの
6. 主な改善点 — 要約 JSON の keyImprovements 配列を箇条書きで提示します。
7. 警告 — 失敗したツール、Semgrep の解析エラー、ファイルとの一致が0件だったツール、その他発生した問題
8. ローカル設定ファイルの制約 — useLocalConfigurationFile: true のツールについて、その問題は Codacy が管理するパターンではなく、プロジェクト独自の設定ファイル（例：.eslintrc、.rubocop.yml）によって制御されることを伝えます。これらのツールのノイズを減らすには、プロジェクト独自の設定を編集する必要があります。ユーザーがさらにノイズを減らしたい場合に確認できるよう、該当する各ツールとその問題件数を一覧表示します。

5c. クラウドでのファイル除外用 .codacy.yaml を生成する

.codacy/codacy.config.json のファイル除外は、ローカル分析にのみ適用されます。Codacy Cloud では、API または CLI 経由でファイル除外をインポートできません。Codacy Cloud でファイル除外を適用するには、リポジトリのルートにある .codacy.yaml ファイルに定義し、コミットする必要があります（Codacy configuration file を参照）。

チューニング中に新しいファイル除外が追加された場合（グローバルまたはツールごと）、.codacy.yaml ファイルを生成します。

1. 既存の設定を保持するため、リポジトリのルートにある既存の .codacy.yaml（存在する場合）を読み込みます
2. 新しい除外を、既存の exclude_paths およびエンジンごとの exclude_paths とマージします
3. 更新した .codacy.yaml をリポジトリのルートに書き込みます

.codacy.yaml の形式では、Java の glob 構文を使用します。

---
exclude_paths:
  - "src/routeTree.gen.ts"
  - "vendor/**"
engines:
  markdownlint:
    exclude_paths:
      - "CHANGELOG.md"
  stylelint:
    exclude_paths:
      - "assets/vendor/**"

エンジン名の対応付け： .codacy.yaml のエンジン名は、.codacy/codacy.config.json のツール ID と異なる場合があります。ツール ID を小文字にしたものをエンジン名として使用します（例：ESLint9 → eslint9、Semgrep → semgrep、markdownlint → markdownlint）。不明な場合は、ツール ID を小文字にしたものを既定値として使用してください。

4. 生成した .codacy.yaml の全内容を文字列として、サマリー JSON の codacyYaml フィールドに保存します
5. ユーザーに次の内容を伝えます。
   • API 経由ではファイル除外を Codacy Cloud にインポートできないこと
   • .codacy.yaml ファイルをリポジトリのルートに作成または更新したこと
   • Codacy Cloud で除外を適用するには、このファイルをコミットしてプッシュする必要があること
   • Codacy Cloud は常にデフォルトブランチの .codacy.yaml を読み込むこと

新しいファイル除外が追加されなかった場合は、このステップをスキップし、codacyYaml は null のままにします。

ステップ 6：クラウドへのインポート（条件付き）

6a. Cloud のステータスを確認する

リポジトリが Codacy Cloud 上にない場合（ステップ 0 の情報を参照）：このステップ全体をスキップします。結果には次のように記載します。「この設定はローカル分析用に準備されています。Codacy Cloud で使用するには、まずリポジトリを Codacy に追加してください。」

6b. インポート動作を決定する

呼び出しモードに基づいて（「呼び出しモード」セクションを参照）、次のように処理します。

1. 自動インポートモード（ユーザーが「import」引数を指定して呼び出した場合）：そのまま 6c に進みます。
2. 対話モード（デフォルト）：AskUserQuestion を使用して、ユーザーに「これらの設定を Codacy Cloud で更新しますか？」と質問します。ユーザーが辞退した場合は、ステップ 7 に進みます。
3. ローカルのみモード：6a ですでに処理済みです（スキップ）。

6c. クラウド専用ツールのノイズ評価

ステップ 0 でクラウド専用ツールの問題が取得されている場合に限ります（.codacy/tmp/codacy-remote-cloud-results.json が存在する場合）。

ステップ 4 と同じノイズ評価の手順を、クラウドから取得した問題に適用します。クラウド専用ツールのノイズの多いパターンごとに、次のようにします。

• パラメーターを調整して結果を減らせるか確認します → codacy pattern <toolName> <patternId> --parameter key=value
• 調整できない場合は、無効化を試みます：codacy pattern <toolName> <patternId> --disable
• 無効化に失敗した場合（コーディング標準による強制）：結果にその旨を記載します

6d. ローカル設定のインポート

codacy tools --import .codacy/codacy.config.json -y

インポート時にコーディング標準との競合（409 エラー — 組織レベルで適用されているパターン／ツールは上書きできません）が発生した場合：

1. 強制モードが有効な場合（ユーザーが「force」引数を指定して実行した場合）：--force を付けて自動的に再試行します。

   codacy tools --import .codacy/codacy.config.json --force -y
   

   --force を使用したことと、リンクを解除したコーディング標準を結果に記載します。

2. 強制モードが有効でない場合（デフォルト）：--force を付けて自動的に再試行しないでください。代わりに、次のようにします。

   • コーディング標準の適用により変更できなかったツール／パターンを報告します
   • 変更を妨げている具体的なコーディング標準を列挙します
   • AskUserQuestion を使用して、ユーザーに次のように尋ねます：「インポートの一部がコーディング標準によってブロックされました［標準名のリスト］。これらのコーディング標準のリンクを解除し、--force を付けて再試行しますか？これにより、このリポジトリと組織レベルの標準とのリンクが解除されます。」
   • ユーザーが同意した場合 → --force を付けて再試行します
   • ユーザーが同意しない場合 → 部分的なインポートをそのまま維持し、ブロックされた変更を結果に記載します

ユーザーの明示的な同意、または「force」実行フラグなしに、コーディング標準のリンクを解除しないでください。

重要： .codacy/codacy.config.json ファイルはローカルでの使用専用です。これをリポジトリにコミットまたはプッシュしても、Codacy Cloud には一切影響しません。ローカル設定を Cloud に同期する方法は、インポートコマンドのみです。

6e. インポート後の Cloud 検証

インポートが成功した後（または部分的なインポートの後）、再解析を実行し、Cloud の結果を待って、Cloud 環境で設定が想定どおりに機能することを確認します。Cloud の解析結果は、ローカル解析と異なる場合があります（ツールのバージョン、コンテナ化された実行、ファイルの可視性が異なるためです）。

1. 再解析を実行し、完了を待ちます：

--reanalyze-and-wait を使用すると、再解析を実行し、完了するまで自動的にポーリングし（10 秒ごと、最大 20 分）、パターン、重大度、カテゴリ別の問題の変化を差分レポートとして取得できます。

codacy repository --reanalyze-and-wait -o json > .codacy/tmp/codacy-reanalysis-delta.json

これにより、手動でのポーリングが不要になります。CLI は再解析前のベースラインを取得して完了を待ち、差分全体をレポートします。20 分後にタイムアウトした場合は、判明している情報を報告して終了します。警告にタイムアウトを記載し、Cloud の検証が完了していない状態で続行してください。

2. 最新の Cloud 概要を取得して評価します：

再解析が完了したら（差分レポートを確認してください）、更新された問題の概要を取得します。

codacy issues -O -o json > .codacy/tmp/codacy-post-import-overview.json

インポート後の概要を、インポート前の概要（.codacy/tmp/codacy-cloud-overview.json）と比較します。新しい概要に含まれる各パターンを、問題数の多い順に並べて確認します。

• 問題数が多く、Security カテゴリに属さず、重大度が Critical／High でもないパターンは、Cloud 側で無効にする候補です
• Cloud のデータを使い、ステップ 4b と同じノイズ判定の枠組み（言語の不一致、規約の不一致、重複排除）を適用します
• 無効にするパターンには、Cloud CLI を使用します。

  codacy pattern <toolId> <patternId> --disable
  

• コーディング標準の適用により無効化に失敗した場合は、警告に記載します
• ステップ 0c の cloudNoiseCloudOnly リストにある、この時点まで保留されていたパターンも無効にします

4. Cloud 検証結果を記録します：

Cloud 側で行ったパターン変更はすべて、概要の新しい cloudVerification フィールドに記録します。

{
  "cloudVerification": {
    "reanalysisCompleted": true,
    "issuesBefore": 375,
    "issuesAfter": 280,
    "patternsDisabled": [
      {
        "patternId": "markdownlint_MD033",
        "toolId": "markdownlint",
        "reason": "Convention mismatch — 150 inline HTML issues in documentation files",
        "issueCount": 150
      }
    ],
    "warnings": []
  }
}

再解析がタイムアウトした場合、または Cloud 検証をスキップした場合は、reanalysisCompleted: false を設定し、理由を警告に記載します。

6f. Cloud のインポート結果を表示する

.codacy/configure-codacy-summary.json の importResults フィールドを更新し、インポート結果を記録します。

{
  "importResults": {
    "status": "success | completed_with_errors | failed",
    "toolsConfigured": 10,
    "toolsEnabled": ["markdownlint"],
    "toolsDisabled": ["PMD"],
    "errors": [
      {
        "toolId": "ESLint9",
        "error": "Conflict (409)",
        "detail": "Unable to update Project Tool Patterns, repository is using a Configuration File"
      },
      {
        "toolId": "PMD",
        "error": "Conflict (409)",
        "detail": "Cannot disable a tool that is enabled by a standard"
      }
    ],
    "warnings": [
      "7 Semgrep pattern parsing errors (non-blocking)",
      "Agentlinter: 0 files matched — no agent config files in this SPA"
    ],
    "codingStandards": ["AI Policy", "Our Default + SOC2"],
    "forceUsed": false
  }
}

importResults フィールドのリファレンス：

• status — すべてのツールがエラーなくインポートされた場合は "success"、一部のツールが失敗したものの他のツールは成功した場合は "completed_with_errors"、インポートコマンド自体が失敗した場合は "failed"
• toolsConfigured — 正常に設定されたツールの数
• toolsEnabled — Cloud で新たに有効化されたツール（それまでは無効だったもの）
• toolsDisabled — Cloud で無効化されたツール（それまでは有効だったもの）。Coding Standard によって無効化が禁止されている場合は空になることがあります
• errors — ツールごとのエラーの配列。各エラーには toolId、error（HTTP ステータスまたはエラーの種類）、detail（CLI からのエラーメッセージ）が含まれます
• warnings — ブロック要因にならない警告の配列（分析エラー、対象ファイルが 0 件のツールなど）
• codingStandards — リポジトリにリンクされている Coding Standard の名前（Step 0 から取得）、または該当するものがない場合は空の配列
• forceUsed — Coding Standard のリンクを解除するために --force が使用されたかどうか

インポート結果をユーザーに提示します。

• 正常に更新された内容
• 変更できなかった内容（Coding Standard による適用）。各エラーとその詳細を列挙します
• Cloud のみのツールパターンの変更（6c から）
• --force が使用されたかどうか、およびそれによる影響

Step 7：クリーンアップ

一時ディレクトリとすべての中間ファイルを削除します。

rm -rf .codacy/tmp

ツールごとの調整のヒント

Semgrep

Semgrep には 30 以上の言語向けのパターンが付属しています。初期化後は、プロジェクトで使用していない言語向けのパターンが多数含まれていることがあります。Step 4 では、discover で検出されなかった言語のパターンを無効にします。これが通常、ノイズを最も大きく減らす方法です。パターン ID のプレフィックス（例：python.、javascript.、java.）を検出された言語と照合します。

Lizard（複雑度）

Lizard には、循環的複雑度（CCN）、コード行数（NLOC）、パラメーター数に関するルールがあり、それぞれ重大度が 3 段階（Critical、Medium、Minor）で、設定可能な threshold パラメーターがあります。

既存の成熟したコードベースでは、デフォルトの Medium のしきい値を使うと、レガシーコードで大量の指摘が発生します。次の方法があります。

• Medium レベルのルールを無効にし、Critical のみを残す
• または、Medium のしきい値をプロジェクトの実際の複雑度に合わせて引き上げる（こちらのほうが望ましく、可視性を維持できます）

新規プロジェクトでは、デフォルトのしきい値が妥当です。

ESLint9

ESLint は、パッケージをインポートする場合があるプロジェクト独自の設定ファイル（例：eslint.config.js）を読み込みます。プロジェクトに既存の ESLint 設定がある場合は、Step 3 の --install-dependencies フラグで対応できます。それでも ESLint が InvocationError で失敗する場合、分析の前にプロジェクトで npm install などを実行する必要がある可能性があります。

プロジェクトに既存の ESLint 設定があり、ユーザーがそれを維持したい場合は、Codacy の管理対象パターンを使う代わりに、ESLint9 のツールエントリーで useLocalConfigurationFile: true を設定します。

markdownlint

MD034（裸の URL）、MD024（見出しの重複）、MD010（ハードタブ）、MD004（リストスタイル）、MD033（インライン HTML）、MD036（見出しとしての強調）などのルールは、CHANGELOG や自動生成ドキュメントで多数検出されます。これらはバグではなく、スタイルに関するものです。ルールを完全に無効化するよりも、ノイズの多いファイルを（ツールごとの exclude を使って）除外することをおすすめします。

Stylelint

結果は文脈に照らして確認してください。違反のように見える CSS ルールでも、意図的な場合があります（例：サードパーティのスタイルを上書きするアプリでは、!important や修飾セレクターが必要になることがあります）。プロジェクトに既存の Stylelint 設定がある場合は、useLocalConfigurationFile: true の使用を検討してください。

セキュリティガードレール

すべてのセキュリティ上の懸念は、少なくとも1つの有効なパターンでカバーする必要があります。 これは例外のない厳格なルールです。

このガードレールは、個々のパターンではなく、懸念事項のレベルで適用されます。2つのツールがどちらも「ハードコードされたシークレット」を検出する場合、精度の低いほうを無効にしても、懸念事項がカバーされた状態であれば問題ありません。ただし、セキュリティ上の懸念事項（SQL インジェクション、XSS、パストラバーサル、ハードコードされたシークレットなど）について、有効なパターンによるカバーがすべて失われる場合は、無効化を取り消してください。

セキュリティパターンの誤検出が多く、重複を解消できない場合：

• 誤検出が発生する特定のファイルを除外します（例：テスト用フィクスチャ、モックデータ）
• 誤検出は Codacy Cloud でのユーザーによるトリアージに任せます（理由を付けて個々の検出結果を無視できます）
• セキュリティ上の懸念事項をカバーする最後のパターンを削除しないでください — 今後のコードで実際の脆弱性を検出できるよう、有効な状態を維持する必要があります

Security 以外のカテゴリにおける Critical／High 重大度のパターンについても、同様に慎重に扱ってください。パターンの無効化よりも、ファイルの除外を優先してください。明らかに異なる技術スタック向けのパターンである場合に限り、無効化してください（例：Python のみのプロジェクトにおける Java の Critical パターン）。