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

エージェントは素早く妥当なコードを生成しますが、その中には注意深いエンジニアなら避けるような抜け道が含まれることがあります。緑色の結果を得るためにテストをスキップしたり、エラーを無視したり、スタブを残したり、型チェックを抑制したり、既存のコードベースで既に実装済みの処理を別の方法で書いたりします。このAnti-slopチェック項目はすべての変更においてこれらを探し出し、あなたが確認する前に変更内容を開発者エージェントに送り返します。

これはあなたの品質ポリシー内の1つのチェック項目に過ぎず、別個のスコアではありません。妨げとなる要素を一切導入しなければ、変更はこのチェックを通過します。

調査対象#

ルールはカテゴリごとにまとめられており、各ルールはブロック、助言または記録情報。

• テスト——対象を絞ったテストやスキップされたテスト、削除されたテスト、削除または弱体化されたアサーション、失敗し得ないテスト。
• 抑制事項——新たなLint無効設定、型無視指定およびanyキャスト。
• ビルドおよびCI——テストステップの削除または無効化、しきい値の引き下げ、「テストなしでも合格」という設定。
• テスト証拠——キャッシュされた結果を実行結果として偽装したり、テストを全く実行せずに完了と報告したりするケース。
• 本番コード——デバッグ用の残骸、プレースホルダー、モックデータ、人間へのメモ、テストコードが本番環境に配信されるケース。
• エラー処理——エラーを無視したり、障害を隠すためのフォールバックを設けたり、許可チェックを常に許可する設定にしたりするケース。
• コメント、アーキテクチャ、依存関係、変更範囲、 セキュリティ、キャッシュおよびエージェント履歴——テストが失敗した直後にそれを編集するなど、エージェントが行った作業の記録です。

各ルールのページは品質 → チェック項目 → Anti-slopにあり、該当する条件とその重要性が記載されています。

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

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

• 新規追加— この変更で新たに追加されました。
• 変更対象— 既に存在し、変更が適用される行または関数内にあります。
• 既存のもの— リポジトリ内の別の場所に存在します。

ブロッキングルールによる新規の検出結果のみがチェックを失敗させます。変更対象および既存の検出結果は記録され、技術的負債を確認できますが、無関係な作業を妨げることはありません。コードの移動は新規追加とはみなされず、コピーした場合のみ新規追加とみなされます。

ポリシーに追加する#

「品質 → ポリシー」でポリシーを開き、品質 → ポリシーからanti-slopプリセットを追加。これにより5つの要件が追加されます：

1. テストが変更内容を引き続き保証する。
2. 未完了のコードやテスト専用のコードはリリースされない。
3. 新たな構造的負債は生じない。
4. 変更内容はスコープ内に留まり、このコードベースの書き方に合致する。
5. 新しい依存関係は実在し、信頼できるものである。

ポリシーを公開すると、関連付けられた各プロジェクトの次回実行時にこのチェックが含まれます。

変更の処理方針を選択する#

この方針により、開発エージェントが変更をどの程度まで適用できるかが決まります：

• 外科的— 仕様で求められる範囲のみ。他の問題は報告されるだけで、修正されません。
• バランス型（デフォルト） — 変更が適用される行にある小さな問題も修正します。
• 修復型— 変更が編集する関数内の検出結果も整理します。

エージェントは提出前に同じルールに従って作業します。方針と隔離パターンを事前に取得し、各編集後に迅速なルールを適用し、QA前にブロッキング検出結果を修正する機会を一度与えられます。

コードベースに合わせて調整する#

• ルールの上書き— チェックの設定でルールを無効にしたり、ブロックではなく警告にしたりできます。
• ルールパック— 独自のパターン、禁止されたインポートや依存関係、ファイルサイズの制限、既に利用中のツール（SARIF）の結果などです。パックにはバージョンが付けられ、ポリシーで使用するバージョンが指定されます。
• 隔離— 今後コピーを許可しないパターンで、代わりに使用するものを指定します。エージェントにはこれらを広めないよう指示され、新たなコピーがあればフラグが立てられます。
• リポジトリファイル — .coroid/anti-slop.ymlリポジトリ内のこのファイルでルールを追加したり、生成されたファイルや外部ライブラリのパスを除外したりできます。変更のベースから読み込まれるため、変更自体でルールを緩めることはできず、編集には承認が必要です。

検出結果と例外処理#

検出結果は品質 → 検出結果、チェック項目で絞り込まれます。特定の検出結果を承認するには、理由を添えて免除申請を行い、その記録を当該検出結果に紐付けます。エージェント自身が作成した検出結果を免除することはできません。エージェントがテスト結果が誤りであると判断して内容を変更した場合、その変更が正しいと判定される前にレビュー担当者による承認が必要です。

Judgeルール#

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

独自のエージェント#

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

• AGENTS.mdスニペットをダウンロード、以下の技術負債タブの品質 → チェック項目 → Anti-slop、プロジェクトの変更管理基準、隔離対象、主要なルールをエージェントの指示文に貼り付けるためのセクションとして提供します。
• Coroid MCPサーバーを介して、anti_slop_rulesは公開済みのポリシーを記述し、anti_slop_scanは同期済みプロジェクトのブランチを読み取り専用でスキャンします。