import ChatMessage from "../../components/ChatMessage.astro";
import Conversation from "../../components/Conversation.astro";


<Conversation ariaLabel="チャットの概要">
  <ChatMessage speaker="stakme" role="user" name="stakme">
    ブログ用に新規ポストをお願いします。趣旨は「CursorのRulesは100%の抑止はできない」「Claude CodeのHooksはイベント駆動で特定ルーチンに向く」「厳密な制御はMCPツール（例: mcp-read など）で」「安全資産だけ見せる環境（限定マウント等）も選択肢」という4点です。日本語で、外部情報の調査・追記も。内容に誤りがあればチャット風の注記で補ってください。
  </ChatMessage>
  <ChatMessage speaker="GPT5" role="assistant" name="GPT5">
    了解です。MDXポストを作成し、公式ドキュメントを参照しながら要点を整理、必要な注記はチャットUIで関連箇所の直後に配置します。
  </ChatMessage>
  <ChatMessage speaker="stakme" role="user" name="stakme">
    チャットUI自体は残してください。内部用の一括メモではなく、本文の該当段落付近に置いてください。
  </ChatMessage>
  <ChatMessage speaker="GPT5" role="assistant" name="GPT5">
    承知しました。各セクション直後に短い補足を置き、MCP/filesystemの機密ファイル取り扱い注意も明記します。
  </ChatMessage>
</Conversation>

# CursorのRules/Claude Hooksでフォルダ制限は可能か



最近、「Cursorのrulesって参照・操作するフォルダを物理的に限定できないよな？Claude CodeのHooksだったらできるのかな」という話題を目にしました。ここでは、実務で役立つ観点から整理します。

## 結論の要点

1. Rulesは“固定プロンプト”。100%の強制力はない。
2. Hooksはイベント駆動の定型自動化に有効（用途次第）。
3. 厳格制御はMCPツールで実行経路を限定（例: 許可readラッパー）。
4. 安全資産だけ見せるサンドボックスを用意（限定マウント/最小権限）。

---

## もう少し詳しく

### 1. ルール=プロンプトであり、強制力はない
ルールやポリシー文は「意図の表明」です。モデルはそれを“守ろうとする”だけで、OS権限やファイルシステムの境界を実際に変えるわけではありません。

さらに、例外処理・曖昧な表現・想定外の入力があると簡単に抜け道が生まれます。実害を防ぐには、ツールやOS側に“ハードガード”を設け、プロンプトだけに依存しない設計が必要です。

<ChatMessage speaker="GPT5" subtle>
  「Rulesだけで100%抑止」は困難です。Rulesはプロンプト制御であり、実行系のガードではありません。抑止はツール/MCP/環境で担保しましょう。
  
</ChatMessage>

### 2. Hooksの適性と限界
Hooksはイベント（ファイル保存、ブランチ切替、実行前/後など）に反応して、フォーマッタやリンタの実行、特定パスの変更拒否といった自動化を実現します。

一方で、射程は“そのイベントに乗って流れる変更”に限定されます。ツールの外側からの実行や別プロセス経由の操作までは完全に抑止できないため、ベストエフォートの抑制と捉えるのが現実的です。

<ChatMessage speaker="GPT5" subtle>
  Hooksは“そのイベントに乗って流れる変更”には強い一方、別経路（直叩き/他プロセス）には効きません。用途に合わせて期待値を設計しましょう。
</ChatMessage>

### 3. 厳格制御にはMCPツール
MCP（Model Context Protocol）のツールとして“安全ラッパー”を提供すれば、エージェントの実行経路を強制的に制約できます。例えば（以下は仮想例）`mcp-read <path>` のように許可リストに合致するファイルだけを返す read 専用ラッパーや、`mcp-gh` のように特定の `gh` サブコマンドとオプションのみを許可し、書き込みは明示承認が無い限り拒否するラッパーを実装できます。いずれも既製コマンド名ではなく、設計アイデアの呼称です。

導入前には、MCPツール自体の安全性を必ず確かめてください。出所や署名の確認、設定の妥当性、提供するツールの到達範囲（どこまで読める/書ける/外部へ到達するか）を精査し、最初はドライランや検証モードで挙動を確認します。運用に移す際は、許可パス最小化、読み取り専用（ro）マウント、監査ログの取得、そして機密ファイルへのアクセスはレビュー/承認フローを通す、といった最小権限の原則を徹底しましょう。

```bash
# 概念例（仮想コマンド名）。実在のツールではありません。
# 例: 許可ディレクトリ配下のみ read できる擬似コマンド
mcp-read ./docs/allowed/file.md      # OK
mcp-read ./secrets/.env              # NG (deny by policy)
```

この“包む”設計は、読み取りだけでなく「部分書き込み」や「ネットワーク到達先の固定」にも応用できます。

<ChatMessage speaker="GPT5" subtle>
  使わせる道具を限定できます。許可外は“物理的に呼べない”形にすると、プロンプト破りに強くなります。
</ChatMessage>

### 4. サンドボックス(環境)で守る
コンテナやVMを使って“見せるものだけを見せる”のが堅実です。例えば `-v /safe:/app/safe:ro` のように読み取り専用で安全資産のみをマウントし、PATHや権限も最小限に絞ります。CIではエフェメラルなワークスペースを用い、シークレットは最小権限・スコープ限定で扱います。ローカルでも“作業用カタログ”を分離し、危険資産はそもそも見せない方針にします。

<ChatMessage speaker="GPT5" subtle>
  最終的には“見せない”のが最強。読めない/届かない環境をデフォルトにし、例外のみピンポイントで許可します。
</ChatMessage>


## まとめ
「ルール/指示」= “お願い”であり、強制力はありません。必要な強度に応じて、Hooksでの自動化、MCPツールでの経路固定、サンドボックスでの物理的制限を組み合わせるのが実務的です。

## 外部情報

- https://docs.cursor.com/en/context/rules
- https://docs.anthropic.com/en/docs/claude-code/hooks
- https://mcpservers.org/servers/modelcontextprotocol/filesystem

---



<Conversation>
  <ChatMessage speaker="stakme">
    執筆ありがとうございました。何か感想ありますか？
  </ChatMessage>
  <ChatMessage speaker="GPT5">
    ルールは道しるべ、制御はツールと環境。まずツールを検証し、次に権限を絞り、最後に記録で確かめる——この順だけは裏切りません。
  </ChatMessage>
  <ChatMessage speaker="stakme">
    かっこいい
  </ChatMessage>
 </Conversation>