この記事のポイント
CLAUDE.mdはClaude Codeのメモリファイルであり、プロジェクトの規約やコマンドをセッション間で記憶させる仕組み
メモリは6種類の階層構造を持ち、エンタープライズポリシーからローカル設定まで用途に応じて使い分けられる
/initコマンドでコードベースを自動解析し、CLAUDE.mdの雛形を素早く生成できる
.claude/rulesディレクトリを活用すれば、テスト規約やAPI設計などトピックごとにルールをモジュール管理できる
CLAUDE.mdやメモリ機能はClaude Codeのサブスクリプションに含まれ、追加料金なしで利用可能(API認証の場合は従量課金)

Microsoft MVP・AIパートナー。LinkX Japan株式会社 代表取締役。東京工業大学大学院にて自然言語処理・金融工学を研究。NHK放送技術研究所でAI・ブロックチェーンの研究開発に従事し、国際学会・ジャーナルでの発表多数。経営情報学会 優秀賞受賞。シンガポールでWeb3企業を創業後、現在は企業向けAI導入・DX推進を支援。
「CLAUDE.mdって何を書けばいいの?」「Claude Codeのメモリ機能はどう使い分ければいい?」
Claude Codeを導入したものの、プロジェクトごとの設定や指示をどのように管理すべきか迷っている方は少なくありません。
CLAUDE.mdは、Claude Codeに対してプロジェクトの規約やコーディングスタイル、よく使うコマンドなどを記憶させるためのマークダウンファイルです。セッションをまたいで一貫した指示を維持できるため、チーム開発でも個人開発でも開発効率を大きく向上させます。
本記事では、CLAUDE.mdの基本から6種類のメモリの階層構造、/initコマンドによる自動生成、.claude/rulesを使ったモジュール管理、チーム運用のベストプラクティスまで、公式ドキュメントに基づいて徹底解説します。
✅Claude Code本体の詳細については、以下の記事で解説しています。合わせてご覧ください。
Claude Codeとは?主な特徴や使い方、料金体系・拡張機能まで徹底解説
目次
CLAUDE.mdとは?
CLAUDE.mdとは、Claude Codeがセッション開始時に自動で読み込むマークダウン形式の設定ファイルです。プロジェクトのコーディング規約、アーキテクチャの方針、よく使うビルドコマンドなどを記述しておくことで、Claude Codeがそれらを「記憶」した状態で作業を開始できます。
エンジニアにとってのREADMEが「人間向けのプロジェクト案内」であるのに対し、CLAUDE.mdは「AI向けのプロジェクト案内」として機能する点が大きな特徴です。一度設定すれば、新しいセッションを立ち上げるたびに同じ指示を繰り返す必要がなくなり、開発の効率と一貫性が大幅に向上します。
CLAUDE.mdが解決する課題
Claude Codeを使ったことがある方なら、セッションが切り替わるたびに「このプロジェクトではTypeScriptを使っている」「テストはJestで書く」「ビルドコマンドはnpm run buildである」といった前提条件を毎回伝え直す手間を感じた経験があるかもしれません。
CLAUDE.mdはこの課題を根本的に解決します。プロジェクトに関する指示を一箇所にまとめておけば、Claude Codeは起動時にそのファイルを自動的に読み込み、過去の文脈を把握した状態で作業を始められるのです。
以下の表で、CLAUDE.mdに記述する代表的な内容を整理しました。
| 記述カテゴリ | 具体例 |
|---|---|
| ビルド・テストコマンド | npm run dev、npm run test、make buildなど |
| コーディング規約 | 2スペースインデント、関数名はキャメルケースなど |
| アーキテクチャ方針 | App Router使用、コンポーネント設計パターンなど |
| 推奨ライブラリ | 状態管理にはZustand、HTTPクライアントにはaxiosなど |
| プロジェクト固有の注意事項 | 特定のディレクトリには触れない、非推奨APIの回避など |
ここで重要なのは、CLAUDE.mdの内容は具体的であるほど効果が高いという点です。「コードを適切にフォーマットする」のような曖昧な指示よりも、「2スペースのインデントを使用し、セミコロンは省略する」といった明確な指示のほうが、Claude Codeは正確に従うことができます。
CLAUDE.mdのメモリ階層構造
Claude Codeのメモリは、単一のファイルではなく6種類の階層構造で管理されています。このセクションでは、各メモリタイプの役割と使い分けを解説します。
組織全体の方針から個人の作業用メモまで、スコープの異なるメモリを適切に配置することで、チーム開発でも個人開発でも柔軟な運用が可能になります。
以下の表は、公式ドキュメントに基づく6種類のメモリタイプの一覧です。
| メモリタイプ | ファイルの場所 | 目的 | 共有範囲 |
|---|---|---|---|
| エンタープライズポリシー | macOS: /Library/Application Support/ClaudeCode/CLAUDE.md | IT/DevOpsが管理する組織全体の指示 | 組織内の全ユーザー |
| プロジェクトメモリ | ./CLAUDE.md または ./.claude/CLAUDE.md | プロジェクトのチーム共有指示 | ソース管理を通じたチームメンバー |
| プロジェクトルール | ./.claude/rules/*.md | モジュール化されたトピック固有の指示 | ソース管理を通じたチームメンバー |
| ユーザーメモリ | ~/.claude/CLAUDE.md | 全プロジェクト共通の個人設定 | 自分のみ(全プロジェクト) |
| プロジェクトメモリ(ローカル) | ./CLAUDE.local.md | 個人的なプロジェクト固有の設定 | 自分のみ(現在のプロジェクトのみ) |
| 自動メモリ(Auto memory) | ~/.claude/projects/<project>/memory/ | セッション中にClaude Codeが自動的に学習した内容を保存 | 自分のみ(プロジェクトごと) |
ここで注目すべきは、階層内で上位に位置するファイルほど優先度が高いという点です。エンタープライズポリシーが最も強い効力を持ち、その下にプロジェクトメモリ、ユーザーメモリと続きます。つまり、組織として守らなければならないルールは、個人やプロジェクトの設定によって上書きされることがない設計になっています。
また、自動メモリ(Auto memory)は、Claude Codeがセッション中に学んだパターンや設定を自動的に記録する仕組みです。ユーザーが明示的に指示しなくても、繰り返し使うコマンドやプロジェクト固有のパターンが蓄積されるため、使い込むほどClaude Codeの応答精度が向上していきます。
プロジェクトメモリとローカルメモリの使い分け
チーム開発において特に重要なのが、プロジェクトメモリ(./CLAUDE.md)とローカルメモリ(./CLAUDE.local.md)の使い分けです。
プロジェクトメモリはGitリポジトリにコミットしてチーム全体で共有するファイルです。コーディング規約やアーキテクチャの方針など、チーム全員が同じ前提で作業するための情報を記述します。
一方、ローカルメモリはGitの管理対象外となるファイルです。CLAUDE.local.mdは自動的に.gitignoreに追加されるため、個人の開発環境に固有の情報を安全に記述できます。
以下の表で、それぞれに記述すべき内容の具体例をまとめました。
| 分類 | プロジェクトメモリ(チーム共有) | ローカルメモリ(個人用) |
|---|---|---|
| コマンド | npm run build、npm run testなどの共通コマンド | 個人用のデバッグコマンドやエイリアス |
| 環境情報 | 本番環境のURLやデプロイ手順 | ローカルのサンドボックスURL、個人のテストデータ |
| コーディング規約 | プロジェクト全体のスタイルガイド | 自分だけが担当するモジュールの補足メモ |
| 作業メモ | アーキテクチャの意思決定記録 | 今日中にやるべきタスクリスト |
この使い分けにより、チームの統一性を保ちつつ、個人の作業環境も柔軟にカスタマイズできるというバランスの取れた運用が実現します。
ユーザーメモリの活用シーン
ユーザーメモリ(~/.claude/CLAUDE.md)は、プロジェクトをまたいで共通する個人的な設定を記述するファイルです。
たとえば「コミットメッセージは日本語で書く」「テスト結果は必ず表示する」「TypeScriptを優先する」といった、どのプロジェクトでも適用したい設定をここに書いておくと、すべてのプロジェクトで自動的に反映されます。
/initコマンドによるCLAUDE.mdの自動生成
CLAUDE.mdを一から手書きするのは手間がかかります。Claude Codeには/initコマンドが用意されており、既存のコードベースを解析してCLAUDE.mdの雛形を自動生成する機能があります。
/initコマンドの使い方
手順はシンプルです。プロジェクトのルートディレクトリでClaude Codeを起動し、対話モードで/initと入力するだけです。
cd your-project
claude
> /init
Claude Codeはプロジェクト内のファイル構成、package.json、Makefile、既存のREADMEなどを解析し、以下のような内容を自動的にCLAUDE.mdへ出力します。
- プロジェクト概要 フレームワーク、言語、主要ライブラリの情報
- ビルド・テストコマンド package.jsonのscriptsやMakefileから検出されたコマンド一覧
- ディレクトリ構造 主要なディレクトリとその役割の説明
- 開発上の注意点 設定ファイルやGitフックの情報
この自動生成は、あくまで出発点として活用するのが効果的です。生成されたCLAUDE.mdをそのまま使い続けるのではなく、プロジェクト固有のルールや注意事項を追記・修正していくことが推奨されています。
/initの出力をそのまま使わない方がよい理由
/initコマンドが生成するCLAUDE.mdは、コードベースの構造的な情報をよく拾う一方で、チーム内の暗黙知や設計上の意図までは捕捉できません。
たとえば「このディレクトリのファイルは自動生成されるので手動で編集しない」「APIのエラーレスポンスは必ずこのフォーマットに従う」といった情報は、人間が補足する必要があります。/initで生成された内容を確認し、足りない部分を加筆していくプロセスが、効果的なCLAUDE.md運用の第一歩です。
/memoryコマンドと自動メモリ機能
CLAUDE.mdを直接編集する以外にも、Claude Codeにはセッション中にメモリを操作するための便利な機能が2つ用意されています。それが/memoryコマンドと、#(ハッシュ記号)を使った自動メモリ機能です。
/memoryコマンドでメモリを直接編集する
セッション中に/memoryと入力すると、まずファイルセレクターが表示されます。ここには自動メモリのエントリーポイントやCLAUDE.mdファイルの一覧が表示され、編集したいファイルを選択するとシステムのデフォルトエディタ(VS Codeやvimなど)で開きます。現在読み込まれているメモリの内容を確認したり、新しい指示を追記したり、不要になった記述を削除したりできます。
/memoryコマンドは、CLAUDE.mdの内容を大幅に見直したい場合や、メモリの構成を整理したい場合に適しています。エディタ上で直接編集できるため、複数の箇所を一度に修正するような作業も効率的に行えます。
#ショートカットで素早くメモリを追加する
もう一つの方法が、入力欄で#(ハッシュ記号)に続けてメモリの内容を書く方法です。
# テストは必ずJestで書くこと
# コミットメッセージは日本語で記述する
この方法で入力すると、Claude CodeがCLAUDE.mdやCLAUDE.local.mdに素早くメモリを追加します。ちょっとしたルールや気づきをその場で記録したい場合に便利な機能です。
以下の表で、2つの方法の特徴を比較しました。
| 方法 | 操作 | 適したシーン |
|---|---|---|
| /memoryコマンド | ファイルセレクターでメモリファイルを選択し、エディタで編集 | 内容の大幅な見直し、複数箇所の修正、構成の整理 |
| #ショートカット | 入力欄で#に続けて記述 | ちょっとしたルール追加、作業中の気づきの即時記録 |
どちらの方法も、追加したメモリは次回以降のセッションで自動的に読み込まれます。つまり、一度設定すれば忘れることなく継続的に反映されるという点で、作業の一貫性を保つ上で非常に有効です。
CLAUDE.mdの効果的な書き方とベストプラクティス
CLAUDE.mdに何を書くかだけでなく、どのように書くかも重要です。このセクションでは、公式ドキュメントの推奨事項をもとに、効果的な書き方のポイントを解説します。
書くべき内容と書くべきでない内容
CLAUDE.mdに記述する情報は、Claude Codeの振る舞いに直接影響を与えるものに絞るのが原則です。
以下の表で、書くべき内容と書くべきでない内容を整理しました。
| 書くべき内容 | 書くべきでない内容 |
|---|---|
| 頻繁に使うビルド・テスト・リントコマンド | エディタの設定やOSの環境情報 |
| コーディング規約(インデント、命名規則など) | プロジェクトと無関係な一般的プログラミング知識 |
| プロジェクト固有のアーキテクチャパターン | すでにREADMEやpackage.jsonに書かれている情報の全文コピー |
| 注意が必要な制約や例外(触れてはいけないディレクトリなど) | 長大な仕様書や設計書の全文 |
| チームの開発フロー(ブランチ戦略、レビュー手順など) | 頻繁に変わるタスクリスト |
特に注意が必要なのは、CLAUDE.mdに詰め込みすぎないことです。Claude Codeはコンテキストウィンドウに制限があるため、メモリファイルが長大になるほど、個々の指示が無視されるリスクが高まります。
具体的で明確な指示を書く
公式ドキュメントでも強調されているのが、具体性の重要性です。
避けるべき書き方と推奨される書き方の例を以下に示します。
| 避けるべき書き方 | 推奨される書き方 |
|---|---|
| コードを適切にフォーマットする | 2スペースのインデントを使用し、セミコロンは省略する |
| テストをしっかり書く | 新しい関数にはJestでユニットテストを追加し、カバレッジ80%以上を目指す |
| 良いコミットメッセージを書く | コミットメッセージはConventional Commits形式(feat:、fix:など)で日本語で記述する |
曖昧な指示はClaude Codeの解釈に委ねられてしまうため、期待と異なる結果になることがあります。再現性のある具体的な指示を心がけることで、安定した出力が得られます。
構造化してメモリを整理する
メモリの内容は、マークダウンの見出しや箇条書きを活用して構造化するのが効果的です。
以下は、公式の推奨に基づいた構成例です。
# プロジェクト概要
Next.js 14(App Router)+ TypeScriptで構築されたコンテンツ管理システム
# コマンド
- ビルド: npm run build
- テスト: npm run test
- リント: npm run lint
# コーディング規約
- インデント: 2スペース
- 命名規則: 変数はキャメルケース、コンポーネントはパスカルケース
- インポート順: 外部ライブラリ → 内部モジュール → 型定義
# アーキテクチャ
- src/app/ 以下はApp Routerのルーティング
- src/components/ には再利用可能コンポーネント
- src/lib/ にはAPIクライアントやユーティリティ
# 注意事項
- public/generated/ 以下はビルド時に自動生成されるため手動編集禁止
- APIキーは環境変数で管理し、コードにハードコードしない
このように見出しで分類し、箇条書きで簡潔にまとめることで、Claude Codeが必要な情報を効率的に参照できるようになります。
定期的なレビューと更新
CLAUDE.mdは一度書いたら終わりではありません。プロジェクトの進化に合わせて、定期的に内容を見直すことが公式でも推奨されています。
たとえば、使わなくなったライブラリへの言及を削除する、新しく追加されたテストフレームワークの情報を追記する、変更されたブランチ戦略を反映するといった更新を定期的に行うことで、Claude Codeが常に最新の正確な情報に基づいて作業できるようになります。
.claude/rulesによるモジュール管理
プロジェクトが大規模になると、CLAUDE.mdが肥大化してしまうことがあります。この問題を解決するのが、.claude/rulesディレクトリを使ったモジュール化されたルール管理です。
.claude/rulesの基本構造
.claude/rulesディレクトリにマークダウンファイルを配置すると、Claude Codeはそれらを自動的にプロジェクトメモリとして読み込みます。公式ドキュメントによれば、これらのファイルは.claude/CLAUDE.mdと同じ優先度を持ちます。
以下は、典型的なディレクトリ構成の例です。
your-project/
├── .claude/
│ ├── CLAUDE.md # プロジェクト全体の指示
│ └── rules/
│ ├── code-style.md # コーディングスタイル
│ ├── testing.md # テスト規約
│ └── security.md # セキュリティ要件
この構成により、1つの巨大なCLAUDE.mdを維持する代わりに、トピックごとに分割されたファイルでルールを管理できます。各ファイルが1つのトピックに集中するため、更新や確認も容易になります。
パス固有のルール(paths指定)
.claude/rulesの大きな特徴の一つが、特定のファイルパスにのみ適用される条件付きルールを設定できることです。YAMLフロントマターでpathsフィールドを指定すると、Claude Codeがそのパターンに一致するファイルを操作しているときだけ、そのルールが適用されます。
以下は、TypeScriptファイルに対するAPI開発ルールの記述例です。
---
paths: src/api/**/*.ts
---
# API開発ルール
- すべてのAPIエンドポイントにバリデーションを含めること
- エラーレスポンスは標準フォーマットを使用すること
- OpenAPIドキュメントコメントを含めること
pathsフィールドでは標準的なグロブパターンがサポートされています。以下の表で代表的なパターンをまとめました。
| パターン | マッチ対象 |
|---|---|
| **/*.ts | 任意のディレクトリ内の全TypeScriptファイル |
| src/**/* | srcディレクトリ配下の全ファイル |
| *.md | プロジェクトルート直下のマークダウンファイル |
| src/components/*.tsx | componentsディレクトリ内のReactコンポーネント |
さらに、中括弧を使って複数のパターンを効率的に指定することもできます。たとえば src/**/*.{ts,tsx} と書けば、TypeScriptとTSXファイルの両方にマッチします。pathsフィールドを持たないルールは、すべてのファイルに無条件で適用されます。
サブディレクトリとシンボリックリンク
ルールファイルはサブディレクトリに分けて整理することも可能です。
.claude/rules/
├── frontend/
│ ├── react.md
│ └── styles.md
├── backend/
│ ├── api.md
│ └── database.md
└── general.md
すべての.mdファイルは再帰的に発見されるため、深い階層に配置しても自動的に読み込まれます。
また、.claude/rulesディレクトリはシンボリックリンクもサポートしています。複数のプロジェクトで共通するルールがある場合、共有ディレクトリへのシンボリックリンクを作成することで、ルールの一元管理が可能になります。
ユーザーレベルのルール
~/.claude/rules/に個人用のルールファイルを配置すると、すべてのプロジェクトに対して自分だけのルールを適用できます。ユーザーレベルのルールはプロジェクトルールよりも先に読み込まれ、プロジェクト側のルールがより高い優先度を持つ設計になっています。
CLAUDE.mdのインポート機能とメモリ検索の仕組み
CLAUDE.mdには、外部ファイルの内容を取り込むインポート機能が備わっています。また、Claude Codeがメモリをどのように検索・読み込むかを理解しておくと、大規模なリポジトリでの運用がよりスムーズになります。
@構文によるファイルインポート
CLAUDE.mdファイル内で @path/to/file という構文を使うと、指定したファイルの内容をインポートできます。
プロジェクトの概要は @README を参照してください。
利用可能なコマンドは @package.json を確認してください。
# Git運用ルール
- @docs/git-instructions.md
相対パスと絶対パスの両方が利用でき、ホームディレクトリからの相対パス(@~/...)も指定できます。たとえば、CLAUDE.local.mdの代わりに個人用の指示ファイルをインポートする形で運用すれば、複数のGitワークツリーをまたいだ個人設定の共有にも対応できます。
インポートされたファイルは再帰的にさらなるインポートを解決でき、最大5階層まで展開されます。なお、マークダウンのコードスパンやコードブロック内の@記述はインポートとして評価されないため、意図しない読み込みが発生する心配はありません。
メモリの再帰的検索
Claude Codeは起動時に、現在の作業ディレクトリからルートディレクトリに向かって再帰的に上方探索を行い、見つかったCLAUDE.mdまたはCLAUDE.local.mdをすべて読み込みます。
この仕組みは、モノレポのような大規模リポジトリで特に役立ちます。たとえば、リポジトリのルートにプロジェクト全体のCLAUDE.mdを置き、各サブディレクトリにより詳細なCLAUDE.mdを配置するという運用が可能です。
monorepo/
├── CLAUDE.md # リポジトリ全体の共通ルール
├── packages/
│ ├── frontend/
│ │ └── CLAUDE.md # フロントエンド固有のルール
│ └── backend/
│ └── CLAUDE.md # バックエンド固有のルール
さらに、サブディレクトリ以下にあるCLAUDE.mdは遅延読み込み(Lazy Load)で処理されます。起動時にすべてを読み込むのではなく、Claude Codeがそのサブツリー内のファイルを実際に操作するタイミングで初めて読み込まれるため、コンテキストウィンドウを効率的に活用できます。
チームでのCLAUDE.md運用方法
CLAUDE.mdはGitリポジトリにコミットしてチーム全体で共有できるため、チーム開発における運用設計が重要になります。このセクションでは、チームでの実践的な運用パターンと注意点を解説します。
Gitリポジトリでの管理戦略
チームでCLAUDE.mdを運用する際の基本戦略は、共有すべき情報とプライベートな情報を明確に分離することです。
以下の表で、各ファイルのGit管理方針をまとめました。
| ファイル | Git管理 | 理由 |
|---|---|---|
| ./CLAUDE.md | コミットする | チーム共通のルール・規約 |
| ./.claude/rules/*.md | コミットする | チーム共通のモジュール化ルール |
| ./CLAUDE.local.md | コミットしない(自動でgitignore) | 個人の環境固有情報 |
| ~/.claude/CLAUDE.md | 対象外 | 個人のグローバル設定 |
CLAUDE.local.mdはClaude Codeによって自動的に.gitignoreに追加されるため、誤ってコミットしてしまうリスクは低いといえます。しかし、個人のAPIキーやテスト用の認証情報などの機密情報は、CLAUDE.local.mdであっても記述を避け、環境変数として管理するのが安全です。
エンタープライズポリシーの活用
組織全体に適用するルールを徹底したい場合は、エンタープライズポリシー用のCLAUDE.mdを活用できます。macOSでは /Library/Application Support/ClaudeCode/CLAUDE.md に配置し、MDMやAnsibleなどの構成管理ツールで全開発者のマシンに配布します。
この方法は、たとえば以下のようなシーンで効果的です。
- セキュリティポリシー 機密データの取り扱いルールや禁止されたライブラリの指定
- コンプライアンス要件 ライセンスチェックの手順や社外公開時の注意事項
- コーディング標準 組織全体で統一する命名規則やコードフォーマット
エンタープライズポリシーは全メモリタイプの中で最も高い優先度を持つため、個々のプロジェクトやユーザーの設定によって上書きされることはありません。
チーム運用時の注意点
チームでCLAUDE.mdを共有する際に留意すべき点を、以下にまとめます。
- CLAUDE.mdの変更はプルリクエストで管理する
CLAUDE.mdはプロジェクトのルールを定義するファイルであり、変更がチーム全体の作業に影響します。通常のコードと同様に、変更時はプルリクエストを作成し、チームメンバーのレビューを経て反映することが望ましいです。
- 過度に長いCLAUDE.mdは避ける
Claude Codeのコンテキストウィンドウには制限があるため、CLAUDE.mdが長大になると一部の指示が無視される可能性があります。記述量が増えてきた場合は、.claude/rules/ディレクトリへの分割を検討してください。
- メンバーの個人設定を尊重する
CLAUDE.local.mdやユーザーメモリの内容はメンバーの裁量に委ねるのが基本です。チームで統一すべきルールはプロジェクトメモリに書き、個人の好みに関する設定はローカルメモリに任せるという線引きを明確にしましょう。
CLAUDE.mdの料金と利用条件
CLAUDE.mdやメモリ機能は、Claude Code本体のサブスクリプションに含まれる機能です。メモリの作成、編集、/initによる自動生成、/memoryによる編集、.claude/rulesの設定など、メモリ関連のすべての機能に追加料金は発生しません。ただし、環境変数にANTHROPIC_API_KEYを設定してAPI認証で利用している場合は、サブスクリプションではなくAPIの従量課金としてトークン消費が発生します。
Claude Codeの料金プラン
CLAUDE.mdを利用するには、Claude Codeが使える有料プランへの加入が必要です。以下の表に、2026年2月時点の主要なプランをまとめました。
| プラン | 月額料金 | Claude Codeの利用 | 利用枠の目安 |
|---|---|---|---|
| Pro | 月額20ドル(年払いの場合は月額17ドル) | 利用可能 | 5時間ごとの利用枠 + 週次制限あり |
| Max 5x | 月額100ドル | 利用可能 | Proの5倍の利用枠 |
| Max 20x | 月額200ドル | 利用可能 | Proの20倍の利用枠 |
| Team(Standard) | 1ユーザーあたり月額25ドル(年払いの場合は月額20ドル) | チーム管理機能付きで利用可能 | Proの1.25倍の利用枠 |
| Team(Premium) | 1ユーザーあたり月額125ドル(年払いの場合は月額100ドル) | チーム管理機能付きで利用可能 | Proの6.25倍の利用枠 |
| API従量課金 | 使用量に応じた課金 | 利用可能 | トークン単位の課金 |
出典: Claude 公式料金ページ、AI総合研究所 Claude Code料金ガイド
ここで注意すべきは、Claude Codeの利用枠は通常のClaudeチャットやResearch機能と共有されるという点です。Claude Code上でのやり取りが多い場合は、チャット側の利用枠にも影響が出ることがあるため、利用頻度に応じたプラン選定が重要になります。
Anthropicの統計によれば、Claude CodeのAPIトークン消費量は1日あたり平均約6ドル相当で、90%のユーザーが1日あたり12ドル以下に収まっているとされています。この数値はAPI従量課金で利用する場合の参考値であり、サブスクリプションプランの利用者に対する直接の請求額ではありません。
【関連記事】
▶︎Claude Codeの料金体系ガイド!利用制限や確認・可視化方法を解説【2026年版】
▶︎Claudeの料金プラン徹底比較!無料・有料版の違いと選び方【2026年最新】
まとめ
本記事では、Claude CodeのCLAUDE.mdとメモリ管理について、基本概念からチーム運用まで包括的に解説しました。
CLAUDE.mdは、単なる設定ファイルではなく、Claude Codeとの協働を効率化するためのプロジェクトの知識基盤です。ここで改めて、本記事の要点を整理します。
- CLAUDE.mdの基本的な役割
Claude Codeが起動時に自動で読み込むメモリファイルであり、プロジェクトの規約やコマンド、アーキテクチャの方針をセッション間で一貫して維持できます。/initコマンドで雛形を自動生成し、プロジェクトに合わせて加筆していくのが効率的な始め方です。
- 6種類のメモリ階層を適切に使い分ける
エンタープライズポリシー、プロジェクトメモリ、プロジェクトルール、ユーザーメモリ、ローカルメモリ、自動メモリの6つを目的に応じて配置することで、組織・チーム・個人それぞれのレベルで最適な指示管理が実現できます。
- チーム開発ではGit管理と分割運用が鍵
CLAUDE.mdをGitリポジトリにコミットしてチーム全体で共有し、個人設定はCLAUDE.local.mdに分離する。プロジェクトが大規模になったら.claude/rulesでトピック別にモジュール化する。このような運用設計が、チーム開発でのClaude Code活用をより効果的にします。
CLAUDE.mdの活用は、Claude Codeの能力を引き出す上で最も基本的かつ重要なステップの一つです。まずは/initコマンドで雛形を生成し、プロジェクトの実情に合わせて少しずつ育てていくことから始めてみてください。










