なぜプロンプトだけではAIの「ゴミ」を防げないのか
プロンプトだけで、AIが生成するゴミのようなコードからコードベースを守ることはできません。AIエージェントは、あなたが苦労して定義したコーディング規約を頻繁に無視したり、回避したりするため、低品質なコード、いわゆる「slop」がプロジェクトに紛れ込んでしまいます。エージェントがプロンプトのルールを無視することは容易であり、それがコードの品質を損なう不整合や潜在的な問題を引き起こします。
この「slop」は、通常、コンパイルを即座に中断させるようなバグではありません。その代わりに、安全でない型キャストのような「根拠の薄いコード（low-evidence code）」であり、時間の経過とともに「型安全性（type safety）」を蝕んでいきます。コードは問題なくコンパイルされますが、後になって表面化するような、追跡困難な微細なバグを生み出し、小さな見落としを大きなデバッグの悩みの種へと変えてしまいます。
典型的な例を考えてみましょう。JSON APIからデータを取得する際、createdAtフィールドが文字列として送られてくるとします。AIエージェントは、JSONには本来Date型が存在しないにもかかわらず、これを直接Dateオブジェクトにキャストしてしまうかもしれません。TypeScriptに対して「自分を信じろ」と明示的に指示しているため、コードは文句を言わずにコンパイルされます。しかし、これは「時限爆弾」のようなもので、文字列のままのデータに対してDate操作を行おうとした瞬間にアプリケーションをクラッシュさせる原因となります。
コードのための、より高速で厳格なゲートキーパー
AIエージェントが魔法のようにコーディングガイドラインに従ってくれることを期待するのはやめましょう。代わりに「anti-slop」を導入してください。これはOxlint向けに設計された、独自の意見を持つルールのコレクションです。Rustで書かれたこのLinterは驚異的な速度を誇り、ESLintよりも50倍から100倍高速に動作します。このパフォーマンスは迅速なフィードバックループに不可欠であり、開発者もエージェントもコードの問題をほぼ瞬時に把握できるようになります。
プロンプトエンジニアリングの確率的な性質とは異なり、Lintは完全に決定論的です。これは厳格な失敗として機能し、チームが明示的に禁止したコードパターンを即座にフラグ立てします。これはAIが「検討するかもしれない」提案ではなく、交渉の余地のない品質ゲートであり、「slop」がコードベースに忍び込むことを確実に防ぎます。
anti-slopの真の力は、そのカスタマイズ性にあります。パッケージ内のすべてのルールを採用する必要はありません。チームは既存のコーディング基準に完全に合致する特定のルールを慎重に選び出し、高度にカスタマイズされた自動強制メカニズムを構築できます。これは単にプロンプトを増やすことではなく、品質のための堅牢で予測可能なシステムを構築することなのです。
LinterのエラーをAIの学習教材に変える
anti-slopの真の革新は、その速度だけでなく、エラーメッセージの質の高さにあります。開発者が頭を抱えて何が問題なのかを考え込んでしまうような、難解なTypeScriptの出力は忘れましょう。このLinterは、AIが生成したコードがなぜ問題なのか、そして極めて重要なことに、それを「どう修正すべきか」を正確に伝えます。曖昧な不満ではなく、直接的で実行可能な洞察を提供します。
この記述的なフィードバックは、エラーメッセージをAIエージェントにとって非常に価値のある「juicy data（有益なデータ）」へと変貌させます。単なる合格/不合格の判定ではなく、Linterは強力な教師へと進化し、エージェントが自身のミスを理解し修正できるように導きます。これにより、単なるコードチェッカーから、インテリジェントで自己改善を行うフィードバックループへと役割が大きくシフトし、手動デバッグの膨大な時間を削減します。
Agentic workflow（エージェント型ワークフロー）は驚くほど効率的になります：
- AIエージェントが初期コードを生成します。
- anti-slopが実行され、問題を即座にフラグ立てします。
- エージェントは詳細なエラーメッセージを解析し、具体的な指示を受け取ります。
- 最後に、エージェントはその正確なガイドラインに基づいてコードを修正し、より高品質な出力を実現します。この反復プロセスにより、根拠の薄いパターンが本番環境に到達するのを防ぎます。これらの独断的なルールの全リストについては、GitHub - dmmulroy/anti-slop: Opinionated Oxlint rules for rejecting low-evidence TypeScript and JavaScript patterns リポジトリを確認してください。
この記事が気に入ったら、毎朝同じようなものをメールで受け取れます。
1日1通 · 2クリックで解除 · サードパーティのトラッキングなし
悪習から堅牢なコードへ
anti-slopルールを導入することで、開発の焦点が根本から変わります。バグが発生した後に対応するのではなく、バグの原因となる低品質なパターンを未然に防ぐことができます。このリンターは、重要な型情報を破棄する安全でない chain type assertion（チェーン型アサーション）のような問題のあるコードをソースレベルで捕捉します。例えば、APIレスポンスを unknown にキャストしてから User にキャストすると、createdAt が日付ではなく文字列である可能性を見落とし、コンパイル前に潜在的なバグを混入させる可能性があります。
予防を超えて、anti-slopはチームのコーディング基準を形式化します。機械可読で強制力のあるルールセットを確立することで、一般的かつ重要な問題に対する人間のレビュー時間を節約できます。つまり、unknown を返す関数やその他の根拠の薄いTypeScriptパターンなどを人間が指摘する必要がなくなります。リンターがこれらをフラグ立てし、なぜ問題なのか、そして境界で信頼できない入力を解析する方法など、どのように修正すべきかを説明します。
anti-slopを CI/CD pipeline またはローカル開発ループに統合することで、コードベース全体を体系的に「anti-slop（スロップ除去）」できます。これにより、人間とAIの両方の貢献が、より高い品質と根拠の基準を確実に満たすようになります。特にAIエージェントは、リンターの明確で実行可能なフィードバックに基づいて修正を行うことで、堅牢なコードを生成することを学び、真に堅牢で保守性の高いシステムを構築できます。
よくある質問
Anti-slopとは何ですか？
Anti-slopは、高性能なJavaScript/TypeScriptリンターであるOxlint向けの独断的なリンティングルールセットです。AIエージェントによって生成されがちな、根拠が薄くシグナルの低いコードパターンを拒否するように設計されています。
Anti-slopはどのようにAI生成コードを改善しますか？
フィードバックループを作成します。AIエージェントがコードを生成し、リンターが実行されて、なぜそのパターンが悪いのか、どう修正すべきかという非常に詳細なエラーを提供します。エージェントはこのフィードバックを使用してコードを修正し、決定論的に品質を向上させます。
Anti-slopはESLintの代替品ですか？
Anti-slopはOxlint上で動作するルールを提供します。OxlintはESLintと併用可能であり、またESLintよりもはるかに高速な代替手段として使用できるリンターです。OxlintはESLintと比較して50〜100倍高速であるとベンチマークされています。
Anti-slopはどのようなコードパターンを捕捉しますか？
コンパイルは通るものの「コードの臭い（code smell）」と見なされるコードを捕捉します。例として、チェーン型アサーション（例: as unknown as User）、未知のパラメータや戻り値の型を持つ関数、その他型安全性を損なう根拠の薄いパターンなどが含まれます。