Claude CodeのRules設定について調べていると、ネット上で「alwaysApply: falseを設定すれば常時ロードを防げる」といった記事を見かけることがあります。
しかし、これはClaude Codeでは誤りです。
Claude CodeのRules仕様を改めて整理し、「alwaysApplyはClaude Codeでは利用できない」ことの説明をしようと思います。
誤解されやすい alwaysApply
一部の記事では以下のような設定例が紹介されています。
---
alwaysApply: false
---
または
---
alwaysApply: true
---
そして、
true→ 常時ロードfalse→ 必要時のみロード
と説明されているケースがあります。
ですが、これはCursor Rules（.cursor/rules/*.mdc）の概念と混同しているケースがほとんどです。
Claude Codeでは事情が異なります。
Claude CodeのRulesにalwaysApplyは存在しない
Claude Code公式ドキュメントを見ると、設定やRulesの仕様は以下を中心に構成されています。
CLAUDE.md.claude/settings.json- permission rules
- hooks
- pathsスコープ付きrule
ですが、alwaysApplyというフロントマター設定は公式仕様に存在しません。 (Claude Code)
つまり、
alwaysApply: true
や
alwaysApply: false
を書いても、Claude Code側で特別な意味を持つわけではありません。
単なる未使用メタデータです。
なぜ誤情報が広がっているのか
原因はかなりシンプルです。
AIコーディングツールごとにRulesの仕組みが違うためです。
たとえば：
| ツール | Rules方式 |
|---|---|
| Cursor | .cursor/rules/*.mdc + alwaysApply |
| Claude Code | CLAUDE.md / .claude / hooks / settings |
| Codex系 | AGENTS.md など |
Claude CodeとCursorは似た用途ですが、Rulesの設計思想は別物です。 (agentlint.app)
そのため、
CursorのRule記事をClaude Code向けとして転載
あるいは
AIが生成した記事を十分検証せず公開
という流れで誤情報が混入しているケースが見受けられます。
Claude Codeで「常時ロード / 条件ロード」を実現する方法
「じゃあClaude Codeではどう管理するの？」という話ですが、Claude CodeにはClaude Codeなりの仕組みがあります。
1. CLAUDE.md
基本となる常時コンテキストです。
プロジェクトルールや開発方針を書く場所です。
例：
# Project Rules
- TypeScript strict mode
- テスト必須
- ESLint warning禁止
2. pathsスコープ
Claude CodeではYAML frontmatterのpathsを利用して、対象ファイルに応じたRule適用が可能です。 (Zenn)
例：
---
paths:
- "frontend/**"
---
ただし注意点があります。
公式説明では「該当ファイル作業時のみ適用」とされていますが、実際には一度読み込まれたRuleがセッション中残り続ける挙動も報告されています。 (Zenn)
つまり、
paths= CursorのalwaysApply: false
という理解も正確ではありません。
3. hooks活用
より厳密に制御したい場合はhooksが有力です。
例えば：
- 特定作業前にRule読み込み
- ファイル種別で切替
- 必須チェック強制
など。
Claude Codeでは「Ruleを書く」より「hookで制御する」方が強力なケースも多いです。 (Claude Code)
まとめ
結論です。
Claude CodeのRulesではalwaysApplyは使えません。
整理すると：
alwaysApplyはCursor Rulesの概念- Claude Code公式仕様に
alwaysApplyは存在しない alwaysApply: true/falseを書いてもClaude Codeでは意味を持たない- Claude Codeでは
CLAUDE.md、paths、hooks、settingsで制御する
Claude Code関連記事は急増していますが、Cursorや他ツールの仕様が混ざったまま解説されている記事も少なくありません。
Rule周りは特に混同されやすい領域なので、公式仕様ベースで確認する癖を持っておくと混乱を避けられます。
