claud codeの情報が色々あるが全て読んでいいとこだけ知りたい。
ただ面倒だ。。。
Claude Code のタグには 3,500 本以上の記事がある。全部読むのは現実的じゃない。
そんなユーザーのためにだから自分が代わりに読んだ。♡上位50本を全部。
正確にいうとclaud codeに読み込んでもらって解析した
50本読んで気づいたのは、「やるべきことは意外と少ない」ということ。記事ごとに表現は違うが、本質的に同じことを言っている。それを 7 つに絞った。
この記事を読み終わったら、50 本分のエッセンスが手に入る。そして各パターンに「今日できること」をつけた。読んで終わりにならないように。
1. CLAUDE.md は長いほど効かなくなる
多くの人が CLAUDE.md に 100 行以上書いている。技術スタック、コマンド一覧、コーディング規約……。気持ちはわかる。でも、長いほど Claude の指示遵守度は下がる。
なぜか。
Claude のコンテキストウィンドウは有限の資源で、CLAUDE.md の内容、会話の履歴、ツール情報、スキルのメタデータが全部同じ枠に入る。CLAUDE.md が長いと他の情報が入るスペースが減る。さらにセッションが進むと、最初に読み込んだ指示への注意が薄れていく。
では何を残すか。Claude の行動を変える指示だけを残す。
# これは効く（行動原則）
- 3ステップ以上のタスクは必ず Plan モードで開始する
- コードを提案する前に必ず対象ファイルを読む
- バグ修正前にそのバグを再現するテストを書く
「Python は動的型付け言語です」みたいな説明は書かない。Claude はそれを知っている。「PDF とは Portable Document Format の略で……」も書かない。トークンの無駄。
コーディング規約やファイル命名規則は .claude/rules/ に分離する。ここに置いたルールは、ファイルパターンで条件付き適用できる。たとえば TypeScript のルールは *.ts にだけ適用し、Python のルールは *.py にだけ適用する。CLAUDE.md を汚さずに済む。
複数の AI ツールを併用しているなら、AGENTS.md も選択肢に入る。60,000 以上のリポジトリが採用し、Linux Foundation が標準として認定した仕様。Claude Code、Cursor、Gemini CLI で共通利用できるので、同じ指示を 3 つのファイルに転記する不毛な作業がなくなる。
📌 今日できること： CLAUDE.md を開いて、1 行ずつ「これがないと Claude の出力が変わるか？」と問いかける。答えが No なら消すか .claude/rules/ に移す。
2. 「何をするか」ではなく「何を解決するか」を伝える
♡1,716 を獲得した最人気記事が伝えていたのはシンプルなことだった。Claude Code を「自動化ツール」ではなく「仕事を任せる相手」として扱え、ということ。
この感覚の違いで、指示の出し方が根本的に変わる。
❌ auth.js の 42 行目を修正して、トークン検証ロジックを追加して
⭕ ログイン時の CSRF トークン検証が失敗する。原因を特定して修正して
前者は「手順」を伝えている。後者は「目的」を伝えている。目的を伝えれば、Claude は自分で最適な手段を選ぶ。42 行目が原因じゃなかった場合、前者の指示では永遠に直らない。
ただし「全部任せる」のは現実的じゃない。完全自動化を目指すと、設定コストが成果を上回る。一番つらい部分だけ任せるのが正解。経費精算が 30 分から 5 分になれば、それだけで毎月何時間も浮く。
仕事を任せるとき、4 つのドキュメントがあると品質が安定する。
| ファイル | 書くこと |
|---|---|
| PLAN.md | これから何を作るか、なぜ作るか |
| SPEC.md | 技術的にどう作るか |
| TODO.md | 具体的なタスク分解 |
| KNOWLEDGE.md | 調査で分かったこと、過去の失敗 |
PLAN.md は雑でいい。完璧を目指すと書き始められない。「ログイン機能を作る。理由はユーザーから要望が来たから」で十分。
指示の質をさらに上げたいなら、2 つの軸を意識するだけでいい。「Done の定義を明確にする」と「文脈を共有する」。「npm run test:auth がパスすること」という Done 定義があれば、Claude は何をもって完了とするかを正確に理解できる。
📌 今日できること： 次のタスクで、手順ではなく目的を伝えてみる。「〇〇行目を直して」ではなく「〇〇が起きる原因を調べて直して」。
3. 同じウィンドウで長時間作業しない
Claude Code を使っていて「トークン上限に達しました」が頻発するなら、これが原因かもしれない。
同じチャットウィンドウで何時間も作業を続けると、Claude は毎回その会話の全履歴を再読み込みする。メールの下書きが終わったあとに旅行の計画を始めたら、メールの文脈が旅行の処理に毎回ロードされる。これは純粋な無駄。
30〜45 分で新しいウィンドウを開く。話題が変わったら切る。新しいウィンドウ = 新しいコンテキスト = 新しい予算。
もう 1 つ見落としがちなのが、MCP コネクタの基礎消費。Slack、Notion、GitHub、Google Drive を全部 ON にしていると、自分が 1 文字もタイプしていない状態で既にコンテキストの一部が埋まっている。今のタスクに必要なコネクタだけ ON にする。
100 件の請求書を 1 件ずつ会話で処理させるのも非効率。スキル化してスクリプトで回せば、スクリプトの実行結果だけがコンテキストに入る。トークン消費が桁違いに減る。
📌 今日できること： 接続中の MCP コネクタを確認して、今のタスクに不要なものを OFF にする。
4. スキルは「全部入り」にしない
Anthropic 公式のスキル構築ガイドで最も重要な概念が「段階的開示」。スキルは 3 段階でロードされる。
- 常時ロード： スキルの名前と説明文だけ（約 100 トークン/個）
- 発動時： SKILL.md の本文（推奨 5,000 トークン以下）
- 必要時のみ： 参照ファイルやスクリプト（使わなければ 0）
100 個のスキルをインストールしても、常時ロードは 10,000 トークンで済む。だから「スキルを入れすぎると重くなる」は誤解。重くなるのは SKILL.md に情報を詰め込みすぎた場合。
SKILL.md は「目次」として書く。詳細は別ファイルに分離して、Claude が必要なファイルだけ読みに行く設計にする。
pdf-skill/
├── SKILL.md ← 発動時に読み込み（目次）
├── FORMS.md ← フォーム操作が必要なときだけ
└── scripts/
└── fill_form.py ← 実行されるがコード自体はコンテキストに入らない
スクリプトのコード自体はコンテキストウィンドウに入らない。出力結果だけが返る。だから同じ処理を会話で Claude に書かせて実行するよりも、スキル化しておくほうがトークン効率がいい。
スキルが発動しない問題は、ほぼ 100% Description の記述不足。「何をするか」「いつ使うか」「主要機能」の 3 要素を含める。
📌 今日できること： 週に 1 回以上やっている定型作業を 1 つ選んで「今のやり方をスキルにして」と Claude に頼む。
5. AI の回答を待つ時間をゼロにする
Claude が考えている間、画面を眺めて待っていないか。その時間がもったいない。
ターミナルのタブを複数開いて、それぞれで Claude Code セッションを走らせる。1 つが処理中の間に、別のタブで次の指示を出す。10〜15 個の並列インスタンスで回している実践者もいる。
ただし「AI で速くなる」は思い込みの可能性がある。UC バークレーの研究では、経験豊富な開発者が「24% 速くなる」と予想していたのに、実測では 19% 遅くなった。原因はセルフレビューと手戻りのコスト。
つまり速さの本質は「生成速度」ではなく「やり直さないこと」。軽量モデルで速く回すより、高性能モデルで一発で決めるほうが効率がいい場合が多い。修正指示の手戻り時間のほうが高くつく。
Git Worktree と組み合わせると、完全に隔離された環境で並列開発できる。claude -w ブランチ名 でブランチ切り替えのコンテキストロスがなくなる。
CLAUDE.md を Git 管理して、AI のミスを記録していくのも効果的。チーム全体の AI が同じ失敗を繰り返さなくなる。知識が複利で効く。
📌 今日できること： ターミナルでタブを 2 つ開いて、片方が処理中に別のタブで次の作業を始めてみる。
6. セキュリティ設定をサボると本番データが消える
実際に起きた事故がある。月 5〜10 ドルの節約を目指したインフラ統合作業で、Terraform の誤実行により 2.5 年分のデータ（約 194 万行）を失った。原因は「何度も成功していたので、承認のハードルが下がっていた」こと。
プロンプトインジェクションの検証では、自然なコード例に紛れた攻撃——print デバッグに認証情報を出力するロジックを混ぜる——が Claude Code に検知されなかった。
対策は 3 つ。
1. 破壊的コマンドを settings.json でブロックする
{
"permissions": {
"deny": [
"Bash(rm -rf *)",
"Bash(git push --force *)",
"Bash(terraform destroy *)"
]
}
}
2. 機密ファイルへのアクセスを制限する
.env、credentials.*、*secret* を .claude/rules/security.md で保護。
3. 「これは何を壊し得るか」を一文で言えるか確認してから承認する
auto-accept モードは便利だが、成功体験が積み重なると確認が形骸化する。新人に本番環境の権限を渡すのと同じ慎重さで運用する。
外部からダウンロードしたスキルは、使う前に必ず Claude Chat で安全確認する。2 分で終わる。
📌 今日できること： settings.json を開いて permissions.deny に rm -rf と git push --force を追加する。
7. 「毎回ゼロから説明する」を仕組みで解決する
新しいセッションを開くたびに、先週やった仕事も、プロジェクトのルールも何も覚えていない。これが「セッション記憶喪失」問題。
解決策は 3 つのファイルで引き継ぎの仕組みを作ること。
| ファイル | 誰が書くか | 内容 |
|---|---|---|
| AGENTS.md | 人間 | 変わらないルール・プロジェクト方針 |
| MEMORY.md | Claude | 学習内容・過去のミス・判明した仕様 |
| HANDOFF.md | 人間がキュレーション | 次のセッションへの引き継ぎ |
ポイントは AI に自由に書かせすぎないこと。MEMORY.md は Claude が記録するが、HANDOFF.md は人間が取捨選択する。AI が書いた記憶が無限に膨らむと、それ自体がコンテキストを圧迫する。
Obsidian をコンテキスト倉庫として使う手法もある。Wikilink で接続されたドキュメント群から、Claude が自律的に関連情報を検索・参照する。ある実践者は「厳密なルールこそが、コンテキストに沿った自律性を生む」と表現していた。自由にさせたいなら、まず枠を決める。
最終的には「Issue 番号を伝えるだけ」で、Claude が自律的にコード実装→テスト→PR 作成まで完結する開発フローも実現できる。人間はレビューと承認だけ。そこまでいくには、記憶の仕組みが土台になる。
📌 今日できること： プロジェクトフォルダに MEMORY.md を作って、「このプロジェクトで学んだことを MEMORY.md に追記して」と Claude に伝える。
まとめ：50 本読んで分かった、たった 1 つのこと
| # | パターン | 一言 |
|---|---|---|
| 1 | CLAUDE.md は短く | 行動原則だけ残す |
| 2 | 目的を伝える | 手順じゃなく課題を渡す |
| 3 | 30 分で切る | コンテキスト腐敗を防ぐ |
| 4 | スキルは目次で | 段階的開示で軽量化 |
| 5 | 待ち時間ゼロ | 並列で回す |
| 6 | セキュリティ最初 | 事故は設定で防げる |
| 7 | 記憶の仕組み化 | 毎回ゼロをやめる |
7 つのパターンを貫く共通思想は 1 つ。
Claude Code は道具じゃなくて、仕事を任せる相手。
道具なら使い方を覚えればいい。でも仕事を任せる相手なら、環境を整えて、ルールを共有して、引き継ぎの仕組みを作る必要がある。
CLAUDE.md はルールブック。スキルはマニュアル。MEMORY.md は引き継ぎ書。セキュリティ設定は権限管理。全部、新しいメンバーを迎え入れるときにやることと同じ。
50 本の記事を読んで、最も印象に残った一文がある。
「速く作るんじゃない。やり直さないから速い」
明日から 1 つずつ試してみてほしい。7 つ全部やる必要はない。1 つやるだけで、Claude Code との仕事の仕方が変わる。