ankuro.dev
← ブログ一覧に戻る
【CCA Foundations対策 / Claude Code実践編 #3】カスタムコマンド・スキル・MCP・GitHub連携
2026-04-03#Claude Code#AI#MCP#GitHub#カスタムコマンド#Claude Certified Architect

【CCA Foundations対策 / Claude Code実践編 #3】カスタムコマンド・スキル・MCP・GitHub連携

Anthropic Academyの「Claude Code in Action」コースをもとに解説しています。

Claude Codeはコマンドラインツールとしての基本機能に加え、カスタムコマンド・パス別ルール・スキル・MCP連携といった拡張機能を持つ。今回はこれらの設定方法と、チーム共有 vs 個人専用のスコープの使い分けを整理する。

この記事でわかること：

  • .claude/commands/ でカスタムコマンドを作る方法と $ARGUMENTS の使い方
  • .claude/rules/ でパス別ルールをYAML frontmatterで設定する方法
  • .claude/skills/ のSKILL.md frontmatter（context: fork / allowed-tools / argument-hint）
  • claude mcp add でMCPサーバーを追加する手順
  • GitHub Actions連携のセットアップと CI/CD での注意点

カスタムコマンド：繰り返す作業を/コマンドにする

.claude/commands/ ディレクトリにMarkdownファイルを置くと、ファイル名がそのまま /コマンド名 になる。

.claude/
  commands/
    audit.md       → /audit
    write_tests.md → /write_tests

ファイルの内容がコマンドのプロンプトとして使われる。たとえば audit.md にこう書く：

以下の手順でプロジェクトの依存関係をチェックする：

1. npm audit を実行して脆弱なパッケージを確認する
2. npm audit fix で自動修正を適用する
3. テストを実行して修正が問題を引き起こしていないか確認する

/audit を実行するだけでこの手順が毎回再現される。

$ARGUMENTSで引数を受け取る

$ARGUMENTS プレースホルダーを使うとコマンドに引数を渡せる。

以下のファイルに対して包括的なテストを書く：$ARGUMENTS

テスト規約：

- Vitestを使う
- テストファイルは **tests** ディレクトリに置く
- ファイル名は [filename].test.ts(x)
- @/ プレフィックスでインポートする

対象：

- ハッピーパス
- エッジケース
- エラー状態

/write_tests src/hooks/use-auth.ts

ファイルパスに限らず、任意の文字列を渡せる。

チーム共有 vs 個人専用

場所 スコープ
.claude/commands/ リポジトリにコミット → チーム全員が使える
~/.claude/commands/ 自分の環境にのみ存在 → 個人専用

チームで共通のワークフローは .claude/commands/ に、自分だけの作業手順は ~/.claude/commands/ に置く。

.claude/rules/：パス別ルールをglobで適用する

プロジェクト全体のルールはCLAUDE.mdに書くが、ファイルの種類や場所によってルールを変えたい場合は .claude/rules/ を使う。

各ファイルにYAML frontmatterで glob パターンを指定する。

---
glob: "src/api/**/*"
---
# API実装規約

- レスポンスは必ずAPIResponseType型でラップする
- バリデーションはzodで行う
- エラーはHTTPException経由でスローする

---
glob: "**/*.test.*"
---
# テスト規約

- Vitestを使う
- モックはvi.mock()でファクトリ関数として書く
- アサーションはexpect().toEqual()を使う

src/api/ のファイルを編集しているときは API 規約のルールが適用され、テストファイルを編集しているときはテスト規約が適用される。関係のないルールがコンテキストに入らないため、Claudeの判断精度が上がる。

.claude/skills/：コンテキスト分離して実行するスキル

スキルはカスタムコマンドと似ているが、重要な違いがある。スキルは メインの会話コンテキストを汚染しない。

.claude/skills/ にSKILL.mdを置く。frontmatterで動作を制御する。

---
description: セキュリティ監査を実行する
argument-hint: 監査対象のディレクトリ（例: src/api）
context: fork
allowed-tools: Read, Grep, Bash(npm audit)
---

指定されたディレクトリのセキュリティ問題を調査する：$ARGUMENTS

確認項目：

- 依存関係の脆弱性
- 環境変数のハードコーディング
- 認証・認可の実装漏れ

frontmatterの各フィールド

フィールド 意味
context: fork メイン会話のコンテキストをコピーして独立したセッションで実行。メイン会話に影響しない
allowed-tools このスキルが使えるツールを制限する
argument-hint /コマンド名 入力時にヒントとして表示されるテキスト

context: fork が重要な設計ポイント。大量のファイルを読むスキル・長い調査を行うスキルをメイン会話で実行すると、コンテキストが膨大になる。fork にすると独立したコンテキストで動くため、メイン会話はクリーンなまま保てる。

📋 試験ガイドより
公式試験ガイドのIn-Scope Topicsに「Custom commands and skills: Project vs user scope, context: fork, allowed-tools, argument-hint frontmatter」が明記されている。スキルの context: fork はメイン会話のコンテキストを分離する設計パターンとして、コンテキスト管理の観点から試験の判断ポイントになっている。

MCPサーバーを追加する

claude mcp add コマンドでMCPサーバーを追加する。

claude mcp add playwright npx @playwright/mcp@latest

このコマンドは：

  1. MCPサーバーに名前（playwright）をつける
  2. サーバーを起動するコマンド（npx @playwright/mcp@latest）を登録する

追加後、Claude Codeが起動するとMCPサーバーも一緒に起動し、Claudeがそのツールを使えるようになる。

ツール権限の事前承認

MCPサーバーのツールを使うたびに許可を求めるプロンプトが出る。頻繁に使う場合は .claude/settings.local.json で事前承認できる。

{
  "permissions": {
    "allow": ["mcp__playwright"],
    "deny": []
  }
}

サーバー名のプレフィックス mcp__（アンダースコア2つ）に注意。

GitHub Actions連携

/install-github-app を実行するとセットアップウィザードが起動する。

  1. GitHubにClaude Codeアプリをインストール
  2. APIキーを追加
  3. ワークフローファイルを含むPRを自動生成

PRをマージすると .github/workflows/ に2つのワークフローが追加される。

Mentionワークフロー

IssueやPRで @claude とメンションすると、ClaudeがコードベースにアクセスしてタスクをこなしてPRで返答する。

PR自動レビューワークフロー

PRを作成するたびにClaudeが自動でレビューし、変更の影響分析とレポートをPRに投稿する。

ワークフローのカスタマイズ

生成されたワークフローファイルはカスタマイズできる。

- name: Project Setup
  run: |
    npm run setup
    npm run dev:daemon

custom_instructions: |
  プロジェクトは依存関係インストール済みで起動している。
  サーバーは localhost:3000 で動作中。ログは logs.txt に書き出されている。

mcp_config: |
  {
    "mcpServers": {
      "playwright": {
        "command": "npx",
        "args": ["@playwright/mcp@latest", "--allowed-origins", "localhost:3000"]
      }
    }
  }

GitHub Actions内でのツール権限

ローカル開発と異なり、GitHub Actions内ではMCPサーバーの各ツールを個別に列挙する必要がある。

allowed_tools: "Bash(npm:*),mcp__playwright__browser_snapshot,mcp__playwright__browser_click"

ローカルのような mcp__playwright 一括許可は使えない。CI/CDで使うツールは明示的にリストアップする。

📋 試験ガイドより
公式試験ガイドのIn-Scope Topicsに「Custom commands and skills: Project vs user scope, context: fork, allowed-tools, argument-hint frontmatter」とあわせて、Claude Code CLIの「-p / --print flag for non-interactive mode」が試験範囲に含まれる。GitHub Actions内でClaude Codeをバッチ実行する場合は -p フラグが必須（詳細は#5で解説）。

よくある誤解まとめ

誤解 実際
.claude/commandsのコマンドはチームに共有されない リポジトリにコミットされるため全員が使える。個人専用は~/.claude/commandsに置く
.claude/rules/のルールは常に全ファイルに適用される YAML frontmatterのglobパターンに一致するファイルを編集するときのみ適用される
スキルはカスタムコマンドと同じ context: forkで独立したコンテキストで動く。メイン会話を汚染しない点が異なる
GitHub ActionsでもローカルのMCP権限設定が使える CI/CDではツールを個別に列挙する必要がある
MCPサーバーの追加はUIから行う claude mcp add コマンドをターミナルで実行する

設計の判断基準

場面 やりがちな選択 正しい選択 判断の根拠
チームで共通のレビュー手順を自動化したい 毎回同じ指示をClaude Codeに送る .claude/commands/にコマンドを作成してコミットする チーム全員が/コマンドで呼び出せる
APIディレクトリだけに適用したいコーディング規約がある CLAUDE.mdに全ルールを書く .claude/rules/にglobパターン付きで書く 関係のないファイル編集時にルールがコンテキストに入らない
大量のファイルを調査するスキルを作りたい context指定なし（デフォルト）で作る context: forkで作る メイン会話のコンテキストを膨らませずにスキルを実行できる

まとめ

  • .claude/commands/（チーム共有）と ~/.claude/commands/（個人専用）でカスタムコマンドを管理する
  • .claude/rules/ のYAML frontmatterに glob パターンを指定してパス別ルールを適用できる
  • .claude/skills/ のSKILL.mdに context: fork / allowed-tools / argument-hint を設定する。context: fork でメイン会話のコンテキストを分離する
  • claude mcp add でMCPサーバーを追加。ローカルはサーバー名で一括許可できるがGitHub Actions内は各ツールを個別列挙
  • GitHub Actions連携は /install-github-app でセットアップ。CI/CDでは -p フラグが必要（#5で解説）

次回（#4）はHooks——PreToolUse / PostToolUseによる自動化と.envファイル保護の実装を解説する。

← #2：コードの変更とコンテキスト管理 ｜ #4：HooksでClaude Codeを自動化する →

← ブログ一覧に戻る