Claude Codeのルール・エージェント設計とは、何を恒久的なルールとして固定し、何を誰（サブエージェント）に委譲するかの線引きを決める作業です。「書き方」よりも、この設計判断と運用ルールこそが、AIに安定して仕事を任せられるかどうかを分けます。
公式ドキュメントやコマンド一覧を読めば「構文」はすぐ分かります。ところが実際に運用を始めると、ルールが肥大化して効かなくなったり、サブエージェントに丸投げして失敗したりと、「書けるのに、まわらない」状態に陥りがちです。原因の多くは、設計の話と運用の話を分けずに進めてしまうことにあります。すでにClaude Codeを触っていて、設定ファイルやサブエージェントの「書き方」は分かるのに運用が安定しない——そんな段階の人に向けた内容です。
この記事は、Claude Codeを実運用してきた経験から、ルールとエージェントを「どう設計し、どう運用するか」に絞って解説します。個々の作り方・構文はClaude Code上級編（MCP・Hooks・Skills・サブエージェント実践ガイド）に、コマンドやCLIの一覧はClaude Codeコマンド一覧＆実践ガイドに譲り、ここでは設計判断・委譲の境界線・実運用で踏むアンチパターンに集中します。
Claude Codeの「ルール」と「エージェント」は4層に分かれる
設計を始める前に、まず「どこに何を書けるか」を層として整理します。Claude Codeに対する指示は、大きく4つの層に分かれます。上の層ほど適用範囲が広く、下の層ほど特定の文脈に効きます。
| 層 | 何を書くか | 適用範囲 |
|---|---|---|
| ① グローバル設定（ユーザー単位） | 全プロジェクト共通の方針・好み・作業フロー | すべてのプロジェクト |
| ② プロジェクト設定（リポ単位） | そのリポジトリ固有のルール・禁止事項 | 1プロジェクト |
| ③ ルールファイル（参照読み込み） | 粒度の細かい規約（コーディング規約・書式など） | 読み込まれた範囲 |
| ④ エージェント／サブエージェント定義 | 特定の役割に特化した専用の指示 | そのエージェント実行中のみ |
ここで設計上もっとも重要な前提があります。これらのルールは「強制」ではなく、文脈（コンテキスト）に注入される指示だということです。Anthropicの公式ドキュメントでも、設定ファイルの内容はモデルが参照するメモリとして読み込まれる仕組みだと説明されています（出典: Anthropic公式 Claude Code Memory ドキュメント）。つまりルールは「必ず守らせる制約」ではなく「強く読ませるお願い」です。優先順位は、より具体的・より近い文脈のものが効きやすく、矛盾する指示があれば狭いスコープが勝ちます。
こうした「設定をどう読み込み、いつ何を実行するか」を司っているのが、Claude Code本体（ハーネス＝AIモデルを動かす実行基盤）です。ルールが強制ではなく注入になるのも、後述するサブエージェントのコンテキストが隔離されるのも、このハーネスの挙動に由来します。本記事ではハーネスの挙動を「設計判断の根拠」として必要な範囲だけ触れ、コンテキスト管理やループといった仕組みそのものの詳細は別記事に譲ります。
具体例で言うと、グローバルに「コメントは日本語」と書き、あるプロジェクトだけ「英語で統一」と書いた場合、そのプロジェクトでは後者（狭いスコープ）が優先されます。この上書きを意図して使えば、共通方針はグローバルに置きつつ、例外だけプロジェクト側で塗り替える、という整理ができます。逆に言えば、同じ強さのルールを複数の層にばらまくと、どれが効いているか追えなくなります。
この「注入であって強制ではない」という性質が、後述するアンチパターンと設計判断のすべての起点になります。絶対に外せない制約（危険なコマンドのブロックなど）は、ルール文ではなくHook（フック）で決定論的に止める——この切り分けが設計の出発点です。
グローバル vs プロジェクトルールの使い分け設計
同じ「ルールを書く」でも、グローバル（全プロジェクト共通）とプロジェクト（リポ固有）のどちらに置くかで、運用の安定性が大きく変わります。判断軸は「適用範囲」と「変更頻度」の2つです。
| 判断軸 | グローバルに置く | プロジェクトに置く |
|---|---|---|
| 適用範囲 | 全プロジェクトで一貫させたい | このリポだけに効かせたい |
| 変更頻度 | めったに変えない安定した方針 | 機能追加・構成変更で変わる |
| 具体例 | コメント言語・命名規約・作業の進め方 | デプロイ手順・ディレクトリ構成・固有の禁止事項 |
| 肥大化リスク | 大（全プロジェクトに効くので盛りがち） | 中（リポ固有なので範囲が限定される） |
設計の原則はシンプルです。「どのプロジェクトでも同じであってほしい」ものだけをグローバルに置き、それ以外はプロジェクト側に置く。迷ったらプロジェクト側に置きます。グローバルは全プロジェクトのコンテキストを毎回消費するため、ここが膨らむと「常に読まされる長文」が増えて、肝心のルールがノイズに埋もれます。
迷ったときの振り分けを、いくつか具体例で示します。判断軸は「全プロジェクトで同じか」「リポ固有の事実・禁止事項か」のどちらに寄るかです。
- 「コミットメッセージは日本語で書く」→ グローバル（どのプロジェクトでも変えたくない方針）
- 「このリポはpushで本番に自動デプロイされる」→ プロジェクト（リポ固有の事実・事故防止）
- 「最小フォントサイズは16pxで統一する」→ グローバル（全制作物で一貫させたい規約）
- 「特定フォルダ直下は手動管理なので触らない」→ プロジェクト（構成依存の禁止事項）
- 「方針提示と実行は分け、承認を取ってから動く」→ グローバル（働き方そのものの原則）
抽象化した例で示すと、グローバル側は次のように「方針の核」だけに絞るのが運用しやすい形です（実在の設定ではなく説明用の骨組みです）。
# グローバル設定（例）
## 言語・スタイル
- コメントとコミットメッセージは日本語
- 変数名・関数名は英語
## 作業の進め方
- 方針提示と実行は分ける（実行前に承認を取る）
- 単純な作業はメインで直接行い、判断不要な定型のみ委譲する
## 参照する詳細ルール
- コーディング規約は別ファイルに分離して参照する細かい規約（書式の細部、命名の例外など）はグローバル本体に書き込まず、別のルールファイルに分けて参照させます。本体を「索引」、詳細を「別冊」にする発想です。設定ファイルの分割や参照の具体的な書き方はClaude Code上級編で解説しています。
エージェントの役割分担をどう設計するか
サブエージェントを使うと、特定の役割に特化したAIアシスタントを用意できます。ここで「会社の組織図」をイメージすると設計しやすくなります——ただしこれはあくまで考えるための補助線です。実際のClaude Codeに「上司・部下」や「ルーター」という機構は存在せず、メインのモデルが必要に応じてサブエージェントを呼び出しているだけ、という点は誤解しないでください。組織図はあくまで「役割を言葉にするための道具」であり、その通りに機構が動くわけではない、と割り切って使うのが安全です。
それでも組織モデルが役立つのは、「この作業は誰の仕事か」を考える癖がつくからです。役割を決めずにサブエージェントを使うと、何でも屋を量産して管理しきれなくなります。先に「どんな役割が必要か」を数個だけ言語化し、その役割に対してエージェントを用意する——この順番を守るだけで、設計はかなり整理されます。
補助線としての組織モデルは、役割を言語化するのに役立ちます。たとえば次のような分担です（役割名は説明用の仮称です）。
- 司令塔（メイン）：依頼の解釈・タスク分解・成果物の統合と最終判断を担う。委譲するかどうかもここが決める
- 探索担当：コードの場所特定や横断検索など、結論だけ持ち帰ればよい調査を担う
- レビュー担当：品質・セキュリティなど決まった観点でのチェックを担う
- 定型実装担当：判断を伴わない定型コード生成など、手順が明確な作業を担う
設計の勘所は、役割を「成果物の種類」で切ることです。「フロントエンド担当」のように技術領域で切ると守備範囲が曖昧になりがちですが、「探索して場所を返す」「決まった観点でレビューする」のように入力と出力が明確な単位で切ると、何を任せ・何が返ってくるかがはっきりします。これは次のセクションの「委譲の境界線」と直結します。
もう一つの勘所は粒度です。役割を細かく刻みすぎると、「どのエージェントを呼ぶか」の判断そのものがコストになり、結局メインで全部やった方が速い、という事態になります。最初は「探索」「レビュー」のような数個の大きな役割から始め、同じ依頼を繰り返し手作業で振り分けていると気づいたときに、その分だけを切り出すのが現実的です。エージェントは増やすより「減らせないか」を先に疑うくらいで、ちょうどよい塩梅になります。
サブエージェント委譲の境界線：何を任せ、何を任せないか
委譲の設計を誤らないために、まずサブエージェントの「動き方」を正確に押さえます。Anthropicの公式ドキュメントによれば、サブエージェントは独立したコンテキストウィンドウで動作し、親に返るのは最終的な結果のみです（出典: Anthropic公式 Subagents ドキュメント）。つまり委譲とは「部下に継続的に仕事を頼む」ことではなく、文脈を切り離して一度だけ結果を受け取る仕組みです。
この性質から、委譲して得をする作業と、損をする作業が決まります。
| 委譲に向く作業 | 委譲に向かない作業 |
|---|---|
| 横断的な探索・調査（結論だけ持ち帰ればよい） | 設計判断（やり取りの文脈が判断に必要） |
| 独立した複数タスクの並列処理 | 複雑なバグ修正（試行錯誤の履歴が効く） |
| 判断を伴わない定型生成 | 会話の前後関係を跨ぐ作業 |
| 決まった観点での検証・レビュー | 「だいたいの方針」しか渡せない曖昧な作業 |
判断基準を一文にすると、「最終結果だけ受け取れば十分で、途中の文脈が切れても困らない作業」だけを委譲する、です。逆に、判断の質がそれまでのやり取りに依存する作業は、文脈が切り離された瞬間に精度が落ちます。設計判断や難しいデバッグをメインに残すのは、能力の問題ではなくコンテキストの連続性が必要だからです。
委譲が最も効くのは、独立した複数の調査を同時に走らせるときです。コンテキストが隔離されることは弱点であると同時に強みでもあり、互いに干渉しない作業を並行させれば、待ち時間を大きく圧縮できます。「結果だけ要る・互いに独立している」という条件がそろう作業ほど、委譲の費用対効果は高くなります。逆にこの条件を満たさない作業を無理に分割すると、調整コストが増えるだけで遅くなります。
そして委譲すると決めたら、渡す指示には次の4点を必ず含めます。これが欠けると、隔離された相手は判断材料を持たないまま「だいたい完成」で戻ってきます。
- 完了条件：触るべきファイル名・通すべきコマンドを具体的に列挙する
- 検証方法：型チェック・ビルド・テストの実行と、結果の報告を求める
- 禁止事項：「だいたい完成での終了」「エラーの独断無視」を禁じる
- 最終報告フォーマット：変更ファイル一覧＋検証ログの形で返させる
この4点は、人に仕事を頼むときの「指示書」とまったく同じです。相手がAIだから特別な作法が要るのではなく、文脈を共有していない相手に過不足なく伝えるという当たり前が、そのまま効きます。逆に言えば、自分が口頭で説明できないほど曖昧な依頼は、サブエージェントにもうまく渡せません。委譲がうまくいかないときは、エージェントの能力を疑う前に、自分の指示が4点を満たしているかを見直すのが先決です。
実運用で踏むアンチパターン5選と対策
ここからが本題です。設計の理屈を知っていても、運用を始めると同じ失敗を踏みます。実際に手を動かして見えてきた、再現性の高いアンチパターンを5つに絞って紹介します。
共通して言えるのは、どれも「悪意なく」踏むということです。むしろ真面目にルールを整え、積極的に委譲しようとする人ほどはまります。だからこそ、起きてから直すのではなく、設計の段階で「こうなりやすい」と知っておくことが効きます。
アンチパターン1：ルールの肥大化
「念のため」と書き足すうちにルールが数百行に膨らみ、結果としてどれも守られなくなる状態です。ルールは注入されるコンテキストなので、量が増えるほど一つひとつの重みは薄まります。対策：本体は原則だけに絞り、詳細は別ファイルへ。そして「絶対に守らせたい制約」はルール文ではなくHookに移す。お願いと強制を混ぜないことが要です。
アンチパターン2：「方針提示」を「実行許可」と取り違える
「こう進めます」という提示を、そのまま実行してよい合図だと解釈してしまうケースです。広範囲の変更や外部への発信で起きると、取り返しがつきにくくなります。対策：「範囲・内容を提示し、承認を得てから実行する」を運用ルールとして明文化する。承認ゲートを設計に組み込むことで、暴走を構造的に防ぎます。
アンチパターン3：サブエージェントの乱発
「専門エージェントに任せた方が良さそう」と、単純な作業まで次々と委譲してしまうパターンです。文脈が切り離されるぶん、かえって指示の手間と精度低下を招きます。対策：委譲は「判断不要な定型」と「結論だけ要る調査」に限定し、判断を伴う作業はメインで直接行う。前セクションの委譲表を判断基準にします。
アンチパターン4：ルールを「強制」だと思い込む
「禁止と書いたのに実行された」と戸惑うケースの多くは、ルールを強制力のある設定だと誤解していることが原因です。前述のとおりルールは注入されるお願いであり、確実な強制ではありません。対策：本当に止めたい操作（危険なコマンド、特定ファイルの書き換えなど）はHookで決定論的にブロックする。Hookの仕組みと書き方はClaude Code上級編を参照してください。
アンチパターン5：委譲時の指示不足
「このバグ直しておいて」と曖昧に委譲し、完了条件も検証方法も渡さないパターンです。隔離された相手は判断材料を持たないため、「動いたつもり」で戻ってきます。対策：完了条件・検証コマンド・禁止事項・最終報告フォーマットの4点をセットで渡す。委譲の質は、渡す指示の具体性でほぼ決まります。
これらのアンチパターンに共通するのは、「独学だと運用の勘所で手が止まる」という点です。設計判断や委譲の境界線は、ドキュメントを読むだけでは身につきにくく、実際の画面を一緒に見ながら相談できると一気に解像度が上がります。
運用の”詰まりどころ”は、月1回のビデオ通話で直接相談できます。独学でAI開発やサイト運用を進めると、設計判断や運用ルールの勘所で手が止まりがちです。CodeQuest.work SEO のプロプラン（¥9,800/月・人数限定）なら、月1回のオンライン相談付き。AI開発・Claude Code活用からSEO・サイト運用まで、学習から実運用まで画面を一緒に見ながら相談できます。
設計が効いているかを検証する
ルールやエージェントの設計を「書いて終わり」にしないことが、運用を安定させる最後のピースです。ルールは注入される指示なので、本当に反映されたのかは出力を見るまで分かりません。だからこそ、効いているかを確かめる仕組みまで含めて設計します。検証は大げさなものではなく、次の3つで十分です。
- 生成物を機械的に点検する：「この書式で出す」と決めたなら、生成後にgrepなどで実際にその書式になっているかを確認する。ルールを読ませるだけでなく、出力側で答え合わせをする
- 強制したルールは発火を確認する：Hookで止める設計にした項目は、実際にフックが発火しているかをログで確かめる。「書いたつもりで効いていない」を防ぐ
- 委譲結果は検証コマンド付きで受け取る：サブエージェントには型チェック・テストの実行と結果報告を求め、ログで成否を確かめてから取り込む
そして検証で漏れが見つかったとき、正しい反応は「ルール文を足すこと」ではありません。「絶対に守らせたいならHookへ」「頻出するミスなら生成後の自己点検ルールへ」と振り分けます。ルールを増やすのではなく、強制と点検の層に逃がす——これがアンチパターン1（肥大化）を防ぎながら精度を上げる、運用の次の一手です。設計・委譲・検証をひとつのループとして回せるようになると、AIに任せられる仕事の範囲が安定して広がっていきます。
よくある質問
Q. ルールに書けば、Claude Codeは必ずそのとおりに従いますか？
いいえ。ルールは強制力のある設定ではなく、文脈に注入されて「強く読まれる指示」です。多くの場合は従いますが、長文に埋もれたり、ほかの指示と矛盾したりすると守られないこともあります。確実に守らせたい制約（危険なコマンドの禁止など）は、ルール文ではなくHookで決定論的にブロックするのが正しい設計です。
Q. ルールはグローバルとプロジェクト、どちらに書くべきですか？
「どのプロジェクトでも同じであってほしい方針」だけをグローバルに置き、それ以外はプロジェクト側に置きます。迷ったらプロジェクト側です。グローバルは毎回コンテキストを消費するため、ここを膨らませると重要なルールがノイズに埋もれます。
Q. どんな作業をサブエージェントに任せ、どんな作業は任せないべきですか？
「最終結果だけ受け取れば十分で、途中の文脈が切れても困らない作業」を任せます。横断的な探索、並列処理、判断を伴わない定型生成、決まった観点のレビューが向きます。逆に、設計判断や複雑なバグ修正など、判断の質がやり取りの文脈に依存する作業はメインに残します。
Q. ルールファイルが増えてきました。どう整理すれば運用が破綻しませんか？
本体を「索引」、詳細を「別冊」にする発想で分割します。設定本体には原則と参照先だけを書き、細かい規約は別ファイルへ切り出して必要なときだけ読み込ませます。さらに、絶対に守らせたい項目はHookへ移すことで、ルール文の量そのものを減らせます。
Q. ルールやエージェントの作り方を、構文レベルで詳しく知りたい場合は？
本記事は「設計・運用」に絞っているため、設定ファイルの記法・サブエージェントの定義方法・Hookの構文といった作り方は、Claude Code上級編にまとめています。コマンドやCLIオプションはClaude Codeコマンド一覧＆実践ガイドを参照してください。
まとめ：作り方より「設計と運用」が差を生む
Claude Codeのルールとエージェントは、構文を覚えれば書けます。しかし安定して仕事を任せられるかは、何を固定し・何を誰に委譲するかの設計と、運用で踏むアンチパターンを避ける判断で決まります。ルールは強制ではなく注入であること、サブエージェントは文脈を切り離して結果だけ返すこと——どちらもハーネス（Claude Code本体）の挙動に由来するこの2つの性質を起点に設計すれば、「書けるのに、まわらない」状態から抜け出せます。
最初から完璧な設計を目指す必要はありません。グローバルとプロジェクトの線引きを意識し、判断不要な作業だけを委譲し、効いているかを点検する——この小さなループを回しながら、自分の運用に合う形へ少しずつ育てていくのが、結局いちばんの近道です。
設計判断や委譲の境界線でつまずいたときは、独学で抱え込まず相談するのが近道です。CodeQuest.work SEO のプロプラン（¥9,800/月・人数限定）は、月1回のビデオ通話でAI開発・サイト運用の学習から実運用までを直接相談できます。
