「Claude Code、思ったより速くならないな」と感じているなら、原因はモデルでもプランでもない。お前の使い方だ。
きつい言い方をして悪い。だが3ヶ月、毎日Claude Codeと殴り合いながらExpo + Supabase + Swiftネイティブの通話アプリを個人開発して、確信した。
速くならない人間は、全員同じ7つのミスをしている。
この記事はポエムでも宣伝でもない。明日から効く設定の話だけを、忖度抜きで書く。1つでも刺さったら、お前は今日まで時間を捨てていたということだ。
ミス1. CLAUDE.md を「全部入りの聖書」にしている
命名規約、過去の経緯、ディレクトリ構成、お気持ち表明——全部 CLAUDE.md に書き込んで2000行の大作にしていないか。
それ、毎ターン全文がコンテキストに乗っている。 git status を聞いただけのターンでも、その2000行ぶんのトークンを毎回お前が払っている。賢くなるどころか、財布と注意力が燃えているだけだ。
正解は、最小限。
# CLAUDE.md（これで十分）
- パッケージマネージャは pnpm
- Edge Functions のデプロイは supabase functions deploy <name>
- 多言語は lib/i18n/ の8ファイルを必ず同時に更新する
「特定の作業のときだけ要る知識」は Agent Skills（.claude/skills/） に逃がせ。Skillsは必要なときだけ読まれる。常に読ませるな。引かせろ。
CLAUDE.md は憲法。Skills は六法全書。違いが分からないなら、まずそこからだ。
ミス2. 1つの指示に作業を全部詰め込んでいる
「テスト直して、リファクタして、ドキュメントも更新して、ついでにPRも作って」
これをやった瞬間、Claudeは自分が何をしていたか見失う。 長いコンテキストの中盤は人間と同じで注意が薄くなる（lost in the middle）。お前は天才に向かって、全部の用事を一度に叫んでいる。混乱しないわけがない。
正解は、責務をサブエージェントに切り出すこと。
---
name: reviewer
description: 差分のバグだけを淡々と指摘する。実装はしない。
tools: Read, Grep, Bash
---
あなたはレビュー専任。修正提案ではなく「どこが・なぜ壊れるか」だけを返せ。
レビュー、テスト実行、i18nの8言語チェック——毎回同じ依頼はサブエージェント化した瞬間に世界が変わる。 メインの会話は指揮官に保て。手を動かすな、命令しろ。
ミス3. 実装の途中で /compact を打っている
コンテキストが膨らむと反射的に /compact していないか。それが事故の引き金だ。
圧縮の過程で「これから何をするつもりだったか」が要約に丸められて消える。再開したClaudeは、さっき自分で立てた設計を忘れ、半分だけ実装された土台の上に、別の実装を平気で重ねてくる。お前は気づかない。動いて見えるから。
-
/compactは作業の区切り（コミット直後）でだけ打て - 長い作業は最初に計画を
PLAN.mdに書き出させろ。コンテキストが飛んでも計画はディスクに残る
実装途中の手動 compact は「危ない手術」だ。安易に執刀するな。
ミス4. MCPサーバーを「全部盛り」で常時つないでいる
Slack、GitHub、Notion、ブラウザ、ファイル系——便利そうだから全部つなぎっぱなし。心当たりがあるだろう。
接続したMCPのツール定義は、それ自体がコンテキストを占有する。 今日使いもしないツール群が、毎ターンお前のトークンと判断力を削っている。
- 今日のタスクに必要な分だけつなげ。GitHubを触らない日にGitHub MCPは要らない
- 多数つなぎたいなら Deferred Tool Loading 対応を使え。スキーマを遅延ロードするので開始時の重さが消える
「とりあえず全部入れる」は2024年の発想。2026年は引き算だ。
ミス5. 設計まで丸投げしている
「いい感じにアプリ作って」
で出てくるのは、いい感じに見える地雷だ。
筆者は実際に踏んだ。SwiftネイティブのPushKitレジストリを let のローカル変数で受けるコードを書かれ、着信しない通話アプリが完成した。PKPushRegistry が解放されてプッシュが届かない。AIは「動くように見えるコード」を書くのが異常に上手い。だから寿命・所有権・スレッドの問題は平気ですり抜ける。
設計は人間。実装はAI。この境界を譲るな。
- 「何を作るか」「どういう構造か」はお前が決める。AIは「どう書くか」の高速な手足
- いわゆるループエンジニアリングで回せ。小さく投げる→検証→直す→また投げる。一発完成を狙うな
- ネイティブ層・並行処理・ライフサイクルが絡む箇所は、生成後に必ず人間が所有権とスレッドを目視しろ
ミス6. レビューを人間がサボっている
「AIが書いたから大丈夫」——逆だ。
生成速度が上がったぶん、レビューの重要性は上がっている。バグの絶対量は減らず、流入速度だけが上がるからだ。お前はバグを高速生成する装置を手に入れたのであって、品質保証を手に入れたわけではない。
- ミス1・2で作ったレビュー専任サブエージェントに一次レビューさせ、人間は最終確認に集中しろ
- diffは小さく保て。1000行のPRは人間もAIも誰もまともにレビューできない
- 「テストが通った」は「正しい」ではない。テストが何を保証していないかを毎回聞け
ミス7. 「同じ会話」を朝から晩まで引きずっている
1セッションで一日中作業を続ける。コンテキストは際限なく伸び、応答は少しずつズレ、トークンは静かに溶ける。それを「AIと深く対話している」と勘違いしている。
- タスクが変わったらセッションを切れ。 「Supabase関数を直す」と「i18nを足す」は別の脳でやれ
- 長期の文脈は会話ではなくファイル（CLAUDE.md / Skills / PLAN.md）に永続化しろ。会話は揮発、ファイルは不揮発
- 「会話を育てる」な。「仕組みを育てろ」。3ヶ月でいちばん効いた発想の転換がこれだった
結論
「コードを書く」から「タスクを委任する」へ。
委任先は、優秀だが3分で記憶を失う天才だと思って渡せ。
| よくある間違い | 正解 |
|---|---|
| CLAUDE.md を全部入りに | 最小限＋Agent Skills |
| 1指示に全作業を詰める | サブエージェントで責務分離 |
実装途中の /compact
|
区切りでのみ、計画はファイルへ |
| MCP全部盛り | 必要な分だけ＋遅延ロード |
| 設計まで丸投げ | 設計は人間、実装を委任 |
| レビューをサボる | レビュー専任エージェント＋小さいdiff |
| 同じ会話を延々使う | タスクで切る、文脈はファイルに |
7つのうち、いくつ刺さった。3つ以上なら、お前は今日まで確実に時間を捨てていた。今夜 CLAUDE.md を半分に削るところから始めろ。
筆者は今もこの7つを守りながら、Expo + Supabase + Swiftの通話アプリを個人開発している。「この罠を踏んだ」「自分はこう回避した」があれば、コメントで殴り返してくれ。その失敗談こそ、いちばんLGTMに値する知見だ。
刺さったなら LGTM とストックを。次は「Claude Codeでネイティブモジュールをデバッグした実録」を書く。