0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kumaboarder

Claude Codeを制御する：GitHub Copilotとの対比で整理する【第3章ノート】

0
Posted at

Claude Codeを制御する：GitHub Copilotとの対比で整理する【第3章ノート】

『Claude Code実践入門 [生成AI深掘りガイド]』第3章「Claude Codeを制御する」の学習メモです。
業務ではGitHub Copilotを使っているので、学んだことをGitHub Copilotとの対比でまとめています。

本書は設定・メモリ・Hooks・サンドボックスを「制御レイヤー」として扱います。本記事はその観点を、公開ドキュメント上の現行仕様と照合しつつ、Copilot側の対応物と対応づけます。

先に結論：制御は「指示」と「強制」を分ける

レイヤー Claude Code GitHub Copilot（近いもの） 強制力
指示・文脈 CLAUDE.md / .claude/rules/ / Auto memory .github/copilot-instructions.md / *.instructions.md / AGENTS.md 弱い（モデルが読む）
設定・権限 settings.json（permissions など） VS Code / Copilot の settings、組織ポリシー 中〜強
イベント駆動 Hooks（PreToolUse など） Copilot hooks（.github/hooks/*.json） 強（スクリプトで遮断可）
実行隔離 Sandbox（bash の FS/NW 制限） Local sandbox（/sandbox） 強（OSレベル）

ポイントは次の一文です。

「やってほしいこと」はメモリへ、「やってはいけないこと」は permissions / hooks / sandbox へ。

CLAUDE.md や .claude/rules/ に「.env を読むな」と書いても、それはお願いです。
パスを絞って rules を置いても 強制にはなりません（そのパス作業時に文脈へ載るだけ）。従うかどうかは確率論です。
確実に止めたいなら permissions.deny や PreToolUse hook、サンドボックスを使います。

3.1 設定ファイルの配置場所と適用範囲

Claude Codeは スコープ（適用範囲） で設定の置き場が分かれます。

Claude Code のスコープ

スコープ 代表パス 誰に効くか チーム共有
Managed /etc/claude-code/ など、MDM / 管理コンソール 組織全員（上書き不可） 管理者配布
User ~/.claude/settings.json 自分の全プロジェクト しない
Project .claude/settings.json そのリポジトリの共同作業者 git に入れる
Local .claude/settings.local.json 自分・そのリポジトリのみ しない（gitignore想定）

優先順位（高い順）: Managed → CLI引数 → Local → Project → User

配列系（permissions.allow や sandbox のパスなど）は「上書き」ではなく マージ されることが多い点に注意です。

関連ファイルの置き場もスコープに沿います。

機能 User Project Local
Settings ~/.claude/settings.json .claude/settings.json .claude/settings.local.json
CLAUDE.md ~/.claude/CLAUDE.md CLAUDE.md or .claude/CLAUDE.md CLAUDE.local.md
MCP ~/.claude.json .mcp.json （per-project は ~/.claude.json）

GitHub Copilot との対比

観点 Claude Code GitHub Copilot
個人設定 ~/.claude/ VS Code User settings / ~/.copilot/（CLI hooks など）
リポジトリ共有 .claude/settings.json .github/ 配下（instructions / hooks）
組織強制 Managed settings（上書き不可） Enterprise の managed policy / 組織カスタム指示
「自分だけこのrepo」 settings.local.json / CLAUDE.local.md 個人カスタム指示、またはローカル未コミット設定

実務での分け方

  • プロジェクト全体の設定
  • 開発グループごとの設定
  • 各個人の設定

settings系はプロジェクト全体があればよさそうだが、rulesは開発グループごとに差異が出そう。

3.2 メモリファイル（CLAUDE.md）とメモリシステム

セッションは毎回新しいコンテキストから始まります。跨セッションの知識を渡すのがメモリです。

2種類のメモリ

CLAUDE.md（手動） Auto memory（自動）
誰が書くか 人間 Claude
中身 規約・ビルド手順・アーキテクチャ 訂正から学んだ好み・パターン
用途 「毎回説明したくないこと」 「同じ指摘を繰り返したくないこと」
強制力 なし（文脈） なし（文脈）

どちらも 強制ではなく文脈 です。守らせたいルールは次節以降へ。

「rules」のパス指定は強制ではない

.claude/rules/ のパス条件（Copilot なら *.instructions.md の applyTo）は、よく誤解されます。

できること できないこと
そのパスを触るときにルールを 文脈へ載せる そのパスでの振る舞いを 必ず守らせる
常時ロードを減らし、トークンとノイズを抑える deny / 遮断と同じ意味の「適用」

パス指定は いつ読むか の制御であり、必ず従わせるか の制御ではありません。
モデルは載せた指示を高い確率で参照しますが、無視・部分遵守もあり得ます。ここは 確率論（プロンプト遵守） です。

確実に止めたい・必ず走らせたいなら:

  • 禁止 → permissions.deny / Hooks（PreToolUse）/ sandbox
  • 必須の後処理 → Hooks（PostToolUse など）

rules という名前でも、ゲートキーパーではなく 条件付きの案内板 です。

CLAUDE.md の置き場（広い → 狭い）

スコープ パス例 用途
Managed /etc/claude-code/CLAUDE.md など 全社ルール
User ~/.claude/CLAUDE.md 個人の書き方・好み
Project ./CLAUDE.md または ./.claude/CLAUDE.md チーム共有
Local ./CLAUDE.local.md 個人のローカル事情（gitignore）

階層上の CLAUDE.md は連結して読み込まれ、より深いディレクトリ側が後に来る（近くの指示が後勝ちしやすい）イメージです。
サブディレクトリの CLAUDE.md は、その配下を触るタイミングで遅延ロードされます。

大規模プロジェクトでは .claude/rules/*.md に分割し、パス条件で必要なときだけ読ませるとトークンを節約でき、関連指示が文脈に残りやすい分だけ遵守も安定しやすいです（それでも保証ではない）。

書き方のコツ（短く・具体的に）

  • 目安: 1ファイル 200行未満
  • 「きちんとフォーマット」より「インデントは2スペース」
  • 「テストして」より「コミット前に npm test」
  • 矛盾するルールを残さない

@path で他ファイルを import できます。他エージェント向けに AGENTS.md がある場合は、

@AGENTS.md

## Claude Code
- `src/billing/` の変更は plan mode を使う

のように共有しつつ、Claude固有の追記を足せます。

/init で雛形生成、/context で「Memory files」に載っているか確認、が定石です。

GitHub Copilot との対比

Claude Code GitHub Copilot メモ
CLAUDE.md .github/copilot-instructions.md どちらも「常時載せる指示」
.claude/rules/ + パス条件 .github/instructions/*.instructions.md + applyTo パスに応じて文脈へ載せる指示（強制ではない）
CLAUDE.local.md 個人カスタム指示 リポジトリに載せない好み
Auto memory （同等の自動メモ機構は弱い/別物） Claude側が学習メモを自前管理
@AGENTS.md import AGENTS.md を直接読むケースあり 相互運用が進んでいる

VS Code / Copilot 側も CLAUDE.md や .claude/rules を認識できるようになってきており、指示ファイルを一本化しやすい方向です。
ただし「誰が正式な正とするか」はチームで決めておくと混乱しません。

実務での分け方

プロジェクト全体のルール、グループごとのルールは別にする。
特に業務アプリ開発と共通部品開発では大きくルールが異なるのに注意する必要がありそう。

3.3 設定ファイル（settings.json）の使い方

settings.json は 振る舞いを技術的に縛る 場所です。メモリ（お願い）と対になる強制レイヤーです。

基本形

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)"
    ],
    "deny": [
      "Bash(curl *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  },
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1"
  }
}

よく触る塊:

キー 役割
permissions allow / deny / ask。ツール実行の可否
hooks ライフサイクルでの自動実行（次節）
sandbox OS隔離（次々節）
env ツールに渡す環境変数
model など モデルやUI系の好み

編集後は多くのキーがホットリロードされます（permissions / hooks など）。model のように再起動や専用コマンドが要るものもあります。
効いているか確認するならセッション内で /status（Setting sources）や /doctor。

permissions の考え方

  • deny: 絶対にやらせない（秘密ファイル、危険コマンド）
  • allow: 何度も聞かれる安全操作を通す（lint / test）
  • ask: 都度確認

「便利だから全部 allow」は避け、deny で守り、必要最小の allow で摩擦を減らすのが安全です。

GitHub Copilot との対比

観点 Claude Code GitHub Copilot
中心設定 .claude/settings.json VS Code settings.json + .github/ 成果物
指示の置き場 メモリファイル側が主戦場 以前は settings に指示も書けたが、ファイルベース指示へ移行（codeGeneration.instructions は非推奨寄り）
ツール承認 permissions + 対話プロンプト ツール実行時の Yes / Session承認 / No
組織ロック Managed で permissions を固定可能 Enterprise managed settings

Copilot経験者向けの読み替え:

  • Copilot の「instructions ファイル」≈ Claude の CLAUDE.md
  • Copilot の「ツール承認ダイアログ」≈ Claude の permissions / ask
  • 「リポジトリにコミットする運用設定」≈ .claude/settings.json

3.4 フック（Hooks）

Hooksは、エージェントのライフサイクルに 決定論的なスクリプト を差し込む仕組みです。
メモリが「守ってね」なら、Hooksは「ここで必ず検査・遮断・ログする」。

代表イベント

イベント いつ 典型用途
SessionStart / SessionEnd セッション開始・終了 環境初期化、監査ログ
UserPromptSubmit プロンプト送信時 入力の記録・検査
PreToolUse ツール実行前 危険コマンド遮断（最重要）
PostToolUse ツール成功後 lint / format、結果ログ
Stop 応答完了時 後処理・チェックリスト

設定は settings.json の hooks に書きます（User / Project / Local / Managed でマージ）。

最小例：危険な rm -rf を止める

.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "\"${CLAUDE_PROJECT_DIR}/.claude/hooks/block-rm.sh\""
          }
        ]
      }
    ]
  }
}

.claude/hooks/block-rm.sh（実行権限必須）:

#!/bin/bash
COMMAND=$(jq -r '.tool_input.command')

if echo "$COMMAND" | grep -q 'rm -rf'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Destructive command blocked by hook"
    }
  }'
else
  exit 0
fi

編集後に自動 format したい場合は PostToolUse + matcher: "Write|Edit" が定番パターンです。

GitHub Copilot との対比

実は Copilot にも Hooksがある（Copilot CLI / cloud agent）。

観点 Claude Code GitHub Copilot
配置 settings.json の hooks、プラグイン等 .github/hooks/*.json、CLIは ~/.copilot/hooks/*.json
形式 イベント → matcher → command/http/prompt version: 1 + hooks オブジェクト
代表イベント PreToolUse, PostToolUse, Stop… preToolUse, postToolUse, sessionStart…（命名が camelCase）
遮断 JSON で permissionDecision: "deny" など preToolUse で deny 応答 / exit で制御
成熟度・イベント数 かなり多い（PermissionRequest, Compact など） CLI/Agent向けに実用セット

共通の使い方

  1. preToolUse で危険操作を止める
  2. 監査ログを残す
  3. セッション開始バナーで「ポリシー適用中」を示す

違い

  • Claude は settings 階層・Managed・matcher が細かい
  • Copilot は .github/hooks/ に JSON を置くリポジトリ中心の配布が分かりやすい

両方使うチームは、「遮断ルールの意図」は共通化し、実装スクリプトだけ各ツール向けに分岐するのが現実的です。

3.5 サンドボックスモード

Sandboxは、エージェントが起動する シェルコマンドを OS レベルで隔離 する仕組みです。
permissions が「Claudeのツール層」、sandbox が「プロセスの境界」です。

Claude Code で押さえること

settings.json 例:

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "allowUnsandboxedCommands": false,
    "excludedCommands": ["docker *"],
    "filesystem": {
      "denyRead": ["~/.aws/credentials"],
      "denyWrite": ["/etc"]
    },
    "network": {
      "allowedDomains": ["registry.npmjs.org", "github.com"]
    }
  }
}
設定 意味
enabled bash サンドボックス有効化（macOS / Linux / WSL2）
autoAllowBashIfSandboxed 隔離下なら承認を減らす（デフォルト true）
allowUnsandboxedCommands 脱出ハッチを許すか。組織では false も検討
filesystem.* 読み書き禁止パス
network.* 許可ドメイン等

重要な注意:

  • サンドボックスは主に サブプロセス（bash 等） 向け
  • 組み込みの Read/Edit ツールまで全部カバーするとは限らない
  • だから permissions の deny と二重化 するのが安全（例: .env は Read deny + sandbox denyRead）

GitHub Copilot との対比

Copilot CLI にも local sandbox があります（/sandbox enable など）。

観点 Claude Code GitHub Copilot CLI
有効化 sandbox.enabled / 設定UI /sandbox enable、設定ダイアログ
対象 代理実行するコマンドの隔離 同様（CLI自体ではなく代理コマンド）
FS / NW settings で詳細制御 General / filesystem / network タブ、/sandbox policy
bypass allowUnsandboxedCommands Allow sandbox bypass
組織強制 Managed でハードゲート可能 managed 表示で変更不可にできる

どちらも思想は同じです。

隔離したうえで、承認コストを下げて速く回す。

Sandbox なしで permissions だけ緩めると危険、Sandbox ありなら autoAllow で快適、というトレードオフです。

3.6 まとめ：制御レイヤーの整理

同じ4層で、Claude Code と GitHub Copilot を並べます。
層の意味は共通で、置き場と正式名称だけが違う、と捉えると迷いづらいです。

Claude Code の制御レイヤー

┌─────────────────────────────────────────────┐
│ 指示レイヤー（弱い／文脈）                      │
│  CLAUDE.md / .claude/rules/ / Auto memory   │
├─────────────────────────────────────────────┤
│ 設定レイヤー（中〜強）                         │
│  .claude/settings.json                      │
│  （permissions / env / model など）           │
├─────────────────────────────────────────────┤
│ フックレイヤー（強／決定論）                    │
│  settings.json の hooks                     │
│  （PreToolUse で遮断、PostToolUse で検証）     │
├─────────────────────────────────────────────┤
│ 隔離レイヤー（強／OS）                         │
│  sandbox（filesystem / network）            │
└─────────────────────────────────────────────┘

GitHub Copilot の制御レイヤー

┌─────────────────────────────────────────────┐
│ 指示レイヤー（弱い／文脈）                      │
│  .github/copilot-instructions.md            │
│  .github/instructions/*.instructions.md     │
│  （必要なら AGENTS.md / 個人カスタム指示）       │
├─────────────────────────────────────────────┤
│ 設定レイヤー（中〜強）                         │
│  VS Code / Copilot settings                 │
│  ツール承認ダイアログ・組織ポリシー              │
├─────────────────────────────────────────────┤
│ フックレイヤー（強／決定論）                    │
│  .github/hooks/*.json                       │
│  （CLI 個人用は ~/.copilot/hooks/*.json）     │
│  （preToolUse で遮断、postToolUse で検証）     │
├─────────────────────────────────────────────┤
│ 隔離レイヤー（強／OS）                         │
│  local sandbox（/sandbox・FS/NW policy）    │
└─────────────────────────────────────────────┘

層ごとの対応表

層 強制力 Claude Code GitHub Copilot
指示 弱（確率論） CLAUDE.md / .claude/rules/ / Auto memory copilot-instructions.md / *.instructions.md / 個人指示
設定 中〜強 .claude/settings.json（permissions など） VS Code settings・ツール承認・組織ポリシー
フック 強 hooks（PreToolUse など） .github/hooks/*.json（preToolUse など）
隔離 強 sandbox local sandbox（/sandbox）

導入順のおすすめ

Claude Code

  1. Project の CLAUDE.md を薄く書く（ビルド・テスト・ディレクトリ規約）
  2. .env など secrets を permissions.deny
  3. PreToolUse で破壊的コマンドを遮断
  4. Sandbox を有効化し、必要なドメインだけ許可
  5. 摩擦の高い安全コマンドだけ allow で通す

GitHub Copilot

  1. .github/copilot-instructions.md を薄く書く（全体規約）
  2. パス別は .github/instructions/*.instructions.md + applyTo
  3. .github/hooks/ の preToolUse で危険コマンドを遮断
  4. Copilot CLI なら /sandbox enable し、FS/NW policy を締める
  5. 繰り返し承認が重い安全操作だけ、セッション承認や設定で摩擦を減らす

併用時の最短対応表

やりたいこと Claude Code Copilot
コーディング規約を共有 CLAUDE.md .github/copilot-instructions.md（または共通の AGENTS.md）
パス別に指示を載せる（強制ではない） .claude/rules/ .github/instructions/*.instructions.md
危険コマンド禁止 permissions + PreToolUse preToolUse hook
秘密ファイル保護 Read deny + sandbox denyRead sandbox FS policy + hook
チーム標準を固定 .claude/settings.json を commit .github/hooks と instructions を commit
個人実験 *.local.* / User スコープ User settings / ~/.copilot/hooks

覚えやすい標語（両方共通）

層 たとえ Claude Code GitHub Copilot
指示 案内板 Memory custom instructions
設定 門番 settings / permissions settings / ツール承認
フック 監視カメラ＋非常停止 Hooks Hooks
隔離 檻 sandbox local sandbox

案内板だけ増やしても檻がなければ事故ります。逆に檻だけ堅くて案内板がないと、毎回チャットで同じ説明をすることになります。

参考（公開ドキュメント）

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?