Claude Code Skills 共有管理 — 4つのAIツールを1リポジトリで統一する方法

「Claude Codeのスキル、Codexにもコピーしなきゃ...あ、OpenClawも...Antigravityも...」

AIコーディングツール、増えすぎじゃないですか。

2026年、開発者の手元には複数のAIアシスタントが同居するのが当たり前になりました。Claude Code で日常の開発、Codex で大規模リファクタリング、OpenClaw でSlack経由の問い合わせ対応、Antigravity で実験的なコード生成。それぞれ得意分野が違うから使い分ける（AIツールのポケモン状態）。ここまでは合理的。

でも、スキル（Skills）の管理がカオスになっていませんか？

ツールごとにスキルをコピペして、片方を更新したらもう片方が古いまま。セキュリティルールもバラバラ。「このツールではforce push禁止にしたけど、あっちは設定してなかった」なんて事故が起きかねない状況...心当たりありませんか？

この記事では、1つのスキルリポジトリを4つのAIツールで共有する仕組みを、実際のコードと設計思想を交えて紹介します。

Codex Skillsの使い方：3ステップで始める

「Codex Skills」って何ができるの？という方のために、まず具体的な使い方を紹介します。

Codex（OpenAI）のSkills機能は、タスク実行時にAIが参照するカスタム指示書です。SKILL.mdに手順・制約・スクリプトを定義しておくと、Codexが自動的にそれに従って動きます。

Step 1: スキルディレクトリを作成

mkdir -p ~/.codex/skills/my-first-skill

Step 2: SKILL.mdを書く

---
name: my-first-skill
description: |
  コミット前にlintとテストを自動実行するスキル。
  Use when: コードを変更してコミットする前に品質チェックしたいとき。
---

# Pre-commit Quality Check

1. `npm run lint` を実行し、エラーがあれば修正
2. `npm run test` を実行し、全テスト通過を確認
3. 問題なければコミットメッセージを提案

Step 3: Codexから呼び出す

codex "このPRの変更をレビューして、pre-commit quality checkスキルに従ってチェックして"

Codexは~/.codex/skills/配下のSKILL.mdを自動検出し、タスクに合ったスキルを選択して実行します。Claude Codeでも同じSKILL.mdがそのまま動くのが、Agent Skills標準の強みです。

ここからが本題——このスキルを複数ツールで共有する方法を見ていきましょう。

まず知りたい：4ツールの違いと使い分け

「そもそもこの4つ、何が違うの？」という方のために、主要な違いをまとめます。

特徴	Claude Code	Codex	OpenClaw	Antigravity
開発元	Anthropic	OpenAI	OSS (Peter Steinberger)	Google DeepMind
主な用途	汎用コーディング・日常開発	大規模リファクタリング・PR作成	Slack/Discord AIアシスタント	実験的コード生成
実行環境	CLI（ターミナル）	CLI / Web	セルフホスト（Docker等）	IDE（エージェント型）
LLMバックエンド	Claude	GPT-5.4 / GPT-5.4-mini	任意（Gemini, Claude, Local LLM）	Gemini
Agent Skills対応	✅	✅	✅	✅
設定ファイル	settings.json	config.toml	openclaw.json	.gemini/settings.json
スキルパス	~/.claude/skills/	~/.codex/skills/	~/.openclaw/skills/	~/.gemini/antigravity/skills/
特徴的な強み	CLAUDE.md + hooksによる高いカスタマイズ性	サンドボックス実行による安全性	マルチプラットフォーム連携	Googleエコシステム統合

4つともAgent Skills標準に対応しているため、同じスキル定義がどのツールでも動くのがポイントです。ただし、セキュリティ設定やツール固有の設定は互換性がありません（詳しくは後述）。

「どれか1つだけ使う」なら設定の共有は不要ですが、用途に応じて2つ以上使い分けているなら、スキル管理の一元化が効いてきます。Claude CodeとCodexの料金・性能の実測比較も参考にしてください。

この記事で学べること

• 複数のAIコーディングツール間でSkillsをsymlinkで共有する方法
• セキュリティポリシーをツール間で揃える現実的なアプローチ
• Nix（home-manager）で設定配布を自動化する実装例

前提条件

• AIコーディングツールを2つ以上使っている（または使う予定がある）
• シェル操作に抵抗がない
• dotfilesの概念を理解している（Nix部分はオプション）

Agent Skillsという共通言語

まず、なぜ「共有」が可能になったのか。

Agent Skillsというオープンスタンダードが登場し、AIコーディングツール間でスキル定義の互換性が生まれました。Claude Code、OpenClaw、Codex、Antigravityがいずれもこの標準に対応しています。

つまり、SKILL.mdとスクリプト群で構成されるスキルは、どのツールに置いても同じように動く。これが大前提です。

各ツールのスキル格納パスはこうなっています。

ツール	スキルパス
Claude Code	~/.claude/skills/
OpenClaw	~/.openclaw/skills/
Codex	~/.codex/skills/
Antigravity	~/.gemini/antigravity/skills/

4箇所に同じものを置きたい。コピーではなくsymlinkで。1つの真実（Single Source of Truth） を維持するために。コピペ同期なんて、3日で破綻します（体感では2日）。

実装方法：symlinkで4ツールを接続する

Step 1: スキル専用リポジトリを作る

まず、スキルをdotfilesから分離します。「dotfilesの中にまとめておけばいいのでは？」と思いますよね。最初は私もそう思っていたのですが、スキルは更新頻度が高く、dotfilesとはライフサイクルが違うんです。

# ghq管理の場合
ghq create it-all-playpark/skills

# 通常のgit管理の場合
mkdir -p ~/skills && cd ~/skills && git init

ディレクトリ構成はこんな感じです。

skills/
├── dev-flow/          # 開発フロー自動化
│   ├── SKILL.md
│   └── scripts/
├── pr-iterate/        # PRイテレーション
│   ├── SKILL.md
│   └── scripts/
├── git-commit/        # コミット支援
│   └── SKILL.md
├── _lib/              # 共通ライブラリ
│   ├── common.sh
│   └── schemas/
└── README.md

Step 2: セットアップスクリプトでsymlinkを一括作成

手動でsymlinkを4つ張る？ それは最初の1回だけ正しく動く方法です（2回目以降は忘れる）。

スクリプトにしましょう。

#!/usr/bin/env bash
set -euo pipefail

# スキルリポジトリのパス
SKILLS_REPO="${HOME}/ghq/github.com/it-all-playpark/skills"

# ツールごとの設定: "設定ディレクトリ:スキルサブパス"
AGENT_CONFIGS=(
    "${HOME}/.claude:skills"
    "${HOME}/.openclaw:skills"
    "${HOME}/.codex:skills"
    "${HOME}/.gemini:antigravity/skills"
)

for config in "${AGENT_CONFIGS[@]}"; do
    IFS=':' read -r config_dir skills_subpath <<< "$config"
    target_path="${config_dir}/${skills_subpath}"
    parent_dir=$(dirname "$target_path")

    # 親ディレクトリがなければ作成
    mkdir -p "$parent_dir"

    # 既存のディレクトリ（実体）はバックアップ
    if [ -e "$target_path" ] && [ ! -L "$target_path" ]; then
        backup="${target_path}.backup.$(date +%Y%m%d%H%M%S)"
        echo "Backing up: $target_path → $backup"
        mv "$target_path" "$backup"
    fi

    # symlinkを作成（既存のsymlinkは上書き）
    ln -sfn "$SKILLS_REPO" "$target_path"
    echo "Linked: $target_path → $SKILLS_REPO"
done

ポイントはln -sfnの-nフラグ。これがないと、既存のsymlinkがディレクトリを指している場合に中にsymlinkが作られるという罠にハマります（経験者は語る）。

Step 3: 動作確認

# 全ツールのスキルパスが同じ場所を指しているか確認
for dir in ~/.claude/skills ~/.openclaw/skills ~/.codex/skills ~/.gemini/antigravity/skills; do
    echo "$dir → $(readlink -f "$dir" 2>/dev/null || echo 'NOT FOUND')"
done

出力がすべて同じパスを指していれば成功です。

/Users/you/.claude/skills → /Users/you/ghq/.../skills
/Users/you/.openclaw/skills → /Users/you/ghq/.../skills
/Users/you/.codex/skills → /Users/you/ghq/.../skills
/Users/you/.gemini/antigravity/skills → /Users/you/ghq/.../skills

1つ更新すれば、4つ全部に反映される。 コピペ地獄からの解放です。

セキュリティポリシー、揃えたいけど自動化はしない

スキルの共有ができたら、次に気になるのがセキュリティです。

「全ツールで同じセキュリティルールを適用したい」——気持ちはわかります。でも先に結論を言うと、フォーマット変換ツールは作っていません。作る気もありません。

なぜか。各ツールの設定フォーマットがまったく違うし、しかもよく変わるからです。

フォーマットの現実を見てみましょう

Claude Codeのsettings.json：

{
  "permissions": {
    "deny": [
      "Bash(git push --force:*)",
      "Bash(git reset --hard:*)",
      "Bash(sudo:*)",
      "Read(./.env)",
      "mcp__gh__merge_pull_request"
    ]
  }
}

Codexのdefault.rules：

prefix_rule(pattern=["git", "push", "--force"], decision="forbidden")
prefix_rule(pattern=["git", "reset", "--hard"], decision="forbidden")
prefix_rule(pattern=["sudo"], decision="forbidden")
# Read(.env)制限 → prefix_ruleでは表現不可
# MCP制限 → Codexは未対応

OpenClawのopenclaw.json：

{
  "channels": {
    "slack": {
      "groupPolicy": "allowlist",
      "channels": { "#general": { "allow": true } }
    }
  }
}

OpenClawにはそもそもコマンドレベルのセキュリティ制御がありません（チャンネルアクセスだけ）。

表現能力の壁

同じ「force push禁止」でも、こんなに書き方が違います。

やりたいこと	Claude Code	Codex	OpenClaw
force push禁止	"Bash(git push --force:*)"	prefix_rule(pattern=["git","push","--force"], decision="forbidden")	不可
.env読み取り禁止	"Read(./.env)"	表現不可	不可
MCP操作制限	"mcp__gh__*"	MCP未対応	不可
globパターン	"Bash(mv /*)"	リテラルマッチのみ	不可

ワイルドカードの文法も違う、対応できる制御レイヤーも違う。1対1で変換できるルールは全体の半分もありません。

じゃあどうしてるか

実際にやっていることはシンプルです。Claude Codeに「この設定と同じ意図のルールをCodex形式で作って」と頼む。 それだけです。

# 実際の作業フロー
1. Claude Code の settings.json を先に整備する（ベースライン）
2. Claude Code に「このdenyリストと同等のCodex rulesを作って」と依頼
3. 表現できないルールはコメントとして記録（将来対応の備忘）
4. 生成されたrulesをdotfilesにcommit

「変換ツールを作ればいいのでは？」と思いますよね。私も一瞬考えました。でも、各ツールの設定フォーマットがアップデートのたびに微妙に変わるんです。Codexのprefix_ruleの文法も初期から何度か変わっていますし、Claude Codeのpermissions構造もdenyのマッチングルールが追加されたりしている。変換ツールのメンテコストが、手動で頼む手間を確実に上回ります。

それに、AIコーディングツールに設定ファイルの変換を頼むの、わりと得意分野じゃないですか（自分の設定ファイルなんだから当然ではある）。

大事なのは「何を禁止するか」のリスト

ツールに依存しない形で禁止ポリシーを言語化しておくこと、これが一番効きます。

# どのツールでも絶対に実行させたくないこと
- git push --force（歴史改変、ダメ、絶対）
- git reset --hard（やり直しの効かない巻き戻し）
- 保護ブランチへの直push（main直push事件は一度で十分）
- sudo（AIにroot権限を渡すのは家の鍵を初対面の人に渡すようなもの）
- rm -rf（説明不要）

このリストがあれば、新しいツールが来ても、フォーマットが変わっても、「このポリシーで作って」と言えば済む。変換ロジックではなく意図の共有が、結局いちばんポータブルです。

Nix（home-manager）で配布を自動化する

ここからはオプションです。「symlinkスクリプトで十分」という方はスキップしてOK。

Nixで環境管理している場合、home-managerのactivation scriptでスキルリポジトリ以外の設定（OpenClawのopenclaw.jsonやCodexのconfig.toml）もまとめて配布できます。

home-manager activation の例

home.activation = {
  # Claude Code設定のsymlink
  setupClaudeCode = lib.hm.dag.entryAfter ["writeBoundary"] ''
    DOTFILES_CLAUDE="$HOME/ghq/.../dotfiles/claude-code"
    CLAUDE_DIR="$HOME/.claude"
    mkdir -p "$CLAUDE_DIR"

    # settings.jsonをsymlink（セキュリティルール含む）
    ln -sf "$DOTFILES_CLAUDE/settings.json" "$CLAUDE_DIR/settings.json"

    # markdownファイル群
    for f in CLAUDE.md PRINCIPLES.md RULES.md; do
      [ -f "$DOTFILES_CLAUDE/$f" ] && \
        ln -sf "$DOTFILES_CLAUDE/$f" "$CLAUDE_DIR/$f"
    done
  '';

  # OpenClaw設定のsymlink
  setupOpenclaw = lib.hm.dag.entryAfter ["writeBoundary"] ''
    ln -sfn "$HOME/ghq/.../dotfiles/openclaw" "$HOME/.openclaw"
  '';

  # Codex設定の配布（base + localのマージ）
  setupCodex = lib.hm.dag.entryAfter ["writeBoundary"] ''
    CODEX_DIR="$HOME/.codex"
    DOTFILES_CODEX="$HOME/ghq/.../dotfiles/codex"
    mkdir -p "$CODEX_DIR"

    # 静的アセットはsymlink
    for dir in prompts policy; do
      ln -sfn "$DOTFILES_CODEX/$dir" "$CODEX_DIR/$dir"
    done

    # config.tomlはbase + localをマージして生成
    if [ -f "$CODEX_DIR/config.local.toml" ]; then
      cat "$DOTFILES_CODEX/config.base.toml" \
          "$CODEX_DIR/config.local.toml" \
          > "$CODEX_DIR/config.toml"
    fi
  '';
};

nix run .#update 一発で、全ツールの設定が最新になる。新しいマシンでも、リポジトリをcloneしてコマンド1つ叩けば同じ環境が再現される（セットアップに丸一日費やした日々よ、さようなら）。

Nix管理で注意すべきハマりポイント

ここで1つ、実際にハマった罠を共有します。「Nixで全部管理すれば完璧だ」と思いきや、落とし穴がありました。

home-managerのactivation scriptでスキルのsymlinkを管理すると、nix run .#updateのたびにセットアップスクリプトが張ったsymlinkを上書きしてしまうことがあります。

初期状態（setup-skills.sh実行後）:
~/.claude/skills → ~/ghq/.../skills ✅

nix run .#update 実行:
1. activation scriptが発動
2. 既存のsymlinkを削除
3. 新しいsymlinkを作成 → dotfiles/claude-code/skills（存在しない）
4. symlink切れ ❌

解決策はシンプル。スキルのsymlinkはactivation scriptから外して、セットアップスクリプトに一元化する。 管理の責務を分けることが大切です。

管理対象	管理方法	理由
settings.json, *.md	home-manager activation	dotfilesに実体がある
skills/	setup-skills.sh	別リポジトリ、独立したライフサイクル
config.toml (Codex)	home-manager activation	base + localのマージが必要

全体像：設定の流れ

最終的な構成をまとめます。

dotfiles/                          skills/ (別リポジトリ)
├── claude-code/                   ├── dev-flow/
│   ├── settings.json ─symlink→    ├── pr-iterate/
│   ├── CLAUDE.md                  ├── git-commit/
│   └── ...                        └── _lib/
├── openclaw/                           ↑
│   └── openclaw.json                   │ symlink
├── codex/                              │
│   ├── config.base.toml           ~/.claude/skills ──────┘
│   ├── rules/                     ~/.openclaw/skills ────┘
│   └── policy/                    ~/.codex/skills ───────┘
└── home-manager/                  ~/.gemini/.../skills ──┘
    └── home/default.nix
         ↓ activation
    nix run .#update

dotfilesがツール固有の設定を、skillsリポジトリが共有スキルを管理する。 役割が明確に分かれているから、どちらかを更新しても他方に影響しません。

注意点・Tips

• symlinkの向き先を確認する習慣をつける: ls -la ~/.claude/skills を定期的に。壊れたsymlinkはエラーも出さずに無言で動かなくなります（犯人探しに30分溶けます）
• スキルリポジトリにはCIを入れる: bash -nでシェルスクリプトの構文チェック、jq emptyでJSONスキーマ検証。4ツールに波及するから、壊れたスキルの影響範囲も4倍です
• 機密情報は.localファイルに分離: config.base.toml（Git管理）とconfig.local.toml（ローカル専用）の2層構造にすることで、API キーをうっかりcommitする事故を防げます
• OpenClawのconfig setコマンドには要注意: 環境変数${VAR}を展開してハードコードしてしまうため、設定ファイルは必ずエディタで直接編集すること

まとめ

AIコーディングツールが増えるたびに設定をコピペしていた時代は終わりです。

symlinkによるスキル共有で4ツールを1リポジトリに統一し、禁止ポリシーの言語化とAIコーディングツール自身による設定生成でセキュリティ水準を揃え、Nix（home-manager） で設定配布を自動化する。この3層のアプローチで、ツールが増えてもスケールする開発環境が手に入ります。

新しいAIツールが登場したら？ AGENT_CONFIGS配列に1行追加して、スクリプトを再実行するだけ。5つ目のツールが来ても、6つ目が来ても、やることは変わりません。

---

あわせて読みたい

• 【2026年最新】Claude Code vs Codex vs Antigravity 完全比較 — 実プロジェクトで選ぶAIコーディングツール
• 【実測比較】Claude Code vs Codex 料金・性能 — 実プロジェクトで使い比べてわかった選び方
• 【Claude Code】settings.json完全ガイド - CLAUDE.mdとの使い分けで最適なAI開発環境を構築 — Claude Code単体のカスタマイズを深掘り
• 【Claude Code Skills】SKILL.mdの書き方と設計パターン — 共有するSkillsの設計指針
• 【OpenClaw × Slack】AIアシスタント構築実践 — OpenClawの実運用事例

---

AIコーディングツール比較・選定ガイド — この記事を含む9本の記事で、AIコーディングツールの比較・選定・共存運用を体系的に解説しています。