AI Lab
記事一覧に戻る
プロンプト・活用術

CLAUDE.md 完全ガイド — 副業エンジニアが「毎回同じ指示」を一度で済ます設定術

Claude Codeで毎回同じ指示を打ち込んでいませんか。CLAUDE.mdに一度書けば、その手間がまるごと消えます。副業エンジニア向けに3パターンのテンプレと、Anthropic社員も使う実践テクをまとめました。

AI Lab編集部2026年5月22日16 min read
#Claude Code#副業エンジニア#プロンプト設計#AI開発#効率化

Key Points

  • 1CLAUDE.mdはClaude Codeがセッション開始時に自動で読み込む「プロジェクト記憶」ファイル。毎回の前置きが要らなくなる
  • 2受託開発・個人開発・学習用の3パターンのテンプレをまるごと配布。コピペして使える内容
  • 3「成功基準を先に書く」「禁止事項を明示」など、Anthropic社員も実践している中級テクを5つ紹介

この記事を読むとわかること

副業でClaude Codeを使っていると、毎セッションの冒頭に「TypeScriptで書いて」「テストは必ず書いて」「コメントは日本語で」と同じ指示を打ち込んでいませんか。私もしばらくその状態で、塵も積もれば結構な時間を使っていました。

その繰り返しを撲滅するのが CLAUDE.md です。プロジェクトのルートに一度だけ置けば、Claude Codeは起動時に自動で読み込み、文脈として記憶してくれます。この記事では、副業エンジニアがすぐに使える3パターンのテンプレと、効果を最大化するコツをまとめました。

CLAUDE.md とは何か？ ── 30秒でわかる正体

CLAUDE.md は「Claude Codeに毎回読ませる、プロジェクト専用の取扱説明書」です。セッションを開始した瞬間にClaudeが勝手に読み込み、その内容を前提として会話が始まります。つまり、自分が書いたルールを“常駐”させられるわけです。

技術的にはただのMarkdownファイル。プロジェクトのルートに CLAUDE.md というファイル名で保存しておくだけで効きます。1行でもいいし、200行書いても構いません。

どんなことが書けるのか

書ける内容に厳密な決まりはありません。私は次の4ジャンルを軸にしています。

  • プロジェクト概要（何のためのコードか、技術スタック）
  • コーディングルール（命名規則、エラーハンドリングの方針）
  • やってほしいこと/やらないでほしいこと
  • 成功基準（「テストが全部通ればOK」のような完了条件）

逆に、ライブラリのバージョンや一時的な作業メモは書かないほうがいい。すぐ古くなって、それがClaudeに伝わり続けると逆効果になります。

なぜ「毎回同じ指示」を撲滅できるのか？

Claude Code は新しいセッションのたびにメモリがリセットされる仕様です。前回どんなプロジェクトを触っていたか、どんなルールを共有したかは持ち越されません。これがCLAUDE.mdの存在理由です。

「毎セッションで同じ指示を打ち直す代わりに、永続化されたメモリとして渡してしまう」── これだけのことなんですが、副業のように細切れの時間で作業する人ほど効果が大きい。ログインしてすぐ本題に入れます。

私の体感では、CLAUDE.mdを整備したプロジェクトとそうでないプロジェクトでは、最初の30分の進捗が全然違います。前者だと「いきなり本実装」、後者だと「まず説明する」から始まる。この差はバカにできません。

副業案件別・CLAUDE.md テンプレ3パターン

ここから実用パートです。副業エンジニアが直面しがちな3つのシチュエーション別に、そのまま使えるテンプレを置きます。コピペして、自分の案件に合わせて1〜2行いじれば動きます。

パターン1: 受託開発（クライアントワーク）

クライアントから引き渡されたコードベースで、納期付きで仕様を実装するタイプの案件。客先のルールを最優先したいので、「規約に従う」「勝手にライブラリを足さない」という縛りを強めに書きます。

# プロジェクト概要

クライアントA社の社内管理ツール改修案件。
技術スタック: Next.js 15 (App Router), TypeScript, Prisma + PostgreSQL

# 厳守ルール

- 既存のESLint/Prettier設定に従う。設定ファイルは絶対に変更しない
- 新規ライブラリの追加は事前確認なしに行わない
- 既存のディレクトリ構造を踏襲する
- コミットメッセージは英語、Conventional Commitsに従う

# やってほしいこと

- 変更前に該当ファイルを必ず読んでから編集
- テストがあるファイルは、変更後にテストを実行
- 影響範囲が広そうな変更は、先に提案してから着手

# やらないでほしいこと

- リファクタリングを「ついでに」しない（依頼範囲外）
- console.logを残さない
- 型をanyで逃げない

# 完了の定義

- pnpm test が緑であること
- pnpm typecheck が緑であること
- 該当機能を手動で動かして動作確認

ポイントは「やらないでほしいこと」を明示することです。Claudeは親切なので、頼んでもいないリファクタを始めることがあります。受託では基本的にスコープ外の変更がトラブルの元なので、これで抑えます。

パターン2: 個人開発（自分のサービス）

自分で運営しているサービスや、これから出すSaaSのコードベース。自由度が高い分、Claude側に裁量を渡してもいい。「目的を達成すれば手段は任せる」のスタンスで書きます。

# プロジェクト概要

個人開発中のメモアプリ「FlowNote」。
スタック: SvelteKit + Cloudflare D1。
ユーザー数: まだいない（夢はある）

# 設計の原則

- とにかくシンプルに。10行で済むなら10行
- 早すぎる抽象化を避ける。同じパターンが3回出てから関数化
- 外部ライブラリより、ブラウザ標準APIを優先

# Claude に期待する役割

- 設計の壁打ち相手。複数案あれば全部出して、トレードオフを言って
- 仕様の穴を遠慮なく指摘してほしい
- ボイラープレートは書いてOK、創造的な部分は私が決める

# 成功基準

- 「動く・読める・後で直せる」が満たされていればOK
- パフォーマンスは現状気にしない
- テストは「複雑なロジック」にだけ書く（カバレッジは追わない）

個人開発では「テスト全部書け」と命令しすぎると、Claudeが過剰に丁寧になって時間がかかります。「複雑なロジックにだけ書く」と書いておくと、適度に手を抜いてくれます。

パターン3: 学習用（写経・素振りプロジェクト）

「Rustに入門してみたい」「自分でWASMコンパイラを書いてみたい」みたいな、収益関係なしの学習プロジェクト用。ここでは「答えを先に出さないでほしい」が最重要です。

# プロジェクト概要

Rustの所有権を体で覚えるための練習リポジトリ。
私はRust初心者です。TypeScript歴は5年。

# 学習方針

- 答えを最初から書かないでほしい
- 私がコードを書く → Claudeがレビューする、の流れを基本にする
- エラーが出たら、「答え」ではなく「ヒント」をまず出す
- 概念の説明はTypeScriptとの対比で

# 説明スタイル

- 専門用語は初回だけ英語併記
- コード例は短く、1ファイル30行以下
- 「なぜそうなるか」を必ず添える

# やらないでほしいこと

- 私が書いたコードを勝手に書き直さない
- 高度な機能（マクロ等）を最初から使わない

このタイプはClaudeを家庭教師のように使う設定です。「答えを書かない」と書くだけで、学習効率がだいぶ変わります。

CLAUDE.md の効きを倍にする5つのコツ

テンプレを置いただけだと、実は効果は半分。実際に使ってみて気づいた、効きを上げる小ワザを書きます。Anthropicの中の人が記事や登壇で言っていた内容も混ぜています。

1. 「成功基準」を先に書く

意外にこれが効きます。「このファイルを編集して、この関数を追加して」と手順を細かく書くより、「テストが全部通ればOK」「ユーザーがログインできればOK」のように完了条件を渡したほうが、Claudeは自律的に動きます。

手順を書きすぎるとClaudeが「手順をなぞる」モードになって、抜け漏れに弱くなる傾向があります。

2. ネガティブ指示は具体的に

「丁寧に書いて」より「コメントは関数1個につき最大1行」のほうが効きます。「シンプルに」は曖昧すぎてClaudeに伝わりません。私はネガティブ指示には数字や具体例を必ず入れるようにしています。

3. 長くしすぎない

CLAUDE.mdを200行とか300行に膨らませると、逆に重要なルールが埋もれます。私の経験では50〜80行が一番効率がいい。長くなりそうな部分は別ファイルにして、CLAUDE.mdから参照させるほうが効きます。

4. 言語は思い切って混ぜていい

「日本語で書け」と思いがちですが、技術用語は英語のままが正確に伝わります。「TypeScript: prefer functional components」みたいに、日本語の中に英語の指示句を混ぜると、Claudeの理解が安定します。

5. 月1回は見直す

これは地味ですが大事。プロジェクトが進むとルールも変わります。「もう不要になった指示」がCLAUDE.md内に残っていると、ノイズになってClaudeを混乱させます。月初に5分、CLAUDE.mdを見直す時間を作るだけで全然違います。

CLAUDE.md でよくある失敗と対処法

最後に、私が踏んだ落とし穴をシェアします。多分多くの人が同じところで詰まります。

よくある失敗何が起きるか対処
指示が抽象的すぎるClaudeが解釈を選び、毎回ブレる具体的な数字・例で書き直す
矛盾するルールを書くどっちかを無視される月1の見直しで整理する
プロジェクト固有の前提を書き忘れる一般論で答えてくる「私のスタック」「私の制約」を冒頭に書く
バージョン番号を書きすぎる古くなって誤情報になるバージョンは最低限。具体策は別ドキュメントへ

私が一番やらかしたのは「TypeScriptで書いて」とだけ書いて、「ESM縛り」を書き忘れたパターン。Claudeが当然のようにrequire構文を使ってきて、ビルドが通らない。あとから「あ、書いてなかった」と気付くやつです。

CLAUDE.mdは「Claudeに伝わっていない前提=書き忘れている前提」だと思って、気付いた時に追記する癖をつけるといいです。

まとめ

要点を整理します。

  • CLAUDE.md はClaude Codeが起動時に自動で読み込むプロジェクト記憶ファイル
  • 毎セッションで同じ指示を打ち直すコストがゼロになる
  • 受託開発・個人開発・学習用で書くべきことは大きく違う
  • 「成功基準」「禁止事項の具体化」「定期見直し」の3点で効きが倍になる

副業エンジニアにとって、CLAUDE.md整備は単なる効率化ツールではなく、限られた時間の使い方を変えるレバーです。まずは今ある副業案件のリポジトリに、20行でいいので置いてみてください。次のセッションから「もう前置きが要らない」体験ができます。

そこからは自分のスタイルに合わせて足し算引き算するだけ。3ヶ月使い込めば、自分専用の最強CLAUDE.mdが出来上がります。

よくある質問

Q. CLAUDE.md は手で書かないとダメですか？ A. いいえ、Claudeに「このプロジェクト用のCLAUDE.mdを書いて」とお願いすればドラフトを作ってくれます。私はそれをベースに30%くらい手で直す運用です。

Q. グローバル設定（全プロジェクト共通のルール）は書けますか？ A. ~/.claude/CLAUDE.md に置けば、全プロジェクトで読まれます。私は「日本語で答えて」「コミットメッセージは英語」など共通ルールはこちらに置いています。

Q. チーム開発でも使えますか？ A. むしろチームで効きます。CLAUDE.mdをGitに含めておけば、メンバー全員が同じルールでClaudeを動かせる。レビューの揺れも減ります。