【AI開発環境】4つのAIコーディングツールのSkillsを1リポジトリで統一管理する方法

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

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

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

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

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

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

この記事で学べること

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

前提条件

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

Agent Skillsという共通言語

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

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

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

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

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禁止」でも、こんなに書き方が違います。

ワイルドカードの文法も違う、対応できる制御レイヤーも違う。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から外して、セットアップスクリプトに一元化する。 管理の責務を分けることが大切です。

全体像：設定の流れ

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

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つ目が来ても、やることは変わりません。