株式会社BlueAI 代表取締役CEO / ソフトウェアエンジニア / プロダクトエンジニア / Google Cloud Architect / 元AIスタートアップ(Doorkel)
サイト改善のため、同意した場合だけGoogle AnalyticsとPostHogを読み込みます。拒否しても、学習コンテンツとお問い合わせは利用できます。詳細
株式会社BlueAI 代表取締役CEO / ソフトウェアエンジニア / プロダクトエンジニア / Google Cloud Architect / 元AIスタートアップ(Doorkel)

Claude Code の使い方を基本操作から実践テクニックまで解説。効果的なプロンプトの書き方、ファイル操作、Git 連携など、すぐに使えるノウハウを紹介します。
Claude CodeでCSV・Excelを安全に集計する実務手順。元ファイルを守り、欠損・重複・金額型を確認し、計画・処理・検算を分けて営業週報を作ります。

Claude Codeで使えるスラッシュコマンドとキーボードショートカットを一覧で解説。/init、/context、/compact、/usageなどの使い方を紹介します。
用途・コマンド・安全ルールを選び、プロジェクト指示のたたき台をブラウザ内で生成します。
CLAUDE.mdは、Claude Codeがプロジェクトで作業するときに参照する指示ファイルです。毎回説明しているプロジェクトの目的、重要な構成、テストコマンド、完了条件をここへまとめると、依頼の前提をそろえやすくなります。
ただし、長いルールを大量に書けば精度が上がるわけではありません。Anthropic公式ドキュメントは、プロジェクトのCLAUDE.mdを簡潔に保ち、目安として200行未満にすることを案内しています。作業中に判断を変える情報だけを書くのが基本です。
すぐ作りたい場合は、無料のCLAUDE.mdジェネレーターを使えます。入力内容はブラウザ内だけで処理され、サーバーへ送信・保存されません。
解説重要:
CLAUDE.mdはClaude Codeへの指示であり、強制的な権限制御ではありません。秘密ファイルや危険なコマンドは、permissions、sandbox、OS・アカウント権限で別に制御してください。
最初は次の5項目だけで十分です。
# Project instructions
## Purpose
- このプロジェクトは、顧客向けFAQサイトです。
## Working area
- 主な実装は `app/` にあります。
- 生成物の `dist/` は直接編集しないでください。
## Commands
- テスト: `bun test`
- 型チェック: `bun run typecheck`
- ビルド: `bun run build`
## Completion criteria
- 既存仕様を変えず、対象Issueを満たすこと。
- 変更に関係するテスト、型チェック、ビルドを実行すること。
- 最後に変更内容、検証結果、未確認事項を報告すること。
## Safety
- `.env`、秘密鍵、顧客データを読まない・出力しないこと。
- 削除、公開、本番変更は明示的な承認なしに実行しないこと。実際に存在しないコマンドは書かないでください。Claude Codeへ理想の工程を伝えるより、このリポジトリで再現できる工程を伝える方が役立ちます。
Anthropic公式ドキュメントでは、プロジェクトの指示をリポジトリ直下の./CLAUDE.mdまたは./.claude/CLAUDE.mdに置けます。組織、ユーザー、プロジェクト、ローカルなど複数のスコープがあり、用途ごとに共有範囲が異なります。
| 目的 | 置き方の考え方 |
|---|---|
| リポジトリ全体で共有 | ルートのCLAUDE.mdをレビューしてコミット |
.claude/へ設定を集約 | .claude/CLAUDE.mdを利用 |
| サブディレクトリ固有 | 必要な範囲へ小さな指示を追加 |
| 個人だけの一時的な補足 | 共有ファイルと混ぜず、公式のローカルスコープを確認 |
/initでたたき台を作成し、/contextで読み込まれたメモリを確認できます。生成された内容は必ず人がレビューし、一般論と重複を削ってください。
# Web application
## Architecture
- React Router + TypeScriptで構成されています。
- ルートは`app/routes.ts`、画面は`app/routes/`にあります。
- 共通UIは既存コンポーネントを優先してください。
## Change policy
- 依頼に関係しないリファクタリングを含めないでください。
- 既存のレスポンシブ表示とキーボード操作を維持してください。
- 新しい依存関係は、必要性を説明してから追加してください。
## Verification
1. 変更箇所のテスト
2. `bun run typecheck`
3. `bun run build`
4. 対象画面のPC・モバイル確認
## Report
- 変更ファイル、ユーザーへの影響、検証結果を報告してください。
- 実行できなかった検証は理由と手順を残してください。この例の価値はフレームワーク名より、変更方針と検証順が明確なことです。実プロジェクトのコマンドに置き換えてください。
# Data processing workspace
## Goal
- `input/`のCSVから集計結果と検算レポートを作成します。
## Data rules
- `input/`の元ファイルを変更・上書きしないでください。
- 出力は`output/`へ新規作成してください。
- 欠損、重複、文字コード、日付・金額型を処理前に確認してください。
## Privacy
- 個人情報や顧客識別子を結果・ログへ出力しないでください。
- 想定外の機密項目を見つけた場合は処理を止めて報告してください。
## Verification
- 入力行数、除外行数、出力行数を記録してください。
- 合計値を別計算で照合し、差分があれば完了にしないでください。
- 仮定と未確認事項を`output/REPORT.md`に残してください。実際の集計手順は、
で確認できます。
# Content workspace
## Purpose
- 公式資料を基に、社内レビュー用の下書きを作成します。
## Source policy
- `sources/`にある資料だけを事実の根拠にしてください。
- 推測は「仮説」、確認できない内容は「要確認」と明記してください。
- 数字、日付、固有名詞には根拠ファイルを付けてください。
## Writing rules
- 読者、目的、次の行動を冒頭で明確にしてください。
- 根拠のない最上級表現や成果保証を書かないでください。
- 既存文の長い転載を避け、自分の言葉で要約してください。
## Completion criteria
- 主張と根拠の対応表を作ること。
- 人が確認すべき箇所を最後に一覧化すること。部門別にすぐ使える依頼文は、無料の部門別プロンプト・テンプレート集にも用意しています。
# Team development rules
## Scope
- Issueに記載された範囲だけを変更してください。
- 既存のユーザー変更と競合した場合は上書きせず報告してください。
## Git
- 作業前後に`git status`と`git diff`を確認してください。
- 依頼なしにpush、merge、rebase、履歴改変をしないでください。
- 生成物、秘密情報、大容量ファイルをコミットしないでください。
## Quality gates
- 既存パターンを優先し、変更理由を差分で説明してください。
- テスト、型チェック、lint、ビルドのうち関連するものを実行してください。
- 失敗を隠さず、再現コマンドと影響を報告してください。
## Review handoff
- 何を変えたか
- なぜこの設計にしたか
- 何を検証したか
- 残るリスクと次に確認すること「高品質なコードを書く」「ベストプラクティスに従う」だけでは、作業中の判断に使えません。どのコマンドを実行し、何を合格とするかへ置き換えます。
過去のツールや別ブランチのコマンドが残ると、失敗や誤修正の原因になります。CI設定やpackage.jsonと一致させてください。
APIキー、パスワード、実在する顧客データを記載しません。秘密情報の参照方法が必要でも、変数名と管理方法だけを書き、値は秘密管理へ置きます。
「絶対に.envを読まない」と書くことは補助になりますが、強制ではありません。
を参照し、permissions.denyなどの境界を実装してください。
複数階層のCLAUDE.md、個人設定、組織設定に同じルールを重複させると、更新漏れが起きます。正本を決め、月1回または大きな構成変更時に棚卸しします。
CLAUDE.mdだけに依存していない/contextなどで読み込み状態を確認した白紙から作る必要はありません。CLAUDE.mdジェネレーターでたたき台を作り、実際のリポジトリと照合してから利用してください。