Claude Code skills を Gemini へ移行 2026：SKILL.md を Gem にワンクリック
Claude Code skills を Gemini へ移行 2026：SKILL.md を Gem にワンクリック
結論から： Claude Code でコードレビュー、commit message、ブログ執筆、AEO 監査など 30 個の skill を積み上げてきた人も、Gemini に乗り換えるのに書き直しは不要、コピペすらいりません。GeminiDesktop は ~/.claude/skills と project/.claude/skills を自動スキャンし、各 SKILL.md の YAML frontmatter と本文を Gem（Gemini のカスタム Agent コンテナ）に 1 対 1 でマッピング —— name、description、system_prompt が揃います。
一言で： SKILL.md を「複数 Agent 共通の prompt ソースコード」として扱う。Claude Code / Cursor / Gemini が同じファイルを消費できます。
すでに 30 個の skill を書いた —— 書き直す必要はない
2024 年後半に Anthropic が Agent Skills の仕様を公開して以来、Claude Code ユーザーのカスタム skill 蓄積ペースが一気に加速しました。/commit、/review-pr、/blog-writer、/improve-aeo-geo…… 30 を超えると、「Agent を変えると prompt を全部書き直し」がリアルな乗り換えコストになります。
しかし skill の本質的価値は特定の Agent runtime に縛られていることではありません。繰り返し磨き上げて、実行可能な運用マニュアルになった Markdown テキスト にこそ価値があります。そのテキストは Claude Code では slash command として呼べるし、Cursor では .cursorrules に貼れるし、Gemini では理論上 Gem の system_prompt として注入できます。
問題は「手動翻訳がどのくらい必要か」だけ。Gemini Desktop では自動スキャン + 自動マッピングで ゼロ設定・ゼロコピペ にしました。
Claude Code skill 構造のおさらい
Anthropic 公式仕様（2024 年 8 月確定）のレイアウトをざっと復習:
---
name: review-commit-push
description: Review code, commit with context, and push with type-check auto-fix
allowed-tools: Bash, Edit, Read, Grep
---
# Review Commit Push
When the user asks to commit, follow this procedure:
1. Run `git status` and `git diff --staged`
2. Analyze changes and draft a conventional commit message
3. ...コアフィールド:
| フィールド | ソース | 意味 | Gem への対応 |
|---|---|---|---|
name |
YAML frontmatter | slash command 名 + Agent 内部 ID | Gem name |
description |
YAML frontmatter | トリガー + 1 行説明 | Gem description |
allowed-tools |
YAML frontmatter | 使用許可ツールのホワイトリスト | 現状は記録のみ、自動転送はしない（後述） |
| 本文 Markdown | frontmatter 以降 | 運用マニュアル・ルール・例 | Gem system_prompt |
本文は 500〜3,000 語のプロンプトテキストで、チェックリスト・判断ツリー・コードテンプレートを含みます。ここが「Agent を跨ぐ時にもっとも自動化する価値のある部分」です。
GeminiDesktop のスキャンパス：~/.claude/skills + project/.claude/skills
起動時 GeminiDesktop は次の順でスキャンします（2 段階 fallback）:
- グローバル:
~/.claude/skills/*/SKILL.md—— 個人の汎用 skill（/commit、/review等） - プロジェクト:
<cwd>/.claude/skills/*/SKILL.md—— プロジェクト固有 skill（BibiGPT なら/topic-finder、/blog-writer等）
マージ時は同名 skill についてプロジェクトレベルが優先 —— Claude Code 本体と同じ挙動です。スキャンはインクリメンタルで、各 SKILL.md の mtime を記憶し、変更されたファイルだけ再インポートします。
インポート後の Gem は Gemini チャットボックスの「/」ドロップダウンに素の Gem と並列で現れ、見た目の違いはありません。
インポートルール：name / description / body → Gem system_prompt
マッピング規則の詳細:
| SKILL.md フィールド | Gem フィールド | 変換 |
|---|---|---|
name: review-commit-push |
Gem name: review-commit-push |
そのまま |
description: ... |
Gem description | そのまま、最大 512 文字 |
| 本文 Markdown | Gem system_prompt | UTF-8-safe 32KB 切り詰め、マルチバイト文字の途中で切らない |
allowed-tools |
Gem metadata tags | タグとして表示のみ、MCP tool 自動バインドなし |
32KB の理由: Gemini 2.5 Pro の systemInstruction 上限が 32KB。99% の skill には十分（SKILL.md の中央値は 6〜8KB）ですが、prompt に大量の例を積んだ skill は超える可能性があります。その場合 GeminiDesktop は末尾に [...truncated at 32KB, original file at /path/to/SKILL.md] を挿入して切られたことを明示。手動で削る判断材料になります。
UTF-8-safe 切り詰め: CJK 文字は UTF-8 で 3 バイト占有するため、単純なバイト切断は文字を半分で切り、デコードエラーを生みます。GeminiDesktop の切り詰めは直近の正当なコードポイント境界まで戻り、常に有効な UTF-8 を保証します。
MCP tool 自動転送を見送った理由
技術的には allowed-tools: Bash, Edit, Read を Gemini の MCP tool バインディングに変換できます。意図的にやりませんでした。理由は 2 つ:
理由 1: skill の多くは shell/git 環境への暗黙依存を持つ
review-commit-push は cwd が git リポジトリであることを前提にしているし、commit は husky hooks を前提、topic-finder は gcloud や GSC CLI のログイン済みを前提にしています。これらの暗黙前提は Claude Code のローカル shell ではデフォルトで成立しますが、Gemini の実行サンドボックス（特に Web UI）ではまったく異なる可能性があります。
Bash tool を雑に転送すると、ユーザーが Gem から skill を呼んで git status が失敗するのを見ることになり、「参照ドキュメントとして読む」よりも悪い体験を生みます。
理由 2: セキュリティ境界が不明瞭
Claude Code の allowed-tools は緩いホワイトリストであって、強制サンドボックスではありません。Gemini が実行を引き受けるなら、各 skill が本当にホワイトリスト内の操作しかしないかを再監査する必要がある —— データ漏洩や破壊的操作のリスクがあるからです。この監査コストはフィールド対応より遥かに大きい。
現状の挙動: SKILL.md の本文は system_prompt にフル注入されるので、Gem は skill が「何をすべきか」を知っています。実行はユーザー手動呼び出しか明示的な MCP server バインディングで行います。次のステップは opt-in 自動ブリッジ —— SKILL.md に gemini-bridge: auto を書いた skill だけ自動配線します。
Agent 跨ぎ再利用のベストプラクティス
上のマッピング規則を踏まえて、「Agent 跨ぎで使える skill」を書くための習慣を整理します:
- ツール依存を最小化。 pure prompt で解けるロジックに bash スクリプト依存を足さない。「git diff を分析して commit message を書く」は prompt でルール記述できるので、実際の
git diff実行は不要 - 自己完結した prompt ブロックとして書く。 「当然リポジトリ構成を知っている前提」は避け、重要なコンテキストは prompt 内に書き切る
- ツール名は具体的なコマンドではなくセマンティック記述で。
bun testではなく「リポジトリのテストスイートを実行」と書く。後者は Cursor や Gemini でも成立 allowed-toolsは自動転送されなくても残す。 「この skill が何に触れるか」の機械可読宣言として残り、将来のブリッジツールが使える
MCP server 設定の詳細 で Claude Code / Cursor / Gemini 三端が同じ MCP server プールを共有する方法を解説しました。skill 再利用と組み合わせると、Agent 乗り換えコストをほぼゼロに圧縮できます。
シナリオ：Claude Code でコーディング + Gemini で video-summary 再利用
リアルな例: BibiGPT の bibigpt-skill パッケージは Agent Native な「動画要約」能力を提供しており、SKILL.md には「URL 種別の判定」「API の選択」「プロンプト組み立て」の完全な運用マニュアルが書かれています。
Claude Code 内: コーディング中に YouTube チュートリアルの実装アイデアを知りたくて /video-summary https://youtube.com/... 一行で完了。
GeminiDesktop 内: 同じ SKILL.md が自動的に Gem になり、ブラウザで開いているチュートリアル動画に対して /video-summary 現在のタブ で要約が返ります。出力フォーマット・引用スタイル・トーンが両環境で完全に一致 —— system_prompt が文字通り同じファイルだから。
これが「skill を Agent 跨ぎの prompt ソースコードとして扱う」ことの価値です。SKILL.md を 1 つ維持すれば、あらゆる Agent で消費できます。
次：逆方向エクスポート + 三端同期
片道 Claude Code → Gemini は今日動きます。次は 逆方向エクスポート —— Gemini で先に Gem を設計したら、SKILL.md に dump し直して Claude Code が拾える状態にできるか？
技術的には簡単: Gem の name/description/system_prompt を YAML frontmatter と本文に戻すだけ。Cursor の .cursorrules フォーマットも観察中で、「1 つの SKILL.md を 3 Agent 同期」を目指しています。
関連記事: Gemini Mac クライアントに足りない 6 機能 で Claude Code と比較した現在のローカルワークフロー差分を整理しました。skill 移行はその中の一つにすぎません。
まとめ
Agent skill はランタイム固有のフォーマットであってはいけません。SKILL.md は知識の沈殿物 —— 何時間もかけて磨いた「レビュー規範」「ブログ執筆マニュアル」「AEO 監査表」が Agent を変えたら失効する、というのは間違っています。GeminiDesktop の自動スキャン + マッピングは第一歩で、目標は skill ライブラリを本当に「Agent runtime 非依存」にすることです。