Codexからサーバー上のHermesにプロジェクトを移行する

サービスの使い方については、Ailootのドキュメントをご覧ください。

移行前に準備すること#

リポジトリとは、Gitの変更履歴を含むプロジェクトフォルダーです。作業コピーには、編集するファイルが含まれています。ここでの目的は、そのコピーをサーバーに置いて開発を続けることです。まだアプリケーションを訪問者に公開する必要はありません。

エージェントがまだサーバーにインストールされていない場合は、VPSへのHermes Agentのインストールから始めてください。ここでは、動作するHermesのインストール環境、サーバーのターミナル、Gitが必要です。サーバーからアクセスできるリモートリポジトリも必要です。まだない場合は、まずリポジトリを作成し、シークレットを含めずにプロジェクトを保存してください。プライベートリポジトリの場合は、事前に自分のアカウントから読み取りアクセスを設定してください。トークンをリポジトリのURLやエージェントへのメッセージに含めないでください。

移行中は、プロジェクトへの並行編集を一時停止してください。元のコンピューターで、プロジェクトフォルダー自体をターミナルで開き、次を実行します。

git status --short --branch
git status --short --ignored

最初のコマンドは、ブランチとファイルの状態を表示します。Mは変更を、??はGitがまだ追跡していないファイルを意味します。2番目のコマンドでは、無視対象のファイルに!!が付きます。通常のクリーンな状態表示だけでは、Gitの外に必要なファイルがないことの証明にはなりません。

必要な変更を別個のコミットに保存し、通常の方法で適切なブランチをリモートリポジトリにプッシュしてください。プッシュする前に、コミットの内容を確認してください。キー、パスワード、実際のユーザーデータを含めてはいけません。どの変更を保存すればよいかわからない場合は、ファイルを削除したりリポジトリにプッシュしたりせず、まずCodexに変更を一覧にして目的を説明するよう依頼してください。

リポジトリをクローンしても、外部データベース、無視対象フォルダーの内容、Codexとの会話が移行されるとは限りません。チャット履歴、サブスクリプション、プロフィール、エージェント独自の設定は、この移行方法には含まれません。

適切なブランチをサーバーにコピーする#

まず、元のコンピューターで次のコマンドの出力を保存します。

git status --porcelain=v2 --branch

# branch.oidの行には現在のコミットが、# branch.headの行にはブランチが表示されます。コミットとは、保存されたプロジェクトのバージョンです。すでにコミットがある一般的なプロジェクトでは、これを使って元のコピーと新しいコピーを比較できます。この比較では、未コミットの変更は確認できません。

サーバーで、プロジェクトを保存するディレクトリに移動します。リモートリポジトリを新しいフォルダーにクローンします。以下のテンプレートでは、REPOSITORY_URLをリポジトリのURLに、BRANCH_NAMEを保存してプッシュしたブランチ名に、my-projectを新しいフォルダーに付けたい名前に置き換えてください。

git clone --branch BRANCH_NAME REPOSITORY_URL my-project
cd my-project
git status --porcelain=v2 --branch

これはテンプレートであり、そのままコピーできるURLではありません。git cloneは、選択したブランチのフォルダーと作業コピーを作成します。コピー先のフォルダーがすでに存在する場合は、空でなければなりません。コマンドを再実行するために中身を削除せず、新しい名前を選んでください。

両方のコピーで# branch.oidを比較します。値が異なる場合は、サーバーでコードの修正を始めず、選択したブランチ、プッシュしたコミット、並行変更の有無を確認してください。状態の出力に変更済みファイルが表示される場合は、別途調査してください。クリーンアップや強制リセットを使って「一致させる」ことはしないでください。

Gitサブモジュール（入れ子になったリポジトリ）がある場合は、その内容も取得する必要があります。git cloneには--recurse-submodulesオプションがあります。プロジェクトに実際にサブモジュールが含まれており、そのURLが確認済みであれば使用してください。その他の外部リソースに依存するプロジェクトでは、READMEに記載された追加手順が必要な場合があります。

プロジェクトのルールに従って依存関係を復元する#

まず、READMEとプロジェクトの設定ファイルを読みます。必要なランタイムのバージョンと、依存関係のインストールに使うパッケージマネージャーを確認してください。以下の例に出てくるからといって、プロジェクトで通常使うツールをnpmに置き換えないでください。

Node.jsとnpmを使う仮定上の例： リポジトリに整合性のあるpackage.jsonとpackage-lock.jsonがあり、プロジェクトに適したバージョンのNode.jsがサーバーにインストールされているとします。その場合は、プロジェクトフォルダーで次を実行します。

npm ci

npm ciのドキュメントによると、このコマンドはロックファイルからプロジェクト全体の依存関係をインストールし、package.jsonやpackage-lock.jsonを書き換えません。これらの内容に矛盾がある場合、インストールは失敗します。既存のnode_modulesフォルダーは、インストール前に削除されます。

--legacy-peer-depsなど、依存関係ツリーに影響するオプションを使ってロックファイルが作成されている場合、npm ciでも同じオプションが必要です。元のプロジェクトの指示と設定を確認してください。最初の移行エラーを隠すためにロックファイルを削除したり、すべての依存関係を更新したりしないでください。

インストール前に、プロジェクト独自のインストールコマンドと起動コマンドを確認してください。本番データにアクセスできない別の作業コピーで実行し、必要な環境値はチャットやGitの外で設定します。可能であれば、権限を制限したテスト用認証情報でプロジェクトを確認してください。プロジェクトがデータベースやファイルに依存する場合は、まず指示に従って許可されたテストデータセットを復元してください。ソースファイルが同じでも、そのデータの代わりにはなりません。

インストール後、READMEに記載された既存のチェック（用意されていればテストとビルド）を実行します。コマンド名はプロジェクトによって異なります。依存関係のインストールに成功しただけでは、アプリケーションが動作するとは限りません。

Hermesで作業コピーを開く#

サーバーのターミナルで新しいコピーのルートに移動し、すでにインストールされているエージェントを起動します。

cd /absolute/path/to/my-project
hermes

ここで、/absolute/path/to/my-projectはプロジェクトの完全なパスを示すプレースホルダーです。Hermesの起動画面で、作業ディレクトリとターミナルコマンドが実行される環境を確認してください。この起動方法は、サーバー上のHermesのローカルターミナル環境を対象としています。SSHまたはDockerが設定されている場合、エージェントが別の環境でコマンドを実行することがあります。まず、そこで利用できるプロジェクトのパスを確認してください。

ターミナルツールを使って実際の作業フォルダーを確認するようエージェントに依頼し、その後READMEとプロジェクトの指示を読んでもらいます。メッセージにフォルダー名が書かれているだけでは、確認したことになりません。

以下の優先順位は固定されたドキュメントのバージョンに記載されているため、インストール済みのHermesでは異なる場合があります。現在のセッションで使われている指示を確認してください。HermesはAGENTS.mdに対応していますが、そのファイルを読むかどうかは、コンテキストファイルの優先順位によって異なります。Hermesの公式ドキュメントによると、指示ファイルの種類は次の順に選択されます：.hermes.md、AGENTS.override.md、AGENTS.md、CLAUDE.md、.cursorrules。作業を始める前に、古い.hermes.mdや個人用のAGENTS.override.mdがないか確認してください。エージェントがそれらとともにあるAGENTS.mdも必ず適用するとは限りません。

選択された指示には、プロジェクトの目的、チェックコマンド、変更に関する制限を残してください。会話のアーカイブにしないでください。エージェント自体の設定も移行する必要がある場合は、それは別の手順です。その範囲はClaude CodeからCodexへの移行ガイドで説明されています。

エージェントに1つのタスクを与え、結果を確認する#

まず、変更を加えずにプロジェクトを読み進めます。例えば、次のように依頼できます。

指定したフォルダーにある既存のプロジェクトで作業しています。
ターミナルツールを使って、実際の作業ディレクトリを確認してください。
READMEと現在のプロジェクト指示を読んでください。
シークレットを含むファイルを開いたり、環境変数の値を表示したりしないでください。
チェックコマンドと、それを実行するための前提条件を一覧にしてください。
今は、変更、インストール、リポジトリへのプッシュを行わないでください。

次に、インターフェースのテキスト修正など、小さなタスクを1つ決めます。変更するファイルまたは範囲を指定し、付随的な依存関係の更新を禁止してください。実験をメインのコピーから分けたい場合は、まずGit worktreeを使った別の作業コピーについて確認してください。

ファイルの変更内容と、プロジェクトのチェックを再度実行した結果に基づいて、結果を受け入れてください。失敗する可能性のある実験の前に、元のコピーと復元ポイントを保存します。変更を一括ですべてリセットするようエージェントに依頼しないでください。チェックに失敗した場合は、エラーを元のコピーと比較してください。移行の問題か、もともと存在していた不具合かを区別する助けになります。

必要なバージョンのソースファイルがそろい、環境が復元され、必要なデータを安全なテスト環境で利用でき、チェックに合格し、Hermesがまさにこのフォルダーで動作していれば、移行は完了とみなせます。アプリケーションを訪問者に公開するのは別の次の段階であり、この確認には含まれません。

Ailootについて知る。