なぜこの移行でコンテキストが失われるのか
Replit の価値は環境であり、その環境は置き去りにされる
Replit の最大の強みは、アイデアからデプロイされた URL までの距離を縮めることです。ランタイム、データベース、シークレット、デプロイ先、これらすべてが管理されています。ローカルリポジトリとターミナルエージェントに移行することで、コントロールを手に入れる代わりに、まさにこれらを放棄することになります。しかし、プロジェクトの実際の挙動の多くは、その管理された環境によって定義されており、それらの前提条件はエクスポートするコードのどこにも明記されていません。
意思決定はリポジトリではなくチャットにある
プロトタイプがどのように構築されたかを振り返ってみてください。あなたが意図を入力し、エージェントがコードを生成し、あなたがそれを修正し、その修正がメッセージになりました。リポジトリは「最終状態」を記録します。チャットは「なぜそうなったか」を記録します。リポジトリだけを移行すると、「何（what）」は維持されますが、「なぜ（why）」はログアウトしようとしているプラットフォームに残されたままになります。
Claude Code も最初はまっさらな状態から始まる
これは、ほとんどの移行ガイドが省略している部分です。Claude Code は、各セッションを履歴なしで開始します。プロジェクトのルートにある CLAUDE.md と、ユーザーレベルの ~/.claude/CLAUDE.md を読み込み、MCP 経由で接続したものにはアクセスできますが、セッションが終了すると何も残りません。これについては、why Claude Code forgets project context で説明されています。コンテキストの保存場所を変えずにツールだけを切り替えても、問題の場所が変わるだけです。
手動での移行手順
ステップ 1: コードを取り出す
可能であれば、zip ファイルではなく Replit 独自の Git 経路を使用してください。
- Repl 内の Version Control (Git) パネルを開きます。
- GitHub アカウントを連携し、リモートリポジトリを作成します。
- プッシュします。これ以降、双方向の同期が可能になります。Replit での変更をプッシュしたり、GitHub での変更をプルしたりできます。
接続がうまく機能しない場合は、Repl を .zip としてダウンロードし、手動で新しいリポジトリにプッシュしてください。その後、ローカルにクローンし、そのディレクトリで Claude Code を実行します。プロジェクトの履歴を移行するための Anthropic 公式の移行コマンドはありません。Claude Code プロジェクトを再配置するためのコミュニティツールはいくつか存在しますが、Replit からのエクスポートに関しては、通常の Git を使用するのがすべてです。
タブを閉じる前に、環境が何を行っていたかを把握しておきましょう。環境変数とシークレット名（値自体ではなく名前）、データベースとその接続パターン、デプロイ先、スケジュールされたジョブ、そして Replit が暗黙的に処理していたポートやビルドの設定などです。これらは、ローカルマシンで最初に壊れる前提条件です。
ステップ 2: CLAUDE.md でコンテキストを再構築する
ここからが、移行が本当に報われるかどうかを左右する部分です。Replit のチャット履歴を開き、過去2週間分を読み返しながら、次の質問を自分に投げかけてみてください。「2回以上説明しなければならなかったことは何か？」その繰り返しこそが、あなたの知識のインベントリ（目録）です。
それを CLAUDE.md に以下の3つのグループに分けて書き出します。
- プロジェクトの全体像 (Project shape) — どのようなサービスがあるか、データモデルはどのようになっているか、何が非推奨か、Replit が行わなくなった現在のデプロイフローはどうなっているか。
- 理由を伴う意思決定 (Decisions with reasons) — 単に「べき等キーを使用する」ではなく、「プロバイダーがリトライし、テスト中に2回二重課金が発生したため、ウェブフックにべき等キーを導入する」のように記述します。
- 罠 (Traps) — バックフィルの前に実行しなければならないマイグレーション、失敗時に 200 を返すエンドポイント、負荷がかかると不安定になるテストなど。
個人の好みは ~/.claude/CLAUDE.md に、プロジェクトの事実はリポジトリ内のファイルに分けて保存することで、チームメンバーがあなたの個人的な習慣を引き継ぐことなく、プロジェクトに関する情報だけを継承できるようにします。
これは、何も情報がない状態から始めるよりも確実に改善されています。しかし、これには限界もあります。マークダウンファイルは「ブリーフィング（事前説明）」であり、「記憶」ではありません。大変なデバッグセッションの後にそれを更新する人はいませんし、ファイルが肥大化すると毎セッションでトークンを消費するようになります。また、その中の情報は、インシデントレビューに使用するアシスタントや、来月より安価なモデルにルーティングする予定のエージェントには届きません。
より良い方法：ツールに依存しない単一のメモリレイヤー
今回の移行で実際に生き残ったものに注目してください。それは「ファイル」です。CLAUDE.md は次の移行でも生き残ります。そして、ツールの外部に保持している他のすべてのものも同様です。これこそが、プロジェクトの知識を現在使用しているエージェントではなく、メモリレイヤーに置くべき理由です。MemoryLake はそれを一度保持すれば、Claude Code は MCP 経由でそれを読み込むことができ、将来採用する他のツールでも同様に読み込むことができます。
ステップ 1: API キーを作成する
キーを生成し、約30秒で最初のリクエストを送信します。
ステップ 2: 最初のメモリをアップロードする
プロジェクトのコンテキストを保持するドキュメント、画像、ファイルを投入します。先ほど作成した CLAUDE.md、ステップ1の環境インベントリ、アーキテクチャのメモ、プロトタイプ段階でのインシデント報告書、API 仕様書などです。
ステップ 3: AI とエージェントを接続する
Claude、Codex、OpenClaw、およびその他のエージェントに、MCP または API を介してそのメモリへのアクセスを許可します。クライアント固有の手順については、how to add memory to Claude Code を参照してください。これにより、新しいセッションはプロジェクトがすでにロードされた状態で開始され、次のツール変更の際には再構築ではなく、単なる接続の切り替えだけで済みます。同じパターンは、他のコーディングエージェントの移行にも適用されます：Cursor to Claude Code および GitHub Copilot to Claude Code。
移行にかかるコストと削減できるコスト
コストを正直に見積もってみましょう。Git のエクスポートとローカルのセットアップ：1時間未満。Replit が処理していた環境の前提条件の復元：半日（そのほとんどは、エラーが発生したときに何かが足りないことに気づくプロセスに費やされます）。知識のインベントリを CLAUDE.md に書き出す：さらに半日（そして、これが唯一、将来にわたって効果が蓄積される部分です）。
次に、回避できる継続的なコストについてです。もし、あなたのプロジェクトの常時コンテキストが 2,000 トークンあり、セッションやエージェント全体で1日に20回再提示されるとすると、同じことを繰り返すために月に約 1.2M トークンを消費していることになります。さらに、セッションごとに4〜5分の再説明の時間がかかります。移行は、これを解決する最も安価なタイミングです。なぜなら、すでに一度再構築のコストを支払っているからです。選択肢は、次のツールで使えなくなるファイルに再構築するか、そうではないレイヤーに再構築するか、それだけです。
移行のためのベストプラクティス
コードだけでなく環境もエクスポートする
プロトタイプは管理された環境で動作していました。移行する前に、シークレットの名前、データベースのトポロジー、cron ジョブ、ビルド手順を書き留めておきましょう。これは「Replit では動いたのに」というバグの最も一般的な原因であり、20分あれば完全に防ぐことができます。
チャットログではなく「結論」を移行する
Replit の履歴をそのまま CLAUDE.md に貼り付けないでください。決定事項（選択肢、理由、日付）を抽出し、それらを保存します。結論は検索しやすく、書き起こし（トランスクリプト）は重要な情報を埋もれさせ、トークンを無駄に消費します。
うまくいっているなら、Replit でのプロトタイピングを続ける
多くのチームが、アイデアを迅速に検証するために Replit を使い続け、本番環境向けの堅牢化のために Claude Code を使用しています。この役割分担がうまく機能するのは、双方が同じプロジェクトメモリを読み込んでいる場合のみです。そうでない場合、2つの異なる「真実」を維持することになり、同じ罠に2回はまることになります。
結論
Replit から Claude Code への移行は、1つの名前で呼ばれる2つの移行プロセスです。1つ目は機械的な移行です。Git パネルを接続し、GitHub にプッシュし、クローンするだけで、1時間で完了します。2つ目はコストのかかる移行です。Replit が静かに処理していた環境の前提条件と、エージェントのチャットにしか存在しなかった推論プロセスです。
これら両方を、一度、意図的に再構築してください。ただし、その知識はエディタの外部にあるものに再構築してください。なぜなら、今日移行しようとしているツールは、あなたが最後に移行するツールではないからです。プロジェクトのメモリがエージェントの読み取るレイヤーに存在していれば、「移行」は「すべてを再説明すること」を意味しなくなり、「新しいクライアントを同じソースに向けること」を意味するようになります。