.claude/ フォルダの中身を解剖する――AIアシスタントに「文脈」を渡す仕組み

---

1. イントロダクション

Claude（クロード）というAIアシスタントをご存じでしょうか。Anthropic社が開発したこのAIは、コードを書いたり、文章を整理したり、複雑な問題を一緒に考えたりと、さまざまな場面で活用されています。

そのClaudeを使いこなすうえで、最近注目を集めているのが .claude/ フォルダという仕組みです。名前に「ドット」がついていて少し不思議に見えますが、これはプロジェクトのフォルダの中に置く、小さな設定ファイルの入れ物です。

このフォルダを使うと、「このプロジェクトではどんな言葉遣いをしてほしいか」「どんな制約を守ってほしいか」「どんな背景知識を前提にしてほしいか」といった情報をClaudeに事前に伝えることができます。

毎回同じ説明を繰り返さなくて済む、チームで同じルールを共有できる――そんな実用的なメリットから、エンジニアだけでなく、AIを業務に取り入れようとしている非エンジニアの方々にも関心が広がっています。

この記事では、.claude/ フォルダの構造と役割を、専門知識がなくても理解できるように丁寧に解説していきます。

---

2. 基礎知識・用語解説

まず、この記事を読み進めるうえで必要な言葉をいくつか整理しておきましょう。

「ドットフォルダ」とは何か

ファイル名やフォルダ名の先頭に .（ドット）がついているものは、一般的に隠しフォルダ・隠しファイルと呼ばれます。普段のファイル一覧には表示されないことが多く、設定情報や内部的なデータを格納するために使われます。.claude/ もこの慣習に従った名前です。

「コンテキスト（文脈）」という概念

AIに何かを依頼するとき、AIは「今どんな状況で、何を求められているか」を理解しようとします。この「状況の理解」を支える情報のことを、AI分野ではコンテキスト（文脈）と呼びます。たとえば「このプロジェクトはECサイトの開発で、言語はPythonを使っている」という情報があれば、AIはより的確な回答を返せます。

「プロジェクトルート」とは

ソフトウェア開発では、ひとつの仕事（プロジェクト）に関連するファイルをまとめたフォルダがあります。そのフォルダの一番上の階層をプロジェクトルートと呼びます。.claude/ フォルダは、このプロジェクトルートに置くことが想定されています。

「CLAUDE.md」ファイルとは

.claude/ フォルダの中でも特に重要なのが CLAUDE.md というファイルです。.md は「Markdown（マークダウン）」という軽量な文書形式の拡張子で、見出しや箇条書きを使って読みやすく書けます。このファイルにClaudeへの指示や背景情報を書き込むことで、AIが毎回の会話の前に「このプロジェクトのルール」を読み込んでくれます。

「コマンド（スラッシュコマンド）」とは

/fix、/review のように、スラッシュで始まる短い命令文のことです。.claude/ フォルダの中にこれらのコマンドを定義しておくと、よく使う操作を短いキーワードで呼び出せるようになります。

---

3. トレンド分析

開発者コミュニティで何が起きているか

2025年に入ってから、Hacker NewsやRedditの技術系コミュニティでは、Claude Code（ClaudeをコマンドラインやIDEから使うためのツール）に関する議論が活発になっています。その中で特に注目されているのが、.claude/ フォルダをどう設計するかという実践的な話題です。

あるHacker Newsのスレッドでは、「CLAUDE.md に何を書くべきか」というテーマで数百件のコメントが集まりました。そこで共有された知見を整理すると、大きく三つの方向性が見えてきます。

① プロジェクト固有のルールを書く

「このコードベースではTypeScriptを使う」「テストは必ずJestで書く」「コメントは日本語で残す」といった、そのプロジェクト特有の取り決めを記述するケースが最も多く見られました。これにより、新しいメンバーがチームに加わったときと同様に、AIも「このプロジェクトの流儀」を理解した状態でサポートしてくれます。

② AIの行動を制限する

「本番環境のデータベースには絶対に触れないこと」「外部APIを勝手に呼び出さないこと」といった安全上の制約を明記するケースも増えています。AIが自律的に動く場面が増えるにつれて、「やってはいけないこと」を明示する重要性が認識されてきました。

③ カスタムコマンドで繰り返し作業を自動化する

.claude/commands/ というサブフォルダにコマンドファイルを置くと、/deploy-check（デプロイ前の確認）や /write-test（テストコードの自動生成）といった独自コマンドを定義できます。Redditでは「これで毎朝の定型作業が半分になった」という報告も見られました。

非エンジニアへの広がり

興味深いのは、この仕組みへの関心がエンジニア以外にも広がっている点です。マーケティング担当者が「ブランドトーン（言葉のトーン）のガイドライン」を CLAUDE.md に書き込んで文章生成に活用したり、法務担当者が「使ってはいけない表現のリスト」を記述したりする事例が、SNSで共有されるようになっています。

つまり .claude/ フォルダは、「コードを書く人のための道具」ではなく、「AIと継続的に協働するすべての人のための道具」として位置づけられつつあります。

Anthropicの公式姿勢

Anthropic社は、.claude/ フォルダの仕様をオープンに公開し、コミュニティからのフィードバックを積極的に取り込む姿勢を示しています。これは「ユーザーがAIの動作をコントロールできる透明性」を重視するという、同社の設計思想と一致しています。

---

4. Spectralの見解

「AIに文脈を渡す」ことの本質的な意味

Spectralがさまざまな企業のAI導入を支援してきた経験から言えることがあります。AIツールの導入がうまくいかない場合、多くは「AIへの指示が毎回バラバラで、一貫性がない」という問題に起因しています。

人間のチームメンバーに仕事を依頼するとき、私たちは暗黙のうちに多くの「文脈」を共有しています。「この会社の文化」「このプロジェクトの目的」「このクライアントの好み」――こうした背景知識があるから、短い指示でも意図が伝わります。

しかしAIには、そうした暗黙の文脈がありません。毎回ゼロから説明しなければ、毎回少しずつ違う答えが返ってきます。.claude/ フォルダは、この問題に対するひとつの実践的な答えです。

「設定ファイル」ではなく「チームの記憶」として捉える

私たちがお勧めしたいのは、.claude/ フォルダを単なる「設定ファイル」として捉えるのではなく、「チームの記憶を保存する場所」として捉えることです。

たとえば、新しいメンバーがチームに加わったとき、あなたはどんな情報を伝えますか？「このプロジェクトの目的」「よく使うツール」「やってはいけないこと」「過去に失敗した経験から学んだこと」――こうした情報を CLAUDE.md に書き込むことで、AIも同じ「チームの記憶」を共有できます。

小さく始めることの重要性

.claude/ フォルダの設計に完璧を求める必要はありません。最初は数行の CLAUDE.md から始めて、使いながら少しずつ育てていく――そのアプローチが最も持続可能です。

Spectralが支援した企業の中には、最初は「このプロジェクトで使う言語は日本語のみ」という一行だけを書いて始め、半年後には50行を超える詳細なガイドラインに育てたケースもあります。

組織的な標準化への一歩

複数のチームがAIを使う組織では、.claude/ フォルダの内容をテンプレート化することで、AIの使い方を組織全体で標準化できます。これは「AIガバナンス（AIの使い方を組織として管理すること）」の第一歩として、非常に実践的な取り組みです。

---

5. 実践的アプローチ

.claude/ フォルダの基本構造

実際にどんなファイルが入るのか、具体的に見ていきましょう。

```

プロジェクトフォルダ/

├── .claude/

│ ├── CLAUDE.md ← メインの指示ファイル

│ └── commands/ ← カスタムコマンドのフォルダ

│ ├── review.md ← /review コマンドの定義

│ └── summarize.md ← /summarize コマンドの定義

├── src/ ← プロジェクトのコードなど

└── README.md

```

この構造はシンプルです。必須なのは CLAUDE.md だけで、カスタムコマンドは必要になってから追加すれば十分です。

CLAUDE.md に書くべき内容

ステップ1：プロジェクトの概要を書く

まず、このプロジェクトが何を目的としているかを2〜3文で書きます。

```

プロジェクト概要

このプロジェクトは、中小企業向けの在庫管理システムです。

ユーザーは主に倉庫スタッフで、ITリテラシーは高くありません。

シンプルで直感的な操作性を最優先にしています。

```

ステップ2：使ってほしいルールを書く

言語、スタイル、禁止事項などを箇条書きで整理します。

```

ルール

• コードのコメントは必ず日本語で書く
• 変数名は英語、ただし略語は使わない
• エラーメッセージはユーザーが理解できる平易な日本語にする
• 外部ライブラリを新たに追加する場合は必ず確認を求める

```

ステップ3：よく使う情報を書く

毎回説明するのが