Claude Code を入れて、いざ使い始めてみたけど、思ったより言うことを聞いてくれない。同じ間違いを何度も繰り返すし、こっちが前に言ったことをすぐ忘れる。
そんな経験はないでしょうか。
そういう時には、一番最初に「公式の運用ドキュメントを、AI本人に読ませて、自分用のスキルに整理させる」のがおすすめです。これをやっておくと、その後のAIの動きがマシになるかもしれません。
そのために投げるプロンプトの例がこれ↓。理由は後で説明するので、とりあえずなんもわからんという人はコピーして使ってみてもいいかもしれないですね。
Claude Code の運用を、Anthropic の公式ドキュメントに沿って整えたいです。
1. まず、Claude Code の公式ドキュメントのうち運用・カスタマイズに関するページ
（CLAUDE.md / メモリ、スキル、フック、サブエージェント、ルール、権限モード、
MCP、ベストプラクティス、および「Steering Claude Code」の解説記事）を
実際に開いて読み、内容を把握してください。
記憶や推測ではなく、ページを参照したうえで回答してください。
2. 読み終えたら、すぐ作成に進まず、
「どの知識を、どの形式（CLAUDE.md / スキル / .claude/rules / フック）でまとめるか」
の方針をまず提案してください。
公式が示す使い分け（常時必要な短い規約は CLAUDE.md、手順やノウハウはスキル、
特定パスに紐づく制約はルール、自動実行はフック）に従い、
内容の性質に応じて置き場所を選んでください。
3. 方針に合意できたら、その形で整理してください。
スキルにまとめる場合は、description に「何を・どんなときに使うか」を
具体的に記載し、各項目に参照元の公式ページ URL を添えてください。迷ったらこれを丸ごと投げてOK。理由が気になる人だけ、この先を読んでください。
この記事では、前半で「なぜこれが効くのか・何を読ませ・どう整理させるのか」を、後半で「初日に知っておくと得する公式の勘どころ」を解説します。
INDEX
なぜ最初にこれをやるのか ―― AIは「毎朝記憶を失う新人」だから
Claude Code は、放っておくと本当に何も知らない状態からスタートします。あなたの好み、プロジェクトのルール、やってほしくないこと ―― 何ひとつ覚えていません。しかもセッションをまたぐと、基本はリセット。
たとえるなら、毎朝、記憶を失った新人が出社してくるようなものです。優秀なのは間違いない。でも昨日教えたことを今日はもう覚えていない。そりゃあ同じ説明を何度もさせられるわけだ、と。
この新人に効くのが、毎朝きちんと読み返してくれる社内マニュアルを先に用意しておくことです。そして、そのマニュアルの”正しい作り方”を一番よく知っているのは、開発元の Anthropic 本人。だから最初に、公式の運用ドキュメントを読ませてしまうのが早いというわけです。
ステップ① 何を読ませるのか ―― 公式ドキュメント一覧
これらをAI本人に読ませます。AIの運用自体もAIにやらせるのがスタンダードです。細かい調整は人の指示が必要かもしれませんが、大枠はAI自身に作ってもらいましょう。
- ベストプラクティス ―― そもそもの上手な使い方
- メモリ / CLAUDE.md ―― ルールを常に読ませる仕組み
- スキル ―― 手順やノウハウを渡す仕組み
- フック ―― 決まったタイミングで処理を自動実行する仕組み
- サブエージェント ―― 脇作業を切り出して本筋を汚さない仕組み
- 権限モード ―― どこまで勝手にやらせるかの設定
- MCP ―― 外部ツールと連携する仕組み
そして今回の一番の目玉が、「どの知識をどこに置くか」を公式が正面から解説したこの記事。
- 🔴 Steering Claude Code: when to use CLAUDE.md, skills, hooks, and subagents（Anthropic 公式ブログ）
白状すると、私のClaudeはこの決定版ブログを最初に見落としていて、遠回りしました。「徹底的に調べろ」と命令したとしてもAIは確実に命令を守るとは限りません。そこはAIを使っていく上で予測みたいなものが働いてくるのですが、怪しいと思ったら「本当に命令したことができているのか？」という再確認はやった方がいいかもしれません。
ステップ② どう整理させるのが正解か ―― 公式の「使い分け」
ここが前半の核心です。公式は、AIへの指示を置く場所を7つ挙げて、それぞれ「コンテキスト（AIの作業メモリ）をどれだけ食うか」と「どれだけ強く従わせられるか」の2軸で使い分けろ、と言っています。
| 置き場所 | いつ使うか |
|---|---|
| CLAUDE.md | ビルドコマンド・ディレクトリ構成・コーディング規約など、常に効かせたい短い事実。毎回まるごと読み込まれる。 |
| ルール（.claude/rules/） | 特定のファイル・フォルダ限定の制約（例「このフォルダは追記のみ」）。その場所を触った時だけ読み込ませられる。 |
| スキル | デプロイ手順・レビュー手順など手順もの。呼ばれた時だけ本体が読み込まれる。 |
| サブエージェント | 調査・ログ解析など、本筋の会話を散らかす脇作業。別の頭で処理して結果だけ返す。 |
| フック | 編集後の自動整形・危険コマンドのブロックなど、絶対に決まった通り起きてほしい処理。 |
| アウトプットスタイル | AIの役割やトーンそのものを変える大きな変更（例: 解説モードにする）。 |
| システムプロンプト追記 | その起動一回きりの追加指示。 |
全部覚える必要はありません。初心者がまず押さえるべきは、次の「これはこっち」という置き換えの勘どころ。公式がはっきり言い切っている部分です。
- CLAUDE.md に30行もの手順を書いているなら → スキルへ移す。CLAUDE.md は”常に持っておくべき事実”の置き場で、手順の置き場ではない。
- 「毎回Xしたら必ずY」と書いているなら → フックにする。「モデルが整形ツールを”選んで”走らせる」のと「整形ツールが”自動で”走る」のは別物。指示は破られることがある、コードは破られない。
- 絶対に起きてはいけないことは、指示では守れない。長いセッションや曖昧な状況では、AIはルールを破ることがある。本当に止めたいならフックで実行前にブロックする。
- 個人の好みは、プロジェクトの CLAUDE.md に書かない。ユーザー個人の設定ファイルへ。プロジェクト側はチーム共通のことだけ。
CLAUDE.md には、公式の具体的な目安もあります。
CLAUDE.md は200行未満に保て。毎行が、全エンジニアの全セッションに読み込まれる ―― たとえその作業に関係なくても。
じつは私の CLAUDE.md も、最初は207行で目安をオーバーしていました。200行以内はそもそも意識していたのですが、気付かぬうちに超えていたようです。定期的な検査というのも必要です。
中を見たら、スキルにも書いてある手順を CLAUDE.md にも重ねて書いていた ―― いわゆる二重管理です。そこをスキルへのリンクに置き換えたら、172行に収まりました。なんでもかんでも CLAUDE.md に盛ると、大事なルールがノイズに埋もれてAIに無視されます。盛ればいいってものじゃない、というわけです。
ここが一番の学び ―― AIが資料を「読まない」のは書き方の問題
スキルに手順をまとめても、肝心なときにAIがそれを読んでくれない、という現象が起きることがあります。「ちゃんと書いたのに！」と、正直けっこうイラっとします。
この真因も、公式を読むと分かります。スキルには description（説明文）という短い一行があって、AIはまずそれだけを見て「今これを読むべきか」を判断しているんです。
この一行に、実際に困っている場面のキーワードが入っていないと、AIは「今がその場面だ」と気づけない。だから本体を読まない。
たとえば「デプロイで詰まったら読め」と書くべきところに、ふわっと「デプロイの手順」とだけ書いていた。これじゃあ、いざ困っても本人が気づけない。読まなかったのは、やる気の問題じゃなくて説明文の書き方の問題でした。私の場合も、説明文が弱いスキルが9個見つかって、全部「何を・どんなときに読むか」を具体的な言葉に書き直したら、読まれないことは減ったような気がします。
AIがミスをした時、それを指摘するとけっこう精神論的に「今後はより気をつけます」みたいなことを言ってきたり、メモリーに反省文的なものを書いたりするのですが、効き目は薄い気がするのでできるだけ公式の推奨する形に寄せるっていうのが良いかなと思います。これは人間が言ってあげないとやってくれなかったりするので、意識しておきたいところです。
ついでに知っておくと得する、公式仕込みの勘どころ
ここからは、公式ドキュメントを読んで「初日に知っておきたかった」と思ったことを、まとめて置いておきます。整理の話とは別に、これを知っているだけで日々の快適さが変わるかもしれません。
大原則:「コンテキストは早く埋まり、埋まると賢さが落ちる」
公式ベストプラクティスの中心にある原則がこれです。AIには「作業メモリ（コンテキスト）」の上限があって、長い作業や無関係な会話でそれが埋まってくると、実際に賢さ（出力の質）が落ちます。だから上手い人は、メモリを意識的に管理します。
- 無関係なタスクに移るときは
/clearで会話をまっさらにする - 話が長引いてきたら
/compactで会話を要約・圧縮する - いま何が読み込まれているかは
/contextで確認できる
「AIがなんだか急にポンコツになった」と感じたら、たいていメモリが散らかっています。こまめに片付ける。これだけで体感がだいぶ変わります。
個人的にはこのコンテキストをリセットする動きっていうのは、また初対面の人と会うみたいで苦手なんですが、意識した方が良いというのは間違いないみたいです。頑張りましょう。
初心者がハマる「5つの失敗パターン」
公式がわざわざ名指しで挙げている”やりがちな失敗”です。先に知っておくと避けられます。
| やりがちな失敗 | 公式の対処 |
|---|---|
| なんでも1セッションに詰め込む | 無関係な話が混ざるとメモリが汚れる。話題が変わったら /clear で仕切る。 |
| 修正の沼（間違い→修正→また間違い） | 2回失敗したら一度 /clearして、指示を練り直す。失敗した試行がメモリに残ると足を引っ張る。 |
| CLAUDE.md を盛りすぎる | 重要ルールがノイズに埋もれて半分無視される。削るか、フックに変換する。 |
| AIを信用しすぎる | それっぽいけど間違った実装を出すことがある。テストやスクショで必ず検証してから受け入れる。 |
| 「Xを調べて」と丸投げ | 範囲がないと何百ファイルも読んでメモリが即満杯に。範囲を絞るか、サブエージェントに投げる。 |
タスクの渡し方の”型”: 調べる → 計画 → 実装 → コミット
いきなり「これ作って」と丸投げすると、AIは方針を外したまま突っ走ることがあります。公式が推奨するのは、段階を踏ませる渡し方。
- 調べる（Explore）: まず関連コードを読ませて、現状を把握させる
- 計画（Plan）: いきなり書かせず、先に「どうやるか」の計画を出させる。
Shift+Tabのプランモードを使うと、実装前に方針だけ確認できる - 実装（Code）: 計画に納得してから書かせる
- コミット（Commit）: 最後にコミットまで任せる
この順で渡すだけで、手戻りがぐっと減ります。「作って」の前に「どう作るつもり?」を挟む。これだけです。あわせて、指示はできるだけ具体的に。エラーやログは「これ読んで」と貼るより、「このファイルを読んで原因を探して」とAI自身に取りに行かせるほうが上手くいきます。
コードを書かなくても効く、便利機能
/rewind―― 会話やファイルの変更を巻き戻せる。AIが変なことをしても、慌てず戻せる安心装置。- アウトプットスタイル ――
/configから選ぶだけで、AIの応答スタイルを変えられる。たとえば「Explanatory」を選ぶと、作業しながら”なぜこうするか”の解説を挟んでくれる。学びながら使いたい人におすすめ。 - オートメモリ ―― AIが作業中に得た学び（ビルドコマンドやハマりどころ）を、自動でメモに貯めていってくれる。放っておいても少しずつ賢くなる。
まとめ ―― 土台を先に作ると、あとがラクになる
長くなったので、要点だけ整理します。
- 公式運用ドキュメントを、AI本人に読ませる（とくに「Steering Claude Code」）
- 読んだ内容を、中身の性質に応じて置き分けさせる（常時の短い規約は CLAUDE.md、手順はスキル、パス固有はルール、自動実行はフック）
- スキルの説明文には「何を・いつ読むか」を具体的な言葉で書く
- CLAUDE.md は200行未満を目安に、短く保つ
- 日々は
/clear・/compactでメモリを片付けながら、調べる→計画→実装の順で渡す
私の環境も色々散らかっていたんですが、これをやって少しはまとまった気がしております。最初のうちにやっておけばもっとスムーズだったかなぁと思い、この記事を作成しました。
Claude Code を触り始めて「なんだか噛み合わないな」と感じている方は、まず冒頭のプロンプトを本人に投げるところから試してみてはいかがでしょうか。
もっと未来ではこんなことも意識する必要はなくなると思いますが、今のうちは我慢して運用方法なんかも情報を追っていかないといけないですね……面倒ですが頑張りましょう。
ここまで読んでいただき、ありがとうございました。
