> ## Documentation Index
> Fetch the complete documentation index at: https://docs.replit.com/llms.txt
> Use this file to discover all available pages before exploring further.

# デプロイメントと公開

> よくある公開に関する質問—公開失敗のデバッグ、ログの読み取り、ランタイムエラーの修正、再デプロイ、リージョンの変更—への回答。

これらの回答は公開とデプロイメントをカバーしています。ステップバイステップのトラブルシューティングについては、[デプロイメントのトラブルシューティング](/ja/build/troubleshooting)をご覧ください。デプロイメントの種類と監視については、[Autoscale デプロイメント](/ja/references/publishing/autoscale-deployments)と[デプロイメントの監視](/ja/references/publishing/monitoring-a-deployment)をご覧ください。

<AccordionGroup>
  <Accordion title="「Autoscale サービスの作成」で公開に失敗します—どのようにデバッグしますか？">
    ほとんどの Autoscale 公開失敗は、デプロイメントログを読むことで修正できます:

    1. **公開**を開き、失敗したデプロイメントを見つけてください。
    2. その隣の三点メニューを選択してログを開いてください。
    3. ログ出力をコピーし、新しい Agent チャットを開いて貼り付け、何が問題で修正方法を尋ねてください。

    実行コマンドを設定しているのに `No run command configured` エラーが表示される場合は、デプロイメント設定を開き、実行コマンドを一度切断してから再追加し、保存して再公開してください。[デプロイメントのトラブルシューティング](/ja/build/troubleshooting)をご覧ください。
  </Accordion>

  <Accordion title="公開に成功した後、アプリに Internal Server Error が表示されます—何が問題ですか？">
    公開が成功したもののライブアプリが 500 エラーを返す場合、問題は Replit のインフラではなくアプリのコードにあります:

    1. **公開**を開き、ログを表示して完全なエラーテキストをコピーしてください。
    2. 新しい Agent チャットを開き、ログを貼り付けて何がエラーの原因かを尋ねてください。
    3. 修正を適用して再公開してください。

    Agent が問題を特定できない場合は、**公開 → 履歴**を開き、最後に動作していたバージョンを見つけて再デプロイしてください。[デプロイメントのトラブルシューティング](/ja/build/troubleshooting)をご覧ください。
  </Accordion>

  <Accordion title="ビルドまたはマイグレーション中にデプロイメントがスタックしています—どうすればよいですか？">
    1. **Shell** ペインを開き、`kill 1` を実行してバックグラウンドプロセスを再起動してください。（`kill 1` は Replit では安全です—プロジェクトのメインプロセスを再起動するだけで、何も削除しません。）
    2. **公開**を開き、**公開**を選択して新しいデプロイメントをトリガーしてください。
    3. 再度失敗する場合は、三点メニューから失敗したデプロイメントのログを開き、ビルドログをコピーして新しい Agent チャットに貼り付けて診断してください。

    デプロイメントがスタックしたままの場合は、完全なビルドログを記載して[Replit サポートにお問い合わせ](https://replit.com/support)ください。[デプロイメントのトラブルシューティング](/ja/build/troubleshooting)をご覧ください。
  </Accordion>

  <Accordion title="アプリは稼働していますが、遅いかタイムアウトが返ります—何を確認すればよいですか？">
    1. デプロイメントログで繰り返すタイムアウトまたはメモリ不足のメッセージを確認してください。
    2. CPU またはメモリの制限についてデプロイメントのリソースを確認してください—[デプロイメントの監視](/ja/references/publishing/monitoring-a-deployment)をご覧ください。
    3. 新しい Agent チャットを開き、最近のログを貼り付けてボトルネックを見つけるよう Agent に依頼してください。

    一般的な原因には、インデックスのないデータベースクエリ、ブロッキングする同期操作、メモリリークが含まれます。[Autoscale デプロイメント](/ja/references/publishing/autoscale-deployments)では、ゼロにスケールした後の最初のリクエストに数秒かかる場合があります—これは通常のコールドスタートです。
  </Accordion>

  <Accordion title="デプロイメント履歴にビルド失敗が表示されています—何が問題かどうやって見つけますか？">
    **公開 → 履歴**を開き、失敗したデプロイメントを選択してビルドログを表示してください。`ERROR` または `FAILED` とマークされた最初の行を見つけてください—それが通常の根本原因で、その後の行は連鎖的な影響です。そのセクションをコピーして新しい Agent チャットに診断のため貼り付けてください。ほとんどのビルド失敗は、依存関係の欠落、誤った実行コマンド、またはデータベースマイグレーションの失敗によるものです。[デプロイメントの監視](/ja/references/publishing/monitoring-a-deployment)をご覧ください。
  </Accordion>

  <Accordion title="アプリはエディタのプレビューでは動作しますが、公開後は動作しません—なぜですか？">
    これはほぼ常に環境間の設定の違いです。次を確認してください:

    * 開発[Secrets](/ja/core-concepts/project-editor/app-setup/secrets)ペインのすべてのキーがデプロイメントのシークレットにも設定されているか—それらは別々の環境です。
    * `DATABASE_URL` が開発ではなく本番データベースを指しているか。
    * ハードコードされた `localhost` または `127.0.0.1` の参照がないか—代わりに相対パスまたは環境ベースの URL を使用してください。

    次に、本番固有のエラーについてデプロイメントログを確認してください。[デプロイメントのトラブルシューティング](/ja/build/troubleshooting)をご覧ください。
  </Accordion>

  <Accordion title="Autoscale デプロイメントが再起動し続けます—SIGTERM または Exit code 1 はどういう意味ですか？">
    [Autoscale デプロイメント](/ja/references/publishing/autoscale-deployments)は設計上定期的に再起動します。ログの `SIGTERM` はプロセスが正常に停止されたことを意味します—これは正常です。`Exit code 1` はプロセス自体がクラッシュしたことを意味します。実際のエラーについては直前の行を確認してください。

    再起動がユーザーに影響するほど頻繁な場合は、未処理のプロミスリジェクション、メモリ不足エラー、または起動に失敗させる欠落した環境変数を探してください。
  </Accordion>

  <Accordion title="環境変数を更新しましたが、公開済みのアプリに反映されていません—なぜですか？">
    Replit は開発と本番のシークレットを別々のストアに保管しており、一方を変更しても他方は更新されません。[開発 Secrets](/ja/core-concepts/project-editor/app-setup/secrets) ペインはエディタでのみ使用可能で、公開済みのアプリはデプロイメントのシークレットから読み取ります。

    ライブアプリの変数を更新するには、デプロイメントのシークレットに設定してから、**公開**を開いて**公開**を選択して再度ライブにしてください。新しい値は新しいデプロイメントの開始時に有効になります。[デプロイメントのトラブルシューティング](/ja/build/troubleshooting)をご覧ください。
  </Accordion>

  <Accordion title="コードを変更せずに再デプロイをトリガーするにはどうすればよいですか？">
    **公開**を開き、**公開**を選択してください。Replit は何も変更がなくても現在のコードをビルドして公開します—シークレットを更新した後、データベースの一時停止解除後、または依存関係の更新を取り込む際に便利です。

    アプリが応答しなくなっていて完全な再デプロイが重い場合は、**Shell** ペインを開いて `kill 1` を実行し、再デプロイせずにバックグラウンドプロセスを再起動してください。
  </Accordion>

  <Accordion title="公開後にアプリのデプロイメントリージョンを変更できますか？">
    はい。**公開**を開き、新しいリージョンを選択して再デプロイしてください。[公開の地理](/ja/references/publishing/publishing-geography)をご覧ください。

    データベースのリージョンはその場では変更できません—移動するには、アプリをフォークして新しいリージョンにフォークバージョンをデプロイしてください。リージョン変更後、`.replit.app` サブドメインが変わる可能性があるため、安定した URL が必要な場合はまず[カスタムドメイン](/ja/references/publishing/custom-domains)を接続し、デプロイメントのシークレットを再追加してください。
  </Accordion>

  <Accordion title="アプリをオフラインにするかアンパブリッシュするにはどうすればよいですか？">
    **公開**を開き、デプロイメントをシャットダウンするオプションを選択して確認してください。アプリはオフラインになり、デプロイメント料金の発生が停止します。プロジェクトファイル、コード、データベースは削除されません—ライブデプロイメントのみ停止します。このデプロイメントに紐付けられたカスタムドメインの接続は削除されるため、再公開する場合は再追加してください。

    コストが気になる場合、[Autoscale デプロイメント](/ja/references/publishing/autoscale-deployments)はトラフィックがないときにゼロにスケールするため、シャットダウンする必要がない場合もあります。
  </Accordion>
</AccordionGroup>

## お困りの場合は？

こちらでデプロイメントに関する質問が解決しない場合は、[Replit サポートにお問い合わせ](https://replit.com/support)ください。