スロップロス防止チェック

エージェントは素早く妥当なコードを生成しますが、慎重なエンジニアなら避けるような短絡的な対応が含まれる場合もあります。例えば、ビルドを通すためにテストをスキップしたり、エラーを無視したり、スタブを残したり、型チェックを無効にしたり、既存のコードと重複する処理を追加したりします。Anti-slopチェック機能はすべての変更内容からこれらを検出し、あなたが確認する前に開発者エージェントに変更内容を戻します。

これはあなたの品質管理ポリシーの中の一つのチェックに過ぎず、別個の評価項目ではありません。問題を引き起こす要素を含まない場合にのみ、変更はこのチェックを通過します。

検出対象#

ルールはカテゴリごとにグループ化されています。各ルールはブロック、助言または記録情報。

• テスト— 対象を絞ったテストやスキップされたテスト、削除されたテスト、弱められたアサーション、失敗しないテストなどです。
• 抑制設定— 新たなlint無効化設定、型チェックの無視設定、anyキャスト
• ビルドおよびCI— テストステップの削除や無効化、閾値の引き下げ、「テストなしでパス」、GitHubアクションがコミットに紐付けられていない状態などです。
• テスト結果— キャッシュされた結果を実行結果として扱ったり、テストを実行せずに済ませたり、部分的な実行結果を完了と報告したりします。
• 本番コード— デバッグ用の残骸、プレースホルダー、モックデータ、人間へのメモ、テストコードが本番環境に含まれる状態などです。
• エラー処理— エラーを無視したり、障害を隠すためのフォールバック処理、開放型の権限チェックなどです。
• 依存関係— 存在しないパッケージや悪意のあると判断されるパッケージ、人気のあるパッケージと名前が似た新しいパッケージ、インストール時にコードを実行するパッケージ、ロックファイルと一致しないマニフェストの変更などです。
• セキュリティ— コード内に秘密情報が含まれたり、TLSチェックが無効化されたり、認証チェックが削除されたり、ネットワークから直接スクリプトが実行されたりします。
• コメント、アーキテクチャ、変更範囲、キャッシュおよび エージェントの履歴— テストが失敗した直後にそれを編集するなど、エージェントが行った操作の記録です。

の中の各ルールはAnti-slopルールで、品質管理のAnti-slop行から開くと、該当するルールがマッチする条件、重要性、組織のデフォルト設定またはプロジェクト内での動作が確認できます。

変更によって新たに導入されたもののみがブロック要因となります#

ほとんどのリポジトリにはすでにこれらのパターンが含まれています。Anti-slopはすべての検出結果を3つのグループに分類します：

• 導入された— この変更で新たに追加されたもの。
• 変更された— すでに存在し、変更内容で編集された行や関数内にあるもの。
• 既存の— リポジトリの他の場所に存在するもの。

ブロック要因となるのは、ブロック系ルールに該当する「導入された」検出結果のみです。「変更された」および「既存の」検出結果は記録され、ファクトリーのDebtセクションで技術負債を確認し、修正タスクを作成できますが、無関係な作業を妨げることはありません。コードを移動しただけでは「導入された」とはみなされず、コピーした場合のみ該当します。

週次の技術負債整理#

既存の技術負債はブロック要因にはなりませんが、そのまま残る必要はありません。品質管理でプロジェクトを開き、Anti-slopを展開して週次の技術負債整理を有効にします。週に一度、Coroidがプロジェクトのデフォルトブランチをスキャンし、見つかった技術負債に対して小規模な整理タスクを作成します。一度に作成されるタスク数は同時に開くタスク数で指定された数（デフォルトは2件）までとし、整理作業がユーザーが依頼した作業を圧迫することがないようにします。各変更には取り消し機能が備わっています。

この整理処理はプロジェクトごとに設定されます。そのスケジュールはファクトリーに記載され、品質管理が管理するものと表示されます。設定の変更はそちらではなくここで行ってください。

以前は新規作業で「週次の技術負債整理」テンプレートが提供されていました。それから作成されたスケジュールは引き続き実行され、スイッチの下に名称が表示されます。技術負債整理機能がそれに取って代わる場合は、ファクトリーで一時停止してください。

有効化方法#

で品質管理、組織のデフォルト設定またはプロジェクトを選択し、Anti-slopを有効にします。これにより5つの要件が追加されます：

1. テストが変更内容を引き続き証明すること。
2. 未完了のコードやテスト専用のコードが本番に反映されないこと。
3. 新たな構造的技術負債が生じないこと。
4. 変更範囲が適切であり、コードベースのスタイルに合致すること。
5. 新たな依存関係が実在し、信頼できるものであること。

変更は即時に適用されます。次回のプロジェクト実行時、またはデフォルト設定を引き継ぐすべてのプロジェクトでこのチェックが適用されます。行の設定で変更の規律を選択でき、これによりブロック系ルールと判定系ルールがグループ化されます。無効にしても次回有効化時に設定が維持されます。

変更の規律の選択#

この規律により、開発者エージェントが変更を及ぼす範囲が決まります：

• 厳密— 仕様で要求される部分のみを処理し、その他の問題は報告されるだけで修正されません。
• バランス良好（デフォルト） — 変更が影響する行内の小さな問題も同時に修正します。
• 修復型— 変更が編集した関数内の不具合も一緒に修正します。

エージェントは提出前に同じルールに従って作業します。事前に規律と隔離されたパターンを取得し、各編集後に迅速なルールを適用し、QA前にブロッキングな不具合を修正する機会を一度だけ得ます。

コードベースに合わせる#

• ルールの上書き— Anti-slopルールで該当ルールを開き、組織全体または特定のプロジェクトに対してブロック、警告、報告のみ、または無効化を設定できます。
• ルールパック— 独自のパターン、禁止されたインポートや依存関係、ファイルサイズ制限、または既存のツール（SARIF）からの結果などです。保存するたびに新しいバージョンが作成され、選択したバージョンが維持されます。
• 隔離— 今後コピーさせたくないパターンで、それぞれに代わりに使用する置換文字列が指定されています。エージェントにはこれらを拡散しないよう指示され、新しいコピーはフラグ付けられます。
• 除外パス— 品質管理 → Anti-slopで、Anti-slopチェックが対象としない生成済みファイルや外部ライブラリファイルを指定します。各行に1つのパターンを記載します（dist/**、 vendor/**）。コミット済みのビルド出力に使用します。ルールが要求するファイルサイズの上限（512 KiB）を超える変更ファイルがある場合、チェックが実行できなくなります。
• リポジトリファイル — .coroid/anti-slop.ymlリポジトリ内の にルールを追加し、generated/、vendor/、node_modules/と__generated__/ディレクトリを除外できます。このファイルは変更のベースから読み込まれるため、変更自体でルールを緩和することはできず、編集には承認が必要です。
• ロックファイルと翻訳カタログ— Anti-slopはこれらの変更をカウントしますが内容は読み取りません。カタログとは.coroid/i18n.jsonが変更のベースで宣言するファイルのことで、グローバリゼーションチェックがこれらを読み取ります。独自のルールでこれらの名前を指定しても同様に読み取られます。

新規依存関係#

モデルが存在しないパッケージを提案することもあり、これは通常2つの実在する名前が組み合わさったものです。攻撃者はnpmやPyPIにこうした名前を登録し、次回のインストール時に自身のコードを実行させるslopsquattingという攻撃を行います。Cloud Security Allianceが説明しています：同機関が引用する調査における223万件のコードサンプルのうち、5分の1近くが存在しないパッケージを少なくとも1つ指名していました。

Anti-slopは変更で追加される各依存関係をpackage.json、要件ファイルまたはpyproject.toml：

• ブロック— パブリックレジストリに存在しないパッケージ、または OSVが悪意あると判定したパッケージです。このような変更はユーザーが確認する前に開発者エージェントに戻されます。
• 警告— 公開から30日未満のパッケージ、ダウンロード数が極めて少ないパッケージ、人気のあるパッケージと1～2文字しか違わない名前のパッケージ、またはインストール時にコードを実行するnpmパッケージです。悪意あると報告されたリリースを持つPyPIパッケージも警告対象となります。なぜならCoroidはどのリリースが要件でインストールされるかを把握できないからです。

レジストリに接続できない場合、チェック結果にその旨が記載され、照会可能なパッケージのみで判断されます。変更を保留することはありません。

Coroidが照会する名前#

名前を照会するとパブリックレジストリに送信されるため、所有者または管理者がCoroidから送信可能な名前を品質管理 → Anti-slop → 新規依存関係のチェック。この設定は組織内のすべてのプロジェクトに適用されます。

• パブリックなnpmおよびPyPI。ただしリポジトリが別のレジストリを指定している場合は除きます— 新規依存関係はすべて照会されますが、.npmrc、要件ファイル、pip.conf、uv.toml、PipfileまたはPythonツールの設定で、マニフェストファイル内またはその上のフォルダに別のレジストリやインデックスが指定されている場合は除きます。この設定を選択する際には、リポジトリ外（例えばユーザー設定やCI設定）にプライベートレジストリが設定されていないことを確認し、いつ誰が確認したかを記録する必要があります。スコープ付きnpmパッケージ（@scope/name）は.npmrcがそのスコープのパブリックレジストリを指定している場合にのみ照会されます。
• リポジトリがパブリックレジストリを指定している場合のみ— デフォルト設定です。パッケージは.npmrcが設定されている場合のみ照会されます registry=https://registry.npmjs.org/、要件ファイルに正確に1行の --index-url https://pypi.org/simpleが含まれる場合、またはPoetryの依存関係がpypi.orgを指すソースを使用している場合です。ほとんどのリポジトリはこれらの条件を満たさないため、新規依存関係のチェックは行われません。
• オフ— 名前の照会を行わず、架空のパッケージも検出されません。

新規依存関係の名前のみがCoroidから送信され、registry.npmjs.orgとpypi.org、api.npmjs.orgnpmのダウンロード数を確認するために、そしてapi.osv.dev(npmバージョンを使用して)悪意のあるパッケージに関するレポートを生成します。コードは決して送信されません。 結果は最大で1日間保持されるため、変更ごとに同じ名前を再度照会することはありません。

検出結果と承認#

タスクの検出結果は、そのタスクの品質セクションに表示されます。ファクトリー内で開発エージェントが変更がレビューに回る前にブロッキングな検出結果を修正した場合、 このセクションにはレビュー前にanti-slopが検出した項目、検出されたルールと、その下の場所とタイミングを表示には、各検出結果のファイル名、行番号、およびそれを検出したチェック内容が記載されます。ファクトリーの技術負債セクションでは、過去30日間にレビュー前に検出されたショートカットの数がカウントされ、オーナーや管理者にはまだこれらのチェックを実施していないプロジェクトがanti-slopを有効にする。

検出結果を承認するには、理由と有効期限を指定します。この承認情報は、該当する検出結果に対して記録されます。エージェントは自身が検出した結果を承認することはできません。エージェントがテストが誤っていたとして内容を変更した場合、チェックが通過する前にレビュアーの承認が必要です。

ルールの判定#

2つのルールがモデルに1行ずつ問い合わせます。1つは表示されたコードでは不可能な事象を防ぐためのチェック、もう1つは隣接するコードと矛盾するコメントです。これらはあくまでアドバイスであり、ブロックはしません。Judgeルールを有効にする新しいチェックで有効になり、実行ごとの判定回数に制限が設けられます。チェックの設定で無効にできます。

独自のエージェント#

同じルールを、自社で運用するエージェントの指針としても利用できます：

• AGENTS.mdスニペットをダウンロード、Anti-slopプロジェクトの設定内の品質管理には、プロジェクトの変更管理ルール、隔離ルール、上位ルールが記載されており、エージェントの指示文に貼り付けるためのセクションとして利用できます。
• Coroid MCPサーバーを介して、anti_slop_rulesは公開されているポリシーを記述し、anti_slop_scan同期済みプロジェクトのブランチを読み取り専用でスキャンします。