概要: Claude Code を導入したチームで「個人ごとの設定が散らかる」「破壊的なコマンドをうっかり実行する」「コミットに不要な署名が混入する」といった問題に当たったとき、.claude/ をチーム共有のハーネスとして整備すると一気に解決します。本記事はその全体像を、実際にあるモノレポで運用している .claude/ の構造を題材に解説する連載の第1回です。

はじめに

Claude Code を一人で使っているうちは、設定ファイルは ~/.claude/settings.json で十分です。permissions を緩めて、自分の好みのフックを少しだけ足せば、それで動きます。

しかしチームでの利用が始まると、一気に話が変わります。

• 「A さんの環境ではすぐ実行できたのに、B さんは毎回 permission の確認ダイアログが出る」
• 「Claude が terraform/prod を terraform apply しようとしてヒヤッとした」
• 「コミットメッセージに Co-Authored-By: Claude が紛れ込んでいて、本番ブランチに残ってしまった」
• 「.env をうっかり Read されて、シークレットが画面に出てしまった」

これらは「Claude Code 本体の機能だけでは防ぎきれないが、.claude/ の設計次第で全部止められる」種類の問題です。

本連載では、ある AI 系プロダクト群を抱えるモノレポで実運用している .claude/ を題材に、チームで共有するハーネスをどう設計するかを 4 回に分けて整理します。

この記事でわかること

• Claude Code の .claude/ がチーム運用上どんな役割を果たすか
• .claude/ を構成する 5 つの要素（settings / hooks / agents / commands / skills）の責務分担
• 「土台 → ガード → 拡張」の 3 層モデルで設定を組み立てる考え方
• 個人 override（settings.local.json）とチーム共有のラインの引き方

対象読者

• Claude Code をチームに導入したが、各自の設定が散らかってきている開発者
• 「permissions.deny だけだと漏れがあるな」と気づき始めた人
• subagent / skill / slash command の使い分けをまだ整理できていない人