AIコーディングCLI乗り換え時の設定資産移植ガイド：CLAUDE.mdやskillsを別ツールで再現する方法

AIコーディングツールの選択において、多くの開発者はモデルの性能や応答速度に注目します。しかし実際に別のツールへ乗り換えようとしたとき、最初に立ちはだかるのは「設定資産の移植問題」です。

Claude Codeで丁寧に育ててきた`CLAUDE.md`、`.claude/skills/`配下のカスタムスキル、hooks、subagentsといった資産は、GitHub Copilot CLIやGoogle Antigravity CLI（agy）では一体どこに配置し、どう読み替えればよいのでしょうか。

諏訪真一氏の投稿は、この実務的な課題に正面から向き合っています。重要なのは「最強のCLI」を決めることではなく、**ツールを切り替えてもリポジトリに対して一貫した振る舞いを維持すること**だというのです。

リポジトリ固有の知識とルールの蓄積

AIコーディングツールを実用レベルで使い込むと、リポジトリごとに以下のような資産が蓄積されます。

これらは単なる設定ファイルではありません。チーム開発における「暗黙知の明文化」であり、AIエージェントがプロジェクトコンテキストを理解するための重要な資産です。

ツール依存による資産のロックイン問題

問題は、これらの設定がツール固有のディレクトリ構造や命名規則に依存している点です。Claude Codeの`.claude/`ディレクトリ構造が、そのまま他のツールで機能するわけではありません。結果として、ツール移行のコストが高くなり、「乗り換えたいけど移行が面倒で踏み切れない」という状況が生まれます。

ツール間の互換性設計の現状と課題

現在のAIコーディングCLI市場は、各ベンダーが独自の設定スキームを採用している「戦国時代」です。これはブラウザ戦争初期に各社が独自拡張を競った状況に似ています。

**Claude Code**は`.claude/`配下に構造化されたディレクトリを持ち、skills、hooks、agentsを明確に分離しています。一方、**GitHub Copilot CLI**は`.github/copilot-instructions.md`のようなシンプルな構造を採用し、**OpenAI Codex CLI**は`.openai/`配下でJSON形式の設定を好む傾向があります。

この多様性は一見、選択肢の豊かさに見えますが、実際には**ベンダーロックインの温床**となっています。WebにおけるW3C標準のような共通フォーマットが存在しないため、開発者は移行コストの高さからツール選択の自由を失っているのです。

設定資産移植の3つのアプローチ

実務的には、以下の3つのアプローチが考えられます。

**1. 抽象化レイヤーの導入**

ツール固有の設定を直接記述するのではなく、共通の中間フォーマット（例：YAML、TOML）で記述し、各ツール用に変換スクリプトを用意する方法です。Infrastructure as Codeの思想に近いアプローチで、初期投資は必要ですが、長期的には最も柔軟性が高い方法です。

**2. ドキュメント駆動型の移植**

`CLAUDE.md`のようなドキュメントを「ツール非依存の共通資産」と位置づけ、各ツールの設定ファイルをこのドキュメントから生成する方法です。実際、多くのツールはMarkdown形式のインストラクションファイルをサポートしており、最小公約数としての互換性は確保しやすい手法です。

**3. マルチツール対応ディレクトリ構造**

複数のツールの設定ファイルを同一リポジトリに共存させ、使用するツールに応じて参照先を切り替える方法です。`.claude/`、`.copilot/`、`.codex/`を並列に配置し、共通部分は`docs/ai-context/`のような中立的な場所に置く設計です。

メリットと注意点の両面分析

**メリット：**

**注意点：**

適用が推奨されるケース

以下のような状況では、設定資産の移植可能性を重視した設計が特に有効です。

1. 設定資産の棚卸しと抽出

まず現在使用しているツールの設定を洗い出します。

# Claude Codeの設定資産を確認
find .claude -type f -name '*' -exec echo {} \; -exec head -5 {} \;

# プロジェクトルートのAI関連ドキュメントを一覧化
ls -la | grep -E '(CLAUDE|COPILOT|AI|CONTEXT)'

リストアップした各ファイルについて、「ツール固有の機能」と「汎用的なコンテキスト情報」を分類します。後者は移植可能性が高い資産です。

2. 共通コンテキストドキュメントの作成

ツール非依存な`AI_CONTEXT.md`を作成し、以下の情報を集約します。

# AI Coding Context for [Project Name]

## Project Overview
- Architecture: [アーキテクチャの概要]
- Tech Stack: [使用技術]
- Key Conventions: [重要な規約]

## Coding Guidelines
- File Structure: [ファイル構成ルール]
- Naming Conventions: [命名規則]
- Testing Policy: [テスト方針]

## Common Tasks
- Task 1: [頻出タスクの説明と手順]
- Task 2: [頻出タスクの説明と手順]

このドキュメントを各ツールの設定ファイルから参照する形にすれば、ツールを切り替えても同じコンテキストを提供できます。

3. 簡易変換スクリプトの作成

完全自動化は難しくても、移植作業の8割を自動化するスクリプトは作成可能です。

#!/usr/bin/env python3
# claude_to_copilot.py - Claude設定をCopilot形式に変換

import os
import shutil
from pathlib import Path

def convert_claude_to_copilot():
    # CLAUDE.mdを.github/copilot-instructions.mdにコピー
    if Path('CLAUDE.md').exists():
        os.makedirs('.github', exist_ok=True)
        shutil.copy('CLAUDE.md', '.github/copilot-instructions.md')
        print('✓ CLAUDE.md → .github/copilot-instructions.md')
    
    # .claude/skills/を.github/copilot-skills/に変換
    # （各ツールの仕様に応じてカスタマイズ）
    if Path('.claude/skills').exists():
        # 変換ロジックをここに実装
        pass

if __name__ == '__main__':
    convert_claude_to_copilot()

こうしたスクリプトをリポジトリに含めておけば、チームメンバーが異なるツールを使用していても、迅速に環境を再現できます。

AIコーディングツールの評価軸として、モデル性能やUI/UXだけでなく、「設定資産の可搬性」が重要な位置を占めつつあります。ツールベンダー間の競争が激化する中、開発者は特定ツールへのロックインを避け、柔軟に最適なツールを選択できる環境を整えるべきです。

諏訪氏が提起したこの問題は、単なる技術的課題ではなく、AIコーディングツール市場の成熟度を測る試金石でもあります。今後、標準化の動きやツール間互換性を重視したプロダクトが登場することを期待したいところです。

この情報は @suwa-sh / 諏訪真一 さんの投稿を参考にしています。