未分類 2026.05.20

Claude Code 設定｜15部署運用でわかった本当に必要な1つ

Claude Code の設定を調べていると、パーミッションモードの段階管理、ブランチ戦略、ワークツリーの使い分け……と、やることが無限に増えていきます。個人で使い始めた人向けの解説は世の中に充実していて、なかでも奥山氏（@okuyama_ai_）が個人・初日のユーザー向けに整理した設定論は、初学者が最初の一歩を踏み出すのに十分な完成度です。本記事はその焼き直しではありません。個人向けに整理された設定を、組織で複数人が並行運用するときにどうチューニングしたか。合同会社iMedia が自社の15部署で Claude Code を実運用してわかった「素のままでよかった設定」と「唯一作り込んだ設定」を、実態ベースで共有します。

先に答えを出しておきます。15部署で回しても、設定はほとんど作り込んでいません。手をかけたのは CLAUDE.md の階層化だけでした。当社は2025年から Claude Code を日次運用しており、その積み重ねのうえで「組織だから設定を固めないと」と身構えている中小企業の担当者ほど、読んで肩の力を抜いてもらえる内容です。

Claude Code を組織で運用すると、個人と設定をどう変えるべき？

結論：ほとんど変えなくていい。iMedia は15部署で運用していますが、設定で本当に手をかけたのは CLAUDE.md の階層化ただ1つだけです。

「組織で複数人が使うなら、権限を細かく分けて、部署ごとにモードを出し分けて……」と発想しがちですが、当社が15部署に展開して振り返ると、その大半は不要でした。秘書室の事実確認レポート（2026-05-19）と、設定ファイルを直接たどった調査（~/.claude/settings.json、find での CLAUDE.md 全件洗い出し、git branch の確認）でも、部署ごとに差別化された設定はほぼ存在しませんでした。

念のため断っておくと、個人向け・導入初日の設定論としては奥山氏の解説が体系的によく整理されています。本記事はそれと競合するものではなく、その続編=「組織で並行運用する段になって、個人向け推奨をどこまで引き継ぎ、どこを変えたか」という位置づけで読んでください。

なお、ここで扱う Claude Code 設定の各項目（パーミッションモード、CLAUDE.md の仕様、settings.json の構造）は、Anthropic が公開している仕様に準拠しています。一次情報はClaude Code 公式ドキュメントを参照してください。本記事はその公式仕様を前提に、組織運用の実態だけを上乗せして語ります。

以下、設定項目ごとに「個人向けの推奨」と「iMedia の15部署運用の実態」を並べて見ていきます。

設定項目	個人向けの一般的な推奨	iMedia の15部署運用の実態
パーミッションモード	Ask から段階的に上げる	全社統一 acceptEdits（部署別の差別化は0件）
危険操作の扱い	個別に都度判断	permissions.ask に破壊的コマンドだけ登録し、ここだけ確認を残す
バイパス権限モード	最初はオフ	設定ベースで全社オフ（該当0件）
ブランチ・ワークツリー	部署名等にカスタマイズ推奨	カスタマイズなし（WPは main のみ・worktree形跡なし）
CLAUDE.md	100行以内・参照先だけ	全社憲法 → 15部署 → 案件の3階層で運用

この表の最後の行だけが、当社が個人向け以上に作り込んだ設定です。残りは組織になっても素のままで回りました。

パーミッションモード、iMedia は15部署でも「全社統一」だった

~/.claude/settings.json の defaultMode は acceptEdits。これが全社の標準で、15部署すべてがこの1つのモードで動いています。個人向けの「Ask から段階的に上げろ」とは違う運用に落ち着きました。Claude Code 設定の中でも、ここは個人と組織で判断が分かれる代表例です。

15部署それぞれで上書きしている設定ファイルを探しましたが、パーミッションモードを部署別に変えている箇所は見つかりませんでした。マーケ部だけ厳しく、開発部だけ緩く、といった段階管理は一切やっていません。

なぜ統一で回るのか。個人向けの「段階的に上げる」という推奨は、ユーザーが Claude Code の挙動に慣れていく学習プロセスを前提にしています。組織で15部署に展開する局面では、各部署が個別に段階を踏むより、全社で1つのモードに揃えてしまったほうが管理コストが下がるというのが当社の結論でした。「部署ごとに最適なモードを設計する」のは一見きめ細かいですが、その設計と維持にかかる手間が、得られる安全性に見合いませんでした。

ただし、acceptEdits で編集を自動承認するということは、放っておくと Claude Code が自動でファイルを書き換え続けるということです。これが事故につながらないのか。当社は破壊的操作だけ確認を残す設計を別途敷くことで、全自動と安全確認を両立させています。その設計の中身を次に分解します。

全自動で運用しても事故らないのはなぜ？

ノートPCに挿さったUSBメモリ。全自動運用でも破壊的操作だけ確認を残す設計のイメージ — Photo by Claudio Sanabria on Unsplash

結論：acceptEdits で編集を自動承認していても、rm・git reset –hard・git clean などの破壊的なコマンドだけは permissions.ask に登録して確認を残しているからです。全自動と安全確認を両立させる、この一点だけ設計しています。

仕組みはシンプルです。パーミッションモードは全社 acceptEdits で「編集は自動で進める」。そのうえで、permissions.ask リストに取り返しのつかない操作、つまりファイル削除（rm）、コミットの巻き戻し（git reset –hard）、未追跡ファイルの一掃（git clean）といった破壊的コマンドを登録し、ここに該当する操作のときだけ人間に確認を求める。普段の編集作業はノンストップで進み、データが消える瞬間だけ手が止まる、という設計です。

当社の ~/.claude/settings.json で、この設計に対応する部分は次の構造です（秘書室の事実確認で裏取りした範囲のみ記載しています）。

{
  "defaultMode": "acceptEdits",
  "permissions": {
    "ask": [
      "Bash(rm:*)",
      "Bash(git reset --hard:*)",
      "Bash(git clean:*)"
    ]
  }
}

defaultMode を acceptEdits に固定し、permissions.ask に破壊的コマンドだけを並べる。設定としてはこれだけです。permissions.ask の挙動の正確な仕様はClaude Code 公式ドキュメント・Configure permissionsにあたってください。

この「全自動を基本にして、破壊的操作だけ確認を残す」やり方は、部署ごとに段階モードを細かく管理するより中小企業にとって現実的だと考えています。登録するコマンドのリストは一度決めれば全社で使い回せます。部署別の段階管理だと、部署が増えるたびに設計と運用が膨らんでいくからです。

正直に補足しておくと、当社では並行運用時の事故記録を残す仕組み（revision_log）を用意していますが、現時点で記録は空です。これは「絶対に事故が起きない」と断定できる根拠ではなく、「破壊的操作だけ確認を残す設計を敷いたうえで、起きたことは記録できる体制にしている」という意味で受け取ってください。事故ゼロを保証する設定は存在しません。

バイパス権限モードは、組織でも不要だった

組織なら権限を緩めたほうが速い。そう考える担当者は多いはずです。当社の答えは逆でした。15部署で運用していても、権限チェックを全面的に飛ばすモードは一度も使っていません。個人向けの推奨（最初はオフ）とまったく同じで、iMedia も設定ベースで全社オフです。

設定ファイルを調べた結果、権限確認を丸ごとスキップするモード（bypassPermissions）に該当する設定はどこにも入っていませんでした。個人向けの「最初はオフのままにしておけ」という推奨と、組織での実態が完全に一致した数少ない項目です。

人数が増え、並行で動く処理が増えるほど、権限チェックを飛ばしたときの被害範囲は広がります。組織だからこそオフのまま回す。当社は破壊的操作に確認を残す設計で全自動運用を成立させているので、そもそも全権限をバイパスする必要が生まれませんでした。危険操作だけ確認を残す設計でも、運用スピードは十分でした。

ブランチやワークツリーの戦略、組織なら作り込むべき？

個人向けには「ブランチのプレフィックスを部署名にする」といったカスタマイズが推奨されます。一方で iMedia の記事・業務系プロジェクトは、main 運用のままで、ブランチ命名もワークツリーもカスタマイズしていません。組織化したからといって、ここに手を入れる必要はありませんでした。

実際に確認したところ、本記事を含む WordPress 運用プロジェクトは main ブランチのみで運用しており、git worktree を使った形跡もありませんでした。ブランチプレフィックスを部署名や用途で命名するルールも設けていません。

なぜ作り込まなかったのか。ブランチ戦略やワークツリーの使い分けは、複数の機能開発を並行させるソースコードのプロジェクトで威力を発揮する設定です。当社の記事制作や業務運用のプロジェクトは、コードを書いて並行ブランチを切る性質の作業ではありません。そこに開発向けのブランチ戦略を持ち込むと、運用ルールだけが増えて実利がない。いわゆる過剰設計になります。

線引きとしてはこうです。コードを書いて並行開発する部署なら、ブランチ・ワークツリー戦略は検討する価値があります。記事制作・バックオフィス運用のように成果物がコードでない部署では、main 一本のままで十分でした。組織だからといって一律にブランチ戦略を敷く必要はない、というのが当社の正直な結論です。

唯一作り込んだのは CLAUDE.md の3階層構造

鉛筆と定規で図面を引く設計士。CLAUDE.mdを3階層で設計するイメージ — Photo by Daniel McCullough on Unsplash

15部署を2025年から日次で回してきて、設定で本当に手をかけたのはここだけでした。組織での CLAUDE.md の書き方は、個人向けの鉄則を「階層をまたいで適用する」ことに尽きます。当社は CLAUDE.md を「全社憲法 → 15部署 → 案件」の3階層に分けて運用しています。Claude Code 設定で唯一、個人向け以上に作り込んだ部分です。

構造は次の3階層になっています。

第1階層：全社憲法（~/iMedia-ai-team/CLAUDE.md）

全部署に共通する原則・禁止事項・トーンを定義します。会社の最上位ルールで、ここに書いたことは15部署すべてに効きます。

第2階層：部署

各部署の CLAUDE.md に、その部署固有の役割・判断ルール・参照すべきナレッジを定義します。全社憲法を前提に、部署単位で上書きします。

第3階層：案件

個別プロジェクトの CLAUDE.md に、そのプロジェクト限定の仕様・作業ルールを定義します。部署ルールを前提に、案件単位でさらに具体化します。

この3階層が成立しているのは、各 CLAUDE.md が「自分の階層の責務だけ書き、詳細は参照先に逃がす」という書き方を守っているからです。個人向けでよく言われる「CLAUDE.md は100行以内に抑え、詳細は参照先リンクで」という鉄則を、組織では階層をまたいで適用しています。全社憲法に部署の細則まで書き込むとどうなるか。ファイルが肥大化して、結局誰も読まなくなります。だから上位の階層ほど薄く保ち、具体的なルールは下位ファイルに寄せる。これを3階層で徹底したことが、15部署を破綻させずに回せている要因でした。

逆に言うと、ここを設計せずに部署を増やすと、ルールの矛盾や重複が起きて組織化が失敗します。組織で Claude Code を運用するときに起こりがちな失敗パターンは、別記事「Claude Code 失敗｜中小企業がやりがちな組織化の落とし穴」で詳しく整理しています。

中小企業が「設定沼」で消耗しないためのチェックリスト

白紙のチェックリストとデスク。設定チェックリストのイメージ — Photo by NORTHFOLK on Unsplash

設定で半年近く悩んだ末に、作り込む価値があったのは CLAUDE.md の階層化だけでした。それ以外（パーミッションの細分化・ブランチ戦略・ワークツリー）は素のままで構いません。当社が15部署で実証した、本当にやるべきことは次の4つだけです。

1. パーミッションモードは全社 acceptEdits で統一する

部署ごとの出し分けは作らない。15部署でも統一で回りました。defaultMode を全社で1つに揃えるだけです。

2. permissions.ask に破壊的コマンドだけ登録する

rm・git reset –hard・git clean など、取り返しのつかない操作だけ確認を残します。全自動でもここだけ止まれば現実的に運用できます。

3. CLAUDE.md を「全社憲法 → 部署 → 案件」の3階層にする

ここだけは作り込む価値があります。上位の階層は薄く保ち、具体的なルールは下位へ寄せる。これが組織運用の成否を分ける核でした。

4. バイパス権限モードは触らない

最初からオフのまま。組織だからこそ緩めない。bypassPermissions は0件で運用できます。

逆に、やらなくていいことは「パーミッションモードの部署別細分化」「ブランチ命名のカスタマイズ」「ワークツリーの使い分け」です。当社の業務系プロジェクトでは、いずれも素のままで支障ありませんでした。設定を増やすほど良くなる、という思い込みを外すことが、設定沼から抜ける最短ルートです。

Claude Code を使った業務効率化の全体像や、中小企業がどこから着手すべきかは、別記事「Claude Code 業務効率化｜中小企業が実際に運用した記録」にまとめています。設定の話の前段として、あわせて読んでいただくと判断しやすくなります。

関連記事：本記事の「設定は作り込まなくていい・効くのは1つだけ」というアプローチは、実は中小企業マーケティングの差別化に共通する「ずらし戦略」の一例でした。3型（ターゲット/切り口/段階）として整理した別記事「中小企業マーケティングの差別化｜AI三つ巴に学ぶずらし戦略の3型と4ステップ」で、iMediaの過去記事3本を実例として分解しています。

組織の CLAUDE.md 設計、伴走支援できます

「3階層にすればいい」と言われても、自社の部署構造に落とし込む段で手が止まる。その設計こそ、外から入る価値が出る部分です。合同会社iMedia は自社の15部署で Claude Code を日次運用しており、その実装ノウハウをそのまま中小企業向けのAI業務改善支援として提供しています。

AI業務改善の支援サービス詳細：https://ai-gyomusien.i-media.jp/
HP制作・その他サービス：https://i-media.jp/#service
ご相談・お問い合わせ：https://i-media.jp/#contact

設定を作り込むより先に、組織のルール構造をどう設計するか。そこに時間を使えるよう伴走します。

今枝友典（合同会社iMedia 代表）
中小企業向けデジタルマーケティングを8年。Claude Code・AI業務自動化を実装し、自社で日次運用中（2025年〜）。AI業務改善支援サービスを提供。
お問い合わせ：https://i-media.jp/#contact

本記事は、奥山氏（@okuyama_ai_）が個人・導入初日のユーザー向けに整理した Claude Code 設定論を踏まえ、それを組織での並行運用に応用した実態を合同会社iMedia がまとめたものです。記事内の設定値・運用実態は、秘書室の事実確認レポート（2026-05-19）および設定ファイルの直接調査に基づきます。設定仕様の一次情報は Anthropic 公式ドキュメントを参照してください。

← ブログ一覧へ戻る