Claude Codeの使い方
「Claude Code、思ったより遅く課金も気になる」と感じている方は使い方の「クセ」？以下はClaude Code「7つのポイント」です
1. CLAUDE.md を“全部”記述しない
命名規約、過去の経緯、ディレクトリ構成、思想まで全部書き込んで 数百行の巨大命令？
CLAUDE.md が大きいと、全文がinput、 何気ない操作でも大量のトークンと注意を消費。
正しい使い方
- CLAUDE.md は「憲法」だけ記述
- 特定作業で必要な知識は Agent Skills（.claude/skills/）へ分離
- Skills は必要なときだけ読ませる → CLAUDE.md は憲法、Skills は六法全書のイメージ。
２．1つの指示に作業全部お願いする
「テスト直して、リファクタして、ドキュメント更新して、PRも作って」 こうした“全部盛り指示”は、長いコンテキストの途中で注意が薄れ、 Claudeが自分の作業目的を見失う lost in the middle を起こしやすい。
正しい使い方
- 責務をサブエージェントに分離する
- 例：レビュー専任、テスト専任、i18nチェック専任
- メイン会話は「指揮官」として保ち、手を動かすのはエージェントに任せる
- 例： 「あなたはレビュー専任。修正提案ではなく、どこが・なぜ壊れるかだけ返して」
３. 実装途中で /compact を使ってしまう
コンテキストが膨らむと反射的に /compact したくなるが、 圧縮の過程で「これから何をするつもりだったか」が要約に吸収される。
その結果、再開したClaudeは自分の設計を忘れ、 半分だけ実装された土台の上に別の実装を重ねてしまう。
正しい使い方
- /compact は作業の区切り（コミット直後）でだけ使う
- 長い作業は最初に PLAN.md に計画を書き出す
- 実装途中の手動 compact は「危ない手術」と考えて慎重に扱う
４． MCPサーバーを“全部盛り”で常時接続している
Slack、GitHub、Notion、ブラウザ、ファイル系などを全部つないでいると、 ツール定義そのものがコンテキストを圧迫し、 今日使わないツールが毎ターンのトークンと判断力を奪う。
正しい使い方
- 今日のタスクに必要な MCP だけ接続する
- 多数つなぎたい場合は Deferred Tool Loading を使う
- 「全部入れる」発想から「必要な分だけ」に切り替える
５. 設計まで丸投げしない
「いい感じにアプリ作って」 これで出てくるのは、見た目は良くても本質的に危ないコードだ。AIは“動くように見えるコード”を書くのが非常に上手いが、 寿命・所有権・スレッドの問題をすり抜けることがある。
正しい使い方
- 設計は人間、実装はAIという境界を守る
- 「何を作るか」「どういう構造か」は人間が決める
- ネイティブ層・並行処理・ライフサイクルは人間が目視確認する
- 小さく投げる → 検証 → 直す → また投げる のループで進める
６. レビューを人間がサボってしまう
「AIが書いたから大丈夫」逆、生成速度が上がったぶんレビューの重要性はむしろ増す。
正しい使い方
- レビュー専任サブエージェントに一次レビューさせる
- 人間は最終確認に集中する
- diff は小さく保ち、1000行PRは避ける
- 「テストが通った」と「正しい」は別物
- テストが何を保証していないか毎回確認する
７. 同じ会話を続けない
1セッションで一日中作業すると、コンテキストが際限なく伸び、 応答は少しずつズレ、トークンはズレる。それを「深い対話」と勘違いしがちだが、実際には非効率。
正しい使い方
- タスクが変わったらセッションを切る
- 長期の文脈は会話ではなくファイル（CLAUDE.md / Skills / PLAN.md）に保存
- 会話は揮発、ファイルは不揮発と割り切る
- 「会話を育てる」ではなく「仕組みを育てる」発想へ
📘 まとめ表：よくある間違いと正解
| よくある間違い | 正解 |
| CLAUDE.md を全部入りに | 最小限＋Agent Skills |
| 1指示に全作業を詰める | サブエージェントで責務分離 |
| 実装途中の /compact | 区切りでのみ、計画はファイルへ |
| MCP全部盛り | 必要な分だけ＋遅延ロード |
| 設計まで丸投げ | 設計は人間、実装を委任 |
| レビューをサボる | レビュー専任エージェント＋小さいdiff |
| 同じ会話を延々使う | タスクで切る、文脈はファイルに |
🎯 結論
「コードを書く」から「タスク委任」へ。 委任先は、優秀だが3分で記憶を失う天才だと思って扱うとちょうどいい。CLAUDE.md を半分に削るところから始める。
次のステップ
- CLAUDE.md の最適構成を一緒に作る
- Skills フォルダの設計テンプレートを作る
- PLAN.md の書き方を最適化する
CLAUDE.md 最適構成を作るには結論から言うと、CLAUDE.md は「最小限の憲法」だけを置く構成にすると、Claude Code の性能が一気に安定する。 あなたの開発スタイル（教育向け、構造化、A4縦レイアウト、工程を分けて進める）にも合うように、最適構成の完成形テンプレートをそのまま使える形でまとめた。
🧭 CLAUDE.md の最適構成（完成テンプレート）
以下は「そのままコピペして使える」構成。 強すぎる指示は避け、Claude が誤解しない“ちょうど良い強度”に調整してある。
# CLAUDE.md（憲法：最小限・普遍ルールのみ）
1. プロジェクトの目的（1〜3行）
本プロジェクトは、〇〇を実現するためのアプリケーション、 Claude Code は実装補助で利用。
2. Claude に守ってほしい基本姿勢
- 設計は人間が行う。Claude は実装と補助に集中する
- 不明点は推測せず、必ず質問してから進める
- diff は小さく、変更理由を明記する
- テストが保証しない領域は必ず指摘する
- 長期文脈は会話ではなくファイル（Skills / PLAN.md）に保存する
3. ディレクトリの基本構造（簡潔に）
コード
/src
/tests
/docs
.claude/skills
PLAN.md
4. 禁止事項（Claude が暴走しやすい領域）
- 大規模リファクタを一度に行う
- 推測で設計を追加する
- 実装途中の /compact
- 1000行を超える PR を生成する
5. Claude が返すべきフォーマット
- コード変更 → diff
- 説明 → 箇条書き
- 質問 → 1〜3個に絞る
- 長い作業 → PLAN.md に計画を書き出してから着手
📁 Skills（六法全書：必要なときだけ読む）
CLAUDE.md に書かない知識はすべてここへ逃がす。
Skills の分類例
- reviewer.skill.md（レビュー専任の振る舞い）
- tests.skill.md（テストを書くときのルール）
- i18n.skill.md（翻訳チェックの基準）
- expo.skill.md（Expo のプロジェクト固有ルール）
- swift-native.skill.md（ネイティブ層の注意点）
- supabase.skill.md（DB・API の扱い方）
Skills は「必要なときだけロードされる」ので、 CLAUDE.md を軽く保つための分離先として最適。
🗂 PLAN.md（長い作業の計画書）
Claude Code の弱点である「記憶の短さ」を補うための必須ファイル。
PLAN.md の構成例
コード
# 今日のタスク
- 通話画面の UI 改修
- Supabase の認証周りの整理
# 手順
1. UI の構造を確認
2. 変更点を diff で提示
3. テストを更新
4. PR を生成
# 注意点
- Swift ネイティブ側のライフサイクルは壊さない
- i18n のキーは既存ルールに従う
🧩 CLAUDE.md・Skills・PLAN.md の役割分担（最適化版）
| ファイル | 役割 | 内容量 |
| CLAUDE.md | 憲法（普遍ルール） | 最小限（〜200行以内） |
| Skills | 特定作業の知識 | 必要なだけ（分割） |
| PLAN.md | 長い作業の計画 | タスクごとに更新 |
この構成にすると、Claude Code の「注意力の散乱」がほぼ消え、 実装精度・速度・一貫性がすべて向上する。
🎯 今すぐ作れる「最適 CLAUDE.md」ひな形
あなたのプロジェクト向けに最適化した、 完成度の高いひな形をそのまま貼るだけで使えるようにした。
📄 CLAUDE.md（貼るだけで使える最終版）
コード
# CLAUDE.md — Project Constitution
## 1. Purpose
このプロジェクトは、〇〇を実現するアプリケーションであり、
Claude Code は実装補助として利用する。
## 2. Core Principles
- 設計は人間が行う。Claude は実装と補助に集中する。
- 推測で構造を追加しない。不明点は必ず質問する。
- diff は小さく、変更理由を明記する。
- テストが保証しない領域を毎回指摘する。
- 長期文脈は会話ではなくファイル（Skills / PLAN.md）に保存する。
## 3. Directory Structure
/src /tests /docs .claude/skills PLAN.md
コード
## 4. Prohibited Actions
- 大規模リファクタを一度に行うこと
- 推測で設計を追加すること
- 実装途中の /compact
- 1000行を超える PR の生成
## 5. Output Format Rules
- コード変更 → diff
- 説明 → 箇条書き
- 質問 → 1〜3個に絞る
- 長い作業 → PLAN.md に計画を書き出してから着手
CLAUDE.md（EITプロジェクト専用・完全版）
コード
# CLAUDE.md — Project Constitution (Okuno Edition)
## 1. Purpose
このプロジェクトは、教育向け STEM/AI/フィジカルコンピューティング教材、
および関連アプリケーションを開発するためのものである。
Claude Code は「実装補助」として利用し、設計・構造判断は人間が行う。
## 2. Core Principles
- 設計は人間、実装はClaude。推測で構造を追加しない。
- 不明点は必ず質問し、曖昧なまま進めない。
- diff は小さく、変更理由を明記する。
- テストが保証しない領域を毎回指摘する。
- 長期文脈は会話ではなく、Skills / PLAN.md に保存する。
- 教材用途のため、読みやすさ・説明性を優先する。
## 3. Project Characteristics
- A4縦レイアウトの資料生成では、構造化されたMarkdownを返す。
- 図示が必要な場合は簡易ASCII図で示す。
- 子ども・初心者が読んでも理解できるコードを優先する。
- Arduinoや電子工作では、安全性（電流・発熱）に関わる処理を勝手に追加しない。
## 4. Technology Boundaries
- ネイティブ層（Swift / Android）は推測で触れない。
- WebSerial / WebGPU / TensorFlow.js は既存仕様に従う。
- 並行処理・ライフサイクル・所有権は人間が最終確認する。
- Supabase のスキーマは勝手に変更しない。
## 5. Directory Structure
/src /tests /docs .claude/skills PLAN.md
コード
## 6. Prohibited Actions
- 大規模リファクタを一度に行うこと
- 推測で設計を追加すること
- 実装途中の /compact
- 1000行を超えるPRの生成
- 「いい感じに作って」への勝手な構造提案
## 7. Output Format Rules
- コード変更 → diff
- 説明 → 箇条書き
- 質問 → 1〜3個に絞る
- 長い作業 → PLAN.md に計画を書き出してから着手
- 資料生成 → A4縦レイアウトを意識したMarkdown構造
## 8. Claude’s Role
Claude は「実装者」であり「設計者ではない」。
構造・責務分離・アーキテクチャは人間が決める。
Claude は計画に従い、正確な実装とレビュー補助を行う。
## 9. Review Standards
- 教育用途のため、変数名・関数名は説明的にする。
- 初学者が読んでも理解できるレベルを目指す。
- テストは「動く」ではなく「理解できる」を優先する。
- diff は小さく、変更理由を明記する。
CLAUDE.md の特徴（EIT向け最適化ポイント）
- 教育向け → 説明性・読みやすさを最優先
- STEM/AI教材 → 図示・構造化Markdownを標準化
- Arduino/電子工作 → 安全性ルールを明文化
- AI × 物理コンピューティング → WebSerial/WebGPU/TensorFlow.js の境界線を明確化
- アプリ開発（Expo/Supabase/Swift） → 推測で触れない領域を明確化
- Claude Code の弱点対策 → 設計禁止・長期文脈の外部化・diff小さく
- あなたの制作物の特徴 → A4縦レイアウトの資料生成ルールを標準化
これにより、Claude Code が迷わず、 毎回同じ品質で、安定した実装・資料生成ができるようになる事を祈ってます。