Zenn
👌

Claudeの「すぐルール忘れる問題」…にインスパイアされて100%解決した方法（俺調べ

に公開
AI
VS Code
tech
Claude
AIエージェント
tech

🔥 はじめに

以下の「Claude Codeの『すぐルール忘れる問題』を解決する超効果的な方法」を読んで「コレだ！」と膝を打った同志は多いはずだ。私もその一人。
https://zenn.dev/sesere/articles/0420ecec9526dc

同記事では AI に「毎回ルールを表示」という 再帰ルール を埋め込むことで、忘却を防ぐ手法が紹介されていた。だが、私の場合、気を抜くとすぐにルールファイルが1000行とか超えてしまうので、 「チャットログにルール全文が現れると長すぎる」 という現実があった。

解決策はシンプル—— すべてのソースの先頭に、たった１行だけ書く 

// 絶対厳守：編集前に必ずAI実装ルールを読む

それだけだ。この１行がすべてのソースに必要だが AIエージェント の視界に常に入ることで、巨大なルールファイルをチャットに貼らずとも “ルール読め” トリガーが常時発火する。もちろん、この1行自体も人間が書くのではない。以下が「AI実装ルール」mdファイルの冒頭だ。


AI実装ルール

🚨🚨🚨 【重要】ソースファイル必須事項（絶対厳守）

絶対厳守：編集前に必ずルールを読む

📝 ソースファイル先頭コメント必須

全てのソースファイル（.ts, .tsx, .js, .jsx）の先頭に必ず以下のコメントを記載：

// 絶対厳守：編集前に必ずAI実装ルールを読む

既存ファイルにコメントがない場合は必ず追加すること。

〜〜〜 ここ以降にルールを書く 〜〜〜

⚙️ なぜ「１行コメント」が効くのか？

  1. 視認性 100%
    AIエージェントはコード全体をコンテキストに取り込む。ファイル冒頭は常に優先的に解析されるポジションだ。
  2. チャット汚染ゼロ
    ルールが巨大でも、チャットには現れない。AI が自己解釈で内部参照するだけ。
  3. 編集者への武士の一喝
    人間エンジニアもファイルを開いた瞬間に「読め」と叱られる。読み飛ばし事故を減らす二重ロック。

参考ルール

以下は「すぐルール忘れる問題」は関係ない。参考までに私が上記の続きで書いてる（厳密には私でなくAIが書いた）ルールの一部だ。React Next プロジェクトだが、私の場合はおそらく他のプロジェクトでも似たような感じなるはずだ。なぜ、駆け出しの初心者を諭すような内容になってるかは、想像がつくと思う。AIエージェントが失敗するたびに、今言った内容をルールに足してね、を繰り返した結果だ。


🚨🚨🚨 【重要】緊急復元ルール（絶対厳守）

ファイル編集中に以下を検出したら、即座に作業を停止してgit履歴から復元せよ：

🆘 緊急復元が必要な状況（自動検出必須）

  • 急激なファイルサイズ減少: 編集前の50%以下になった場合
  • 元コードの大幅消失: 主要な関数・コンポーネントが消えた場合
  • 空ファイル化: 意図しない空ファイルになった場合
  • TypeScript型エラー大量発生: 元は正常だったファイルで多数のエラー
  • 重要な実装の消失: ツールチップ、計算ロジック、UIコンポーネント等

🔄 緊急復元の実行手順（即座に実行）

# 1. 即座に作業停止
echo "🚨 緊急復元開始: ファイルの異常を検出"

# 2. git履歴から最新の正常版を復元
git checkout HEAD -- ファイルパス

# 3. 復元確認
git status
git diff ファイルパス

# 4. 原因分析（ツール使用ミスの検証）
echo "🔍 復元完了。原因を調査し、安全な編集方法で再実行"

🛡️ 予防策（常時適用）

  • 編集前バックアップ: 重要ファイルはcp file.tsx file.tsx.backup
  • 最小限編集: 一度に大量の変更を避ける
  • 段階的確認: 各編集後にgit diffで変更を確認
  • 復元優先: 疑わしい場合は復元を選択

この緊急復元ルールは他の全てのルールより優先される。

🗂️ プロジェクト管理ルール

  • mdファイル配置: docs/ディレクトリ（README.md以外）
  • AI指示ファイル: AIエージェントによる
  • コミットメッセージ: 日本語で記述（例: feat: 新機能を追加）

🧹 作業開始前の必須準備（絶対厳守）

全ての実装作業前に必ず実行すること：

# キャッシュクリアスクリプト実行 (AIが作ったもの)
./scripts/clear-cache.sh

実行タイミング：

  • 作業開始前: 毎回必ず実行
  • 動作が遅い時: パフォーマンス低下を感じたら即座に実行
  • ビルドエラー解決困難時: 原因不明のエラーが続く場合に実行

効果：

  • Next.js キャッシュクリア（.next/cache）
  • Node.js キャッシュクリア（node_modules/.cache）
  • 開発環境に依存するキャッシュクリア

🚨 コミット実行ルール

コミット可能条件（以下をすべて満たした場合、自動実行可能）：

  • 0バイトファイル削除済み: 空ファイルが存在しないこと
  • ビルドエラーなし: npm run buildが成功すること
  • テストエラーなし: 全てのテストが失敗でないこと（warningは許可）

禁止事項：

  • 条件未満時の強制コミット: 上記条件を満たさない状態でのコミット
  • ユーザー指示無視: 明示的にコミット停止指示がある場合の実行

💻 AI実装の基本原則

🚨 重要：意図しない大量削除防止策

  • 段階的編集: 一度に大量の変更を避け、小さな単位で確認しながら編集
  • 最小限修正: 1つの問題に対して必要最小限の変更で対応
  • 編集前確認: 重要ファイルはcp file.tsx file.tsx.backupでバックアップ
  • 変更確認: 各編集後にgit diffで意図した変更のみが行われているか確認

🔄 効果検証と対策の撤回原則（絶対厳守）

  • 無効対策の即座撤回: 問題解決に効果がない対策は直ちに元に戻す
  • 複数対策禁止: 効果のない対策を累積させると保守不能・バグ温床化
  • 単純化優先: 複雑な対策より単純で確実な解決策を選択
  • 検証必須: 対策実装後は必ず効果を確認し、無効なら即座に撤回

🛠️ 対策実装の手順

  1. 問題の根本原因特定: 表面的症状でなく真の原因を分析
  2. 最小限対策実装: 必要最小限の変更で問題解決を試行
  3. 効果即座検証: 実装後すぐに問題解決を確認
  4. 無効対策撤回: 効果がない場合は元に戻して別アプローチ
  5. 成功対策保持: 効果確認できた対策のみ保持

🔍 コード品質管理ルール（絶対厳守）

🏗️ データ構造設計原則（絶対厳守）

「動作しているから良い」という妥協は絶対禁止

🚨 禁止事項（即座にリファクタリング対象）

  • 技術的負債の許容: 「現在の構造は複雑で理想的ではないが機能的には動作している」
  • 短期的解決の積み重ね: 問題の根本解決を避けた対症療法的修正
  • データ重複の放置: 同じ情報が複数箇所で管理されている状態
  • 分類基準の混在: 異なる観点による分類が同一データ構造内に混在

✅ 必須実装方針（将来性・保守性最優先）

  • Single Source of Truth: 全てのデータは単一の信頼できる情報源から提供
  • 明確な分類基準: 一貫した観点による論理的なデータ分類
  • 拡張性重視: 新機能追加時に既存構造への影響を最小化
  • 型安全性: コンパイル時にデータ整合性を保証する型設計
  • 検索最適化: 使用パターンに応じた効率的なデータアクセス構造

🔄 リファクタリング判断基準

  1. 重複排除: 同じデータが2箇所以上に存在する → 即座に統合
  2. 分類整理: 分類基準が不明確 → 論理的な階層構造に再編
  3. 型強化: 型安全性が不十分 → 厳密な型定義に移行
  4. 性能改善: 非効率なデータアクセス → インデックス化・最適化

このデータ構造設計原則は、短期的な実装コストより長期的な保守性を優先する。

🔍 全ソーススキャン必須ルール

関数・定義の追加・修正・削除前に必ず実行：

📋 追加時の必須手順

  1. 全ソーススキャン: grep -r "類似機能名" src/ で既存の同様コードを検索
  2. 重複確認: 同じような機能・処理が既に存在しないか確認
  3. 共通化検討: 類似コードが存在する場合は共通化を実装
  4. プライベート化: 1箇所でのみ使用する関数は同一ファイル内に宣言し、exportを付けない

⚠️ 修正・削除時の必須手順

  1. 全ソーススキャン: grep -r "対象関数名" src/ で全使用箇所を特定
  2. 修正漏れ防止: 類似コードがある場合は同時に修正
  3. 削除漏れ防止: 削除対象の関連コード・依存関係も併せて削除
  4. 影響範囲確認: 修正・削除が他のファイルに影響しないか確認

🔗 共通化とプライベート化の原則

  • 共通化対象: 2箇所以上で使用される同様の処理
  • プライベート化対象: 1箇所でのみ使用される関数・定義
  • 共通化場所: src/lib/ 配下の適切なユーティリティファイル
  • プライベート化: 同一ファイル内に宣言し、export を付けない

この全ソーススキャンルールは、コードの重複・不整合・保守性低下を防ぐための必須手順である。

📏 分割統治（ファイルサイズ管理）

  • 300行以下: 分割不要（適切なサイズ）
  • 301-500行: 責任別分離を検討
  • 501行以上: 即座に分割実行

🗑️ 関数削除の段階的プロセス

  1. @deprecated マーキング: 削除前に非推奨化
  2. 使用箇所確認: grep -r "関数名" src/ で全検索
  3. 猶予期間: 最低1週間の非推奨期間
  4. 物理削除: 使用箇所0件確認後に実行

🎯 技術的な実装指示

技術仕様の参照先

仕様詳細はルールに記載せず、各ソースファイルのコメントに記載

技術的な実装詳細・計算方法・関数仕様等は、該当するソースファイル内のコメントを参照すること。
ルールファイルには基本方針のみを記載し、具体的な実装はソースコードで管理する。

🧪 必須テスト・チェック

各作業終了後は必ず以下を実行：

  • npm test （全テスト）
  • npm run build （ビルド確認）
  • npm test -- --testPathPatterns=timeline-consistency （一貫性テスト）

🗑️ ファイル完全削除の手順（絶対厳守）

🚨 重要：単純なrmでは不完全・復活の原因

AIエージェントは必ずこの手順を実行すること。例外は認めない。

ファイルを削除する際は、以下の完全削除手順を7ステップ全て必ず実行：

# ステップ1: 物理ファイル削除
rm -f ファイル名

# ステップ2: Gitインデックスから完全削除
git rm --cached ファイル名 2>/dev/null || true

# ステップ3: Git履歴からも削除（強制）
git rm ファイル名 2>/dev/null || true

# ステップ4: Gitインデックスリセット
git reset HEAD -- ファイル名 2>/dev/null || true

# ステップ5: .gitignoreパターン確認（具体的ファイル名追加は禁止）
# 注意：具体的なファイル名は追加しない。パターンで対応済み

# ステップ6: 削除確認（何も表示されなければ成功）
ls -la ファイル名 2>/dev/null || echo "✅ 完全削除成功"

# ステップ7: 開発環境復活防止強化対策（重要ファイルのみ）
# 詳細は下記「最終確認と開発環境復活防止の強化対策」セクション参照

🚨 AI実装時の絶対ルール（破ったら失敗扱い）

  • 単純削除は絶対禁止: rm ファイル名のみは100%復活する
  • 7ステップ完全実行: 上記手順を1つでも飛ばしたら不完全
  • run_in_terminal使用: 必ずrun_in_terminalツールで実行
  • 開発環境対策必須: 開発環境が空ファイルとして復活させることを防ぐ
  • Git完全除去: Git履歴・インデックス・キャッシュから完全除去
  • 復活防止強化: 重要ファイルはステップ7の強化対策も実行

🔍 削除対象パターン（定期的に検出・削除）

  • 空ファイル: find . -type f -size 0 -not -path "./.git/*"
  • バックアップファイル: *.backup*, *.bak
  • デバッグファイル: debug-*, *.debug
  • 一時ファイル: *.tmp, *.temp, *.~
  • 重複ファイル: 移動済みで元の場所に残存
  • 開発環境復活ファイル: 空の.tsx, .ts, .jsファイル

❌ 絶対禁止：不完全削除（復活の原因）

# ❌ 禁止：単純削除（100%復活する）
rm ファイル名

# ❌ 禁止：git rmのみ（物理ファイルが残存）
git rm ファイル名

# ❌ 禁止：確認なし削除（失敗の検知不可）

✅ 正しい完全削除例（必ずこの形式で実行）

# 例：不要なxxx.tsの完全削除
rm -f src/lib/xxx.ts
git rm --cached src/lib/xxx.ts 2>/dev/null || true
git rm src/lib/xxx.ts 2>/dev/null || true
git reset HEAD -- src/lib/xxx.ts 2>/dev/null || true
# 注意：具体的ファイル名はgitignoreに追加しない（パターンで対応済み）
ls -la src/lib/xxx.ts 2>/dev/null || echo "✅ 完全削除成功"

🔄 削除後の必須チェック

  • find . -type f -size 0 -not -path "./.git/*" で空ファイル検出
  • git status で削除されたファイルが表示されないことを確認
  • 開発環境再起動後もファイルが復活しないことを確認

この7ステップ完全削除手順は、重要ファイル削除時に必ず実行すること。

� .gitignore重要ルール（絶対厳守）

# 1. 空ファイルを全て検出・削除
find . -type f -size 0 -not -path "./.git/*" -not -path "./node_modules/*" | while read file; do
    echo "🗑️ 空ファイル削除: $file"
    rm -f "$file"
    git rm --cached "$file" 2>/dev/null || true
    git rm "$file" 2>/dev/null || true
    # 注意：具体的ファイル名はgitignoreに追加しない（パターンで対応済み）
done

# 2. バックアップ・デバッグファイル削除
find . -name "*.backup*" -o -name "*.bak" -o -name "debug-*" -o -name "*.debug" -o -name "*.tmp" -o -name "*.temp" | while read file; do
    echo "🗑️ 不要ファイル削除: $file"
    rm -f "$file"
    git rm --cached "$file" 2>/dev/null || true
    git rm "$file" 2>/dev/null || true
    # 注意：具体的ファイル名はgitignoreに追加しない（パターンで対応済み）
done

# 3. 削除確認
echo "✅ 清掃完了。残存不要ファイル確認:"
find . -type f -size 0 -not -path "./.git/*" -not -path "./node_modules/*" || echo "✅ 空ファイルなし"

この清掃は実装前後に必ず実行すること。

🛡️ 最終確認と開発環境復活防止の強化対策（絶対実行）

開発環境や他のエディタがファイルを復活させることを完全に防ぐための追加対策

# ステップ7: 最終確認と開発環境復活防止
# 1. ファイルが完全に削除されているか最終確認
find . -name "*削除対象ファイル名*" -not -path "./.git/*" -not -path "./node_modules/*" || echo "✅ 対象ファイルなし"

# 2. .gitignoreパターンの確認（必要に応じてパターン追加）
echo "🔍 .gitignoreパターン確認:"
grep -n "_new\|backup\|debug\|tmp" .gitignore

# 3. 開発環境設定からファイル参照を削除
if [ -d .開発環境 ]; then
  find .開発環境 -name "*.json" -exec grep -l "削除対象パターン" {} \; 2>/dev/null | while read file; do
    echo "🔍 開発環境設定ファイルから削除: $file"
    sed -i '' '/削除対象パターン/d' "$file" 2>/dev/null || true
  done
fi

# 4. ファイルシステム状態リセット（開発環境復活防止）
git add -A
git stash
git stash drop 2>/dev/null || true

# 5. .gitignoreに適切なパターンが存在することを確認
# 既存パターン例: *_new.*, *.backup*, debug-*, *.tmp, *.temp
# 新しいパターンが必要な場合のみ追加（具体的ファイル名は禁止）

echo "✅ 開発環境復活完全防止対策完了"

🚨 開発環境復活防止の重要ポイント

  • Git管理除外: .gitignoreパターンでエディタの自動生成を無視
  • 設定クリーンアップ: 開発環境設定ファイルから削除対象の参照を除去
  • ファイルシステムリセット: git stash/dropでクリーンな状態に戻す
  • パターン追加: 必要時のみ.gitignoreにパターン追加（具体名禁止）
  • 多層防御: 物理削除 + Git除去 + エディタ設定 + 無視パターン

この7ステップ完全削除手順は、重要ファイル削除時に必ず実行すること。

🚨 .gitignore重要ルール（絶対厳守）

  • 具体的ファイル名追加禁止: echo "src/lib/file.ts" >> .gitignore は絶対禁止
  • パターンのみ使用: debug-*, *.tmp, *.backup* などのパターンのみ許可
  • 理由: 具体的ファイル名の追加は管理の混乱と肥大化を招く
  • 対処法: 既存パターンで対応済み。追加の必要なし


✨ まとめ

  • 再帰ルールで「忘れない AI」を実現した先人の知見を １行コメント というミニマルな形で昇華
  • 緊急復元ルールが開発資産を守り
  • コミット実行ルールがヒューマンエラーを遮断し
  • AI実装の基本原則がコードを未来へ繋ぐ。

これらを常に思い出させるのが冒頭の１行コメントだ。ルールがたとえ 1000 行を超えても、AI は「読むべき場所」を確実に把握し、暴走を免れる。


型破りな発想は、型を護る者に宿る。

ルールを刃に、AI を味方に。
次にキーボードを叩くとき、君のコードはもう二度と壊されない。

Discussion