Claude Codeの設定フォルダを整えたら、同じツールなのに別物になった

結論から言うと、Claude Codeの実力を引き出せていない原因は、モデルの性能でもプロンプトの書き方でもなく、プロジェクトの設定フォルダにある。

自分はフリーランスエンジニアとしてClaude Codeを日常的に使っているが、正直に言うと最初の数週間は「便利だけど、毎回同じ説明をするのがだるい」という状態だった。それが.claude/というフォルダを整備したことで、まるで別のツールになった。

この記事では、Claude Codeの隠れた設定フォルダの仕組みと、自分が実際に整備して変わったことを書く。

・Claude Codeを導入したけど期待ほど変わらない

・毎回同じ指示を繰り返している

・出力の品質がセッションごとにバラバラ

・チームで使っているのに人によって結果が違う

ここで止まっている人ほど見てほしい。

Claude Codeには「記憶」を置くフォルダがある
設定しないとどうなるか：毎回「初対面」のAIと仕事する羽目になる
CLAUDE.mdは「ドキュメント」ではなく「行動契約書」
agents/とskills/で「チーム」を作れる
設定の有無で生まれる「70%の差」
「プロンプトが上手い人」より「設定が上手い人」が勝つ時代
まとめ
【PR】フリーランスエンジニアにおすすめのツール
1. あわせて読みたい

Claude Codeには「記憶」を置くフォルダがある

Claude Codeをインストールすると、プロジェクトのルートに.claude/というディレクトリが作られる。多くの人はこのフォルダの存在すら知らないか、知っていても開いたことがない。

自分もそうだった。

このフォルダの中身は、大きく分けて5つの要素で構成されている。

以下がその一覧だ。

CLAUDE.md: プロジェクトのルールや文脈を定義するファイル。コーディング規約、アーキテクチャの方針、コミット前に確認すべきことなどを書く
rules/: 具体的な制約を置くフォルダ。「mainブランチに直接コミットしない」「プッシュ前にテストを実行する」といったルール
skills/: 再利用可能な機能を定義するフォルダ。「標準構成で新しいサービスを立ち上げる」「PRをセキュリティ観点でレビューする」など
agents/: サブエージェントの定義。データベース作業、フロントエンドの調整、インフラ関連など、専門的な作業を委任できる
hooks/: ライフサイクルイベントに応じて動くハンドラ。保存時のフォーマット、コミット前のリント実行など

つまり、このフォルダは「Claude Codeに対するマネージャーの期待値」を書く場所だ。人間のエンジニアに対してオンボーディング資料を渡すのと同じ感覚で、AIに対してプロジェクトの常識を共有する仕組みになっている。

設定しないとどうなるか：毎回「初対面」のAIと仕事する羽目になる

このフォルダを整備しないとどうなるか。

端的に言うと、毎回AIに一から説明する作業が発生する。「このプロジェクトはGoで書いてて、DBはPostgreSQLで、このディレクトリ構成で…」というやつだ。

これは地味にきつい。

自分の場合、2026年3月にVPSにClaude Codeをインストールして使い始めた。最初は「すごい、コード書いてくれる」と感動していたが、1週間もすると違和感に気づいた。

同じプロジェクトなのに、セッションが変わるたびにClaude Codeの出力のトーンが変わる。昨日は丁寧にエラーハンドリングを入れてくれたのに、今日は雑。import文のスタイルもバラバラ。

原因は単純で、Claude Codeがプロジェクトのルールを知らないからだ。人間で言えば、毎日違う派遣エンジニアが来て、引き継ぎなしで作業しているようなものだった。

AnthropicでClaude Codeを開発したBoris Chernyという人物は、ターミナルから5つのClaude Codeインスタンスを並行で動かし、それぞれが機能実装を一発で完了できるらしい。その秘密がこの.claude/フォルダの設定だったという話を読んで、自分の使い方がいかに雑だったか痛感した。

CLAUDE.mdは「ドキュメント」ではなく「行動契約書」

このフォルダの中で最も重要なのがCLAUDE.mdだ。

これは単なるREADMEやドキュメントではない。Claude Codeに対する行動契約書のようなものだ。

例えば、決済系のサービスを開発しているなら、こんな内容を書く。

アーキテクチャ: マイクロサービス構成、永続化にPostgreSQL、キャッシュにRedis
コミット前の確認事項: テスト実行、リント実行、差分にシークレットが含まれていないかチェック
DB変更のルール: 必ずマイグレーションファイルを使う、スキーマを直接変更しない、ロールバック手順を含める

こういったルールをCLAUDE.mdに書いておくと、Claude Codeは毎回それを読んでから作業を始める。人間が忘れがちなチェック項目も、AIなら律儀に守ってくれる。

自分がこのファイルを整備し始めてから、明らかに変わったことが3つある。

1つ目は、出力の一貫性。同じプロジェクトなら、誰がどのタイミングでClaude Codeを使っても同じスタイルのコードが出てくるようになった。

2つ目は、セッション間の文脈の保持。前回の会話内容は消えても、プロジェクトのルールは残る。これだけで「また説明するのか…」というストレスがなくなった。

3つ目は、新しいメンバーのオンボーディング。フリーランスの自分はチーム開発の機会もあるが、新しく入った人がClaude Codeを使い始めたとき、ベテランと同じ品質のアウトプットが出る。これは地味にすごい。

agents/とskills/で「チーム」を作れる

CLAUDE.md以外にも注目すべき機能がある。

agents/フォルダでは、特定の作業に特化したサブエージェントを定義できる。データベース周りの作業、フロントエンドの調整、インフラ関連の設定など、それぞれに専門知識を持たせたエージェントを用意しておける。

skills/フォルダには、プロジェクトをまたいで再利用できる機能を定義する。「標準的なスタックで新しいサービスを立ち上げる」「PRをセキュリティの観点でレビューする」といった定型作業をスキルとして登録しておけば、どのプロジェクトでも呼び出せる。

hooks/フォルダでは、特定のイベントに反応する処理を定義する。コードを保存したらフォーマットをかける、コミット前にリントを走らせる、といった処理を設定できる。

一人で作業していても、この3つを整備しておくだけで「一人チーム」が完成する。自分の場合、ルーチンワークをサブエージェントに任せることで、考える作業に集中できる時間が明らかに増えた。

設定の有無で生まれる「70%の差」

Anthropicの開発者の話によると、多くのチームはClaude Codeの能力の70%を使い切れていないらしい。

70%というのは、つまり本来の3分の1以下の力しか引き出せていないということだ。

この差を生んでいるのは、モデルの性能でもAPIの使い方でもなく、プロジェクト固有のコンテキストをどれだけAIに渡せているかという一点に集約される。

自分自身、.claude/フォルダを整備する前と後では作業の質が明確に変わった。整備前は「Claude Codeが書いたコードを自分がレビューして手直しする」というフローだった。整備後は「Claude Codeが自分のコーディング規約に沿ったコードを出す」ので、レビューで見るべきポイントがロジックの正しさだけに絞られた。

これは単純に楽だ。

ただし注意点もある。自分は以前、設定ファイルにVPSの構成やDockerの設定、環境変数名といった情報まで書き込んでしまったことがある。便利さを追求するあまり、セキュリティ上まずい情報をリポジトリに含めてしまうリスクがある。CLAUDE.mdに書く内容は「コーディングルールや設計方針」に留めて、認証情報やインフラの詳細は絶対に含めないようにしたい。これは自分への戒めでもある。