複数のAIコーディングエージェントを併用しているチームで、「セッション履歴を別ツールに移せば乗り換えは楽になる」と考えている方に向けた内容です。
Claude Code（Anthropic社製のターミナル型コーディングエージェント）のセッションを、session-migrate というOSSツールでCodexやGitHub Copilot CLIなど7つの形式に変換した検証結果が公開されています。会話やツール実行の文脈は思いのほか良く移りましたが、組織で安全にエージェントを運用するための「統制」は一切移らなかったという指摘が中心です。この違いは、ベンダーロックイン対策を検討するエンジニアリングリーダーにとって見過ごせない論点です。
何が検証され、なぜ注目に値するか
セッションとは、エージェントとの対話履歴・ツール呼び出し・思考過程などを記録したログファイルのことです。
Claude CodeはこれをJSONL形式（1行が1つのJSONオブジェクトになったログ形式）で保存します。このセッションファイルを別ベンダーの形式に変換できれば、乗り換えコストが下がりロックインが緩和される、という発想が背景にあります。
検証ではmacOS上のPython 3.12仮想環境にsession-migrate 0.8.0を導入し、341,646バイト・90レコードの実際のClaude Codeセッションを凍結（追記を止めた状態）にしてから変換を実施しています。対象はCodex、Pi、GitHub Copilot CLI、Qwen Code、Kimi Code、Muse Code、Mistral Vibeの7形式です。
注目すべきは、変換先ごとの差がほとんどなかった点です。生成されたレコード数は33〜50と幅がありますが、これは同じ内容を各形式が違う単位で分割しているだけで、情報量の差ではありません。
技術的な仕組みと失われたもの
session-migrateは「ネイティブセッション → 検証済みイベントタイムライン → ネイティブターゲット → resume」という経路で変換します。
つまり各ベンダー固有の形式をいったん共通の中間表現（イベントタイムライン）に正規化し、そこから変換先ネイティブ形式を再構築する仕組みです。この中間表現に入らない情報は、どの変換先を選んでも失われます。
実際、7つの変換先すべてで欠落レコード数は54〜57件とほぼ一致し、欠落した「thinking」ブロック（モデルの内部推論を記録した部分）は全ターゲットで9件固定でした。
欠落の内訳は主にソース側のメタデータレコード、ツール参照レコード、そしてプライベートなthinking内容です。Codexでは追加でセッションタイトルが1件失われ、Vibeだけが他ターゲットが捨てた2件のツール参照レコードを保持していました。
この結果が示すのは、「変換先を変えても欠落量はほぼ変わらない」という事実です。つまり失われる情報を決めているのは変換先の実装ではなく、元のセッションが持つ「イベントの語彙（vocabulary）」、すなわちClaude Code側がそもそも何を記録形式として持っているかという制約です。
背景：ポータビリティと統制は別レイヤーの話
この検証結果を、開発生産性の観点で整理すると次のように分解できます。
- 会話コンテキストのポータビリティ: プロンプトの流れ、ツール呼び出し結果、コード差分などの「作業内容」
- 統制のポータビリティ: 誰が承認したか、なぜその変更が許可されたか、監査ログをどこで確認できるか
検証が明らかにしたのは、前者はツール変換で概ね移せるが、後者は移らないという点です。セッションファイルは開発者個人のローカルJSONLに置かれ、PR説明文に一部がコピーされ、別の人はすでにディレクトリを消している、といった状態は個人の実験なら問題になりません。しかし本番アクセスや個人情報に関わる変更が絡むと、これは運用上の欠陥になります。
逆方向のリスクも指摘されています。セッションファイルには本番ログの断片やスキーマ情報、時には実データのサンプルが含まれることがあります。変換コマンドは単なる便利機能ではなく、データを別ベンダー形式で持ち出す新たな経路にもなり得ます。
対照的なアプローチとして紹介されているのがSlack Codeです。エージェントをメンションすると専用のコードチャンネルが作られ、関係者・コード差分・計画文書・ライブHTMLプレビューが集約され、完了後はチャンネルごと検索可能な記録として保存されます。この方式は作業記録を個人のワークステーションから共有の運用基盤に移し、既存のSlackの権限・管理者コントロールをそのまま引き継ぐ設計です。IT部門が新たに監査体制を作り直す必要がない、という点が構造的な違いです。
読者への影響と今日確認できること
複数のコーディングエージェントを併用、または将来の乗り換えを検討している場合、次の点を確認しておく価値があります。
- 使用中のツールのセッション保存場所: Claude Codeなら
~/.claude配下のJSONLファイルなど、どこに何が残るかを把握する - 承認・監査の記録先: 「なぜこの変更が許可されたか」を後から追える場所が、個人のローカルログ以外にあるか
- 変換ツール導入時の対応バージョン: session-migrateのREADMEはPython 3.11+およびLinuxを公式サポート対象としており、macOSでの動作は検証時点で公式サポート範囲外だった点に注意が必要です
- 欠落しても業務上問題ない情報かどうか: thinkingブロックやメタデータが失われても支障がないワークフローか、事前に洗い出しておく
社内でエージェント利用ルールを検討する際は、セッションファイルの変換可否をロックイン対策の主指標にしないことをおすすめします。むしろ、承認フローや監査ログをどのレイヤー（Slackのようなチャットプラットフォーム、社内の変更管理システムなど）に持たせるかを先に決め、コーディングエージェント自体は差し替え可能な「実行エンジン」として扱う設計が現実的です。
まとめ
検証結果を振り返ると、ポイントは次の3点に整理できます。
- セッション変換ツールは会話・ツール実行の文脈をよく保持するが、欠落量は変換先を変えても大きくは変わらない
- 欠落するのはメタデータ・ツール参照・thinkingブロックであり、これらは組織の監査要件に関わりうる
- ロックイン対策は「ログの移植性」ではなく「承認と監査の記録場所」を軸に設計するほうが実務的
まずは自社で使っているエージェントのセッション保存先と、承認記録がどこに残っているかを一度書き出してみることから始めてみてください。