CLAUDE LABEN
FORK — Claude Code 2.1.212で/forkの挙動が変わりました。会話を新しいバックグラウンドセッションへ複製し、作業を続けたまま並走できます。従来のセッション内サブエージェントは/subtaskに移りましたLIMITS — WebSearchの呼び出しがセッション単位で既定200回に制限されました。サブエージェントの起動も既定200回が上限で、暴走した検索・委譲のループを止められますMCPBG — 2分を超えるMCPツール呼び出しは自動的にバックグラウンドへ移り、セッションが固まらなくなりました。しきい値はCLAUDE_CODE_MCP_AUTO_BACKGROUND_MSで調整できますPLANFIX — プランモードがtouchやrmといったファイルを変更するBashコマンドを、許可プロンプトもcanUseToolコールバックも通さずに実行してしまう不具合が修正されましたSONNET5 — Claude Sonnet 5は導入価格として入力100万トークンあたり2ドル、出力10ドルで提供中です。8月31日を過ぎると3ドルと15ドルに戻りますIPO — Anthropicが早ければ10月の株式公開を視野に、引受銀行が投資家との面談を組み始めたと報じられていますFORK — Claude Code 2.1.212で/forkの挙動が変わりました。会話を新しいバックグラウンドセッションへ複製し、作業を続けたまま並走できます。従来のセッション内サブエージェントは/subtaskに移りましたLIMITS — WebSearchの呼び出しがセッション単位で既定200回に制限されました。サブエージェントの起動も既定200回が上限で、暴走した検索・委譲のループを止められますMCPBG — 2分を超えるMCPツール呼び出しは自動的にバックグラウンドへ移り、セッションが固まらなくなりました。しきい値はCLAUDE_CODE_MCP_AUTO_BACKGROUND_MSで調整できますPLANFIX — プランモードがtouchやrmといったファイルを変更するBashコマンドを、許可プロンプトもcanUseToolコールバックも通さずに実行してしまう不具合が修正されましたSONNET5 — Claude Sonnet 5は導入価格として入力100万トークンあたり2ドル、出力10ドルで提供中です。8月31日を過ぎると3ドルと15ドルに戻りますIPO — Anthropicが早ければ10月の株式公開を視野に、引受銀行が投資家との面談を組み始めたと報じられています
記事一覧/Claude Code
Claude Code/2026-05-06上級

gh skillで実現するマルチエージェント開発体制 — SKILL.mdのバージョン管理・CI/CD連携・エージェント別最適化の設計

gh skillを使ったSKILL.mdのチーム横断配布を本番運用する方法。バージョン管理戦略、GitHub Actions連携、エージェント別スキル最適化、モノレポ対応まで、実際の設計パターンを詳しく解説します。

Claude Code197SKILL.md6gh skill2マルチエージェント6GitHub Actions12チーム開発4上級4

個人でClaude Codeを使っている分には、SKILL.mdをローカルで管理するだけで十分です。しかしチーム開発になると話が変わります。「誰がいつスキルを更新したか」「この変更は全員に伝わっているか」「本番環境と開発環境でスキルが食い違っていないか」——こういった問いに答えられる体制が必要になります。

gh skill はそのインフラを提供するツールですが、それを本番品質で運用するには、設計の深さが求められます。ここでは私が実際のプロジェクトで試行錯誤しながら構築したマルチエージェント・スキル管理の設計パターンをお伝えします。

なぜスキル管理に「設計」が必要なのか

まず、よくある失敗パターンを共有します。

gh skillを使い始めた初期段階で、多くのチームがやりがちなのが「とりあえず一つのリポジトリに全部のスキルをまとめる」アプローチです。これは最初は便利に見えますが、すぐに問題が出ます。

バックエンドチームが追加したスキルがフロントエンドの作業を邪魔したり、AIエージェントが矛盾する指示を受け取ったりします。「このプロジェクトではTypeScriptを使う」と「JavaScriptを優先する」が同じスキルセットに共存するような状況です。

設計が必要な理由はここにあります。スキルにはスコープがあります。それを意識した構造にしないと、スケールしません。

スキルリポジトリの構造設計

本番運用に耐えるスキルリポジトリの構造を紹介します。

team-skills/
├── skill.yaml                    # メインメタデータ
├── README.md
├── CHANGELOG.md
├── .github/
│   └── workflows/
│       ├── validate.yml          # スキルの自動検証
│       └── release.yml           # バージョンリリース自動化
├── base/
│   ├── code-style.md             # 全プロジェクト共通ルール
│   └── git-workflow.md           # Gitフロー
├── frontend/
│   ├── react-patterns.md         # Reactのパターン集
│   └── testing-frontend.md       # フロントエンドテスト
├── backend/
│   ├── api-design.md             # API設計規約
│   └── database-patterns.md      # DBパターン
└── agent-overrides/
    ├── claude-code-specific.md   # Claude Code専用の高度な設定
    └── copilot-hints.md          # Copilot向け補完ヒント

skill.yaml でこの構造を定義します:

name: team-skills
version: 2.1.0
description: "チーム共通コーディングスキル集"
maintainer: "platform-team@example.com"
 
agents:
  - claude-code
  - copilot
  - cursor
  - gemini-cli
 
# プロファイル: 役割別にスキルセットをグループ化
profiles:
  frontend:
    skills:
      - base/code-style.md
      - base/git-workflow.md
      - frontend/react-patterns.md
      - frontend/testing-frontend.md
    agents: [claude-code, copilot, cursor]
 
  backend:
    skills:
      - base/code-style.md
      - base/git-workflow.md
      - backend/api-design.md
      - backend/database-patterns.md
    agents: [claude-code, copilot, cursor, gemini-cli]
 
  fullstack:
    extends: [frontend, backend]
 
# エージェント固有の追加設定
agent_overrides:
  claude-code:
    append: agent-overrides/claude-code-specific.md
  copilot:
    append: agent-overrides/copilot-hints.md

プロファイルを使うことで、フロントエンドエンジニアは gh skill install team/team-skills --profile frontend、バックエンドエンジニアは --profile backend と使い分けられます。

セマンティックバージョニングとCHANGELOGの運用

スキルはコードと同様に、変更履歴を管理する必要があります。私はセマンティックバージョニングを採用しています。

  • MAJOR(例:1.0.0 → 2.0.0): 既存のスキルを大幅に書き換えたり、削除したりした場合。AIの動作が大きく変わる可能性がある変更。
  • MINOR(例:1.0.0 → 1.1.0): 新しいスキルや指示を追加した場合。既存の動作は変えありません。
  • PATCH(例:1.0.0 → 1.0.1): 誤字修正、表現の改善など。機能的な変化なし。

CHANGELOG.md にはどのAIエージェントの動作が変わったかを明記します:

## [2.1.0] - 2026-04-15
### Added
- `backend/database-patterns.md`: PostgreSQL jsonb型の扱い方を追加
  - Agents affected: Claude Code, Copilot, Cursor
- `agent-overrides/claude-code-specific.md`: PreToolUseフックの標準設定を追加
  - Agents affected: Claude Code only
 
### Changed
- `base/code-style.md`: TypeScript strictモードを必須に変更
  - Breaking change for agents: all
  - Migration guide: tsconfig.jsonにstrict:trueを追加してください
 
## [2.0.0] - 2026-03-01
### Removed
- `frontend/vue-patterns.md`: プロジェクトのReact統一に伴い削除

GitHub Actionsによる自動検証パイプライン

スキルファイルの品質を人間のレビューだけに頼るのは限界があります。CIで自動検証するパイプラインを組みます。

# .github/workflows/validate.yml
name: Validate Skills
 
on:
  pull_request:
    paths:
      - '**.md'
      - 'skill.yaml'
 
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
 
      - name: Setup gh skill
        run: gh extension install github-actions/gh-skills
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 
      - name: Validate skill.yaml structure
        run: gh skill validate
 
      - name: Check for broken internal links
        run: |
          # スキルファイル間の参照整合性チェック
          gh skill lint --check-links
 
      - name: Verify agent compatibility
        run: |
          # 各エージェントへのデプロイシミュレーション
          gh skill dry-run --agent claude-code
          gh skill dry-run --agent copilot
          gh skill dry-run --agent cursor
 
      - name: Check CHANGELOG updated
        run: |
          # スキルの変更時にCHANGELOGが更新されているか確認
          if git diff --name-only origin/main | grep -q "\.md$"; then
            if ! git diff --name-only origin/main | grep -q "CHANGELOG.md"; then
              echo "❌ スキルファイルが変更されましたが、CHANGELOGが更新されていません"
              exit 1
            fi
          fi

リリースの自動化も設定します:

# .github/workflows/release.yml
name: Release Skills
 
on:
  push:
    tags:
      - 'v*'
 
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
 
      - name: Create GitHub Release
        uses: actions/create-release@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          tag_name: ${{ github.ref }}
          release_name: Release ${{ github.ref }}
          body_path: CHANGELOG.md
 
      - name: Notify team via Slack
        run: |
          # チームへのSlack通知(スキルが更新されたことを知らせる)
          curl -X POST "${{ secrets.SLACK_WEBHOOK }}" \
            -d "{\"text\": \"🎯 team-skills ${{ github.ref }} がリリースされました。\ngh skill update team-skills で更新してください。\"}"

エージェント別のスキル最適化

最も重要で、かつ見落とされがちな点が「エージェントによる解釈能力の差」です。

Claude Codeが最も深く解釈できること

Claude Codeは現時点で最もリッチなスキル解釈ができます。以下はClaude Code専用の高度な設定例です:

<!-- agent-overrides/claude-code-specific.md -->
## PreToolUseフック設定
 
以下のファイルへの書き込み前に必ず確認を取ること:
- `production.env`
- `database/migrations/`
- `src/auth/`
 
## ツール使用制限
 
本番環境(NODE_ENV=production)では以下のコマンドを実行しないこと:
- `npm run migrate`
- `git push --force`
- データベースへのDELETEクエリ
 
## ワークフロー定義
 
コードレビューを求められた場合、以下の順序で実行すること:
1. 型エラーのチェック(tsc --noEmit)
2. リントの実行(eslint src/)
3. テストの実行(npm test)
4. セキュリティスキャン(npm audit)

GitHub Copilotへの指示の書き方

Copilotはより単純な指示しか解釈しません。「〜すること」「〜しないこと」という明確な命令文が効果的です:

<!-- agent-overrides/copilot-hints.md -->
## コードスタイル
 
- TypeScriptを使用する。anyは使わない
- 関数はアロー関数を優先する
- コメントは日本語で書く
- エラーハンドリングは必ずcatch節を含める
 
## 禁止事項
 
- console.logをそのままコミットしない
- ハードコードされたURLや認証情報を書かない

Cursorとの統合

Cursorは .cursorrules と SKILL.md の両方を参照できますが、gh skillがインストールするのはプロジェクトルートの .cursor/skills/ ディレクトリです。既存の .cursorrules と競合しないよう注意が必要です:

# Cursorユーザー向け:既存の.cursorrulesとの統合
gh skill install team/team-skills --agent cursor --no-override-rules

モノレポでのスキル管理

モノレポ環境では、パッケージごとに異なるスキルを適用したい場合があります:

monorepo/
├── skill.yaml          # 共通スキル
├── packages/
│   ├── frontend/
│   │   └── skill.yaml  # フロントエンド専用(共通スキルを継承)
│   └── backend/
│       └── skill.yaml  # バックエンド専用

各パッケージの skill.yaml では親の設定を継承しつつ拡張できます:

# packages/frontend/skill.yaml
extends: ../../skill.yaml
name: frontend-skills
additional_skills:
  - skills/react-specific.md
  - skills/storybook-patterns.md

実際に運用してわかったこと

半年ほどこの仕組みを使ってみて、印象的だったのは「AIへの指示の品質が可視化される」という点でした。SKILL.mdをPRレビューの対象にすることで、「この指示は曖昧すぎてAIが意図通りに動かない」という問題が議論の俎上に乗るようになりました。

コードのコーディング規約はlinterで自動チェックできますが、AIへの指示の品質はこれまで個人の感覚に委ねられていました。gh skillとGitフローを組み合わせることで、初めてそれが「チームの資産」として管理できるようになります。

スキルリポジトリのトップレベルに examples/ ディレクトリを作り、「このスキルを使ったときにAIがどう応答するか」のサンプルを置いておくと、新しいチームメンバーへのオンボーディングにも使えます。

設計は最初は大げさに見えても、チームが5人を超えたあたりから「あのときちゃんと作っておいてよかった」と感じる部分です。最初から完璧にしなくていいですが、少なくとも skill.yaml の構造とCHANGELOGの運用だけは最初に決めておくことをお勧めします。

シェア

お読みいただきありがとうございます

Claude Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

もしこの記事がお役に立ちましたら、チップ(¥150)で応援いただけると大変励みになります。広告なしでの運営を続けるため、皆さまのご支援が大きな力になっています。

関連記事

Claude Code2026-05-06
SKILL.mdをClaude Code以外でも使えるようにする「gh skill」の仕組みと使い方
GitHubのgh skillコマンドを使うと、Claude Code向けに書いたSKILL.mdをGitHub Copilot・Cursor・Gemini CLIなど30以上のAIエージェントで共有できます。仕組みと実践的な使い方を解説します。
Claude Code2026-03-19
Unity × Claude Code 実践ワークフロー — シェーダー自動生成からCI/CDまで【上級編】
Unity 開発に Claude Code を組み込んで半年運用した実体験から、URP シェーダー自動生成・エディタ拡張・GitHub Actions CI/CD・実機パフォーマンス測定の実装と、サンプルでは見えない運用上の落とし穴を、動くコードと実測値つきで整理します。
Claude Code2026-06-24
Claude Design 由来のプロトタイプを本番化する — 単一ソース・CI・OGP自動生成の実装
Claude Design で作ったプロトタイプを Claude Code で本番運用に耐える形へ。生成物ランタイムを土台にする判断、ロジックを mixin で分離する構成、取引台帳を単一ソースにするデータ設計、GitHub Actions による自動更新と OGP 画像の実ブラウザ生成まで、実装込みで解説します。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →