Rulesを全部捨てて認識をリセットした話（with Gemini 2.5 Pro）
2025年04月20日現在の話です。
毎度ですが、記事の賞味期限には気をつけてください。食あたり注意です。
Rulesを捨てた経緯
2025年3月末、Gemini 2.5 Pro が出ました。コンテキストウィンドウ1Mということでゲームチェンジャー感がありすぐ使い始めました。4/20日現在もほぼGemini1本と言っていいくらい使ってます。
別にこのタイミングである必要はなかったかもしれませんが、直近で感じてた疑念— 「LLMに辞書みたいなrulesを読み込ませるのは本当に正しいのか？」 を検証することにしました。（というか、正しくないことが半分分かっていたのでどっかで認識をリセットしなくてはと思っていました。）
元々以下のような記事を書いて逐次的なRulesの更新を推奨していました。
この頃は、将来的にモデルの性能向上でコンテキストウィンドウも拡大するから何でもツッコんで貯めとこうと思っていました。
しかし、割とすぐに当時のCursor+Sonnet3.7環境では問題が出ました。
というのも、rulesが増大して辞書みたいになってきた結果、コンテキスト長の都合で内容が抜け落ち始めました。
特に、（Rulesに限った話ではないですが）セッションが長引くと分かりやすく色々抜け落ちてきます。
さらに、運用も煩雑であるにも関わらずこの先いつまで使える代物かも分かりません
そこでちょうどいい見直しのタイミングだと感じ、思い切って 「全部捨てて、最小から作り直す」 ことにしました。
ほぼ直感的に始めました。Geminiでこれまでと別ゲームになるような気がしました。
この記事はその経緯と学びをまとめた覚え書きです。
rulesを捉え直す
Rulesは、LLM に「こう振る舞え」と教える設定ファイルです。
Rulesに記載する内容は整理すると、大まかに以下の３つの要素に分かれると思っています。
- 行動規範 — 禁則事項や使用言語など、振る舞いを縛る
- ナレッジ — プロジェクト固有の知識
- 手順 — 繰り返し行ってもらう作業の明文化
これらの分類はTeslaさんの記事に影響を受けています。（記事の内容と上記の分類は完全には合致してないかもしれません。）
それぞれのイメージ
| 要素 | 例 |
|---|---|
| 行動規範 | 「日本語で答えて」「不要なコメントは厳禁」 |
| ナレッジ | 「NextでApp Router使用」「Vercelにデプロイ」 |
| 手順 | 「〜〜のフォーマットで実装ログを残して」 |
以下、本題です。これらの用語（行動規範、ナレッジ、手順）を使います。
Gemini2.5Proで行ったrules再構築
やったこと
-
全面リセット —
.cursor/rules、.clinerules、.windsurfrulesなどを全削除 - 最小復元 — 「日本語で答えて」など、無いと困るものだけは引き継ぐ
- 調整 - ほぼ裸の状態で実戦投入し1から組み立て
環境
- レポジトリ: モノレポ
- スタック: TypeScript（Next、Nest）
- エージェント: メイン: Cline（Roo Code）、サブ: Cursor
- モデル: メイン:Gemini2.5Pro、サブ: Sonnet3.7（1割以下）、gpt4.1（数日のみ）
- プロジェクト規模：小〜中規模の既存システム
結論
- 行動規範と手順はモード毎に記載する
- ナレッジの記載は最低限でいい
- Rulesよりプロンプトで勝負
1つ目に関しては、個人的な予測です。間違っていたらすみません。
（AI時代、予測不可能なことが起きすぎるので多分間違っていると思います。）
以下、それぞれを説明していきます。
行動規範と手順はモード毎に記載する
モードとは、コード記述や実行、アーキテクチャ設計、技術的質問への回答など、特定の開発シナリオに最適化された異なるAIアシスタントの役割や動作パターンを切り替えられる機能のことです。
Rooのこれです。
Cursorだとこれ。
CursorとRooは自分でモードを追加可能です。
Windsurfでは、Chat/Writeの2種類のみで、Cline本家もPlan/Actの2種類（？）だと思います。
AIコーディングをやり出すと分かるのですが、特定の開発シナリオにはパターンがあり、その時々の状況でモデルに求める振る舞いが変わります。
特定の開発シナリオ：
- 実装計画の策定
- 実装
- デバッグ
- ただの質問
これはそれぞれRooのデフォルトのArchitect、Code、Debug、Askに該当します。
例えば、Architect（実装計画の策定）には以下のような内容がデフォルトで書かれています。（和訳）
あなたはRooです。
経験豊富な技術リーダーであり、探究心が強く、優れた計画立案者です。
あなたの目標は情報を収集し、コンテキストを把握して、ユーザーのタスクを達成するための詳細な計画を作成することです。
ユーザーはその計画を確認し承認してから、別のモードに切り替えてソリューションを実装します。
情報収集（例：read_fileやsearch_filesを使用）を行い、タスクに関するより多くのコンテキストを取得します。
ユーザーに明確化のための質問をして、タスクをより良く理解するよう努めます。
ユーザーの要求についてより多くのコンテキストを得たら、タスクを達成するための詳細な計画を作成します。計画を明確にするのに役立つ場合は、Mermaidダイアグラムを含めます。
ユーザーにこの計画に満足しているか、または変更を加えたいかを尋ねます。これはタスクについて議論し、それを達成する最良の方法を計画するブレインストーミングセッションと考えてください。
ユーザーが計画を確認したら、マークダウンファイルに書き込みたいかどうかを尋ねます。
switch_modeツールを使用して、ユーザーにソリューションを実装するための別のモードに切り替えるよう依頼します。
これまでは、各モードとその振る舞いを以下のように事細かにrulesに書いていました。
1. プロンプトの確認とモードの決定
まず、ユーザーから受け取った指示を確認します：
<指示>
{{instructions}}
</指示>
ユーザーの指示から今あなたに求められているタスクを把握してください。
タスクの性質によってあなたの行う作業モードが変わります：
1. 実装計画の立案→「実装計画立案モード」
2. 実際の実装や修正作業→「実装モード」
3. デバッグの実行→「デバッグモード」
- ユーザーからの指示をもとに作業モードが決まったら、**「~~~~~モードで作業を始めます！」と宣言して下さい。**
- 決まらなかったら「実装モード」にセットして下さい。
2. 指示作業の実行
【重要】「1. プロンプトの確認とモードの決定」で判断した自身のモードにより 以下の指示は読み分けてください。
### 「実装計画立案モード」の場合
作業前に必ず「実装計画立案モードで作業を開始します！」とユーザーに伝えて下さい。
#### 重要ルール（実装計画立案モード）// コレが行動規範です！
- git status で現在のgit のコンテキストを確認して下さい。
- 要求されている変更について深く考察し、既存のコードを分析して必要な変更の全範囲をマッピングしてください。
- 計画を提案する前に、1~2個の明確化質問をしてください。それでも不明確であればさらに質問をして下さい。
- 回答を得たら、包括的な行動計画を作成し、その計画の承認を求めてください。
- タスク実行のための具体的なステップを詳細に列挙してください。
- それらのステップの最適な実行順序を決定してください。
- 影響対象であるファイルをすべて列挙してください。
- ファイルの新規作成の場合はどのようなフォルダやファイルを作成するかを明確に伝えてください。
- また、ファイルの中の影響を受けるコードを全て理由付きで説明してください。
- 実装計画立案はタスク実行の最終的な結果を最大化する最重要ステップです。時間をかけてでも、十分に詳細かつ包括的な分析を行ってください。
- すべてのタスクが完了したら、実装計画を再評価してください。
- 当初の指示内容との整合性を確認し、必要に応じて調整を行ってください。
3. 結果報告 // コレが手順！
各々のモードによって定義された「結果報告フォーマット」に沿って返して下さい。
#### 「実装計画立案モード」の結果報告フォーマット
# 実装計画
## 概要
[実装内容の簡潔な説明]
## ファイル変更計画
- 新規: `[ファイルパス]` - [目的]
- 更新: `[ファイルパス]` - [変更内容]
- 削除: `[ファイルパス]` - [理由]
## 主要実装ステップ
1. - [x] Task1 // 既に終わっているTaskの場合
2. - [ ] Task2
3. - [ ] Task3
...
## 技術的考慮事項
- [重要な技術的ポイント]
- [潜在的な課題]
（以下、省略）
モードを使用してみて元々Rulesで定義していた行動規範と手順の大部分はモード毎の指示で済むことが分かりました。Rooのデフォルトのモード毎のカスタム指示が非常に優秀なのでこれをベースに改良しています。
個人的には、モード毎にrules（行動規範+手順）を指定することが主流になり、それに特化した管理方法が高度化していくんではないかと思っています。少なくとも自分にとっては、ストレスなく成果を最大化するという目的を考えると一番理にかなっている様に思えます。
初期は1つのチャットウィンドウでChat/Writeさえ分かれていなかったCursorも今や独自モードを作れるまで機能が進化していてRooでは独自のモードをコードで管理できるところまできています。
{
"customModes": [
{
"slug": "boomerang-mode",
"name": "Boomerang Mode",
"roleDefinition": "You are Roo, a strategic workflow orchestrator who coordinates complex tasks by delegating them to appropriate specialized modes. You have a comprehensive understanding of each mode's capabilities and limitations, allowing you to effectively break down complex problems into discrete tasks that can be solved by different specialists.",
"customInstructions": "Your role is to coordinate complex workflows by delegating tasks to specialized modes. As an orchestrator, you should:\n\n1. When given a complex task, break it down into logical subtasks that can be delegated to appropriate specialized modes.\n\n2. For each subtask, use the `new_task` tool to delegate. Choose the most appropriate mode for the subtask's specific goal and provide comprehensive instructions in the `message` parameter. These instructions must include:\n _ All necessary context from the parent task or previous subtasks required to complete the work.\n _ A clearly defined scope, specifying exactly what the subtask should accomplish.\n * An explicit statement that the subtask should *only* perform the work outlined in these instructions and not deviate.\n * An instruction for the subtask to signal completion by using the `attempt_completion` tool, providing a concise yet thorough summary of the outcome in the `result` parameter, keeping in mind that this summary will be the source of truth used to keep track of what was completed on this project. \n \* A statement that these specific instructions supersede any conflicting general instructions the subtask's mode might have.\n\n3. Track and manage the progress of all subtasks. When a subtask is completed, analyze its results and determine the next steps.\n\n4. Help the user understand how the different subtasks fit together in the overall workflow. Provide clear reasoning about why you're delegating specific tasks to specific modes.\n\n5. When all subtasks are completed, synthesize the results and provide a comprehensive overview of what was accomplished.\n\n6. Ask clarifying questions when necessary to better understand how to break down complex tasks effectively.\n\n7. Suggest improvements to the workflow based on the results of completed subtasks.\n\nUse subtasks to maintain clarity. If a request significantly shifts focus or requires a different expertise (mode), consider creating a subtask rather than overloading the current one.",
"groups": [],
"source": "global"
}
]
}
これからマルチエージェントの協調みたいな話が加速していくと、
モード毎に制約を課していくのが主流になると思われます。
もっというと、モードxモデルになると思います。
モデルが変わると記載しなきゃいけない内容は変わるため。
ナレッジの記載は最低限でいい
今後、コードを見て容易に判断できることは記載しなくて良いと思います。
以前は、
- Next15のApp Routerを使用
- OrvalでAPIクライアントを生成
- ~~/~~/api/index.tsの編集は厳禁
などとツラツラ書いていました。本当にメチャクチャたくさん追加していました。
特に２つ目は守ってもらえなくてずっと苦しめられてました。
消してみて驚きましたが、
GeminiはRulesなしでもコードベースからOrvalを使うことを勝手に読み取って正しく生成してくれました。
Clineがコードベースを網羅的に見た結果ではあると思うのでツール依存はある程度ありますが、コードベースからナレッジを勝手に読み取ってルールとして守れるくらいにモデル（賢さとコンテキスト長）が進化してきているということでありモデルの進化は加速していくはずです。
Rulesよりプロンプトを大事に
Geminiを使い始めて強く感じたのは、プロンプトを頑張る必要があるということです。
これはGeminiのモデル固有のキャラクターに由来する話です。
LLMにはモデル固有の癖があります。以下はSonnet3.7とGemini 2.5 Proの例です。
-
Sonnet 3.7 ― “お節介キャラ”で、頼んでいない箇所までよしなに変更を加えがち。
なので、以下のように明示して抑え込みます。依頼されたタスク"のみ"を実行せよ。未依頼のコード変更は厳禁。 -
Gemini 2.5 Pro ― きちんと依頼しないとやってくれない。作業ログコメントを大量出力。
後者の抑制で以下の行動規範を追加します。後続の技術者残す必要がある不要なコメントを残すことは厳禁。
悲しいかな、Geminiのコメント癖はrulesでは矯正できませんでした。
Gemini2.5を使っている中で以下の2点に気づきました。
- モデルに元来内蔵された行動規範をrulesで上書きできないことが多い
- rulesよりもプロンプトで都度守ってほしい制約を書いた方がいい結果になる
ということです。
上記2点はそれぞれ少し違う話ですが、結果としてrulesよりもプロンプトに注力する様になりました。
Sonnet3.7メイン利用の時もプロンプトはある程度はきちんと書いてましたが、それをもっと突き詰めてやるようになりました。
守ってほしい行動規範はプロンプトの末尾に以下のように追加します。mdファイルによく使うプロンプトを保存しておいて再利用しています。
デバッグ開始
follow this rule:
@000_debug.md
@012_neverComment.md
今後、どのような性格のモデルが出てくるかは分かりませんが、プロンプトはLLMに対して要望を最も効果的に伝えられる手段なのは間違いありません。
結論として、LLMの出力をコントロールするには、内部ルールを変更しようとするより明確で具体的なプロンプトを用意して行動規範、ナレッジ、手順もプロンプトで教えてあげる方が効果的なことを知りました。
結論（というか伝えたいこと?）
- モードを活用して用途に合わせた自作エージェントを作ってみてほしい
- Rulesはモード毎の管理になる気がしています
- プロンプトを頑張るのがおすすめ
- 自作プロンプト集をMDに保存して再利用するスタイルおすすめです
- ナレッジはほどほどに
- コードを読んでわかることは書かないでOK
- Rulesを捨ててみると新しい視点が得られます。サンクコストに泣きますが、既存の認識を捨てることもAI時代に必要なスキルの1つですね
最後に：Xのフォローお願いします！
一瞬で自分のスキルが陳腐化するサンクコストに泣きながらも最前線にいれるよう奮闘してます。自分の学びを日々発信しています。
ここ からどうぞ。
Discussion