操縦法の地図 — どれをいつ使うか

第6章ではここまで、スラッシュコマンド・Hooks・Skills・MCP・Subagents・settings.json・Worktrees・デバッグループと、Claude Code を操縦(ステアリング、＝振る舞いを目的に合わせて誘導すること)する手法を1つずつ深掘りしてきました。さらに直前の ch6-l9 で Rules・Output Styles・システムプロンプト追記の3つを足しました。

このレッスンはそれらの総まとめです。新しい機能は出てきません。代わりに「どの手法を、いつ使うか」を1枚の地図にします。これは原典ブログ「Steering Claude Code」の核心そのものです。深い使い方は各レッスンに譲るので、本文からどんどんリンクへ飛んでください。迷ったらこの地図に戻ってくる、という使い方を想定しています。

手法を選ぶには、まず4つの違いを見ます。どの手法も同じではなく、次の4点でクセが違います。

• いつ読み込まれるか: セッション開始時にずっと持つのか、ファイルに触れた時だけか、呼び出した時だけか。
• コンパクション(文脈圧縮)で消えるか: 会話が長くなると過去が要約・圧縮されます。その時に残るのか、回避(bypass)されるのか、消えてしまうのか。
• コスト: 常に文脈に居座る指示はトークン(AIが読む文字の単位)を食い続けます。必要な時だけ読まれる指示は安いです。
• 指示の強制力: 「お願い」レベルなのか、モデルの気分に関係なく決定論的(必ず同じ条件で発火する)に効くのか。

ここで大事な結論。何でも CLAUDE.md に書くのは悪手です。理由は2つあります。

1. CLAUDE.md はセッション中ずっと文脈に居座るので、書けば書くほどトークンを食い、肝心の作業の余地を圧迫します。だからルート CLAUDE.md は200行未満に保つのが推奨です(さらに、オーナー＝管理者を決めて、コードと同じようにレビューするのが良いとされています)。
2. CLAUDE.md はお願いであって強制ではない。「毎回必ずYせよ」「絶対するな」と書いても、モデルがその通り動く保証はありません。本当に止めたいなら別の仕組み(Hooks など)が要ります。

つまり「常に効かせたい/必要な時だけ効かせたい」「お願いでいい/絶対守らせたい」を切り分けて、目的に合う手法を選ぶのがこのレッスンの全てです。

ここが地図の本体です。原典ブログの比較表(列＝Method / When it's loaded / Compaction behavior / Context cost / When to use)を、CLAUDE.md のルート版・サブディレクトリ版を分けて8行で示します。

各行の深掘りは既存レッスンにあります。関連リンクをまとめておきます。

• スラッシュコマンド: /lesson/ch6-l1
• Hooks: /lesson/ch6-l2
• Skills: /lesson/ch6-l3
• MCP: /lesson/ch6-l4
• Subagents: /lesson/ch6-l5
• settings.json と Permissions: /lesson/ch6-l6
• Worktrees(並列開発): /lesson/ch6-l7
• デバッグループ実践: /lesson/ch6-l8
• Rules / Output Styles / システムプロンプト追記: /lesson/ch6-l9

表の読み方のコツ。「高コスト」の2つ(ルート CLAUDE.md と Output Styles)は常に文脈に居座るので、ここに何でも詰めるとすぐ重くなります。逆に Skills・Subagents・Hooks は「必要な時だけ」なので安く、強い武器です。

デュアルユース能力とは、有益にも有害にも使える知識・技術のことです。 たとえば高度な 生物学 や サイバーセキュリティ の知識は、研究や防御に役立つ一方で、悪用のリスクも伴います。

• Fable 5: モデルが極めて高性能になったため、安全クラシファイア (分類器) がリクエストを監視し、研究レベルの生物学や大半のサイバーセキュリティ関連の依頼を 拒否 (refusal) することがあります。これが「追加の安全対策」の中身です。
• Mythos 5: セキュリティ研究やライフサイエンスなど、正当な目的でその能力を必要とする審査済みの組織だけ に、追加対策なしで提供されます。招待制だった Claude Mythos Preview の後継にあたります。

💡 ch1-l4 で学んだ AI Safety の実践例です。「能力が上がるほど、提供の仕方に段階を設ける」——最前線モデルの安全運用の現在形と言えます。 詳細は公式発表 https://www.anthropic.com/news/claude-fable-5-mythos-5 を参照してください。

原典ブログがはっきり警告している「CLAUDE.md の誤用」と、その直し方です。ここが一番実戦的です。

NG1: 「Xしたら毎回必ずYせよ」を CLAUDE.md に書く

CLAUDE.md はお願いなので、毎回確実には実行されません。「毎回必ず」は決定論的な仕組みの仕事です。

• 正しい置き換え → Hooks。編集後に linter を走らせる、といった自動化は Hooks が決定論的に発火します。詳しくは Hooks の回。

wzxhzdk:0

NG2: 「絶対にこれをするな」を CLAUDE.md に書く

「絶対するな」は CLAUDE.md では本当のガードレールになりません。守られない時があります。

• 正しい置き換え → ブロック機能付きの Hooks(PreToolUse フックは exit code 2 で拒否=deny できる)か、managed settings(管理ポリシー設定)。組織として禁止したいなら後者。

wzxhzdk:0

NG3: 30行の手順を CLAUDE.md に書く

長い手順を CLAUDE.md に置くと、毎セッション常に読み込まれてトークンを浪費します。

• 正しい置き換え → Skills。本体(SKILL.md の全文)は呼び出した時だけ読み込まれます。開始時は「名前と説明」だけ。デプロイ手順やリリースチェックリストはこれが最適。詳しくは Skills の回。

NG4: paths の無い「API 専用ルール」

Rules に paths を付けないと、API と無関係なファイルを触っている時も常にトークンを食います。

• 正しい置き換え → paths フィールドでスコープする。対象パスを書けば、そのファイルに触れた時だけ効きます。

wzxhzdk:1

迷ったら上から順に当てはめてください。これがこの地図の「結論」です。

• プロジェクト全体の規約・概要(ビルドコマンド、ディレクトリ構成、チームの慣習)→ ルート CLAUDE.md(ただし200行未満に保つ)
• 特定ディレクトリだけのルール(例: app/api/ 配下の決まり)→ サブディレクトリ CLAUDE.md(そこに触れた時だけ読まれる)
• 特定ファイル群への制約(例: API ハンドラは入力検証、マイグレーションは追記のみ)→ Rules(必ず paths でスコープ)
• 手順・チェックリスト(デプロイ、リリース、レビューの段取り)→ Skills
• 隔離したい大きな脇道タスク(深い検索、ログ解析、依存関係監査)→ Subagents(専用の新しいコンテキストで動き、最終メッセージだけ戻る。最大5階層までネスト可)
• 「毎回必ず」「絶対するな」＝決定論的に強制したい→ Hooks(ブロックは PreToolUse + exit 2、または managed settings)
• 役割そのものを大きく変えたい→ Output Styles(ただし既定の指示が置き換えられて外れるので慎重に。残したいなら frontmatter に keep-coding-instructions: true)
• 起動時に標準・フォーマットを足したいだけ(役割は変えない)→ --append-system-prompt(元のシステムプロンプトに足すだけ。キャッシュで初回以降は安い)

補足: チームでこれらの設定を共有したい時は plugins(プラグイン) でまとめて配布できる、と原典ブログは触れています。

新しい手法を覚える必要はもうありません。覚えるべきは選び方です。

• 4つの軸(読み込みタイミング / コンパクション / コスト / 強制力)で見れば、どの手法も役割が決まる。
• 「全部 CLAUDE.md」は重くて弱い。お願いでいいなら CLAUDE.md、絶対守らせたいなら Hooks、長い手順は Skills、ファイル単位の制約は Rules(paths)。
• 実際の構築の細部は各レッスン(ch6-l1〜ch6-l9)へ。

次に自分のリポジトリで「これ、どこに書こう?」と迷ったら、上の決定の早見をもう一度なぞってください。それがこのレッスンの使い方です。

あなた(または架空)のリポジトリにある3つの要求を、根拠つきで最適な手法に割り当てる演習です。観察ポイント: Claude が単に手法名を挙げるだけでなく、「いつ読み込まれるか / コンパクションで消えるか / コスト / 強制力」という4つの判断軸のどれを根拠にしているかを確認してください。特に『毎回必ず』系が Hooks に、『長い手順』が Skills に、『ファイル群の制約』が paths 付き Rules に向く理由を説明できているかが鍵です。

わざと『何でも CLAUDE.md に詰め込んだ』設定を Claude に見せて、ブログの警告に沿ってリファクタしてもらう演習です。観察ポイント: 『絶対するな』がブロック Hooks か managed settings に、『毎回必ず』が Hooks に、長い手順が Skills に、API 専用ルールが paths 付き Rules に振り分けられるか。CLAUDE.md に残すべきもの(プロジェクト概要・規約)と、外に出すべきものの線引きができているかを見ます。