〜初学者がAIを使って、AIの使い方を改善した記録〜
きっかけ
ある日、Anthropicが公式ブログで記事を出した。
タイトルは "Steering Claude Code: Skills, Hooks, Rules, Subagents, and More"。
どうやらClaude Codeには指示を渡す方法が7種類あるらしいですわよ奥さん。
私がClaude Codeに渡している指示といえば、~/.claude/CLAUDE.md に書いた数十行だけ。それ以外の方法があるとは、正直あまり意識していなかった。
「もしかして、あーしの環境って結構雑なんじゃね？」
そう思ってClaudeに「この記事、深掘りして教えてクレメンス」と頼んだのが、この一連の作業の始まり。
「あーしは、何使ってるの？」 現状確認してみた
記事を要約して、役割を見やすくしたものがこれでち
| 方法 | 役割 |
|---|---|
| CLAUDE.md | 常時読み込まれるプロジェクトの文脈 |
| Rules | 制約・規約（パス指定で条件読み込み可能） |
| Skills | 手順書（呼び出し時だけ読み込まれる） |
| Subagents | 独立したエージェント（並列タスク向け） |
| Hooks | ライフサイクルイベントで動くシェルスクリプト |
| Output styles | Claudeの応答スタイルそのものを変える |
| --append-system-prompt | CLI起動時にシステムプロンプトに追記する |
「Rules？ なにそれ。」
そう思って ~/.claude/ を確認してみたら、rules/ ディレクトリがちゃんと存在した。
~/.claude/rules/
├── education-mode.md
└── sre-learning.md
え、あった。しかも2個も。
自分で設定したはずなのに、すっかり存在を忘れていた。中身を読んでみると、教育モードの指示やSRE学習の観点が書いてある。
「てか、文量少なくて草」
「pathsなしのRulesはCLAUDE.mdと同じ」 とかマ？
記事にはRulesについてこう書いてあった。
"An unscoped rule is mechanically identical to putting the content in CLAUDE.md: always loaded, always costing tokens."
（パス指定なしのRulesは、CLAUDE.mdに書くのと機械的に同じだ）
私のRulesには paths: という指定が一切なかった。
つまり、TypeScriptのコンポーネントを書いているときも、GoのAPIを実装しているときも、SRE学習の観点ルールがずっとコンテキストに読み込まれていた。
無関係な場面でもトークンを食い続けていた。
Rulesの本当の価値は、このパス指定にある。
---
paths:
- "src/api/**"
- "**/*.handler.ts"
---
このルールはAPIファイルを触った時だけ読み込まれる
こう書くと、APIファイルを触った時だけ読み込まれる。ドキュメントを書いているときは無視される。コンテキストを無駄に使わない設計だ。
この paths: 記法、最初はブログ記事から取ってきた書き方だったので「公式に載ってるの？」と不安になった。
調べてみるとcode.claude.com/docs/en/memory の「Path-specific rules」セクションにちゃんと記載があった。
公式ドキュメントで確認済みの書き方。
さらに、ブレース展開も使えると分かった
（正直ブレース展開とか使ったことないし、そんなのあったなレベル私を許して）
---
paths:
- "**/*.{ts,tsx}"
---
**/*.ts と **/*.tsx を別々に書く必要がない。
実際にRulesを強化した
ADHDかつASDのあーしは、スーパーヤクの毛刈りマンなので、すぐに強化。
既存ファイルの改善：sre-learning.md ←私のSRE AI メンター
インフラ・Go系のファイルを触った時だけ読み込まれるよう、pathsを追加した。
---
paths:
- "**/*.go"
- "**/amplify/**"
- "**/sst.config.ts"
- "**/*.{yaml,yml,tf}"
---
# SRE学習コンテキスト
...
これでReactコンポーネントなどを書いているときはSRE観点のルールが静かにしていてくれる。
新規作成：typescript.md
TypeScript / Next.js固有のルールがゼロだったので作った。
---
paths:
- "**/*.{ts,tsx}"
- "**/tsconfig.json"
---
# TypeScript / Next.js ルール
- `any` 型は使わない。型が不明な場合は `unknown` を使って絞り込む
- Next.js App Router を使う（`app/` ディレクトリ）
- `"use client"` は必要最小限に
- 環境変数は `amplify_outputs.json` 経由で取得する
新規作成：aws.md
AWS設計でやりがちな請求トラップとアーキテクチャの地雷を書いておいた。
SNSで先人たちが、私たち新米に数十万と身を削って教えてくれているあの恐怖、これでもかというハーネス、安全装置はあればあるほどいいからね（※バランス大事）
---
paths:
- "**/amplify/**"
- "**/sst.config.ts"
- "**/*.{yaml,yml,tf}"
---
# AWS 設計ルール
## 請求トラップ
- NAT Gatewayは原則使わない（GB課金＋時間課金）
- CloudWatch Logsの保持期間を必ず設定する
...
AWSが何もわからんちの民と自覚しているので、AWSのRulesを設計するにあたって、Amazon BedrockとAgentCoreのページを参考にした。
前提として守りたかったのは、直接Bedrock固有のルールを書きたかったわけではなく
「AWSがAI時代にどういう設計思想をもっていらっしゃるんやろ」
を読み解いて、AIの動き方、初学者が踏みやすい地雷を整理したいという黄金の意志。
Bedrockのページからは、こういう哲学が見えてきた（哲学ってなんかかっけえね❤️🔥）
- マネージドサービス優先（責任をAWSに委譲する）
- コストは構造で制御する（後から節約するのではなく、設計で決める）
- 観測できないものは制御できない（CloudWatch統合が前提だし、o11y大事って話）
これはBedrockに限らず、AWS全体のアーキテクチャ哲学だだった。
Cloud Practitionerで体系的に学べる内容でもあるので、ちゃんと勉強しましょうておもた。
「僕最強だから」 > Output styles 〜最強を語る人外魔境編〜
記事を深掘りしていくと、Output styles という機能が出てきた。
これは ~/.claude/output-styles/ にMarkdownファイルを置くと、Claudeの応答スタイルそのものを変えられる機能だ。システムプロンプトに直接注入されて、セッション中は絶対に消えない。
Output stylesはデフォルトでは存在しない。自分で作らない限り何も起きない。CLAUDE.mdやRulesと違って、最初からファイルがあるわけではないので注意。
カスタムスタイルを作る時に一つ罠がある。デフォルトのコーディング指示（スコープの判断・コメントの書き方・検証の習慣など）が丸ごと消える。
コーディング用途で使い続けたい場合はフロントマターに
keep-coding-instructions: true を書く必要がある。
---
name: my-style
keep-coding-instructions: true
---
書かない場合（デフォルト false）は、ClaudeCode固有のSWE指示が消えてしまう。
「じゃ あーしの教育モードをここに移せばいいんじゃね？」
education-mode.md という、私のAI家庭教師で指導を基本的な振る舞いにしてくれてるものがあるのだが🧑🏫
- 「重要ポイントでは手を動かしてもらう」
- 「エラー時に正解を先に教えない」
といったような内容が書いてある。これはファイルタイプと関係ない全セッション共通の話なので、確かにOutput styleっぽい。
移そうとしたところで、ひとつ疑問が浮かんだ。
「ペアプロとかバイブコーディングをする時に、教育モードが邪魔になる時あるくね？」
ドライバーになってガンガン実装を進めたい場面で、「まず自分でやってみてください」と言われたら困る。
さて、どうしよ
Output Styleの可能性を探るZE⭐️
Output stylesの特性を確認してみると、分かったことがある。
セッション中は会話で変更できない。切り替えるには設定ファイルを書き換えてから /clear かセッション再起動が必要。
これはまじい！
教育モードをOutput styleに入れると、バイブコーディング中に「今日は説明不要、どんどん実装して」と言っても完全には切れない。/clear するとコンテキストが全部消える。
一方、Rulesは「中程度の権威」なので、会話の流れで上書きできる。
「今日はバイブコーディングモードで。説明不要、どんどん実装して」
→ ClaudeはRulesより会話の指示を優先できるらしいので、これができる
結論
Output stylesは「絶対に変えたくないもの」だけに使うべき。
Rulesはシーンによって「切り替えたい設定」がある場合に使うべき。
❤️ なので自分で作った"教育モード"は、Rulesに導入しました！
番外編：Output stylesが本領を発揮する場所を見つけたンゴ
「でもこの強制力は武器だよなぁ、使いたいなぁ」という謎の盛り上がりを見せた我が心。
自分の環境を見回してみたら、ドンピシャな使いどころが見つかった。
Claude Codeをメンターとして活用する学習システム（命名: Study OS）を構築したのだが、その中に「メンターエージェント」があって、下記の応答ルールをCLAUDE.mdに書いていた。
・ 一度に1つのことだけ教える
・ 「なぜそうなるか」を必ず一文で添える
・ 長い説明より短い問いかけを優先する etc.
「超限定的なムーブをしてほしいエージェントにこそ、Output Styleでは？？？」
しかも学習セッションって長くなりがちだけど、コンテキスト圧縮が起きても、メンターの応答スタイルは絶対に消えてほしくないというわがままっこな希望がある。
CLAUDE.mdに書いていた時はそこが不安で、実際不安定だったのだが。
Output styleはシステムプロンプトに直接注入されるので、圧縮されない。
欲しかったやつやーん。
---
name: mentor
description: Toriumiの学習メンターとしての応答スタイル
---
- 一度に1つのことだけ教える（ADHDに配慮）
- 「なぜそうなるか（仕組み）」を必ず一文で添える
- 長い説明より短い問いかけを優先する
{
"outputStyle": "mentor"
}
このディレクトリで起動した時だけ適用され、他のプロジェクトには一切影響しない。
「権威が強い＝使いづらい」と思っていたけど、「絶対に切り替えたくないもの」ならむしろ権威が高い方がいい、という気づきでした。
Study OSについては別途まとめた記事を書く予定なので、興味ある方はお待ちいただけると嬉しいです！
こっちはこっちで初学者には楽しいと思うので是非に😘
余談：settings.local.json について少し
「Output Style強すぎて使いにくすぎるやろ！サトシのリザードンか！え？ケッキング？」
と思っていたのだが、ドンピシャな使い方が判明した上記のものだが、その中で重要なのが .claude/settings.local.json の存在。
| 設定ファイル | スコープ | gitへのコミット |
|---|---|---|
~/.claude/settings.json |
全プロジェクト共通（個人） | なし |
.claude/settings.json |
プロジェクト共有 | あり |
.claude/settings.local.json |
ローカルのみ | なし（gitignored） |
settings.local.json はgitignoreされるので、チームメンバーには影響しない。自分だけ教育スタイルで使いたいなら、ここに書けばいい。
{
"outputStyle": "my-style"
}
この階層構造はCLAUDE.md・Rules・settingsの全部に共通している。
my-styleはデフォルト4兄弟でも、Custumでもお好きなものを都度指定してあげよ✌🏻
設定の置き場所＝影響範囲 という設計思想がClaude Code全体を貫いている。
-
~/.claude/→ 自分の全プロジェクト -
.claude/→ チーム全員 -
.claude/*.local→ 自分だけ（gitignored）
💁🏼便利なツールだからこそ、しっかり追ってあげる事で、クオリティもあげ👆
今回知れたこと一覧
- Rules の
paths:はファイルを触った時だけルールを読み込む仕組みで、コンテキスト節約に効く -
paths:なしのRulesはCLAUDE.mdに書くのと機械的に同じ - ブレース展開
**/*.{ts,tsx}が使える（公式ドキュメントで確認済み） - Output stylesはデフォルトでは存在しない。自分で
~/.claude/output-styles/に作る -
keep-coding-instructions: trueを書かないと、デフォルトのコーディング指示が全部消える - 権威が強い設定ほど、柔軟性が下がる。切り替えられる余地を残すのも設計のうち
-
settings.local.jsonはgitignoreされる。チームへの影響なしに個人設定できる - Output stylesはプロジェクトレベル（
.claude/output-styles/）にも置ける。他プロジェクトに影響しない - Rulesは「コードの制約」、Output stylesは「Claudeの人格・スタイル」で使い分ける
- AI時代、アップデートが目まぐるしすぎてやばい
- ゆっくりでいいからどんどん知識つけてこ🤌
参考