# Codexからサーバー上のHermesにプロジェクトを移行する > Hermesで作業を続けるために、リポジトリをサーバーに移行する方法：保存済みの変更、依存関係、シークレット、作業フォルダー、開発を続ける前の確認。 Source: https://ailoot.ai/blog/ja/codex-project-to-hermes-server/ Canonical: https://ailoot.ai/blog/ja/codex-project-to-hermes-server/ Language: ja Publisher: Ailoot (https://ailoot.ai/) Translation: guide-082 Revision: sha256-742161323bc77a342becfbfa24ebf24821454c34834a504b2610683d2efc0514 サービスの使い方については、[Ailootのドキュメント](https://ailoot.ai/docs/)をご覧ください。
重要なポイント Codexを使って作成したプロジェクトでHermesでの作業を続けるには、リポジトリ自体を移行し、その環境を復元します。この方法では、エージェントからプロジェクトをインポートする手順を別途行う必要はありません。まず保存済みのファイルと依存関係を確認してから、Hermesで正しいフォルダーを開きます。このガイドでは、サーバーとHermesの設定がすでに完了しており、リポジトリにアクセスできることを前提としています。
## 移行前に準備すること リポジトリとは、Gitの変更履歴を含むプロジェクトフォルダーです。作業コピーには、編集するファイルが含まれています。ここでの目的は、そのコピーをサーバーに置いて開発を続けることです。まだアプリケーションを訪問者に公開する必要はありません。 エージェントがまだサーバーにインストールされていない場合は、[VPSへのHermes Agentのインストール](https://ailoot.ai/blog/ja/hermes-agent-vps-24-7/)から始めてください。ここでは、動作するHermesのインストール環境、サーバーのターミナル、Gitが必要です。サーバーからアクセスできるリモートリポジトリも必要です。まだない場合は、まずリポジトリを作成し、シークレットを含めずにプロジェクトを保存してください。プライベートリポジトリの場合は、事前に自分のアカウントから読み取りアクセスを設定してください。トークンをリポジトリのURLやエージェントへのメッセージに含めないでください。 移行中は、プロジェクトへの並行編集を一時停止してください。元のコンピューターで、プロジェクトフォルダー自体をターミナルで開き、次を実行します。 ```bash git status --short --branch git status --short --ignored ``` 最初のコマンドは、ブランチとファイルの状態を表示します。`M`は変更を、`??`はGitがまだ追跡していないファイルを意味します。2番目のコマンドでは、無視対象のファイルに`!!`が付きます。通常のクリーンな状態表示だけでは、Gitの外に必要なファイルがないことの証明にはなりません。 必要な変更を別個のコミットに保存し、通常の方法で適切なブランチをリモートリポジトリにプッシュしてください。プッシュする前に、コミットの内容を確認してください。キー、パスワード、実際のユーザーデータを含めてはいけません。どの変更を保存すればよいかわからない場合は、ファイルを削除したりリポジトリにプッシュしたりせず、まずCodexに変更を一覧にして目的を説明するよう依頼してください。 | プロジェクトの部分 | 移行前に確認すること | |----|----| | ソースファイルとGitの履歴 | 必要な変更が保存され、選択したブランチでリモートリポジトリからアクセスできる | | READMEとエージェントの指示 | 起動手順、チェック、制限事項が記載され、指示が最新である | | 依存関係のファイル | 依存関係の定義と、プロジェクトで使うロックファイル（バージョンを固定するファイル）が保存されている | | シークレット | サーバー上で設定する別の安全な方法があり、その値がGitにもチャットにも含まれていない | | データベースとアップロード済みファイル | 許可されたテストデータの入手先と、プロジェクトの指示に従った復元方法がわかっている | リポジトリをクローンしても、外部データベース、無視対象フォルダーの内容、Codexとの会話が移行されるとは限りません。チャット履歴、サブスクリプション、プロフィール、エージェント独自の設定は、この移行方法には含まれません。 ## 適切なブランチをサーバーにコピーする まず、元のコンピューターで次のコマンドの出力を保存します。 ```bash git status --porcelain=v2 --branch ``` `# branch.oid`の行には現在のコミットが、`# branch.head`の行にはブランチが表示されます。コミットとは、保存されたプロジェクトのバージョンです。すでにコミットがある一般的なプロジェクトでは、これを使って元のコピーと新しいコピーを比較できます。この比較では、未コミットの変更は確認できません。 サーバーで、プロジェクトを保存するディレクトリに移動します。リモートリポジトリを新しいフォルダーにクローンします。以下のテンプレートでは、`REPOSITORY_URL`をリポジトリのURLに、`BRANCH_NAME`を保存してプッシュしたブランチ名に、`my-project`を新しいフォルダーに付けたい名前に置き換えてください。 ```bash 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がサーバーにインストールされているとします。その場合は、プロジェクトフォルダーで次を実行します。 ```bash npm ci ``` [npm ciのドキュメント](https://raw.githubusercontent.com/npm/cli/c039090578a5b21a1aa3aba9c96e199feaf1823a/docs/lib/content/commands/npm-ci.md)によると、このコマンドはロックファイルからプロジェクト全体の依存関係をインストールし、`package.json`や`package-lock.json`を書き換えません。これらの内容に矛盾がある場合、インストールは失敗します。既存の`node_modules`フォルダーは、インストール前に削除されます。 `--legacy-peer-deps`など、依存関係ツリーに影響するオプションを使ってロックファイルが作成されている場合、`npm ci`でも同じオプションが必要です。元のプロジェクトの指示と設定を確認してください。最初の移行エラーを隠すためにロックファイルを削除したり、すべての依存関係を更新したりしないでください。 インストール前に、プロジェクト独自のインストールコマンドと起動コマンドを確認してください。本番データにアクセスできない別の作業コピーで実行し、必要な環境値はチャットやGitの外で設定します。可能であれば、権限を制限したテスト用認証情報でプロジェクトを確認してください。プロジェクトがデータベースやファイルに依存する場合は、まず指示に従って許可されたテストデータセットを復元してください。ソースファイルが同じでも、そのデータの代わりにはなりません。 インストール後、READMEに記載された既存のチェック（用意されていればテストとビルド）を実行します。コマンド名はプロジェクトによって異なります。依存関係のインストールに成功しただけでは、アプリケーションが動作するとは限りません。 ## Hermesで作業コピーを開く サーバーのターミナルで新しいコピーのルートに移動し、すでにインストールされているエージェントを起動します。 ```bash cd /absolute/path/to/my-project hermes ``` ここで、`/absolute/path/to/my-project`はプロジェクトの完全なパスを示すプレースホルダーです。Hermesの起動画面で、作業ディレクトリとターミナルコマンドが実行される環境を確認してください。この起動方法は、サーバー上のHermesのローカルターミナル環境を対象としています。SSHまたはDockerが設定されている場合、エージェントが別の環境でコマンドを実行することがあります。まず、そこで利用できるプロジェクトのパスを確認してください。 ターミナルツールを使って実際の作業フォルダーを確認するようエージェントに依頼し、その後READMEとプロジェクトの指示を読んでもらいます。メッセージにフォルダー名が書かれているだけでは、確認したことになりません。 以下の優先順位は固定されたドキュメントのバージョンに記載されているため、インストール済みのHermesでは異なる場合があります。現在のセッションで使われている指示を確認してください。Hermesは`AGENTS.md`に対応していますが、そのファイルを読むかどうかは、コンテキストファイルの優先順位によって異なります。[Hermesの公式ドキュメント](https://raw.githubusercontent.com/NousResearch/hermes-agent/44f6d3bbeee093ab985bb1e16d7346fdc3b1db7a/website/docs/user-guide/features/context-files.md)によると、指示ファイルの種類は次の順に選択されます：`.hermes.md`、`AGENTS.override.md`、`AGENTS.md`、`CLAUDE.md`、`.cursorrules`。作業を始める前に、古い`.hermes.md`や個人用の`AGENTS.override.md`がないか確認してください。エージェントがそれらとともにある`AGENTS.md`も必ず適用するとは限りません。 選択された指示には、プロジェクトの目的、チェックコマンド、変更に関する制限を残してください。会話のアーカイブにしないでください。エージェント自体の設定も移行する必要がある場合は、それは別の手順です。その範囲は[Claude CodeからCodexへの移行ガイド](https://ailoot.ai/blog/ja/migrate-claude-code-to-codex/)で説明されています。 ## エージェントに1つのタスクを与え、結果を確認する まず、変更を加えずにプロジェクトを読み進めます。例えば、次のように依頼できます。 ``` 指定したフォルダーにある既存のプロジェクトで作業しています。 ターミナルツールを使って、実際の作業ディレクトリを確認してください。 READMEと現在のプロジェクト指示を読んでください。 シークレットを含むファイルを開いたり、環境変数の値を表示したりしないでください。 チェックコマンドと、それを実行するための前提条件を一覧にしてください。 今は、変更、インストール、リポジトリへのプッシュを行わないでください。 ``` 次に、インターフェースのテキスト修正など、小さなタスクを1つ決めます。変更するファイルまたは範囲を指定し、付随的な依存関係の更新を禁止してください。実験をメインのコピーから分けたい場合は、まず[Git worktreeを使った別の作業コピー](https://ailoot.ai/blog/ja/codex-worktree-separate-task/)について確認してください。 ファイルの変更内容と、プロジェクトのチェックを再度実行した結果に基づいて、結果を受け入れてください。失敗する可能性のある実験の前に、元のコピーと復元ポイントを保存します。変更を一括ですべてリセットするようエージェントに依頼しないでください。チェックに失敗した場合は、エラーを元のコピーと比較してください。移行の問題か、もともと存在していた不具合かを区別する助けになります。 必要なバージョンのソースファイルがそろい、環境が復元され、必要なデータを安全なテスト環境で利用でき、チェックに合格し、Hermesがまさにこのフォルダーで動作していれば、移行は完了とみなせます。アプリケーションを訪問者に公開するのは別の次の段階であり、この確認には含まれません。 [Ailoot](https://ailoot.ai/)について知る。 ## Codexからサーバー上のHermesにプロジェクトを移行する：よくある質問 ### リポジトリのクローンで作業環境全体を移せますか？ いいえ。Gitのクローンでは、無視対象のファイル、外部データベース、アップロード済みデータ、秘密情報、エージェントの会話履歴は移りません。必要な依存関係と、使用が許可されたテストデータは、プロジェクトの指示に従って別に復元します。 ### サーバー側のコピーを編集する前に何を比較しますか？ 保存したブランチとコミットIDを元のコピーと比較し、未コミット変更を確認して、Hermesに実際の作業ディレクトリを検証させます。その正確なコピーで、既存のプロジェクトチェックを実行してください。 ## Ailoot · 企業とそのプロジェクト群 Ailootは、蓄積した運営経験、幅広い顧客基盤、安定したサービス、継続的なKPI管理を基盤としています。 企業とそのプロジェクト群：数百万の顧客、毎月数十億規模の売上。 Ailootはこの運営経験を、お客様の製品、エージェント、アプリケーション、自動化でAI機能を利用するためのAPIアクセスに活かしています。