Claude Codeで開発速度を3倍にした7つの設定術——「なんとなく使う」から「仕組みで使う」へ
「とりあえず動かす」から「仕組みで動かす」へ
Claude Codeを導入したけれど、「思ったより出力がブレる」「長い会話になると指示が伝わらない」——そういう感想を持っている開発者は少なくないはずだ。
Qiitaに投稿されたlocallabの記事は、まさにそこを出発点にしている。対象読者を「Claude Codeを導入済みだが、なんとなく使っている状態から抜け出せていないエンジニア」と明示したうえで、開発速度を3倍にした7つのテクニックを具体的なコマンドと設定例つきで解説している。
重要なのは、これが「Claudeをもっと賢く使う話」ではないということだ。どんな文脈でエージェントを動かすか、どこまで権限を与えるか——そちらの設計の話だ。そしてその設計の巧拙が、生産性を大きく左右する。
7つのテクニック：事実の整理
内容を順番に整理しておく。
1. CLAUDE.mdでプロジェクト固有の文脈を注入する
Claude CodeはリポジトリルートにCLAUDE.mdがあると自動的に読み込み、セッション全体のコンテキストとして扱う。言語（TypeScript strict）、フレームワーク（Next.js 15 App Router）、よく使うコマンド（pnpm dev、pnpm test:unit）などをここに書いておけば、毎回「TypeScript strictで」と伝えなくて済む。CLAUDE.mdはネストにも対応しており、src/CLAUDE.mdにフロントエンドのルール、server/CLAUDE.mdにバックエンドのルールを分けて書くことができる。
2. –allowedToolsでエージェント権限を最小化する
デフォルトではファイル読み書き・シェル実行・WebFetchなど多くのツールが有効になっている。これを--allowedTools "Read,Write,Glob,Grep"のように絞ることで、意図しない副作用を防ぐ。レビュー・調査系タスクでは--allowedTools "Read,Glob,Grep"として書き込み権限ごと外してしまうと、確認前にファイルが変わっていたという事故がなくなる。
3. –printフラグでパイプラインに組み込む
-pフラグをつけると対話モードに入らず、回答を標準出力に書いて終了する。git diff --staged | claude -p "Conventional Commits形式でコミットメッセージを1行で書いて"のように、他のコマンドとパイプでつなぐことができる。CIの失敗ログをSlackに流す前に要約させたり、PRテンプレートへの自動入力にも使える。
4. 長いタスクはサブゴール分割で指示する
「AとBとCをやって」と一度に頼むと途中で迷走しやすくなる。代わりにチェックリスト形式でサブゴールを渡し、「各ステップが完了したら完了と報告してから次に進んでください」の一言を添える。これだけでエージェントが暴走せず、人間が途中で確認・中断できる余地が生まれる。
5. important-instruction-remindersブロックで強調する
CLAUDE.md内に専用ブロックを設けることで、「既存のテストを削除しない」「any型を使わない」「console.logをコミットしない」といったルールを通常の指示文と分離して視認性を高める。Anthropicの公式ドキュメントでも推奨されているパターンだ。
6. ヘッドレスモード＋Git worktreeで並列作業する
--dangerously-skip-permissionsフラグと-pを組み合わせ、Gitのworktreeを2つ作ることで独立したタスクを同時実行できる。「決済モジュールにユニットテストを追加」と「i18nのja.jsonに欠けているキーをen.jsonから補完」を並列で走らせる、といった使い方だ。ただし--dangerously-skip-permissionsは名前の通りリスクがある。独立したworktree内での使用＋変更内容をレビューしてからマージ、が運用の前提になる。
7. カスタムスラッシュコマンドでよく使う指示を再利用する
~/.claude/commands/または.claude/commands/以下に*.mdを置くと、セッション内で/コマンド名として呼び出せる。.claude/commands/review.mdにレビュー観点（TypeScriptの型安全性、不要な再レンダリング、エラーハンドリングの漏れ、テストカバレッジの不足）を書いておけば、/reviewと打つだけで毎回同じ観点でレビューが走る。.claude/commands/をGitで管理すればチームでレビュー観点を標準化できる。
ここからは見方の話：「AIの賢さ」より「文脈設計」が競争軸
この記事を読んで感じるのは、Claude Codeそのものの性能ではなく、エージェントをどういう文脈に置くかの設計力が、生産性の差を生んでいるという構造だ。
CLAUDE.mdにプロジェクトの前提を書く行為は、見方を変えると「チームの暗黙知を明文化する作業」だ。「うちのプロジェクトはnamed exportで統一、コンポーネントはsrc/components/以下」——これは普通であれば口頭かREADMEに書かれて埋もれる情報だ。CLAUDE.mdに書くことで、AIだけでなく新メンバーへのオンボーディング資料にもなる。
important-instruction-remindersブロックも同様だ。「テストを消すな」「anyを使うな」というルールは、本来コードレビューで毎回指摘するものだ。それをエージェントへの指示として構造化する過程で、チームが守るべきルールが整理されていく。AIへの設定整備が、開発文化の整備を副産物として生む——これは結構面白い逆説だと思っている。
一方で、期待値の調整も必要だ。「開発速度3倍」という数字はインパクトがあるが、これはCLAUDE.mdもなく、都度プロンプトを書き直していた状態と比べた場合の話だろう。ゼロから整備するコストは最初にかかる。CLAUDE.mdを適切に書くには、プロジェクトの構造をそれなりに整理できていることが前提になる。整理されていないプロジェクトに導入しても、混乱をAIが増幅するだけになりかねない。
実務的な示唆：何から始め、何に気をつけるか
導入順序について言うと、記事の著者が「まずCLAUDE.mdの整備から始めて」と言っているのは正しい判断軸だと思う。理由は2つある。
ひとつは、CLAUDE.mdの整備はツールの追加コストなしにできること。もうひとつは、ここで書く内容がそのまま他のテクニック（サブゴール分割の書き方、important-instruction-reminders）の土台になること。先にworktree並列実行を試しても、文脈設定がなければ並列に迷走するだけだ。
--dangerously-skip-permissionsの扱いには注意が必要だ。名前にわざわざ"dangerously"と入れているあたり、Anthropic自身もリスクを認識している。並列実行の前に「共有ファイルに同時書き込みするタスクは並列化しない」設計が必要で、これはタスク分割の設計力を問う。
今後の論点：個人最適がチーム複雑性になるとき
ここが次に問われるところだと見ている。
.claude/commands/をGitで管理してチームで共有するのは理にかなっているが、「レビュー観点のアップデートは誰が判断するのか」「CLAUDE.mdの更新フローはどうするのか」という運用の問いが出てくる。個人が自分のプロジェクトでCLAUDE.mdを整備するのは簡単だが、5人のチームで誰がどのタイミングで更新し、それをレビューするのかは別の話だ。
さらに言えば、エージェントへの権限設計——--allowedToolsで何を許可し何を禁止するか——は、組織のセキュリティポリシーに接続する問題でもある。個人開発者がローカルで試す分には自己責任で済むが、CI/CDパイプラインにClaudeを組み込む場合は「どのツール権限を誰が管理するか」を明示的に決める必要が出てくる。
「AIエージェントの権限設計」という概念が、インフラのIAM設計と同じように当たり前に語られる日は、そう遠くないと思っている。
まとめに代えて
Claude Codeを「賢いペアプログラマー」として使うには、どんな文脈に置くか・どこまで権限を与えるかの整備が先に来る。CLAUDE.mdで文脈を渡し、--allowedToolsで権限を絞り、サブゴール分割で長タスクを管理する。この3つだけでも、「なんとなく使っている」状態からは大きく変わるはずだ。
次に似たようなAIコーディングツールの記事を見るとき、見るべき軸がひとつ増える。「ツールが何をできるか」ではなく、「どうやって文脈とルールを渡す仕組みを設計しているか」——そこに実際の生産性の差がある。
