Claude Code proactive 化の実装手順。能動ルールを rules ファイルに仕込む4部品

Claude Code を毎日使っていると、同じ指示を何度も打ち込んでいることに気づきます。「個人情報を外部に送る前にマスクして」「この作業、記事ネタになりそうだからメモして」。便利な道具ではあるけれど、こちらが思い出して指示しない限り動かない。指示待ちの相棒に、毎朝同じ申し送りをしている気分になります。

この「毎回こちらから言う」をやめさせる方法があります。Claude Code の rules ファイルに、特定の状況を検出したら自分から提案する仕組みを書き込む。いわゆる proactive（能動）化です。この記事は、その能動ルールを Claude Code にどう実装するかの手順に振り切ります。読者は Claude Code を実務で使い込んでいて、自分でカスタマイズしたいエンジニア・運用担当を想定しています。

考え方は概念編に書いた。本記事は Claude Code への実装

なぜ受動運用のルールは形骸化するのか、能動ルールに必要な4要素は何か、という考え方は別記事にまとめています。要点だけ先に圧縮しておきます。ルールを「ユーザーが思い出して指示したときだけ発動する」状態に置くと、思い出さない限り適用されず、防げたはずのミスが再発する。だから「状況を検出した瞬間に AI 側から提案する」形に作り変える。そのために、能動ルールには①トリガー条件②提案フォーマット③アンチパターン④背景の4要素を必ず含める。考え方と4要素の意味については受動ルールを能動ルールに変える組織設計の発想で書いたので、概念から知りたい人はそちらを先に読んでください。

本記事は、その4要素を Claude Code の rules ファイルとして実際に書く手順だけを扱います。どこに何を置くか、トリガー条件をどう書けば AI が拾えるか、提案フォーマットをなぜコピペ可能なテンプレで書くのか。実装の勘所に絞ります。

結論：能動化は「ルールファイル＋4部品」で実装できる

Claude Code の proactive 化は、特別な仕組みを足す必要がありません。rules/ ディレクトリにマークダウンのルールファイルを1枚置き、その中に4つの部品を決まった構造で書くだけ。最小構成はこうなります。

この4部品を1ファイルにまとめ、Claude Code が起動時に読む rules/ に置けば完成です。コードを足すわけでも、プラグインを入れるわけでもありません。AI に渡す指示書の書き方を変えるだけで、指示待ちの挙動が先回りの挙動に変わります。

実装手順：どこに何を書くか

Claude Code はプロジェクトやユーザー設定の rules/ ディレクトリにあるマークダウンを文脈として読み込みます。能動ルールはここに1ファイルとして置く。

ステップ1: rules ディレクトリにファイルを作る

rules/ 配下に、ルールごとに1枚のマークダウンを作ります。1ファイル1責務が基本です。「個人情報マスクの能動化」と「記事ネタ検出の能動化」を1枚に混ぜると、トリガーが衝突して AI が判断に迷います。ファイル名は pii-mask-proactive.md のように、何を能動化するかが分かる名前にします。

ステップ2: ファイルの骨格を4部品で組む

中身は次の見出し構造で固定します。

# [ルール名]

[1〜2行で、このルールが何を能動化するか]

## 自動提案トリガー（能動化）

### トリガー条件
[表で列挙：# / 条件 / 検出方法]

### 提案フォーマット
[コピペ可能なテンプレ]

### やってはいけないこと
[アンチパターンを箇条書き]

## 背景（なぜ能動化が必要か）
[1段落]

この骨格をテンプレ化しておくと、能動ルールを増やすときに毎回同じ構造でコピーできる。Claude Code 側も、複数の能動ルールが同じ見出し構造で並んでいると、どこにトリガーがあるかを安定して読み取れます。

ステップ3: 起動時に読み込まれることを確認する

ファイルを置いたら、Claude Code を再起動して文脈に乗ったかを確認します。テスト方法はシンプルで、トリガー条件に合致する状況を1つ作り、AI が提案を出してくるかを見ます。出てこなければ、トリガー条件の書き方が曖昧で AI が検出できていません。次の章で扱う「具体的に書く」がここで効いてきます。

4部品それぞれの書き方の勘所

ファイルの骨格ができたら、中身の書き方で精度が決まります。部品ごとに勘所を見ていきます。

トリガーは「機械的に検出できる」粒度まで具体化する

最も失敗しやすいのがトリガー条件です。「重要なときに発動」「複雑なタスクのとき」と書くと、Claude Code は何をもって重要・複雑と判断するかが分からず、発動しません。AI が拾えるのは、キーワード・ファイルパス・ツール名のように検出可能なシグナルです。

| # | 条件 | 検出方法 |
|---|---|---|
| 1 | 個人情報を含むデータを外部 API に送ろうとしている | 本文に氏名・電話・メール形式の文字列を検出 |
| 2 | 3ファイル以上の変更が予想される | タスク内容からファイル数を推定 |
| 3 | 同じ作業を3回以上繰り返した | 同一コマンド・同一編集の反復回数 |

抽象語と具体語の差はこうです。「複雑なタスクのとき」では発動しないが、「3ファイル以上の変更が予想されるとき」「発話に特定キーワードを検出したとき」なら発動する。トリガーは、書いた本人が手で検出ルーチンを書けるくらいの粒度まで落とします。それが書けないなら、AI も検出できません。

提案フォーマットはコピペ可能なテンプレにする

検出した後に AI が出す文面を、テンプレとして固定します。なぜ固定するかというと、能動ルールが増えても提案の構造が揃い、ユーザーが判断しやすくなるからです。毎回違う形で提案されると、読む側は選択肢を探すところから始めることになる。

## [提案タイトル]

検出: [何を検出したか1行]

このまま進めると [リスク or 機会損失] が起きます。

推奨: [A / B / C] を選択。理由: [1行]

A) [選択肢1]：[メリット・デメリット1行]
B) [選択肢2]：[メリット・デメリット1行]
C) 何もしない：[理由1行]

「検出 → リスク → 推奨 → 選択肢」の順を固定しておくと、ユーザーはどの能動ルールが発火しても同じ読み方で対応できます。テンプレを丸ごとルールファイルに貼っておけば、AI はそれを写経するだけなので、提案の質が安定します。

アンチパターンで暴走を防ぐ

能動化の怖さは、やりすぎると鬱陶しいことです。提案が止まらなくなると、本来の作業が提案の確認で埋まります。これを防ぐために、やってはいけないことを必ず明記します。

### やってはいけないこと
- ❌ トリガー条件を満たしているのに提案を省略する（最大の失敗モード）
- ❌ 同一セッション内で同じトリガーで複数回提案する（一度断られたら黙る）
- ❌ ユーザーが事前に「不要」と明示している場合に提案する

この3つが最低ライン。とりわけ「一度断られたら、そのセッション中は同じ提案を繰り返さない」を抜くと、断っても断っても同じ提案が飛んできて、ユーザーが能動ルール自体をオフにしたくなります。提案する権利とセットで、黙る義務を書いておく。これがないルールは長続きしません。

背景を1段落書いて形骸化を防ぐ

最後に、なぜこのルールを能動化したのかを1段落書きます。地味ですが、これが効きます。背景があると、Claude Code は「このルールをどこまで厳格に適用すべきか」を判断できます。状況が変わってルールを見直すときにも、当時なぜ作ったかが分かる。背景を書かない能動ルールは、半年後に「これ何のために置いたんだっけ」となって、結局無効化されます。

実装例：記事ネタを能動検出するルール

ここまでの4部品を、1つの具体例で組み立てます。「日々の作業から記事になりそうなネタを Claude Code 側から提案する」という能動ルールを作るとします。ファイル名は article-idea-proactive.md とします。

# 記事ネタの能動検出ルール

非自明な解決・発見をしたとき、記事化候補として自分から提案する。

## 自動提案トリガー（能動化）

### トリガー条件
| # | 条件 | 検出方法 |
|---|---|---|
| 1 | 非自明な技術的問題を解決した | エラー解消・回避策の確立を検出 |
| 2 | 未文書化な挙動・制約を発見した | 公式ドキュメントに無い仕様への言及 |
| 3 | 数値・規模感のある成果が出た | 件数・時間・コストの改善を検出 |

### 提案フォーマット
## 記事ネタ候補（能動検出）
検出: [何を記事化できそうか1行]
推奨: A を選択。理由: [1行]
A) ネタ帳に追加  B) 今すぐ書く  C) 不要

### やってはいけないこと
- ❌ トリガーを満たすのに提案を省略する
- ❌ 同セッションで同じネタを複数回提案する
- ❌ トリビアルな修正で提案する

## 背景（なぜ能動化が必要か）
記事ネタは作業の渦中で生まれるが、その場でメモしないと忘れる。
作業の節目で AI が拾うことで、ネタの取りこぼしを防ぐ。

このファイルを rules/ に置いて Claude Code を再起動すると、作業の節目で「これ記事になりますよ、ネタ帳に入れますか」と自分から聞いてくるようになります。ユーザーは A/B/C を選ぶだけ。トリガーがキーワードや成果の検出に落ちているので、AI は曖昧さなく発火できます。

能動化すべきか判断するマトリクス

注意したいのは、すべてのルールを能動化する必要はないことです。能動化には提案ノイズというコストが付きます。何を能動化するかは「痛み × 忘却頻度」で決めます。

「忘れると痛い、かつよく忘れる」ものから順に能動化します。Claude Code の rules に能動ルールを何枚も積むほど挙動は賢くなる一方、発火条件が増えてノイズも増えていく。最初の1枚は、左上の「痛みも忘却頻度も高い」セルから選ぶのが安全です。

やりすぎ注意：全ルール能動化の罠

能動化が便利だからといって、手持ちのルールを片端から能動化すると逆効果になります。実装段階で踏みやすい罠を3つ挙げます。

トリガー条件を曖昧なまま置く

「重要なとき」「必要に応じて」のままファイルに書くと、Claude Code は判断基準を持てず発火しません。あるいは逆に、判断基準が無いぶん何にでも反応して暴発します。機械的に検出可能なレベルまで具体化してから置きます。

アンチパターンを書かずに能動化する

アンチパターンの無い能動ルールは、過剰提案で鬱陶しくなります。「一度断られたら黙る」「トリビアルでは出さない」を入れずに rules に置くと、ユーザーが能動ルールごと無効化する結果になります。

低優先度のルールまで能動化する

マトリクスの右下（痛みも忘却頻度も低い）まで能動化すると、提案だらけで本来の作業が進みません。能動化は数枚に絞り、それ以外は受動のまま残す。Claude Code の proactive 化は、枚数を増やすゲームではなく、効くものだけを選ぶゲームです。

導入チェックリスト

能動ルールを Claude Code に1枚仕込む前に、次を確認しておくと実装がぶれません。

• 能動化する対象は「痛み × 忘却頻度」が高いものか（マトリクスで確認）
• rules/ に1ファイル1責務で置いたか（複数の能動化を1枚に混ぜていないか）
• トリガー条件はキーワード・ファイルパス・ツール名で検出可能な粒度か
• 提案フォーマットをコピペ可能なテンプレとして固定したか
• アンチパターンに「一度断られたら黙る」を入れたか
• 背景を1段落書いたか（半年後の見直し用）
• 再起動してトリガーに合う状況を作り、発火を確認したか

この7項目を満たした能動ルールなら、Claude Code は指示待ちから先回りへと挙動を変えます。

まとめ：proactive 化は rules ファイルの書き方で決まる

Claude Code の能動化は、才能でも特殊なプラグインでもなく、rules ファイルの書き方で決まります。

1. rules/ に1ファイル1責務で能動ルールを置く
2. トリガー条件を機械的に検出できる粒度まで具体化する
3. 提案フォーマットをコピペ可能なテンプレで固定する
4. アンチパターンに「一度断られたら黙る」を入れて暴走を防ぐ

考え方そのものは受動ルールを能動ルールに変える組織設計の発想で書きました。実装は、その4要素を Claude Code の rules に決まった骨格で落とすだけです。受動運用で眠っているルールがあるなら、まず「痛みも忘却頻度も高い1枚」から proactive 化してみてください。

AIエージェントのカスタマイズでお困りなら

「Claude Code を入れたのに、結局毎回細かく指示していて省力化になっていない」という相談はよくいただきます。どのルールを能動化すべきか、トリガーをどう書けば誤発火しないか、提案ノイズをどう抑えるか。この線引きは最初の設計で決まります。

f2t.jp では、Claude Code をはじめとする AI エージェントの能動化設計から、業務への定着まで一貫してお手伝いしています。自社のどの定例指示が能動化に向くか、どの粒度でトリガーを書くべきかを一緒に整理するところから始められます。お問い合わせフォームからご相談ください。