AIコーディングエージェントの暴走を防ぐルール集

この記事はAIコーディングアシスタントを、希望に基づくプロンプトから制約に基づくルールへシフトすることで制御する手法を提示している。著者は問題を診断することから始める。最初の2週間はモデルが魔法のように見えるが、コードベースがモデルがコンテキストに収まるものを超えて成長すると、「Aを修正しながらBを破壊」し始める。著者はこれはスキル問題ではなく構造問題だと主張する。より強いプロンプトでは解決できない問題だ。

当面のアクションはプロジェクトルートにCLAUDE.mdファイルを作成することで、プロジェクト説明、現在の状態、「Do not touch」セクション、明示的なルールを含む。Claude Codeはこのファイルをすべての会話開始時に自動読み込みする。CursorはcursorrulesをCoex/CopilotはAGENTS.mdを同じ内容で使用する。核となるルールは「指定していないファイルを修正するな」である。著者はこれを曖昧な肯定的指示と対比する。「きれいなコードを書いてくれと言う何もしない。きれいさに閾値がないので、行動は変わらない。禁止事項は明確な境界を持つ。即座に適用される。」

記事は次に5つのプロンプトを提供して破壊を防ぐ。第1―「コードをまだ書くな。まずどのファイルに触れるか、どこが危険か教えて」―は実行前の計画を強制し、ほとんどの副次被害を殺す。第2―「これを変える前に、何が他に影響を受けるか教えて」―はモデルが依存関係を述べるよう強制し、無視したであろうカップリングを浮上させることが多い。第3―「機能すると言うな。テストを書いて合格を見せて」―は中核的な弱点に対処する。モデルはそれを構築した同じ想定を使ってコードをレビューするため、間違った想定は両方のパスを生き残る。合格テストは証拠。「見栄えがいい」は意見だ。第4プロンプトはセッション終了前に実行され、完了内容、次のステップ、試行して放棄された事項の要約を求める。最後の項目が重要で、なければ新規セッションはちょうど失敗したアプローチを自信を持って再度提案する。第5は簡単にルールファイル最高価値行である。「指定していないファイルを修正するな。」

著者はコンテキスト腐食にも対処する。長いセッションは放棄された方向と修正された間違いがコンテキストに蓄積するため悪化する。シグナルを履歴に埋める。解決策は3～5タスクごとに新規セッションを開始し、閉じる前にサマリープロンプトを実行すること。同じリクエストを3回目に依頼しなければならない場合、著者はウィンドウを変更するようアドバイスする―「そのセッションはもはや答えを生産できない。」

可逆性については、著者は取り消し可能なものはすべて簡単にし、取り消し不可能なアクションのみをゲートすることを勧める。可逆性ルールが提供される。読む、検索する、分析する、ローカル編集（状態が保存されている場合）、下書き、テスト実行はすべて低リスクで自由にすべき。削除、デプロイ、ペイメントまたは注文は取り消し不可能で確認が必要。著者はまたキルスイッチ―すべての作業を即座に停止するSTOP.txtファイル―の追加も提案するため、開発者は自律的に動作するエージェントを安心して放置できる。

最後に、記事は事前に想像されたルールはほぼ役に立たず、実際の破壊から抽出されたルールが持つ規則を強調する。モデルが失敗するたびに、その特定の失敗をルールファイルに追加すべき。「既知のトラップ」セクションが例として提供される。order_service.pyの在庫控除はトランザクション外（既知、放置）、test_payment.pyはライブAPIにヒット（控え目に実行しない）、イベント駆動アプローチは試行して放棄（再度提案するな）。著者はこれを1週間行うと間違いが繰り返すのを止めるとクレームする。

記事はフレームワーク全体を一度に採用する必要がないことで終わる―CLAUDE.mdを今晩書くと明日を変える。著者は購入可能な25ページのフィールドマニュアル（「Working With Claude Code — Field Manual · 19ドル · PDF」）についても言及し、承認ゲート、フック、キルスイッチ、スキル、コスト制御、症状から原因から修正へのテーブルをカバーするが、上記のREADMEがほとんどの人にとって有用な半分であることを強調する。

この記事は実在する問題を扱っている。AIコーディングアシスタントが1回の会話内でより有能になるにつれ、スケールでより危険になるという問題だ。著者の観察―最初の2週間の見かけ上の魔法の後、モデルが問題Aを修正しながら問題Bを破壊し始めるという観察―は、単一タスク性能と複数ファイルの一貫性の隔たりを反映している。提案されたソリューションはモデルをより良く訓練したり、より強くプロンプトしたりしようとしない代わりに、これを制約を必要とする構造的問題として扱う。

ルールフレームワークは特定の洞察に基づいている。曖昧な指示は実行境界がないから失敗するということだ。「注意して」や「きれいなコードを書け」は願いだが行動的に空である。「指定していないファイルを修正するな」という禁止事項は明確な境界があるため実行可能だ。同じ論理は5つのプロンプトにも拡張される。各プロンプトは検証の負担をモデルの自己レビュー（その想定を継承する）から外的証拠へシフトさせる。テストが合格すること、または実行前にプランが述べられることを要求することで、モデルがバグを作った同じ欠陥のある論理を用いて合理化できないチェックポイントを作成する。

著者はコンテキスト腐食も実践的な失敗モードとして識別する。長いセッションは放棄された方向と修正された間違いを蓄積し、それらはコンテキストウィンドウに留まってシグナルを腐す。解決策―3～5タスクごとに新規セッションを開始し、試行されて放棄された事項の要約をする―は、モデルが失敗したアプローチを再度提案するのを防ぐ状態リセットの形式だ。最後に、可逆性原則（エージェント実行前に状態を保存し、取り消し不可能なアクションのみをゲートする）はリスク管理の洞察である。低リスク領域ではモデルが反復するのを自由にしながら、デプロイなどの高リスク決定に対する人間のコントロールを維持する。

まだコメントがありません。最初のコメントを投稿しましょう！